RE: Another field for traffic selector?

[Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>]

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