Re: 2401bis Issue #68 -- Negotiating VPN context

[Mark Duffy <mduffy@quarrytech.com>]

I ardently support signaling the VPN context in IKE as described by Karen 
below.  This should be passed from the initiator to the responder.

So what exactly is a "VPN context" and how is it identified?  At the risk 
of alienating everyone ;-)  I will assert that there is more than one type 
of context to be dealt with.  The two context types I am aware of are:

Context type: security gateway -- This is for the case where a single box 
is serving as security gateway independently on behalf of multiple 
protected subscriber nets.  (I believe this is the case Karen's description 
envisions.) In this case the Context ID is a value that identifies the 
particular security gateway instance.

Context type: overlay network -- This is for cases such as the provider 
provisioned layer 3 VPN case where tunnels protected by IPsec are used as 
"virtual links" in the topology of an overlay network.  In this case the 
Context ID is a value, such as an RFC 2685 VPN-ID, that identifies the 
overlay internetwork to whose forwarding context the virtual link should be 
bound.

Other context types may emerge in the future as IPsec is used in other 
applications.

A minimal level of support for this would be to let IKE convey only a 
Context-ID value.  Ideally this would be an opaque field of variable 
length.  At the least it should be a field that can contain an 8-byte RFC 
2685 VPN-ID.

Some devices support both of the above service types, and need to determine 
what service AND what context is being addressed when they are the IKE 
responder.  This could be addressed by judicious coordinated assignment of 
Context-IDs across both types of contexts, but this would probably impose 
operational hardships.  A nicer approach would be for IKE to convey a 
Context-Type as well as a Context-ID.

Thanks, Mark


At 08:27 PM 9/12/2003 -0400, Karen Seo wrote:
>4. When establishing an SA to a security gateway (SG1) (that also may 
>serve multiple subscribers with non-routable addresses), it is necessary 
>to inform the peer (SG1) as to the identity of the subscriber network on 
>whose behalf the SA is being established, and the identity of the 
>subscriber net that is the target of the SA. Given the possibility of 
>overlapping addresses for subscribers, it is clear that addresses cannot 
>be used for identification in these cases. So, some other form of ID is 
>needed and the form of the ID must be consistent between peers, to ensure 
>that each subscriber net is uniquely identified. It has been suggested 
>that some form of VPN subscriber ID be added as an IKE payload value, to 
>provide a means of passing this info between IPsec peers, when necessary. 
>This additional value is not a selector per se, as it need not be used 
>locally by an IPsec implementation to map outbound traffic to an SA, nor 
>is it checked upon receipt.