< draft-ietf-ipsecme-ad-vpn-problem-04.txt   draft-ietf-ipsecme-ad-vpn-problem-05.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: August 25, 2013 HP Expires: October 11, 2013 HP
February 21, 2013 April 09, 2013
Auto Discovery VPN Problem Statement and Requirements Auto Discovery VPN Problem Statement and Requirements
draft-ietf-ipsecme-ad-vpn-problem-04 draft-ietf-ipsecme-ad-vpn-problem-05
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
or the endpoints may be behind NAT gateways, making static or the endpoints may be behind NAT gateways, making static
configuration impossible. The Auto Discovery VPN solution will configuration impossible. The Auto Discovery VPN solution will
address these requirements. 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 August 25, 2013. This Internet-Draft will expire on October 11, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Endpoint-to-Endpoint ADVPN Use Case . . . . . . . . . . . 5 2.1. Endpoint-to-Endpoint ADVPN Use Case . . . . . . . . . . . 4
2.2. Gateway-to-Gateway ADVPN Use Case . . . . . . . . . . . . 5 2.2. Gateway-to-Gateway ADVPN Use Case . . . . . . . . . . . . 4
2.3. Endpoint-to-Gateway ADVPN Use Case . . . . . . . . . . . . 6 2.3. Endpoint-to-Gateway ADVPN Use Case . . . . . . . . . . . 5
3. Inadequacy of Existing Solutions . . . . . . . . . . . . . . . 7 3. Inadequacy of Existing Solutions . . . . . . . . . . . . . . 6
3.1. Exhaustive Configuration . . . . . . . . . . . . . . . . . 7 3.1. Exhaustive Configuration . . . . . . . . . . . . . . . . 6
3.2. Star Topology . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Star Topology . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Proprietary Approaches . . . . . . . . . . . . . . . . . . 8 3.3. Proprietary Approaches . . . . . . . . . . . . . . . . . 7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Gateway and Endpoint Requirements . . . . . . . . . . . . 9 4.1. Gateway and Endpoint Requirements . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . . 15 8. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 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.
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 and the requirements on a solution to address deployments of IPsec and the requirements on a solution to address
skipping to change at page 3, line 41 skipping to change at page 3, line 21
1.1. Terminology 1.1. Terminology
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
topology, or one of the central points in the full mesh style VPN, topology, or one of the central points in the full mesh style VPN,
i.e. gateway where multiple other hubs or spokes connect to. The i.e. gateway where multiple other hubs or spokes connect to. The
hubs usually forward traffic coming from encrypted links to other hubs usually forward traffic coming from encrypted links to other
encrypted links, i.e. there are no devices connected to it in clear. encrypted links, i.e. there are no devices connected to it in clear.
Spoke - The edge devices in a star topology/ dynamic full mesh Spoke - The endpoint in a star topology/ dynamic full mesh topology,
topology, or gateway which forwards traffic from multiple cleartext or gateway which forwards traffic from multiple cleartext devices to
devices to other hubs or spokes, and some of those other devices are other hubs or spokes, and some of those other devices are connected
connected to it in clear (i.e. it encrypts data coming from cleartext to it in clear (i.e. it encrypts data coming from cleartext devices
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.
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,
skipping to change at page 7, line 18 skipping to change at page 6, line 18
none of these solutions is adequate, as described here. none of these solutions is adequate, as described here.
3.1. Exhaustive Configuration 3.1. Exhaustive Configuration
One simple solution is to configure all gateways and endpoints in One simple solution is to configure all gateways and endpoints in
advance with all the information needed to determine which gateway or advance with all the information needed to determine which gateway or
endpoint is optimal and to establish an SA with that gateway or endpoint is optimal and to establish an SA with that gateway or
endpoint. However, this solution does not scale in a large network endpoint. However, this solution does not scale in a large network
with hundreds of thousands of gateways and endpoints, especially when with hundreds of thousands of gateways and endpoints, especially when
multiple administrative domains are involved and things are rapidly multiple administrative domains are involved and things are rapidly
changing (e.g. mobile endpoints). Such a solution is also limited by changing (e.g. mobile endpoints). Such a solution is also limited
the smallest endpoint/ gateway, as the same exhaustive configuration by the smallest endpoint/ gateway, as the same exhaustive
is to be applied on all endpoints/ gateways. A more dynamic, secure configuration is to be applied on all endpoints/ gateways. A more
and scalable system for establishing SAs between gateways is needed. dynamic, secure and scalable system for establishing SAs between
gateways is needed.
3.2. Star Topology 3.2. Star Topology
The most common way to address a part of this this problem today is The most common way to address a part of this this problem today is
to use what has been termed a "star topology". In this case one or a to use what has been termed a "star topology". In this case one or a
few gateways are defined as "hub gateways", while the rest of the few gateways are defined as "hub gateways", while the rest of the
systems (whether endpoints or gateways) are defined as "spokes". The systems (whether endpoints or gateways) are defined as "spokes". The
spokes never connect to other spokes. They only open tunnels with spokes never connect to other spokes. They only open tunnels with
the hub gateways. Also for a large number of gateways in one the hub gateways. Also for a large number of gateways in one
administrative domain, one gateway may be defined as the hub, and the administrative domain, one gateway may be defined as the hub, and the
skipping to change at page 10, line 18 skipping to change at page 8, line 34
This requirement is driven by use case 2.1. ADVPN peers (especially This requirement is driven by use case 2.1. ADVPN peers (especially
spokes) become compromised fairly often. The compromise of one ADVPN spokes) become compromised fairly often. The compromise of one ADVPN
peer SHOULD NOT affect the security of other peers. peer SHOULD NOT affect the security of other peers.
6. Gateways SHOULD allow for seamless handoff of sessions in case 6. Gateways SHOULD allow for seamless handoff of sessions in case
endpoints are roaming, even if they cross policy boundaries. This endpoints are roaming, even if they cross policy boundaries. This
would mean the data traffic is minimally affected even as the handoff would mean the data traffic is minimally affected even as the handoff
happens. External factors like firewall, NAT boxes will not be happens. External factors like firewall, NAT boxes will not be
considered part of this solution. considered part of this solution.
Such endpoint roaming may affect not only the endpoint-to-endpoint SA
but also the relationship between the endpoints and gateways (such as
when an endpoint roams to a new network that is handled by a
different gateway).
This requirement is driven by use case 2.1. Today's endpoints are This requirement is driven by use case 2.1. Today's endpoints are
mobile and transition often between different networks (from 4G to mobile and transition often between different networks (from 4G to
WiFi and among various WiFi networks). WiFi and among various WiFi networks).
7. Gateways SHOULD allow for easy handoff of a session to another 7. Gateways SHOULD allow for easy handoff of a session to another
gateway, to optimize latency, bandwidth, load balancing, gateway, to optimize latency, bandwidth, load balancing,
availability, or other factors, based on policy. availability, or other factors, based on policy.
This ability to migrate traffic from one gateway to another applies
regardless of whether the gateways in question are hubs or spokes.
It even applies in the case where a gateway (hub or spoke) moves in
the network, as may happen with a vehicle-based network.
This requirement is driven by use case 2.3. This requirement is driven by use case 2.3.
8. Gateways and endpoints MUST have the capability to participate in 8. Gateways and endpoints MUST have the capability to participate in
an ADVPN even when they are located behind NAT boxes. However, in an ADVPN even when they are located behind NAT boxes. However, in
some cases they may be deployed in such a way that they will not be some cases they may be deployed in such a way that they will not be
fully reachable behind a NAT box. It is especially difficult to fully reachable behind a NAT box. It is especially difficult to
handle cases where the Hub is behind a NAT box. Where the two handle cases where the Hub is behind a NAT box. Where the two
endpoints are both behind separate NATs, communication between these endpoints are both behind separate NATs, communication between these
spokes SHOULD be supported using workarounds such as port forwarding spokes SHOULD be supported using workarounds such as port forwarding
by the NAT or detecting when two spokes are behind uncooperative NATs by the NAT or detecting when two spokes are behind uncooperative NATs
 End of changes. 12 change blocks. 
35 lines changed or deleted 46 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/