Re: Another field for traffic selector?

[Mark Duffy <mduffy@quarrytech.com>]

Ah. I was ready to say I didn't think this solved the problem, because 
there was no way for Bob to know which context Alice wanted to have an SA 
with.  And AFAIK that was true for IKEv1.  For IKEv2, I think this would be 
done by Alice sending the optional [IDr,] payload to Bob.  Is that what you 
have in mind?

I think that would do pretty well.  A minor deficiency from the PPVPN POV 
would be that VPN membership discovery schemes may be passing around 
VPN-IDs and so VPN-IDs would be what the device has available to send to 
the IKE peer.  I suppose this could be addressed by having the membership 
discovery scheme pass some recognized IKE identity type instead, or by 
stuffing VPN-ID into ID_KEY_ID, or by defining a new IKE ID type that has 
type VPN-ID.

--Mark


At 02:51 PM 3/14/2003 -0500, Radia Perlman - Boston Center for Networking 
wrote:
>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