idnits 2.17.1 draft-nir-ipsecme-p2p-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (October 14, 2011) is 4570 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPsecME Working Group Y. Nir 3 Internet-Draft Check Point 4 Intended status: Informational J. Veizades 5 Expires: April 16, 2012 Juniper 6 C. Ulliott 7 CESG 8 J. Mendoza 9 Microsoft 10 October 14, 2011 12 Creating Large Scale Mesh VPNs Problem Statement 13 draft-nir-ipsecme-p2p-00 15 Abstract 17 This document presents the problem of configuring a large number of 18 IKE/IPsec systems in such a way that any two of them can use IPsec to 19 protect the traffic between them. Manual configuration of all 20 possible tunnels is too cumbersome in such cases, so an automated 21 method is needed. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 16, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 59 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. The Service Provider Use Case . . . . . . . . . . . . . . 5 61 2.2. Cross Domain Mesh Use Case . . . . . . . . . . . . . . . . 5 62 2.2.1. Scenario 1 . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2.2. Scenario 2 . . . . . . . . . . . . . . . . . . . . . . 5 64 2.2.3. Scenario 3 . . . . . . . . . . . . . . . . . . . . . . 6 65 2.3. The Consultant Use Case . . . . . . . . . . . . . . . . . 6 66 2.3.1. Scenario A: Mobile worker and multiple domains . . . . 6 67 2.3.2. Scenario B: Consultants sharing securely . . . . . . . 6 68 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 71 6. Normative References . . . . . . . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 IPsec ([RFC4301]) is used in several different cases, including 77 tunnel-mode site-to-site VPNs and Remote Access VPNs. Host to host 78 communication employing transport mode also exists, but is far less 79 commonly deployed. The subject of this document is large scale 80 deployments. These may be a large collection of VPN gateways and 81 hosts, all administered within the same administrative domain, or 82 they may be a smaller collection of VPN gateways, with many remote 83 access clients connecting to any of them, or they may be several 84 collections of gateways, each collection administered by a different 85 domain, or they may be combinations of all of the above. 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 "mesh" of several gateways 90 becomes inconvenient. 92 One way to handle this is what has been termed a "star topology", or 93 a "trunk topology". In this case one gateway, or a few gateways are 94 defined as "core gateways", while the rest, whether remote-access 95 clients or gateways are defined as "satellites". The satellites 96 never connect to other satellites. They only open tunnels with the 97 core gateways. 99 For a large number of gateways in one administrative domain, one 100 gateway may be defined as the core, and the rest of the gateways and 101 remote access clients connect only to that gateway. If the packet 102 destination is behind another gateway, then the core gateway will re- 103 encrypt the traffic, and send it through the other tunnel. If we 104 have two collections of gateways under two administrative domains, 105 then each domain has its own "core", and the administrators only need 106 to define an IPsec tunnel between the two cores. This tunnel is 107 often referred to as a "trunk". 109 The problem with stars and trunks is that it creates a high load on 110 the core gateways as well as on the trunk connection. This load is 111 both in processing power and in network bandwidth. A single packet 112 in the trunk scenario can be encrypted and decrypted three times. It 113 would be much preferable if these gateways and clients could initiate 114 tunnels between them, bypassing the core gateways. Additionally, the 115 path bandwidth to these core gateways may be lower than that of the 116 path between the satellites. For example, two remote access users 117 may be in the same building with high-speed wifi (for example, at an 118 IETF meeting). Channeling their conversation through the core 119 gateways of their respective employers seems extremely wasteful, as 120 well as having lower bandwidth. 122 The challenge is how to build large scale, fully meshed IPsec 123 protected networks that can dynamically change with minimum 124 administrative overhead. 126 The difficulty is that all the configuration mentioned in RFC 4301 is 127 not superfluous. IKE implementations need to know the identity and 128 credentials of all possible peer systems, as well as the addresses of 129 hosts and/or networks behind them. A simplified mechanism for 130 establishing ad-hoc tunnels is needed. Section 2 contains several 131 use cases that led to the publishing of this document. 133 1.1. Conventions Used in This Document 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 "Administrative Domain" is used in this document for the entity, 140 whether human, team, or computer, that configures VPN gateways and 141 clients. Gateways are said to be under the same administrative 142 domain if they are configured by a single entity and implement the 143 same policy. Some products have the ability to configure multiple 144 VPN gateways or clients, which would solve the problem presented in 145 this document for gateways under the same administrative domain, but 146 they do not solve the problem for multiple administrative domains. 148 2. Use Cases 150 This section presents the use cases that have motivated this document 151 in no particular order. 153 2.1. The Service Provider Use Case 155 A service provider wishes to control communication between network 156 elements with authentication and encryption as provided by standard 157 protocols like IPsec. This is possible today but the amount of 158 configuration information on each system is currently order n squared 159 so from an operational standpoint this can be challenging as the size 160 of the enterprise network grows. In short service providers wish to 161 minimize the configuration data that is required by any one system to 162 initiate a secure communication link to any other arbitrary system 163 that is part of the service provider enterprise. 165 These same service providers wish to extend these secure 166 communication links to partners that have similar systems. Again 167 they wish to minimize the amount of configuration needed to initiate 168 these secure connections to arbitrary systems at an arbitrary 169 partner. Additionally they required a directory of connection 170 information that can be updated independently to manage the identity 171 of the connection endpoints at each one of their partners. 173 2.2. Cross Domain Mesh Use Case 175 This section describes requirements for dynamically creating a mesh 176 of VPN endpoints although those endpoints belong to different 177 administrative domains. 179 2.2.1. Scenario 1 181 Multiple users, connected to a corporate remote access solution are 182 participating in high bandwidth peer to peer communications. It is 183 required that to optimise bandwidth and latency (subject to policy), 184 the solution is able to establish links between remote peers rather 185 than through a central gateway. 187 2.2.2. Scenario 2 189 Rather than remote hosts, the next scenario covers the connectivity 190 between gateways. Behind each gateway there are a number of 191 individual hosts who aren't aware of the protection being offered by 192 the gateway. As each client send traffic to a host at a different 193 site, the gateway is required to identify the location of the remote 194 host and selects the most approprate gateway. Having made this 195 decision, it dynamically establishes a secure tunnel and forwards the 196 traffic. 198 2.2.3. Scenario 3 200 The third scenario is a combination of the first two, where a remote 201 user is no longer tied to using a specific remote access gateway. 202 Should the remote host need to communicate with an entity protected 203 by a gateway as described above, it would be possible for it to 204 identify a suitable gateway and establish a dynamic SA / tunnel and 205 communicate via the most effective route (subject to policy) It is 206 essential that any solution that meets the above scenarios, that we 207 specify a mechanism for identifying permitted hosts / gateways and 208 deploying a policy to each gateway and participating host. The 209 solution also needs to work in an environment where gateways / hosts 210 are administered by different entitites or management domains. 212 2.3. The Consultant Use Case 214 This section describes use cases for a consultant who works for 215 multiple organizations but is not an employee of any of them. 217 2.3.1. Scenario A: Mobile worker and multiple domains 219 A consultant is hired by corporations (A and B) each of them with 220 their own isolated domains and resources protected with IPsec 221 authentication. The consultant has signed NDA and the corporation 222 granted some level of trust in the form of an authentication ID. 223 This level of trust allows the contractor to access secured resources 224 and networks protected by IPsec until such trust is revoked. 226 In any given work week the consultant would be providing services on 227 site or remotely to multiple corporations. This is possible today, 228 yet unmanageable due to the amount of configuration required in order 229 for the consultant to dynamically identify the parameters to use 230 when: 231 o He/She needs to get connected to secure resources when on premises 232 (E2E client to server secured connection) 233 o He/She needs to use a secure access point when working remotely 234 (Client to Edge connection) 236 One key aspect of this problem is that the consultant may be 237 providing consulting services to Corp A and Corp B, for privacy 238 reasons this information should be protected. 240 2.3.2. Scenario B: Consultants sharing securely 242 Consultant team A and team B have hired by corporation C and are 243 working together in a project that requires collaboration, however 244 because they are from different consulting firms half of the 245 consultants are based in WA and half in CA. As in the scenario above 246 they have been entrusted with authentication ID. They have a need to 247 share folders with sensitive files in order to work efficiently 248 towards a tight deadline. 250 They have a need to securely handle this information hence they have 251 a need to discover what type of security should be used when 252 attempting to share information among themselves. 254 3. Security Considerations 256 The solution to the problems presented in this draft may involve 257 dynamic updates to databases defined by RFC 4301, such as the 258 Security Policy Database (SPD) or the Peer Authorization Database 259 (PAD). 261 RFC 4301 is silent about the way these databases are populated, and 262 it is implied that these databases are static and pre-configured by a 263 human. Allowing dynamic updates to these databases must be thought 264 out carefully, because it allows the protocol to alter the security 265 policy that the IPsec endpoints implement. 267 One obvious attack to watch out for is stealing traffic to a 268 particular site. The IP address for www.example.com is 192.0.43.10. 269 If we add an entry to an IPsec endpoint's SPD that says that traffic 270 to 192.0.43.10 is protected through peer Gw-Mallory, then this allows 271 Gw-Mallory to either pretend to be www.example.com or to proxy and 272 read all traffic to that site. Updates to this database requires a 273 clear trust model. 275 More to be added. 277 4. IANA Considerations 279 No actions are required from IANA for this informational document. 281 5. Acknowledgements 283 The authors would like to thank Geoffrey Huang, Suresh Melam, Andreas 284 Stephen, and Brian Weis for their discussion and comments on early 285 versions of this draft. We would also like to thank Stephen Hanna 286 for gathering the group that has produced this draft. 288 6. Normative References 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, March 1997. 293 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 294 Internet Protocol", RFC 4301, December 2005. 296 Authors' Addresses 298 Yoav Nir 299 Check Point Software Technologies Ltd. 300 5 Hasolelim st. 301 Tel Aviv 67897 302 Israel 304 Email: ynir@checkpoint.com 306 John Veizades 307 Juniper Networks, Inc. 308 1194 N. Mathilda ave. 309 Sunnyvale, CA 94089 310 USA 312 Email: jveizades at juniper dot net 314 Chris Ulliott 315 CESG 316 Hubble Road 317 Cheltenham GL51 0EX 318 UK 320 Email: Chris.Ulliott@cesg.gsi.gov.uk 322 Jorge Coronel Mendoza 323 Microsoft Corporation 324 1 Microsoft Way 325 Redmond, WA 98052 326 USA 328 Email: jcoronel@microsoft.com