idnits 2.17.1 draft-ietf-ipsecme-ad-vpn-problem-04.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 16 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 (February 21, 2013) is 4072 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: August 25, 2013 HP 6 February 21, 2013 8 Auto Discovery VPN Problem Statement and Requirements 9 draft-ietf-ipsecme-ad-vpn-problem-04 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 then 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 endpoints change 20 or the endpoints may be behind NAT gateways, making static 21 configuration impossible. The Auto Discovery VPN solution will 22 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 August 25, 2013. 41 Copyright Notice 43 Copyright (c) 2013 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 ADVPN Use Case . . . . . . . . . . . 5 63 2.2. Gateway-to-Gateway ADVPN Use Case . . . . . . . . . . . . 5 64 2.3. Endpoint-to-Gateway ADVPN 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 Endpoint Requirements . . . . . . . . . . . . 9 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 74 8. Normative References . . . . . . . . . . . . . . . . . . . . . 15 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 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 - Communication between two parties without active 113 participation (e.g. encryption or decryption) by any other parties. 115 Hub - The central point in a star topology/ dynamic full mesh 116 topology, or one of the central points in the full mesh style VPN, 117 i.e. gateway where multiple other hubs or spokes connect to. The 118 hubs usually forward traffic coming from encrypted links to other 119 encrypted links, i.e. there are no devices connected to it in clear. 121 Spoke - The edge devices in a star topology/ dynamic full mesh 122 topology, or gateway which forwards traffic from multiple cleartext 123 devices to other hubs or spokes, and some of those other devices are 124 connected to it in clear (i.e. it encrypts data coming from cleartext 125 devices and forwards it to the ADVPN). 127 ADVPN Peer - any member of an ADVPN including gateways, endpoints, 128 hub or spoke. 130 Star topology - This is the topology where there is direct 131 connectivity only between the hub and spoke and communication between 132 the 2 spokes happens through the hub. 134 Full Mesh topology - This is the topology where there is a direct 135 connectivity between every Spoke to every other Spoke directly, 136 without the traffic between the spokes having to be redirected 137 through an intermediate hub device. 139 Dynamic Full Mesh topology - This is the topology where direct 140 connections exist in a hub and spoke manner, but dynamic connections 141 are created/ removed between the spokes on a need basis. 143 Security Association (SA) - Defined in [RFC4301]. 145 1.2. Conventions Used in This Document 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 2. Use Cases 153 This section presents the key use cases for large-scale point-to- 154 point VPN. 156 In all of these use cases, the participants (endpoints and gateways) 157 may be from a single organization (administrative domain) or from 158 multiple organizations with an established trust relationship. When 159 multiple organizations are involved, products from multiple vendors 160 are employed so open standards are needed to provide 161 interoperability. Establishing communications between participants 162 with no established trust relationship is out of scope for this 163 effort. 165 2.1. Endpoint-to-Endpoint ADVPN Use Case 167 Two endpoints wish to communicate securely via a point-to-point 168 Security Association (SA). 170 The need for secure endpoint to endpoint communications is often 171 driven by a need to employ high-bandwidth, low latency local 172 connectivity instead of using slow, expensive links to remote 173 gateways. For example, two users in close proximity may wish to 174 place a direct, secure video or voice call without needing to send 175 the call through remote gateways, which would add latency to the 176 call, consume precious remote bandwidth, and increase overall costs. 177 Such a use case also enables connectivity when both behind NAT 178 gateways. Such a use case ought to allow for seamless connectivity 179 even as endpoints roam, even if they are moving out from behind a NAT 180 gateway, from behind one NAT gateway to behind another, or from a 181 standalone position to behind a NAT gateway. 183 In a star topology when two endpoints communicate, they need a 184 mechanism for authentication, such that they do not expose themselves 185 to impersonation by the other spoke endpoint. 187 2.2. Gateway-to-Gateway ADVPN Use Case 189 A typical Enterprise traffic model follows a star topology, with the 190 gateways connecting to each other using IPsec tunnels. 192 However for voice and other rich media traffic that requires a lot of 193 bandwidth or is performance sensitive, the traffic tromboning to the 194 hub can create traffic bottlenecks on the hub and can lead to an 195 increase in cost. A fully meshed solution would make best use of the 196 available network capacity and performance but the deployment of a 197 fully meshed solution involves considerable configuration, especially 198 when a large number of nodes are involved. It is for this purpose 199 spoke-to-spoke tunnels are dynamically created and torn-down. For 200 the reasons of cost and manual error reduction, it is desired that 201 there be minimal configuration on each gateway. 203 The solution ought to work in cases where the endpoints are in 204 different administrative domains, albeit, ones that have an existing 205 trust relationship (for example two organisations who are 206 collaborating on a project, they may wish to join their networks, 207 whilst retaining independent control over configuration). It is 208 highly desirable that the solution works for the star, full mesh as 209 well as dynamic full mesh topology. 211 The solution ought to also address the case where gateways use 212 dynamic IP addresses. 214 Additionally, the routing implications of gateway-to-gateway 215 communication need to be addressed. In the simple case, selectors 216 provide sufficient information for a gateway to forward traffic 217 appropriately. In other cases, additional tunneling (e.g., Generic 218 Routing Encapsulation - GRE) and routing (e.g., Open Shortest Path 219 First - OSPF) protocols are run over IPsec tunnels, and the 220 configuration impact on those protocols needs to be considered. 221 There is also the case when Layer-3 Virtual Private Networks (L3VPNs) 222 operate over IPsec Tunnels. 224 When two gateways communicate, they need to use a mechanism for 225 authentication, such that they do not expose themselves to the risk 226 of impersonation by the other entities. 228 2.3. Endpoint-to-Gateway ADVPN Use Case 230 An endpoint ought to be able to use the most efficient gateway as it 231 roams in the internet. 233 A mobile user roaming on the Internet may connect to a gateway, which 234 because of roaming is no longer the most efficient gateway to use 235 (reasons could be cost/ efficiency/ latency or some other factor). 236 The mobile user ought to be able to discover and then connect to the 237 current most efficient gateway without having to reinitiate the 238 connection. 240 3. Inadequacy of Existing Solutions 242 Several solutions exist for the problems described above. However, 243 none of these solutions is adequate, as described here. 245 3.1. Exhaustive Configuration 247 One simple solution is to configure all gateways and endpoints in 248 advance with all the information needed to determine which gateway or 249 endpoint is optimal and to establish an SA with that gateway or 250 endpoint. However, this solution does not scale in a large network 251 with hundreds of thousands of gateways and endpoints, especially when 252 multiple administrative domains are involved and things are rapidly 253 changing (e.g. mobile endpoints). Such a solution is also limited by 254 the smallest endpoint/ gateway, as the same exhaustive configuration 255 is to be applied on all endpoints/ gateways. A more dynamic, secure 256 and scalable system for establishing SAs between gateways is needed. 258 3.2. Star Topology 260 The most common way to address a part of this this problem today is 261 to use what has been termed a "star topology". In this case one or a 262 few gateways are defined as "hub gateways", while the rest of the 263 systems (whether endpoints or gateways) are defined as "spokes". The 264 spokes never connect to other spokes. They only open tunnels with 265 the hub gateways. Also for a large number of gateways in one 266 administrative domain, one gateway may be defined as the hub, and the 267 rest of the gateways and remote access clients connect only to that 268 gateway. 270 This solution however is complicated by the case when the spokes use 271 dynamic IP addresses and DNS with dynamic updates needs to be used. 272 It is also desired that there is minimal to no configuration on the 273 hub as the number of spokes increases and new spokes are added and 274 deleted randomly. 276 Another problem with the star topology is that it creates a high load 277 on the hub gateways as well as on the connection between the spokes 278 and the hub. This load is both in processing power and in network 279 bandwidth. A single packet in the hub-and-spoke scenario can be 280 encrypted and decrypted multiple times. It would be much preferable 281 if these gateways and clients could initiate tunnels between them, 282 bypassing the hub gateways. Additionally, the path bandwidth to 283 these hub gateways may be lower than that of the path between the 284 spokes. For example, two remote access users may be in the same 285 building with high-speed wifi (for example, at an IETF meeting). 286 Channeling their conversation through the hub gateways of their 287 respective employers seems extremely wasteful, as well as having 288 lower bandwidth. 290 The challenge is to build a large scale, IPsec protected networks 291 that can dynamically change with minimum administrative overhead. 293 3.3. Proprietary Approaches 295 Several vendors offer proprietary solutions to these problems. 296 However, these solutions offer no interoperability between equipment 297 from one vendor and another. This means that they are generally 298 restricted to use within one organization, and it is harder to move 299 off such solutions as the features are not standardized. Besides 300 multiple organizations cannot be expected to all choose the same 301 equipment vendor. 303 4. Requirements 305 This section defines the requirements, on which the solution will be 306 based. 308 4.1. Gateway and Endpoint Requirements 310 1. For any network topology (star, full mesh and dynamic full mesh) 311 gateways and endpoints SHOULD minimize configuration changes when a 312 new gateway or endpoint is added, removed or changed. Adding or 313 removing a spoke in the topology MUST NOT require configuration 314 changes to the hubs other than where the spoke was connected to and 315 SHOULD NOT require configuration changes to the hub the spoke was 316 connected to. The changes also MUST NOT require configuration 317 changes in other spokes. 319 Specifically, when evaluating potential proposals, we will compare 320 them by looking at how many endpoints or gateways must be 321 reconfigured when a new gateway or endpoint is added, removed, or 322 changed and how substantial this reconfiguration is, besides the 323 amount of static configuration required. 325 This requirement is driven by use cases 2.1 and 2.2 and by the 326 scaling limitations pointed out in section 3.1. 328 2. ADVPN peers MUST allow IPsec Tunnels to be setup with other 329 members of the ADVPN without any configuration changes, even when 330 peer addresses get updated every time the device comes up. This 331 implies that SPD entries or other configuration based on peer IP 332 address will need to be automatically updated, avoided, or handled in 333 some manner to avoid a need to manually update policy whenever an 334 address changes. 336 3. In many cases additional tunneling protocols (e.g. GRE) or 337 Routing protocols (e.g. OSPF) are run over the IPsec tunnels. 338 Gateways MUST allow for the operation of tunneling and Routing 339 protocols operating over spoke-to-spoke IPsec Tunnels with minimal or 340 no, configuration impact. The ADVPN solution SHOULD NOT increase the 341 amount of information required to configure protocols running over 342 IPsec tunnels. 344 4. In the full mesh and dynamic full mesh topology, Spokes MUST 345 allow for direct communication with other spoke gateways and 346 endpoints. In the star topology mode, direct communication between 347 spokes MUST be disallowed. 349 This requirement is driven by use cases 2.1 and 2.2 and by the 350 limitations of a star topology pointed out in section 3.2. 352 5. One ADVPN peer MUST NOT be able to impersonate another ADVPN 353 peer. 355 This requirement is driven by use case 2.1. ADVPN peers (especially 356 spokes) become compromised fairly often. The compromise of one ADVPN 357 peer SHOULD NOT affect the security of other peers. 359 6. Gateways SHOULD allow for seamless handoff of sessions in case 360 endpoints are roaming, even if they cross policy boundaries. This 361 would mean the data traffic is minimally affected even as the handoff 362 happens. External factors like firewall, NAT boxes will not be 363 considered part of this solution. 365 This requirement is driven by use case 2.1. Today's endpoints are 366 mobile and transition often between different networks (from 4G to 367 WiFi and among various WiFi networks). 369 7. Gateways SHOULD allow for easy handoff of a session to another 370 gateway, to optimize latency, bandwidth, load balancing, 371 availability, or other factors, based on policy. 373 This requirement is driven by use case 2.3. 375 8. Gateways and endpoints MUST have the capability to participate in 376 an ADVPN even when they are located behind NAT boxes. However, in 377 some cases they may be deployed in such a way that they will not be 378 fully reachable behind a NAT box. It is especially difficult to 379 handle cases where the Hub is behind a NAT box. Where the two 380 endpoints are both behind separate NATs, communication between these 381 spokes SHOULD be supported using workarounds such as port forwarding 382 by the NAT or detecting when two spokes are behind uncooperative NATs 383 and using a hub in that case. 385 This requirement is driven by use cases 2.1 and 2.2. Endpoints are 386 often behind NATs and gateways sometimes are. IPsec SHOULD continue 387 to work seamlessly regardless, using ADVPN techniques whenever 388 possible and providing graceful fallback to hub and spoke techniques 389 as needed. 391 9. Changes such as establishing a new IPsec SA SHOULD be reportable 392 and manageable. However, creating a MIB or other management 393 technique is not within scope for this effort. 395 This requirement is driven by manageability concerns for all the use 396 cases, especially use case 2.2. As IPsec networks become more 397 dynamic, management tools become more essential. 399 10. To support allied and federated environments, endpoints and 400 gateways from different organizations SHOULD be able to connect to 401 each other. 403 This requirement is driven by demand for all the use cases in 404 federated and allied environments. 406 11. The administrator of the ADVPN SHOULD allow for the 407 configuration of a Star, Full mesh or a partial full mesh topology, 408 based on which tunnels are allowed to be setup. 410 This requirement is driven by demand for all the use cases in 411 federated and allied environments. 413 12. The ADVPN solution SHOULD be able to scale for multicast 414 traffic. 416 This requirement is driven by the use case 2.2, where the amount of 417 rich media multicast traffic is increasing. 419 13. The ADVPN solution SHOULD allow for easy monitoring, logging and 420 reporting of the dynamic changes, to help for trouble shooting such 421 environments. 423 This requirement is driven by demand for all the use cases in 424 federated and allied environments. 426 14. There is also the case when L3VPNs operate over IPsec Tunnels, 427 for example Provider Edge (PE) based VPN's. An ADVPN MUST support 428 L3VPN as an application protected by the IPsec Tunnels. 430 This requirement is driven by demand for all the use cases in 431 federated and allied environments. 433 5. Security Considerations 435 This is a Problem statement and requirement document for the ADVPN 436 solution, and in itself does not introduce any new security concerns. 437 The solution to the problems presented in this draft may involve 438 dynamic updates to databases defined by RFC 4301, such as the 439 Security Policy Database (SPD) or the Peer Authorization Database 440 (PAD). 442 RFC 4301 is silent about the way these databases are populated, and 443 it is implied that these databases are static and pre-configured by a 444 human. Allowing dynamic updates to these databases must be thought 445 out carefully, because it allows the protocol to alter the security 446 policy that the IPsec endpoints implement. 448 One obvious attack to watch out for is stealing traffic to a 449 particular site. The IP address for www.example.com is 192.0.2.10. 450 If we add an entry to an IPsec endpoint's SPD that says that traffic 451 to 192.0.2.10 is protected through peer Gw-Mallory, then this allows 452 Gw-Mallory to either pretend to be www.example.com or to proxy and 453 read all traffic to that site. Updates to this database requires a 454 clear trust model. 456 6. IANA Considerations 458 No actions are required from IANA for this informational document. 460 7. Acknowledgements 462 Many people have contributed to the development of this problem 463 statement and many more will probably do so before we are done with 464 it. While we cannot thank all contributors, some have played an 465 especially prominent role. Yoav Nir, Yaron Sheffer, Jorge Coronel 466 Mendoza, Chris Ulliott, and John Veizades wrote the document upon 467 which this draft was based. Geoffrey Huang, Suresh Melam, Praveen 468 Sathyanarayan, Andreas Steffen, Brian Weis, and Lou Berger provided 469 essential input. 471 8. Normative References 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, March 1997. 476 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 477 Internet Protocol", RFC 4301, December 2005. 479 Authors' Addresses 481 Steve Hanna 482 Juniper Networks, Inc. 483 1194 N. Mathilda Ave. 484 Sunnyvale, CA 94089 485 USA 487 Email: shanna@juniper.net 489 Vishwas Manral 490 Hewlett-Packard Co. 491 19111 Pruneridge Ave. 492 Cupertino, CA 95113 493 USA 495 Email: vishwas.manral@hp.com