Re: Modefg considered harmful

[jeremy.de_clercq@alcatel.be]

Hi Derek, Dirk, all,

jumping in on an earlier comment:

> A client connects to a gateway but doesn't agree on an IP Address.
> The client then says "ok, I'm 1.2.3.4".  The IPsec gateway has no way
> to know that this client is authorized to use 1.2.3.4 -- it's just
> trusting the client, which is bad.  Think PPVPN!  If my company and
> your company share a VPN node, I could gain access to your vpn this
> way.

In a scenario where sites are allowed to connect to the PPVPN using an
IPsec tunnel with the PE (which serves different VPNs), the SP's PE
would need to be pre-configured with the necessary information to
authenticate connecting sites as belonging to a specific PPVPN (I don't
believe it to be related with the customer's private addresses). 

Once the (dynamically established IPsec) virtual interface (virtual
interfaces are really what's needed in the PPVPN context) is mapped to a
specific Virtual Router (or VRF in BGP/MPLS VPNs), from a customer
transparency requirement point of view, using DHCP for both IP address
assignment and for the other configuration information assignment looks
like the preferred approach.

I believe it to be more transparant (e.g. inter-working with a DHCP
infrastructure), in-line with PPVPN's use of virtual interfaces and more
easily extensible; I therefore support the requests as formulated by
Bernard Aboba and Dirk Van Aken to include the RFC3456 approach in
IKEv2. One way forward could be to list both solutions and clearly
describe their applicability.

Jeremy De Clercq.