< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/