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

Re: Phase 1 Re-keying Implementation Identification



Scott,
   While the IKE SA is indeed a seperate entity from the IPSec or
protocol SA, the IKE SA is used to authenticate/authorize the 
IPSec/Protocol SA.  If it is important to "your" implementation to 
have precise boundries when authentication/authorization is removed 
(given a peer who may not cooperate), then dangling Phase 2's should 
be restricted.

This is a similar issue to allowing phase 2 lifetimes to extend
beyond the validity period of the certificate that authenticated
the phase 1 used to negotiate the phase 2.

It is impossible be absolutely precise in revocation of authorization.
If in "your" application it is "close enough" to revoke authorization 
within the limits of a phase 2 lifetime, there is no need expend the 
extra development effort required to restrict dangling phase 2's.

Regards,
Michael Carney
 

> I tend to agree with Tero. I've been following this discussion for
> around a year now, and have always had a hard time understanding why
> "dangling SAs" are such an issue. I have come to the conclusion that it
> has something to do with the architectural viewpoint one takes with
> respect to isakmp. Below is a diagram from RFC2408:

<Fine ascii art deleted >

> ISAKMP is clearly an application protocol which provides services to the
> kernel, and the notion of binding ISAKMP constructs (sessions, SAs, or
> what have you) to kernel constructs (SAs, in this case), really rubs me
> the wrong way. The IKE SAs and the protocol SAs (despite the unfortunate
> fact that they share a name) are distinctly different constructs in
> distinctly different architectural layers. It seems incorrect to assert
> that deletion of an application layer session should justify deletion of
> a kernel-level session. 
> 
> I understand the keep-alive issue in the remote access scenario, but I
> don't think this justifies cutting across the architectural layers here
> in the name of a quick fix. IKE SAs really have no binding to the
> protocol SAs they negotiate once they've been instantiated, and assuming
> that it is okay to delete a protocol SA just because the IKE session
> used to instantiate it goes away seems incorrect to me.
> 
> Scott




Follow-Ups: References: