Re: [Tcpcrypt] New version of the charter text

[Joe Touch <[e-mail]>]

On 4/30/2014 6:51 AM, Tero Kivinen wrote:
> Joe Touch writes:
>>> 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.
>
> The timer to delete the old SA after the new is up (and we are seeing
> traffic on the new SA) are usually in order of 5-10 seconds or
> something like that, just to take care of the old packets.
>
> If the out-of-order packet is delayed by more than 5-10 seconds before
> it finally arrive to the other peer, it might already be dropped by
> the replay window checks (depending how big window you are using), and
> it would most likely already been considered as being lost by the
> upper layers.

But in that case the replay prevention would be dropping packets that 
could be valid (i.e., they're only replayed if the particular byte range 
overlaps, but merely if it's "earlier than expected".

...
> I.e. in normal case there is no lost packets.

You just said that replay would drop them - that's a drop TCP would see 
too.

Joe