[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKEv2 traffic selector subsetting.
This mail is not exactly about traffic selector subsetting, but it's
related to traffic selectors very much, so I didn't want to start a
new thread.
I've been thinking about Phase 1 and Phase 2 exchanges in IKEv2 and it looks
that IKE negotiation might be simplified for traffic selectors and number of
IKE messages to complete IKE negotiation between the initiator and responder.
The IKE negotiation as it stands in IKEv2 document now is following -
Phase 1 exchange
Initiator Responder
----------- -----------
HDR, SA, KE, Ni [,CERTREQ] -->
<-- HDR, SA, KE, Nr [,CERTREQ]
HDR*, ID, AUTH, [CERT,]
SA, TSi, TSr -->
<-- HDR*, ID, AUTH, [CERT,]
SA, TSi, TSr
then
The CREATE_CHILD_SA exchange (Phase 2):
Initiator Responder
----------- -----------
HDR*, SA, Ni, [KEi,]
TSi, TSr -->
<-- HDR*, SA, Nr, [KEr,]
TSi, TSr
I think instead of having two phases we might be able to achive the same
traffic selections by reducing the IKE negotiation to only one exchange -
Phase 1 exchange
Initiator Responder
----------- -----------
HDR, SA, KE, Ni [,CERTREQ] -->
<-- HDR, SA, KE, Nr [,CERTREQ]
HDR*, ID, AUTH, [CERT,]
[KEi,]
SA, TSi, TSr
[SA0, TSi0, TSr0,]
[SA1, TSi1, TSr1, ...] -->
<-- HDR*, ID, AUTH, [CERT,]
[KEr,]
SA, TSi, TSr
[SA0, TSi0, TSr0,]
[SA1, TSi1, TSr1, ...]
So, the intiator will propose all rules for traffic selectors.
The key derivation will not change. So, Phase 2 is not required
in this case. I know that the second messages are a bit overloaded,
but there is no duplication of traffic selectors in Phase 1 and Phase 2
and number of messages (4) is minimal. Still, the initiator/responder can use
CREATE_CHILD_SA exchange for rekeying. We can also add extra nonces in
the second messages if we want.
I might have missed something here, but I thought it would be useful to
write down this idea.
Other idea is to move initiator's [,CERTREQ] payload to initiator's second
message since responder's certificate is sent in responder's second message.
For developers it would be easier to implement the latter, otherwise
the responder would have to keep a state between initiator's first
message and responder's second message. It's not a big deal, the developers
will adapt, but it would be nice to get rid of the [,CERTREQ] state for the
responder.
Thanks,
Yuri Poeluev
Andrew Krywaniuk wrote:
>
> > > ...If you
> > > wish to avoid sending traffic that will be filtered out by
> > the peer then
> > > that would be best accomplished by an IPSP protocol.
> >
> > I.e., "by some hypothetical protocol yet to be defined".
> >
> > It's better to solve the problem than to pretend that someone
> > somehow will
> > deliver a solution when required. IKE has demonstrated that simple
> > solutions are adequate for many purposes. Deliberately excluding this
> > from son-of-IKE may be ideologically preferable but makes no
> > sense as a
> > matter of practical engineering.
>
> Being idealistic is something that I am rarely accused of. My point is that
> there is a difference between phase 2 traffic selectors (which represent an
> IP->identity binding), and policy (which can be complex, ordered, and
> asymmetric).
>
> The IP->id binding is something that needs to be agreed upon, because it
> verifies that the peers agree on which protected subnets are behind which
> gateway (or which user is logged into the remote computer). The bindings
> are
> relatively static and they could be obtained from trusted sources like a
> configuration file or a DNS record.
>
> The policy rules, on the other hand, are basically a re-implementation of
> firewalling. They don't need to be negotiated; they simply need to be
> enforced at each end. The fact that we negotiated an SA from A to B doesn't
> mean that I'm going to accept all UDP traffic to port 17 at 5:15 am on
> odd-numbered Tuesdays. The policy can change at any time and it need not be
> shared with the peer ahead of time.
>
> The bindings need to be agreed upon, whereas the two policies are ukases
> (which should be merged independently at each side); this is the key
> distinction between them. In IKEv1, the responder couldn't change the
> traffic selectors so they had to be preshared (this is inappropriate for
> policy). In IKEv2, the responder can narrow the traffic selectors but there
> are still potential issues (like what happens if the responder's narrow
> selectors don't include the packet that triggered the negotiation).
>
> The problem stems from the attempt to merge the bindings and the traffic
> selectors. The bindings are essential for security, whereas the policy is
> merely an optimization which allows you to avoid forwarding packets that
> the
> peer has informed you he intends to drop.
>
> Although I said that traffic filtering would be best accomplished by an
> IPSP
> protocol, I don't personally care whether that protocol is run as a
> separate
> negotiation stage or tacked onto IKE (although the complexity-Nazis may
> take
> issue with that). My main comment is that it would be better to have a
> separate policy payload rather than overloading to traffic selectors to do
> two different things.
>
> I suppose if you wanted to, you could use a second set of traffic selectors
> in the quick mode to express policy, but I don't think that's a very good
> idea. The traffic selectors in IKE don't do a very good job of expressing
> every useful policy. Having a policy payload allows you to use an SA for
> multiple non-adjacent traffic selectors. Plus, you could dynamically
> add/delete selectors or conditions to an SA.
>
> Andrew
> -------------------------------------------
> There are no rules, only regulations. Luckily,
> history has shown that with time, hard work,
> and lots of love, anyone can be a technocrat.