Re: Re[10]: www.isoc.org unreachable when ECN is used

On Mon, 15 Dec 2003 10:22:24 +0100, "Anthony G. Atkielski" 
<anthony(_at_)atkielski(_dot_)com>  said:

>   "If a host has received an ECN-setup SYN packet, then it MAY send
>   an ECN-setup SYN-ACK packet.  If a host has not received an ECN-setup
>   SYN packet, then it MUST NOT send an ECN-setup SYN-ACK packet."
See? You parsed it.  Couldn't have been TOO ambiguous.

>   "There exists at least one faulty TCP implementation in which TCP
>   receivers set the Reserved field of the TCP header in ACK packets (and
>   hence the SYN-ACK) simply to reflect the Reserved field of the TCP
>   header in the received data packet."
>
> If reserved is not synonymous with must-be-zero, then why is reflection
> of the reserved field "faulty"?
Because simply parroting back bits that you don't understand is broken.

Read the next sentence or two of the RFC you're citing:

   Because the TCP SYN packet sets the ECN-Echo and CWR flags to
   indicate ECN-capability, while the SYN-ACK packet sets only the ECN-
   Echo flag, the sending TCP correctly interprets a receiver's
   reflection of its own flags in the Reserved field as an indication
   that the receiver is not ECN-capable.  The sending TCP is not mislead
   by a faulty TCP implementation sending a SYN-ACK packet that simply
   reflects the Reserved field of the incoming SYN packet.

Now consider the breakage if ECN had defined the bits such that seeing
both ECN-Echo and CWR on a SYN+ACK was interpreted as "the other
end is ECN-aware", when in fact the other end was clueless.

That's why echoing back the bits is faulty - if anybody ever allocates the
bits for something, you may be agreeing to do something you didn't intend to.

It's the packet-level equivalent of mumbling "Yeah sure, whatever." in response
to a question.

pgpHc7v0dmvYV.pgp
Description: PGP signature