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

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



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

At 08:27 PM 9/12/2003 -0400, Karen Seo wrote:
>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

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


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

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