> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Paul Wouters > Sent: Sunday, February 12, 2012 4:54 PM > To: [email protected]; [email protected] > Cc: Paul Wouters > Subject: [IPsec] IKEv2 Traffic Selector narrowing questions > > > > 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")
If the initiators SPD says that a particular packet should be protected, it'd be the Wrong Thing to send it in the clear just because it fell outside of the proposal that the responder replied with. IMHO, the correct behavior you should do if you have a packet that the SPD says should be encrypted but you don't have any SAs that you can send it with, is to attempt to negotiate an SA that can handle the packet. This is true regardless of whether you have any existing SAs for other packets. And, if the peer refuses to negotiate an SA that accepts the packet, well, I don't see you have any alternative to dropping the packets (unless you can find an alternative route to the destination that doesn't involve the IPsec SPD). > > 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) Why would the user care? If you create new SAs on an as-needed basis, so that all the traffic is being encrypted, why would the user care if everything was handled by one SA, or a couple of SAs were used. Now, if the peer rejected the negotiation for some traffic the user was interested in, then yes you should inform him. However, this wouldn't appear to differ from the case that the peer rejected the SAs from the start. > > 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. Not quite. The responder responds with a proposal that is a subset of the union of the proposals that the initiator sent. This subset could be just one of the selectors that the initiator sent, but doesn't have to be. In the example you give in (a) below, the responder could also send a proposal 10.a.b.0/24 to 10.d.e.0/24. > > 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 ? Perhaps it's to avoid scenarios like "A can negotiate with B (because A's policy is a subset of B's), but B can't negotiate with A (because B proposes a proper superset of what A can accept)". After all, if A couldn't ask that the policy be narrowed, it would have to reject B's entire proposal, even if it could have handled the traffic we were actually interested in. In any case, as above, it is not meant to reduce to SAs that handle traffic source/dest'ed from single IP addresses. > > 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". Doesn't sound like that much of a corner case to me. It's more of "if the two sides has policy that doesn't quite agree, we'll let them agree to the parts of the policy they have in common". Or, are you of the opinion that the two sides should reject negotiations (and all traffic is dropped) until the policy resyncs? > 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". That's certainly part of it, but I don't believe that's the only case. > 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? The above can also be useful when ModeCFG isn't being used. > > 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? Are you wrong in suggesting that the RFC should be changed? That, of course, is a matter of opinion. If you ask my opinion, well, IKE always had the provision of the initiator proposing multiple encryption methods (3DES, AES) and the responder selecting a subset. How is this fundamentally different from the initiator proposing selectors, and the responder selecting a subset? If the former is useful, why isn't the latter? In any case, why do you think that there is a security problem with allowing the responder to narrow the selectors? If the responder narrows the selectors (and if the initiator makes sure that this narrowing really is a subset), then the SAs that will be set up with be in according to both SPDs; with selectors that are listed as to be protected, to peers that the SPD allows. I don't see a problem with this. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
