Paul Wouters writes:
> 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".
I think your problem is as you think it as concept of "tunnel" being
up or down, it would be better to think it as "VPN connection" as
defined by "IKEv2 SA" being up or down.
I.e. immediatley when you get your first IKEv2 SA (and Child SA)
negotiated with the other end your VPN is up. You can now send traffic
through that VPN connection to the other end. If there is no Child SA
suitable for the traffic defined in the policy, you use IKEv2 SA to
create it and send it forward using that Child SA. If that Child SA is
not allowed by remote policy, then you drop the packet (and that means
you have mismatching policies between the two hosts).
You do not need to have all possible SAs you could negotiate with that
specific policy up, before you should consider your VPN being up.
> >> 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.
Unfortunately people are lazy, and quite many system adminstrators
want to do exactly that. I myself think 0/0 and ::/0 polices are bad
and should not be used, especially as it requires special handling so
that your "local network" packets still get sent locally and not sent
to the VPN tunnel (for example the http-login page, your dhcp packets,
etc).
But that seems to be something that system adminstrators want so you
might need to implement it anyways.
> > 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".
The tunnel is there, it is not just yet actually formed. When you send
first packet trying the head to that tunnel it will get automatically
created (provided it is allowed by policy).
> 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?
It is ok not to send the information about the packet if you do not
have it. If you have it the RFC says you SHOULD send it.
If you do not send it, then other end is STILL allowed to narrow the
SA down to whather it thinks it wants the SA to be, but as it does not
have any information for which of the possible subsets of the
initiators proposal it should narrow to, it might take something that
is not useful for the initiator.
In that case the responder can also send ADDITIONAL_TS_POSSIBLE
notification telling that there would be another possible SA that
would more SAs which could be created using the same TS set.
> 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.
Your connection is not failing, as when you hit the other half, the
IPsec will automatically trigger the IKEv2 CREATE_CHILD_SA exchange
and create another SA for that second half.
The connection would only fail if you would try to create SA that is
NOT allowed by the responder's policy.
> 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.
Note, that responder is ALWAYS allowed to narrow the TS proposed by
the initiator. There is no way to disable that. This is mandatory
feature of the IKEv2. The responder does not need to support narrowing
itself, but the initiator MUST be able to handle the case where
responder decided to narrow the TS.
Also you SHOULD always send the data from the packet as first TS if
you have packet which triggered the negotiation, as this allows
responder to do intelligent and useful narrowing.
Lets take an example. The HQ has 10.0.0.0/8 network configured, but
because of the adminstrative reasons it is always split up to
10.x.y.0/24 networks. For example each user is given access permission
per /24 network, and thats why the gateway is always configured not to
allow any subnet larger than /24 in one Child SA.
The VPN client wants to connect to the HQ, and in the startup creates
the IKEv2 connection to the HQ server. It sends remote TS as:
TSi = 192.168.2.11
TSr = 10.0.0.0-10.255.255.255
without the data from packet as it does this on the startup and there
is no packet.
The server will narrow that down to some 10.x.y.0/24 network, lets say
it just takes the first network, i.e. sends narrowed TS back:
TSi = 192.168.2.11
TSr = 10.0.0.0-10.0.0.255
N(ADDITIONAL_TS_POSSIBLE)
it adds ADDITIONAL_TS_POSSIBLE notification as there would be more SAs
that would be possible for the TS initiator proposed.
The VPN client now has the VPN connection up to the HQ.
Next VPN client tries to start reading email from the
mail.hq.example.com. It first connects to the dns server 10.0.0.1 to
find out the IP-address of mail.dep1.example.com. This packet goes
through the Child SA created in the first step, and it gets reply back
saying that dep1 mail server is at the 10.0.22.4. (the 10.0.22.0/24
happen to be the dep1 service network).
Now the VPN client tries to send packet to 10.0.22.4 port 25, and
notices there is no Child SA for it, but it is allowed by the local
policy, so it will trigger new CREATE_CHILD_SA negotiation and sends
TS:
TSi: TCP,3233,192.168.2.11
192.168.2.11
TSr: TCP,25,10.0.22.4
10.0.0.0-10.255.255.255
sending 2 TS payloads, one for the exact data from the packet, another
for the generic policy.
The gateway will see this, and will narrow the proposed list into the
subset allowed by its policy and making sure the first traffic
selector is included in its response. So it will reply with traffic
selectors saying:
TSi: 192.168.2.11
TSr: 10.0.22.0-10.0.22.255
Note, that it did remove the first initiators traffic selectors, as
they are already included in the traffic selectors it responded. Also
it did include full 10.0.22.0/24 network as this is what policy says.
It does not need to include the ADDITIONAL_TS_POSSIBLE as it was able
to fullfill the requirement that the first TS fits in to the returned
SA and after fullfilling that requirement there was only one subset
which was allowed, i.e. if the client would resend that same TS set
again, it would create exactly same (and only that) response back.
There would not be any other possible answer from the server.
Next if VPN client tries to connect to the some other network which it
is not allowed to i.e. tries to connect to the 10.0.23.4 it tries with
another CREATE_CHILD_SA exchange with traffic selectors:
TSi: TCP,2323,192.168.2.11
192.168.2.11
TSr: TCP,80,10.0.23.4
10.0.0.0-10.255.255.255
Now the HQ SGW says that this user is NOT allowed to connect to the
10.0.23.0/24 network, and sgw starts processing the operations as
defined in the RFC5996:
----------------------------------------------------------------------
The responder performs the narrowing as follows:
o If the responder's policy does not allow it to accept any part of
the proposed Traffic Selectors, it responds with a TS_UNACCEPTABLE
Notify message.
o If the responder's policy allows the entire set of traffic covered
by TSi and TSr, no narrowing is necessary, and the responder can
return the same TSi and TSr values.
o If the responder's policy allows it to accept the first selector
of TSi and TSr, then the responder MUST narrow the Traffic
Selectors to a subset that includes the initiator's first choices.
In this example above, the responder might respond with TSi being
(198.51.100.43 - 198.51.100.43) with all ports and IP protocols.
o If the responder's policy does not allow it to accept the first
selector of TSi and TSr, the responder narrows to an acceptable
subset of TSi and TSr.
----------------------------------------------------------------------
It notices, that yes, it would be able to allow some parts of the TS,
so it will not reply with TS_UNACCEPTABLE.
Then it checks whether it can allow the whole set, and finds out that
it cannot, so it needs to do narrowing.
The next check fails also, as it notices that it cannot allow this
users to access the 10.0.23.4 machine, so it cannot do intelligent
narrowing.
Now it is left ot the last option. I.e. it needs to narrow this down
to something that will not be useful for the user. Which of the
possible subsets it takes is completely implementation dependant. It
might take the same way out it took when you created the first SA,
i.e. return 10.0.0.0-10.0.0.255. Or it might intelligently notice that
you already have Child SA for that range, so lets not create
overlapping range, lets take next one from the policy which is not
already covered by the SAs we have. The next one might be
10.0.22.0-10.0.22.255, which it also have. The next one after that
might be 10.0.44.0-10.0.44.255, so it might return
TSi: 192.168.2.11
TSr: 10.0.44.0-10.0.44.255
N(ADDITIONAL_TS_POSSIBLE)
and add the ADDITIONAL_TS_POSSIBLE as there is still more possible
subsets it has not yet used.
Anyways the responder will see that the trigger for the packet did
create Child SA, but when it tries to send packet again, it will not
find usable Child SA for it, so it might trigger again. Normally you
would not want it to go to loop to creating multiple exachanges, so
you would have some kind of negative cache marking that this kind of
packet triggered already lately, so do not trigger again for similar
packets for next n seconds.
This last part of the processing is not really very clean, it would be
better if there would be clean error code returned by the responder,
but as the data from the packet was added bit late to the IKEv2
specification, we didn't want to change the TS format to add for
example a bit for it, but instead hacked it in as being first TS in
the list. Also as some people considered it important to allow NOT
sending the data from packet, we cannot mandate it always being there,
so there is no real way for responder knowing whether it is there or
not, and special processing depending whether it is there or not is
not done.
As this last case is anyways failure case, where the there either is
policy mismatch or the user is trying to do something he is not
allowed (i.e. attack), this is not very common case and thats why
there might not be need to "optimize" that corner case.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
