[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Phase 1 Re-keying Implementation Identification
Slava Kavsan wrote:
>
> Wouldn't be simpler to eliminate "continious" model instead of creating
> additional protocol extensions to support it.
> What are advantages of "continious" model vs. "dangling"?
>
The continuous model provides a 'session' metaphor that is appropriate
for remote access accounting and billing. P2 SA deletion upon P1 termination
also garbage collects any open SA's when a remote access user 'logs out'
of a VPN. This releases resources on the security gateway and closes
P2 SA's that would otherwise be used to send data to a client who is no
longer connected.
(I recognize DELETE's can be issued for each P2 SA but I believe that
any dangling P2 SA's should be deleted when a remote access user's P1
SA is terminated).
-Ben McCann
> Tim Jenkins wrote:
>
> > Greetings,
> >
> > At the 46th IETF last week, I again presented the re-keying document. In
> > that presentation and in the re-keying document, I described two methods of
> > phase 1 re-keying.
> >
> > One of these I called "phase 2 SA dangling". In this method, an
> > implementation does not necessarily keep any valid phase 1 SAs alive while
> > there are phased 2 SAs between it and another peer. In other words, the
> > phase 2 SAs may "dangle" without the existence of a control channel.
> >
> > The other method is what I called the "continuous channel" method. In this
> > method, an implementation always keeps at least one phase 1 SA up between
> > itself and a peer when there are any phase 2 SAs up between them. If, for
> > any reason, there are no phase 1 SAs between the peers, all phase 2 SAs
> > would be torn down as well.
> >
> > However, this leads to a potential interoperability issue between the two
> > methods, since a continuous channel implementation would delete phase 2 SAs
> > when a dangling phase 2 SA peer deletes the phase 1 SA between them.
> >
> > To correct this, a continuous channel implementation could choose to not
> > delete phase 2 SAs when it received a delete notification for the only phase
> > 1 SA that exists.
> >
> > However, this leads to problems if the peer is also a continuous channel
> > model. Note that this can occur since delete notifications for all SAs are
> > both optional and send without acknowledgement over UDP.
> >
> > So, I asked if there was interest in allowing vendors to be able to
> > determine if the peer is also a continuous channel model.
> >
> > Obviously, if a vendor sends a vendor ID payload, the implementation can
> > determine that it is talking to itself, and thus determine which phase 1
> > re-keying model it uses.
> >
> > So: Is there any interest in this? How many vendors are using the continuous
> > channel model?
> >
> > Please note that this has absolutely no effect on dangling phase 2 SA
> > implementations. It has already been stated that continuous channel model
> > implementation should be dangling phase 2 SA implementation aware if they
> > cannot determine the nature of the peer implementation.
> >
> > If there is, what method would be suggested?
> >
> > (One potential method is the exchange of a specific vendor ID, but this goes
> > against the intent of the vendor ID payload. Unfortunately, there doesn't
> > seem to be a feature negotiation capability in IKE.)
> >
> > Thanks,
> >
> > Tim
> >
> > ---
> > Tim Jenkins TimeStep Corporation
> > tjenkins@timestep.com http://www.timestep.com
> > (613) 599-3610 x4304 Fax: (613) 599-3617
>
> --
> Bronislav Kavsan
> IRE Secure Solutions, Inc.
> 100 Conifer Hill Drive Suite 513
> Danvers, MA 01923
> voice: 978-539-4816
> http://www.ire.com
--
Ben McCann Indus River Networks
31 Nagog Park
Acton, MA, 01720
email: bmccann@indusriver.com web: www.indusriver.com
phone: (978) 266-8140 fax: (978) 266-8111
Follow-Ups:
References: