Re: Specification of tunnel/transport attribute in IKEv2

[Dan Harkins <dharkins@tibernian.com>]

On Sat, 18 May 2002 06:36:42 +0300 you wrote
> 
> There is no need and never should be any "policy negotiation" protocol
> within IKE. I view IPSEC policy as similar concept as firewall
> rules. Each host decides and specifies it's requirements outside
> IKE. There is no "firewall policy exchange protocol" either, and hosts
> manage to communicate over them.

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?
In your view of the world each side has SAs that denote their own rules
but there is no communication between them to express a mismatch. Someone
monitoring the 192.168.10.1 gateway may see lots of packets sent from
172.21.16.5 being dropped because they fail a policy check (assuming of
course that someone is monitoring it which is _highly_ unlikely). But that's
about it. To Joe it's a blackhole and "it just doesn't work". 

  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.

  A hopeless blackhole and (arguably) the most popular use of IPsec today
being not allowed. That's not a very compelling argument.

  Dan.