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
>