< draft-ietf-ipsecme-ad-vpn-problem-06.txt   draft-ietf-ipsecme-ad-vpn-problem-07.txt >
IPsecME Working Group S. Hanna IPsecME Working Group S. Hanna
Internet-Draft Juniper Internet-Draft Juniper
Intended status: Informational V. Manral Intended status: Informational V. Manral
Expires: October 24, 2013 HP Expires: December 05, 2013 HP
April 22, 2013 June 03, 2013
Auto Discovery VPN Problem Statement and Requirements Auto Discovery VPN Problem Statement and Requirements
draft-ietf-ipsecme-ad-vpn-problem-06 draft-ietf-ipsecme-ad-vpn-problem-07
Abstract Abstract
This document describes the problem of enabling a large number of This document describes the problem of enabling a large number of
systems to communicate directly using IPsec to protect the traffic systems to communicate directly using IPsec to protect the traffic
between them. It then expands on the requirements, for such a between them. It then expands on the requirements, for such a
solution. solution.
Manual configuration of all possible tunnels is too cumbersome in Manual configuration of all possible tunnels is too cumbersome in
many such cases. In other cases the IP address of endpoints change many such cases. In other cases the IP address of endpoints change
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 24, 2013. This Internet-Draft will expire on December 05, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions Used in This Document . . . . . . . . . . . . 4 1.2. Conventions Used in This Document . . . . . . . . . . . . 4
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Endpoint-to-Endpoint ADVPN Use Case . . . . . . . . . . . 4 2.1. Endpoint-to-Endpoint ADVPN Use Case . . . . . . . . . . . 4
2.2. Gateway-to-Gateway ADVPN Use Case . . . . . . . . . . . . 4 2.2. Gateway-to-Gateway ADVPN Use Case . . . . . . . . . . . . 5
2.3. Endpoint-to-Gateway ADVPN Use Case . . . . . . . . . . . 5 2.3. Endpoint-to-Gateway ADVPN Use Case . . . . . . . . . . . 5
3. Inadequacy of Existing Solutions . . . . . . . . . . . . . . 6 3. Inadequacy of Existing Solutions . . . . . . . . . . . . . . 6
3.1. Exhaustive Configuration . . . . . . . . . . . . . . . . 6 3.1. Exhaustive Configuration . . . . . . . . . . . . . . . . 6
3.2. Star Topology . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Star Topology . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Proprietary Approaches . . . . . . . . . . . . . . . . . 7 3.3. Proprietary Approaches . . . . . . . . . . . . . . . . . 7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Gateway and Endpoint Requirements . . . . . . . . . . . . 7 4.1. Gateway and Endpoint Requirements . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . 11 8. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
IPsec [RFC4301] is used in several different cases, including tunnel- IPsec [RFC4301] is used in several different cases, including tunnel-
mode site-to-site VPNs and Remote Access VPNs. Host to host mode site-to-site VPNs and Remote Access VPNs. Host to host
communication employing transport mode also exists, but is far less communication employing transport mode also exists, but is far less
commonly deployed. commonly deployed.
skipping to change at page 3, line 14 skipping to change at page 3, line 14
The difficulty is that all the configuration mentioned in RFC 4301 is The difficulty is that all the configuration mentioned in RFC 4301 is
not superfluous. IKE implementations need to know the identity and not superfluous. IKE implementations need to know the identity and
credentials of all possible peer systems, as well as the addresses of credentials of all possible peer systems, as well as the addresses of
hosts and/or networks behind them. A simplified mechanism for hosts and/or networks behind them. A simplified mechanism for
dynamically establishing point-to-point tunnels is needed. Section 2 dynamically establishing point-to-point tunnels is needed. Section 2
contains several use cases that motivate this effort. contains several use cases that motivate this effort.
1.1. Terminology 1.1. Terminology
ADVPN - Auto Discovery Virtual Private Network (ADVPN) is VPN
solution that enables a large number of systems to communicate
directly, with minimal configuration and operator intervention using
IPsec to protect communication between them.
Endpoint - A device that implements IPsec for its own traffic but Endpoint - A device that implements IPsec for its own traffic but
does not act as a gateway. does not act as a gateway.
Gateway - A network device that implements IPsec to protect traffic Gateway - A network device that implements IPsec to protect traffic
flowing through the device. flowing through the device.
Point-to-Point - Communication between two parties without active Point-to-Point - Communication between two parties without active
participation (e.g. encryption or decryption) by any other parties. participation (e.g. encryption or decryption) by any other parties.
Hub - The central point in a star topology/ dynamic full mesh Hub - The central point in a star topology/ dynamic full mesh
skipping to change at page 3, line 42 skipping to change at page 3, line 47
to it in clear (i.e. it encrypts data coming from cleartext devices to it in clear (i.e. it encrypts data coming from cleartext devices
and forwards it to the ADVPN). and forwards it to the ADVPN).
ADVPN Peer - any member of an ADVPN including gateways, endpoints, ADVPN Peer - any member of an ADVPN including gateways, endpoints,
hub or spoke. hub or spoke.
Star topology - This is the topology where there is direct Star topology - This is the topology where there is direct
connectivity only between the hub and spoke and communication between connectivity only between the hub and spoke and communication between
the 2 spokes happens through the hub. the 2 spokes happens through the hub.
Allied and Federated Environments - Environments where we have
multiple different organizations that have close association and need
to connect to each other.
Full Mesh topology - This is the topology where there is a direct Full Mesh topology - This is the topology where there is a direct
connectivity between every Spoke to every other Spoke directly, connectivity between every Spoke to every other Spoke directly,
without the traffic between the spokes having to be redirected without the traffic between the spokes having to be redirected
through an intermediate hub device. through an intermediate hub device.
Dynamic Full Mesh topology - This is the topology where direct Dynamic Full Mesh topology - This is the topology where direct
connections exist in a hub and spoke manner, but dynamic connections connections exist in a hub and spoke manner, but dynamic connections
are created/ removed between the spokes on a need basis. are created/ removed between the spokes on a need basis.
Security Association (SA) - Defined in [RFC4301]. Security Association (SA) - Defined in [RFC4301].
skipping to change at page 10, line 19 skipping to change at page 10, line 32
This requirement is driven by demand for all the use cases in This requirement is driven by demand for all the use cases in
federated and allied environments. federated and allied environments.
14. There is also the case when L3VPNs operate over IPsec Tunnels, 14. There is also the case when L3VPNs operate over IPsec Tunnels,
for example Provider Edge (PE) based VPN's. An ADVPN MUST support for example Provider Edge (PE) based VPN's. An ADVPN MUST support
L3VPN as an application protected by the IPsec Tunnels. L3VPN as an application protected by the IPsec Tunnels.
This requirement is driven by demand for all the use cases in This requirement is driven by demand for all the use cases in
federated and allied environments. federated and allied environments.
15. There ADVPN solution SHOULD allow the enforcement of per peer
QoS in both the Star as well as the Full Mesh topology.
This requirement is driven by demand for all the use cases in
federated and allied environments.
5. Security Considerations 5. Security Considerations
This is a Problem statement and requirement document for the ADVPN This is a Problem statement and requirement document for the ADVPN
solution, and in itself does not introduce any new security concerns. solution, and in itself does not introduce any new security concerns.
The solution to the problems presented in this draft may involve The solution to the problems presented in this draft may involve
dynamic updates to databases defined by RFC 4301, such as the dynamic updates to databases defined by RFC 4301, such as the
Security Policy Database (SPD) or the Peer Authorization Database Security Policy Database (SPD) or the Peer Authorization Database
(PAD). (PAD).
RFC 4301 is silent about the way these databases are populated, and RFC 4301 is silent about the way these databases are populated, and
 End of changes. 8 change blocks. 
7 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/