[Openswan dev] IKEv2 Traffic Selector narrowing questions

[Paul Wouters]

I have a few design questions on IKEv2 Traffic Selector narrowing

Specifically, regarding http://tools.ietf.org/html/rfc5996#section-2.9


1) The responder can propose a narrowed proposal of the initiator's request

a) What should the initiator do with packets that suddenly fall outside
    the new narrowed proposal? drop them? send them in plain text?
    (in other words, I'm trying to define a "local policy")

b) If the initiator agrees to the narrowed proposal, how on earth should it
    inform the user? Should the user know? (I think so, see a)

2) If the initiator triggers the IKE on a packet, then it should send
    that packet's source/destination as the first TSi/TSr, and the complete
    tunnel proposal as the second TSi/TSr. The responder gets to pick which
    traffic selector to use.

a) If the packet is 10.a.b.c to 10.d.e.f, and the policy on the initiator
    is 10.a.b.0/24 to 10/8, then why would it ever want to give the
    responder an option to narrow it down to what will eventually become
    a cascade of /32 <-> /32 Child SA's ?

b) If the packet is triggered on some opportunistic encryption policy,
    eg based on IPSECKEY, then the initiator can reasonably only propose
    a /32 to /32 policy (and maybe not allow gateway != endpoint), in
    effect already (and only) creating the packet src/dst as the only
    valid traffic selector.

3) The first (so implicating important) use case mentioned is:

    "This could happen when the configurations of the two endpoints
     are being updated but only one end has received the new
    information."

This seems like a real odd corner case. It reads me as "if we changed
the lock on the front door, try this key on the back door". My guess is
this is to support clients that were configured for say 10.0.0.0/8, to be
narrowed down more specifically, say 10.0.0.0/24 but since the initiator
is setting up the tunnel, it might have a need to reach 10.1.2.3/32. Now
with that "this packet triggered this IKE request" it could signal this,
and the responder could figure out its narrowing won't work for this client.
But this just seems a bad patch to a bad starting situation.

4) The next use case is:

    "It also allows for intentionally different configurations, as when one
     end is configured to tunnel all addresses and depends on the other end
     to have the up-to-date list."

This really smells like creating 0/0 <-> 0/0 tunnels, or as some vendors
call it, "routing based VPNs". I guess the use case is to setup all
clients with 0/0 <-> 0/0 and then reconfiguring/narrowing down on the
head-end what you really want tunneled. This would then depend on the
head-ends changing address range use. I can see the use case here.
You want split-tunnel and tell the client which parts to send. It is
something you want the client to agree to, though if it is already agreeing
to send you everything, I guess it already decided to put all trust in
the remote peer. But I believe this case is already covered via XAUTH with
ModeCFG type scenarios?

In other words, I find it really hard to come up with valid scenario's
of narrowing down policy as per RFC 5669 Section 2.9. And as a result,
I'm not sure how (and if) I should implement this part of the RFC.

Am I wrong in that allowing narrowing on the initiator or responder is
not something that should be allowed per-default, but only after being
explicitely told to allow it? Or am I missing a (secure!) use case when
not allowing narrowing of traffic selectors per default?

Paul