Subject: Re: Modefg considered harmful

From: [email-masked]
Date: Thu, 13 Feb 2003 17:39:28 +0100

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.

---

From: Derek Atkins <[email-masked]>
Date: 13 Feb 2003 22:21:45 -0500

Sorry, you lost me in the sea of acronyms.  Could you please expand
PE and SP?  Provider Equipment and ...???

more inline..

> believe it to be related with the customer's private addresses). 

This is only one possible scenario.  In your scenario you may not care
about ip address policy inside the tunnel, in which case you can leave
the policy as 0/0 <-> 0/0, which is perfectly fine.  However, just
because YOUR architecture doesn't need this feature does not imply
that others can live without it.

> interfaces are really what's needed in the PPVPN context) is mapped to a
 
Again, this may be fine in a PPVPN world, but the world is not just
PPVPN.  I want to set of host-to-gateway road-warrior VPNs, or even
host-to-host protections.  I need to be able to dynamically set
policies on what address to expect on any particular SPI, and I want
these policies tied to the IKE ID.

Pehaps your world does not require this level of protection.  Then
again, I do not have to answer to your boss. ;)

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: [email-masked]
Date: Fri, 14 Feb 2003 10:15:04 +0100

> PE and SP?  Provider Equipment and ...???

sorry... (as you say, we live in different worlds ;); PE stands for
Provider Edge device and SP for Service Provider.

> that others can live without it.

I agree. We'll have to find a solution where all architectures that are
impacted can be satisfied. (isn't that what applicability statements are
for ?)

> these policies tied to the IKE ID.

I understand, I'm not disputing that different worlds may have different
requirements.

Jeremy.