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

RE: Phase 1 KB lifetime



>From: Paul Koning [pkoning@xedia.com]
>Sent: Wednesday, January 19, 2000 8:57 AM
>To: smamros@nortelnetworks.com
>Cc: ipsec@lists.tislabs.com
>Subject: Re: Phase 1 KB lifetime
>
>>>>>> "Shawn" == Shawn Mamros <smamros@nortelnetworks.com> writes:
>
> Shawn> At 11:22 AM 1/19/2000 -0500, Paul Koning wrote:
> >> Now consider a similar situation with byte count limits rather
> >> than time limits.  And assume that the network is very lossy
> >> (because otherwise acked deletes work).  In that case, the
> >> sender's byte count is substantially greater than the receiver's
> >> byte count.  So the sender will rekey much sooner than the
> >> receiver expects.
> >> 
> >> You get the same problem then, and responder-lifetime isn't any
> >> help.
>
> Shawn> But in that case, the sender *does* rekey.  Rekeying sooner
> Shawn> than one expects shouldn't cause a problem, should it? 
>
>That's what I argued.
>
>Perhaps there's a difference in assumptions: I assumed that expiration 
>causes rekeying, while you assumed it causes only SA deletion, not (by 
>itself) rekeying.  That makes a bit of difference.
>
>Then again, it doesn't completely affect the answer, because if the
>traffic stops at the right place you might still end up not rekeying
>if you only rekey on traffic occuring *after* expiration.
>Furthermore, if the network is so messed up that acknowledged deletes
>don't work, rekeying might not either.
>
>Bottom line is that IKE/IPSEC isn't fully self-stabilizing; it doesn't 
>recover (in short time) from a situation where one side has SAs and
>the other does not -- however that situation may have come about.
>
>There's a conflict between self-stabilization and robustness in the
>face of DOS attack, unfortunately.  That shows up in Dan's summary:
>
>>  * What do I do if I get IPSec packets for SAs which I don't currently
have?
>>    Should I send unproteted notifies or begin an IKE exchange with that
person
>>    or do nothing?
>>
>> This is implementation specific.
>
>The safest answer is "do nothing" but that is also exactly the design
>choice for non-self-stabilitization.

Some questions,

Are you saying that a design choice for non-self-stabilization is
acceptable? Since as you mention before that the situation that
one side has SA and another side does can come about in many ways,
isn't self-stabilization all the more important?

Why is "do nothing" a safe choice for the receiver of the bad IPSec packet
(IPSec packet without SA)? How does sending a 'invalid spi' notify 
to the sender of the ipsec packet affect the safety of the receiver? 
Isn't sending a notify better than doing nothing? 

>From the sender (of the stale ipsec packet) point of view it may
be useful to receive a notify immediately  - if it can be authenticated
in some way than it can even act on it immediately.

>
>	paul

Thanks,

-- sankar --


Follow-Ups: