[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ipsec error protocol
Frédéric,
>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.
Not sure I agree with the principle you state above, but we can let
it ride for now.
>
>(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).
I have to admit that, at this point in the exchange (and trying to
deal with threads o other lists at the same time) that I'm lost. What
problem are we trying to solve? Is it the loss of state at the other
IPsec device, or the parallel crypto chip and sequence number problem
that Dan raised?
Steve
Follow-Ups:
References: