idnits 2.17.1 draft-ietf-sidr-bgpsec-protocol-06.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 : ---------------------------------------------------------------------------- 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 22, 2012) is 4204 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: '15' is defined on line 1559, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4893 (ref. '4') (Obsoleted by RFC 6793) ** Downref: Normative reference to an Informational RFC: RFC 6480 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Lepinski, Ed. 3 Internet-Draft BBN 4 Intended status: Standards Track October 22, 2012 5 Expires: April 25, 2013 7 BGPSEC Protocol Specification 8 draft-ietf-sidr-bgpsec-protocol-06 10 Abstract 12 This document describes BGPSEC, an extension to the Border Gateway 13 Protocol (BGP) that provides security for the path of autonomous 14 systems through which a BGP update message passes. BGPSEC is 15 implemented via a new optional non-transitive BGP path attribute that 16 carries a digital signature produced by each autonomous system that 17 propagates the update message. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 23 "OPTIONAL" are to be interpreted as described in RFC 2119 [1] only 24 when they appear in all upper case. They may also appear in lower or 25 mixed case as English words, without normative meaning 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 25, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. BGPSEC Negotiation . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. BGPSEC Send Capability . . . . . . . . . . . . . . . . . . 3 64 2.2. BGPSEC Receive Capability . . . . . . . . . . . . . . . . 4 65 2.3. Negotiating BGPSEC Support . . . . . . . . . . . . . . . . 5 66 3. The BGPSEC_Path Attribute . . . . . . . . . . . . . . . . . . 6 67 3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 8 68 3.2. Signature_Block . . . . . . . . . . . . . . . . . . . . . 9 69 4. Generating a BGPSEC Update . . . . . . . . . . . . . . . . . . 11 70 4.1. Originating a New BGPSEC Update . . . . . . . . . . . . . 12 71 4.2. Propagating a Route Advertisement . . . . . . . . . . . . 14 72 4.3. Processing Instructions for Confederation Members . . . . 18 73 4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . . 20 74 5. Processing a Received BGPSEC Update . . . . . . . . . . . . . 21 75 5.1. Overview of BGPSEC Validation . . . . . . . . . . . . . . 23 76 5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . . 24 77 6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 28 78 6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 28 79 6.2. Extensibility Considerations . . . . . . . . . . . . . . . 28 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 82 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 83 9.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 32 84 9.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 34 85 10. Normative References . . . . . . . . . . . . . . . . . . . . . 34 86 11. Informative References . . . . . . . . . . . . . . . . . . . . 35 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35 89 1. Introduction 91 This document describes BGPSEC, a mechanism for providing path 92 security for Border Gateway Protocol (BGP) [2] route advertisements. 93 That is, a BGP speaker who receives a valid BGPSEC update has 94 cryptographic assurance that the advertised route has the following 95 two properties: 97 1. The route was originated by an AS that has been explicitly 98 authorized by the holder of the IP address prefix to originate 99 route advertisements for that prefix. 101 2. Every AS on the path of ASes through which the update message 102 passes has explicitly authorized the advertisement of the route 103 to the subsequent AS in the path. 105 This document specifies a new optional (non-transitive) BGP path 106 attribute, BGPSEC_Path. It also describes how a BGPSEC-compliant BGP 107 speaker (referred to hereafter as a BGPSEC speaker) can generate, 108 propagate, and validate BGP update messages containing this attribute 109 to obtain the above assurances. 111 BGPSEC relies on the Resource Public Key Infrastructure (RPKI) 112 certificates that attest to the allocation of AS number and IP 113 address resources. (For more information on the RPKI, see [7] and 114 the documents referenced therein.) Any BGPSEC speaker who wishes to 115 send BGP update messages to external peers (eBGP) containing the 116 BGPSEC_Path needs to have the private key associated with an RPKI 117 router certificate [10] that corresponds to the BGPSEC speaker's AS 118 number. Note, however, that a BGPSEC speaker does not need such a 119 certificate in order to validate update messages containing the 120 BGPSEC_Path attribute. 122 2. BGPSEC Negotiation 124 This document defines two new BGP capabilities [6] that allow a BGP 125 speaker to advertise to a neighbor the ability (respectively) to send 126 or to receive BGPSEC update messages (i.e., update messages 127 containing the BGPSEC_Path attribute). 129 2.1. BGPSEC Send Capability 131 This capability has capability code : TBD 133 The capability length for this capability MUST be set to 3. 135 The three octets of the capability value are specified as follows. 137 BGPSEC Send Capability Value: 139 0 1 2 3 4 5 6 7 140 +---------------------------------------+ 141 | Version | Reserved | 142 +---------------------------------------+ 143 | | 144 +------ AFI -----+ 145 | | 146 +---------------------------------------+ 148 The first four bits of the first octet indicate the version of BGPSEC 149 for which the BGP speaker is advertising support. This document 150 defines only BGPSEC version 0 (all four bits set to zero). Other 151 versions of BGPSEC may be defined in future documents. A BGPSEC 152 speaker MAY advertise support for multiple versions of BGPSEC by 153 including multiple versions of the BGPSEC capability in its BGP OPEN 154 message. 156 The remaining four bits of the first octet are reserved for future 157 use. These bits are set to zero by the sender of the capability and 158 ignored by the receiver of the capability. 160 The second and third octets contain the 16-bit Address Family 161 Identifier (AFI) which indicates the address family for which the 162 BGPSEC speaker is advertising support for BGPSEC. This document only 163 specifies BGPSEC for use with two address families, IPv4 and IPv6, 164 AFI values 1 and 2 respectively. BGPSEC for use with other address 165 families may be specified in future documents. 167 2.2. BGPSEC Receive Capability 169 This capability has capability code : TBD 171 The capability length for this capability MUST be set to 3. 173 The three octets of the capability value are specified as follows. 175 BGPSEC Receive Capability Value: 177 0 1 2 3 4 5 6 7 178 +---------------------------------------+ 179 | Version | Reserved | 180 +---------------------------------------+ 181 | | 182 | AFI | 183 | | 184 +---------------------------------------+ 186 The first four bits of the first octet indicate the version of BGPSEC 187 for which the BGP speaker is advertising support. This document 188 defines only BGPSEC version 0 (all four bits set to zero). Other 189 versions of BGPSEC may be defined in future documents. A BGPSEC 190 speaker MAY advertise support for multiple versions of BGPSEC by 191 including multiple versions of the BGPSEC capability in its BGP OPEN 192 message. 194 The remaining four bits of the first octet are reserved for future 195 use. These bits are set to zero by the sender of the capability and 196 ignored by the receiver of the capability. 198 The second and third octets contain the 16-bit Address Family 199 Identifier (AFI) which indicates the address family for which the 200 BGPSEC speaker is advertising BGPSEC support. This document only 201 specifies BGPSEC for use with two address families, IPv4 and IPv6, 202 AFI values 1 and 2 respectively. BGPSEC for use with other address 203 families may be specified in future documents. 205 2.3. Negotiating BGPSEC Support 207 A BGP speaker sends the BGPSEC Send Capability (see Section 2.1) in 208 order to indicate that the speaker is willing to send BGP update 209 messages containing the BGPSEC_Path attribute (for a particular 210 address family). A BGP speaker sends the BGPSEC Receive Capability 211 (see Section 2.2) in order to indicate that the speaker is willing to 212 receive messages containing the BPGSEC_Path attribute. 214 Note that if the BGPSEC speaker wishes to use BGPSEC with two 215 different address families (i.e., IPv4 and IPv6) over the same BGP 216 session, then the speaker includes two instances of this capability 217 (one for each address family) in the BGP OPEN message. A BGPSEC 218 speaker SHOULD NOT advertise the capability of BGPSEC support for a 219 particular AFI unless it has also advertised the multiprotocol 220 extension capability for the same AFI combination [3]. 222 In a session where BGP session, a peer is permitted to send update 223 messages containing the BGPSEC_Path attribute if, and only if: 225 o The given peer has sent the BGPSEC Send Capability for a 226 particular version of BGPSEC and a particular address family; and 228 o The other peer has sent the BGPSEC Receive Capability for the same 229 version of BGPSEC and the same address family. 231 In such a session, we say that the use of (the particular version of) 232 BGPSEC has been negotiated (for a particular address family). BGP 233 update messages without the BGPSEC_PATH attribute MAY be sent within 234 a session regardless of whether or not the use of BGPSEC is 235 successfully negotiated. However, if BGPSEC is not successfully 236 negotiated, then BGP update messages containing the BGPSEC_PATH 237 attribute MUST NOT be sent. 239 This document defines the behavior of implementations in the case 240 where BGPSEC version zero is the only version that has been 241 successfully negotiated. If there exist multiple versions have 242 BGPSEC that are negotiated for a particular session, the behavior of 243 the peers (e.g., which version of BGPSEC shall actually be used) will 244 be specified in a future document. 246 BGPSEC cannot provide meaningful security guarantees without support 247 for four-byte AS numbers. Therefore, any BGP speaker that announces 248 the capability to send BGPSEC messages, MUST also announce the 249 capability for four-byte AS support [4]. If a BGP speaker sends the 250 BGPSEC send capability but not the four-byte AS support capability 251 then BGPSEC has not been successfully negotiated, and update messages 252 containing the BGPSEC_Path attribute MUST NOT be sent within such a 253 session. 255 Note that BGPSEC update messages can be quite large, therefore any 256 BGPSEC speaker announcing the capability to receive BGPSEC messages 257 SHOULD also announce support for the capability to receive BGP 258 extended messages [9]. 260 3. The BGPSEC_Path Attribute 262 The BGPSEC_Path attribute is a new optional non-transitive BGP path 263 attribute. 265 This document registers a new attribute type code for this attribute 266 : TBD 268 The BGPSEC_Path attribute carries the secured information regarding 269 the path of ASes through which an update message passes. This 270 includes the digital signatures used to protect this information. We 271 refer to those update messages that contain the BGPSEC_Path attribute 272 as "BGPSEC Update messages". The BGPSEC_Path attribute replaces the 273 AS_PATH attribute in a BGPSEC update message. That is, update 274 messages that contain the BGPSEC_Path attribute MUST NOT contain the 275 AS_PATH attribute, and vice versa. 277 The BGPSEC_Path attribute is made up of several parts. The following 278 high-level diagram provides an overview of the structure of the 279 BGPSEC_Path attribute: 281 High-Level Diagram of the BGPSEC_Path Attribute 282 +---------------------------------------------------------+ 283 | +-----------------+ | 284 | | Secure Path | | 285 | +-----------------+ | 286 | | AS X | | 287 | | pCount X | | 288 | | Flags X | | 289 | | AS Y | | 290 | | pCount Y | | 291 | | Flags Y | | 292 | | ... | | 293 | +-----------------+ | 294 | | 295 | +-----------------+ +-----------------+ | 296 | | Sig Block 1 | | Sig Block 2 | | 297 | +-----------------+ +-----------------+ | 298 | | Alg Suite 1 | | Alg Suite 2 | | 299 | | SKI X1 | | SKI X1 | | 300 | | Signature X1 | | Signature X1 | | 301 | | SKI Y1 | | SKI Y1 | | 302 | | Signature Y1 | | Signature Y1 | | 303 | | ... | | .... | | 304 | +-----------------+ +-----------------+ | 305 | | 306 +---------------------------------------------------------+ 308 The following is the specification of the format for the BGPSEC_Path 309 attribute. 311 BGPSEC_Path Attribute 313 +-------------------------------------------------------+ 314 | Secure_Path (variable) | 315 +-------------------------------------------------------+ 316 | Sequence of one or two Signature_Blocks (variable) | 317 +-------------------------------------------------------+ 319 The Secure_Path contains AS path information for the BGPSEC update 320 message. This is logically equivalent to the information that is 321 contained in a non-BGPSEC AS_PATH attribute. A BGPSEC update message 322 containing the BGPSEC_PATH attribute MUST NOT contain the AS_PATH 323 attribute. The Secure_Path is used by BGPSEC speakers in the same 324 way that information from the AS_PATH is used by non-BGPSEC speakers. 325 The format of the Secure_Path is described below in Section 3.1. 327 The BGPSEC_Path attribute will contain one or two Signature_Blocks, 328 each of which corresponds to a different algorithm suite. Each of 329 the Signature_Blocks will contain a signature segment for one AS 330 number (i.e, secure path segment) in the Secure_Path. In the most 331 common case, the BGPSEC_Path attribute will contain only a single 332 Signature_Block. However, in order to enable a transition from an 333 old algorithm suite to a new algorithm suite (without a flag day), it 334 will be necessary to include two Signature_Blocks (one for the old 335 algorithm suite and one for the new algorithm suite) during the 336 transition period. (See Section 6.1 for more discussion of algorithm 337 transitions.) The format of the Signature_Blocks is described below 338 in Section 3.2. 340 3.1. Secure_Path 342 Here we provide a detailed description of the Secure_Path information 343 in the BGPSEC_Path attribute. 345 Secure_Path 347 +-----------------------------------------------+ 348 | Secure_Path Length (2 octets) | 349 +-----------------------------------------------+ 350 | One or More Secure_Path Segments (variable) | 351 +-----------------------------------------------+ 353 The Secure_Path Length contains the length (in octets) of the entire 354 Secure_Path (including the two octets used to express this length 355 field). As explained below, each Secure_Path segment is six octets 356 long. Note that this means the Secure_Path Length is two greater 357 than six times the number Secure_Path Segments (i.e., the number of 358 AS numbers in the path). 360 The Secure_Path contains one Secure_Path Segment for each (distinct) 361 Autonomous System in the path to the originating AS of the NLRI 362 specified in the update message. 364 Secure_Path Segment 366 +----------------------------+ 367 | AS Number (4 octets) | 368 +----------------------------+ 369 | pCount (1 octet) | 370 +----------------------------+ 371 | Flags (1 octet) | 372 +----------------------------+ 374 The AS Number is the AS number of the BGP speaker that added this 375 Secure_Path segment to the BGPSEC_Path attribute. (See Section 4 for 376 more information on populating this field.) 378 The pCount field contains the number of repetitions of the associated 379 autonomous system number that the signature covers. This field 380 enables a BGPSEC speaker to mimic the semantics of prepending 381 multiple copies of their AS to the AS_PATH without requiring the 382 speaker to generate multiple signatures. 384 The first bit of the Flags field is the Confed_Segment flag. The 385 Confed_Segment flag is set to one to indicate that the BGPSEC speaker 386 that constructed this Secure_Path segment is sending the update 387 message to a peer AS within the same Autonomous System confederation 388 [5]. (That is, the Confed_Segment flag is set in a BGPSEC update 389 message whenever in a non-BGPSEC update message the BGP speaker's AS 390 would appear in a AS_PATH segment of type AS_CONFED_SEQUENCE.) In 391 all other cases the Confed_Segment flag is set to zero. 393 The remaining seven bits of the Flags MUST be set to zero by the 394 sender, and ignored by the receiver. Note, however, that the 395 signature is computed over all eight bits of the flags field. 397 3.2. Signature_Block 399 Here we provide a detailed description of the Signature_Blocks in the 400 BGPSEC_Path attribute. 402 Signature_Block 404 +---------------------------------------------+ 405 | Signature_Block Length (2 octets) | 406 +---------------------------------------------+ 407 | Algorithm Suite Identifier (1 octet) | 408 +---------------------------------------------+ 409 | Sequence of Signature Segments (variable) | 410 +---------------------------------------------+ 412 The Signature_Block Length is the total number of octets in the 413 Signature_Block (including the two octets used to express this length 414 field). 416 The Algorithm Suite Identifier is a one-octet identifier specifying 417 the digest algorithm and digital signature algorithm used to produce 418 the digital signature in each Signature Segment. An IANA registry of 419 algorithm identifiers for use in BGPSEC is created in the BGPSEC 420 algorithms document[11]. 422 A Signature_Block has exactly one Signature Segment for each 423 Secure_Path Segment in the Secure_Path portion of the BGPSEC_Path 424 Attribute. (That is, one Signature Segment for each distinct AS on 425 the path for the NLRI in the Update message.) 427 Signature Segments 428 +---------------------------------------------+ 429 | Subject Key Identifier (20 octets) | 430 +---------------------------------------------+ 431 | Signature Length (2 octets) | 432 +---------------------------------------------+ 433 | Signature (variable) | 434 +---------------------------------------------+ 436 The Subject Key Identifier contains the value in the Subject Key 437 Identifier extension of the RPKI router certificate [10] that is used 438 to verify the signature (see Section 5 for details on validity of 439 BGPSEC update messages). 441 The Signature Length field contains the size (in octets) of the value 442 in the Signature field of the Signature Segment. 444 The Signature contains a digital signature that protects the NLRI and 445 the BGPSEC_Path attribute (see Sections 4 and 5 for details on 446 signature generation and validation, respectively). 448 4. Generating a BGPSEC Update 450 Sections 4.1 and 4.2 cover two cases in which a BGPSEC speaker may 451 generate an update message containing the BGPSEC_Path attribute. The 452 first case is that in which the BGPSEC speaker originates a new route 453 advertisement (Section 4.1). That is, the BGPSEC speaker is 454 constructing an update message in which the only AS to appear in the 455 BGPSEC_Path is the speaker's own AS. The second case is that in 456 which the BGPSEC speaker receives a route advertisement from a peer 457 and then decides to propagate the route advertisement to an external 458 (eBGP) peer (Section 4.2). That is, the BGPSEC speaker has received 459 a BGPSEC update message and is constructing a new update message for 460 the same NLRI in which the BGPSEC_Path attribute will contain AS 461 number(s) other than the speaker's own AS. 463 The remaining case is where the BGPSEC speaker sends the update 464 message to an internal (iBGP) peer. When originating a new route 465 advertisement and sending it to an internal peer, the BGPSEC speaker 466 creates a new BGPSEC_Path attribute with zero Secure_Path segments 467 and zero Signature Segments. When propagating a received route 468 advertisement to an internal peer, the BGPSEC speaker populates the 469 BGPSEC_Path attribute by copying the BGPSEC_Path attribute from the 470 received update message. That is, the BGPSEC_Path attribute is 471 copied verbatim. Note that in the case that a BGPSEC speaker chooses 472 to forward to an iBGP peer a BGPSEC update message that has not been 473 successfully validated (see Section 5), the BGPSEC_Path attribute 474 SHOULD NOT be removed. (See Section 7 for the security ramifications 475 of removing BGPSEC signatures.) 477 The information protected by the signature on a BGPSEC update message 478 includes the AS number of the peer to whom the update message is 479 being sent. Therefore, if a BGPSEC speaker wishes to send a BGPSEC 480 update to multiple BGP peers, it MUST generate a separate BGPSEC 481 update message for each unique peer AS to which the update message is 482 sent. 484 A BGPSEC update message MUST advertise a route to only a single NLRI. 485 This is because a BGPSEC speaker receiving an update message with 486 multiple NLRI would be unable to construct a valid BGPSEC update 487 message (i.e., valid path signatures) containing a subset of the NLRI 488 in the received update. If a BGPSEC speaker wishes to advertise 489 routes to multiple NLRI, then it MUST generate a separate BGPSEC 490 update message for each NLRI. 492 In order to create or add a new signature to a BGPSEC update message 493 with a given algorithm suite, the BGPSEC speaker must possess a 494 private key suitable for generating signatures for this algorithm 495 suite. Additionally, this private key must correspond to the public 496 key in a valid Resource PKI end-entity certificate whose AS number 497 resource extension includes the BGPSEC speaker's AS number [10]. Note 498 also that new signatures are only added to a BGPSEC update message 499 when a BGPSEC speaker is generating an update message to send to an 500 external peer (i.e., when the AS number of the peer is not equal to 501 the BGPSEC speaker's own AS number). Therefore, a BGPSEC speaker who 502 only sends BGPSEC update messages to peers within its own AS, it does 503 not need to possess any private signature keys. 505 4.1. Originating a New BGPSEC Update 507 In an update message that originates a new route advertisement (i.e., 508 an update whose path will contain only a single AS number), when 509 sending the route advertisement to an external, BGPSEC-speaking peer, 510 the BGPSEC speaker creates a new BGPSEC_Path attribute as follows. 512 First, the BGPSEC speaker constructs the Secure_Path with a single 513 Secure_Path Segment. The AS in this path is the BGPSEC speaker's own 514 AS number. In particular, this AS number MUST match an AS number in 515 the AS number resource extension field of the Resource PKI router 516 certificate(s) [10] that will be used to verify the digital 517 signature(s) constructed by this BGPSEC speaker. 519 The BGPSEC_Path attribute and the AS_Path attribute are mutually 520 exclusive. That is, any update message containing the BGPSEC_Path 521 attribute MUST NOT contain the AS_Path attribute. The information 522 that would be contained in the AS_Path attribute is instead conveyed 523 in the Secure_Path portion of the BGPSEC_Path attribute. 525 The Resource PKI enables the legitimate holder of IP address 526 prefix(es) to issue a signed object, called a Route Origination 527 Authorization (ROA), that authorizes a given AS to originate routes 528 to a given set of prefixes (see [8]). Note that validation of a 529 BGPSEC update message will fail (i.e., the validation algorithm, 530 specified in Section 5.2, returns 'Not Valid') unless there exists a 531 valid ROA authorizing the first AS in the Secure_Path portion of the 532 BGPSEC_Path attribute to originate routes to the prefix being 533 advertised. Therefore, a BGPSEC speaker SHOULD NOT originate a 534 BGPSEC update advertising a route for a given prefix unless there 535 exists a valid ROA authorizing the BGPSEC speaker's AS to originate 536 routes to this prefix. 538 The pCount field of the Secure_Path Segment is typically set to the 539 value 1. However, a BGPSEC speaker may set the pCount field to a 540 value greater than 1. Setting the pCount field to a value greater 541 than one has the same semantics as repeating an AS number multiple 542 times in the AS_PATH of a non-BGPSEC update message (e.g., for 543 traffic engineering purposes). Setting the pCount field to a value 544 greater than one permits this repetition without requiring a separate 545 digital signature for each repetition. 547 If the BGPSEC speaker is not a member of an autonomous system 548 confederation [5], then the Flags field of the Secure_Path Segment 549 MUST be set to zero. (Members of a confederation should follow the 550 special processing instructions for confederation members in Section 551 4.4.) 553 Typically, a BGPSEC speaker will use only a single algorithm suite, 554 and thus create only a single Signature_Block in the BGPSEC_Path 555 attribute. However, to ensure backwards compatibility during a 556 period of transition from a 'current' algorithm suite to a 'new' 557 algorithm suite, it will be necessary to originate update messages 558 that contain a Signature_Block for both the 'current' and the 'new' 559 algorithm suites (see Section 6.1). 561 When originating a new route advertisement, each Signature_Block MUST 562 consist of a single Signature Segment. The following describes how 563 the BGPSEC speaker populates the fields of the Signature_Block. 565 The Subject Key Identifier field (see Section 3) is populated with 566 the identifier contained in the Subject Key Identifier extension of 567 the RPKI router certificate corresponding to the BGPSEC speaker[10]. 568 This Subject Key Identifier will be used by recipients of the route 569 advertisement to identify the proper certificate to use in verifying 570 the signature. 572 The Signature field contains a digital signature that binds the NLRI 573 and BGPSEC_Path attribute to the RPKI router corresponding to the 574 BGPSEC speaker. The digital signature is computed as follows: 576 o Construct a sequence of octets by concatenating the Target AS 577 Number, the Secure_Path (Origin AS, pCount, and Flags), Algorithm 578 Suite Identifier, and NLRI. The Target AS Number is the AS to 579 whom the BGPSEC speaker intends to send the update message. (Note 580 that the Target AS number is the AS number announced by the peer 581 in the OPEN message of the BGP session within which the update is 582 sent.) 583 Sequence of Octets to be Signed 584 +------------------------------------+ 585 | Target AS Number (4 octets) | 586 +------------------------------------+ 587 | Origin AS Number (4 octets) | ---\ 588 +------------------------------------+ \ 589 | pCount (1 octet) | > Secure_Path 590 +------------------------------------+ / 591 | Flags (1 octet) | ---/ 592 +------------------------------------+ 593 | Algorithm Suite Id. (1 octet) | 594 +------------------------------------+ 595 | NLRI Length (1 octet) | 596 +------------------------------------+ 597 | NLRI Prefix (variable) | 598 +------------------------------------+ 600 o Apply to this octet sequence the digest algorithm (for the 601 algorithm suite of this Signature_Block) to obtain a digest value. 603 o Apply to this digest value the signature algorithm, (for the 604 algorithm suite of this Signature_Block) to obtain the digital 605 signature. Then populate the Signature Field with this digital 606 signature. 608 The Signature Length field is populated with the length (in octets) 609 of the Signature field. 611 4.2. Propagating a Route Advertisement 613 When a BGPSEC speaker receives a BGPSEC update message containing a 614 BGPSEC_Path attribute (with one or more signatures) from an (internal 615 or external) peer, it may choose to propagate the route advertisement 616 by sending to its (internal or external) peers by creating a new 617 BGPSEC advertisement for the same prefix. 619 If a BGPSEC router has received only a non-BGPSEC update message 620 (without the BGPSEC_Path attribute), containing the AS_Path 621 attribute, from a peer for a given prefix and if it chooses to 622 propagate that peer's route for the prefix, then it MUST NOT attach 623 any BGPSEC_Path attribute to the corresponding update being 624 propagated. (Note that a BGPSEC router may also receive a non-BGPSEC 625 update message from an internal peer without the AS_Path attribute, 626 i.e., with just the NLRI in it. In that case, the prefix is 627 originating from that AS and hence the BGPSEC speaker SHOULD sign and 628 forward the update to its external peers, as specified in Section 629 4.1.) 630 Conversely, if a BGPSEC router has received a BGPSEC update message 631 (with the BGPSEC_Path attribute) from a peer for a given prefix and 632 it chooses to propagate that peer's route for the prefix, then it 633 SHOULD propagate the route as a BGPSEC update message containing the 634 BGPSEC_Path attribute. However, the BGPSEC speaker MAY propagate the 635 route as a (unsigned) BGP update message without the BGPSEC_Path 636 attribute. 638 Note that removing BGPSEC signatures (i.e., propagating a route 639 advertisement without the BGPSEC_Path attribute) has significant 640 security ramifications. (See Section 7 for discussion of the 641 security ramifications of removing BGPSEC signatures.) Therefore, 642 when a route advertisement is received via a BGPSEC update message, 643 propagating the route advertisement without the BGPSEC_Path attribute 644 is NOT RECOMMENDED, unless the message is sent to a peer that did not 645 advertise the capability to receive BGPSEC update messages (see 646 Section 4.4). 648 Furthermore, note that when a BGPSEC speaker propagates a route 649 advertisement with the BGPSEC_Path attribute it is not attesting to 650 the validation state of the update message it received. (See Section 651 7 for more discussion of the security semantics of BGPSEC 652 signatures.) 654 If the BGPSEC speaker is producing an update message which would, in 655 the absence of BGPSEC, contain an AS_SET (e.g., the BGPSEC speaker is 656 performing proxy aggregation), then the BGPSEC speaker MUST NOT 657 include the BGPSEC_Path attribute. In such a case, the BGPSEC 658 speaker must remove any existing BGPSEC_Path in the received 659 advertisement(s) for this prefix and produce a standard (non-BGPSEC) 660 update message. It should be noted that BCP 172 [12] recommends 661 against the use of AS_SET and AS_CONFED_SET in AS_PATH in BGP 662 updates. 664 To generate the BGPSEC_Path attribute on the outgoing update message, 665 the BGPSEC speaker first prepends a new Secure_Path Segment (places 666 in first position) to the Secure_Path. The AS number in this 667 Secure_Path segment MUST match the AS number in the AS number 668 resource extension field of the Resource PKI router certificate(s) 669 that will be used to verify the digital signature(s) constructed by 670 this BGPSEC speaker[10]. 672 The pCount is typically set to the value 1. A BGPSEC speaker may set 673 the pCount field to a value greater than 1. (See Section 4.1 for a 674 discussion of setting pCount to a value greater than 1.) A route 675 server that participates in the BGP control path, but does not act as 676 a transit AS in the data plane, may choose to set pCount to 0. This 677 option enables the route server to participate in BGPSEC and obtain 678 the associated security guarantees without increasing the effective 679 length of the AS path. (Note that BGPSEC speakers compute the 680 effective length of the AS path by summing the pCount values in the 681 BGPSEC_Path attribute, see Section 5.) However, when a route server 682 sets the pCount value to 0, it still inserts its AS number into the 683 Secure_Path segment, as this information is needed to validate the 684 signature added by the route server. Note that the option of setting 685 pCount to 0 is intended only for use by route servers that desire not 686 to increase the effective AS-PATH length of routes they advertise. 687 The pCount field SHOULD NOT be set to 0 in other circumstances. 688 BGPSEC speakers SHOULD drop incoming update messages with pCount set 689 to zero in cases where the BGPSEC speaker does not expect its peer to 690 set pCount to zero (i.e., cases where the peer is not acting as a 691 route server). 693 If the BGPSEC speaker is not a member of an autonomous system 694 confederation [5], then the Confed_Segment bit of the Flags field of 695 the Secure_Path Segment MUST be set to zero. (Members of a 696 confederation should follow the special processing instructions for 697 confederation members in Section 4.3.) 699 If the received BGPSEC update message contains two Signature_ Blocks 700 and the BGPSEC speaker supports both of the corresponding algorithms 701 suites, then the new update message generated by the BGPSEC speaker 702 SHOULD include both of the Signature_Blocks. If the received BGPSEC 703 update message contains two Signature_Blocks and the BGPSEC speaker 704 only supports one of the two corresponding algorithm suites, then the 705 BGPSEC speaker MUST remove the Signature_Block corresponding to the 706 algorithm suite that it does not understand. If the BGPSEC speaker 707 does not support the algorithm suites in any of the Signature_Blocks 708 contained in the received update message, then the BGPSEC speaker 709 MUST NOT propagate the route advertisement with the BGPSEC_Path 710 attribute. (That is, if it chooses to propagate this route 711 advertisement at all, it must do so as an unsigned BGP update 712 message). 714 Note that in the case where there are two Signature_Blocks 715 (corresponding to different algorithm suites) that the validation 716 algorithm (see Section 5.2) deems a BGPSEC update message to be 717 'Valid' if there is at least one supported algorithm suite (and 718 corresponding Signature_Block) that is deemed 'Valid'. This means 719 that a 'Valid' BGPSEC update message may contain a Signature_Block 720 which is not deemed 'Valid' (e.g., contains signatures that the 721 BGPSEC does not successfully verify). Nonetheless, such 722 Signature_Blocks MUST NOT be removed. (See Section 7 for a 723 discussion of the security ramifications of this design choice.) 725 For each Signature_Block corresponding to an algorithm suite that the 726 BGPSEC speaker does support, the BGPSEC speaker then adds a new 727 Signature Segment to the Signature_Block. This Signature Segment is 728 prepended to the list of Signature Segments (placed in the first 729 position) so that the list of Signature Segments appears in the same 730 order as the corresponding Secure_Path segments in the Secure_Path 731 portion of the BGPSEC_Path attribute. The BGPSEC speaker populates 732 the fields of this new signature segment as follows. 734 The Subject Key Identifier field in the new segment is populated with 735 the identifier contained in the Subject Key Identifier extension of 736 the RPKI router corresponding to the BGPSEC speaker[10]. This 737 Subject Key Identifier will be used by recipients of the route 738 advertisement to identify the proper certificate to use in verifying 739 the signature. 741 The Signature field in the new segment contains a digital signature 742 that binds the NLRI and BGPSEC_Path attribute to the RPKI router 743 certificate corresponding to the BGPSEC speaker. The digital 744 signature is computed as follows: 746 o Construct a sequence of octets by concatenating the Target AS 747 number, the Secure_Path segment that is being added by the BGPSEC 748 speaker constructing the signature, and the signature field of the 749 most recent Signature Segment (the one corresponding to AS from 750 whom the BGPSEC speaker's AS received the announcement). Note 751 that the Target AS number is the AS number announced by the peer 752 in the OPEN message of the BGP session within which the BGPSEC 753 update message is sent. 755 Sequence of Octets to be Signed 756 +--------------------------------------+ 757 | Target AS Number (4 octets) | 758 +--------------------------------------+ 759 | Signer's AS Number (4 octets) | ---\ 760 +--------------------------------------+ \ 761 | pCount (1 octet) | > Secure_Path 762 +--------- ----------------------------+ / 763 | Flags (1 octet) | ---/ 764 +--------------------------------------+ 765 | Most Recent Sig Field (variable) | 766 +--------------------------------------+ 768 o Apply to this octet sequence the digest algorithm (for the 769 algorithm suite of this Signature_Block) to obtain a digest value. 771 o Apply to this digest value the signature algorithm, (for the 772 algorithm suite of this Signature_Block) to obtain the digital 773 signature. Then populate the Signature Field with this digital 774 signature. 776 The Signature Length field is populated with the length (in octets) 777 of the Signature field. 779 4.3. Processing Instructions for Confederation Members 781 Members of autonomous system confederations [5] MUST additionally 782 follow the instructions in this section for processing BGPSEC update 783 messages. 785 When a confederation member sends a BGPSEC update message to a peer 786 that is a member of the same confederation, the confederation member 787 puts its (private) Member-AS Number (as opposed to the public AS 788 Confederation Identifier) in the AS Number field of the Secure_Path 789 Segment that it adds to the BGPSEC update message. Furthermore, when 790 a confederation member sends a BGPSEC update message to a peer that 791 is a member of the same confederation, the BGPSEC speaker that 792 generates the Secure_Path Segment sets the Confed_Segment flag to 793 one. Note that this means that in a BGPSEC update message, an AS 794 number appears in a Secure_Path Segment with the Confed_Segment flag 795 set to one, in precisely those circumstances where the AS number 796 would appear in a segment of type AS_CONFED_SEQUENCE in a non-BGPSEC 797 update message. 799 Within a confederation, the verification of BGPSEC signatures added 800 by other members of the confederation is optional. If a 801 confederation chooses to have its members not verify signatures added 802 by other confederation members, then when sending a BGPSEC update 803 message to a peer that is a member of the same confederation, the 804 confederation MAY set the Signature field within the 805 Signature_Segment that it generates to be zero (in lieu of 806 calculating the correct digital signature as described in Sections 807 4.1 and 4.2). Note that if a confederation chooses not to verify 808 digital signatures within the confederation, then BGPSEC is able to 809 provide no assurances about the integrity of the (private) Member-AS 810 Numbers placed in Secure_Path segments where the Confed_Segment flag 811 is set to one. 813 When a confederation member receives a BGPSEC update message from a 814 peer within the confederation and propagates it to a peer outside the 815 confederation, it needs to remove all of the Secure_Path Segments 816 added by confederation members as well as the corresponding Signature 817 Segments. To do this, the confederation member propagating the route 818 outside the confederation does the following: 820 o First, starting with the most recently added Secure_Path segments, 821 remove all of the consecutive Secure_Path segments that have the 822 Confed_Segment flag set to one. Stop this process once a 823 Scure_Path segment is reached which has its Confed_Segment flag 824 set to zero. Keep a count of the number of segments removed in 825 this fashion. 827 o Second, starting with the most recently added Signature Segment, 828 remove a number of Signature Segments equal to the number of 829 Secure_Path Segments removed in the previous step. (That is, 830 remove the K most recently added signature segments, where K is 831 the number of Secure_Path Segments removed in the previous step.) 833 o Finally, add a Secure_Path Segment containing, in the AS field, 834 the AS Confederation Identifier (the public AS number of the 835 confederation) as well as a corresponding Signature Segment. Note 836 that all fields other that the AS field are populated as per 837 Sections 4.1 and 4.2. 839 When validating a received BGPSEC update message, confederation 840 members need to make the following adjustment to the algorithm 841 presented in Section 5.2. When a confederation member processes 842 (validates) a Signature Segment and its corresponding Secure_Path 843 Segment, the confederation member must note that for a signature 844 produced by a BGPSEC speaker outside of a confederation, the Target 845 AS will always be the AS Confederation Identifier (the public AS 846 number of the confederation) as opposed to the Member-AS Number. 848 To handle this case, when a BGPSEC speaker (that is a confederation 849 member) processes a current Secure_Path Segment that has the 850 Confed_Segment flag set to zero, if the next most recently added 851 Secure_Path segment has the Confed_Segment flag set to one then, when 852 computing the digest for the current Secure_Path segment, the BGPSEC 853 speaker takes the Target AS Number to be the AS Confederation 854 Identifier of the validating BGPSEC speaker's own confederation. 855 (Note that the algorithm in Section 5.2 processes Secure_Path 856 Segments in order from most recently added to least recently added, 857 therefore this special case will apply to the first Secure_Path 858 segment that the algorithm encounters that has the Confed_Segment 859 flag set to zero.) 861 Finally, as discussed above, an AS confederation may optionally 862 decide that its members will not verify digital signatures added by 863 members. In such a federation, when a confederation member runs the 864 algorithm in Section 5.2, when processing a Signature_Segment, the 865 confederation member first checks whether the Confed_Sequence flag in 866 the corresponding Secure_Path segment is set to one. If the 867 Confed_Sequence flag is set to one in the corresponding Secure_Path 868 segment, the confederation member does not perform any further checks 869 on the Signature_Segment and immediately moves on to the next 870 Signature_Segment (and checks its corresponding Secure_Path segment). 871 Note that as specified in Section 5.2, it is an error for a BGPSEC 872 speaker to receive a BGPSEC update messages containing a Secure_Path 873 segment with the Confed_Sequence flag set to one from a peer who is 874 not a member of the same AS confederation. (Such an error is treated 875 in exactly the same way as receipt of a non-BGPSEC update message 876 containing an AS_CONFED_SEQUENCE from a peer that is not a member of 877 the same AS confederation.) 879 4.4. Reconstructing the AS_PATH Attribute 881 BGPSEC update messages do not contain the AS_PATH attribute. Note, 882 however, that the AS_PATH attribute can be reconstructed from the 883 BGPSEC_Path attribute. This is necessary in the case where a route 884 advertisement is received via a BGPSEC update message and then 885 propagated to a peer via a non-BGPSEC update message. There may be 886 additional cases where an implementation finds it useful to perform 887 this reconstruction. 889 The AS_PATH attribute can be constructed from the BGPSEC_Path 890 attribute as follows. Starting with an empty AS_PATH attribute, 891 process the Secure_Path segments in order from least-recently added 892 (corresponding to the origin) to most-recently added. For each 893 Secure_Path segment perform the following steps: 895 1. If the Confed_Segment flag in the Secure_Path segment is set to 896 one, then look at the most-recently added segment in the AS_PATH. 898 * In the case where the AS_PATH is empty or in the case where 899 the most-recently added segment is of type AS_SEQUENCE then 900 add (prepend to the AS_PATH) a new AS_PATH segment of type 901 AS_CONFED_SEQUENCE. This segment of type AS_CONFED_SEQUENCE 902 shall contain a number of elements equal to the pCount field 903 in the current Secure_Path segment. Each of these elements 904 shall be the AS number contained in the current Secure_Path 905 segment. (That is, if the pCount field is X, then the segment 906 of type AS_CONFED_SEQUENCE contains X copies of the 907 Secure_Path segment's AS Number field.) 909 * In the case where the most-recently added segment in the 910 AS_PATH is of type AS_CONFED_SEQUENCE then add (prepend to the 911 segment) a number of elements equal to the pCount field in the 912 current Secure_Path segment. The value of each of these 913 elements shall be the AS number contained in the current 914 Secure_Path segment. (That is, if the pCount field is X, then 915 add X copies of the Secure_Path segment's AS Number field to 916 the existing AS_CONFED_SEQUENCE.) 918 2. If the Confed_Segment flag in the Secure_Path segment is set to 919 zero, then look at the most-recently added segment in the 920 AS_PATH. 922 * In the case where the AS_PATH is empty, and the pCount field 923 in the Secure_Path segment is greater than zero, add (prepend 924 to the AS_PATH) a new AS_PATH segment of type AS_SEQUENCE. 925 This segment of type AS_SEQUENCE shall contain a number of 926 elements equal to the pCount field in the current Secure_Path 927 segment. Each of these elements shall be the AS number 928 contained in the current Secure_Path segment. (That is, if 929 the pCount field is X, then the segment of type AS_SEQUENCE 930 contains X copies of the Secure_Path segment's AS Number 931 field.) 933 * In the case where the most recently added segment in the 934 AS_PATH is of type AS_SEQUENCE then add (prepend to the 935 segment) a number of elements equal to the pCount field in the 936 current Secure_Path segment. The value of each of these 937 elements shall be the AS number contained in the current 938 Secure_Path segment. (That is, if the pCount field is X, then 939 add X copies of the Secure_Path segment's AS Number field to 940 the existing AS_SEQUENCE.) 942 5. Processing a Received BGPSEC Update 944 Upon receiving a BGPSEC update message from an external (eBGP) peer, 945 a BGPSEC speaker SHOULD validate the message to determine the 946 authenticity of the path information contained in the BGPSEC_Path 947 attribute. Section 5.1 provides an overview of BGPSEC validation and 948 Section 5.2 provides a specific algorithm for performing such 949 validation. (Note that an implementation need not follow the 950 specific algorithm in Section 5.2 as long as the input/output 951 behavior of the validation is identical to that of the algorithm in 952 Section 5.2.) During exceptional conditions (e.g., the BGPSEC 953 speaker receives an incredibly large number of update messages at 954 once) a BGPSEC speaker MAY temporarily defer validation of incoming 955 BGPSEC update messages. The treatment of such BGPSEC update 956 messages, whose validation has been deferred, is a matter of local 957 policy. 959 The validity of BGPSEC update messages is a function of the current 960 RPKI state. When a BGPSEC speaker learns that RPKI state has changed 961 (e.g., from an RPKI validating cache via the RTR protocol), the 962 BGPSEC speaker MUST re-run validation on all affected update messages 963 stored in its ADJ-RIB-IN. That is, when a given RPKI certificate 964 ceases to be valid (e.g., it expires or revoked), all update messages 965 containing a signature whose SKI matches the SKI in the given 966 certificate must be re-assessed to determine if they are still valid. 967 Note that this reassessment determines that the validity state of an 968 update has changed then, depending on local policy, it may be 969 necessary to re-run best path selection. 971 BGPSEC update messages do not contain an AS_PATH attribute. 972 Therefore, a BGPSEC speaker MUST utilize the AS path information in 973 the BGPSEC_Path attribute in all cases where it would otherwise use 974 the AS path information in the AS_PATH attribute. The only exception 975 to this rule is when AS path information must be updated in order to 976 propagate a route to a peer (in which case the BGPSEC speaker follows 977 the instructions in Section 4). Section 4.4 provides an algorithm 978 for constructing an AS_PATH attribute from a BGPSEC_Path attribute. 979 Whenever the use of AS path information is called for (e.g., loop 980 detection, or use of AS path length in best path selection) the 981 externally visible behavior of the implementation shall be the same 982 as if the implementation had run the algorithm in Section 4.4 and 983 used the resulting AS_PATH attribute as it would for a non-BGPSEC 984 update message. 986 Many signature algorithms are non-deterministic. That is, many 987 signature algorithms will produce different signatures each time they 988 are run (even when they are signing the same data with the same key). 989 Therefore, if an implementation receives a BGPSEC update from a peer 990 and later receives a second BGPSEC update message from the same peer, 991 the implementation SHOULD treat the second message as a duplicate 992 update message if it differs from the first update message only in 993 the Signature fields (within the BGPSEC_Path attribute). That is, if 994 all the fields in the second update are identical to the fields in 995 the first update message, except for the Signature fields, then the 996 second update message should be treated as a duplicate of the first 997 update message. Note that if other fields (e.g., the Subject Key 998 Identifier field) within a Signature segment differ between two 999 update messages then the two updates are not duplicates. 1001 With regards to the processing of duplicate update messages, if the 1002 first update message is valid, then an implementation SHOULD NOT run 1003 the validation procedure on the second, duplicate update message 1004 (even if the bits of the signature field are different). If the 1005 first update message is not valid, then an implementation SHOULD run 1006 the validation procedure on the second duplicate update message (as 1007 the signatures in the second update may be valid even though the 1008 first contained a signature that was invalid). 1010 5.1. Overview of BGPSEC Validation 1012 Validation of a BGPSEC update messages makes use of data from RPKI 1013 certificates and signed Route Origination Authorizations (ROA). In 1014 particular, to validate update messages containing the BGPSEC_Path 1015 attribute, it is necessary that the recipient have access to the 1016 following data obtained from valid RPKI certificates and ROAs: 1018 o For each valid RPKI router certificate containing an AS Number 1019 extension, the AS Number, Public Key and Subject Key Identifier 1020 are required, 1022 o For each valid ROA, the AS Number and the list of IP address 1023 prefixes. 1025 Note that the BGPSEC speaker could perform the validation of RPKI 1026 certificates and ROAs on its own and extract the required data, or it 1027 could receive the same data from a trusted cache that performs RPKI 1028 validation on behalf of (some set of) BGPSEC speakers. (For example, 1029 the trusted cache could deliver the necessary validity information to 1030 the BGPSEC speaker using the router key PDU [15]for the RTR protocol 1031 [14].) 1033 To validate a BGPSEC update message containing the BGPSEC_Path 1034 attribute, the recipient performs the validation steps specified in 1035 Section 5.2. The validation procedure results in one of two states: 1036 'Valid' and 'Not Valid'. 1038 It is expected that the output of the validation procedure will be 1039 used as an input to BGP route selection. However, BGP route 1040 selection and thus the handling of the two validation states is a 1041 matter of local policy, and shall be handled using local policy 1042 mechanisms. It is expected that BGP peers will generally prefer 1043 routes received via 'Valid' BGPSEC update messages over routes 1044 received via 'Not Valid' BGPSEC update messages as well as routes 1045 received via update messages that do not contain the BGPSEC_Path 1046 attribute. However, BGPSEC specifies no changes to the BGP decision 1047 process. (See [16] for related operational considerations.) 1049 BGPSEC validation needs only be performed at eBGP edge. The 1050 validation status of a BGP signed/unsigned update MAY be conveyed via 1051 iBGP from an ingress edge router to an egress edge router via some 1052 mechanism, according to local policy within an AS. As discussed in 1053 Section 4, when a BGPSEC speaker chooses to forward a (syntactically 1054 correct) BGPSEC update message, it SHOULD be forwarded with its 1055 BGPSEC_Path attribute intact (regardless of the validation state of 1056 the update message). Based entirely on local policy, an egress 1057 router receiving a BGPSEC update message from within its own AS MAY 1058 choose to perform its own validation. 1060 5.2. Validation Algorithm 1062 This section specifies an algorithm for validation of BGPSEC update 1063 messages. A conformant implementation MUST include a BGPSEC update 1064 validation algorithm that is functionally equivalent to the 1065 externally visible behavior of this algorithm. 1067 First, the recipient of a BGPSEC update message performs a check to 1068 ensure that the message is properly formed. Specifically, the 1069 recipient performs the following checks: 1071 1. Check to ensure that the entire BGPSEC_Path attribute is 1072 syntactically correct (conforms to the specification in this 1073 document). 1075 2. Check that each Signature_Block contains one Signature segment 1076 for each Secure_Path segment in the Secure_Path portion of the 1077 BGPSEC_Path attribute. (Note that the entirety of each 1078 Signature_Block must be checked to ensure that it is well formed, 1079 even though the validation process may terminate before all 1080 signatures are cryptographically verified.) 1082 3. Check that the update message does not contain an AS_PATH 1083 attribute. 1085 4. If the update message was received from a peer that is not a 1086 member of the BGPSEC speaker's AS confederation, check to ensure 1087 that none of the Secure_Path segments contain a Flags field with 1088 the Confed_Sequence flag set to one. 1090 5. If the update message was received from a peer that is not 1091 expected to set pCount equal to zero (see Section 4.2) then check 1092 to ensure that the pCount field in the most-recently added 1093 Secure_Path segment is not equal to zero. 1095 If any of these checks identify an error in the BGPSEC_Path 1096 attribute, then the implementation should notify the operator that an 1097 error has occurred and treat the update in a manner consistent with 1098 other BGP errors (i.e., following RFC 4271[2] or any future updates 1099 to that document). 1101 Next, the BGPSEC speaker verifies that the origin AS is authorized to 1102 advertise the prefix in question. To do this, consult the valid ROA 1103 data to obtain a list of AS numbers that are associated with the 1104 given IP address prefix in the update message. Then locate the last 1105 (least recently added) AS number in the Secure_Path portion of the 1106 BGPSEC_Path attribute. If the origin AS in the Secure_Path is not in 1107 the set of AS numbers associated with the given prefix, then the 1108 BGPSEC update message is 'Not Valid' and the validation algorithm 1109 terminates. 1111 Finally, the BGPSEC speaker examines the Signature_Blocks in the 1112 BGPSEC_Path attribute. A Signature_Block corresponding to an 1113 algorithm suite that the BGPSEC speaker does not support is not 1114 considered in validation. If there does not exist a Signature_Block 1115 corresponding to an algorithm suite that the BGPSEC speaker supports, 1116 then the BGPSEC speaker MUST treat the update message in the same 1117 manner that the BGPSEC speaker would treat an (unsigned) update 1118 message that arrived without a BGPSEC_Path attribute. 1120 For each remaining Signature_Block (corresponding to an algorithm 1121 suite supported by the BGPSEC speaker), the BGPSEC speaker iterates 1122 through the Signature segments in the Signature_Block, starting with 1123 the most recently added segment (and concluding with the least 1124 recently added segment). Note that there is a one-to-one 1125 correspondence between Signature segments and Secure_Path segments 1126 within the BGPSEC_Path attribute. The following steps make use of 1127 this correspondence. 1129 o (Step I): Locate the public key needed to verify the signature (in 1130 the current Signature segment). To do this, consult the valid 1131 RPKI router certificate data and look up all valid (AS, SKI, 1132 Public Key) triples in which the AS matches the AS number in the 1133 corresponding Secure_Path segment. Of these triples that match 1134 the AS number, check whether there is an SKI that matches the 1135 value in the Subject Key Identifier field of the Signature 1136 segment. If this check finds no such matching SKI value, then 1137 mark the entire Signature_Block as 'Not Valid' and proceed to the 1138 next Signature_Block. 1140 o (Step II): Compute the digest function (for the given algorithm 1141 suite) on the appropriate data. If the segment is not the (least 1142 recently added) segment corresponding to the origin AS, then the 1143 digest function should be computed on the following sequence of 1144 octets: 1146 Sequence of Octets to be Hashed 1148 +-------------------------------------------+ 1149 | AS Number of Target AS (4 octets) | 1150 +-------------------------------------------+ 1151 | AS Number (4 octets) | ---\ 1152 +-------------------------------------------+ \ 1153 | pCount (1 octet) | > Secure_Path 1154 +-------------------------------------------+ / 1155 | Flags (1 octet) | ---/ 1156 +-------------------------------------------+ 1157 | Sig Field in the Next Segment (variable) | 1158 +-------------- ----------------------------+ 1160 For the first segment to be processed (the most recently added 1161 segment), the 'AS Number of Target AS' is the AS number of the BGPSEC 1162 speaker validating the update message. Note that if a BGPSEC speaker 1163 uses multiple AS Numbers (e.g., the BGPSEC speaker is a member of a 1164 confederation), the AS number used here MUST be the AS number 1165 announced in the OPEN message for the BGP session over which the 1166 BGPSEC update was received. 1168 For each other Signature Segment, the 'AS Number of Target AS' is the 1169 AS number in the Secure_Path segment that corresponds to the 1170 Signature Segment added immediately after the one being processed. 1171 (That is, in the Secure_Path segment that corresponds to the 1172 Signature segment that the validator just finished processing.) 1174 The AS Number, pCount and Flags fields are taken from the Secure_Path 1175 segment that corresponds to the Signature segment currently being 1176 processed. The 'Signature Field in the Next Segment' is the 1177 Signature field found in the Signature segment that is next to be 1178 processed (that is, the next most recently added Signature Segment). 1180 Alternatively, if the segment being processed corresponds to the 1181 origin AS (i.e., if it is the least recently added segment), then the 1182 digest function should be computed on the following sequence of 1183 octets: 1185 Sequence of Octets to be Hashed 1186 +------------------------------------+ 1187 | AS Number of Target AS (4 octets) | 1188 +------------------------------------+ 1189 | Origin AS Number (4 octets) | ---\ 1190 +------------------------------------+ \ 1191 | pCount (1 octet) | > Secure_Path 1192 +------------------------------------+ / 1193 | Flags (1 octet) | ---/ 1194 +------------------------------------+ 1195 | Algorithm Suite Id. (1 octet) | 1196 +------------------------------------+ 1197 | NLRI Length (1 octet) | 1198 +------------------------------------+ 1199 | NLRI Prefix (variable) | 1200 +------------------------------------+ 1202 The NLRI Length, NLRI Prefix, and Algorithm Suite Identifier are all 1203 obtained in a straight forward manner from the NLRI of the update 1204 message or the BGPSEC_Path attribute being validated. The Origin AS 1205 Number, pCount, and Flags fields are taken from the Secure_Path 1206 segment corresponding to the Signature Segment currently being 1207 processed. 1209 The 'AS Number of Target AS' is the AS Number from the Secure_Path 1210 segment that was added immediately after the Secure_Path segment 1211 containing the Origin AS Number. (That is, the Secure_Path segment 1212 corresponding to the Signature segment that the receiver just 1213 finished processing prior to the current Signature segment.) 1215 o (Step III): Use the signature validation algorithm (for the given 1216 algorithm suite) to verify the signature in the current segment. 1217 That is, invoke the signature validation algorithm on the 1218 following three inputs: the value of the Signature field in the 1219 current segment; the digest value computed in Step II above; and 1220 the public key obtained from the valid RPKI data in Step I above. 1221 If the signature validation algorithm determines that the 1222 signature is invalid, then mark the entire Signature_Block as 'Not 1223 Valid' and proceed to the next Signature_Block. If the signature 1224 validation algorithm determines that the signature is valid, then 1225 continue processing Signature Segments (within the current 1226 Signature_Block). 1228 If all Signature Segments within a Signature_Block pass validation 1229 (i.e., all segments are processed and the Signature_Block has not yet 1230 been marked 'Not Valid'), then the Signature_Block is marked as 1231 'Valid'. 1233 If at least one Signature_Block is marked as 'Valid', then the 1234 validation algorithm terminates and the BGPSEC update message is 1235 deemed to be 'Valid'. (That is, if a BGPSEC update message contains 1236 two Signature_Blocks then the update message is deemed 'Valid' if the 1237 first Signature_Block is marked 'Valid' OR the second Signature_Block 1238 is marked 'Valid'.) 1240 6. Algorithms and Extensibility 1242 6.1. Algorithm Suite Considerations 1244 Note that there is currently no support for bilateral negotiation 1245 between BGPSEC peers to use of a particular (digest and signature) 1246 algorithm suite using BGP capabilities. This is because the 1247 algorithm suite used by the sender of a BGPSEC update message must be 1248 understood not only by the peer to whom he is directly sending the 1249 message, but also by all BGPSEC speakers to whom the route 1250 advertisement is eventually propagated. Therefore, selection of an 1251 algorithm suite cannot be a local matter negotiated by BGP peers, but 1252 instead must be coordinated throughout the Internet. 1254 To this end, a mandatory algorithm suites document will be created 1255 which specifies a mandatory-to-use 'current' algorithm suite for use 1256 by all BGPSEC speakers [11]. 1258 It is anticipated that in the future mandatory algorithm suites 1259 document will be updated to specify a transition from the 'current' 1260 algorithm suite to a 'new' algorithm suite. During the period of 1261 transition (likely a small number of years), all BGPSEC update 1262 messages SHOULD simultaneously use both the 'current' algorithm suite 1263 and the 'new' algorithm suite. (Note that Sections 3 and 4 specify 1264 how the BGPSEC_Path attribute can contain signatures, in parallel, 1265 for two algorithm suites.) Once the transition is complete, use of 1266 the old 'current' algorithm will be deprecated, use of the 'new' 1267 algorithm will be mandatory, and a subsequent 'even newer' algorithm 1268 suite may be specified as recommend to implement. Once the 1269 transition has successfully been completed in this manner, BGPSEC 1270 speakers SHOULD include only a single Signature_Block (corresponding 1271 to the 'new' algorithm). 1273 6.2. Extensibility Considerations 1275 This section discusses potential changes to BGPSEC that would require 1276 substantial changes to the processing of the BGPSEC_Path and thus 1277 necessitate a new version of BGPSEC. Examples of such changes 1278 include: 1280 o A new type of signature algorithm that produces signatures of 1281 variable length 1283 o A new type of signature algorithm for which the number of 1284 signatures in the Signature_Block is not equal to the number of 1285 ASes in the Secure_Path (e.g., aggregate signatures) 1287 o Changes to the data that is protected by the BGPSEC signatures 1288 (e.g., attributes other than the AS path) 1290 In the case that such a change to BGPSEC were deemed desirable, it is 1291 expected that a subsequent version of BGPSEC would be created and 1292 that this version of BGPSEC would specify a new BGP path attribute, 1293 let's call it BGPSEC_PATH_TWO, which is designed to accommodate the 1294 desired changes to BGPSEC. In such a case, the mandatory algorithm 1295 suites document would be updated to specify algorithm suites 1296 appropriate for the new version of BGPSEC. 1298 At this point a transition would begin which is analogous to the 1299 algorithm transition discussed in Section 6.1. During the transition 1300 period all BGPSEC speakers SHOULD simultaneously include both the 1301 BGPSEC_PATH attribute and the new BGPSEC_PATH_TWO attribute. Once 1302 the transition is complete, the use of BGPSEC_PATH could then be 1303 deprecated, at which point BGPSEC speakers SHOULD include only the 1304 new BGPSEC_PATH_TWO attribute. Such a process could facilitate a 1305 transition to a new BGPSEC semantics in a backwards compatible 1306 fashion. 1308 7. Security Considerations 1310 For discussion of the BGPSEC threat model and related security 1311 considerations, please see [13]. 1313 A BGPSEC speaker who receives a valid BGPSEC update message, 1314 containing a route advertisement for a given prefix, is provided with 1315 the following security guarantees: 1317 o The origin AS number corresponds to an autonomous system that has 1318 been authorized, in the RPKI, by the IP address space holder to 1319 originate route advertisements for the given prefix. 1321 o For each AS in the path, a BGPSEC speaker authorized by the holder 1322 of the AS number intentionally chose (in accordance with local 1323 policy) to propagate the route advertisement to the subsequent AS 1324 in the path. 1326 That is, the recipient of a valid BGPSEC Update message is assured 1327 that the Secure_Path portion of the BGPSEC_Path attribute corresponds 1328 to a sequence of autonomous systems who have all agreed in principle 1329 to forward packets to the given prefix along the indicated path. (It 1330 should be noted that BGPSEC does not offer any guarantee that the 1331 data packets would propagate along the indicated path; it only 1332 guarantees that the BGP update conveying the path indeed propagated 1333 along the indicated path.) Furthermore, the recipient is assured 1334 that this path terminates in an autonomous system that has been 1335 authorized by the IP address space holder as a legitimate destination 1336 for traffic to the given prefix. 1338 Note that although BGPSEC provides a mechanism for an AS to validate 1339 that a received update message has certain security properties, the 1340 use of such a mechanism to influence route selection is completely a 1341 matter of local policy. Therefore, a BGPSEC speaker can make no 1342 assumptions about the validity of a route received from an external 1343 BGPSEC peer. That is, a compliant BGPSEC peer may (depending on the 1344 local policy of the peer) send update messages that fail the validity 1345 test in Section 5. Thus, a BGPSEC speaker MUST completely validate 1346 all BGPSEC update messages received from external peers. (Validation 1347 of update messages received from internal peers is a matter of local 1348 policy, see Section 5). 1350 Note that there may be cases where a BGPSEC speaker deems 'Valid' (as 1351 per the validation algorithm in Section 5.2) a BGPSEC update message 1352 that contains both a 'Valid' and a 'Not Valid' Signature_Block. That 1353 is, the update message contains two sets of signatures corresponding 1354 to two algorithm suites, and one set of signatures verifies correctly 1355 and the other set of signatures fails to verify. In this case, the 1356 protocol specifies that if the BGPSEC speaker propagates the route 1357 advertisement received in such an update message then the BGPSEC 1358 speaker SHOULD add its signature to each of the Signature_Blocks 1359 using both the corresponding algorithm suite. Thus the BGPSEC 1360 speaker creates a signature using both algorithm suites and creates a 1361 new update message that contains both the 'Valid' and the 'Not Valid' 1362 set of signatures (from its own vantage point). 1364 To understand the reason for such a design decision consider the case 1365 where the BGPSEC speaker receives an update message with both a set 1366 of algorithm A signatures which are 'Valid' and a set of algorithm B 1367 signatures which are 'Not Valid'. In such a case it is possible 1368 (perhaps even quite likely) that some of the BGPSEC speaker's peers 1369 (or other entities further 'downstream' in the BGP topology) do not 1370 support algorithm A. Therefore, if the BGPSEC speaker were to remove 1371 the 'Not Valid' set of signatures corresponding to algorithm B, such 1372 entities would treat the message as though it were unsigned. By 1373 including the 'Not Valid' set of signatures when propagating a route 1374 advertisement, the BGPSEC speaker ensures that 'downstream' entities 1375 have as much information as possible to make an informed opinion 1376 about the validation status of a BGPSEC update. 1378 Note also that during a period of partial BGPSEC deployment, a 1379 'downstream' entity might reasonably treat unsigned messages 1380 different from BGPSEC updates that contain a single set of 'Not 1381 Valid' signatures. That is, by removing the set of 'Not Valid' 1382 signatures the BGPSEC speaker might actually cause a downstream 1383 entity to 'upgrade' the status of a route advertisement from 'Not 1384 Valid' to unsigned. Finally, note that in the above scenario, the 1385 BGPSEC speaker might have deemed algorithm A signatures 'Valid' only 1386 because of some issue with RPKI state local to his AS (for example, 1387 his AS might not yet have obtained a CRL indicating that a key used 1388 to verify an algorithm A signature belongs to a newly revoked 1389 certificate). In such a case, it is highly desirable for a 1390 downstream entity to treat the update as 'Not Valid' (due to the 1391 revocation) and not as 'unsigned' (which would happen if the 'Not 1392 Valid' Signature_Blocks were removed). 1394 A similar argument applies to the case where a BGPSEC speaker (for 1395 some reason such as lack of viable alternatives) selects as his best 1396 route to a given prefix a route obtained via a 'Not Valid' BGPSEC 1397 update message. (That is, a BGPSEC update containing only 'Not 1398 Valid' Signature_Blocks.) In such a case, the BGPSEC speaker should 1399 propagate a signed BGPSEC update message, adding his signature to the 1400 'Not Valid' signatures that already exist. Again, this is to ensure 1401 that 'downstream' entities are able to make an informed decision and 1402 not erroneously treat the route as unsigned. It may also be noted 1403 here that due to possible differences in RPKI data at different 1404 vantage points in the network, a BGPSEC update that was deemed 'Not 1405 Valid' at an upstream BGPSEC speaker may indeed be deemed 'Valid' at 1406 another BGP speaker downstream. 1408 Therefore, it is important to note that when a BGPSEC speaker signs 1409 an outgoing update message, it is not attesting to a belief that all 1410 signatures prior to its are valid. Instead it is merely asserting 1411 that: 1413 o The BGPSEC speaker received the given route advertisement with the 1414 indicated NLRI and Secure_Path; and 1416 o The BGPSEC speaker chose to propagate an advertisement for this 1417 route to the peer (implicitly) indicated by the 'Target AS' 1419 The BGPSEC update validation procedure is a potential target for 1420 denial of service attacks against a BGPSEC speaker. To mitigate the 1421 effectiveness of such denial of service attacks, BGPSEC speakers 1422 should implement an update validation algorithm that performs 1423 expensive checks (e.g., signature verification) after performing less 1424 expensive checks (e.g., syntax checks). The validation algorithm 1425 specified in Section 5.2 was chosen so as to perform checks which are 1426 likely to be expensive after checks that are likely to be 1427 inexpensive. However, the relative cost of performing required 1428 validation steps may vary between implementations, and thus the 1429 algorithm specified in Section 5.2 may not provide the best denial of 1430 service protection for all implementations. 1432 The mechanism of setting the pCount field to zero is included in this 1433 specification to enable route servers in the control path to 1434 participate in BGPSEC without increasing the effective length of the 1435 AS-PATH. However, entities other than route servers could 1436 conceivably use this mechanism (set the pCount to zero) to attract 1437 traffic (by reducing the effective length of the AS-PATH) 1438 illegitimately. This risk is largely mitigated if every BGPSEC 1439 speaker drops incoming update messages that set pCount to zero but 1440 come from a peer that is not a route server. However, note that a 1441 recipient of a BGPSEC update message in which an upstream entity that 1442 is two or more hops away set pCount to zero is unable to verify for 1443 themselves whether pCount was set to zero legitimately. 1445 Finally, BGPSEC does not provide protection against attacks at the 1446 transport layer. An adversary on the path between a BGPSEC speaker 1447 and its peer is able to perform attacks such as modifying valid 1448 BGPSEC updates to cause them to fail validation, injecting (unsigned) 1449 BGP update messages without BGPSEC_Path_Signature attributes, or 1450 injecting BGPSEC update messages with BGPSEC_Path_Signature 1451 attributes that fail validation, or causing the peer to tear-down the 1452 BGP session. Therefore, BGPSEC sessions SHOULD be protected by 1453 appropriate transport security mechanisms. 1455 8. IANA Considerations 1457 TBD: Need IANA to assign numbers for the two capabilities and the 1458 BGPSEC_PATH attribute. 1460 This document does not create any new IANA registries. 1462 9. Contributors 1464 9.1. Authors 1466 Rob Austein 1467 Dragon Research Labs 1468 sra@hactrn.net 1469 Steven Bellovin 1470 Columbia University 1471 smb@cs.columbia.edu 1473 Randy Bush 1474 Internet Initiative Japan 1475 randy@psg.com 1477 Russ Housley 1478 Vigil Security 1479 housley@vigilsec.com 1481 Matt Lepinski 1482 BBN Technologies 1483 lepinski@bbn.com 1485 Stephen Kent 1486 BBN Technologies 1487 kent@bbn.com 1489 Warren Kumari 1490 Google 1491 warren@kumari.net 1493 Doug Montgomery 1494 USA National Institute of Standards and Technology 1495 dougm@nist.gov 1497 Kotikalapudi Sriram 1498 USA National Institute of Standards and Technology 1499 kotikalapudi.sriram@nist.gov 1501 Samuel Weiler 1502 Sparta 1503 weiler+ietf@watson.org 1505 9.2. Acknowledgements 1507 The authors would like to thank Luke Berndt, Sharon Goldberg, Ed 1508 Kern, Chris Morrow, Doug Maughan, Pradosh Mohapatra, Russ Mundy, 1509 Sandy Murphy, Keyur Patel, Mark Reynolds, Heather Schiller, Jason 1510 Schiller, John Scudder, Ruediger Volk and David Ward for their 1511 valuable input and review. 1513 10. Normative References 1515 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1516 Levels", BCP 14, RFC 2119, March 1997. 1518 [2] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 1519 Gateway Protocol 4", RFC 4271, January 2006. 1521 [3] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1522 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 1524 [4] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number 1525 Space", RFC 4893, May 2007. 1527 [5] Traina, P., McPherson, D., and J. Scudder, "Autonomous System 1528 Confederations for BGP", RFC 5065, August 2007. 1530 [6] Scudder, J. and R. Chandra, "Capabilities Advertisement with 1531 BGP-4", RFC 5492, February 2009. 1533 [7] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure 1534 Internet Routing", RFC 6480, February 2012. 1536 [8] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1537 Origin Authorizations (ROAs)", RFC 6482, February 2012. 1539 [9] Patel, K., Ward, D., and R. Bush, "Extended Message support for 1540 BGP", July 2012. 1542 [10] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPSEC 1543 Router Certificates, Certificate Revocation Lists, and 1544 Certification Requests", April 2012. 1546 [11] Turner, S., "BGP Algorithms, Key Formats, & Signature Formats", 1547 March 2012. 1549 11. Informative References 1551 [12] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET 1552 and AS_CONFED_SET in BGP", RFC 6472, December 2011. 1554 [13] Kent, S., "Threat Model for BGP Path Security", February 2012. 1556 [14] Bush, R. and R. Austein, "The RPKI/Router Protocol", 1557 February 2012. 1559 [15] Bush, R., Patel, K., and S. Turner, "Router Key PDU for RPKI- 1560 Router Protocol", October 2012. 1562 [16] Bush, R., "BGPsec Operational Considerations", May 2012. 1564 Author's Address 1566 Matthew Lepinski (editor) 1567 BBN 1568 10 Moulton St 1569 Cambridge, MA 55409 1570 US 1572 Phone: +1 617 873 5939 1573 Email: mlepinski@bbn.com