[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
paul
References: