Subject: RE: Another field for traffic selector?

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Wed, 12 Mar 2003 19:20:35 -0500 (EST)

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: Mark Duffy <[email-masked]>
Date: Thu, 13 Mar 2003 01:04:58 -0500

Radia, thank you.  What you propose sounds fine.

However, I will make a small pitch here for the globally unique VPN-ID:
In a PPVPN (provider provisioned VPN) view of things, the "firewalls" may 
be called "Provider Edge devices" (PEs).  And a number of these may 
participate in a VPN membership discovery scheme in which they learn which 
VPNs (by VPN-ID) are "present" in which PE devices.  Then they might 
initiate IKE signalling amongst themselves, using this super-duper 
capability to bind the SAs to VPN contexts.  A 2-octet VPN-ID would be very 
limiting in this environment because  a) a given network operator might 
service more than 64K VPNs, and  b) if used in an interdomain environment 
it would not be practical to ensure the uniqueness of locally-significant 
2-octet VPN-IDs.  Globally unique RFC 2685 VPN-IDs would solve this nicely.

BTW, the rfc 2685 VPN-IDs are hierarchically structured, consisting of an 
organization number, and a VPN number from a space maintained by that 
organization.  So I don't think the length of the thing per se should lead 
to configuration errors -- in scenarios such as the one you describe, that 
don't need all that uniqueness, the high order bits would just be a 
constant.  Looked at another way, if IKE permits an opaque 8 octet field, 
it can be up to whoever is operating the equipment what to use as 
VPN-IDs.  They can still use e.g. 71, 22, 3, 1, etc.

--Mark

At 07:20 PM 3/12/2003 -0500, Radia Perlman - Boston Center for Networking

---

From: "sankar ramamoorthi" <[email-masked]>
Date: Thu, 13 Mar 2003 01:42:14 -0800

----- Original Message -----
From: "Radia Perlman - Boston Center for Networking" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 12, 2003 4:20 PM
Subject: RE: Another field for traffic selector?

> VPN-IDs) modify IP addresses, route between the VPNs, etc.

This is how I understood the VPN-ID usage. What I was trying to point out
that this IKEV1 went into a lot of effort to ensure negotiated traffic
selector parameters are verified for each packet. This issue comes up
periodically. There was a long thread last year questioning the need for TS.
One of the points that was emphasized repeatedly was the access control
features of ipsec.

If we now make part of the negotiated traffic selector (VPN-ID) to be not
sent on the wire but implicitly trust the peer to send the data through the
right SA, are we loosening the access control mechanisms in ipsec? What does
it imply?

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Mar 2003 10:29:42 -0800 (PST)

> no way to route the packets, if the IP addresses in the customer

This evades the real question. Why does this need
to be part of the base spec? There's lots of world
hunger that IKEv2 doesn't solve. Why can't this be
deferred for later consideration, rather than an
ill-advised last minute addition?  If IKEv2 does
not lend itself to such additions, maybe we asking
ourselves how we can make IKEv2 more amenable to
these kinds of additions rather than loading up
the kitchen sink blindly.

	    Mike

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 13 Mar 2003 13:27:18 -0800

Aside from the question of deferring this, I think there's a larger
question pertaining to whether the spec needs to solve this at all. I've
seen this problem (overlapping address space) solved by using
per-customer tunnels, and static nat'ing the private addresses at either
end when the customers want to interact (extranet scenarios). I really
don't see why everyone's ipsec implementation must be modified to
accommodate someone's aversion to per-customer tunnels.

If I'm missing something, please let me know.

Scott

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Mar 2003 14:07:10 -0800

One key issue about VPN-IDs:

The VPN-ID itself (RFC 2685) is spec'd only as a format - it may be 
standards-track but it refers to a 'work in progress' for its 
architecture and management (presumably the document that later became 
RFC2764).

I.e., some of the assertions about how the VPN-ID is managed appear to 
be based on an Informational RFC only.

Joe

---

From: Mark Duffy <[email-masked]>
Date: Thu, 13 Mar 2003 20:29:16 -0500

I think this is in fact *specifically* so that we can have per-customer 
tunnels.  That is, per-customer tunnels, for multiple customers at once, 
that terminate in the same IPsec device.  Without this proposed feature 
there is no  attractive alternative for the security gateways to agree on 
which tunnels are for which customers.

I also believe that "everyone's ipsec implementation" need not be modified 
to do anything with a VPN-ID attribute.  Devices that support only one VPN 
context would presumably ignore this.

Mark

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 13 Mar 2003 17:54:11 -0800

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?

---

From: Mark Duffy <[email-masked]>
Date: Thu, 13 Mar 2003 21:49:10 -0500

Hi Scott,
I'm not sure if I understand what you mean but let me try to answer.

I think you are assuming that the plaintext packets would be NAT'ed before 
they arrive at the "shared" security gateway.  I think this is an incorrect 
assumption, at least for the types of scenarios I envision.  Plenty of 
people won't want NATs in the middle of their private intranets - it breaks 
too many things.  The other suggestion, encapsulating the plaintext packets 
before they arrive at the "shared" security gateway, seems to me equally 
improbable.

The problem we are trying to solve here IMHO is where some sort of service 
provider is providing security gateway services to multiple independent 
customers, using a shared IPsec box.  But the customers will want it to 
work just as transparently as if they were being served by a dedicated 
IPsec box.  This transparency is not consistent with placing extra NAT or 
encapsulation boxes in the path.

-Mark

---

From: Markku Savela <[email-masked]>
Date: Fri, 14 Mar 2003 09:25:15 +0200

Assuming just for a moment that some "VPN-ID" type attribute would be useful.

Then, wouldn't something similar be required if someone actually
implemented "userid" specific selector? And, wanted to have separate
SA's for each user on a multiuser system (even when communicating with
the same other end).

If I ever implemented it, the policy would actually read as

  dst = <someservice> -> use_user_specicic_IPSEC

(e.g. selector would match all traffic to/from <someservice>, but the
specification instructs system negotiate SA pair per user).

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 14 Mar 2003 09:53:59 -0800

Okay, I think I understand a bit better now. In the case where customers
don't have access to one another's networks, you will not want (or need)
to nat traffic. However, I think Sankar's point is an important one: the
provider must strictly control the boxes at both ends, or else you lose
the access controls provided by ipsec, and are open to spoofing attacks.
As an aside, I believe that some vendors support a "virtual router"
concept which might permit the tunnels to be handled independently, but
I'm not sure if this would work for your scenario or not.

Scott