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

From: "Smith, Allyn D" <[email-masked]>
Date: Mon, 22 Nov 1999 16:30:54 -0700

Here are my humble comments, suggestions, and opinions on this draft.

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.

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
is only a minor reference (and not the only reference) to TCPs action to
send a reset in response to the changed precedence bits.  So, the sentence
should read:
   "The connection must be reset [RFC793, pages 36,37,40,66,67,71].

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
that it reads:
   "... these three bits may or may not be used to denote the
   precedence of the IP packet."

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
the above text is taken out of context.  What is "not intended for the
current connection" is further defined later in the same section.  The
"design philosophy" is laid out clearly in this section and others: a reset
must be sent whenever a precedence value is received that does not exactly
match the requested precedence value.  Therefore, a changed precedence value
clearly is "NOT intended for the current connection" so a reset must be
sent.  To suddenly say that with the advent of Diffserv the opposite is now
true, that is, a changed precedence value clearly "IS intended for the
current connection", and to say that it fits with the existing text and
"design philosophy" in RFC 793, is defiant and contradictory.  What this
paragraph says to me is NOT that the proposed change fits the original TCP
"design philosophy", but that the TCP "design philosophy" has been
manipulated to fit the change.  Personally, I would like to see the above
paragraph removed from the draft.  The proposed modification stands on its
own merit without having to describe an interpretation of TCPs "design
philosophy".

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
governing the RST generation in response to a received precedence value are
described in section 3.9, Event Processing, SEGMENT ARRIVES (the rules are
on various page numbers and are dependent on state and type of segment
arriving).  The rules in section 3.9 describe that the sequence number must
be checked for validity before the precedence value.  
	Also, it is not the "RFC 793 rules" that pose a denial-of-service
threat, but it is a poorly implemented TCP receiver that poses the threat.
If a TCP does not first verify the incoming sequence number before the
precedence value, then that TCP is broken.
	Sooooo.....  Here's how I think the security section should read:

	"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."

Kind Regards,
___________________________
Al Smith
Unisys
1.651.635.5769    NET 524.5769
[email-masked]
___________________________

-----Original Message-----
From: Scott Bradner [mailto:[email-masked]]
Sent: Sunday, November 21, 1999 6:49 AM
To: [email-masked]
Subject: [Tsvwg] draft-xiao-tcp-prec-00.txt

This is an Working Group last-call for draft-xiao-tcp-prec-00.txt for
Proposed Standard.  PLease send any comments to the tsvwg list by 12/6/99.

Abstract

   This draft describes a potential conflict between TCP [RFC793] and
   DiffServ [RFC2475] on the use of the three leftmost bits in the TOS
   octet of an IPv4 header [RFC791] or the Traffic Class octet of an
   IPv6 header [RFC2460]. In a network that contains DiffServ capable
   nodes, such a conflict can cause failures in establishing TCP
   connections or can cause some established TCP connections to be reset
   undesirably. This draft proposes a modification to TCP for resolving
   the conflict.

thanks

Scott

_______________________________________________
tsvwg mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/tsvwg