Re: [Tcpcrypt] New version of the charter text

[Joe Touch <[e-mail]>]

On 4/28/2014 5:30 AM, Tero Kivinen wrote:
> John-Mark Gurney writes:
>> The goal is to make it very easy for everyone to deploy...  Configuring
>> IPSEC is a pain, and as Joe mentions, most implementations don't handle
>> key roll over properly (even though apparently, you're allowed to keep
>> both the old key and the new key around for the transition period to
>> handle this case)...
>
> Of course there can be buggy IPsec implementations which do not follow
> the rules set in the RFCs and which loose some packets when doing
> rekeying, but same applies to any protocol.
>
> The current IPsec specifications (IKEv2, RFC5996) do specify how rekey
> happens and it is specified so that no packets are lost: i.e. first
> create new Child SA proactively, i.e. before the old Child SA expires;
> then wait for traffic to move to this new SA (i.e. when you see
> packets on new Child SA, you know that other end has installed it);
> and only then remove old Child SA.

You can't ensure that no packets are lost that way. Once you transition 
to a new SA - even if you coordinate that handoff - there may be 
out-of-order packets that arrive after that coordination.

Those packets would be dropped, and presumably TCP would retransmit them 
using the new SA, but the receiver would still see a gap in received 
packets that might affect its congestion control.

TCP is the only one who can know when there is no outstanding gap after 
a key change, and thus when it can remove an old key without impact to 
its congestion control.

Joe