Subject: Re: [tcpm] (ref. RFC 7323) Increase of shift count from 14 to 15.
From: Joe Touch <[email-masked]>
To: David Borman <[email-masked]>, Yoshifumi Nishida <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Sanjeev Ranot <[email-masked]>
Date: Tue, 6 Sep 2016 11:14:27 -0700
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>

Hi, all,

On 9/6/2016 7:24 AM, David Borman wrote:
> The biggest problem with changing the shift count midstream is that TCP has no reliable mechanism for doing option negotiation midstream.
Agreed.

>   The only packets that are reliably delivered are packets that contain data or have the SYN or FIN bit set.

AFAICT, this isn't strictly true.

The data and connection state are reliably "delivered" (or
synchronized), but not the packets per se. Options in those packets
aren't reliably delivered any more than any other packet, esp. because
TCP has no strict requirement that the options of retransmitted segments
don't vary. TCP gets around this by confirming the options exchanged
during the SYN, but no other time during the connection.

You *can* build your own handshake on top of TCP, but it's complicated.
We did this for TCP-AO to support key rollover - the sender offers a new
key, which cannot be used until the receiver confirms it. The same
happens in the opposite direction. As Dave pointed out, this takes up
option space (one extra byte in AO, in addition to the confirmation
being overloaded with the current keyID) and requires that the option
"protocol" consider how to handle handshake failure, packet reordering, etc.

Joe