[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: