Re: Specification of tunnel/transport attribute in IKEv2

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

> From: Jan Vilhuber <vilhuber@cisco.com>

> Maybe, but in the interest of maintaining a properly functioning
> network and being able to troubleshoot it (and interoperate between
> vendors), this negotiation is somewhat important (critical in my
> mind).
> 
> Yea... we COULD configure everything manually. Good luck.

Well, we all need good luck in that case. There is no policy
negotiation in the current IKE either.

Note however, that my proposal is:

 - in phase II, only SA's are negotiated, without policy checks

I have no objections, if IKE or something installs or removes
additional policy lines in PHASE 1, after the user has been
authenticated. Thus, a policy could initially be

  - drop all

and there would some local database of users that can establish VPN or
some other access, for example

  joe  -> setup VPN
  bob  -> allow HTTP with ESP
  alice -> setup VPN

so when joe connects from 172.2.1.1 and authenticates itself as joe,
then IKE or something could add a policy line and result would be

  remote 172.2.1.1  -> protect via 172.2.1.11
  drop all

Similarly, if bob connects from 172.2.1.2, the policy is again augmented

  remote 172.2.1.1  -> protect via 172.2.1.1
  remote 172.2.1.2 local-port 80 -> use ESP
  drop all

Note, the policies must still be locally configured. It is a security
breach, if other end can define the policy lines.