idnits 2.17.1 draft-ietf-ipsecme-p2p-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 5, 2012) is 4427 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 March 5, 2012 5 Expires: September 6, 2012 7 Point to Point VPNs Problem Statement 8 draft-ietf-ipsecme-p2p-vpn-problem-00 10 Abstract 12 This document describes the problem of enabling a large number of 13 systems to communicate directly using IPsec to protect the traffic 14 between them. Manual configuration of all possible tunnels is too 15 cumbersome in such cases, so an automated method is needed. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 6, 2012. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. Conventions Used in This Document . . . . . . . . . . . . 3 54 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1. Endpoint-to-Endpoint P2P VPN Use Case . . . . . . . . . . 4 56 2.2. Gateway-to-Gateway P2P VPN Use Case . . . . . . . . . . . 4 57 2.3. Endpoint-to-Gateway P2P VPN Use Case . . . . . . . . . . . 4 58 3. Inadequacy of Existing Solutions . . . . . . . . . . . . . . . 6 59 3.1. Exhaustive Configuration . . . . . . . . . . . . . . . . . 6 60 3.2. Star Topology . . . . . . . . . . . . . . . . . . . . . . 6 61 3.3. Proprietary Approaches . . . . . . . . . . . . . . . . . . 7 62 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 66 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 1. Introduction 71 IPsec [RFC4301] is used in several different cases, including tunnel- 72 mode site-to-site VPNs and Remote Access VPNs. Host to host 73 communication employing transport mode also exists, but is far less 74 commonly deployed. 76 The subject of this document is the problem presented by large scale 77 deployments of IPsec. These may be a large collection of VPN 78 gateways connecting various sites, a large number of remote endpoints 79 connecting to a number of gateways or to each other, or a mix of the 80 two. The gateways and endpoints may belong to a single 81 administrative domain or several domains with a trust relationship. 83 Section 4.4 of RFC 4301 describes the major IPsec databases needed 84 for IPsec processing. It requires an extensive configuration for 85 each tunnel, so manually configuring a system of many gateways and 86 endpoints becomes infeasible and inflexible. 88 The difficulty is that all the configuration mentioned in RFC 4301 is 89 not superfluous. IKE implementations need to know the identity and 90 credentials of all possible peer systems, as well as the addresses of 91 hosts and/or networks behind them. A simplified mechanism for 92 dynamically establishing point-to-point tunnels is needed. Section 2 93 contains several use cases that motivate this effort. 95 1.1. Terminology 97 Endpoint - A host that implements IPsec for its own traffic but does 98 not act as a gateway. 100 Gateway - A network device that implements IPsec to protect traffic 101 flowing through the device. 103 Point-to-Point - Direct communication between two parties without 104 active participation (e.g. encryption or decryption) by any other 105 parties. 107 Security Association (SA) - Defined in [RFC4301]. 109 1.2. Conventions Used in This Document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 2. Use Cases 117 This section presents the key use cases for large-scale point-to- 118 point VPN. 120 In all of these use cases, the participants (endpoints and gateways) 121 may be from a single organization or from multiple organizations with 122 an established trust relationship. When multiple organizations are 123 involved, products from multiple vendors are employed so open 124 standards are needed to provide interoperability. Establishing 125 communications between participants with no established trust 126 relationship is out of scope for this effort. 128 2.1. Endpoint-to-Endpoint P2P VPN Use Case 130 Two endpoints wish to communicate securely via a direct, point-to- 131 point SA. 133 The need for secure endpoint to endpoint communications is often 134 driven by a need to employ high-bandwidth, low latency local 135 connectivity instead of using slow, expensive links to remote 136 gateways. For example, two users in close proximity may wish to 137 place a direct, secure video or voice call without needing to send 138 the call through remote gateways, which would add latency to the 139 call, consume precious remote bandwidth, and increase overall costs. 141 2.2. Gateway-to-Gateway P2P VPN Use Case 143 Two gateways suddenly need to exchange a lot of data. 145 For example, a mobile worker from one government agency may sit down 146 in a shared remote office and start up his VOIP or video phone 147 software. He should rapidly get an efficient, secure, low latency 148 connection to his voice mail system and to anyone that he might call. 149 This user, his voice mail system, and other people that he calls will 150 probably be operating behind gateways but those gateways may have 151 little advance warning of the need to establish secure connectivity 152 between them. 154 2.3. Endpoint-to-Gateway P2P VPN Use Case 156 An endpoint wants to connect directly to the most efficient gateway 157 for accessing a particular service. 159 For example, a mobile user roaming on the Internet may need to open a 160 remote desktop connection to a virtual machine hosted on a particular 161 server or to a service provided by a variety of servers distributed 162 around the globe. The user should be able to establish a connection 163 directly to the gateway closest to the service desired. If multiple 164 gateways can suffice, load balancing and failover across gateways may 165 be useful. 167 3. Inadequacy of Existing Solutions 169 Several solutions exist for the problems described above. However, 170 none of these solutions is adequate, as described here. 172 3.1. Exhaustive Configuration 174 One simple solution is to configure all gateways and endpoints in 175 advance with all the information needed to determine which gateway or 176 endpoint is optimal and to establish an SA with that gateway or 177 endpoint. However, this solution does not scale in a large network 178 with hundreds of thousands of gateways and endpoints, especially when 179 multiple organizations are involved and things are rapidly changing 180 (e.g. mobile endpoints). A more dynamic system for securely and 181 scalably establishing SAs between gateways is needed. 183 3.2. Star Topology 185 The most common way to address this problem today is to use what has 186 been termed a "star topology". In this case one or a few gateways 187 are defined as "core gateways", while the rest of the systems 188 (whether endpoints or gateways) are defined as "satellites". The 189 satellites never connect to other satellites. They only open tunnels 190 with the core gateways. 192 For a large number of gateways in one administrative domain, one 193 gateway may be defined as the core, and the rest of the gateways and 194 remote access clients connect only to that gateway. If the packet 195 destination is behind another gateway, then the core gateway will re- 196 encrypt the traffic, and send it through the other tunnel. If we 197 have two collections of gateways under two administrative domains, 198 then each domain has its own core, and the administrators only need 199 to define an IPsec tunnel between the two cores. This tunnel is 200 often referred to as a "trunk". 202 One problem with stars and trunks is that it creates a high load on 203 the core gateways as well as on the trunk connection. This load is 204 both in processing power and in network bandwidth. A single packet 205 in the trunk scenario can be encrypted and decrypted three times. It 206 would be much preferable if these gateways and clients could initiate 207 tunnels between them, bypassing the core gateways. Additionally, the 208 path bandwidth to these core gateways may be lower than that of the 209 path between the satellites. For example, two remote access users 210 may be in the same building with high-speed wifi (for example, at an 211 IETF meeting). Channeling their conversation through the core 212 gateways of their respective employers seems extremely wasteful, as 213 well as having lower bandwidth. 215 The challenge is how to build large scale, fully meshed IPsec 216 protected networks that can dynamically change with minimum 217 administrative overhead. 219 3.3. Proprietary Approaches 221 Several vendors offer proprietary solutions to these problems. 222 However, these solutions offer no interoperability between equipment 223 from one vendor and another. This means that they are generally 224 restricted to use within one organization. Multiple organizations 225 cannot be expected to all choose the same equipment vendor. 227 4. Requirements 229 This section will be completed when the use cases are agreed upon. 231 5. Security Considerations 233 The solution to the problems presented in this draft may involve 234 dynamic updates to databases defined by RFC 4301, such as the 235 Security Policy Database (SPD) or the Peer Authorization Database 236 (PAD). 238 RFC 4301 is silent about the way these databases are populated, and 239 it is implied that these databases are static and pre-configured by a 240 human. Allowing dynamic updates to these databases must be thought 241 out carefully, because it allows the protocol to alter the security 242 policy that the IPsec endpoints implement. 244 One obvious attack to watch out for is stealing traffic to a 245 particular site. The IP address for www.example.com is 192.0.2.10. 246 If we add an entry to an IPsec endpoint's SPD that says that traffic 247 to 192.0.2.10 is protected through peer Gw-Mallory, then this allows 248 Gw-Mallory to either pretend to be www.example.com or to proxy and 249 read all traffic to that site. Updates to this database requires a 250 clear trust model. 252 More to be added. 254 6. IANA Considerations 256 No actions are required from IANA for this informational document. 258 7. Acknowledgements 260 Many people have contributed to the development of this problem 261 statement and many more will probably do so before we are done with 262 it. While we cannot thank all contributors, some have played an 263 especially prominent role. Yoav Nir, Jorge Coronel Mendoza, Chris 264 Ulliott, and John Veizades wrote the document upon which this draft 265 was based. Geoffrey Huang, Suresh Melam, Praveen Sathyanarayan, 266 Andreas Steffen, and Brian Weis provided essential input. 268 8. Normative References 270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 271 Requirement Levels", BCP 14, RFC 2119, March 1997. 273 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 274 Internet Protocol", RFC 4301, December 2005. 276 Author's Address 278 Steve Hanna 279 Juniper Networks, Inc. 280 1194 N. Mathilda Ave. 281 Sunnyvale, CA 94089 282 USA 284 Email: shanna@juniper.net