[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ipsec error protocol
Stephen Kent wrote:
>
> Frédéric,
>
> I'm very uncomfortable moving toward ACKs in ESP. We try in IPsec to mimic IP functionality as much as possible, and IP does not ACK packets.
I agree but we also created a tunneling protocol... what does not make much sense in transport mode makes a lot in tunnel mode.
(but I am with you, do not shoot)
> Note that our anti-replay strategy allows for out of order arrival precisely because IP allows for it (even though we do impose some limits here).
Again, I can only agree with you. The only goal of the ack is to avoid a "large" gap between the sender and the receiver. In filigrane, read large as "configurable" gap in the sense of
. can be turned off
. gap of configurable size (in # of packets or amount of data).
Obviously, no retransmission of any sort nor any expectation in the order of arrival (replay detection stays as it is): we just ack the biggest packet ID received (piggy backed if possible).
More (or actually less), my very restricted goal is to make sure the other IPSec peer still has all its marbles. NOT assuring *some* packets were not lost in the path (well if that has that side effect, good, but we do not want to explicitely cover that; we let it to TCP).
Actually, I am not too much in favor of changing ESP either: I believe it would be better to design an acknowledged tunneling protocol (or change an existing one like GRE or L2TP) and make it "IPSec aware" within a given stack (i.e. when the tunnel lacks some acks, it tears itself down and takes its SA's with it).
>From the field, though, I can see that people are already so confused with a single tunnel... and we make them use tunnels in tunnels... and they screw their topology. I just thought it may be easier to embed the feature in IPSec (almost transparently) => would make IPSec more appealing.
Now, if you tell me that this is a Bad-Idea(tm)...
frederic
> Steve
Follow-Ups:
References: