draft-ietf-ipsecme-p2p-vpn-problem-01.txt | draft-ietf-ipsecme-p2p-vpn-problem-02.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: November 26, 2012 HP | Expires: January 11, 2013 HP | |||
May 25, 2012 | July 10, 2012 | |||
Auto Discovery VPN Problem Statement | Auto Discovery VPN Problem Statement and Requirements | |||
draft-ietf-ipsecme-p2p-vpn-problem-01 | draft-ietf-ipsecme-p2p-vpn-problem-02 | |||
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. Manual configuration of all possible tunnels is too | between them. It them expands on the requirements, for such a | |||
cumbersome in many such cases. In other cases the IP address of end | solution. | |||
points change or the end points may be behind NAT gateways, making | ||||
static configuration impossible. The Auto Discovery VPN solution is | Manual configuration of all possible tunnels is too cumbersome in | |||
many such cases. In other cases the IP address of end points change | ||||
or the end points may be behind NAT gateways, making static | ||||
configuration impossible. The Auto Discovery VPN solution is | ||||
chartered to address these requirements. | chartered to address these requirements. | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 November 26, 2012. | This Internet-Draft will expire on January 11, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2012 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 22 | skipping to change at page 2, line 25 | |||
1.2. Conventions Used in This Document . . . . . . . . . . . . 4 | 1.2. Conventions Used in This Document . . . . . . . . . . . . 4 | |||
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2.1. Endpoint-to-Endpoint P2P VPN Use Case . . . . . . . . . . 5 | 2.1. Endpoint-to-Endpoint P2P VPN Use Case . . . . . . . . . . 5 | |||
2.2. Gateway-to-Gateway AD VPN Use Case . . . . . . . . . . . . 5 | 2.2. Gateway-to-Gateway AD VPN Use Case . . . . . . . . . . . . 5 | |||
2.3. Endpoint-to-Gateway AD VPN Use Case . . . . . . . . . . . 6 | 2.3. Endpoint-to-Gateway AD VPN Use Case . . . . . . . . . . . 6 | |||
3. Inadequacy of Existing Solutions . . . . . . . . . . . . . . . 7 | 3. Inadequacy of Existing Solutions . . . . . . . . . . . . . . . 7 | |||
3.1. Exhaustive Configuration . . . . . . . . . . . . . . . . . 7 | 3.1. Exhaustive Configuration . . . . . . . . . . . . . . . . . 7 | |||
3.2. Star Topology . . . . . . . . . . . . . . . . . . . . . . 7 | 3.2. Star Topology . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.3. Proprietary Approaches . . . . . . . . . . . . . . . . . . 8 | 3.3. Proprietary Approaches . . . . . . . . . . . . . . . . . . 8 | |||
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.1. Gateway and End Point Requirements . . . . . . . . . . . . 9 | ||||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
8. Normative References . . . . . . . . . . . . . . . . . . . . . 13 | 8. Normative References . . . . . . . . . . . . . . . . . . . . . 13 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
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. | |||
The subject of this document is the problem presented by large scale | The subject of this document is the problem presented by large scale | |||
deployments of IPsec. These may be a large collection of VPN | deployments of IPsec and the requirements on a solution to address | |||
gateways connecting various sites, a large number of remote endpoints | the problem. These may be a large collection of VPN gateways | |||
connecting various sites, a large number of remote endpoints | ||||
connecting to a number of gateways or to each other, or a mix of the | connecting to a number of gateways or to each other, or a mix of the | |||
two. The gateways and endpoints may belong to a single | two. The gateways and endpoints may belong to a single | |||
administrative domain or several domains with a trust relationship. | administrative domain or several domains with a trust relationship. | |||
Section 4.4 of RFC 4301 describes the major IPsec databases needed | Section 4.4 of RFC 4301 describes the major IPsec databases needed | |||
for IPsec processing. It requires an extensive configuration for | for IPsec processing. It requires an extensive configuration for | |||
each tunnel, so manually configuring a system of many gateways and | each tunnel, so manually configuring a system of many gateways and | |||
endpoints becomes infeasible and inflexible. | endpoints becomes infeasible and inflexible. | |||
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 | |||
Endpoint - A host that implements IPsec for its own traffic but does | Endpoint - A device that implements IPsec for its own traffic but | |||
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 - Direct communication between two parties without | Point-to-Point - Direct communication between two parties without | |||
active participation (e.g. encryption or decryption) by any other | active participation (e.g. encryption or decryption) by any other | |||
parties. | parties. | |||
Hub - The central point in a star topology, generally implemented in | Hub - The central point in a star topology, generally implemented in | |||
a gateway | a gateway | |||
skipping to change at page 9, line 7 | skipping to change at page 9, line 7 | |||
Several vendors offer proprietary solutions to these problems. | Several vendors offer proprietary solutions to these problems. | |||
However, these solutions offer no interoperability between equipment | However, these solutions offer no interoperability between equipment | |||
from one vendor and another. This means that they are generally | from one vendor and another. This means that they are generally | |||
restricted to use within one organization, and it is harder to move | restricted to use within one organization, and it is harder to move | |||
off such solutions as the features are not standardized. Besides | off such solutions as the features are not standardized. Besides | |||
multiple organizations cannot be expected to all choose the same | multiple organizations cannot be expected to all choose the same | |||
equipment vendor. | equipment vendor. | |||
4. Requirements | 4. Requirements | |||
This section will be completed when the use cases are agreed upon. | This section is currently being updated and hence under flux. | |||
4.1. Gateway and End Point Requirements | ||||
1. For any network topology (whether Hub-and-Spoke or Full Mesh) | ||||
Gateways/ end points MUST allow for minimal configuration changes | ||||
when a new Gateway or end-point is added, removed or changed. The | ||||
solution should allow for such configuration on a global basis. | ||||
2. Gateways/ end-points MUST allow IPsec Tunnels to be setup without | ||||
any configuration changes, even as peer addresses gets updated every | ||||
time the device comes up. | ||||
3. Gateways MUST allow tunnel binding, such that applications like | ||||
Routing using the tunnels can work seamlessly without any updates to | ||||
the higher level application configuration i.e. OSPF configuration. | ||||
4. In a Hub-and-Spoke topology, Spoke Gateways/ en-points MUST allow | ||||
for direct communication with other Spoke Gateways/ end-points, using | ||||
authentication that does not expose them to other Gateway Spoke. | ||||
5.Gateways SHOULD allow for easy handoff of sessions in case end- | ||||
points are roamining and cross policy boundaries. | ||||
6. Gateways SHOULD allow for easy handoff of a session to another | ||||
gateway, to optimize latency, bandwidth or other factor, based on | ||||
policy. | ||||
7. Gateways/ End-points MUST be able to work, behing NAT boxes. | ||||
5. Security Considerations | 5. Security Considerations | |||
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 | |||
it is implied that these databases are static and pre-configured by a | it is implied that these databases are static and pre-configured by a | |||
End of changes. 8 change blocks. | ||||
14 lines changed or deleted | 47 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |