[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RE: Another field for traffic selector?



The different IKE tunnels are differentiated by having different
SPI pairs (what in IKEv1 was called cookie pairs). So Fn starts
up 4 IKE-SAs. The identity that the initiator asserts in the IKE
handshake defines whether that IKE-SA is for C1, C2, C3, or C4.
(Note it doesn't need to assert an identity for the other end...its
own identity is sufficient---this comment is to answer a comment from someone
in a different email).

So let's say Fn creates 4 IKE SAs. When using identity Fn-C1 to
create an IKE-SA, it winds
up with SPI pair (26,91) and when using identity Fn-C2, it winds up
with SPI pair (8,152). Any child-SA created under (26,91) would
be understood to belong to the VPN for C1. Any child-SA created under
IKE-SA (8,152) would be understood to belong to the VPN for C2.

Radia
>
>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
>
>
>
>