Talk:TCP spoofing
Existing CZ work, and clarifying differences
I've learned, through fairly bitter experience, that it's usually best to use the full name of a subject in its article name and first sentence, define the abbreviation in the bold name required in the first sentence of the introduction, a sentence that is part of the CZ style:
- The fundamental Internet end-to-end protocol for implementing reliable delivery that accounts for packet loss is the Transmission Control Protocol (TCP).
We really don't have a good convention for naming articles that are subarticles of another. Some people use main article name, subarticle name, but others find the convention ugly. In this case, your safest course would be to rename (using the move command) to Transmission Control Protocol spoofing, and also create a redirect page for TCP spoofing.
Have you looked through the existing article on Transmission Control Protocol? In all fairness to you, I'm working on that article today, to add a good deal more background information that affects the topics being discussed in this article. Writing a main article on a protocol is challenging, as we don't want to repeat the whole RFC, but the important parts need to be present. What is especially important in a main article are the operational problems that might not be subjects of any specific RFC. Sequence numbers, for example, produce a number of difficulties in different contexts to which you allude, such as performance in high bandwidth×delay products, and in the sequence number prediction attack.
The spoofing you describe is not the most common way to deal with the bandwidth×delay problem; the first fix is described in RFC 1323. You should be familiar with that technique, and then explain the advantages and disadvantages of spoofing over the use of timestamps and window scaling.
Also, there is more than one attack that involves sequence number prediction. I'd suggest that you either cite some of the others, or explain the general principle, or not have a one sentence mention of the issue without further explanation.
These comments are meant to help, not to attack. You've helped me, because I now have a reason to work on the main TCP article and give you some background; there will be more detail there today although I may not have time to put in everything I'd like.
Howard C. Berkowitz 10:16, 23 August 2008 (CDT)