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

Re: Phase 1 KB lifetime

>>>>> "Shawn" == Shawn Mamros <smamros@nortelnetworks.com> writes:

 Dan> It is _never_ a good idea to just enforce a lifetime without
 Dan> telling the peer (assuming, as we all remember from 3rd grade,
 Dan> makes an ass out of you and me).
 >>  I quite disagree.  The protocol works if someone rekeys at a time
 >> of their choosing for reasons of their choosing.  Or at least it
 >> appears to; if it doesn't work for that case then the protocol is
 >> defective and needs to be repaired.
 >> 
 >> Therefore, it isn't actually necessary to tell the peer about
 >> lifetimes you enforce.  I still don't understand why that stuff is
 >> in the protocol at all.

 Shawn> Consider the following scenario:

 Shawn> A Quick Mode initiator (QMi) sends a proposal for IPsec SAs
 Shawn> with a lifetime of one hour.  The Quick Mode responder (QMr)
 Shawn> decides it wants to use a lifetime of only half an hour
 Shawn> instead, but does not use the RESPONDER-LIFETIME Notify
 Shawn> message to inform QMi that it is doing so.

 Shawn> Half an hour elapses.  QMr deletes the IPsec SAs.  QMr sends a
 Shawn> Delete to QMi, but the Delete gets lost somewhere along the
 Shawn> way.  (Even if we have an acknowledged Informational exchange,
 Shawn> Deletes can still get lost; QMr is eventually going to have to
 Shawn> give up and delete the SAs anyways, right?)

Well, yes, the lack of acknowledged delete is a known bug that's being 
fixed.

 Shawn> QMr has no further traffic requiring an IPsec SA to QMi, so
 Shawn> doesn't bother proposing one.  QMi, however, does have traffic
 Shawn> and, believing there's still valid IPsec SAs, uses them.  QMr,
 Shawn> seeing this IPsec traffic for IPsec SAs it doesn't have, drops
 Shawn> the packets.  This continues on for another half hour, until
 Shawn> QMi finally deletes the IPsec SAs and negotiates new ones, and
 Shawn> the cycle starts again...

Right.

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.

	paul
References: