idnits 2.17.00 (12 Aug 2021) /tmp/idnits19116/draft-behringer-mpls-vpn-auth-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC2547]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC-2119' is mentioned on line 67, but not defined -- Looks like a reference, but probably isn't: '2154' on line 132 -- Looks like a reference, but probably isn't: '2385' on line 132 == Unused Reference: 'RFC2154' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'RFC2385' is defined on line 362, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Downref: Normative reference to an Informational RFC: RFC 2042 ** Obsolete normative reference: RFC 2082 (Obsoleted by RFC 4822) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Experimental RFC: RFC 2154 ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2858 (Obsoleted by RFC 4760) Summary: 16 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Michael Behringer 3 Jim Guichard 4 Cisco Systems, Inc. 6 Pedro Roque Marques 7 Juniper Networks, Inc. 9 IETF Internet Draft 10 Expires: December, 2004 11 Document: draft-behringer-mpls-vpn-auth-04.txt June, 2004 13 Layer-3 VPN Import/Export Verification 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are 19 Working documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working groups. Note that other groups may also 21 distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 Configuration errors on Provider Edge (PE) routers in Layer-3 VPN 36 networks based on [RFC2547] can lead to security breaches of the 37 connected VPNs. For example, the PE router could be mistakenly 38 configured such that a connected Customer Edge (CE) router belongs to 39 an incorrect VPN. Here we propose a scheme that verifies local and 40 remote routing information received by the PE router before it 41 installs new VPN routes into the Virtual Routing & Forwarding 42 Instance (VRF). The proposed changes affect only the PE routers. 44 Behringer, Guichard, Roque 1 45 Table of Contents 47 1 Conventions used in this document...............................2 48 2 Problem Statement and Overview..................................2 49 3 CE-CE Authentication............................................3 50 3.1 PE-CE Authentication Behavior..................................4 51 3.2 Behaviour of PE sending the UPDATE-authenticator...............4 52 3.3 Behaviour of PE receiving the UPDATE-authenticator.............5 53 4 Extranet VPN Processing.........................................6 54 5 The UPDATE-authenticator attribute..............................6 55 6 IANA Considerations.............................................7 56 7 Security Considerations.........................................7 57 8 Acknowledgements................................................7 58 9 References......................................................7 59 10 Authors' Addresses..............................................8 60 11 Full Copyright Statement........................................8 62 1 Conventions used in this document 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 66 this document are to be interpreted as described in [RFC-2119]. 68 2 Problem Statement and Overview 70 The current Layer-3 VPN architecture as defined in [RFC2547] does not 71 provide any mechanism to determine whether an imported route on a PE 72 router originated from the correct VPN. This opens a potential 73 security hole where the VPN Service Provider could mistakenly assign 74 on a PE router the incorrect "route-target" values, thus 75 inadvertently bringing a connected CE router, with the network/s 76 behind it, into a wrong VPN. 78 [RFC2547] does not require that PE-CE sessions or PE-PE sessions be 79 authenticated. However, in the cases where this is deployed, route 80 authentication relies on a three-step configuration process; From the 81 CE router to the PE router, from that PE router to other PE routers 82 in the same VPN provider network, and from the other PE routers to 83 the corresponding CE routers. 85 Correct access control between VPNs relies on the accurate 86 configuration of "route-targets" on the PE routers. Because the 3 87 authentication steps above are essentially disjoint, the linkage 88 necessary to "glue" them together is the correct configuration of the 89 VPN provider network, and the corresponding "route-target" values. . 91 If the Service Provider has assigned the wrong "route-target" values 92 then this is hard to detect from within the customer's network, and a 93 real issue in [RFC2547] networks. One possible solution to this 94 problem is to mount IPsec [RFC2401] on all CE routers, but this is 95 often perceived as too "heavy-weight". Therefore, a mechanism is 97 Behringer, Guichard, Roque 2 98 required which prevents routes from being passed into a PE router's 99 Virtual Routing & Forwarding Instance (VRF), unless they have been 100 verified to belong to the associated VPN. Also, in the case of such 101 configuration errors, the Service Provider must be alerted so that 102 the mistake can be rectified. 104 This proposal aims to solve the problem of accidental 105 misconfiguration of VPN parameters on PE routers. The approach is to 106 associate one or more authentication keys to a VPN, and use existing 107 routing protocol authentication mechanisms [RFC2082, 2154, 2385], to 108 provide PE-CE authentication. PE-PE routing exchanges are validated 109 via routing update signatures. Since a PE router can hold several 110 VRF's, the authentication between PEs will use the different MD5 111 keys, based on which VRF's routes need to be verified. 113 BGP UPDATE messages between PE routers will include a new BGP 114 attribute, hereby referred to as the "UPDATE-authenticator". This 115 attribute contains a keyed HMAC MD5 signature of a locally generated 116 per-VRF random number, using the MD5 key that is also used on this PE 117 router for the PE-CE routing authentication of that VPN. 119 The receiving PE router generates a keyed HMAC MD5 signature using 120 information from the "UPDATE-authenticator" attribute contained 121 within the BGP UPDATE message, and the routing key of the CE router 122 that is to receive the routes contained within the update. If the 123 result is different from the signature value transmitted in the 124 UPDATE-authenticator attribute, the routes within the UPDATE are not 125 imported and a warning is logged. 127 This proposal imposes some operational constraints to be workable; 128 Regardless of whether a routing protocol is used or not within the 129 VRF, at least one authentication key MUST be configured for each VRF 130 that wishes to use the mechanisms described within this document. If 131 a dynamic routing protocol is used, then routing with MD5 132 authentication [RFC2082, 2154, 2385] SHOULD be configured for all PE- 133 CE links of a particular VPN. All CE routers of the same VPN MAY use 134 the same or different MD5 keys and the PE router MUST indicate which 135 key has been used when advertising routes from the associated VRF. If 136 the Service Provider manages the CE routers on behalf of the 137 customer, then downstream C routers MUST also use the same MD5 key. 138 MD5 keys SHOULD be chosen to be unique to a VPN. 140 3 CE-CE Authentication 142 As previously stated, this document proposes to re-use the MD5 key 143 that is being used for PE-CE routing authentication. This has the 144 advantage that no changes or software upgrades are necessary at the 145 CE routers or within the VPN site. For this proposal to work, each PE 146 router, on export of the routes from within a given VPN, MUST 147 indicate which MD5 key has been used to authenticate the local 148 routes. The MD5 key set SHOULD be unique to each VPN. The VPN 149 customer configures thus all their CE routers with an MD5 key. The 151 Behringer, Guichard, Roque 3 152 VPN Service Provider also configures the PE routers with this local 153 key on all links to the customers CE routers. This proposal does not 154 affect the CE-PE routing authentication, but the authentication MUST 155 be used for this scheme to work. 157 This proposal is orthogonal with MD5 authentication between PE 158 routers on the VPN network. Authentication of peering sessions 159 between PEs provides protection of the VPN routing information 160 without any validation of its origin. 162 While currently, the VPN service provider may choose to configure 163 routing authentication between the PE and CE, this information only 164 affects the local routing session between the two routers. 165 Conceptually, this proposal extends this key verification between the 166 local PE and CE to remote PE to CE connections. 168 Using the mechanisms described within this document, the BGP UPDATE 169 message, as defined in [RFC1771], is sent between PE routers (or BGP 170 route reflectors), and carries a new UPDATE-authenticator attribute, 171 which is used to verify the source of the routing information. 173 3.1 PE-CE Authentication Behavior 175 If a dynamic routing protocol is used between PE and CE routers, then 176 the routing protocol is secured with MD5 authentication. Routes are 177 only put into a VRF that is configured with Layer-3 VPN 178 "Import/Export Verification" if the MD5 authentication is successful. 180 If a VRF is configured at the PE router for Layer-3 VPN 181 "Import/Export Verification" using MD5 authentication, it is OPTIONAL 182 to confirm local route authentication prior to any route export from 183 the VRF. Route authentication involves checking whether the PE router 184 can confirm route receipt from each CE router that is attached to the 185 VRF. 187 3.2 Behaviour of PE sending the UPDATE-authenticator 189 When Layer-3 "Import/Export Verification" is enabled, the PE router 190 SHOULD calculate a random number, referred to as the 'Generator', for 191 each VRF that is configured for authentication. Alternatively a 192 combination of the local "route-target" values may be used to 193 generate this number. This is implementation specific. 195 Having generated the VRF specific random number, the PE router on 196 sending a [RFC2858] BGP UPDATE calculates a keyed HMAC-MD5 signature, 197 as defined in [RFC2104], over the 'Generator', using the key of one 198 of the CEs that is connected to the corresponding VRF. The result of 199 this calculation is carried, along with the 'Generator' and an 200 identification of the key used against the 'Generator', in the "HMAC- 201 MD5 Signature" field within the UPDATE-authenticator attribute. 203 Each key within a VRF will have a corresponding 'key-identifier', 204 which SHOULD be configurable within the VRF, and MUST be unique 206 Behringer, Guichard, Roque 4 207 across VPNs. Every PE router that holds members of the VPN MUST carry 208 mappings so that they can verify which key to 209 use when authenticating incoming routing updates. The key-identifier 210 MAY be the route-target. 212 The PE sending an [RFC2858] UPDATE will add a 'key-identifier' to the 213 UPDATE-authenticator attribute to indicate which key should be used 214 by a receiving PE router to verify the update. The UPDATE message is 215 sent to any [RFC2858] BGP peers (other PE routers or BGP route 216 reflectors). The "route-targets" in the [RFC2858] update determine 217 which VRF/s the UPDATE refers to, and these are used as described in 218 [RFC2547] to determine which PE routers will import which routes. 220 3.3 Behaviour of PE receiving the UPDATE-authenticator 222 A PE router that receives a [RFC2858] BGP update that contains the 223 UPDATE-authenticator attribute SHOULD verify the contents of the 224 update with the following algorithm. As an OPTIONAL step, the PE 225 router MAY perform this comparison only if it has authenticated local 226 routes from the CE router: 228 IF target VRF is configured for Layer-3 VPN Import/Exp. Verification 229 THEN 230 IF UPDATE-authenticator attribute is present 231 THEN 232 subroutine determine_MD5-key 233 verify UPDATE-authenticator with MD5-key 234 IF result = signature of received UPDATE-authenticator 235 THEN 236 import route into VRF 237 ELSE 238 mark routes as 'not authenticated'; log error 239 ELSE 240 mark routes as 'not authenticated'; log error 241 ELSE 242 mark routes as 'not authenticated'; log error 244 subroutine determine_MD5-key 245 IF key-identifier = 0 246 THEN 247 MD5-key = the MD5 key used for routing authentication 248 with one of the routing peers of the VRF. 249 ELSE 250 MD5-key = lookup_in_config (key-identifier) 251 RETURN MD5-key 253 A router MAY verify whether all MD5 keys for a given VRF are the 254 same. If it does a warning message MUST be logged if it detects 255 differences. 257 In the case where the Service Provider manages the CE routers, the 258 Service Provider must also configure the key at the CE routers and 259 this should match with any directly connected downstream C routers 261 Behringer, Guichard, Roque 5 262 within the customer site. If the C routers have a different key than 263 the CE router then the CE will not authenticate any routes from 264 within the site, and will therefore not advertise any routing 265 information to the PE router. The PE router is thus able to use the 266 previously described mechanisms and will not import/export any routes 267 from/to the customers VRF. 269 4 Extranet VPN Processing 271 There are typically two types of Extranets that can be defined using 272 the [RFC2547] architecture; Central Services Extranet and Distributed 273 Extranet. 275 The Central Services Extranet provides connectivity between spoke VPN 276 sites through a central PE router. This PE router carries routes for 277 all members of the extranet whereas spoke PE routers carry only local 278 routes, and a route to the central PE router. To support this type of 279 configuration, the central PE router needs to carry mappings for ALL members of the extranet. On receiving an 281 incoming update, the central PE is able to identify which key to use 282 on the UPDATE-authenticator attribute by looking at the key- 283 identifier carried within the update. 285 The Distributed Extranet model provides connectivity directly between 286 members of a given VPN. This means that each PE router that holds 287 members of the extranet is configured to import the relevant "route- 288 target" values used for export by other members of the VPN. Using the 289 key-identifier, a PE router is able to identify which key to use on 290 an incoming update to verify the source. This means that each PE 291 router within the extranet MUST carry mappings 292 for all members of the VPN. 294 5 The UPDATE-authenticator attribute 296 The UPDATE-authenticator attribute is an optional, transitive BGP 297 attribute, with an attribute type code value to be assigned. Its 298 length is 24 octets, which is the length of the output of an MD5 299 function (16 octets), a 'Generator' field, and a 'Key-identifier', as 300 shown in the following figure. 302 Behringer, Guichard, Roque 6 303 0 1 2 3 304 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | HMAC-MD5 Signature | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | HMAC-MD5 (cont) | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | HMAC-MD5 (cont) | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | HMAC-MD5 (cont) | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Generator | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Key-identifier | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 6 IANA Considerations 321 The UPDATE-authenticator BGP attribute type will need to be 322 registered with IANA, according to the procedures defined in 323 [RFC2042]. 325 7 Security Considerations 327 This modification to the behavior of the PE router aims at detecting 328 inadvertent configuration mistakes of the Service Provider, and at 329 isolating CE routers that appear not to belong to the VPN they were 330 configured for. 332 There is no protection against the Service Provider staff maliciously 333 adding a CE router to a VPN. However, the malicious engineer must 334 know the MD5 key of the VPN to be intruded. This threat can be 335 avoided with CE-CE IPsec authentication, which is configured by the 336 VPN customer, and to which the Service Provider does not have access. 338 8 Acknowledgements 340 Many thanks to Dan Tappan, David Allan and Eric Vyncke for their 341 contributions to this work. 343 9 References 345 [RFC1771] "A Border Gateway Protocol 4 (BGP-4)". Y. Rekhter, T. Li. 346 March 1995 348 [RFC2042] "Registering New BGP Attribute Types". B. Manning. January 349 1997. 351 Behringer, Guichard, Roque 7 353 [RFC2082] "RIP-2 MD5 Authentication". F. Baker, R. Atkinson. January 354 1997. 356 [RFC2104] "HMAC: Keyed-Hashing for Message Authentication". H. 357 Krawczyk, M. Bellare, R. Canetti. February 1997. 359 [RFC2154] "OSPF with Digital Signatures". S. Murphy, M. Badger, B. 360 Wellington. June 1997. 362 [RFC2385] "Protection of BGP Sessions via the TCP MD5 Signature 363 Option". A. Heffernan. August 1998. 365 [RFC2547] "BGP/MPLS VPNs". E. Rosen, Y. Rekhter. March 1999. 367 [RFC2401] Kent and Atkinson, "Security Architecture for the Internet 368 Protocol, RFC 2401, November 1998. 370 [RFC2858] Rekhter, Y. et al., Multiprotocol Extensions for BGP-4, 371 RFC 2858, June, 2000. 373 10 Authors' Addresses 375 Michael H. Behringer 376 Cisco Systems, Inc. 377 Avda de la Vega, 15; 28100 Alcobendas, Madrid; Spain 378 Email: mbehring@cisco.com 380 Jim Guichard 381 Cisco Systems, Inc. 382 300 Apollo Drive 383 Chelmsford, MA, 01824 384 Email: jguichar@cisco.com 386 Pedro Marques 387 Juniper Networks 388 1194 N. Mathilda Ave. 389 Sunnyvale, CA 94089 390 Email: roque@juniper.net 392 11 Full Copyright Statement 394 Copyright (C) The Internet Society (2000). All Rights Reserved. 396 This document and translations of it may be copied and furnished to 397 others, and derivative works that comment on or otherwise explain it 398 or assist in its implementation may be prepared, copied, published 399 and distributed, in whole or in part, without restriction of any 400 kind, provided that the above copyright notice and this paragraph 401 are included on all such copies and derivative works. However, this 402 document itself may not be modified in any way, such as by removing 404 Behringer, Guichard, Roque 8 405 the copyright notice or references to the Internet Society or other 406 Internet organizations, except as needed for the purpose of 407 developing Internet standards in which case the procedures for 408 copyrights defined in the Internet Standards process must be 409 followed, or as required to translate it into languages other than 410 English. 412 The limited permissions granted above are perpetual and will not be 413 revoked by the Internet Society or its successors or assigns. 415 This document and the information contained herein is provided on an 416 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 417 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 418 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 419 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 420 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 422 Behringer, Guichard, Roque 9