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

Re: Question about mis-match SA lifetimes

  A delete message is not delivered reliably and to depend on it is
foolhardy. Tim Jenkins has proposed a reliable delete message and that would 
work but we don't have it yet. Also, if RFC2409 had a RESPONDER-LIFETIME
type of message ala RFC2407 that's work but it doesn't--yet. So, why care 
about how long the peer retains the SA and key I guess is the question.

  I've heard several people mention that a solution to the "failover"
problem-- where the box crashes, reboots, loses all state, and silently
drops incoming IPSec packets leaving the remote peer to try and figure
out why-- is to save all SA information, including keys, on a disk somewhere. 
(Our product doesn't have a disk so I don't have that option but some people
do). Not knowing whether a peer is doing this I can only assume that it is.
So if I have a lifetime configured for 1 hour and the peer offers 12 hours, 
or worse doesn't even offer a lifetime, my assumption is that this key is
sitting somewhere for 12 hours, or worse as long as the peer wants it to.
Since this key can be used to generate lots and lots of IPSec SAs that might
not be a good thing.

  Even disregarding the issue of storing the key in a file, I just get a
warm fuzzy knowing that the peer has acknowledged that the key will be
destroyed in accordance with my local policy.

  So maybe I'm paranoid (or maybe I'm ignorantly proscribing some security
benefit where there is none). But there's also a knob to set the lifetime and
if someone takes an affirmative step to actually set the lifetime on my
box I assume he did it for a reason and I honor the policy configuration.
Is there a similar knob on your product? 

  Dan.

On Wed, 03 Feb 1999 15:04:40 EST you wrote
> >>>>> "Mason," == Mason, David <David_Mason@nai.com> writes:
> 
>  Mason,> If the peer has an IKE SA lifetime configuration of 2 hours,
>  Mason,> and locally you have an IKE SA lifetime configuration of 1
>  Mason,> hour, then wouldn't it be more advantageous to allow the
>  Mason,> phase 1 negotiation to proceed and then just send a delete
>  Mason,> notification for the IKE SA cookie after 1 hour, right before
>  Mason,> you expire your IKE SA, then to just always fail the
>  Mason,> negotiation?
> 
> I would have thought the same.  In fact, it's not clear to me why the
> lifetime value needs to be mentioned in the protocol at all.  If I
> think the SA has lived long enough, I can rekey.  Whether the other
> side is more tolerant seems irrelevant.
> 
> To put it differently: consider a hypothetical protocol that was just
> like IKE except that it doesn't exchange this information.  What bad
> properties, if any, would such a protocol have?
> 
> 	paul
Follow-Ups: References: