[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Another field for traffic selector?

Title: RE: Another field for traffic selector?

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.


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

> -----Original Message-----
> From: jeremy.de_clercq@xxxxxxxxxx
> [mailto:jeremy.de_clercq@xxxxxxxxxx]
> Sent: Wednesday, March 12, 2003 3:19 AM
> To: Radia Perlman - Boston Center for Networking
> Cc: ipsec@xxxxxxxxxxxxxxxxx; 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