RE: Issue #68: VPNs with overlapping IP address ranges (was Re: 2 401bis issues (possible) resolution)

["Paul Knight" <paul.knight@nortelnetworks.com>]

Hi Tero and all,  (trying to send again)

I think you are right that the VPN subscriber ID is = not required in the case you describe (individual host or client = connecting via a gateway), but the more difficult case is where there = are multiple "ISP SGW" devices, which are used to = interconnect multiple corporate sites in a VPN.  In the = VPN-related working groups, the terminology would be "PE" - = provider edge devices.

So in terms of your diagram, it would look = like:


 Corp A = --------.                           .------ Corp A
              = +-----+           = ;         +-----+
              | ISP |---{ Internet } ----| ISP |
              | SGW = |            = ;        | SGW |
              = +-----+           = ;         +-----+
 Corp B = --------'                           '------ Corp B

Corporations A & B may trust their links to the = ISP who runs the security gateways, but they want the ISP to provide = IPsec protection between the ISP's SGWs, where the traffic runs across = the Internet.

In my message of yesterday (Re: 2401bis issues = (possible) resolution), I identified some issues, described some ways = to deal with this, and recommended using the VPN-ID as a way for the = ISP SGWs to negotiate an SA pair per VPN between the two SGWs, without = requiring extra IP addresses.

There are ways to multiplex the VPN traffic over a = single SA pair, but these all seem to require either extra = encapsulation or the addition of some "tag" to every = packet.  It appears to me that a solution allowing a single = encapsulation of the corporate traffic (either IPsec tunnel mode or = IP-tunnel-in-IPsec-transport-mode), and without tagging every packet, = requires the VPN-ID (or "Context identifier").

I do hope there is a way to support this requirement = without adding the extra "Context ID" payload, but I have not = seen it yet. I would be happy to hear of a solution.

Another possible way to support this could be another = ID Type within the Identification Payload. In this case, multiple new = ID Types may be needed since there are multiple VPN-ID formats (see my = message of yesterday).  I am somewhat concerned about overloading = the Identification Payload in this way, since the Context IDs are = actually a kind of temporary "sub-identity" of the gateways.  This brings to mind the "me Tarzan - you Jane" concepts = discussed earlier.

Regards,
Paul Knight

P.S.  I include my message of yesterday below = for ease of reference.

