Re: [tcpm] TCP Four-Way Handshake

[David Borman <[e-mail]>]

> On Oct 17, 2014, at 5:29 PM, Joe Touch <[e-mail]> wrote:
> 
> 
> 
> On 10/17/2014 11:43 AM, David Borman wrote:
>> All this really points out is that when there are incompatible options,
>> there should be a documented procedure for how to handle the case when
>> they are all negotiated. 
> 
> Currently:
> 	SYN indicates desired options
> 	SYN/ACK indicates subset of desired options
> 	ACK indicates final set negotiated
> 
> Right now, one side can easily avoid that by what it selects in its SYN.
> You're suggesting entirely different semantics for options that now need
> to be determined for all past and future options concurrently.
> 
> I don't think that's feasible.

You keep missing the point.  If an option isn’t both sent and received
in a packet with the SYN bit, it is not enabled.  So with the 3WHS it
doesn’t matter if there are additional options in the SYN-ACK, they will not be
enabled because they weren’t in the original SYN.  The fact that the SYN-ACK
is a subset of what was in the SYN *is only an optimization*.  The final ACK
has nothing to do with it, it’s only what is exchanged in the packets with
the SYN bit that matter.

Look at RFC1072, supported options were sent in any packet with the SYN
bit set, so the SYN-ACK would have WS even if the inbound SYN didn’t have
it.  I’m the one that pointed out because you had to both send and receive
the option to enable it, that sending the option in the SYN-ACK when it
wasn’t received in the SYN wasn’t useful, and that’s why RFC1323 added
that you only sent the options in the SYN-ACK if they were received in
the SYN.  But it was purely an optimization.  With the 3WHS, all TCP
implementations should ignore any options in the received SYN-ACK that
they didn’t send in the initial SYN.  If they don’t, they are broken.

With the 4WHS, the client has a second chance to enable additional options
with its SYN-ACK, provided they were received in the servers SYN-ACK.
		
	-David
> 
> Joe
> 
>