VPN-ID-Enhanced IPSec-VPN DOI for ISAKMP
draft-lordello-ipsec-vpn-doi-00
Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
---|---|---|---|
Authors | Claudio Lordello , Udo Neustadter | ||
Last updated | 2000-08-21 | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Expired | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
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 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.
Authors
Claudio Lordello
Udo Neustadter
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)