Internet Engineering Task Force (IETF) V. Manral Request for Comments: 7018 HP Category: Informational S. Hanna ISSN: 2070-1721 Juniper September 2013 Auto-Discovery VPN Problem Statement and Requirements
AbstractThis document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements for such a solution. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases, the IP addresses of endpoints change, or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto-Discovery VPN solution will address these requirements. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7018.
Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction ....................................................2 1.1. Terminology ................................................3 1.2. Conventions Used in This Document ..........................4 2. Use Cases .......................................................4 2.1. Use Case 1: Endpoint-to-Endpoint VPN .......................4 2.2. Use Case 2: Gateway-to-Gateway VPN .........................5 2.3. Use Case 3: Endpoint-to-Gateway VPN ........................6 3. Inadequacy of Existing Solutions ................................6 3.1. Exhaustive Configuration ...................................6 3.2. Star Topology ..............................................6 3.3. Proprietary Approaches .....................................7 4. Requirements ....................................................7 4.1. Gateway and Endpoint Requirements ..........................7 5. Security Considerations ........................................11 6. Acknowledgements ...............................................11 7. Normative References ...........................................12 RFC4301] is used in several different cases, including tunnel-mode site-to-site VPNs and remote access VPNs. Both tunneling modes for IPsec gateways and host-to-host transport mode are supported in this document. The subject of this document is the problem presented by large-scale deployments of IPsec and the requirements on a solution to address 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 two. The gateways and endpoints may belong to a single administrative domain or several domains with a trust relationship.
Section 4.4 of RFC 4301 describes the major IPsec databases needed for IPsec processing. It requires extensive configuration for each tunnel, so manually configuring a system of many gateways and endpoints becomes infeasible and inflexible. The difficulty is that a lot of configuration mentioned in RFC 4301 is required to set up a Security Association. The Internet Key Exchange Protocol (IKE) implementations need to know the identity and credentials of all possible peer systems, as well as the addresses of hosts and/or networks behind them. A simplified mechanism for dynamically establishing point-to-point tunnels is needed. Section 2 contains several use cases that motivate this effort.
Star Topology - Topology in which there is direct connectivity only between the hub and spoke, and where communication between the 2 spokes happens through the hub. Allied and Federated Environments - Environments where we have multiple different organizations that have close associations and need to connect to each other. Full-Mesh Topology - Topology in which there is direct connectivity between every spoke to every other spoke, without the traffic between the spokes having to be redirected through an intermediate hub device. Dynamic Full-Mesh Topology - Topology in which direct connections exist in a hub-and-spoke manner but dynamic connections are created/removed between the spokes on an as-needed basis. Security Association (SA) - Defined in [RFC4301]. RFC2119].
the call through remote gateways, as the remote gateways would add latency to the call, consume precious remote bandwidth, and increase overall costs. Such a use case also enables connectivity when both users are behind NAT gateways. Such a use case ought to allow for seamless connectivity even as endpoints roam and even if they are moving out from behind a NAT gateway, from behind one NAT gateway to behind another, or from a standalone position to behind a NAT gateway. In a star topology, when two endpoints communicate, they need a mechanism for authentication such that they do not expose themselves to impersonation by the other spoke endpoint.
There is also the case where Layer 3 Virtual Private Networks (L3VPNs) operate over IPsec tunnels. When two gateways communicate, they need to use a mechanism for authentication such that they do not expose themselves to the risk of impersonation by the other entities.
This solution, however, is complicated by the case where the spokes use dynamic IP addresses and DNS with dynamic updates needs to be used. It is also desired that there is minimal to no configuration on the hub as the number of spokes increases and new spokes are added and deleted randomly. Another problem with the star topology is that it creates a high load on the hub gateways, as well as on the connection between the spokes and the hub. This load impacts both processing power and network bandwidth. A single packet in the hub-and-spoke scenario can be encrypted and decrypted multiple times. It would be much preferable if these gateways and clients could initiate tunnels between them, bypassing the hub gateways. Additionally, the path bandwidth to these hub gateways may be lower than that of the path between the spokes. For example, two remote access users may be in the same building with high-speed WiFi (for example, at an IETF meeting). Channeling their conversation through the hub gateways of their respective employers seems extremely wasteful, given that a more optimal direct path exists. The challenge is to build large-scale IPsec-protected networks that can dynamically change with minimal administrative overhead.
Specifically, when evaluating potential proposals, we will compare them by looking at how many endpoints or gateways must be reconfigured when a new gateway or endpoint is added, removed, or changed and how substantial this reconfiguration is, in addition to the amount of static configuration required. This requirement is driven by use cases 1 and 2 and by the scaling limitations pointed out in Section 3.1. 2. ADVPN Peers MUST allow IPsec tunnels to be set up with other members of the ADVPN without any configuration changes, even when peer addresses get updated every time the device comes up. This implies that Security Policy Database (SPD) entries or other configuration based on a peer IP address will need to be automatically updated, avoided, or handled in some manner to avoid a need to manually update policy whenever an address changes. 3. In many cases, additional tunneling protocols (e.g., GRE) or routing protocols (e.g., OSPF) are run over the IPsec tunnels. Gateways MUST allow for the operation of tunneling and routing protocols operating over spoke-to-spoke IPsec tunnels with minimal or no configuration impact. The ADVPN solution SHOULD NOT increase the amount of information required to configure protocols running over IPsec tunnels. 4. In the full-mesh and dynamic full-mesh topologies, spokes MUST allow for direct communication with other spoke gateways and endpoints. In the star topology mode, direct communication between spokes MUST be disallowed. This requirement is driven by use cases 1 and 2 and by the limitations of a star topology as pointed out in Section 3.2. 5. ADVPN Peers MUST NOT have a way to get the long-term authentication credentials for any other ADVPN Peers. The compromise of an endpoint MUST NOT affect the security of communications between other ADVPN Peers. The compromise of a gateway SHOULD NOT affect the security of the communications between ADVPN Peers not associated with that gateway. This requirement is driven by use case 1. ADVPN Peers (especially spokes) become compromised fairly often. The compromise of one ADVPN Peer SHOULD NOT affect the security of other unrelated ADVPN Peers.
6. Gateways SHOULD allow for seamless handoff of sessions in cases where endpoints are roaming, even if they cross policy boundaries. This would mean the data traffic is minimally affected even as the handoff happens. External factors like firewalls and NAT boxes that will be part of the overall solution when ADVPN is deployed will not be 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 1. Today's endpoints are mobile and transition often between different networks (from 4G to WiFi and among various WiFi networks). 7. Gateways SHOULD allow for easy handoff of a session to another gateway, to optimize latency, bandwidth, load balancing, 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 3. 8. Gateways and endpoints MUST have the capability to participate 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 fully reachable behind a NAT box. It is especially difficult to handle cases where the hub is behind a NAT box. When the two endpoints are both behind separate NATs, communication between these spokes SHOULD be supported using workarounds such as port forwarding by the NAT or detecting when two spokes are behind uncooperative NATs, and using a hub in that case. This requirement is driven by use cases 1 and 2. Endpoints are often behind NATs, and gateways sometimes are. IPsec SHOULD continue to work seamlessly regardless, using ADVPN techniques whenever possible and providing graceful fallback to hub-and- spoke techniques as needed.
9. Changes such as establishing a new IPsec SA SHOULD be reportable and manageable. However, creating a MIB or other management technique is not within scope for this effort. This requirement is driven by manageability concerns for all the use cases, especially use case 2. As IPsec networks become more dynamic, management tools become more essential. 10. To support allied and federated environments, endpoints and gateways from different organizations SHOULD be able to connect to each other. This requirement is driven by demand for all the use cases in federated and allied environments. 11. The administrator of the ADVPN SHOULD allow for the configuration of a star, full-mesh, or partial full-mesh topology, based on which tunnels are allowed to be set up. This requirement is driven by demand for all the use cases in federated and allied environments. 12. The ADVPN solution SHOULD be able to scale for multicast traffic. This requirement is driven by use case 2, where the amount of rich media multicast traffic is increasing. 13. The ADVPN solution SHOULD allow for easy monitoring, logging, and reporting of the dynamic changes to help with troubleshooting such environments. This requirement is driven by demand for all the use cases in federated and allied environments. 14. There is also the case where L3VPNs operate over IPsec tunnels, for example, Provider-Edge-based VPNs. An ADVPN MUST support L3VPNs as applications protected by the IPsec tunnels. This requirement is driven by demand for all the use cases in federated and allied environments. 15. The ADVPN solution SHOULD allow the enforcement of per-peer QoS in both the star and full-mesh topologies. This requirement is driven by demand for all the use cases in federated and allied environments.
16. The ADVPN solution SHOULD take care of not letting the hub be a single point of failure. This requirement is driven by demand for all the use cases in federated and allied environments. RFC 4301, such as the Security Policy Database (SPD) or the Peer Authorization Database (PAD). RFC 4301 is silent about the way these databases are populated, and it is implied that these databases are static and preconfigured by a human. Allowing dynamic updates to these databases must be thought out carefully because it allows the protocol to alter the security policy that the IPsec endpoints implement. One obvious attack to watch out for is stealing traffic to a particular site. The IP address for www.example.com is 192.0.2.10. If we add an entry to an IPsec endpoint's SPD that says that traffic to 192.0.2.10 is protected through peer Gw-Mallory, then this allows Gw-Mallory to either pretend to be www.example.com or proxy and read all traffic to that site. Updates to this database require a clear trust model. Hubs can be a single point of failure that can cause loss of connectivity of the entire system; this can be a big security issue. Any ADVPN solution design should take care of these concerns.