Re: Another field for traffic selector?

["Derek Atkins" <derek@ihtfp.com>]

Mark Duffy <mduffy@quarrytech.com> writes:

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

It really doesn't matter.  You could know that F1-C1 is supposed to
talk to F2-C1, F1-C2 talks to F2-C2, etc.)  But yea, theoretically you
could also sent the IDr payload.

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

Are VPN-IDs dynamic or quazi-static?  If quazi-static then you can
just print a certificate for each firewall involved in a particular
VPN-ID.  If they are absolutely dynamic (e.g. VPN #17 today is not the
same as VPN #17 tomorrow) then we probably need to come up with
another solution.

> --Mark

-derek

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

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       derek@ihtfp.com             www.ihtfp.com