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

[Karen Seo <kseo@bbn.com>]

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