Re: Another field for traffic selector?

[Geoff Keating <geoffk@geoffk.org>]

Derek Atkins <derek@ihtfp.com> writes:

> Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com> writes:
> 
> > 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.
> 
> 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.

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 <geoffk@geoffk.org>