RE: Another field for traffic selector?

["Cambria, Michael (Michael)" <mcambria@avaya.com>]

Hi,

How would there be 4 IKE tunnels (ISAKMP SAs?) between each IKE entity?

I understood the original problem as having only one (physical) FW at each end.  
Each of these FW's had one IP address into the "cloud" network which would be used 
to connect to the (physical) FW at the remote end.  The goal was to have one 
IKEv2 tunnel over the cloud used to setup all the SA's between customer subnets.

In order to have a FW have 4 identities (and 4 IKE tunnels), would IKE need to use different UDP ports between identities or have 4 different IP addresses (i.e. one 
per customer) into the cloud?

Am I missing something?

Thanks,
MikeC


-----Original Message-----
From: Radia Perlman - Boston Center for Networking
[mailto:Radia.Perlman@sun.com]
Sent: Friday, March 14, 2003 2:51 PM
To: Derek Atkins
Cc: ipsec@lists.tislabs.com
Subject: Re: Another field for traffic selector?


Aha. I think Derek's suggestion is a more
elegant solution to the problem. To explain
it again just because seeing it explained in different
words is always helpful,
to perform VPN service on behalf of four customer
nets, (C1, C2, C3, C4), firewall n would have
four identities, say Fn-C1, Fn-C2, Fn-C3, Vn-C4, and
also have 4 certificates (for each of the identities) and
form four IKE tunnels. Then which customer
net the child-SA is for is based on which IKE
tunnel it was formed under.

The identities could have the same public key or different
public keys for the different.
It don't think it matters.

Radia


"Derek Atkins" <derek@ihtfp.com> wrote:
>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.
>
>A box could internally apply the meta-IP information for SA selection.
>How this is done does not need to be standardized, IMHO.
>
>-derek
>
>> Radia
>> 
>> "Scott G. Kelly" <scott@airespace.com> 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?
>> >
>> 
>
>-- 
>       Derek Atkins
>       Computer and Internet Security Consultant
>       derek@ihtfp.com             www.ihtfp.com