IPSec Working Group Claudio Lordello INTERNET-DRAFT Udo Neustadter Category: Standards Track Siemens Expires: February, 2001 August, 2000 VPN-ID-Enhanced IPSec-VPN DOI for ISAKMP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract The IPSec DOI for ISAKMP defines identities for phase 2 exchanges that are suitable for a flat, unique address space. On the other hand, different VPN's cannot guarantee a non-overlapping address space among them. Therefore when security gateways on an ISP network negotiate IPSec SA's in the context of multiple VPN's, identifying traffic flows for this multiplicity of VPN's become an issue. Of course, an alternative would be to have multiple contexts of security gateways, one for each VPN. Unfortunately that would impose severe administrative challenges to an ISP, some of which are described later. Another alternative and a more appealing one would be to have a single security gateway with a single tunnel endpoint address, a single X.509 certificate, etc., that exists in a common context and is able to negotiate IPSec tunnels for any VPN with a presence in the security gateway. For the later to be possible however, it is required for this common security gateway to be able to negotiate phase 2 SA's on behalf of each one of these VPN's with overlapping address spaces. A second motivation for the later approach would be to simply negotiate IPSec tunnels for each VPN as a whole without implying any specific traffic flow. This specification describes an extended DOI for ISAKMP which, while Lordello, Neustadter Standards Track Page 1 Internet Draft IPSec-VPN DOI for ISAKMP August, 2000 inheriting the existing IPSec DOI in its entirety, defines extra types of phase 2 identities which include a VPN-ID field as an extra piece of tunnel identity, i.e., a qualifier for the IP addresses selectors. The VPN-ID is defined in RFC 2685. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP14]. 3. Introduction For an introduction to VPN's and VPN-ID's the reader is pointed to [VPNFRAME] and [VPNID]. VPN-ID's have the property of allowing globally unique identification of private networks. In a Quick Mode (QM) exchange identities are exchanged between the initiator and the responder. These identities define the IPSec SA selectors, which are used to control what packets are expected and allowed in a given IPSec SA. These identities are specified in the IPSec DOI specification [IPSECDOI]. Basically, the types of identity allowed include IP address(es) (in several formats, i.e., single address, range of addresses, and subnets for both IPv4 and IPv6), protocol ID, and port number. In addition, some other identity types are deemed allowed in [IPSECDOI] although it has been agreed in interoperability workshops to restrict QM identity types to the IP address types only. Certain security gateways can be implemented on ISP-Class IP routers, which are logically broken into multiple router instances each with its own routing table. On these routers, the traffic on one subset of IP interfaces is routed in the context of one routing table while the traffic of another subset of IP interfaces is routed in the context of another routing table, and so on. Each subset of IP interfaces having its traffic routed in the context of its own routing table while sharing a single router's physical resources is referred to as a virtual router or simply VR. One important characteristic of such virtual routers is that they are not expected to guarantee a non-overlapping address domain among them, i.e., each virtual router has its own IP address realm. When an IPSec security gateway is implemented on an ISP-class IP router, which supports multiple instances of virtual routers like described above, there can be a few approaches for such an implementation. This document focuses on the approach whereby extra ID Payload Types are defined carrying an VPN-ID identifier as a qualifier for the IP addresses selectors. Therefore, this draft defines and proposes additional identity types to be used during an IKE phase 2 exchange so that VPN-ID's can become a selector qualifier. This proposal is made in the form of a new DOI which Lordello, Neustadter Standards Track Page 2 Internet Draft IPSec-VPN DOI for ISAKMP August, 2000 inherits the existing IPSec DOI specified in [IPSECDOI] and defines further identity types. For a description and analysis of other approaches to solve the issue of identifying multiple IP address realms during a phase 2 SA negotiation refer to section 5. 3.1. Terminology This document uses the following terms: VR It refers to a subset of interfaces having its traffic routed in the context of its own routing table while sharing a single router's physical resources. VPN-ID A globally unique identifier given to a network created by a set of interconnected routers, virtual routers that belong to a single administrative entity characterized by a non-overlapping address space. The connection among the several routers on a VPN can be real IP Interfaces dedicated to that VPN or can be in the form of IP Tunnels (IPSec, GRE, L2TP) whose endpoints are defined in another context (possibly the public Internet context) but internally carrying traffic for that VPN. The format for this identifier is defined in [VPNID]. 4. Security Association Payload The Security Association Payload defined for this DOI is identical to the one defined in [IPSECDOI], section 4.6.1, with the exception of the Domain of Interpretation field. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation (IPSec-VPN) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Security Association Payload Format The Domain of Interpretation field is a 4 octets field specifying a DOI. For this IPSec-VPN DOI, the value remains to be assigned by IANA. When the IPSec-VPN DOI is specified in this field, all existing definitions from [IPSECDOI] remain valid in addition to the definitions contained in this DOI. Lordello, Neustadter Standards Track Page 3 Internet Draft IPSec-VPN DOI for ISAKMP August, 2000 5. Identification Payload Content This DOI specifies additional identity types to the ones specified in the IPSec DOI [IPSECDOI]. As such, all implementations supporting the additional Identity Types defined in this DOI MUST also support the Identity Types defined in the IPSec DOI [IPSECDOI]. The Identification Payload Content as described in section 4.6.2 of the IPSec DOI [IPSECDOI] remains entirely valid with this DOI. For illustration purposes the content of the Identification Payload as defined by ISAKMP [ISAKMP] is shown below. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Type | Identification Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Identification Payload fields are defined as follows: o Next Payload - 1 octet - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, this field will be zero (0). o RESERVED - 1 octet - Unused, must be zero (0). o Payload Length - 2 octets - Length, in octets, of the identification data, including the generic header. o Identification Type - 1 octet - Value describing the identity information found in the Identification Data field. o Identification Data - variable length - Value, as indicated by the Identification Type. 5.1. New Identification Type Values The following table lists the assigned values for the new Identification Type field found in the Identification Payload for this DOI. Lordello, Neustadter Standards Track Page 4 Internet Draft IPSec-VPN DOI for ISAKMP August, 2000 ------------------------------------------------- ID Type Value ------------------------------------------------- ID_VPN_ID.............................TBA by IANA ID_VPN_ID_IPV4_ADDR...................TBA by IANA ID_VPN_ID_IPV4_ADDR_SUBNET............TBA by IANA ID_VPN_ID_IPV4_ADDR_RANGE.............TBA by IANA ID_VPN_ID_IPV6_ADDR...................TBA by IANA ID_VPN_ID_IPV6_ADDR_SUBNET............TBA by IANA ID_VPN_ID_IPV6_ADDR_RANGE.............TBA by IANA ------------------------------------------------- The VPN-ID MUST be interpreted by security gateways to identify a particular VR whose traffic is expected and allowed in the IPSec SA being negotiated, i.e. the VPN-ID becomes another SAD selector. In addition, traffic from IPSec tunnels created on that VR's behalf is considered to belong to that VR, even when the tunnel itself (outer header) is routed in another VR's context (the common context). When no further identification data is provided (i.e., IP addresses, protocol and port), it is implied that ANY traffic associated with the given VPN-ID is expected and allowed in the IPSec SA, i.e. the VPN-ID becomes the only SAD selector. How exactly traffic is assigned to one or another VPN-ID is implementation specific. It is however a common approach to have IP Interfaces assigned to one and only one VR. In cases where a given VPN ID is not known to a responder security gateway, it should act as if the proposed client identities are not allowed by its policies, and reply with a Notify Message Type INVALID-ID-INFORMATION as specified by RFC 2409 [IKE]. In addition, besides the VPN-ID, further identity data can be provided such as IPv4/Ipv6 IP Address, IPv4/Ipv6 IP Address Range, IPv4/Ipv6 IP Subnet, Protocol ID and Port Number. In such cases the extra identity information is to be processed as extra selectors to be applied to all traffic for IP Interfaces belonging to the VR identified by VPN-ID plus all traffic from all IPSec SA's negotiated for the VR identified by the same VPN-ID. In other words, the VPN-ID qualifies traffic of which set of IP Interfaces and IPSec SA to be submitted to IPSec SPD/SAD processing. The Protocol ID field, when included in the identity information, contains a value specifying an associated IP protocol ID (i.e. TCP/UDP). A value of zero means that the Protocol ID field should be ignored. The Port Number field, when included in the identity information, contains a value specifying an associated transport layer port. A value of zero means that the Port Number field should be ignored. All new Identification Types have fixed sizes. Lordello, Neustadter Standards Track Page 5 Internet Draft IPSec-VPN DOI for ISAKMP August, 2000 All new Identification Types are used only in Phase 2 SA negotiations. 5.1.1 ID_VPN_ID The ID_VPN_ID type specifies a seven (7) octet encoding a VPN-ID as defined by RFC 2685 [VPNID]. The format of the Identity Payload is shown below. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | RESERVED | Payload Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Type | VPN-ID OUI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN-ID Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1.2 ID_VPN_ID_IPV4_ADDR The ID_VPN_ID_IPV4_ADDR type specifies a combination of a VPN-ID as defined by RFC 2685 [VPNID], a single four (4) octet IPv4 address, a protocol ID and a Port Number. The format of the Identity Payload is shown below. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | RESERVED | Payload Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Type | VPN-ID OUI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN-ID Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED | Protocol ID | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ID Type is set to ID_VPN_ID_IPV4_ADDR. 5.1.3 ID_VPN_ID_IPV4_ADDR_SUBNET The ID_VPN_ID_IPV4_ADDR_SUBNET type specifies a combination of a VPN-ID as defined by RFC 2685 [VPNID], a range of IPv4 address, a protocol ID and a Port Number. The range of IP Addresses is represented by two four-octet values. The first value is an IPv4 IP Address. The second is an IPv4 network mask. Ones (binary 1) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (binary 0) indicate a "wildcard" bit. The format of the Identity Payload is shown below. Lordello, Neustadter Standards Track Page 6 Internet Draft IPSec-VPN DOI for ISAKMP August, 2000 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | RESERVED | Payload Length = 24 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Type | VPN-ID OUI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN-ID Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED | Protocol ID | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ID Type is set to ID_VPN_ID_IPV4_ADDR_SUBNET. 5.1.4 ID_VPN_ID_IPV4_ADDR_RANGE The ID_VPN_ID_IPV4_ADDR_RANGE type specifies a combination of a VPN- ID as defined by RFC 2685 [VPNID], a range of IPv4 address, a protocol ID and a Port Number. The range of IP Addresses is represented by two four-octet values. The first value is the IPv4 IP Address that begins the range (inclusive). The second value is the IPv4 IP Address that ends the range (inclusive). The format of the Identity Payload is shown below. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | RESERVED | Payload Length = 24 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Type | VPN-ID OUI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN-ID Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED | Protocol ID | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 IP Address - Beginning of Range | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 IP Address - End of Range | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ID Type is set to ID_VPN_ID_IPV4_ADDR_RANGE. 5.1.5. ID_VPN_ID_IPV6_ADDR Similar as ID_VPN_ID_IPV4_ADDR except that an IPv6 IP Address replaces the IPv4 IP Address. The Payload Length and ID Type fields must also be adjusted accordingly. Lordello, Neustadter Standards Track Page 7 Internet Draft IPSec-VPN DOI for ISAKMP August, 2000 5.1.6 ID_VPN_ID_IPV6_ADDR_SUBNET Similar as ID_VPN_ID_IPV4_ADDR_SUBNET except that an IPv6 Subnet replaces the IPv4 Subnet. The Payload Length and ID Type fields must also be adjusted accordingly. 5.1.7 ID_VPN_ID_IPV6_ADDR_RANGE Similar as ID_VPN_ID_IPV4_ADDR_RANGE except that an IPv6 Address Range replaces the IPv4 Address Range. The Payload Length and ID Type fields must also be adjusted accordingly. 5.2. Co-existence of IPSec DOI and IPSec-VPN DOI A Security Gateway supporting this DOI can negotiate some IPSec SA's using the established IPSec DOI [IPSECDOI] and others using this IPSec-VPN DOI. In such cases, all IPSec SA's negotiated using the IPSec DOI MUST NOT apply to traffic of any IP Interfaces or IPSec SA's negotiated on a VPN-ID's behalf, i.e., using any of the identity types defined in this DOI. In addition, it SHOULD apply to all other traffic. 5.3. VPN-ID's for IDci and IDcr A Quick Mode Exchange making use of any of the VPN-ID identity types defined in this specification MUST do it for both IDci and IDcr, i.e., it MUST use one of the VPN-ID types of identity on both IDci and IDcr. The other identity data (IP Addresses, Protocol ID, and Port Number) keep the same properties as defined by the IPSec DOI. 6. Appendix A - Motivation In the Introduction section of this draft it was mentioned that multiple approaches exist for solving the handling of multiple IP address realms by an ISP-class security gateway. In this informative section some of those approaches are described and analyzed regarding performance and other factors. Other approaches may exist besides the ones described here. At the end, hopefully it will be clear why adding a VPN-ID identifier to the ID payload was the preferred choice. Approach 1: An obvious first approach is one where each virtual router can have its own security gateway context, completely unaware and independent of other security gateway instances. That's equivalent to running a separate context of a routing protocol like BGP, OSPF, etc. for each virtual router. Such an approach, although viable when the number of virtual routers making up a physical router is small enough, would have severe limitations on Lordello, Neustadter Standards Track Page 8 Internet Draft IPSec-VPN DOI for ISAKMP August, 2000 scalability. In addition it has a major disadvantage of not leveraging the ISP infrastructure since for each new customer commissioned in the network needs to have an entire new security gateway context setup. In this approach, IPSec tunnels do not cross VR domains. Approach 2: In a second approach a single instance of a security gateway could establish multiple ISAKMP SA's, one for each virtual router protected by the security gateway. IPsec SA's for a particular virtual router would then be negotiated on the context of the ISAKMP SA associated with that virtual router. This approach would scale slightly better than the previous one although it still has the major overhead of multiple ISAKMP SA's and everything that comes with it. Approach 3: Yet a third approach would exist if there were a way to identify the virtual router context for which a given IPsec SA is being negotiated. This would be the ideal solution in the sense that between two routers in the ISP network there would be only one ISAKMP SA negotiated. This would allow a single instance of a security gateway and a single ISAKMP SA to be shared amongst all virtual routers occurring on a physical router. In such approach the phase I SA's are not established in the context of a particular VR but in a common context. However, the phase II SA's must be negotiated in the context of a particular VR. That is due to the fact that an IPSec SA destination and policies for given traffic flow in VR-1 may be completely different than those for the same traffic flow in VR-2. As an illustration to the above consider the following figure. 10.1.* 10.2.* -------+ +------+ +------+ +------- Cust1 | VR-1 | | | | VR-1 | Cust1 +--------+ I1 | | I1 +--------+ | | VR-0 | | | SG-A +====================+ SG-B | VR-2 | | (tunneled traffic) | | VR-2 +--------+ I2 | | I2 +--------+ Cust2 | | | | | | Cust2 -------+ +------+ +------+ +------- 10.1.* SiteX SiteY 10.2.* The figure shows two physical routers and IPSec security gateways, SG-A and SG-B; each having IP Interfaces I1 and I2 assigned to virtual routers VR-1 and VR-2 respectively. Given that one of the basic premises of virtual routers is that they may have overlapping address spaces, one can clearly see the problem that arises when traffic from 10.1.* arriving on interface I1 of SG-A has to be IPSec-tunneled to SG-B as identified by SG-A's policies. Traffic from 10.1.* destined to 10.2.* arrives at SG-A on a interface that belongs to VR-1. Assuming a phase 2 SA does not already exist for Lordello, Neustadter Standards Track Page 9 Internet Draft IPSec-VPN DOI for ISAKMP August, 2000 that flow, it triggers a phase 2 exchange. SG-B receives the phase 2 negotiation message with the phase 2 identities [10.1.*, 10.2.*]. Now SG-B has no means to tell if the intended IPSec SA is for the VR-1 or the VR-2 flows given that the VR Identification is not included in the phase 2 exchange and the existing phase 2 identities are identical. Notice that the interface connecting SG-A to SG-B (directly or through a cloud) belongs to a common context (ISP or network provider infrastructure) and not to a specific VR. Approach 3 leverages an existing ISP infrastructure and allows the ISP to easily interconnect customers offices in a secure way while also providing routing functionality to those customers. The following picture better illustrates the kind of environment that becomes possible with such an approach. In the picture Net 1, ..., N are customer networks with any private addressing scheme which are interconnected in a secure way via IPSec tunnels. The endpoints for those IPSec tunnels, the ISAKMP SA's are defined in the ISP network. In a way, the IPSec tunnels allow customer traffic to cross IP address realms in addition to security. private addr. public addresses private addr. <--------------><-------------------------------><--------------> +----------+ +----------+ +---+ | | | | +---+ |Net|----|VR-1 | | VR-1|----|Net| | | .. | ^ | | ^ | .. | | | 1 |----|i/f's | | | | i/f's|----| 1 | +---+ | | | | | | +---+ . | | | | | | . . | | | | | | . . | | | | | | . +---+ | | | | | | +---+ |Net|----|VR-N | | | | VR-N|----|Net| | | .. | ^ | | | | ^ | .. | | | N |----|i/f's | | | | | | i/f's|----| N | +---+ | | | | | | | | +---+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---------+ | | | | | | | |-----| Public |-----| | | | | VR-0| . | -or- | . |VR-0 | | (Public)| . | Shared | . |(Public) | | i/f's| . | ISP | . |i/f's | | |-----| Network |-----| | +----------+ +---------+ +----------+ Security Security Gateway A Gateway B Lordello, Neustadter Standards Track Page 10 Internet Draft IPSec-VPN DOI for ISAKMP August, 2000 6.1 Performance analysis for different approaches Consider a hypothetical ISP network made up of 'M' edge routers/security gateways (i.e. routers connected to end customers) providing VPN services to 'N' customers, where each customer is assigned a virtual router. To simplify the analysis lets assume that all customers (virtual routers) are present in all edge routers of the ISP network. +--------+ +--------+ C-1---|VR-1 | +------+ | VR-1|---C-1 C-2---|VR-2 | / \ | VR-2|---C-2 . | | / \ | | . . | R/SG-1 |======| Shared Core |==========| R/SG-M | . . | | \ / | | . C-N---|VR-N | \ / | VR-N|---C-N +--------+ +------+ +--------+ || || || +--------+ C-1-----|VR-1 | C-2-----|VR-2 | . | | . | R/SG-2 | . | | C-N-----|VR-N | +--------+ The following table shows the number of ISAKMP and IPSec SA's required to interconnect all customers networks together via IPSec tunnels, i.e. to create a full mesh of IPSec tunnels. +--------------------+--------------------+ | # of ISAKMP SA's | # of IPSec SA's | +--------------------+--------------------+--------------------+ | Approach 1 | N * (M - 1) | k * N * (M - 1) | | Approach 2 | N * (M - 1) | k * N * (M - 1) | | Approach 3 | M - 1 | k * N * (M - 1) | +--------------------+--------------------+--------------------+ Table 1: Number of SA for full mesh of IPSec tunnels The factor 'k' depends o the granularity desired for the flow and is irrelevant for our discussion. Table 2 below shows the additional number of ISAKMP and IPSec SA's that have to be created on each node for each one of the described approaches when a new virtual router (i.e., a new customer) is commissioned in the ISP network. Lordello, Neustadter Standards Track Page 11 Internet Draft IPSec-VPN DOI for ISAKMP August, 2000 +--------------------+--------------------+ | # of ISAKMP SA's | # of IPSec SA's | +--------------------+--------------------+--------------------+ | Approach 1 | M - 1 | k * (M - 1) | | Approach 2 | M - 1 | k * (M - 1) | | Approach 3 | 0 | k * (M - 1) | +--------------------+--------------------+--------------------+ Table 2: Additional SA for commissioning new VR Table 3 below shows the additional number of ISAKMP and IPSec SA's that have to be created on each node for each one of the described approaches when a new router/security gateway node is added to the ISP network. +--------------------+--------------------+ | # of ISAKMP SA's | # of IPSec SA's | +--------------------+--------------------+--------------------+ | Approach 1 | N | k * N | | Approach 2 | N | k * N | | Approach 3 | 1 | k * N | +--------------------+--------------------+--------------------+ Table 3: Additional SA for adding node to ISP network Approaches 1 and 2 have similar requirements in terms of number of SA's although they are quite distinct in other matters. However, it is not the intention of this draft to compare them any further. The previous tables show clearly the better scalability of approach 3. The number of ISAKMP SA's required upon commissioning a new VR or addition of a new node is invariant to both the number of nodes present in the ISP network and the number of VR's supported by each node. The number of ISAKMP SA's required limit the scalability of a security gateway for two reasons: o processing requirements on the node and traffic requirement on the network limit the number of ISAKMP SA's that can be performed per unit of time. o administration overhead required to setup and maintain multiple ISAKMP identities and their corresponding authentication information required for each one of the ISAKMP SA's. This is true for both shared-key and X.509 certificate authentication data. Besides the scalability factor, approach 2 would also be viewed as somewhat proprietary because there would be no interoperable way of associating a given ISAKMP SA to a particular VPN-ID. The ISAKMP identity would have to be used for that purpose with no clear rules. Lordello, Neustadter Standards Track Page 12 Internet Draft IPSec-VPN DOI for ISAKMP August, 2000 7. References [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [IPSECDOI] Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998. [VPNID] Fox, B., Gleeson, B., "Virtual Private Networks Identifier", RFC 2685, September 99. [VPNFRAME] Gleeson, Heinanen, Lin, Armitage, Malis, "A Framework for IP Based Virtual Private Networks", Work in Progress. [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [IKE] Harkins, D., and D. Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. 8. Security Considerations The identities specified in this document are exchanged during an IKE phase 2 exchange, therefore they are encrypted, authenticated and integrity protected. 9. IANA Considerations This draft requires that a new DOI value be allocated for use as the IPSec-VPN DOI for ISAKMP. Also new identity types specified in this draft require new values. These new values must not overlap with the values already assigned to the identity types defined by the IPSec DOI, as these new identity types are an addition to the ones specified in the IPsec DOI and not a replacement of them. No new number spaces are created for IANA administration. 10. Author's Addresses Claudio Lordello Siemens Address: 505 March Road Kanata, ON, Canada K2K 2N5 Phone: +1 (613) 271-7720 Email: claudio.lordello@tic.siemens.ca Lordello, Neustadter Standards Track Page 13 Internet Draft IPSec-VPN DOI for ISAKMP August, 2000 Udo Neustadter Siemens Address: 505 March Road Kanata, ON, Canada K2K 2N5 Phone: +1 (613) 271-7734 Email: udo.neustadter@tic.siemens.ca 11. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 12. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR Lordello, Neustadter Standards Track Page 14 Internet Draft IPSec-VPN DOI for ISAKMP August, 2000 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 13. Expiration Date This memo is filed as , and expires February 2001. 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Lordello, Neustadter Standards Track Page 15