Subject: Re: Another field for traffic selector?

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 14 Mar 2003 10:24:04 -0800

Hi Radia,

I gather my last post hadn't yet propagated through the list when you
composed this. I get it now. I think there are other ways to handle this
(e.g. routing encapsulation by the gateways), but I can see where folks
might like a solution with lower overhead. 

Sorry if I seemed dense.

Scott

Radia Perlman - Boston Center for Networking wrote:
> 
> When traffic is going from one part of the customer's
> intranet to another (as opposed to talking to a
> node off the intranet) there's no natting. A locally
> significant IP address is simply forwarded across
> to the other part of the intranet.
> The firewalls are just creating an "internal" wire
> on behalf of the customer nets. The issue is
> what happens if the same
> pair of firewalls are creating multiple internal
> wires for multiple customers. You can have two
> conversations going on, each looking, to IP,
> like the same locally significant IP addresses.
> 
> If there is some way to tell what "wire" things
> are coming on, as for instance if they are
> different MPLS tunnels, then there's no problem.
> But if they are forwarding simply with IP, then
> without this way of negotiating on SA creation,
> I don't see how the firewalls can do this.
> 
> Radia
> 
> "Scott G. Kelly" <[email-masked]> wrote:
> >I guess I don't see why you can't have multiple tunnels between the
> >devices, since the tunnel selectors (the nat'd network addresses) are
> >unique. Alternatively, you can use an encapsulation of some sort (GRE,
> >UDP, L2TP, etc), which permits unique per-customer selectors. This can
> >be done cleanly without modifying the ipsec protocols, can't it?
> >

---

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Fri, 14 Mar 2003 13:18:42 -0500

Radia

---

From: Derek Atkins <[email-masked]>
Date: 14 Mar 2003 14:03:43 -0500

> I don't see how the firewalls can do this.

Why not just use different identities?

The ingres firewall already needs some out-of-band mechanism to know
that a packet from 10.0.0.1 is from VPN-1 rather than VPN-2.  It can
know this because it's arriving on a different port or a different
MPLS tunnel.  Regardless, it doesn't matter, it knows the source.
This means that any firewall endpoint must necessarily have some
meta-IP method to determine VPNs.

If one piece of hardware is acting as an IPsec terminal point, why
can't it use a different IKE identity per VPN?  If I want to set up a
tunnel for VPN-1, I negotiate an SA for VPN-1 using an IKE ID for
VPN-1.

A box could internally apply the meta-IP information for SA selection.
How this is done does not need to be standardized, IMHO.

-derek

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

---

From: Geoff Keating <[email-masked]>
Date: 14 Mar 2003 16:10:54 -0800

> tunnel for VPN-1, I negotiate an SA for VPN-1 using an IKE ID for

It's worth pointing out that if you try to implement a solution where
you *don't* use a different IKE negotation for each customer, this
makes it possible for a customer to mount a chosen-plaintext attack
and perhaps determine the shared keys and so compromise another
customer's traffic.  Chosen-plaintext attacks are not hard to mount in
many situations where IPSec is in use, but 'not hard' is not always
the same as 'easy and convenient'.

-- 
- Geoffrey Keating <[email-masked]>