[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: Issue #68: VPNs with overlapping IP address ranges (was Re: 2401bis issues (possible) resolution)
Repeating; hope the text format comes through this time - sorry for the
"noise".
-----Original Message-----
From: Knight, Paul [BL60:1A14:EXCH]
Sent: Wednesday, October 08, 2003 12:13 PM
To: 'Tero Kivinen'; Mark Duffy
Cc: Angelos D. Keromytis; ipsec@lists.tislabs.com
Subject: RE: Issue #68: VPNs with overlapping IP address ranges (was Re:
2401bis issues (possible) resolution)
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: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 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:mduffy@quarrytech.com]
> 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
>
>
>