RE: Another field for traffic selector?

[Mark Duffy <mduffy@quarrytech.com>]

Hi Radia and others,

I too would love to see a "VPN-ID" conveyable by IKEv2.

RFC 2685 style VPN-ID (7 bytes) would seem a fine format.

RFC 2547 Route Targets (8 bytes) are another possibility but given that RFC 
2547 allows them to be  a) different in one direction than in the other, 
and  b) not have a 1:1 correspondence to what Radia has dubbed "customer 
intranets, C1, C2, C3, C4", I suspect it would be difficult to use them.

Both types are (or can be) structured to be globally unique.
An encoding that could transparently carry either would probably be wise at 
this point.


On the question of verifying received packets to see that they match the 
VPN ID of the negotiated traffic selectors, this doesn't seem necessary to 
me, based on my motivations anyway :-).  Especially given that there is 
currently no VPN ID field in the AH/ESP packet to be verified.  The SPI can 
be used to deliver the received packets to the correct context, so this is 
an access control issue only.

Perhaps then VPN-ID shouldn't be a Traffic Selector at all but rather some 
other attribute that can be bound to an SA.  Sorry but I don't know enough 
about IKEv2 to know whether such a concept fits or not.  In my mind this 
would be analogous to the "Remote End ID" AVP in l2tpv3, which can be used 
to bind a VPN ID to an l2tp session at the time the session is 
created.  Just substitute "IPsec SA" for "l2tp session" to get the same 
ability with IPsec.

--Mark