Subject: RE: Another field for traffic selector?

From: "Paul Knight" <[email-masked]>
Date: Wed, 12 Mar 2003 12:34:09 -0500

Hi Radia and Jeremy,

I'll second Jeremy's support for this.  The need for including something
like a VPN-ID as a traffic selector has been discussed in at least two
individual drafts in the PPVPN WG:
- draft-knight-ppvpn-vr-protocol-00.txt (Protocol Actions for Virtual Router
VPNs)
- draft-duffy-ppvpn-ipsec-vlink-00.txt (Framework for IPsec Protected
Virtual Links for PPVPNs)

I would definitely support adding extensibility or flexibility to the
encoding of the traffic selector, since even for VPN-ID, there is still not
a universal format.  (RFC 2685 specifies 7 bytes; RFC 2547 has a Target VPN
or Route Target which is 8 bytes.)  I think the field should accommodate
these sizes when VPN-ID is used as a selector.  It may be possible to use a
smaller field, but the signaling to negotiate a smaller field and ensure its
uniqueness would probably be more burdensome than simply having a field
which can accommodate current VPN-IDs.

Draft-knight-ppvpn-vr-protocol-00.txt suggests:
   The Traffic Selector (TS) payload proposed in [IKE-V2] may be 
   suitable for this purpose [carrying the VPN-ID].  The TS Payload
specifies address ranges, 
   and thus does not appear to be a clear fit for specifying a single 
   VPN-ID, but it may be possible to define an additional TS Type with 
   semantics suitable for the VPN-ID. 

Also, as a quick response to Sankar's question: 
(How are the packets coming out of a tunnel verified to ensure they match
the negotiated virtual net? [....] Is Virtual net field expected to be part
of ipsec headers also?)

Yes, I think including a VPN-ID in the IPsec header is needed to map the
packets to the VPN.

Regards,
Paul 

"The world is a jungle in general, and the networking game contributes many
animals."  - RFC 826

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Wednesday, March 12, 2003 3:19 AM
> To: Radia Perlman - Boston Center for Networking
> Cc: [email-masked]; Carugi, Marco [CTF:0000:EXCH]
> Subject: Re: Another field for traffic selector?
> 
> 
> 
> > I'm not sure what to call it, or what size it ought to be. Other 
> > protocols need to solve this problem. The "VLAN tag" is 
> used in 802. 
> > "Partition ID" is used in infiniband. I've heard the name "virtual 
> > router ID" for something, but I think that's a terrible name (since 
> > it's a virtual net, not a virtual router). If anyone can suggest an 
> > already-recognized name for this concept, an 
> already-recognized size 
> > of the field, and an already-recognized numbering scheme, we should 
> > adopt it. Otherwise, I'd suggest the name "virtual net", 
> size 2 bytes,
> > and a numbering scheme that is local to F1 and F2 (someone
> > would configure it compatibly at the two ends and map it
> > to specific customer nets).
> 
> For some VPN approaches, the PPVPN WG refers to the "Virtual 
> Private Networks Identifier" defined in RFC 2685.
> 
> > So, there are two issues:
> > a) I think we need to add this field to the traffic selector in IKE
> 
> 1. I support this idea, and 
> 2. if it is accepted by the ipsec community, I propose to 
> allign with the ppvpn wg.
> 
> thanks,
> Jeremy.
> 
> 
> > b) If at this late date extra things (this plus the uniquifier) are 
> > coming up as needing to be in the traffic selector, perhaps the 
> > encoding of traffic selector should be more flexible, so that new 
> > fields can be added in the future.
> > 
> > Radia
>

---

From: Shane Amante <[email-masked]>
Date: Wed, 12 Mar 2003 15:23:00 -0700

Instead of creating another field in the IPSec header, why can't the
receiver use the IPSec SPI be used to direct the traffic into the
appropriate VPN context?

For the record, I also support deployment of signalling VPN-ID's
within IKEv2.  One example of where signalling VPN-ID's is most useful
is multi-user/customer IPSec GW's, where:
a) there is only a single, unique public IP address on the public side
of the chassis; and,
b) there are multiple customers on the private side of the chassis,
each of which has the same, overlapping RFC1918 address space, e.g.:
	C1-private: 192.168.1.0/24
	C2-private: 192.168.1.0/25
	C3-private: 192.168.0.0/23
	...
NOTE: All three of the above customers/contexts ARE NOT related to
one another, e.g.: do not share security policies, etc.

As it stands now, the only way to overcome the above limitation (aside
from proprietary signalling) is to create a unique, public IP address
per customer/context, which: a) hurts SP's that strive to conserve
their public IP addresses; and, b) is no different than deploying a
whole IPSec GW per customer.

-shane

---

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

Hi Shane,

I think your point here raises an interesting question.

When one uses a unique public IP address per customer/context (as you 
describe below) one ends up with separate IKE SAs, and probably separate 
identities, used for each customer/context.

OTOH, putting the VPN ID in the Traffic Selector Payload as proposed in 
this thread binds each child SA to a VPN; the IKE SA is shared across 
multiple VPNs.

Another possibility that presents itself is putting the VPN ID attribute in 
some payload that binds it to the IKE SA.  (HDR payload?  An optional 
VPN-ID payload?)  This would make it more similar to the way you describe 
below, only not require all the separate IP addresses.

Which is better?  Sharing an IKE SA across VPN contexts probably scales 
better and is probably sufficient when say a service provider is operating 
the SGs at both ends.  However, for the case of multi-user/customer IPSec 
GW's, especially where the remote peer might be a single-user GW or a 
multi-user one operated by a different service provider, it might be the 
case that each user/customer would want to use their own identity.

--Mark

At 03:23 PM 3/12/2003 -0700, Shane Amante wrote:
[snip]
>One example of where signalling VPN-ID's is most useful