[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IKEv2 traffic selector subsetting.
> > ...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.
References: