Subject: RE: Another field for traffic selector?

From: "Claudio Lordello" <[email-masked]>
Date: Wed, 12 Mar 2003 21:43:02 -0500

3 years ago I authored a draft proposing an RFC-2685 style VPN-ID as an "qualifier" for the regular traffic selector identities of IKEv1 ("draft-lordello-ipsec-vpn-doi-01.txt"), and yes, I would love to see a VPN-ID as traffic selector "attribute". However, it seems to me that a globally unique VPN-ID, as described by RFC-2685, and in my original draft, would be more beneficial. What difference does the VPN-ID lengh makes if it will not appear on every packet anyways?

Claudio.

-----Original Message-----
From: Radia Perlman - Boston Center for Networking
[mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 7:21 PM
To: [email-masked]
Subject: RE: Another field for traffic selector?

OK. Let me summarize the issue and what I'll propose
as the solution, and try to answer all the comments.

The issue: two firewalls F1 and F2 are creating VPN service on behalf
of multiple customer nets (C1, C2, C3, C4),
and the nets have the same IP address
space (can be overlapping, can be identical ranges...point being
that an IP address is no longer unique for F2 to know who
to deliver a packet to). Let's say that all customer nets have
the address range 10.1.1.0-10.1.2.255.

Within a customer net the addresses are unique, but between
them they are not.

F1 and F2 are trusted to glue together the pieces of C1, C2, C3, and C4,
but they won't know which is which based solely on addresses.

*********
The proposed solution:

1. Use a "VPN-ID" which need not be globally unique. It only has
   to be such that F1 and F2 know which customer is being referred to.

   If F2 and F3 have a similar topology, they could, in theory, map
   customer net Cn to a different VPN-ID than Cn was assigned between
   F1 and F2.

   I prefer something where we don't need globally unique VPN-IDs, since
   it takes fewer bytes, and because I suspect fewer errors will be
   made when configuring a 2-byte quantity than a 7-byte quantity.
   I imagine the firewall administrator knowing that they have
   customers C1, C2, C3, and C4, and assigning them the numbers
   71, 22, 3, 1, and it's just necessary that "C4" get assigned the
   same number at F2 as at F1.
   
   But if we have globally unique ones, that's fine too.
   Mark Duffy says if we want to copy RFC 2685 it would take
   7 bytes, or to copy RFC 2547 would take 8 bytes).

2. The VPN-ID does NOT appear in data packets. It only exists in the
   IKE negotiation for the child-SA. "I'd like to create an ESP tunnel
   with SPI x, and IP address range k-j, with VPN-ID 7".
   
3. F2, when it receives a packet from F1 over SPI x, knows that it
   needs to get routed to the customer net that has been assigned VPN-ID 7.
   The VPN-ID is implicitly known based on the SPI.
   
4. Since on a particular SA, there should be no possibility of mixing
   traffic from multiple VPNs, the field shouldn't go in the traffic
   selector (which can appear multiple times if there are multiple
   IP ranges) but instead, I'd claim, in the "Traffic Selector Payload"
   (section 3.13 of IKEv2 spec). There's currently a 3-octet "reserved"
   field. I'd suggest using 2 octets of that for VPN-ID, and not
   have globally unique VPN-IDs (the assumption being that firewalls
   wouldn't have more than 2^16 VPNs...if not, we can use all 24 bits).
   
*****************
Comments on various people's comments, if I think the above doesn't
answer the comments...

1) packets do not need to be verified as coming on a particular virtual
net. Assuming there is end-to-end IPsec as well as firewall-to-firewall,
packets would just get lost if misrouted, since the key wouldn't work.
If there is only firewall-to-firewall IPsec, then you were trusted
the firewalls anyway, and the firewalls can (as they could without
VPN-IDs) modify IP addresses, route between the VPNs, etc.

2) Why does it need to go into IKEv2?...because otherwise there's
no way to route the packets, if the IP addresses in the customer
nets overlap.

Radia

---

From: [email-masked]
Date: Fri, 14 Mar 2003 17:03:40 -0700 (MST)

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
>
>
>Sent: Friday, March 14, 2003 2:51 PM
>To: Derek Atkins
>Cc: [email-masked]
>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" <[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: "Cambria, Michael (Michael)" <[email-masked]>
Date: Fri, 14 Mar 2003 20:44:16 -0500

Hi,

I used the term IKE tunnel because it was in the original message.  I wasn't 
exactly sure what it meant.

The ability to havie multiple ISAKMP SA's between the two IKE's was the what I 
missed.  Thanks for filling in the blank.

Thanks,
MikeC

-----Original Message-----
From: Derek Atkins [mailto:[email-masked]]
Sent: Friday, March 14, 2003 7:13 PM
To: Cambria, Michael (Michael)
Cc: [email-masked]; [email-masked]
Subject: Re: Another field for traffic selector?

> How would there be 4 IKE tunnels (ISAKMP SAs?) between each IKE entity?

Where do you see the limit on one-and-only-one ISAKMP SA between IP
Address A and IP Address B?  You have different Cookies and SAid's for
the various SAs.  So SA#1 is ID#1, SA#2 is ID#2.  Note that if you DO
have this limitation of only one ISAKMP SA per peer-IP then you cannot
have multiple peers behind the same NAT, because both of them would
have the same IP Address (albeit different UDP Ports).

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

You did understand the original problem -- a single gateway with one
physical IP address is handling some meta-IP VPN architecture, and you
want to use IPsec between this gateway and another gateway.

Question: what do you mean by IKEv2 tunnel?  Do you mean one ISAKMP
SA?  Or do you mean one IPsec tunnel?  I presume you mean the former,
but it's unclear due to your improper use of terminology.

Furthermore, I do not recall seeing anyone mention a goal of having
only one IKEv2 SA per pair of PPVPN gateways.  If that is an actual
requirement then yes, we would need to explore an alternate solution.
However I disbelieve that maintaining one more SA is a significant
overhead to support meta-IP tunnels, and it's something that works
without any changes to the IKEv2 or IPsec protocols -- indeed, such an
implementation could be done now and be fully compliant.

So, what's the actual "goal"?  Is the goal to support separate meta-IP
tunnels?  Or to support it with one fewer SA?

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

No, of course not.  You just negotiate multiple ISAKMP SAs with your
peers, one per VPN.  If you're handling 100 VPNs, you have 100 ISAKMP
SAs and 200 IPsec SAs.  Keep in mind that you already need to keep
track of the meta-IP state for each VPN, so you DO already have O(n)
state.

> Am I missing something?

I would say "yes", but I'm not sure what you're missing.  Actually,
what you are probably missing is the fact that somewhere in the IPsec
stack implementation there needs to be an up-call to let the IKE
daemon know which ID needs to be used for a particular negotiation.
But that's a local matter (IMHO) because the upcall for YOUR
implementation does not necessarily need to match the upcall in mine.

(The right place to standardize this particular upcall would be within
a PFkey extension).

-derek