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

Re: Phase 1 Re-keying Implementation Identification

I have a question on "continious" model re-keying:

If P1 lifetime is set to 7 min and P2 lifetime is set to 5 min - what do you do when
P1 re-keyes after 7 min - do you re-key P2 after 5+2 minutes also?

(Of course, in the "dangling" model - both phases re-key on their own schedule
independent from each other).

Ben McCann wrote:

> 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

--
Bronislav Kavsan
IRE Secure Solutions, Inc.
100 Conifer Hill Drive  Suite 513
Danvers, MA  01923
voice: 978-539-4816
http://www.ire.com
References: