[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Dangling phase 2 SAs (was RE: issues from the bakeoff)
> -----Original Message-----
> From: Volpe, Victor [mailto:vvolpe@altiga.com]
> Sent: June 17, 1999 6:41 PM
> To: 'Scott G. Kelly'; Tim Jenkins
> Cc: ipsec@lists.tislabs.com
> Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff)
>
>
> Originally I was concerned about the security problems that
> the dangling
> Phase 2 SAs could pose, but I guess I agree that those issues
> are minimal if
> any. Let me raise my question to a more functional level so
> that I can make
> a decision on how to tweak our implementation.
>
> My assumption was that rekeying a Phase 1 SA meant that it was
> rekeyed/renegotiated with the peer. I assumed that most other
> implementations would behave the same way. When we rekey
> with ourselves, we
> negotiate a new Phase 1 SA before tearing down the old one.
> When the old
> one is deleted, the Phase 2 SAs stay up because they are
> transitioned to the
> new SA. They then rekey under the protection of the new
> Phase 1 SA. It
> seems like a lot of implementations interpreted Phase 1
> rekeying as "just
> drop the old SA". It will then be renegotiated as the result
> of a Phase 2
> rekey.
>
> Either way will work and either way can be implemented in a
> way that is
> interoperable and prevents data from being lost. I guess the
> 2 methods will
> also interoperate if it is clear to everyone that delete
> messages for Phase
> 1 SAs do not imply any action to the respective Phase 2 SAs.
>
> I wanted to get a feel for where people stood on this and it
> looks like
> orphan Phase 2 SAs should be supported to support the widest range of
> implementations.
>
> Tim, is this something that is worth putting in the rekeying draft?
This is already in the re-keying draft as I've been presenting: where
dangling phase 2 SAs is bad. However, either no one bothered to read it or
comment on it, or maybe no one understood it...
In any case, the original point you raised is valid. Unfortunately, I see,
once again, incompatibilities due to implementations re-keying differently.
Another case of too many ways to do it that aren't explicitly allowed or
dis-allowed.
As for the feel of things, well, it looks like your conclusion that support
for dangling SAs is going to be necessary for maximum interoperability.
I'm going to make another (futile) attempt to explain why I don't like
dangling SAs again, by responding to the latest set of questions.
Tim
>
> Victor
>