Re: [Tcpcrypt] New version of the charter text

[Tero Kivinen <[e-mail]>]

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.

Note, also that after the rekey has been finished, and we have see
packets on the new SA, and when we start deleting the old SA, we still
accept packets on the old SA, because the delete is two way. I.e. we
send delete notification saying we are not going to send data our
outgoing old SA, and only when we get response back from the other
where it tells he will not be sending data on his old outgoing SA (i.e
our incoming SA), we actually delete the inbound SA.

I.e. in normal case there is no lost packets. 
-- 
[e-mail]