[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