Subject: Re: [Tsvwg] draft-xiao-tcp-prec-00.txt

From: Vern Paxson <[email-masked]>
Date: Tue, 23 Nov 1999 18:54:37 PST

Thanks for the thoughtful comments.  They all strike me as on target
(though I haven't touched based with my coauthors on them yet, in case
they disagree).

> 1. The Abstract section, first sentence:
> 
>    "This draft describes a potential conflict between TCP [RFC793] and
>    DiffServ [RFC2475] on the use of the three leftmost bits in the TOS
>    octet ...."
> 
> 	Please remove the word "potential".  There is really nothing
> "potential" about this; there is a "direct" conflict between the RFC 2475
> redefinition of the TOS byte and RFC 793's described use of it.

Fixed.

> 2. The Introduction section, page 2, third paragraph, last sentence:
> 
>    "The connection must be reset [RFC793, page 37]."
> 
> 	Please add pages 36, 40, 66, 67, and 71 to the reference.  Page 37

Fixed - thanks for catching this.

> 3. The Terminology section, page 2, precedence field, last sentence:
> 
>    "... these three bits may or may not used to denote the
   precedence of the IP packet."
> 
> 	Please insert the word "be" between the words "not" and "used" such

Fixed.

> 4. The Pproposed Modification to TCP section, page 5, fifth paragraph:
> 
>    "The proposed modification to TCP is in conformance with TCP's design
>    philosophy. In RFC 793, page 36, it is stated that:
> 
>         As a general rule, reset (RST) must be sent whenever a segment
>         arrives which apparently is not intended for the current connec-
>         tion.  A reset must not be sent if it is not clear that this is
>         the case."
> 
> 	If this paragraph is intended to support the justification in making
> this change, then it strikes me as being somewhat of a stretch.  I believe

I disagree that it's a stretch (much less "defiant and contradictory" :-),
but agree that it's not necessary, so I've removed it.

> 5. The security considerations section, page 5, first paragraph:
> 
>    "The RST generation rules given on page 37 of RFC 793 appear to indi-
>    cate that the reception of any segment with an incorrect precedence
>    field terminates a connection.  If this is true regardless of the
>    correctness of the sequence numbers in the segment's header, then the
>    RFC 793 rules present a serious denial-of-service threat, as all an
>    attacker must do to terminate a connection is guess the port numbers
>    and then send two segments with different precedence values; ..."
> 
> 	I believe the above statement is somewhat naive in assuming that the
> RST generation rules are encompassed on page 37.  More specific rules

Well, the idea was that there's a pitfall in someone not closely following
the spec in this regard.  Your suggested wording:

> 	"A TCP implementation that terminates a connection upon receipt of
> any segment with an incorrect precedence field, regardless of the
> correctness of the sequence numbers in the segment's header, poses a serious
> denial-of-service threat, as all an attacker must do to terminate a
> connection is guess the port numbers and then send two segments with
> different precedence values; one of them is certain to terminate the
> connection.  Accordingly, the change to TCP processing proposed in this memo
> would yield a significant gain in terms of that TCP implementation's
> resilience.
> 
> 	On the other hand, a TCP implementation that follows stricter
> processing rules makes TCP spoofing attacks more difficult, as the attacker
> must not only guess the victim TCP's initial sequence number, but also its
> precedence setting."

addresses this better, and I've incorporated it.

	Thanks,

		Vern