> -----Original Message-----
> From: Tero Kivinen [<3d.htm>mailto:kivinen@ssh.fi]
> Sent: Wednesday, October 08, 2003 10:28 = AM
> To: Mark Duffy
> Cc: Angelos D. Keromytis; = ipsec@lists.tislabs.com
> Subject: Issue #68: VPNs with overlapping IP = address ranges
> (was Re: 2401bis issues (possible) = resolution)
>
>
> [Please when you send comments to list, use the = issue number
> in the subject, so it is easier for the others = to search for
> other mails with same issue].
>
> Mark Duffy writes:
> > = >         68 VPNs with = overlapping IP address ranges
> > #68 (as I think you have acknowledged) = consists of multiple parts,
> > some of
> > which are implementation issues but not = all.  Part of #68
> involved a
> > capability in the protocol:
> >
> = >           b. = They MUST negotiate a VPN subscriber ID using IKE, as
> = >           noted = above, to enable forwarding of inbound IPsec
> = >           = traffic after crypto processing.
>
> I do not think there is any need to negotiate = the VPN
> subscriber ID between the parties. The VPN = subscriber ID is
> internal to the SGW, and it is not going to = trust anything
> the other end sends.
>
> If I have understood correctly about the case = it is something like
> this:
>
>
>
>       Corp A = --------.        =         =           +---- Client C
>       =              = +-----+            =           |
>       =              | = ISP |-----{ Internet } ----|
>       =              | = SGW |            =           |
>       =              = +-----+            =           +---- Client D
>       Corp B = --------'
>
>
> Where the ISP SGW is acting as VPN GW for both = corporation A
> and corporation B, and the clients connect to = it using IPsec
> through the internet. Corporations A and B both = use
> 10.0.0.0/8 network, and give out IP address to = the clients
> from the same range. Now when the client C = connects to the
> ISP SGW it authenticates itself as = c@corp-a.com. The ISP SGW
> will now link that authenticated identity to = the VPN
> Subscriber ID of Corp-A, and attach all packets = coming from
> the client C to that VPN ID. When it is sending = them out it
> will send to Corp A interface, because it is = also attached to
> the Corp-A VPN ID.
>
> The ISP SGW will not be trusting client C to = send him the VPN
> ID, as if it would trust clinet C, the = c@corp-a.com could
> send VPN ID of corp-b instead and get access to = the Corp B network.
>
> So only way to get those VPN-IDs is through the = configuration
> based on the authenticated ID of the client, = thus there is no
> need to negotiate them in IKE.
>
> This means that client C and D are normal IPsec = clients, and
> they do not have any special processing to be = done. If Client
> C for some reason wants (and is allowed) to be = part of both
> Corp A and B networks, then he can have two = authenticated IKE
> identities c@corp-a.com and = c@corp-b.com.
>
> All the special processing of VPN IDs etc (or = whatever local
> processing the ISP SGW does) is inside the ISP = SGW, thus it
> is purely local implementation issue.
>
> > When a security Gateway is operating on = behalf of multiple contexts
> > (e.g.
> > multiple subscribers, or multiple = ppvpn-style overlay
> addressing contexts),
> > it is essential that the initiator be able = to convey to the
> responder which
> > context is being addressed.
>
> Do not use IP addresses as a IKE SA identities = then. Use the
> dns names or email addresses or something else. = There is no
> need to use ip addresses in those cases (or = actually using ip
> addresses would be quite bad, as it is not = unique...).
>
> > In the absence of a capability to signal = this
> > in IKE, the only full-functioned = alternative is for the SGs
> to maintain a
> > separate IP address to use for each = supported context.
> This can waste a
> > lot of addresses, and it isn't even as = good anyway because
> it requires
> > coordinated configuration on both ends to = understand which
> IP address in
> > each SG corresponds to which = context.
>
> There is no need for that.
>
> > My conclusion:  2401bis should = support the concept of multiple
> > contexts
> > supported in an IPsec device, and IKE = should provide a
> means to convey the
> > desired context in the initial = exchange.
>
> I do not think this is general case that should = be
> implemented in the all IPsec stacks out there. = It will be
> implemented as purely local matter in some of = the IPsec
> implementations, and there is no need to have = any kind of
> negotiation or changes to the IKE because of = that.
> --
> kivinen@ssh.fi
> SSH Communications = Security                  <3d.htm>http://www.ssh.fi/
> SSH IPSEC = Toolkit           = ;            = ;     <3d.htm>http://www.ssh.fi/ipsec/

***************** yesterday's message below = *******
Hi Angelos, Mark, and all,

I agree with Mark on this, we need a context = identifier for the VPN case, in order to provide the most = straightforward IPsec solution, while not forcing the use of multiple = IP addresses on the security gateways.

Just to make sure we're clear, here is the basic = scenario:

CE-A1--\                       /--CE-A2
        = PE1---(Internet)----PE2
CE-B1--/                       \--CE-B2

CE = Customer Edge device
CE-A1 = CE at customer A, VPN site 1
PE = Provider Edge device (also security gateway = in this case) Customers A,B each have two VPN sites.  They each = use network 10.0.0.0 (for example).

PE1 and PE2 would like to set up IPsec SA pairs = (IPsec connections) to carry the VPN traffic for both VPNs A and = B.

They have at least two basic ways to do this:
(1) Set up a single IPsec connection between PE1 and = PE2 for both VPNs.
(2) Set up one IPsec connection *per VPN* between = PE1 and PE2. Two ways to do this:
   (2a) use one IP address per VPN on the = Internet-facing interface(s) of each PE, and negotiate an IPsec = connection for each IP address pair, and use an internal mechanism to = associate the IP addresses and IPsec connections to the = VPNs.

   (2b) use a single IP address on the = Internet-facing interface of each PE, use a context identifier (VPN-ID) = to negotiate multiple IPsec connections (one per VPN), and use an = internal mechanism to associate the IPsec connections to the = VPNs.

