Subject: TOS issues with non RFC compliant TCP stacks

From: Alan Hannan <[email-masked]>
Date: Tue, 8 Jun 1999 22:45:11 -0700

Howdy.

  We have learned of a problem with non RFC compliant users of
  the Internet.

  We believe this problem will be of interest to NANOG and tcp-impl
  WG participants.

  We would like to involve a larger body so that:

	- more people are aware of this issue

	- ISPs can more quickly handle potential problems when 
	  they arise

	- we can learn about additional IP stacks that have this problem

	- alternate opinions can be presented that may argue this 
	  behaviour is appropriate, and RFC compliant

  It has come to our attention that a notable fraction of the
  internet client community uses a TCP stack which is not RFC
  compliant, as far as we can determine.

  Certain versions of MacTCP send a RST when they receive SYN ACK
  packets of TOS!=0.

  I assume there are other TCP implementations which also have
  this behaviour.

  This concerns us, as we would like to see IP transport utilize
  TOS markings for the growth of the Internet.

  In discussions with several vendors, colleagues, and review of
  RFCs, the following phrase seems most applicable, from Postel in
  RFC 793:

------------------------ = ------------------------
2.10.  Robustness Principle
 
  TCP implementations will follow a general principle of robustness:  be
  conservative in what you do, be liberal in what you accept from
  others.
------------------------ = ------------------------
 
  Open Transport (an alternate, Apple supported stack) follows
  this principle and works well.  Additionally, a patch is available 
  on the net for MacTCP (see below).

  So, the empirical part:  We implemented TOS bit-setting for the
  purpose of tracking traffic flows and traffic levels.  For an
  entirely arbitrary reason, we chose TOS=5 for the default of
  traffic.  We found that MacTCP ceased functioning.  The MacTCP
  stack would initiate an RST when receiving SYN ACK packets with
  a TOS=5, as the SYN packets had a TOS=0.  Therefore, all TCP
  sessions would fail.

  We can quite simply work around our customer's problem by setting
  TOS=0 on all traffic to/from the customer interface.

  However, any traffic towards nonFGC customer's [ie, from our
  interconnection partners] will not be modified.  Therefore, they
  are also vulnerable to this problem.

  Because of a hardware implementation limitation on most of
  routers, INbound TOS setting is efficient, while OUTbound TOS
  setting is inefficient.

  So it is difficult for us to modify the TOS settings leaving
  our network.

  It would be moderately trivial for most interconnection partners
  to modify the TOS settings on input.  This is a path we plan
  to pursue.

  As it turns out, this is an archaically (sp) known problem, with
  a pre-existing patch.

  Information about this patch for MacTCP exists at:

	http://www.mactcp.org.nz/mactcp.html

  At this time we do not modify TCP TOS bits.  Once we have more
  information we intend to move forward with the TOS modifications,
  after notifying our InterConnection partners and customers of
  potential impact.

  Thank you for your consideration.

  -alan

---

From: Joe Touch <[email-masked]>
Date: Wed, 9 Jun 1999 00:57:53 -0700 (PDT)

> From [email-masked] Tue Jun  8 23:27:07 1999
> Date: Tue, 8 Jun 1999 22:45:11 -0700
> From: Alan Hannan <[email-masked]>
> To: [email-masked], [email-masked]
> Subject: TOS issues with non RFC compliant TCP stacks
...
>   Certain versions of MacTCP send a RST when they receive SYN ACK

Far as I have found, the spec (STD7) says that TOS is a TCP 
per-connection property (page 12). 

On page 36 it appears to clearly state that (case 2):

    terminated then).  If our SYN has been acknowledged (perhaps in this
    incoming segment) the precedence level of the incoming segment must
    match the local precedence level exactly, if it does not a reset
    must be sent.

>   a TOS=5, as the SYN packets had a TOS=0.  Therefore, all TCP

Granted, this is a first cut read, but wouldn't this appear
to indicate that NOT sending the RST is the violation of the 
spec?

Can you clarify?

Joe