idnits 2.17.1 draft-bose-secure-l3vpn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 498. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 509. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 522. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 26, 2005) is 6993 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2796' is mentioned on line 356, but not defined ** Obsolete undefined reference: RFC 2796 (Obsoleted by RFC 4456) == Unused Reference: 'I-D.baker-nested-vpn-routing' is defined on line 418, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-baker-nested-vpn-routing-01 -- Possible downref: Normative reference to a draft: ref. 'I-D.baker-nested-vpn-routing' ** Downref: Normative reference to an Informational RFC: RFC 3809 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Bose, Ed. 3 Internet-Draft Lockheed Martin 4 Expires: August 30, 2005 R. Bonica 5 Juniper Networks 6 R. White 7 Cisco Systems 8 February 26, 2005 10 Secure Layer 3 Virtual Private Networks 11 draft-bose-secure-l3vpn-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 30, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document presents an framework for secure layer 3 Virtual 45 Private Networks (VPNs) for customer networks that exchange encrypted 46 information through a service provider network. It also describes 47 the necessary interactions between the various functions (e.g. 48 routing and encryption) at the VPN boundary to construct the secure 49 VPN. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Key Requirements for Secure VPNs in the GIG . . . . . . . 3 56 2. Functional Architecture of a Secure L3 VPN . . . . . . . . . . 5 57 2.1. Proposed L3 VPN Architecture . . . . . . . . . . . . . . . 6 58 2.2. Functional components at the VPN boundary . . . . . . . . 7 59 2.3. Hierarchical Distribution of Reachability Information . . 8 61 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 74 Intellectual Property and Copyright Statements . . . . . . . . . . 16 76 1. Introduction 78 VPNs are typically constructed in one of two ways. One is that a 79 service provider offers the VPN, and provides an underlying circuit 80 network, often MPLS, that connects the underlying endpoints as 81 defined in a contract. These are referred to as "Provider- 82 Provisioned VPNs" [RFC3809]. The other, generally referred to as 83 "customer-provisioned", is that the edge routers themselves provide 84 tunnels over an underlying network using one of a variety of types of 85 IP tunnel technologies such as loose source routes as specified in 86 DVMRP [RFC1075], IP/IP [RFC2003], IPsec/ESP [RFC2401][RFC2406], L2TP 87 [RFC2661], GRE [RFC2784] and others. 89 In this context, a "Secure VPN" is an example of an IPsec or IPsec- 90 like VPN, and is therefore "customer-provisioned". Such networks 91 have in the past been a complex collection of tunnels, a star or a 92 multi-star network in which a large set of client sites maintain 93 static or semi-static tunnels with a much smaller set of service 94 sites. This document presents a Layer 3 VPN architecture for such 95 networks by taking into account the underlying network architecture 96 and requirements of a secure VPN where plaintext (red) enclaves 97 connect to remote plaintext enclaves through a ciphertext (black) 98 network. 100 1.1. Key Requirements for Secure VPNs in the GIG 102 Secure VPNs presents a unique set of requirements which include: 104 o Scalability of VPN sites up to a large number of routes and 105 prefixes: Each secure enclave may have hundreds or thousands of 106 reachable destinations, and there may be thousands of secure 107 enclaves. A solution proven to be able to map large number of 108 destinations to some indicator of the enclave those destinations 109 belong to, ideally a ciphertext (black) next hop address 110 representing the secure enclave. Two types of systems have these 111 scaling characteristics in today's global Internet, name 112 resolution systems, and interdomain routing systems. 114 o Mobility of customer and service provider networks: Secure 115 enclaves will tend to be mobile in most environments, and 116 reachable destinations will tend to be mobile between secure 117 enclaves themselves. This implies any solution must be able to 118 adjust to changes in enclave or reachable destinations within an 119 enclave very quickly, within the application requirements for the 120 network as a whole. In most large scale internetworks, the times 121 acceptable for reacting to changes in reachability or connectivity 122 is on the order of seconds to tens of seconds, rather than minutes 123 to hours. Interdomain routing systems deployed in the global 124 Internet can meet these convergence time criteria. 126 o Secure routing and discovery of hosts, routers and gateways: 127 Destination reachability, in some environments, cannot become 128 known within the general routing table of all devices. This 129 implies not only authentication and authorization of reachability 130 information must be provided, but also that confidientality of 131 reachability information. Current interdomain routing protocols 132 can be used over secure point-to-point links, providing this type 133 of security. Further, authorization to advertise a specific set 134 of destinations must also be authorizable, in some fashion. 135 Interdomain routing protocols allow the validation of 136 authorization to advertise reachability, and this is an area of 137 current research and work for interdomain routing protocols. 139 o Minimal information transfer at the VPN boundary: Minimal amounts 140 of information may be passed between secure enclaves and the 141 internetwork through which these secure enclaves communicate. 142 Primarily, for this work, this includes reachability information, 143 as described above; reachability information cannot be passed from 144 the secure enclave into the insecure internetwork. Thus, there 145 must be some way to associate a public address with a set of 146 destinations within a secure enclave, without adding any 147 information to the insecure internetwork. Current interdomain 148 routing allows this attachment through the use of indirection; the 149 next hop towards a particular destination does not need to be the 150 transmitter of the routing information itself. 152 o Reachability policies are required: Because of the nature of the 153 routing information, the system used to advertise and discover 154 reachability information within secure enclaves must be able to 155 attach policy about where and how that routing information may be 156 shared to the routing information itself. Such policies are also 157 required to provide inter-enclave routing with information about 158 the best possible entry point into the secure enclave to reach any 159 specific destination within the enclave, as well as other 160 preferences. Current interdomain routing within the global 161 Internet has similar policy requirements, and thus the current 162 interdomain routing protocol supports such policy mechanisms. 164 o Dynamic on-demand discovery of reachability In some environments, 165 it may be more feasible to request routes on demand, rather than 166 learning all possible routes through a connection to a server or 167 other device. Current interdomain routing does not support this 168 mode of operation, but could be easily modified to provide this 169 type of service. 171 2. Functional Architecture of a Secure L3 VPN 173 A simple representation of a secure VPN is shown in Figure 1. 175 Plaintext(PT)| Ciphertext(CT) | Plaintext(PT) 176 (Red) | (Black) | (Red) 177 | | 178 +-------+-------+ +-------+-------+ 179 | | | | | | 180 | +----+---------------------------------+----+ | 181 | +----+---------------------------------+----+ | 182 | VPN|Router | Encrypted | VPN|Router | 183 +-------+-------+ Tunnel +-------+-------+ 184 | | 185 | | 186 | | 187 | | 188 | | 190 Figure 1: Simple VPN 192 Each customer network has a plaintext (red) enclave which 193 participates in a virtual private network with other red enclaves. 194 This is accomplished via an encrypted tunnel which originates and 195 terminates in the red enclave and traverses through the intermediate 196 ciphertext (black) service provider network. The VPN Router 197 (depicted here as a single logical node) performs the following 198 functions: 200 o Intra-Domain Routing 202 o Encryption/Decryption 204 o Transfer of necessary control plane information between plaintext 205 and ciphertext domains (e.g. IP addresses) 207 o Inter-Domain Routing 209 o Data Forwarding 211 Each of these functions may be performed by the same or different 212 physical entity in the network. A description of the various 213 physical implementation alternatives of these functions is beyond the 214 scope of this document. 216 The simple view presented in Figure 1 can be expanded in terms of a 217 typical layer 3 framework as described in [RFC4110] and depicted in 218 Figure 2 below. 220 Plaintext(PT) | Ciphertext(CT) | Plaintext(PT) 221 (Red) | (Black) | (Red) 222 | | 223 +-----+ + +-----+ +-----+ +-----+ + +-----+ 224 IGP | CE | | | CE | | PE | | CE | | | CE |IGP 225 <==== | ================================================ |===> 226 Static | +------+---------------------------------+------+ |Static 227 | | | | | | | | | | | | 228 +-----+ + +-----+ +-----+ +-----+ + +-----+ 229 |IGP IGP| 230 |<==> <==> BGP <==> <==>| 231 |Static Static| 232 | | 233 | IPsec | 234 <=======================================> 235 | | 236 | BGP(For PT to CT Nexthop) | 237 <==============================================> 239 Figure 2: Secure Layer 3 VPN Architecture 241 2.1. Proposed L3 VPN Architecture 243 The proposed Layer 3 VPN architecture as described in Figure 2 244 overlays a BGP VPN over IPsec tunnels. It is assumed for this 245 description that the two first hop routers at the VPN boundary form 246 the customer edge router which may or may not be the same device. 247 The red CE router learns and summarizes red prefixes using an IGP in 248 the red enclave such as OSPF. These prefixes are imported into the 249 inter-domain routing function at the red CE router and advertised to 250 a remote red enclave via BGP. BGP information exchange between 251 remote enclaves flows along with other data in the security 252 associations (e.g. IPsec). Any given red CE router learns the black 253 address of the remote enclave initially via configuration, a routing 254 service such as a BGP Route Reflector or a red-to-black address 255 translation scheme. 257 Data is forwarded into the appropriate security association as per 258 the virtual forwarding table constructed at the VPN boundary by BGP. 259 The black domain may use static, IGP or BGP routing as appropriate. 260 The figure above presents one possible routing model for the black 261 domain. The information exchange between the red and black domains 262 in this model is restricted to the knowledge in the red domain of the 263 black address to red address mapping of the remote enclave CE router. 265 The proposal is further explained by describing the different 266 functional components at the VPN boundary and the roles played by 267 them in the VPN as shown in Figure 3 268 PLAINTEXT | CIPHERTEXT 269 (Red) | (Black) 270 | 271 +---------------+ | 272 PT Prefixes | Intra-Domain | | 273 R1,R2,R3 | Routing | | 274 +---------------| | 275 | | 276 | | 277 Route|Redistribute | 278 | | 279 | | 280 +-----------+ CT-PT +---------------+ CT IP | 281 | BGP Route |<---------->| Inter-Domain |<--------+ | 282 | Reflector | Routes | Routing | Addr | | 283 +-----------+ +---------------+ = | | 284 R1->B1.H1 | B1.H1 | | 285 R2->B1.H1 FIB | Table | | 286 R3->B1.H1 +---------------+ +-----+------+ 287 | Forwarding |-----| Encryption | 288 +---------------+ +-----+------+ 289 |CT IP Addr 290 | 292 Figure 3: Functional Components at Secure VPN Boundary 294 2.2. Functional components at the VPN boundary 296 The role of the various functions at the VPN boundary as depicted in 297 Figure 3 are: 299 o Intra-Domain Routing: This function advertises, withdraws, and 300 summarizes the routes in the red enclave. It maintains an 301 internal routing table for the red domain. This routing table is 302 provided to the Inter-Domain Routing function for advertisement to 303 remote enclaves. 305 o Encryption: This function encrypts and decrypts all data traffic 306 into IPsec security associations with peer enclaves. It 307 establishes these security associations with a peer encryptor 308 using the IP address provided by the Forwarding function. The 309 encryption function has an IP address on the black side (CT IP 310 Addr) and an IP address on the red side (PT IP Addr), which is 311 used for forwarding data in the respective domains. 313 o Inter-Domain Routing: This function imports the internal routing 314 table from the Intra-Domain Routing function. It also advertises 315 the CT IP Addr of the encryption as the next-hop for the internal 316 red routes of the enclave. It provides this information to its 317 peer functions in the remote enclaves through a protocol such as 318 BGP. It also provides this information to a Route Reflector which 319 can be queried by remote enclaves to learn the CT IP Addr of the 320 encryption function for an internal red route. This function also 321 manages the information transfer of control plane information 322 between the red and black domains. In secure VPNs, the CT IP Addr 323 of the encryption function is accessed by the Inter-Domain Routing 324 function via manual configuration, SNMP, a simple routing protocol 325 such as RIP etc. 327 o Route Reflector: The route reflector function maintains the inter- 328 domain routing tables as provided the Inter-Domain Routing 329 function. It converses with other route reflectors to exchange 330 this routing information. A red enclave Inter-Domain Routing 331 function can query the route reflector to learn the next-hop 332 information for remote enclaves. Routes learnt from the Route 333 Reflector by the Inter-Domain routing function can be used to 334 populate the Security Policy Database of the encryption function 335 via manual configuration, SNMP etc. 337 o Forwarding: This function maintains the forwarding table which is 338 used to forward data to remote enclaves. It receives this 339 forwarding table from the Inter-Domain Routing function. The IP 340 addresses maintained in this forwarding table are used by the 341 encryption function to set up security associations to remote 342 enclaves. 344 These functions and the described interactions construct the proposed 345 virtual private network. Unicast routing between peer enclaves is 346 conducted via routing exchanges inside the security associations by 347 the peer Inter-Domain routing functions or by querying the 348 neighborhood route reflector. 350 2.3. Hierarchical Distribution of Reachability Information 352 In many cases, secure enclaves will not have the correct information 353 to directly connect and build BGP peering sessions; the correct set 354 of public internetwork addresses to connect to will be difficult to 355 discover on a large scale. To resolve this problem, a set of route 356 servers, or route reflectors [RFC2796], may be maintained for each 357 secure enclave attached to the insecure internetwork. The BGP 358 speaker contained within the secure enclave would have a manually 359 configured list of these route reflectors. Some form of anycast 360 addressing may be applicable to this situation, though this has not 361 been thoroughly investigated. 363 In some situations, it may be difficult to scale a single group of 364 route reflectors or route servers large enough to support the number 365 of sites within an interconnected secure enclave. Hierarchical route 366 reflectors, or hierarchical eBGP route servers, may be used to scale 367 in these situations. This is common practice in the public Internet. 369 3. IANA Considerations 371 This document makes no request of the IANA. 373 Note to RFC Editor: in the process assigning numbers and building 374 IANA registries prior to publication, this section will have served 375 its purpose. It may therefore be removed upon publication as an RFC. 377 4. Security Considerations 379 One security concern addressed in this proposal is the transfer of CT 380 IP address information to the plaintext side. In the current 381 proposal this is achieved via an authorized manual/automated network 382 management function on the plaintext side which queries the 383 encryption function. Alternatively a simple routing protocol like 384 RIP is used on the plaintext enclave only to provide this 385 information. 387 The security policy database for the encryption function, denoted in 388 the proposal as the forwarding table is also populated with CT IP 389 address nexthop information for remote enclaves. This information is 390 again configured via an an authorized manual/automated network 391 management function on the plaintext side. Only ciphertext IP 392 addresses fronting remote VPN enclaves are therefore used within the 393 plaintext enclave for the purposes of routing. Since this 394 information is only available on the plaintext enclave, which due to 395 the VPN characteristics of these networks a more secure environment, 396 misuse of this information within the plaintext enclave is expected 397 to be minimal. 399 5. Contributors 401 o Fred Baker (fred@cisco.com) 403 o Eric Fleischman (eric.fleischman@boeing.com) 405 o Julie Tarr (tarr@itd.nrl.navy.mil) 407 o Tony De Simone (antonio.desimone@jhuapl.edu) 409 6. Acknowledgements 411 Initial introductory text is borrowed from [I-D.baker-nested-vpn- 412 routing] . 414 7. References 416 7.1. Normative References 418 [I-D.baker-nested-vpn-routing] 419 Baker, F., "Routing across Nested VPNs", 420 draft-baker-nested-vpn-routing-01 (work in progress), 421 July 2005. 423 [RFC3809] Nagarajan, A., "Generic Requirements for Provider 424 Provisioned Virtual Private Networks (PPVPN)", RFC 3809, 425 June 2004. 427 7.2. Informative References 429 [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance 430 Vector Multicast Routing Protocol", RFC 1075, 431 November 1988. 433 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 434 October 1996. 436 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 437 Internet Protocol", RFC 2401, November 1998. 439 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 440 Payload (ESP)", RFC 2406, November 1998. 442 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 443 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 444 RFC 2661, August 1999. 446 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 447 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 448 March 2000. 450 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 451 Provider-Provisioned Virtual Private Networks (PPVPNs)", 452 RFC 4110, July 2005. 454 Authors' Addresses 456 Pratik Bose (editor) 457 Lockheed Martin 458 700 North Frederick Ave 459 Gaithersburg, Maryland 20876 460 USA 462 Phone: +1-240-462-9083 463 Fax: +1-301-428-5415 464 Email: pratik.bose@lmco.com 466 Ron Bonica 467 Juniper Networks 468 Virginia 469 USA 471 Phone: 472 Fax: 473 Email: rbonica@juniper.net 475 Russ White 476 Cisco Systems 477 North Carolina 478 USA 480 Phone: 481 Fax: 482 Email: riw@cisco.com 484 Full Copyright Statement 486 Copyright (C) The Internet Society (2005). 488 This document is subject to the rights, licenses and restrictions 489 contained in BCP 78, and except as set forth therein, the authors 490 retain all their rights. 492 This document and the information contained herein are provided on an 493 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 494 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 495 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 496 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 497 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 498 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 500 Intellectual Property 502 The IETF takes no position regarding the validity or scope of any 503 Intellectual Property Rights or other rights that might be claimed to 504 pertain to the implementation or use of the technology described in 505 this document or the extent to which any license under such rights 506 might or might not be available; nor does it represent that it has 507 made any independent effort to identify any such rights. Information 508 on the procedures with respect to rights in RFC documents can be 509 found in BCP 78 and BCP 79. 511 Copies of IPR disclosures made to the IETF Secretariat and any 512 assurances of licenses to be made available, or the result of an 513 attempt made to obtain a general license or permission for the use of 514 such proprietary rights by implementers or users of this 515 specification can be obtained from the IETF on-line IPR repository at 516 http://www.ietf.org/ipr. 518 The IETF invites any interested party to bring to its attention any 519 copyrights, patents or patent applications, or other proprietary 520 rights that may cover technology that may be required to implement 521 this standard. Please address the information to the IETF at 522 ietf-ipr@ietf.org. 524 Acknowledgment 526 Funding for the RFC Editor function is currently provided by the 527 Internet Society.