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

From: Ravi Kumar <[email-masked]>
Date: Wed, 17 Sep 2003 12:08:17 +0530

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" <[email-masked]>
 > To: "ipsec mailingList" <[email-masked]>
 > Cc: <[email-masked]>; <[email-masked]>; "Angelos D. Keromytis" 
<[email-masked]>; <[email-masked]>; <[email-masked]>
 > 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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Sep 2003 11:03:37 -0400

At 12:08 +0530 9/17/03, Ravi Kumar wrote:
>     'Destination IP'. Based on this, subscriber ID is extracted 
>locally and after decryption, the packets
>     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

Ravi,

Use of multiple public addresses, one per subscriber net per Ipsec 
implementation, does provide another means of identifying the 
subscriber net, but this requires an ability to acquire the multiple, 
public addresses at each end. In that sense, this is a less general 
approach than using a subscriber net ID internal to IPsec (IKE). In 
general I think we are better off with a mechanism that works in all 
cases, vs. one that works only if it is possible to acquire enough 
public addresses from an ISP to assign one to each subscriber net 
address behind the device.

Steve

---

From: Ravi Kumar <[email-masked]>
Date: Thu, 18 Sep 2003 09:06:37 +0530

Hi Steve,
         Since, there is one common method being followed (which does not 
require
         any interoperability), I am trying to see whether we should make 
this requirement as
         'Should' rather than 'MUST'.
    Thanks
    Ravi

At 11:03 AM 9/17/03 -0400, Stephen Kent wrote:
>implementation, does provide another means of identifying the subscriber 
>net, but this requires an ability to acquire the multiple, public 
>addresses at each end. In that sense, this is a less general approach than 
>using a subscriber net ID internal to IPsec (IKE). In general I think we 
>are better off with a mechanism that works in all cases, vs. one that 
>works only if it is possible to acquire enough public addresses from an 
>ISP to assign one to each subscriber net address behind the device.
>
>Steve

----------
Ravi Kumar CH

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 18 Sep 2003 07:49:13 -0400

At 9:06 +0530 9/18/03, Ravi Kumar wrote:
>Hi Steve,
>         Since, there is one common method being followed (which does 
>not require
>         any interoperability), I am trying to see whether we should 
>make this requirement as

Ravi,

How would you characterize the "common method" to which you refer? I 
recall no provisions in 2401 that would allow on to characterize 
locally processed IKE traffic for processing. When we wrote 2401 we 
assumed that folks understood that this traffic need not be subject 
to the SPD/SAD controls, but we didn't make that clear. Still, a less 
than "MUST" statement may be appropriate.

Steve