Subject: Re: [Tcpcrypt] New version of the charter text

From: Tero Kivinen <[email-masked]>
Date: Mon, 5 May 2014 16:30:43 +0300

Joe Touch writes:
> > 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".

That is not related to the rekey. For rekey each SA have separate
replay windows, so that is not on issue there.

I meant that if you have situation where the network commonly delays
packets for 5 seconds and send them all out of order then that will
quite often cause IPsec replay window to drop the packets which are
too old. The IPsec replay window size is normally something like
32-128 packets so after you the peer has received that many newer
packets it will drop the old packet when it arrives.

> > 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.

The normal case we were talking about is a rekey case, and rekey
normally do not loose any packets. 

Replay window will drop packets in general (i.e. cases not related to
rekey) if packets get too much out of order. Thats why IPsec
architecture asks you to create separate SAs for cases where packets
might get delayed different amounts. I.e. one IPsec SA per traffic
class if you are doing class based QoS etc. IPsec rekey does not cause
packets to be lost.

Also TCP usually will already do actions when it sees that one packet
has not been received for 5 seconds and there has been other newer
packets coming in all the time (i.e. do SACK and that will cause the
other end to retransmit the packet when it receives that information,
and if both of the packets do arrive to the other end then later one
of them is simply dropped, as TCP has already received the earlier
one).

Anyways I think we are getting quite far away from the charter text. 
-- 
[email-masked]