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

[Ravi Kumar <ravivsn@roc.co.in>]

   Hi,
     Implementations (including ours) allocate one or more public IP 
addresses for each subscriber.
     It is expected that IKE negotiations and IPSEC traffic come with 
this(these) IP address(es) as
     'Destination IP'. Based on this, subscriber ID is extracted locally 
and after decryption, the packets
   are forwarded onto the subscriber network.
      It is not mandatory to negotiate Subscriber ID via IKE.
     Due to this, I feel, we should not make negotiation of subscribe ID 
mandatory.
    But, if same public IP address is used across multiple subscribers, 
then subscriber ID via IKE
    is needed. The proposed text should take care of above.
Thanks
  Ravi

 > ----- Original Message -----
 > From: "Karen Seo" <kseo@bbn.com>
 > To: "ipsec mailingList" <ipsec@lists.tislabs.com>
 > Cc: <byfraser@cisco.com>; <tytso@mit.edu>; "Angelos D. Keromytis" 
<angelos@cs.columbia.edu>; <kivinen@ssh.fi>; <kseo@bbn.com>
 > Sent: Friday, September 12, 2003 5:27 PM
 > Subject: 2401bis Issue #68 -- VPNs with overlapping IP address ranges
 >
 >
 > > 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

The Views Presented in this mail are completely mine. The company is not 
responsible for what so ever.

----------
Ravi Kumar CH
Rendezvous On Chip (I) Pvt Ltd
Hyderabad, INDIA

ROC HOME PAGE:
http://www.roc.co.in