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
<draft-lordello-ipsec-vpn-doi-00.txt>
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 <draft-lordello-ipsec-vpn-doi-00.txt>, 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