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