idnits 2.17.1 draft-ietf-ipsecme-p2p-vpn-problem-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 10, 2012) is 4307 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPsecME Working Group S. Hanna 3 Internet-Draft Juniper 4 Intended status: Informational V. Manral 5 Expires: January 11, 2013 HP 6 July 10, 2012 8 Auto Discovery VPN Problem Statement and Requirements 9 draft-ietf-ipsecme-p2p-vpn-problem-02 11 Abstract 13 This document describes the problem of enabling a large number of 14 systems to communicate directly using IPsec to protect the traffic 15 between them. It them expands on the requirements, for such a 16 solution. 18 Manual configuration of all possible tunnels is too cumbersome in 19 many such cases. In other cases the IP address of end points change 20 or the end points may be behind NAT gateways, making static 21 configuration impossible. The Auto Discovery VPN solution is 22 chartered to address these requirements. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 11, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Conventions Used in This Document . . . . . . . . . . . . 4 61 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.1. Endpoint-to-Endpoint P2P VPN Use Case . . . . . . . . . . 5 63 2.2. Gateway-to-Gateway AD VPN Use Case . . . . . . . . . . . . 5 64 2.3. Endpoint-to-Gateway AD VPN Use Case . . . . . . . . . . . 6 65 3. Inadequacy of Existing Solutions . . . . . . . . . . . . . . . 7 66 3.1. Exhaustive Configuration . . . . . . . . . . . . . . . . . 7 67 3.2. Star Topology . . . . . . . . . . . . . . . . . . . . . . 7 68 3.3. Proprietary Approaches . . . . . . . . . . . . . . . . . . 8 69 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.1. Gateway and End Point Requirements . . . . . . . . . . . . 9 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 74 8. Normative References . . . . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 77 1. Introduction 79 IPsec [RFC4301] is used in several different cases, including tunnel- 80 mode site-to-site VPNs and Remote Access VPNs. Host to host 81 communication employing transport mode also exists, but is far less 82 commonly deployed. 84 The subject of this document is the problem presented by large scale 85 deployments of IPsec and the requirements on a solution to address 86 the problem. These may be a large collection of VPN gateways 87 connecting various sites, a large number of remote endpoints 88 connecting to a number of gateways or to each other, or a mix of the 89 two. The gateways and endpoints may belong to a single 90 administrative domain or several domains with a trust relationship. 92 Section 4.4 of RFC 4301 describes the major IPsec databases needed 93 for IPsec processing. It requires an extensive configuration for 94 each tunnel, so manually configuring a system of many gateways and 95 endpoints becomes infeasible and inflexible. 97 The difficulty is that all the configuration mentioned in RFC 4301 is 98 not superfluous. IKE implementations need to know the identity and 99 credentials of all possible peer systems, as well as the addresses of 100 hosts and/or networks behind them. A simplified mechanism for 101 dynamically establishing point-to-point tunnels is needed. Section 2 102 contains several use cases that motivate this effort. 104 1.1. Terminology 106 Endpoint - A device that implements IPsec for its own traffic but 107 does not act as a gateway. 109 Gateway - A network device that implements IPsec to protect traffic 110 flowing through the device. 112 Point-to-Point - Direct communication between two parties without 113 active participation (e.g. encryption or decryption) by any other 114 parties. 116 Hub - The central point in a star topology, generally implemented in 117 a gateway 119 Spoke - The edge devices in a star topology, implemented in endpoints 120 or gateways 122 Security Association (SA) - Defined in [RFC4301]. 124 1.2. Conventions Used in This Document 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 2. Use Cases 132 This section presents the key use cases for large-scale point-to- 133 point VPN. 135 In all of these use cases, the participants (endpoints and gateways) 136 may be from a single organization or from multiple organizations with 137 an established trust relationship. When multiple organizations are 138 involved, products from multiple vendors are employed so open 139 standards are needed to provide interoperability. Establishing 140 communications between participants with no established trust 141 relationship is out of scope for this effort. 143 2.1. Endpoint-to-Endpoint P2P VPN Use Case 145 Two endpoints wish to communicate securely via a direct, point-to- 146 point SA. 148 The need for secure endpoint to endpoint communications is often 149 driven by a need to employ high-bandwidth, low latency local 150 connectivity instead of using slow, expensive links to remote 151 gateways. For example, two users in close proximity may wish to 152 place a direct, secure video or voice call without needing to send 153 the call through remote gateways, which would add latency to the 154 call, consume precious remote bandwidth, and increase overall costs. 155 Such a usecase also enables connectivity when both endpoints are 156 behind NAT gateways. Such usecase should allow for seamless 157 connectivity even as Endpoints roam, in behing or away from gateways. 159 In a hub and spoke topology when two end-points communicate, they 160 must use a mechanism for authentication, such that they do not expose 161 them to impersonation by the other spoke endpoint. 163 2.2. Gateway-to-Gateway AD VPN Use Case 165 A typical Enterprise traffic model is Hub and Spoke, with the 166 Gateways connecting to each other using IPsec tunnels. 168 However for the voice and other rich media traffic that occupies a 169 lot of bandwidth and the traffic tromboning to the Hub can create 170 traffic bottlenecks on the Hub and can lead to a increase cost. It 171 is for this purpose Spoke-to-Spoke tunnels are dynamically created 172 and torn-down. 174 The Spoke Gateways can themselves come up and down, getting different 175 IP addresses in the process, making th static configuration 176 impossible. 178 Also for the reasons of cost and manual error reduction, it is 179 desired there be minimal or even no configuration on the Hub as a new 180 Spoke Router is added or removed. 182 In a hub and spoke topology when two spoke gateways communicate, they 183 must use a mechanism for authentication, such that they do not expose 184 them to impersonation by the other gateways spoke. 186 2.3. Endpoint-to-Gateway AD VPN Use Case 188 An endpoint should be able to use the most efficient gateway as it 189 roams in the internet. 191 A mobile user roaming on the Internet may connect to a gateway, which 192 because of roaming is no longer the most efficient gateway to use 193 (reasons could be cost/ efficiency/ latency or some other factor). 194 The mobile user should be able to discover and then connect to the 195 current most efficient gateway without having to reinitiate the 196 connection. 198 3. Inadequacy of Existing Solutions 200 Several solutions exist for the problems described above. However, 201 none of these solutions is adequate, as described here. 203 3.1. Exhaustive Configuration 205 One simple solution is to configure all gateways and endpoints in 206 advance with all the information needed to determine which gateway or 207 endpoint is optimal and to establish an SA with that gateway or 208 endpoint. However, this solution does not scale in a large network 209 with hundreds of thousands of gateways and endpoints, especially when 210 multiple organizations are involved and things are rapidly changing 211 (e.g. mobile endpoints). Such a solution is also limited by the 212 smallest endpoint/ gateway, as the same exhaustive configuration is 213 to be applied on all endpoints/ gateways. A more dynamic, secure and 214 scalable system for establishing SAs between gateways is needed. 216 3.2. Star Topology 218 The most common way to address this problem today is to use what has 219 been termed a "star topology". In this case one or a few gateways 220 are defined as "Hub gateways", while the rest of the systems (whether 221 endpoints or gateways) are defined as "spokes". The spokes never 222 connect to other spokes. They only open tunnels with the core 223 gateways. Also for a large number of gateways in one administrative 224 domain, one gateway may be defined as the core, and the rest of the 225 gateways and remote access clients connect only to that gateway. 227 This solution however does not work when the spokes, get dynamic IP 228 address which the "core gateways" cannot be configured with. It is 229 also desired that there is minimal to no configuration on the Hub as 230 the number of spokes increases and new spokes are added and deleted 231 randomly. 233 Another problem with stars and trunks is that it creates a high load 234 on the core gateways as well as on the trunk connection. This load 235 is both in processing power and in network bandwidth. A single 236 packet in the trunk scenario can be encrypted and decrypted three 237 times. It would be much preferable if these gateways and clients 238 could initiate tunnels between them, bypassing the core gateways. 239 Additionally, the path bandwidth to these core gateways may be lower 240 than that of the path between the satellites. For example, two 241 remote access users may be in the same building with high-speed wifi 242 (for example, at an IETF meeting). Channeling their conversation 243 through the core gateways of their respective employers seems 244 extremely wasteful, as well as having lower bandwidth. 246 The challenge is to build a large scale, IPsec protected networks 247 that can dynamically change with minimum administrative overhead. 249 3.3. Proprietary Approaches 251 Several vendors offer proprietary solutions to these problems. 252 However, these solutions offer no interoperability between equipment 253 from one vendor and another. This means that they are generally 254 restricted to use within one organization, and it is harder to move 255 off such solutions as the features are not standardized. Besides 256 multiple organizations cannot be expected to all choose the same 257 equipment vendor. 259 4. Requirements 261 This section is currently being updated and hence under flux. 263 4.1. Gateway and End Point Requirements 265 1. For any network topology (whether Hub-and-Spoke or Full Mesh) 266 Gateways/ end points MUST allow for minimal configuration changes 267 when a new Gateway or end-point is added, removed or changed. The 268 solution should allow for such configuration on a global basis. 270 2. Gateways/ end-points MUST allow IPsec Tunnels to be setup without 271 any configuration changes, even as peer addresses gets updated every 272 time the device comes up. 274 3. Gateways MUST allow tunnel binding, such that applications like 275 Routing using the tunnels can work seamlessly without any updates to 276 the higher level application configuration i.e. OSPF configuration. 278 4. In a Hub-and-Spoke topology, Spoke Gateways/ en-points MUST allow 279 for direct communication with other Spoke Gateways/ end-points, using 280 authentication that does not expose them to other Gateway Spoke. 282 5.Gateways SHOULD allow for easy handoff of sessions in case end- 283 points are roamining and cross policy boundaries. 285 6. Gateways SHOULD allow for easy handoff of a session to another 286 gateway, to optimize latency, bandwidth or other factor, based on 287 policy. 289 7. Gateways/ End-points MUST be able to work, behing NAT boxes. 291 5. Security Considerations 293 The solution to the problems presented in this draft may involve 294 dynamic updates to databases defined by RFC 4301, such as the 295 Security Policy Database (SPD) or the Peer Authorization Database 296 (PAD). 298 RFC 4301 is silent about the way these databases are populated, and 299 it is implied that these databases are static and pre-configured by a 300 human. Allowing dynamic updates to these databases must be thought 301 out carefully, because it allows the protocol to alter the security 302 policy that the IPsec endpoints implement. 304 One obvious attack to watch out for is stealing traffic to a 305 particular site. The IP address for www.example.com is 192.0.2.10. 306 If we add an entry to an IPsec endpoint's SPD that says that traffic 307 to 192.0.2.10 is protected through peer Gw-Mallory, then this allows 308 Gw-Mallory to either pretend to be www.example.com or to proxy and 309 read all traffic to that site. Updates to this database requires a 310 clear trust model. 312 More to be added. 314 6. IANA Considerations 316 No actions are required from IANA for this informational document. 318 7. Acknowledgements 320 Many people have contributed to the development of this problem 321 statement and many more will probably do so before we are done with 322 it. While we cannot thank all contributors, some have played an 323 especially prominent role. Yoav Nir, Yaron Scheffer, Jorge Coronel 324 Mendoza, Chris Ulliott, and John Veizades wrote the document upon 325 which this draft was based. Geoffrey Huang, Suresh Melam, Praveen 326 Sathyanarayan, Andreas Steffen, and Brian Weis provided essential 327 input. 329 8. Normative References 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, March 1997. 334 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 335 Internet Protocol", RFC 4301, December 2005. 337 Authors' Addresses 339 Steve Hanna 340 Juniper Networks, Inc. 341 1194 N. Mathilda Ave. 342 Sunnyvale, CA 94089 343 USA 345 Email: shanna@juniper.net 347 Vishwas Manral 348 Hewlett-Packard Co. 349 19111 Pruneridge Ave. 350 Cupertino, CA 95113 351 USA 353 Email: vishwas.manral@hp.com