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

Re: Phase 1 Re-keying Implementation Identification



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim Jenkins wrote:
> 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.

The first thought that comes to mind WRT continuous channel is what
happens with PFS?  If I intentionally tear down my P1 immediately
after negotiating my P2 due to PFS, I would now need to make sure a
new P1 gets negotiated prior to doing that, thus creating a
potentially lengthy delay before PFS actually takes effect.  Use of
PFS without correcting for this would make the peers unable to
communicate because the P2 SA would get nuked when the P1 SA gets
nuked.

> 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.

Isn't it about time we all acknowledged that IKE without Delete
notifications has serious rekeying problems and made these a MUST
anyway (as Acknowledged Notifications in the new IKE draft)?  Your
draft is like a proof for this.  If rekeying worked reliably without
these things we wouldn't need your draft as much as we do.

> 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?

If we make Acknowledged Notifications a requirement, I think the need
for continuous channel mode goes away, correct?  That seems like a
cleaner solution than creating a permanent hack Vendor ID payload
shared by all the vendors who "do things right".

We currently try our best to keep a "continuous channel" open, but if
through PFS or some other reason the other side deletes the P1, we
don't care.  We'll just negotiate a new one if we need it... and if
we can.  The only reasons we would ever need to negotiate a new P1 if
it had been deleted are (1) the P2 needs to be rekeyed, (2) the user
told us to rekey, (3) the user told us to kill the P2 and we want to
send a protected Delete.

For (1), if we can't make a new P1, we might as well kill the P2
anyway.  For (2), again if we can't make a P1 we might as well kill
the P2.  For (3), we could send an unauthenticated Delete -- not
ideal but if the devices have lost the ability to negotiate a Phase 1
it really doesn't seem critical.

> 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

- -- 

Will Price, Architect/Sr. Mgr., PGP Client Products
Total Network Security Division
Network Associates, Inc.
Direct  (408)346-5906
<pgpfone://cast.cyphers.net>


-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2

iQA/AwUBODGcPqy7FkvPc+xMEQKKvgCg9PE7J8qOeyeeAlAy35XKKWYKd+IAoIW1
BncBN9cR75o6WC3sX6BqMYk0
=G6Ie
-----END PGP SIGNATURE-----


References: