[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Issue #68: VPNs with overlapping IP address ranges (was Re: 2 401bis 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 [<3d.htm>mailto:kivinen@xxxxxx] > Sent: Wednesday, October 08, 2003 10:28 = AM > To: Mark Duffy > Cc: Angelos D. Keromytis; = ipsec@xxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxx 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@xxxxxxxxxx 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@xxxxxxxxxx and = c@xxxxxxxxxxx > > 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@xxxxxx > 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 = 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 [<3d.htm>mailto:mduffy@xxxxxxxxxxxxxx]<= /FONT> > Sent: Tuesday, October 07, 2003 4:25 PM > To: Angelos D. Keromytis; = ipsec@xxxxxxxxxxxxxxxxx > 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 > > >