[Openswan dev] [IPsec] IKEv2 Traffic Selector narrowing questions
Paul Wouters
pwouters at redhat.com
Mon Feb 13 15:16:43 EST 2012
On 02/13/2012 02:28 PM, Yoav Nir wrote:
> On Feb 13, 2012, at 3:26 PM, Paul Wouters wrote:
>
>> 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)
> Not really. Think of an example, where Gw-A has 192.168.3.0/24 behind it, while Gw-B has 192.168.6.0/23 behind it, although on Gw-B it is defined as two /24 subnets.
>
> Gw-A might initiate with TS: 192.168.3.0/24<-->192.168.6.0/23, but since the triggering packet is 192.168.3.5-->192.168.6.9, the proposal gets narrowed to 192.168.3.0/24<-->192.168.6.0/24.
I'm still looking at it from the user's point of view. Let's say that
Sysadmin A brought up the "A to B" tunnel. They think they got the whole
/23 covered, but in fact half of what they think is up, is not.
Should GwA keep retrying the for either the entire /23 or for the
remaining /24 that fell outside the narrowing?
> 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.
Paul
More information about the Dev
mailing list