[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Phase 1 Re-keying Implementation Identification
I don't believe outside-in phase 1's are addressed in the current RSIP
document. If there is an outside phase 1 coming to the gateway, there is
just no way to know to witch inner computer this phase 1 should be sent to.
(I note that the first phase 1 packet will have the outside initiator cookie
and zeros in the responder cookie, routing based on cookies is not
possible).
Systems like "continuous channel model" cause RSIP is have more problems
since they cause more outside-in phase 1's to occur. The only way RSIP will
work fine with IPsec is to have one inside-out phase 1 that is kept open at
all times, and require IKE vendors to properly re-key on the right phase 1.
I don't see how the authentication method (Pre-shared key, certs...) can
help in demultiplexing and outside-in phase 1 or make a outside machine
select the right phase 1 for a new phase 2.
Ylian Saint-Hilaire
Intel Communication Architecture Labs
-----Original Message-----
From: Tim Jenkins [mailto:tjenkins@TimeStep.com]
Sent: Tuesday, November 16, 1999 10:34 AM
To: wprice@cyphers.net
Cc: ipsec@lists.tislabs.com
Subject: RE: Phase 1 Re-keying Implementation Identification
comments below.
---
Tim Jenkins TimeStep Corporation
tjenkins@timestep.com http://www.timestep.com
(613) 599-3610 x4304 Fax: (613) 599-3617
> -----Original Message-----
> From: Will Price [mailto:wprice@cyphers.net]
> Sent: November 16, 1999 1:03 PM
> To: Tim Jenkins
> Cc: ipsec@lists.tislabs.com
> Subject: 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.
> How to do PFS with the continuous channel model is described in the
> document. Basically, you create two phase 1 SAs as you mentioned above,
but
> you use the newest one to do phase 2 negotiations and immediately delete
it.
> The first and oldest remains as the channel to send notifications and
> deletes and heart beats and keep-alives and whatever else you need to send
> in the channel.
>
> > 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.
Perhaps not as much. But it doesn't change the fact that there can be
distinct advantages in keeping the channel available at all times.
Consider premature tear down of the entire channel. The acknowledged delete
can't be used if you can't get the control channel back up.
Then, you've got to count on (still proprietary) heart beats to determine
that the peer has died to clean up. And until that happens you've got SAs at
one end that might be spewing out encryted useless data.
The clean-up is messy, and it doesn't need to be.
>
> > 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".
It doesn't go away. One of the conditions that makes it more useful goes
away (dropped phase 2 delete before phase 1 delete). See above as well.
Also, you appear to be making an issue about how we do feature extension
with IKE. That's a separate issue. Right now, I don't know how it's done,
and I've already said I don't like using the vendor ID for that. But I don't
know how else to do it without being proprietary.
So there's two questions:
1) Are other interested in recognizing that the peer is contuous channel?
If the answer to 1 is yes, then:
2) How should that be done?
>
> 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.
This is the termination case I described above. If you don't think it's
critical, that's fine. Personally, I think it is important and I think that
the people who have to use our products will think it's important. Some of
them want to see alarms when they get encrypted packets for SAs that no
longer exist. Implementations that don't clean up well will not be as
popular with these customers.
>From the sounds of it, your implementation is a continuous channel model
that is dangling phase 2 SA aware. That's exactly what the draft recommends
in the absence of knowledge about the peer.
So, if you don't think there's an advantage knowing that the peer is also a
continuous channel implementation, just say no to question 1. For now, I'll
assume you have.