TOS issues with non RFC compliant TCP stacks

Alan Hannan alan at globalcenter.net
Wed Jun 9 05:45:11 UTC 1999



  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





More information about the NANOG mailing list