@techreport{lordello-ipsec-vpn-doi-00, number = {draft-lordello-ipsec-vpn-doi-00}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-lordello-ipsec-vpn-doi/00/}, author = {Claudio Lordello and Udo Neustadter}, title = {{VPN-ID-Enhanced IPSec-VPN DOI for ISAKMP}}, pagetotal = 15, year = 2000, month = aug, day = 21, 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.}, }