idnits 2.17.1 draft-ietf-ipsecme-ad-vpn-problem-00.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: ---------------------------------------------------------------------------- No issues found here. 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 (August 21, 2012) is 4266 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: February 22, 2013 HP 6 August 21, 2012 8 Auto Discovery VPN Problem Statement and Requirements 9 draft-ietf-ipsecme-ad-vpn-problem-00 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 February 22, 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 . . . . . . . . . . . . . . . . . . . 11 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 74 8. Normative References . . . . . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 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 AD VPN Use Case 145 Two endpoints wish to communicate securely via a direct, point-to- 146 point Security Association (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 use case also enables connectivity when both endpoints are 156 behind NAT gateways. Such use case should allow for seamless 157 connectivity even as endpoints roam, even if they are moving out from 158 behind a gateway, from behind one gateway to behind another, or from 159 a standalone position to behind a gateway. 161 In a hub and spoke topology when two endpoints communicate, they must 162 use a mechanism for authentication, such that they do not expose them 163 to impersonation by the other spoke endpoint. 165 2.2. Gateway-to-Gateway AD VPN Use Case 167 A typical Enterprise traffic model is hub and spoke, with the 168 gateways connecting to each other using IPsec tunnels. 170 However for the voice and other rich media traffic that occupies a 171 lot of bandwidth and the traffic tromboning to the hub can create 172 traffic bottlenecks on the hub and can lead to a increase cost. It 173 is for this purpose spoke-to-spoke tunnels are dynamically created 174 and torn-down. 176 The spoke gateways can themselves come up and down, getting different 177 IP addresses in the process, making th static configuration 178 impossible. 180 Also for the reasons of cost and manual error reduction, it is 181 desired there be minimal or even no configuration on the hub as a new 182 spoke Router is added or removed. 184 In a hub and spoke topology when two spoke gateways communicate, they 185 must use a mechanism for authentication, such that they do not expose 186 them to impersonation by the other gateways spoke. 188 2.3. Endpoint-to-Gateway AD VPN Use Case 190 An endpoint should be able to use the most efficient gateway as it 191 roams in the internet. 193 A mobile user roaming on the Internet may connect to a gateway, which 194 because of roaming is no longer the most efficient gateway to use 195 (reasons could be cost/ efficiency/ latency or some other factor). 196 The mobile user should be able to discover and then connect to the 197 current most efficient gateway without having to reinitiate the 198 connection. 200 3. Inadequacy of Existing Solutions 202 Several solutions exist for the problems described above. However, 203 none of these solutions is adequate, as described here. 205 3.1. Exhaustive Configuration 207 One simple solution is to configure all gateways and endpoints in 208 advance with all the information needed to determine which gateway or 209 endpoint is optimal and to establish an SA with that gateway or 210 endpoint. However, this solution does not scale in a large network 211 with hundreds of thousands of gateways and endpoints, especially when 212 multiple organizations are involved and things are rapidly changing 213 (e.g. mobile endpoints). Such a solution is also limited by the 214 smallest endpoint/ gateway, as the same exhaustive configuration is 215 to be applied on all endpoints/ gateways. A more dynamic, secure and 216 scalable system for establishing SAs between gateways is needed. 218 3.2. Star Topology 220 The most common way to address this problem today is to use what has 221 been termed a "star topology". In this case one or a few gateways 222 are defined as "hub gateways", while the rest of the systems (whether 223 endpoints or gateways) are defined as "spokes". The spokes never 224 connect to other spokes. They only open tunnels with the hub 225 gateways. Also for a large number of gateways in one administrative 226 domain, one gateway may be defined as the hub, and the rest of the 227 gateways and remote access clients connect only to that gateway. 229 This solution however does not work when the spokes get dynamic IP 230 address which the "hub gateways" cannot be configured with. It is 231 also desired that there is minimal to no configuration on the hub as 232 the number of spokes increases and new spokes are added and deleted 233 randomly. 235 Another problem with the star topology is that it creates a high load 236 on the hub gateways as well as on the connection between the spokes 237 and the hub. This load is both in processing power and in network 238 bandwidth. A single packet in the hub-and-spoke scenario can be 239 encrypted and decrypted three times. It would be much preferable if 240 these gateways and clients could initiate tunnels between them, 241 bypassing the hub gateways. Additionally, the path bandwidth to 242 these hub gateways may be lower than that of the path between the 243 spokes. For example, two remote access users may be in the same 244 building with high-speed wifi (for example, at an IETF meeting). 245 Channeling their conversation through the hub gateways of their 246 respective employers seems extremely wasteful, as well as having 247 lower bandwidth. 249 The challenge is to build a large scale, IPsec protected networks 250 that can dynamically change with minimum administrative overhead. 252 3.3. Proprietary Approaches 254 Several vendors offer proprietary solutions to these problems. 255 However, these solutions offer no interoperability between equipment 256 from one vendor and another. This means that they are generally 257 restricted to use within one organization, and it is harder to move 258 off such solutions as the features are not standardized. Besides 259 multiple organizations cannot be expected to all choose the same 260 equipment vendor. 262 4. Requirements 264 This section is currently being updated and hence under flux. 266 4.1. Gateway and Endpoint Requirements 268 1. For any network topology (whether hub-and-spoke or Full Mesh) 269 gateways and endpoints MUST minimize configuration changes when a new 270 gateway or endpoint is added, removed or changed. Specifically, when 271 evaluating potential solutions, we will compare them by looking at 272 how many endpoints or gateways must be reconfigured when a new 273 gateway or endpoint is added, removed, or changed and how substantial 274 this reconfiguration is. 276 This requirement is driven by use cases 2.1 and 2.2 and by the 277 scaling limitations pointed out in section 3.1. 279 2. Gateways and endpoints MUST allow IPsec Tunnels to be setup 280 without any configuration changes, even when peer addresses get 281 updated every time the device comes up. This implies that SPD 282 entries or other configuration based on peer IP address will need to 283 be automatically updated, avoided, or handled in some manner to avoid 284 a need to manually update policy whenever an address changes. 286 This requirement is driven by use cases 2.1 and 2.2 and by the 287 scaling limitations pointed out in section 3.1. 289 3. Gateways MUST allow tunnel binding, such that applications like 290 Routing using the tunnels can work seamlessly without any updates to 291 the higher level application configuration i.e. OSPF configuration. 293 4. In a hub-and-spoke topology, spoke gateways and endpoints MUST 294 allow for direct communication with other spoke gateways and 295 endpoints. 297 This requirement is driven by use cases 2.1 and 2.2 and by the 298 limitations of a star topology pointed out in section 3.2. 300 5. One spoke MUST NOT be able to impersonate another spoke. 302 This requirement is driven by use case 2.1. Endpoints become 303 compromised fairly often. The compromise of one endpoint should not 304 affect the security of other endpoints. 306 6. Gateways SHOULD allow for easy handoff of sessions in case 307 endpoints are roaming, even if they cross policy boundaries. This 308 means that TCP session breakage and packet loss should be avoided, 309 when possible. 311 This requirement is driven by use case 2.1. Today's endpoints are 312 mobile and transition often between different networks (from 4G to 313 WiFi and among various WiFi networks). 315 7. Gateways SHOULD allow for easy handoff of a session to another 316 gateway, to optimize latency, bandwidth, load balancing, 317 availability, or other factors, based on policy. 319 This requirement is driven by use case 2.3. 321 8. Gateways and endpoints MUST be able to work when they are behind 322 NAT boxes. However, it is especially difficult to handle cases where 323 gateways are behind NATs and where two endpoints are both behind 324 separate NATs. In those cases, workarounds MAY be used such as port 325 forwarding by the NAT or detecting when two spokes are behind 326 uncooperative NATs and using a hub in that case. 328 This requirement is driven by use cases 2.1 and 2.2. Endpoints are 329 often behind NATs and gateways sometimes are. IPsec should continue 330 to work seamlessly regardless, using AD VPN techniques whenever 331 possible and providing graceful fallback to hub and spoke techniques 332 as needed. 334 9. Changes such as establishing a new IPsec SA SHOULD be reportable 335 and manageable. However, creating a MIB or other management 336 technique is not within scope for this effort. 338 This requirement is driven by manageability concerns for all the use 339 cases, especially use case 2.2. As IPsec networks become more 340 dynamic, management tools become more essential. 342 10. To support allied and federated environments, endpoints and 343 gateways from different organizations SHOULD be able to connect to 344 each other. 346 This requirement is driven by demand for all the use cases in 347 federated and allied environments. 349 11. The solution SHOULD allow administrators the ability to 350 configure a variety of permissible topologies: full mesh, partial 351 mesh, star, etc. They should be able to set different topologies for 352 different types of traffic: voice, video, web, email, etc. 354 This requirement is driven by counter-balancing requirements to log 355 or control traffic of certain types (e.g. email) while ensuring 356 efficient, low-latencies flows of other types (e.g. video). 358 5. Security Considerations 360 The solution to the problems presented in this draft may involve 361 dynamic updates to databases defined by RFC 4301, such as the 362 Security Policy Database (SPD) or the Peer Authorization Database 363 (PAD). 365 RFC 4301 is silent about the way these databases are populated, and 366 it is implied that these databases are static and pre-configured by a 367 human. Allowing dynamic updates to these databases must be thought 368 out carefully, because it allows the protocol to alter the security 369 policy that the IPsec endpoints implement. 371 One obvious attack to watch out for is stealing traffic to a 372 particular site. The IP address for www.example.com is 192.0.2.10. 373 If we add an entry to an IPsec endpoint's SPD that says that traffic 374 to 192.0.2.10 is protected through peer Gw-Mallory, then this allows 375 Gw-Mallory to either pretend to be www.example.com or to proxy and 376 read all traffic to that site. Updates to this database requires a 377 clear trust model. 379 More to be added. 381 6. IANA Considerations 383 No actions are required from IANA for this informational document. 385 7. Acknowledgements 387 Many people have contributed to the development of this problem 388 statement and many more will probably do so before we are done with 389 it. While we cannot thank all contributors, some have played an 390 especially prominent role. Yoav Nir, Yaron Scheffer, Jorge Coronel 391 Mendoza, Chris Ulliott, and John Veizades wrote the document upon 392 which this draft was based. Geoffrey Huang, Suresh Melam, Praveen 393 Sathyanarayan, Andreas Steffen, and Brian Weis provided essential 394 input. 396 8. Normative References 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, March 1997. 401 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 402 Internet Protocol", RFC 4301, December 2005. 404 Authors' Addresses 406 Steve Hanna 407 Juniper Networks, Inc. 408 1194 N. Mathilda Ave. 409 Sunnyvale, CA 94089 410 USA 412 Email: shanna@juniper.net 414 Vishwas Manral 415 Hewlett-Packard Co. 416 19111 Pruneridge Ave. 417 Cupertino, CA 95113 418 USA 420 Email: vishwas.manral@hp.com