Subject: Re: Another field for traffic selector?

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Fri, 14 Mar 2003 14:51:15 -0500

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" <[email-masked]> wrote:
>Radia Perlman - Boston Center for Networking <[email-masked]> 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" <[email-masked]> 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
>       [email-masked]             www.ihtfp.com

---

From: Mark Duffy <[email-masked]>
Date: Fri, 14 Mar 2003 17:41:00 -0500

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

---

From: "Derek Atkins" <[email-masked]>
Date: 14 Mar 2003 18:57:44 -0500

Mark Duffy <[email-masked]> writes:

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

-derek

> 
> At 02:51 PM 3/14/2003 -0500, Radia Perlman - Boston Center for
> Networking wrote:

---

From: Mark Duffy <[email-masked]>
Date: Sat, 15 Mar 2003 15:13:16 -0500

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