Discussion:
(1) does not require any change to IKEv2 or 2401bis, = but it is not able to carry IP directly (without additional = encapsulation or some kind of label) in the VPN scenario described = above. One approach based on (1) is proposed in = draft-ietf-l3vpn-ipsec-2547-01.txt.  It relies on an MPLS label = attached to each packet within the SA, to allow the receiver to associat= e the traffic with the appropriate VPN.

[IMPORTANT NOTE: This approach implies that paragraph = b. of issue 68 (quoted by Mark below) should use MAY instead of MUST or = SHOULD.  This approach would be invalidated by the adoption of the = MUST language.] A variation of this approach could use a VPN-ID field = appended to each packet instead of an MPLS label.

Another approach based on (1) is described in the = "backbone Virtual Router" discussion of = draft-ietf-l3vpn-vpn-vr-01.txt.  It uses additional encapsulation = to allow multiple VPNs to be carried over a single IPsec connection = between PEs.  It uses additional IP addresses per VPN, but they = can be private addresses of the provider.

(2a) does not scale well, since it requires adding = additional routable IP addresses when additional VPNs are added to a = PE.

(2b) is attractive from the viewpoint of not = requiring multiple IP addresses, although there are minor scaling = issues with separate IPsec connections per VPN.  It requires a = method of signaling a context identifier or VPN-ID during IKE = negotiation.  The simplest way I know to support this requirement = would be to add a Context-Identifier Payload to IKEv2.  It should = support multiple types of context identifiers, since there are several = potential identifiers already known: 1 - VPN-ID - 7 bytes (RFC 2685) 2 = - Route Distinguisher - 8 bytes (RFC 2547) 3 - MPLS Label

Regards,
Paul Knight

> -----Original Message-----
> From: Mark Duffy [<3d.htm>mailto:mduffy@quarrytech.com]<= /FONT>
> Sent: Tuesday, October 07, 2003 4:25 PM
> To: Angelos D. Keromytis; = ipsec@lists.tislabs.com
> Subject: Re: 2401bis issues (possible) = resolution
>
>
> At 01:38 PM 10/7/2003 -0400, Angelos D. = Keromytis wrote:
> >In our weekly teleconference, we discussed = the following
> items from the
> >issues list:
> ...
> = >         68 VPNs with = overlapping IP address ranges
> ...
> >We believe that these items are = implementation-specific and/or not
> >applicable to implementations in general = (this applies in
> particular to
> >50 and partially to 68). We invite one last = round of
> comments on these
> >items --- if you feel strongly, = yell!
>
>
> Hi Angelos and list,
>
> As invited, I am yelling :-)
>
> #68 (as I think you have acknowledged) consists = of multiple parts,
> some of which are implementation issues but not = all.  Part of #68
> involved a capability in the protocol:
>
>          = ; b. They MUST negotiate a VPN subscriber ID using IKE, as
>          = ; noted above, to enable forwarding of inbound IPsec
>          = ; traffic after crypto processing.
>
> When a security Gateway is operating on behalf = of multiple contexts
> (e.g. multiple subscribers, or multiple = ppvpn-style overlay
> addressing contexts),
> it is essential that the initiator be able to = convey to the
> responder which
> context is being addressed.  In the = absence of a capability
> to signal this
> in IKE, the only full-functioned alternative is = for the SGs
> to maintain a
> separate IP address to use for each supported = context.  This
> can waste a
> lot of addresses, and it isn't even as good = anyway because it
> requires
> coordinated configuration on both ends to = understand which IP
> address in
> each SG corresponds to which context.
>
> My conclusion:  2401bis should support the = concept of multiple
> contexts supported in an IPsec device, and IKE = should provide a means
> to convey the
> desired context in the initial exchange.
>
> Thanks, Mark
>
>
>