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