Re: Specification of tunnel/transport attribute in IKEv2

[Markku Savela <msa@burp.tkv.asdf.org>]

> From: Dan Harkins <dharkins@tibernian.com>

> What if Joe User had an workstation with IP address 172.21.16.5 and
> the following policy:
> 
>     172.21.16.5 <---> 10.1/16, protect via 192.168.10.1
>     any <--> any, drop
> 
> and 192.168.10.1 has the 10.1/16 network on a directly connected interface
> and the following policy:
> 
>     10.1.17/24 <---> 172.21.16.5, protect via 172.21.16.5
>     any <--> any, drop
> 
> Here Joe thinks he can access more than the remote gateway will allow.
> Joe tries to access 10.1.5.5. How does Joe figure out what the
> problem is?

This is a somewhat different type of policy mismatch than what I was
thinking. In this case, the maintainer of 192.168.10.1 is
intentionally forbidding joe from accessing the 10.1.5.5. If joe still
tries to do that, he is basicly trying to crack the "firewall". It
would be appropriate to alert the 192.168.10.1 maintainer, but I don't
think we should notify the cracker about it.

On the other hand this a good example of why policy selectors should
not be checked in the IKE negotiation. As long as joe stays within
the limits of 10.1.17/24, both sides are happy when they compare the
exchanged packets to their policy selectors.

In above, nothing is yet said about how many SA pairs are being used
between 192.168.10.1 and 172.21.16.5. Assuming only one pair for all
communication, then in the IKE negotiation, the selector information
to be associated with the bots SA's would be

  protocol=any
  src port=any
  dst port=any

> In addition, in your view of how IKE should work it would not be
> possible to do IPsec remote access where one end is coming from an
> unknown IP address and accessing a protected network behind a
> gateway. The gateway cannot know the IP address of the remote client
> a priori and therefore can't have any policy information specifying
> what traffic to and from him is to be protected, dropped, or
> bypassed. And since, in your view, IKE is forbidden from providing
> any hints it won't work.

My view works just fine in such situation. The gateway 192.168.10.1
just has the policy (using your notation)

   10.1.17/24 <---> any, protect via "any"
   any <--> any, drop

You do need to have the ability to express tunneling with
"any". Assuming joe has the policy as before and wants to connect to
10.1.17.1, then IKE negotiates the SA pair exactly as before (except,
of course, that at least now joe must identify itself in phase 1 with
something that does not depend on address). The resulting SA's would
be exactly the same as before.

Looking the situation at 192.168.10.1...

Incoming protected packet from joe gets decoded, detunneled, revealing
the inner IP: src=172.21.16.5 dst=10.1.17.1 (protected via
172.21.16.5). This will match the policy and gets passed on in clear.

Outgoing clear packet is received from 10.1.17.1 with destination
172.21.16.5. Again, this will match the policy selector

   10.1.17/24 <---> any, protect via "any"

At this point there is the first "tricky" issue. In the example, joe
is his own security gateway, so the assumption

  any == "any"

would work and just using the inner destination also as outer
destination gives the correct behaviour. Packet is protected using the
proper SA and sent away.

HOWEVER, if joe itself is behind a security gateway (=172.21.16.1),
and 192.168.10.1 receives and outgoing packet with

  src=10.1.17.1, dst=172.21.16.5

How does 192.168.10.1 know that in this case any != "any", e.g. packet
should be protected via 172.21.16.1).

Freeswan guys probably install additional policy entry 

   10.1.17/24 <---> 172.21.16.5, protect via 172.21.16.1
   10.1.17/24 <---> any, protect via "any"
   any <--> any, drop

This solves the case, when joe is the initator. There is no solution,
if 10.1.17.1 is the initiator (inherently impossible, unless
assumption any == "any" is made).

In my view, the solution could be as follows:

joe's SG (172.21.16.1) negotiates SA's for joe (172.21.16.5), and the
resulting SA has the following info

   protocol=any
   src port=any
   dst port=any
   proxy=172.21.16.5

Now, 192.168.10.1 receives the outbound packet

  src=10.1.17.1, dst=172.21.16.5

it matches the policy

   10.1.17/24 <---> any, protect via "any"

from this it knows that tunneling is required, so it will need to look
for an SA that has proxy=172.21.16.5, and if joe is the initiator,
such thing might be found and packet can be processed.

If SA does not exist, there is not enough information to start
negotiation. Situation is inherently unsolvable (unless a simple
default assumption is attempted, namely the any == "any")