[Openswan dev] [IPsec] IKEv2 Traffic Selector narrowing questions

[Paul Wouters]

On Sun, 12 Feb 2012, Scott Fluhrer (sfluhrer) wrote:

>> 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.

Right, so that likely means the initiator cannot allow any narrowing
(unless you accept it is okay to start an IKE negotiation for each
src/dst combo, which causes lots of delay for the user over establishing
one broad SA)

> 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).

Agreed. But the initiator already sent a proposal that it thinks will
cover its traffic. The responder's second guessing is what makes this
harder.

>> 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.

Because I need to give the user some feedback if they bring a tunnel up
to tell them if it succeeded or not. If part of the range is only
covered, then what does one tell the user? The initiator also cannot
keep requesting more narrow SA's until its covered all the space (esp in
a 10/8 or even 0/0 case). So in the end, part of a tunnel is up and the
user might need to know.

> 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.

"some traffic" is all the traffic the responder narrowed down...

> 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.

Right. While I agree encrypting some is better then encrypting none, the
confusion goes back to the user. Is the VPN up or not? Well, it's kinda
up. As implementor, I have a hard time working with this.

> 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".

But again, leaving the user in some odd state of having partial vpn
connectivity.

> Or, are you of the opinion that the two sides should reject negotiations
> (and all traffic is dropped) until the policy resyncs?

At least that is something I can convey back to the user.

>> 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.

Yes, but that is the "routed vpn" scenario.

>> 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?

Because that case covers all traffic the initiator wanted, while
reducing the address space covers only partialy what the initiator
wanted. The question then becomes, did the initiator meant to say "give
me all or some of this". And if so, then how does the initiator know
which "some" is good and which "some" is bad for the user?

> 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.

If I want to setup a tunnel to 10/8 and I only get 10/24, then for 10/24
the tunnel suceeded, but for 10.255.255.0/24 the tunnel failed. The only
information I have as implementor is that the user wanted 10/8. So to me
the tunnel has failed to establish. But taking that approach just means
I always end up rejecting every narrowed down proposal, which I still
think is the sane default. I am just reaching out to understand why and
how I should allow this narrowing to take place to get the advantages of
it without the disavvantages.

Paul
>