Re: Another field for traffic selector?

[Shane Amante <shane@castlepoint.net>]

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


On Wed, Mar 12, 2003 at 12:34:09PM -0500, Paul Knight wrote:
> 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: jeremy.de_clercq@alcatel.be 
> > [mailto:jeremy.de_clercq@alcatel.be] 
> > Sent: Wednesday, March 12, 2003 3:19 AM
> > To: Radia Perlman - Boston Center for Networking
> > Cc: ipsec@lists.tislabs.com; 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
> >