Re: Specification of tunnel/transport attribute in IKEv2

[Dan Harkins <dharkins@tibernian.com>]

On Sun, 19 May 2002 00:49:50 +0300 you wrote
> > 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.

Your firewall analogy is breaking down. Joe is not a "cracker" he is a
user who has been properly authenticated by the gateway. The gateway has
decided that he does wish to give Joe access, just that Joe seems to think
he is entitled to access more than gateway is allowing.

Notification of Joe is the prudent thing to do since he is not a "cracker",
he is a legitimate user with old/stale/incorrect policy. By just blackholing
his packets you have relegated him to oblivion. You obviously have not
dealt with real world use of this technology.

This is not a firewall. It's an IPsec gateway.

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

On the contrary, this is a good example of why they should. So that Joe
will know exactly what part of his policy is old/stale/incorrect and
be able to initiate a procedure to fix it. By not checking the only 
information Joe will have is "it's broke". I know who your sysadmin
staff is and I know that "it's broke" is not satisfactory to get them
to fix it. 

IKE wants to make sure that what is being established is useful and if it
is not then to not establish it. If you want to do away with this utility
then you should have some substitute for it.

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

Not just freeswan but every one else who implements this _correctly_.

> 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

Proxy? Where did that come from? I thought IKE was not permitted to provide
any clarifying information in your view. SA were just established that
specify a destination address, in this case 172.21.16.1. There is no tie
from the policy statement with "any" to this address and a packet sent
to 172.21.16.5 would definitely hit the "any" part of that selector but
there would be no way to locate the correct SA and destination gateway.

  Dan.