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

Phase 1 Re-keying Implementation Identification

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
Follow-Ups: