Re: Another field for traffic selector?

[Mark Duffy <mduffy@quarrytech.com>]

Hi Derek,

Perhaps I am being dense, or perhaps we have somewhat different problems in 
mind that we are trying to solve.

Suppose we have some number of security gateways F1, F2, ... and each has 
some number of customer contexts that it is serving e.g. F1-C1a, F1-C2a, 
..., F2-C1b, F2-C2b, ...   Suppose F1 initiates an IKE SA to F2, on behalf 
of F1-C1a and it wants F2 to respond on behalf of F2-C1b.  How is F2 to 
know which of its customer contexts to use?

I think perhaps you are assuming that the desired responder ID can be 
inferred from the initiator ID that is sent?  In particular are you 
assuming that identity F1-C1a == F2-C1b?  Or that F1 has a preconfigured 
mapping from initiator identity to intended responder identity?  I don't 
think those are valid assumptions.  In fact, now that I have had a day to 
think about it, I don't think that it is sufficient even if the initiator 
passes the desired responder identity [IRr] payload.

Here is why.  In the problem I have in mind, devices such as we have called 
a firewall in this thread (called "PE routers" or just "PE"s in ppvpn 
terminology) may use protocols like BGP or RADIUS to discover, for each VPN 
context, the addresses of the other firewalls (PEs) that serve the same 
VPN.  For this purpose a globally significant VPN-ID is assigned to each 
VPN context in all participating firewalls (PEs).

Each firewall (PE) then wants to set up, perhaps, an IKE SA to each other 
firewall (PE), for each VPN context.  Thus we have F1 initiating multiple 
IKE SAs to F2, each SA for a particular VPN context.  F3 may also be 
initiating  to F2 for the same contexts.  F1 has to tell F2 which VPN 
context each IKE SA is for.  Passing the VPN-ID in an IKE payload would be 
a direct way to do this.  But if we rely on any scheme that uses the IKE 
identity to represent the VPN context, then we have unfortunately coupled 
the VPN-ID with the IKE identity.

One result of this coupling would be that we can end up with multiple 
devices asserting the same identity.  Offhand, this seems bad from a 
security perspective.  Wouldn't it present a problem if using shared secret 
auth? How does the responder know which shared secret to use unless it uses 
the same one for all peers in a given VPN?  With certificates, is it any 
better?  I'm a little out of my depth here but if the responder has already 
cached a cert or public key for the identity, isn't it broken unless all 
peers asserting that identity have the same private key?

--Mark


At 06:57 PM 3/14/2003 -0500, Derek Atkins wrote:
>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