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

[Paul Wouters]

On Mon, 13 Feb 2012, Paul Hoffman wrote:

>>> There is no reason why the initiator cannot allow any narrowing. This is supposed to be an improvement over IKEv1 where any mismatch in configuration between the peers resulted in failure to set up a tunnel. I realize that this invalidates the concept of a defined tunnel being either "up" or "down".
>>
>> Right. This is the exact problem I'm trying to handle, and I don't see a good way out. I'm also really afraid people will start demanding I configure 0/0 to them so they can be lazy and I end up with massive overlapping policies to deal with and I won't be able to have more then one vpn up at a time.
>
> If the problem is "the application knows the exact tunnel it needs", then the solution is that if the responder narrows the tunnel, the IPsec stack tells the application "you never got a tunnel".

Okay, so in that context, reading section 2.9:

    To enable the responder to choose the appropriate range in this case,
    if the initiator has requested the SA due to a data packet, the
    initiator SHOULD include as the first Traffic Selector in each of TSi
    and TSr a very specific Traffic Selector including the addresses in
    the packet triggering the request.

Am I right that it is valid to not send the first TSi/TSr of the packet
that triggered the IKE initiation?

> IKEv2 was designed around the idea of gateways being the ones that control the tunnel properties, thus avoiding the API issues to applications.

If you give me a $vendorbox at home to handle the VPN for me, and my box
initiates a connection to the mothership, and it narrows it down to half
of it, me on my laptop still have no idea why my connection is failing
if it trying to hit the other half.

I do see the use case where you configure a 0/0 on my $vendorbox and
it sets up narrow SAs to the mothership for those addresses is would
like to receive, as those indeed do change depending on mothership
expansion. So I do think we should support this, but I do think the
default of this should be "off". I'll think about how to relay this
information back to the user. With NetworkManager integration, this
should be possible.

Thanks for everyone's input on this,

Paul