[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ipsec error protocol

Markus,

>Derek Atkins <warlord@mit.edu> writes:
>>  "sankar ramamoorthi" <sankar@nexsi.com> writes:
>>  > If the receiver window is limited to 2**32 bits, then it means
>>  > at 10Gig/sec speeds  the receiver has to rekey after 400 seconds.
>>  No, the receiver 'replay' window is limited to 2^32 bits.  This means
>>  you can only accept packets within this 400-second window, so if a
>>  packet gets delayed by 400 seconds it will be dropped (because it is
>>  now outside this window).  You still only need to rekey every 2^64,
>>  which is 400*2^32 seconds, which is a LARGE number.
>
>Yes.. But.. (pointing out something not addressed in the discussion before,
>although I do not think it's big issue at least currently)
>
>>  > Is that acceptable?
>>  I think the limitation of dropping packets delayed by 400s may be
>>  acceptible, provided we're not talking about interplanetary internets.
>>  I certainly believe that the 400*2^32 is sufficiently large.
>
>Obviously, this is the case. However, what if the route happens to be down
>say, 5 minutes? The window _may_ have moved by roughly 0.8*2^32, and the
>receiver cannot make decent guesstimates about real sequence number.  Okay,
>that's the trivial case (two guesses)..
>
>Assuming that the draffic is unidirectional (IPsec SA for say, multimedia
>or whatever traffic)..
>
>How about downtime of hour in SA with lifetime of say, ten hours? 10
>guesses? New SA?
>
>Downtime of two days in SA with lifetime of year? 500 guesses? New SA?
>
>The so-far-simple logic gets suddenly somewhat more complex. I'm not sure
>if this is an issue, though, because typically first guess would be always
>correct and it'd require (at least with current communication speeds) N
>years of dead link for guessing-delay to actually matter.

You raise an interesting issue. The second example I think is not 
credible, i.e., an SA lifetime of a year. But, in the context of a 
unidirectional traffic flow, a serious outage might be long enough at 
very high speeds to cause the counter to wrap more than once, 
creating ambiguity at the receiver and a loss of synch.  If we adopt 
any of the keep alive (or is that make dead?) proposals, we have a 
chance to detect and address this problem, but we do need to think 
about this and have a good answer.

Steve
Follow-Ups: References: