Subject: 2401bis Issue #68 -- VPNs with overlapping IP address ranges

From: Karen Seo <[email-masked]>
Date: Fri, 12 Sep 2003 20:27:35 -0400

Folks,

Here's a description and proposed approach for:

IPsec Issue #:	68

Title:		VPNs with overlapping IP address ranges

Description:
============
How should we address the situation of VPNs between customer 
intranets (PPVPNs) that have overlapping, private IP address ranges? 
This situation involves several problems.

1. Outbound IPsec traffic -- An IPsec implementation needs to be able 
to associate outbound traffic with the right SPD (SPD cache) in order 
to apply the appropriate policy to the traffic.  However, 2401's set 
of selectors are not sufficient to enable selection of an appropriate 
SPD when there are overlapping subscriber address spaces served by a 
single IPsec implementation.  However, SPD selection could be 
performed in a purely local fashion, e.g., based on tracking the 
local interface on which the packet arrived.

2. Inbound IPsec traffic -- The SA in which the traffic arrives will 
be linked to an SPD entry which will define the set of selectors, 
algorithms, etc. to use in checking the data. However, when the data 
exits IPsec processing, if the destination address is not unique 
relative to the set of subscribers served by the IPsec device, the 
SAD will need to contain some data that will enable appropriate 
routing of the traffic to the right subscriber.  Here too, this could 
be a purely local matter.

3. Non-IPsec traffic -- Other problems arise with regard to handling 
of non-IPsec traffic.  When subscriber addresses are not routable, 
NAT or some similar process has to be employed to translate the 
private addresses to routable addresses.  In theory, this could be 
done in two ways

a. AFTER outbound traffic is processed (bypassed) by IPsec and BEFORE
    inbound traffic is handed to IPsec for access control.
b. BEFORE outbound traffic is passed to IPsec (bypassed) and AFTER
    inbound traffic exits IPsec.

Our understanding is that (b) is not acceptable because subscribers 
want to use native, private addresses for SPD entries.   For case 
(a), the NAT processing can be effected outside of IPsec, i.e., after 
outbound traffic is bypassed and before inbound traffic is handed to 
IPsec for access control.

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.

Proposed approach:
==================
We recommend that IPsec implementations that support multiple 
subscriber nets with overlapping private address spaces incorporate 
the following capabilities:

a. They MUST employ some local means to select the appropriate SPD for
    each subscriber for outbound traffic
b. They MUST negotiate a VPN subscriber ID using IKE, as noted above,
    to enable forwarding of inbound IPsec traffic after crypto processing.
c. They SHOULD employ NAT, outside of IPsec, to accommodate bypassed
    traffic.

These requirements are imposed only on IPsec implementations that 
support multiple subscriber networks that employ private addresses 
(and which may thus overlap).

Thank you,
Karen

---

From: Mark Duffy <[email-masked]>
Date: Fri, 19 Sep 2003 00:27:26 -0400

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:
>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.

---

From: Mark Duffy <[email-masked]>
Date: Fri, 19 Sep 2003 00:00:34 -0400

At 04:42 PM 9/18/2003 -0400, Stephen Kent wrote:
>Mark,
>
>>>Proposed approach:
>>>==================
>>>We recommend that IPsec implementations that support multiple subscriber 
>>>nets with overlapping private address spaces incorporate the following 
>>>capabilities:
>>>
>>That addresses your numbered item 1 above (for outbound traffic).  I 
>>think there should be a corresponding recommendation a' that addresses 
>>item #2 above (for inbound traffic).  E.g. "They MUST employ some local 
>>means to select the proper subscriber for inbound IPsec traffic."
>
>for inbound traffic, the SAD entry would use the negotiated VPN subscriber 
>ID to map, via some local means, to the right subscriber. Is that what you 
>have in mind?

Yes, exactly.  Or even in the event that the VPN ID is not negotiated but 
determined in some other, static way, then it still needs to use some local 
means to determine the proper subscriber.

>>I agree that NAT is best done on the outside (black side).  But I 
>>question whether 2401bis should be saying so.  It seems to me that it is 
>>beyond the scope of IPsec.
>
>We're trying to be complete, but you are right that this is not purely an 
>IPsec issue. How about if we say that some means, e.g., NAT, is needed to 
>deal with bypassed traffic?

That's fine, it sounds a little less coercive.  The part about doing it on 
the black side was useful though.  Perhaps it could add that if NAT is 
done, it is usually advisable to do it on the outside, so that the SG can 
be configured based on the native addresses.

>Also, we should probably add a note re the assumed context, i.e., that 
>this model assumes that the subscribers with private address space are NOT 
>trying to communicate securely between nets where there would be address 
>space collisions.

Sure.
BTW, I think the VPN-ID aka context ID is useful even if the address spaces 
do not overlap.  Separation can be desirable even when overlapping 
addresses do not make it necessary.

>Steve

Thanks, Mark

---

From: Mark Duffy <[email-masked]>
Date: Thu, 18 Sep 2003 14:52:36 -0400

Hi Karen, I have embedded 2 comments below.   --Mark

At 08:27 PM 9/12/2003 -0400, Karen Seo wrote:
>How should we address the situation of VPNs between customer intranets 
>(PPVPNs) that have overlapping, private IP address ranges? This situation 
>involves several problems.
>
>1. Outbound IPsec traffic -- An IPsec implementation needs to be able to 
>associate outbound traffic with the right SPD (SPD cache) in order to 
>apply the appropriate policy to the traffic.  However, 2401's set of 
>selectors are not sufficient to enable selection of an appropriate SPD 
>when there are overlapping subscriber address spaces served by a single 
>IPsec implementation.  However, SPD selection could be performed in a 
>purely local fashion, e.g., based on tracking the local interface on which 
>the packet arrived.
>
>2. Inbound IPsec traffic -- The SA in which the traffic arrives will be 
>linked to an SPD entry which will define the set of selectors, algorithms, 
>etc. to use in checking the data. However, when the data exits IPsec 
>processing, if the destination address is not unique relative to the set 
>of subscribers served by the IPsec device, the SAD will need to contain 
>some data that will enable appropriate routing of the traffic to the right 
>subscriber.  Here too, this could be a purely local matter.
>
>3. Non-IPsec traffic -- Other problems arise with regard to handling of 
>non-IPsec traffic.  When subscriber addresses are not routable, NAT or 
>some similar process has to be employed to translate the private addresses 
>to routable addresses.  In theory, this could be done in two ways
>
>Our understanding is that (b) is not acceptable because subscribers want 
>to use native, private addresses for SPD entries.   For case (a), the NAT 
>processing can be effected outside of IPsec, i.e., after outbound traffic 
>is bypassed and before inbound traffic is handed to IPsec for access control.
>

That addresses your numbered item 1 above (for outbound traffic).  I think 
there should be a corresponding recommendation a' that addresses item #2 
above (for inbound traffic).  E.g. "They MUST employ some local means to 
select the proper subscriber for inbound IPsec traffic."

>c. They SHOULD employ NAT, outside of IPsec, to accommodate bypassed

I agree that NAT is best done on the outside (black side).  But I question 
whether 2401bis should be saying so.  It seems to me that it is beyond the 
scope of IPsec.

>These requirements are imposed only on IPsec implementations that support 
>multiple subscriber networks that employ private addresses (and which may 
>thus overlap).
>
>Thank you,
>Karen

---

From: Stephen Kent <[email-masked]>
Date: Fri, 19 Sep 2003 09:29:51 -0400

At 0:00 -0400 9/19/03, Mark Duffy wrote:
>>>>subscriber nets with overlapping private address spaces 
>>>>incorporate the following capabilities:
>>>>
>>>That addresses your numbered item 1 above (for outbound traffic). 
>>>I think there should be a corresponding recommendation a' that 
>>>addresses item #2 above (for inbound traffic).  E.g. "They MUST 
>>>employ some local means to select the proper subscriber for 
>>>inbound IPsec traffic."
>>
>>for inbound traffic, the SAD entry would use the negotiated VPN 
>>subscriber ID to map, via some local means, to the right 
>>subscriber. Is that what you have in mind?
>
>Yes, exactly.  Or even in the event that the VPN ID is not 
>negotiated but determined in some other, static way, then it still 
>needs to use some local means to determine the proper subscriber.

OK, we'll make appropriate changes to the text along these lines.

>>>question whether 2401bis should be saying so.  It seems to me that 
>>>it is beyond the scope of IPsec.
>>
>>We're trying to be complete, but you are right that this is not 
>>purely an IPsec issue. How about if we say that some means, e.g., 
>>NAT, is needed to deal with bypassed traffic?
>
>That's fine, it sounds a little less coercive.  The part about doing 
>it on the black side was useful though.  Perhaps it could add that 
>if NAT is done, it is usually advisable to do it on the outside, so 
>that the SG can be configured based on the native addresses.

Yes, we should note that too. We felt it appropriate to suggest NAT 
on the outside for exactly the reason you cite.

>>Also, we should probably add a note re the assumed context, i.e., 
>>that this model assumes that the subscribers with private address 
>>space are NOT trying to communicate securely between nets where 
>>there would be address space collisions.
>
>Sure.
>BTW, I think the VPN-ID aka context ID is useful even if the address 
>spaces do not overlap.  Separation can be desirable even when 
>overlapping addresses do not make it necessary.

Once the facility is available, it is up to the local admins to 
decide when/how to use it.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 18 Sep 2003 16:42:28 -0400

Mark,

>think there should be a corresponding recommendation a' that 
>employ some local means to select the proper subscriber for inbound 
>IPsec traffic."

for inbound traffic, the SAD entry would use the negotiated VPN 
subscriber ID to map, via some local means, to the right subscriber. 
Is that what you have in mind?

Also, we should probably add a note re the assumed context, i.e., 
that this model assumes that the subscribers with private address 
space are NOT trying to communicate securely between nets where there 
would be address space collisions.

Steve