idnits 2.17.00 (12 Aug 2021) /tmp/idnits6234/draft-ymbk-l3vpn-origination-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 2012) is 3498 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) == Unused Reference: 'I-D.ietf-sidr-rpki-rtr' is defined on line 380, but no explicit reference was found in the text == Outdated reference: draft-ietf-sidr-bgpsec-algs has been published as RFC 8208 ** Downref: Normative reference to an Informational RFC: RFC 4808 ** Downref: Normative reference to an Informational RFC: RFC 6480 == Outdated reference: draft-ietf-sidr-pfx-validate has been published as RFC 6811 == Outdated reference: draft-ietf-sidr-rpki-rtr has been published as RFC 6810 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft Internet Initiative Japan 4 Intended status: Standards Track K. Patel 5 Expires: April 02, 2013 P. Mehta 6 A. Sreekantiah 7 Cisco Systems 8 L. Jalil 9 Verizon 10 October 2012 12 Authenticating L3VPN Origination Signaling 13 draft-ymbk-l3vpn-origination-02 15 Abstract 17 A BGP-signaled Layer-3 VPN's prefix bindings sent over BGP are 18 subject to unintentional errors, both by the legitimate originator 19 and by non-legitimate origins. This is of special concern if the VPN 20 traverses untrusted networks. This document describes how the sender 21 of the Prefix/VPN binding may sign it so that recipient of the 22 binding may authenticate it. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 28 be interpreted as described in RFC 2119 [RFC2119] only when they 29 appear in all upper case. They may also appear in lower or mixed 30 case as English words, without normative meaning. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 02, 2013. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 This document may not be modified, and derivative works of it may not 64 be created, and it may not be published except as an Internet-Draft. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. NLRI Deaggregation . . . . . . . . . . . . . . . . . . . . . . 3 70 3. L3VPN Origination BGP Path Attribute (L3OPA) . . . . . . . . . 3 71 4. Validation of Routes Having an L3OPA . . . . . . . . . . . . . 4 72 5. L3VPN Deployment Scenarios . . . . . . . . . . . . . . . . . . 5 73 5.1. End CE to CE Authentication . . . . . . . . . . . . . . . 5 74 5.2. Provider/ASBR Based Validation/Authentication . . . . . . 5 75 5.3. PE-PE Based Validation . . . . . . . . . . . . . . . . . . 6 76 6. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 82 10.2. Informative References . . . . . . . . . . . . . . . . . 8 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 85 1. Introduction 87 RFC 4364 [RFC4364] Section 7.4 describes how a Customer Edge (CE) 88 router uses eBGP to announce to a Provider Edge (PE) router the 89 address prefix(es) the customer provides to an L3VPN. It is possible 90 that the originator of such an announcement could unintentionally 91 announce prefixes they do not own. 93 Cust(West)-CE--PE-Provider(West)--TransitA-~ 94 ~-TransitB--Provider(East)-PE--CE-Cust(East) 96 This document describes how the PE receiving the CE's originating 97 announcement, West, may sign the announcement so that the PE proximal 98 to the destination CE, East, may authenticate the NLRI see RFC 4364 99 [RFC4364] Section 4.3.1. Alternatively, the originating CE router 100 may sign the announcement so that the destination CE router may 101 authenticate the NLRI. 103 It is assumed that the providers already have the key creation, 104 storage, and distribution infrastructure needed. Keys might be 105 configured on the routers, or in some shared PKI, or, for example, 106 the Resource Public Key Infrastructure (RPKI) could be used, see RFC 107 6480 [RFC6480]. 109 A new BGP PATH Attribute, called L3VPN Origination BGP PATH Attribute 110 (L3OPA), is created to contain the necessary keying information and 111 signature. 113 2. NLRI Deaggregation 115 Normally, a BGP Update may contain multiple NLRI which all share the 116 identical set of attributes. As L3OPA signalling signs over the 117 NLRI, and NLRI can become separated as they transit the network, 118 separation would break the signature. Therefore, a BGP announcement 119 using L3OPA signalling MUST contain one and only one NLRI. 121 3. L3VPN Origination BGP Path Attribute (L3OPA) 123 The L3OPA is a BGP optional transitive Path Attribute RFC 4271 124 [RFC4271]. BGP Path Attributes are Type/Length/Value tuples. 126 .-------------------------------------------. 127 | | 128 | Attribute Header, see RFC 4271 S. 4.3 | 129 | | 130 +-------------------------------------------+ 131 | | 132 | | 133 | | 134 +---- Key Identifier ----+ 135 | | 136 | | 137 | | 138 +-------------------------------------------+ 139 | Alg | MUST | | 140 | Suite | be | Signature Length | 141 | 1 | Zero | | 142 +-------------------------------------------+ 143 | | 144 | Signature | 145 | | 146 `-------------------------------------------' 148 The Attribute Type is two octets, the first of which, Attribute 149 Flags, MUST have the two high order bits set to signify that 150 attribute is optional and transitive. 152 The second octet of the Attribute Flags, Attribute Type, MUST be set 153 to 0xXX, as assigned by the IANA, see Section 8, to signal that this 154 is an L3OPA. 156 The Length field is one or two octets with a value of the number of 157 octets in the entire attribute. If the length of the L3OPA is less 158 than 256 octets, only the first octet of the length field is used. 159 Otherwise, both octets are used to represent the Length.. See RFC 160 4271 [RFC4271] Section 4.2 for another explanation of this byte 161 saving. 163 The Key Identifier is an eight octet value identifying the key (pair) 164 used for the Signature. It is used when the keying is not implied by 165 the NLRI, as it would be, for example, if the RPKI was used. It is 166 often the VPN Identifier. If not used to identify the key, it MUST 167 be zero. 169 The Algorithm Suite is a one-octet identifier specifying the digest 170 algorithm and digital signature algorithm used to produce the 171 Signature. The values reference the IANA registry for Algorithm 172 Identifiers from BGPsec, see [I-D.ietf-sidr-bgpsec-algs]. 174 The Signature Length is two octets and is the number of octets in the 175 Signature field. 177 The Signature field is a digital signature that covers the NLRI and 178 the Key Identifier. 180 To compute the Signature, the digest algorithm for the specified 181 Algorithm Suite is applied to the catenation of the NLRI and the Key 182 Identifier. This is then fed to the signature algorithm for the 183 specified algorithm suite and the resulting value is the Signature. 185 Signature = sign ( hash ( NLRI || Key Identifier ) ) 187 4. Validation of Routes Having an L3OPA 189 A BGP speaker receiving routes with an L3OPA MUST perform the 190 necessary validation if configured to do so. 192 The digest algorithm for the specified Algorithm Suite is applied to 193 the catenation of the NLRI and the Key Identifier. This is then fed 194 to the signature algorithm for the specified algorithm suite and the 195 resulting value is compared with the Signature. 197 If the signature value matches the Signature in the attribute, the 198 route MUST be marked as Valid, otherwise it MUST be marked as 199 Invalid. 201 A route received without an L3OPA SHOULD be marked as having an 202 Unknown validity state. 204 If L3OPA marking is disabled in the router configuration, routes are 205 considered to have the Unknown validity state. 207 Configured local policy on the router may use the validity state 208 markings to implement policy. For example, a route marked as Invalid 209 or Unknown may be dropped or de-preferenced by appropriate use of 210 normal BGP policy mechanisms. 212 Note that this is similar to annuncement marking while allowing the 213 user to control policy as described in RPKI-Based BGP origin 214 validation, see [I-D.ietf-sidr-pfx-validate]. 216 5. L3VPN Deployment Scenarios 218 The following L3VPN deployment scenarios illustrate use of the 219 scheme. The examples use the language of symmetric keys which have 220 been previously agreed upon between the signer of the route and the 221 validator. Asymmetric keying, a PKI, etc. could also be used. 222 Signing and validation are as described above. 224 5.1. End CE to CE Authentication 226 CE1 ---- PE1 --------- PE2 -- CE2 227 AS1 229 CE1 ---- PE1 --------- ASBR1 ----- ASBR2 -------- PE2 ---- CE2 230 AS1 AS2 232 CE1 and CE2 are end CEs in the same VPN. PE1, PE2, ASBR1, ASBR2 are 233 provider PE/ASBRs which are blindly propagating the announcement with 234 the L3OPA as generated by CE1. 236 As the authorization is between the originating CE1 and the 237 terminating CE2, the keying should not be known by the provider(s). 238 The CEs are configured with the keying information, the originating 239 CE1 creates and signs an L3OPA for each NLRI participating in the 240 VPN. 242 An update received by CE2 without an L3OPA, or having an Invalid 243 Signature would likely be dropped. Thus the CEs are protected from 244 incorrect prefixes originating from a provider network or 245 unauthorized CEs. 247 5.2. Provider/ASBR Based Validation/Authentication 249 CE1 ---- PE1 --------- ASBR1 ----- ASBR2 -------- PE2 ---- CE2 250 AS1 AS2 252 In the diagram, CE1 is the originating/signing CE. ASBR2 is the 253 trusted provider with whom CE1 has collaborated. Updates generated 254 by CE1 may be passed transparently through any number of intermediate 255 providers, ASBR1s, which blindly propagate the L3OPA. Validation is 256 performed when the announcement reaches the trusted validating 257 provider, ASBR2. 259 Keying is agreed between CE1 and the trusted provider ASBR2, likely 260 on per-VPN basis. 262 5.3. PE-PE Based Validation 264 CE1 ------ PE1 --------- ASBR1 ---- ASBR2 -------- PE2 ------ CE2 265 AS1 | AS2 266 | 267 CE3 ---- ASBR3 ----+ 268 AS3 270 Here PEs, possibly across ASes, agree on the keying. The Key 271 Identifier and associated keys would normally be configured on a per 272 VPN basis, with the PE1 signing and PE2 and PE3 validating similarly 273 to the CEs in the previous examples. 275 CE1 originates an announcement, possibly with multiple NLRI, but 276 without an L3OPA. PE1 de-aggregates the NLRI into separate 277 announcements, signs each with the keying agreed with PE2 and PE3, 278 and propagates them. Arbitrary providers carry the announcements 279 toward PE2 and PE3, where the announcements have their Signatures 280 validated, the L3OPAs removed, and are then propagated to CE2 and 281 CE3. 283 6. Notes 285 The keying could either come from the Global RPKI or the customer or 286 carrier running their own PKI. The keying is assumed to be 287 asymmetric, but possibly could be symmetric. The keys can be 288 statically configured (beware scaling and key-roll issues), dynamic, 289 in some public or private infrastructure, etc. 291 If the RPKI is used, and the public key is taken from the CA 292 certificate which owns the NLRI, the classic problem arises where all 293 the NLRI on that certificate share fate. I.e. if one causes the 294 need for a re-key, then all must re-key. RPKI-based origin 295 validation solves this problem by a level of indirection, the CA 296 certificate is used to sign an End Entity (EE) certificate which 297 signs a Route Origin Authorization (ROA), see RFC 6480 [RFC6480] and 298 RFC 6482 [RFC6482]. As the Key Identifier of an L3VPN signal is 299 larger than the four octets of a ROA, a new RPKI object, for the 300 moment let's call it a VOA, would have to be defined and then it 301 would have to be carried in the RPKI-Router Protocol [I-D.ietf-sidr- 302 rpki-rtr]. 304 If the value of the signing key, as identified by the Key Identifier, 305 is to be rolled, in case of compromise or security policy, the 306 technique in RFC 4808 [RFC4808] should be used. 308 While it is poor security practice to trust a different entity for 309 your security/authentication/..., should a non-validating router 310 choose to trust a validating router, they could use normal policy and 311 signaling mechanisms, e.g. communities, to signal validation status. 312 This page is too small to enumerate the vulnerabilities this creates. 314 7. Security Considerations 316 Signing (NLRI || Key Identifier) with the key of the NLRI-owner or 317 some other pre-agreed key, only says that the contents were produced 318 by the owner of the key (NLRI or other), and that no one in between 319 has changed the (NLRI || Key Identifier). This is not protection 320 against attacks, only configuration errors, aka 'fat fingers'. If we 321 were trying to protect against an attacking PE replaying a signed ( 322 NLRI || Key Identifier) it has no business announcing, this design 323 does not help. 325 If Key Identifier based keying is used, then the Key Identifier, and 326 hence the signing key, MUST be unique to the VPN. 328 Adding a VOA which binds ( NLRI || Key Identifier ) still could be 329 replayed from anywhere so really offers nothing. Like RPKI-based 330 origin validation, this only catches fat fingers, not black hats. 332 8. IANA Considerations 334 This document requests the IANA create a new entry in the BGP Path 335 Attributes Registry as follows: 337 Value Code Reference 338 ----- ----------------- --------- 339 TBD L3VPN Origination This Document 341 9. Acknowledgements 343 The authors would like to thank Eric Rosen, John Scudder, Russ 344 Housley, and Sandy Murphy. 346 We note the long expired draft draft-ietf-l3vpn-auth by Ron Bonica, 347 Yakov Rekhter, Eric Rosen, Robert Raszuk, and Dan Tappan. 349 10. References 351 10.1. Normative References 353 [I-D.ietf-sidr-bgpsec-algs] 354 Turner, S., "BGP Algorithms, Key Formats, & Signature 355 Formats", Internet-Draft draft-ietf-sidr-bgpsec-algs-03, 356 September 2012. 358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", BCP 14, RFC 2119, March 1997. 361 [RFC4271] Rekhter, Y., Li, T. and S. Hares, "A Border Gateway 362 Protocol 4 (BGP-4)", RFC 4271, January 2006. 364 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 365 Networks (VPNs)", RFC 4364, February 2006. 367 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC 368 4808, March 2007. 370 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 371 Secure Internet Routing", RFC 6480, February 2012. 373 10.2. Informative References 375 [I-D.ietf-sidr-pfx-validate] 376 Mohapatra, P., Scudder, J., Ward, D., Bush, R. and R. 377 Austein, "BGP Prefix Origin Validation", Internet-Draft 378 draft-ietf-sidr-pfx-validate-10, October 2012. 380 [I-D.ietf-sidr-rpki-rtr] 381 Bush, R. and R. Austein, "The RPKI/Router Protocol", 382 Internet-Draft draft-ietf-sidr-rpki-rtr-26, February 2012. 384 [RFC6482] Lepinski, M., Kent, S. and D. Kong, "A Profile for Route 385 Origin Authorizations (ROAs)", RFC 6482, February 2012. 387 Authors' Addresses 389 Randy Bush 390 Internet Initiative Japan 391 5147 Crystal Springs 392 Bainbridge Island, Washington 98110 393 US 395 Email: randy@psg.com 397 Keyur Patel 398 Cisco Systems 399 170 W. Tasman Drive 400 San Jose, CA 95134 401 USA 403 Email: keyupate@cisco.com 405 Pranav Mehta 406 Cisco Systems 407 170 W. Tasman Drive 408 San Jose, CA 95134 409 USA 411 Email: pmehta@cisco.com 412 Arjun Sreekantiah 413 Cisco Systems 414 170 W. Tasman Drive 415 San Jose, CA 95134 416 USA 418 Email: asreekan@cisco.com 420 Luay Jalil 421 Verizon 422 1201 E Arapaho Rd. 423 Richardson, TX 75081 424 USA 426 Email: luay.jalil@verizon.com