[e2e] TCP Option Negotiation

[Bob Braden]

  *> 
  *> Someone recently pointed out a possible correctness issue with TCP
  *> option negotiation to me, and I was wondering if anybody here had an
  *> explanation.  My understanding is that TCP stacks, upon receiving an
  *> option they do not understand or expect, should ignore it.  This creates
  *> a loophole, however, in options like window scaling negotiation and SACK
  *> permitted, whereby the communicating hosts can come to differing
  *> opinions of the state of the option.
  *> 
  *> In the admittedly improbable case that a host sends a TCP SYN requesting
  *> say, window scaling, and then crashes, a new host may immediately
  *> receive the old host's address, and issue its own SYN to the same
  *> destination from the same port number.  Suppose that SYN is lost in the
  *> network.  The new host may happen to receive the SYN ACK from the
  *> original SYN.  Assuming, again, that the stars are aligned and the
  *> sequence numbers match, the new host would accept it, and consider the
  *> connection established.  This is correct behavior.  Except for the
  *> options.
  *> 
  *> The new host may not understand window scaling, and just ignore the
  *> option.  Now the communicating hosts have different opinions of what the
  *> window sizes are.  Clearly the reliable byte stream semantic is
  *> maintained, but the transmission is likely to be highly inefficient,
  *> overrunning receive windows on a frequent basis.  A similar issue arises
  *> with SACK negotiation, although the affect is even more harmless.
  *> 
  *> Is there a correctness argument I'm missing, or is this just considered
  *> too improbable a case to be concerned with?
  *> 
  *> - Alex

Alex,

This seems to be another manifestation of the standard  problem of old
duplicate packet.   Your scenario is a violation of TCP's "quiet time"
requirement upon host crash and restart (it's the same host if it has
the same IP address).  Quiet time is a vital part of TCP's machinery to
protect against old duplicates.

Bob Braden

  *> 
  *> --
  *> NMS / PDOS Groups
  *> MIT Laboratory for Computer Science
  *> 545 Technology Square, NE43-512, Cambridge, Massachusetts 02139
  *>                                      http://nms.lcs.mit.edu/~snoeren
  *>