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

From: "Paul Knight" <[email-masked]>
Date: Wed, 8 Oct 2003 12:13:06 -0400

Hi Tero and all,

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 [mailto:[email-masked]] 
> Sent: Wednesday, October 08, 2003 10:28 AM
> To: Mark Duffy
> Cc: Angelos D. Keromytis; [email-masked]
> 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 [email-masked]. 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 [email-masked] 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 [email-masked] and [email-masked].
> 
> 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. 
> -- 
> [email-masked]
> SSH Communications Security                  http://www.ssh.fi/
> SSH IPSEC Toolkit                            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 associate 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 [mailto:[email-masked]]
> Sent: Tuesday, October 07, 2003 4:25 PM
> To: Angelos D. Keromytis; [email-masked]
> 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
> 
> 
>

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 9 Oct 2003 11:35:13 +0300

[I will combine my reply to one email about all the issues]. 

> working groups, the terminology would be "PE" - provider edge devices.

Ok, there are some other usage cases too, but the approach I presented
would work for them too, with the overhead of extra IKE SA and extra
credential.

Note, that if the ISP SGW boxes are doing IPsec on the interface
hardware which can fail independantly, then the current IKEv2 draft
requires you to have separate IKE SAs per each hardware, as it is not
accectable for IPsec SA to fail (on the interface hardware) when the
IKE SA stays up.

Also having multiple credentials is good thing, as it offers
protection that if one of the ISP SGW box is compromized, only those
networks which go through that box are compromized, not all VPN
networks anywhere in the ISP SGW (yes, you can have access filters to
limit the damage, but its complexity is the more than having separate
credentials, thus if ISP didn't do multiple credentials because it is
too hard, they would not include the filters either).

For the IKEv2 point of view the VPN ID is not traffic selector, nor is
it pure authentication ID. If you do not want to have multiple IKE SAs
between ISP SGWs then it cannot be authentication ID. It is not
traffic selector as it does not fit current traffic selector approach.

The IKEv2 will have list of traffic selectors items, where you can
select any subset. Each traffic selector item includes ip address
range, protocol, and port range. The VPN ID does not fit to this
approach very well. It should propably be included in all of the
traffic selector items, meaning that it requires quite major change in
the IKEv2 traffic selectors (i.e traffic selector item would have VPN
ID, address range, protocol, and port range). With that approach you
would be able to combine multiple VPN IDs to one IPsec SA (provided
there is no overlapping IP addresses). I.e this IPsec SA traffic
selectors would be:

    VPN ID corp-a, 10.0.0.1-10.0.0.255, any proto, any port
    VPN ID corp-b, 192.168.2.0-192.168.2.255, any proto, any port. 

If we add it as separate type of traffic selector to the list, then
what happens if the responder choose not to include it. I.e the IPsec
SA traffic selectors would be:

    10.0.0.1-10.0.0.255, any proto, any port
    VPN ID corp-a

and the responder could narrow the selection:

    10.0.0.1-10.0.0.255, any proto, any port

Better approach would be to include it (if it is really needed) as
notification that is attached to the create child sa exchange. This
would have the meaning that it communicates the VPN ID to the
responder associated to one IPsec SA created with that exchange. Good
thing about this is that this kind of change can be included as
separate document without breaking any existing implementations (they
will simply ignore the notification if they do not understand it), and
it is much smaller change to be implemented in implementations. 

> to every packet.  It appears to me that a solution allowing a single

I think that using the SPI as a tag is the best approach. It is small
(32 bits), we already have rules how to allocate and what to do with
them etc. I.e use separate IPsec SA for each VPN tunnel. Also IPsec SA
overhead in the SGW is not that much either (8 bytes for sequence
number * 2, 8 bytes for replay window, 16 bytes * 4 for keys (ESP +
auth), both directions etc, i.e about 100 bytes + the information
about the VPN ID (interface id or similar)).

Now the only question is how to tie one SPI to one VPN ID...

> (one per VPN), and use an internal mechanism to associate the IPsec

So, I would propose 2b, but with different way to send the VPN ID
between hosts. My first choice would not send it at all, instead use
different credentials per VPN, and tie VPN ID to the credentials. This
have also better security than using one global authentication
credential.

My second choice would include the VPN-ID-NOTIFICATION in the
CREATE_CHILD_SA exchange in IKEv2, and also document that notification
in separate document. 

> 2 - Route Distinguisher - 8 bytes (RFC 2547) 3 - MPLS Label

That notification could easily include any type of identifiers needed.
The first choice does not care about the types, as the identifiers are
there purely local matter.

Mark Duffy writes:
> It will trust what the peer sends because it authenticates the peer 
> identity, and its configuration tells it which context(s) a given peer may 
> access.  Semantically this is no different than placing separate SGWs there 
> for each context -- each of them only allowing connections from certain peers.

If each system is going to have list of all possible remote GWs which
can connect to it, there is already separate configuration for each
remote end per each VPN. Using separate credentials would then be just
one more configuration information added to this same configuration.
Actually it might also make the configurations smaller, as some of the
configuration can be simply said: if you can authenticate yourself
with certificate from this ISP-Corp-A-internal-CA (internal CA from
the ISP created only for Corp-A), then you are part of Corp-A VPN.

Each box still needs to have only one private key, they only need
multiple certificates for the same private key from different CAs.
There are also other ways to do the same thing (use the dns name
inside the certificate to find out the VPN ID or if using pre shared
keys, use the common key for Corp-A VPN etc).

> I believe your statement above embeds the assumption that Clients C and D 
> connect to the same logical SGW.  I.e. the ISP SGW presents the same 
> identity, offers the same phase 1 policies, etc. to both of them.  I should 
> like the ISP SGW to have the capability to present different identities and 
> policies on behalf of Corp A and Corp B.

It can already do that, because the client C can use the you Jane me
Tarzan approach. Note, having different proposals for different
connections is only possible if we are using per VPN IKE SA along with
per VPN credentials. If we only have one IKE SA then we cannot have
different IKE SA parameters per each VPN. If we have only one identity
and credentials then there is no way to identify during the initial
exchange to which VPN you want to connect (or we have to move the
VPN-ID-NOTIFICATION to IKE_SA_INIT exchange).

So if there is requirement that we need to have different IKE SA
parameters in different VPNs then we do not have any other choice than
having different IKE SAs per VPNs.

> Your statement above also embeds an assumption that the context to be 
> assigned  by the ISP SGW (responder) can be inferred from the identity 
> asserted by the clients.  I think this is a highly undesirable condition to 
> impose, especially for the PPVPN overlay case where the set of ISP SGWs 
> (called PE routers in PPVPN-speak) will be supporting many contexts.  They 
> will not want to have separate identities and credentials for each context!

Why not? With certificates the identity costs them about 1-2 kB or so,
with pre shared keys it costs 50 bytes (name) + 4+16 bytes (ip + key)
per each other end node. If you have 100 VPNs its still quite a small
amount of memory. 

> >The ISP SGW will not be trusting client C to send him the VPN ID, as
> >if it would trust clinet C, the [email-masked] could send VPN ID of
> >corp-b instead and get access to the Corp B network.
> No, because when client C sends the VPN ID of corp-b, it has to 
> authenticate itself to the corp-b context.  The corp-b context does not 
> have any configured policy that will let client C connect.

I.e you need to have mapping from the authenticated ID to the VPN ID,
so why cannot use that information to derive VPN ID in the first place. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/