idnits 2.17.1 draft-ietf-sidr-bgpsec-protocol-17.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 (June 23, 2016) is 2862 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Lepinski, Ed. 3 Internet-Draft NCF 4 Intended status: Standards Track K. Sriram, Ed. 5 Expires: December 23, 2016 NIST 6 June 23, 2016 8 BGPsec Protocol Specification 9 draft-ietf-sidr-bgpsec-protocol-17 11 Abstract 13 This document describes BGPsec, an extension to the Border Gateway 14 Protocol (BGP) that provides security for the path of autonomous 15 systems through which a BGP update message passes. BGPsec is 16 implemented via an optional non-transitive BGP path attribute that 17 carries a digital signature produced by each autonomous system that 18 propagates the update message. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 24 "OPTIONAL" are to be interpreted as described in RFC 2119 [1] only 25 when they appear in all upper case. They may also appear in lower or 26 mixed case as English words, without normative meaning. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 23, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. BGPsec Negotiation . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. The BGPsec Capability . . . . . . . . . . . . . . . . . . 3 65 2.2. Negotiating BGPsec Support . . . . . . . . . . . . . . . . 4 66 3. The BGPsec_Path Attribute . . . . . . . . . . . . . . . . . . 6 67 3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.2. Signature_Block . . . . . . . . . . . . . . . . . . . . . 8 69 4. BGPsec Update Messages . . . . . . . . . . . . . . . . . . . . 10 70 4.1. General Guidance . . . . . . . . . . . . . . . . . . . . . 10 71 4.2. Constructing the BGPsec_Path Attribute . . . . . . . . . . 12 72 4.3. Processing Instructions for Confederation Members . . . . 16 73 4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . . 18 74 5. Processing a Received BGPsec Update . . . . . . . . . . . . . 20 75 5.1. Overview of BGPsec Validation . . . . . . . . . . . . . . 21 76 5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . . 22 77 6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 25 78 6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 25 79 6.2. Extensibility Considerations . . . . . . . . . . . . . . . 26 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 81 7.1 Security Guarantees . . . . . . . . . . . . . . . . . . . . 27 82 7.2 On the Removal of BGPsec Signatures . . . . . . . . . . . . 28 83 7.3 Mitigation of Denial of Service Attacks . . . . . . . . . . 29 84 7.4 Additional Security Considerations . . . . . . . . . . . . . 30 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 86 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 87 9.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 31 88 9.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 32 89 10. Normative References . . . . . . . . . . . . . . . . . . . . 32 90 11. Informative References . . . . . . . . . . . . . . . . . . . 33 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 93 1. Introduction 94 This document describes BGPsec, a mechanism for providing path 95 security for Border Gateway Protocol (BGP) [2] route advertisements. 96 That is, a BGP speaker who receives a valid BGPsec update has 97 cryptographic assurance that the advertised route has the following 98 property: Every AS on the path of ASes listed in the update message 99 has explicitly authorized the advertisement of the route to the 100 subsequent AS in the path. 102 This document specifies an optional (non-transitive) BGP path 103 attribute, BGPsec_Path. It also describes how a BGPsec-compliant BGP 104 speaker (referred to hereafter as a BGPsec speaker) can generate, 105 propagate, and validate BGP update messages containing this attribute 106 to obtain the above assurances. 108 BGPsec is intended to be used to supplement BGP Origin Validation 109 [19][20] and when used in conjunction with origin validation, it is 110 possible to prevent a wide variety of route hijacking attacks against 111 BGP. 113 BGPsec relies on the Resource Public Key Infrastructure (RPKI) 114 certificates that attest to the allocation of AS number and IP 115 address resources. (For more information on the RPKI, see [12] and 116 the documents referenced therein.) Any BGPsec speaker who wishes to 117 send, to external (eBGP) peers, BGP update messages containing the 118 BGPsec_Path needs to possess a private key associated with an RPKI 119 router certificate [9] that corresponds to the BGPsec speaker's AS 120 number. Note, however, that a BGPsec speaker does not need such a 121 certificate in order to validate received update messages containing 122 the BGPsec_Path attribute (see Section 5.2). 124 2. BGPsec Negotiation 126 This document defines a BGP capability [6] that allows a BGP speaker 127 to advertise to a neighbor the ability to send or to receive BGPsec 128 update messages (i.e., update messages containing the BGPsec_Path 129 attribute). 131 2.1. The BGPsec Capability 133 This capability has capability code : TBD 135 The capability length for this capability MUST be set to 3. 137 The three octets of the capability value are specified as follows. 139 BGPsec Send Capability Value: 141 0 1 2 3 4 5 6 7 142 +---------------------------------------+ 143 | Version | Dir | Reserved | 144 +---------------------------------------+ 145 | | 146 +------ AFI -----+ 147 | | 148 +---------------------------------------+ 150 The first four bits of the first octet indicate the version of BGPsec 151 for which the BGP speaker is advertising support. This document 152 defines only BGPsec version 0 (all four bits set to zero). Other 153 versions of BGPsec may be defined in future documents. A BGPsec 154 speaker MAY advertise support for multiple versions of BGPsec by 155 including multiple versions of the BGPsec capability in its BGP OPEN 156 message. 158 The fifth bit of the first octet is a direction bit which indicates 159 whether the BGP speaker is advertising the capability to send BGPsec 160 update messages or receive BGPsec update messages. The BGP speaker 161 sets this bit to 0 to indicate the capability to receive BGPsec 162 update messages. The BGP speaker sets this bit to 1 to indicate the 163 capability to send BGPsec update messages. 165 The remaining three bits of the first octet are reserved for future 166 use. These bits are set to zero by the sender of the capability and 167 ignored by the receiver of the capability. 169 The second and third octets contain the 16-bit Address Family 170 Identifier (AFI) which indicates the address family for which the 171 BGPsec speaker is advertising support for BGPsec. This document only 172 specifies BGPsec for use with two address families, IPv4 and IPv6, 173 AFI values 1 and 2 respectively. BGPsec for use with other address 174 families may be specified in future documents. 176 2.2. Negotiating BGPsec Support 178 In order to indicate that a BGP speaker is willing to send BGPsec 179 update messages (for a particular address family), a BGP speaker 180 sends the BGPsec Capability (see Section 2.1) with the Direction bit 181 (the fifth bit of the first octet) set to 1. In order to indicate 182 that the speaker is willing to receive BGP update messages containing 183 the BGPsec_Path attribute (for a particular address family), a BGP 184 speaker sends the BGPsec capability with the Direction bit set to 0. 185 In order to advertise the capability to both send and receive BGPsec 186 update messages, the BGP speaker sends two copies of the BGPsec 187 capability (one with the direction bit set to 0 and one with the 188 direction bit set to 1). 190 Similarly, if a BGP speaker wishes to use BGPsec with two different 191 address families (i.e., IPv4 and IPv6) over the same BGP session, 192 then the speaker includes two instances of this capability (one for 193 each address family) in the BGP OPEN message. A BGP speaker MUST 194 support the BGP multiprotocol extension [3]. Additionally, a BGP 195 speaker MUST NOT advertise the capability of BGPsec support for a 196 particular AFI unless it has also advertised the multiprotocol 197 extension capability for the same AFI [3]. 199 In a BGPsec peering session, a peer is permitted to send update 200 messages containing the BGPsec_Path attribute if, and only if: 202 o The given peer sent the BGPsec capability for a particular version 203 of BGPsec and a particular address family with the Direction bit 204 set to 1; and 206 o The other (receiving) peer sent the BGPsec capability for the same 207 version of BGPsec and the same address family with the Direction 208 bit set to 0. 210 In such a session, we say that the use of the particular version of 211 BGPsec has been negotiated for a particular address family. BGP 212 update messages without the BGPsec_Path attribute MAY be sent within 213 a session regardless of whether or not the use of BGPsec is 214 successfully negotiated. However, if BGPsec is not successfully 215 negotiated, then BGP update messages containing the BGPsec_Path 216 attribute MUST NOT be sent. 218 This document defines the behavior of implementations in the case 219 where BGPsec version zero is the only version that has been 220 successfully negotiated. Any future document which specifies 221 additional versions of BGPsec will need to specify behavior in the 222 case that support for multiple versions is negotiated. 224 BGPsec cannot provide meaningful security guarantees without support 225 for four-byte AS numbers. Therefore, any BGP speaker that announces 226 the BGPsec capability, MUST also announce the capability for four- 227 byte AS support [4]. If a BGP speaker sends the BGPsec capability but 228 not the four-byte AS support capability then BGPsec has not been 229 successfully negotiated, and update messages containing the 230 BGPsec_Path attribute MUST NOT be sent within such a session. 232 Note that BGPsec update messages can be quite large, therefore any 233 BGPsec speaker announcing the capability to receive BGPsec messages 234 SHOULD also announce support for the capability to receive BGP 235 extended messages [8]. 237 3. The BGPsec_Path Attribute 239 The BGPsec_Path attribute is an optional non-transitive BGP path 240 attribute. 242 This document registers an attribute type code for this attribute : 243 TBD 245 The BGPsec_Path attribute carries the secured information regarding 246 the path of ASes through which an update message passes. This 247 includes the digital signatures used to protect the path information. 248 We refer to those update messages that contain the BGPsec_Path 249 attribute as "BGPsec Update messages". The BGPsec_Path attribute 250 replaces the AS_PATH attribute in a BGPsec update message. That is, 251 update messages that contain the BGPsec_Path attribute MUST NOT 252 contain the AS_PATH attribute, and vice versa. 254 The BGPsec_Path attribute is made up of several parts. The following 255 high-level diagram provides an overview of the structure of the 256 BGPsec_Path attribute: 258 High-Level Diagram of the BGPsec_Path Attribute 259 +---------------------------------------------------------+ 260 | +-----------------+ | 261 | | Secure Path | | 262 | +-----------------+ | 263 | | AS X | | 264 | | pCount X | | 265 | | Flags X | | 266 | | AS Y | | 267 | | pCount Y | | 268 | | Flags Y | | 269 | | ... | | 270 | +-----------------+ | 271 | | 272 | +-----------------+ +-----------------+ | 273 | | Sig Block 1 | | Sig Block 2 | | 274 | +-----------------+ +-----------------+ | 275 | | Alg Suite 1 | | Alg Suite 2 | | 276 | | SKI X1 | | SKI X1 | | 277 | | Signature X1 | | Signature X1 | | 278 | | SKI Y1 | | SKI Y1 | | 279 | | Signature Y1 | | Signature Y1 | | 280 | | ... | | .... | | 281 | +-----------------+ +-----------------+ | 282 | | 283 +---------------------------------------------------------+ 285 The following is the specification of the format for the BGPsec_Path 286 attribute. 288 BGPsec_Path Attribute 290 +-------------------------------------------------------+ 291 | Secure_Path (variable) | 292 +-------------------------------------------------------+ 293 | Sequence of one or two Signature_Blocks (variable) | 294 +-------------------------------------------------------+ 296 The Secure_Path contains AS path information for the BGPsec update 297 message. This is logically equivalent to the information that is 298 contained in a non-BGPsec AS_PATH attribute. The information in 299 Secure_Path is used by BGPsec speakers in the same way that 300 information from the AS_PATH is used by non-BGPsec speakers. The 301 format of the Secure_Path is described below in Section 3.1. 303 The BGPsec_Path attribute will contain one or two Signature_Blocks, 304 each of which corresponds to a different algorithm suite. Each of 305 the Signature_Blocks will contain a signature segment for each AS 306 number (i.e., Secure_Path segment) in the Secure_Path. In the most 307 common case, the BGPsec_Path attribute will contain only a single 308 Signature_Block. However, in order to enable a transition from an 309 old algorithm suite to a new algorithm suite (without a flag day), it 310 will be necessary to include two Signature_Blocks (one for the old 311 algorithm suite and one for the new algorithm suite) during the 312 transition period. (See Section 6.1 for more discussion of algorithm 313 transitions.) The format of the Signature_Blocks is described below 314 in Section 3.2. 316 3.1. Secure_Path 318 Here we provide a detailed description of the Secure_Path information 319 in the BGPsec_Path attribute. 321 Secure_Path 323 +-----------------------------------------------+ 324 | Secure_Path Length (2 octets) | 325 +-----------------------------------------------+ 326 | One or More Secure_Path Segments (variable) | 327 +-----------------------------------------------+ 329 The Secure_Path Length contains the length (in octets) of the entire 330 Secure_Path (including the two octets used to express this length 331 field). As explained below, each Secure_Path segment is six octets 332 long. Note that this means the Secure_Path Length is two greater 333 than six times the number Secure_Path Segments (i.e., the number of 334 AS numbers in the path). 336 The Secure_Path contains one Secure_Path Segment for each Autonomous 337 System in the path to the originating AS of the NLRI specified in the 338 update message. 340 Secure_Path Segment 342 +----------------------------+ 343 | pCount (1 octet) | 344 +----------------------------+ 345 | Flags (1 octet) | 346 +----------------------------+ 347 | AS Number (4 octets) | 348 +----------------------------+ 350 The AS Number is the AS number of the BGP speaker that added this 351 Secure_Path segment to the BGPsec_Path attribute. (See Section 4 for 352 more information on populating this field.) 354 The pCount field contains the number of repetitions of the associated 355 autonomous system number that the signature covers. This field 356 enables a BGPsec speaker to mimic the semantics of prepending 357 multiple copies of their AS to the AS_PATH without requiring the 358 speaker to generate multiple signatures. The pCount field is also 359 useful in managing route servers (see Section 4.2) and AS Number 360 migrations, see [18] for details. 362 The first bit of the Flags field is the Confed_Segment flag. The 363 Confed_Segment flag is set to one to indicate that the BGPsec speaker 364 that constructed this Secure_Path segment is sending the update 365 message to a peer AS within the same Autonomous System confederation 366 [5]. (That is, the Confed_Segment flag is set in a BGPsec update 367 message whenever, in a non-BGPsec update message, the BGP speaker's 368 AS would appear in a AS_PATH segment of type AS_CONFED_SEQUENCE.) In 369 all other cases the Confed_Segment flag is set to zero. 371 The remaining seven bits of the Flags MUST be set to zero by the 372 sender, and ignored by the receiver. Note, however, that the 373 signature is computed over all eight bits of the flags field. 375 3.2. Signature_Block 377 Here we provide a detailed description of the Signature_Blocks in the 378 BGPsec_Path attribute. 380 Signature_Block 382 +---------------------------------------------+ 383 | Signature_Block Length (2 octets) | 384 +---------------------------------------------+ 385 | Algorithm Suite Identifier (1 octet) | 386 +---------------------------------------------+ 387 | Sequence of Signature Segments (variable) | 388 +---------------------------------------------+ 390 The Signature_Block Length is the total number of octets in the 391 Signature_Block (including the two octets used to express this length 392 field). 394 The Algorithm Suite Identifier is a one-octet identifier specifying 395 the digest algorithm and digital signature algorithm used to produce 396 the digital signature in each Signature Segment. An IANA registry of 397 algorithm identifiers for use in BGPsec is specified in the BGPsec 398 algorithms document [10]. 400 A Signature_Block has exactly one Signature Segment for each 401 Secure_Path Segment in the Secure_Path portion of the BGPsec_Path 402 Attribute. (That is, one Signature Segment for each distinct AS on 403 the path for the NLRI in the Update message.) 405 Signature Segments 406 +---------------------------------------------+ 407 | Subject Key Identifier (20 octets) | 408 +---------------------------------------------+ 409 | Signature Length (2 octets) | 410 +---------------------------------------------+ 411 | Signature (variable) | 412 +---------------------------------------------+ 414 The Subject Key Identifier contains the value in the Subject Key 415 Identifier extension of the RPKI router certificate [9] that is used 416 to verify the signature (see Section 5 for details on validity of 417 BGPsec update messages). 419 The Signature Length field contains the size (in octets) of the value 420 in the Signature field of the Signature Segment. 422 The Signature contains a digital signature that protects the NLRI and 423 the BGPsec_Path attribute (see Sections 4 and 5 for details on 424 signature generation and validation, respectively). 426 4. BGPsec Update Messages 428 Section 4.1 provides general guidance on the creation of BGPsec 429 Update Messages -- that is, update messages containing the 430 BGPsec_Path attribute. 432 Section 4.2 specifies how a BGPsec speaker generates the BGPsec_Path 433 attribute to include in a BGPsec Update message. 435 Section 4.3 contains special processing instructions for members of 436 an autonomous system confederation [5]. A BGPsec speaker that is not 437 a member of such a confederation MUST set the Flags field of the 438 Secure_Path Segment to zero in all BGPsec update messages it sends. 440 Section 4.4 contains instructions for reconstructing the AS_PATH 441 attribute in cases where a BGPsec speaker receives an update message 442 with a BGPsec_Path attribute and wishes to propagate the update 443 message to a peer who does not support BGPsec. 445 4.1. General Guidance 447 The information protected by the signature on a BGPsec update message 448 includes the AS number of the peer to whom the update message is 449 being sent. Therefore, if a BGPsec speaker wishes to send a BGPsec 450 update to multiple BGP peers, it must generate a separate BGPsec 451 update message for each unique peer AS to whom the update message is 452 sent. 454 A BGPsec update message MUST advertise a route to only a single NLRI. 455 This is because a BGPsec speaker receiving an update message with 456 multiple NLRI would be unable to construct a valid BGPsec update 457 message (i.e., valid path signatures) containing a subset of the NLRI 458 in the received update. If a BGPsec speaker wishes to advertise 459 routes to multiple NLRI, then it MUST generate a separate BGPsec 460 update message for each NLRI. Additionally, a BGPsec update message 461 MUST use the MP_REACH_NLRI [3] attribute to encode the NLRI. 463 The BGPsec_Path attribute and the AS_PATH attribute are mutually 464 exclusive. That is, any update message containing the BGPsec_Path 465 attribute MUST NOT contain the AS_PATH attribute. The information 466 that would be contained in the AS_PATH attribute is instead conveyed 467 in the Secure_Path portion of the BGPsec_Path attribute. 469 In order to create or add a new signature to a BGPsec update message 470 with a given algorithm suite, the BGPsec speaker must possess a 471 private key suitable for generating signatures for this algorithm 472 suite. Additionally, this private key must correspond to the public 473 key in a valid Resource PKI end-entity certificate whose AS number 474 resource extension includes the BGPsec speaker's AS number [9]. Note 475 also that new signatures are only added to a BGPsec update message 476 when a BGPsec speaker is generating an update message to send to an 477 external peer (i.e., when the AS number of the peer is not equal to 478 the BGPsec speaker's own AS number). Therefore, a BGPsec speaker who 479 only sends BGPsec update messages to peers within its own AS does not 480 need to possess any private signature keys. 482 The Resource PKI enables the legitimate holder of IP address 483 prefix(es) to issue a signed object, called a Route Origination 484 Authorization (ROA), that authorizes a given AS to originate routes 485 to a given set of prefixes (see [7]). It is expected that most 486 relying parties will utilize BGPsec in tandem with origin validation 487 (see [19] and [20]). Therefore, it is RECOMMENDED that a BGPsec 488 speaker only originate a BGPsec update advertising a route for a 489 given prefix if there exists a valid ROA authorizing the BGPsec 490 speaker's AS to originate routes to this prefix. 492 If a BGPsec router has received only a non-BGPsec update message 493 (without the BGPsec_Path attribute), containing the AS_PATH 494 attribute, from a peer for a given prefix then it MUST NOT attach a 495 BGPsec_Path attribute when it propagates the update message. (Note 496 that a BGPsec router may also receive a non-BGPsec update message 497 from an internal peer without the AS_PATH attribute, i.e., with just 498 the NLRI in it. In that case, the prefix is originating from that 499 AS, and if it is selected for advertisement, the BGPsec speaker 500 SHOULD attach a BGPsec_Path attribute and send a signed route (for 501 that prefix) to its external BGPsec-speaking peers.) 503 Conversely, if a BGPsec router has received a BGPsec update message 504 (with the BGPsec_Path attribute) from a peer for a given prefix and 505 it chooses to propagate that peer's route for the prefix, then it 506 SHOULD propagate the route as a BGPsec update message containing the 507 BGPsec_Path attribute. 509 Note that removing BGPsec signatures (i.e., propagating a route 510 advertisement without the BGPsec_Path attribute) has significant 511 security ramifications. (See Section 7 for discussion of the 512 security ramifications of removing BGPsec signatures.) Therefore, 513 when a route advertisement is received via a BGPsec update message, 514 propagating the route advertisement without the BGPsec_Path attribute 515 is NOT RECOMMENDED, unless the message is sent to a peer that did not 516 advertise the capability to receive BGPsec update messages (see 517 Section 4.4). 519 Furthermore, note that when a BGPsec speaker propagates a route 520 advertisement with the BGPsec_Path attribute it is not attesting to 521 the validation state of the update message it received. (See Section 522 7 for more discussion of the security semantics of BGPsec 523 signatures.) 525 If the BGPsec speaker is producing an update message which would, in 526 the absence of BGPsec, contain an AS_SET (e.g., the BGPsec speaker is 527 performing proxy aggregation), then the BGPsec speaker MUST NOT 528 include the BGPsec_Path attribute. In such a case, the BGPsec 529 speaker must remove any existing BGPsec_Path in the received 530 advertisement(s) for this prefix and produce a traditional (non- 531 BGPsec) update message. It should be noted that BCP 172 [13] 532 recommends against the use of AS_SET and AS_CONFED_SET in the AS_PATH 533 of BGP updates. 535 The case where the BGPsec speaker sends a BGPsec update message to an 536 internal (iBGP) peer is quite simple. When originating a new route 537 advertisement and sending it to an internal peer, the BGPsec speaker 538 omits the BGPsec_Path attribute. When propagating a received route 539 advertisement to an internal peer, the BGPsec speaker typically 540 populates the BGPsec_Path attribute by copying the BGPsec_Path 541 attribute from the received update message. That is, the BGPsec_Path 542 attribute is copied verbatim. However, in the case that the BGPsec 543 speaker is performing an AS Migration, the BGPsec speaker may add an 544 additional signature on ingress before copying the BGPsec_Path 545 attribute (see [18] for more details). Note that when a BGPsec 546 speaker chooses to forward a BGPsec update message to an iBGP peer, 547 the BGPsec attribute SHOULD NOT be removed, unless the peer doesn't 548 support BGPsec. In particular, the BGPsec attribute SHOULD NOT be 549 removed even in the case where the BGPsec update message has not been 550 successfully validated. (See Section 5 for more information on 551 validation, and Section 7 for the security ramifications of removing 552 BGPsec signatures.) 554 4.2. Constructing the BGPsec_Path Attribute 556 When a BGPsec speaker receives a BGPsec update message containing a 557 BGPsec_Path attribute (with one or more signatures) from an (internal 558 or external) peer, it may choose to propagate the route advertisement 559 by sending to its other (internal or external) peers. When sending 560 said route advertisement to an internal BGPsec-speaking peer, the 561 BGPsec_Path attribute SHALL NOT be modified. When sending said route 562 advertisement to an external BGPsec-speaking peer, the following 563 procedures are used to form or update the BGPsec_Path attribute. 565 To generate the BGPsec_Path attribute on the outgoing update message, 566 the BGPsec speaker first generates a new Secure_Path Segment. Note 567 that if the BGPsec speaker is not the origin AS and there is an 568 existing BGPsec_Path attribute, then the BGPsec speaker prepends its 569 new Secure_Path Segment (places in first position) onto the existing 570 Secure_Path. 572 The AS number in this Secure_Path segment MUST match the AS number in 573 the AS number resource extension field of the Resource PKI router 574 certificate(s) that will be used to verify the digital signature(s) 575 constructed by this BGPsec speaker [9]. 577 The pCount field of the Secure_Path Segment is typically set to the 578 value 1. However, a BGPsec speaker may set the pCount field to a 579 value greater than 1. Setting the pCount field to a value greater 580 than one has the same semantics as repeating an AS number multiple 581 times in the AS_PATH of a non-BGPsec update message (e.g., for 582 traffic engineering purposes). 584 To prevent unnecessary processing load in the validation of BGPsec 585 signatures, a BGPsec speaker SHOULD NOT produce multiple consecutive 586 Secure_Path Segments with the same AS number. This means that to 587 achieve the semantics of prepending the same AS number k times, a 588 BGPsec speaker SHOULD produce a single Secure_Path Segment -- with 589 pCount of k -- and a single corresponding Signature Segment. 591 A route server that participates in the BGP control plane, but does 592 not act as a transit AS in the data plane, may choose to set pCount 593 to 0. This option enables the route server to participate in BGPsec 594 and obtain the associated security guarantees without increasing the 595 effective length of the AS path. (Note that BGPsec speakers compute 596 the effective length of the AS path by summing the pCount values in 597 the BGPsec_Path attribute, see Section 5.) However, when a route 598 server sets the pCount value to 0, it still inserts its AS number 599 into the Secure_Path segment, as this information is needed to 600 validate the signature added by the route server. (See [18] for a 601 discussion of setting pCount to 0 to facilitate AS Number Migration.) 602 BGPsec speakers SHOULD drop incoming update messages with pCount set 603 to zero in cases where the BGPsec speaker does not expect its peer to 604 set pCount to zero. (That is, pCount is only to be set to zero in 605 cases such as route servers or AS Number Migration where the BGPsec 606 speaker's peer expects pCount to be set to zero.) 608 Next, the BGPsec speaker generates one or two Signature_Blocks. 609 Typically, a BGPsec speaker will use only a single algorithm suite, 610 and thus create only a single Signature_Block in the BGPsec_Path 611 attribute. However, to ensure backwards compatibility during a 612 period of transition from a 'current' algorithm suite to a 'new' 613 algorithm suite, it will be necessary to originate update messages 614 that contain a Signature_Block for both the 'current' and the 'new' 615 algorithm suites (see Section 6.1). 617 If the received BGPsec update message contains two Signature_Blocks 618 and the BGPsec speaker supports both of the corresponding algorithm 619 suites, then the new update message generated by the BGPsec speaker 620 SHOULD include both of the Signature_Blocks. If the received BGPsec 621 update message contains two Signature_Blocks and the BGPsec speaker 622 only supports one of the two corresponding algorithm suites, then the 623 BGPsec speaker MUST remove the Signature_Block corresponding to the 624 algorithm suite that it does not understand. If the BGPsec speaker 625 does not support the algorithm suites in any of the Signature_Blocks 626 contained in the received update message, then the BGPsec speaker 627 MUST NOT propagate the route advertisement with the BGPsec_Path 628 attribute. (That is, if it chooses to propagate this route 629 advertisement at all, it must do so as an unsigned BGP update 630 message. See Section 4.4 for more information on converting to an 631 unsigned BGP message.) 633 Note that in the case where the BGPsec_Path has two Signature_Blocks 634 (corresponding to different algorithm suites), the validation 635 algorithm (see Section 5.2) deems a BGPsec update message to be 636 'Valid' if there is at least one supported algorithm suite (and 637 corresponding Signature_Block) that is deemed 'Valid'. This means 638 that a 'Valid' BGPsec update message may contain a Signature_Block 639 which is not deemed 'Valid' (e.g., contains signatures that BGPsec 640 does not successfully verify). Nonetheless, such Signature_Blocks 641 MUST NOT be removed. (See Section 7 for a discussion of the security 642 ramifications of this design choice.) 644 For each Signature_Block corresponding to an algorithm suite that the 645 BGPsec speaker does support, the BGPsec speaker adds a new Signature 646 Segment to the Signature_Block. This Signature Segment is prepended 647 to the list of Signature Segments (placed in the first position) so 648 that the list of Signature Segments appear in the same order as the 649 corresponding Secure_Path segments. The BGPsec speaker populates the 650 fields of this new signature segment as follows. 652 The Subject Key Identifier field in the new segment is populated with 653 the identifier contained in the Subject Key Identifier extension of 654 the RPKI router certificate corresponding to the BGPsec speaker [9]. 655 This Subject Key Identifier will be used by recipients of the route 656 advertisement to identify the proper certificate to use in verifying 657 the signature. 659 The Signature field in the new segment contains a digital signature 660 that binds the NLRI and BGPsec_Path attribute to the RPKI router 661 certificate corresponding to the BGPsec speaker. The digital 662 signature is computed as follows: 664 o For clarity, let us number the Secure_Path and corresponding 665 Signature Segments from 1 to N as follows. Let Secure_Path Segment 666 1 and Signature Segment 1 be the segments produced by the origin 667 AS. Let Secure_Path Segment 2 and Signature Segment 2 be the 668 segments added by the next AS after the origin. Continue this 669 method of numbering and ultimately let Secure_Path Segment N be 670 the Secure_Path segment that is being added by the current AS. 672 o In order to construct the digital signature for Signature Segment 673 N (the signature segment being produced by the current AS), first 674 construct the following sequence of octets to be hashed. 676 Sequence of Octets to be Hashed 677 +------------------------------------+ 678 | Target AS Number | 679 +------------------------------------+ -\ 680 | Signature Segment : N-1 | \ 681 +------------------------------------+ | 682 | Secure_Path Segment : N | | 683 +------------------------------------+ \ 684 ... > For N Hops 685 +------------------------------------+ / 686 | Signature Segment : 1 | | 687 +------------------------------------+ | 688 | Secure_Path Segment : 2 | / 689 +------------------------------------+ -/ 690 | Secure_Path Segment : 1 | 691 +------------------------------------+ 692 | Algorithm Suite Identifier | 693 +------------------------------------+ 694 | AFI | 695 +------------------------------------+ 696 | SAFI | 697 +------------------------------------+ 698 | NLRI | 699 +------------------------------------+ 701 In this sequence, the Target AS Number is the AS to whom the 702 BGPsec speaker intends to send the update message. (Note that the 703 Target AS number is the AS number announced by the peer in the 704 OPEN message of the BGP session within which the update is sent.) 705 The Secure_Path and Signature Segments (1 through N-1) are 706 obtained from the BGPsec_Path attribute. Finally, the Address 707 Family Identifier (AFI), Subsequent Address Family Identifier 708 (SAFI), and Network Layer Reachability Information (NLRI) fields 709 are obtained from the MP_REACH_NLRI attribute. Additionally, in 710 the Prefix field of the NLRI (from MP_REACH_NLRI), all of the 711 trailing bits MUST be set to zero when constructing this 712 sequence. 714 o Apply to this octet sequence the digest algorithm (for the 715 algorithm suite of this Signature_Block) to obtain a digest value. 717 o Apply to this digest value the signature algorithm, (for the 718 algorithm suite of this Signature_Block) to obtain the digital 719 signature. Then populate the Signature Field with this digital 720 signature. 722 The Signature Length field is populated with the length (in octets) 723 of the value in the Signature field. 725 4.3. Processing Instructions for Confederation Members 727 Members of autonomous system confederations [5] MUST additionally 728 follow the instructions in this section for processing BGPsec update 729 messages. 731 When a confederation member sends a BGPsec update message to a peer 732 that is a member of the same Member-AS, the confederation member 733 SHALL NOT modify the BGPsec_Path attribute. When a confederation 734 member sends a BGPsec update message to a peer that is a member of 735 the same confederation but is a different Member-AS, the 736 confederation member puts its (private) Member-AS Number (as opposed 737 to the public AS Confederation Identifier) in the AS Number field of 738 the Secure_Path Segment that it adds to the BGPsec update message. 739 Additionally, in this case, the confederation member that generates 740 the Secure_Path Segment sets the Confed_Segment flag to one. This 741 means that in a BGPsec update message, an AS number appears in a 742 Secure_Path Segment with the Confed_Segment flag set whenever, in a 743 non-BGPsec update message, the AS number would appear in a segment of 744 type AS_CONFED_SEQUENCE. 746 Within a confederation, the verification of BGPsec signatures added 747 by other members of the confederation is optional. If a 748 confederation chooses not to have its members verify signatures added 749 by other confederation members, then when sending a BGPsec update 750 message to a peer that is a member of the same confederation, the 751 confederation members MAY set the Signature field within the 752 Signature Segment that it generates to be zero (in lieu of 753 calculating the correct digital signature as described in Section 754 4.2). Note that if a confederation chooses not to verify digital 755 signatures within the confederation, then BGPsec is able to provide 756 no assurances about the integrity of the (private) Member-AS Numbers 757 placed in Secure_Path segments where the Confed_Segment flag is set 758 to one. 760 When a confederation member receives a BGPsec update message from a 761 peer within the confederation and propagates it to a peer outside the 762 confederation, it needs to remove all of the Secure_Path Segments 763 added by confederation members as well as the corresponding Signature 764 Segments. To do this, the confederation member propagating the route 765 outside the confederation does the following: 767 o First, starting with the most recently added Secure_Path segment, 768 remove all of the consecutive Secure_Path segments that have the 769 Confed_Segment flag set to one. Stop this process once a 770 Secure_Path segment is reached which has its Confed_Segment flag 771 set to zero. Keep a count of the number of segments removed in 772 this fashion. 774 o Second, starting with the most recently added Signature Segment, 775 remove a number of Signature Segments equal to the number of 776 Secure_Path Segments removed in the previous step. (That is, 777 remove the K most recently added signature segments, where K is 778 the number of Secure_Path Segments removed in the previous step.) 780 o Finally, add a Secure_Path Segment containing, in the AS field, 781 the AS Confederation Identifier (the public AS number of the 782 confederation) as well as a corresponding Signature Segment. Note 783 that all fields other that the AS field are populated as per 784 Section 4.2. 786 When validating a received BGPsec update message, confederation 787 members need to make the following adjustment to the algorithm 788 presented in Section 5.2. When a confederation member processes 789 (validates) a Signature Segment and its corresponding Secure_Path 790 Segment, the confederation member must note the following. For a 791 signature produced by a peer BGPsec speaker outside of a 792 confederation, the Target AS will always be the AS Confederation 793 Identifier (the public AS number of the confederation) as opposed to 794 the Member-AS Number. 796 To handle this case, when a BGPsec speaker (that is a confederation 797 member) processes a current Secure_Path Segment that has the 798 Confed_Segment flag set to zero, if the next most recently added 799 Secure_Path segment has the Confed_Segment flag set to one then, when 800 computing the digest for the current Secure_Path segment, the BGPsec 801 speaker takes the Target AS Number to be the AS Confederation 802 Identifier of the validating BGPsec speaker's own confederation. 803 (Note that the algorithm in Section 5.2 processes Secure_Path 804 Segments in order from most recently added to least recently added, 805 therefore this special case will apply to the first Secure_Path 806 segment that the algorithm encounters that has the Confed_Segment 807 flag set to zero.) 809 Finally, as discussed above, an AS confederation may optionally 810 decide that its members will not verify digital signatures added by 811 members. In such a federation, when a confederation member runs the 812 algorithm in Section 5.2, the confederation member, during processing 813 of a Signature Segment, first checks whether the Confed_Sequence flag 814 in the corresponding Secure_Path segment is set to one. If the 815 Confed_Sequence flag is set to one in the corresponding Secure_Path 816 segment, the confederation member does not perform any further checks 817 on the Signature Segment and immediately moves on to the next 818 Signature Segment (and checks its corresponding Secure_Path segment). 819 Note that as specified in Section 5.2, it is an error when a BGPsec 820 speaker receives from a peer, who is not in the same AS 821 confederation, a BGPsec update containing a Confed_Sequence flag set 822 to one. (As discussed in Section 5.2, any error in the BGPsec_Path 823 attribute MUST be handled using the "treat-as-withdraw", approach as 824 defined in RFC7606 [11].) 826 4.4. Reconstructing the AS_PATH Attribute 828 BGPsec update messages do not contain the AS_PATH attribute. However, 829 the AS_PATH attribute can be reconstructed from the BGPsec_Path 830 attribute. This is necessary in the case where a route advertisement 831 is received via a BGPsec update message and then propagated to a peer 832 via a non-BGPsec update message (e.g., because the latter peer does 833 not support BGPsec). Note that there may be additional cases where an 834 implementation finds it useful to perform this reconstruction. Before 835 attempting to reconstruct an AS_PATH for the purpose of forwarding an 836 unsigned (non-BGPsec) update to a peer, a BGPsec speaker MUST perform 837 the basic integrity checks listed in Section 5.2 to ensure that the 838 received BGPsec update is properly formed. 840 The AS_PATH attribute can be constructed from the BGPsec_Path 841 attribute as follows. Starting with an empty AS_PATH attribute, 842 process the Secure_Path segments in order from least-recently added 843 (corresponding to the origin) to most-recently added. For each 844 Secure_Path segment perform the following steps: 846 1. If the Confed_Segment flag in the Secure_Path segment is set to 847 one, then look at the most-recently added segment in the AS_PATH. 849 * In the case where the AS_PATH is empty or in the case where 850 the most-recently added segment is of type AS_SEQUENCE then 851 add (prepend to the AS_PATH) a new AS_PATH segment of type 852 AS_CONFED_SEQUENCE. This segment of type AS_CONFED_SEQUENCE 853 shall contain a number of elements equal to the pCount field 854 in the current Secure_Path segment. Each of these elements 855 shall be the AS number contained in the current Secure_Path 856 segment. (That is, if the pCount field is X, then the segment 857 of type AS_CONFED_SEQUENCE contains X copies of the 858 Secure_Path segment's AS Number field.) 860 * In the case where the most-recently added segment in the 861 AS_PATH is of type AS_CONFED_SEQUENCE then add (prepend to the 862 segment) a number of elements equal to the pCount field in the 863 current Secure_Path segment. The value of each of these 864 elements shall be the AS number contained in the current 865 Secure_Path segment. (That is, if the pCount field is X, then 866 add X copies of the Secure_Path segment's AS Number field to 867 the existing AS_CONFED_SEQUENCE.) 869 2. If the Confed_Segment flag in the Secure_Path segment is set to 870 zero, then look at the most-recently added segment in the 871 AS_PATH. 873 * In the case where the AS_PATH is empty, and the pCount field 874 in the Secure_Path segment is greater than zero, add (prepend 875 to the AS_PATH) a new AS_PATH segment of type AS_SEQUENCE. 876 This segment of type AS_SEQUENCE shall contain a number of 877 elements equal to the pCount field in the current Secure_Path 878 segment. Each of these elements shall be the AS number 879 contained in the current Secure_Path segment. (That is, if 880 the pCount field is X, then the segment of type AS_SEQUENCE 881 contains X copies of the Secure_Path segment's AS Number 882 field.) 884 * In the case where the most recently added segment in the 885 AS_PATH is of type AS_SEQUENCE then add (prepend to the 886 segment) a number of elements equal to the pCount field in the 887 current Secure_Path segment. The value of each of these 888 elements shall be the AS number contained in the current 889 Secure_Path segment. (That is, if the pCount field is X, then 890 add X copies of the Secure_Path segment's AS Number field to 891 the existing AS_SEQUENCE.) 893 As part of the above described procedure, the following additional 894 actions are performed in order not to exceed the size limitations of 895 AS_SEQUENCE and AS_CONFED_SEQUENCE. While adding the next Secure_Path 896 segment (with its prepends, if any) to the AS_PATH being assembled, 897 if it would cause the AS_SEQUENCE (or AS_CONFED_SEQUENCE) at hand to 898 exceed the 255 ASN per segment limit [2][5], then the BGPsec speaker 899 would follow the recommendations in RFC4271 [2] and RFC5065 [5] of 900 creating another segment of the same type (AS_SEQUENCE or 901 AS_CONFED_SEQUENCE) and continue filling that. 903 5. Processing a Received BGPsec Update 905 Upon receiving a BGPsec update message from an external (eBGP) peer, 906 a BGPsec speaker SHOULD validate the message to determine the 907 authenticity of the path information contained in the BGPsec_Path 908 attribute. Typically, a BGPsec speaker will also wish to perform 909 origin validation (see [19] and [20]) on an incoming BGPsec update 910 message, but such validation is independent of the validation 911 described in this section. 913 Section 5.1 provides an overview of BGPsec validation and Section 5.2 914 provides a specific algorithm for performing such validation. (Note 915 that an implementation need not follow the specific algorithm in 916 Section 5.2 as long as the input/output behavior of the validation is 917 identical to that of the algorithm in Section 5.2.) During 918 exceptional conditions (e.g., the BGPsec speaker receives an 919 incredibly large number of update messages at once) a BGPsec speaker 920 MAY temporarily defer validation of incoming BGPsec update messages. 921 The treatment of such BGPsec update messages, whose validation has 922 been deferred, is a matter of local policy. However, an 923 implementation SHOULD ensure that deferment of validation and status 924 of deferred messages is visible to the operator. 926 The validity of BGPsec update messages is a function of the current 927 RPKI state. When a BGPsec speaker learns that RPKI state has changed 928 (e.g., from an RPKI validating cache via the RPKI-to-Router protocol 929 [15]), the BGPsec speaker MUST re-run validation on all affected 930 update messages stored in its Adj-RIB-In. For example, when a given 931 RPKI certificate ceases to be valid (e.g., it expires or is revoked), 932 all update messages containing a signature whose SKI matches the SKI 933 in the given certificate must be re-assessed to determine if they are 934 still valid. If this reassessment determines that the validity state 935 of an update has changed then, depending on local policy, it may be 936 necessary to re-run best path selection. 938 BGPsec update messages do not contain an AS_PATH attribute. 939 Therefore, a BGPsec speaker MUST utilize the AS path information in 940 the BGPsec_Path attribute in all cases where it would otherwise use 941 the AS path information in the AS_PATH attribute. The only exception 942 to this rule is when AS path information must be updated in order to 943 propagate a route to a peer (in which case the BGPsec speaker follows 944 the instructions in Section 4). Section 4.4 provides an algorithm 945 for constructing an AS_PATH attribute from a BGPsec_Path attribute. 946 Whenever the use of AS path information is called for (e.g., loop 947 detection, or use of AS path length in best path selection) the 948 externally visible behavior of the implementation shall be the same 949 as if the implementation had run the algorithm in Section 4.4 and 950 used the resulting AS_PATH attribute as it would for a non-BGPsec 951 update message. 953 Many signature algorithms are non-deterministic. That is, many 954 signature algorithms will produce different signatures each time they 955 are run (even when they are signing the same data with the same key). 956 Therefore, if an implementation receives a BGPsec update from a peer 957 and later receives a second BGPsec update message from the same peer, 958 the implementation SHOULD treat the second message as a duplicate 959 update message if it differs from the first update message only in 960 the Signature fields (within the BGPsec_Path attribute). That is, if 961 all the fields in the second update are identical to the fields in 962 the first update message, except for the Signature fields, then the 963 second update message should be treated as a duplicate of the first 964 update message. Note that if other fields (e.g., the Subject Key 965 Identifier field) within a Signature segment differ between two 966 update messages then the two updates are not duplicates. 968 With regards to the processing of duplicate update messages, if the 969 first update message is valid, then an implementation SHOULD NOT run 970 the validation procedure on the second, duplicate update message 971 (even if the bits of the signature field are different). If the 972 first update message is not valid, then an implementation SHOULD run 973 the validation procedure on the second duplicate update message (as 974 the signatures in the second update may be valid even though the 975 first contained a signature that was invalid). 977 5.1. Overview of BGPsec Validation 979 Validation of a BGPsec update messages makes use of data from RPKI 980 certificates. In particular, it is necessary that the recipient have 981 access to the following data obtained from valid RPKI certificates: 982 the AS Number, Public Key and Subject Key Identifier from each valid 983 RPKI router certificate. 985 Note that the BGPsec speaker could perform the validation of RPKI 986 certificates on its own and extract the required data, or it could 987 receive the same data from a trusted cache that performs RPKI 988 validation on behalf of (some set of) BGPsec speakers. (For example, 989 the trusted cache could deliver the necessary validity information to 990 the BGPsec speaker using the router key PDU [16] for the RPKI-to- 991 Router protocol [15].) 993 To validate a BGPsec update message containing the BGPsec_Path 994 attribute, the recipient performs the validation steps specified in 995 Section 5.2. The validation procedure results in one of two states: 996 'Valid' and 'Not Valid'. 998 It is expected that the output of the validation procedure will be 999 used as an input to BGP route selection. That said, BGP route 1000 selection, and thus the handling of the validation states is a matter 1001 of local policy, and is handled using local policy mechanisms. 1002 Implementations SHOULD enable operators to set such local policy on a 1003 per-session basis. (That is, we expect some operators will choose to 1004 treat BGPsec validation status differently for update messages 1005 received over different BGP sessions.) 1007 It is expected that BGP peers will generally prefer routes received 1008 via 'Valid' BGPsec update messages over both routes received via 'Not 1009 Valid' BGPsec update messages and routes received via update messages 1010 that do not contain the BGPsec_Path attribute. However, BGPsec 1011 specifies no changes to the BGP decision process. (See [17] for 1012 related operational considerations.) 1014 BGPsec validation needs only be performed at the eBGP edge. The 1015 validation status of a BGP signed/unsigned update MAY be conveyed via 1016 iBGP from an ingress edge router to an egress edge router via some 1017 mechanism, according to local policy within an AS. As discussed in 1018 Section 4, when a BGPsec speaker chooses to forward a (syntactically 1019 correct) BGPsec update message, it SHOULD be forwarded with its 1020 BGPsec_Path attribute intact (regardless of the validation state of 1021 the update message). Based entirely on local policy, an egress 1022 router receiving a BGPsec update message from within its own AS MAY 1023 choose to perform its own validation. 1025 5.2. Validation Algorithm 1027 This section specifies an algorithm for validation of BGPsec update 1028 messages. A conformant implementation MUST include a BGPsec update 1029 validation algorithm that is functionally equivalent to the 1030 externally visible behavior of this algorithm. 1032 First, the recipient of a BGPsec update message performs a check to 1033 ensure that the message is properly formed. Specifically, the 1034 recipient performs the following checks: 1036 1. Check to ensure that the entire BGPsec_Path attribute is 1037 syntactically correct (conforms to the specification in this 1038 document). 1040 2. Check that each Signature_Block contains one Signature segment 1041 for each Secure_Path segment in the Secure_Path portion of the 1042 BGPsec_Path attribute. (Note that the entirety of each 1043 Signature_Block must be checked to ensure that it is well formed, 1044 even though the validation process may terminate before all 1045 signatures are cryptographically verified.) 1047 3. Check that the update message does not contain an AS_PATH 1048 attribute. 1050 4. If the update message was received from a peer that is not a 1051 member of the BGPsec speaker's AS confederation, check to ensure 1052 that none of the Secure_Path segments contain a Flags field with 1053 the Confed_Sequence flag set to one. 1055 5. If the update message was received from a peer that is not 1056 expected to set pCount equal to zero (see Section 4.2) then check 1057 to ensure that the pCount field in the most-recently added 1058 Secure_Path segment is not equal to zero. 1060 If any of these checks fail, it is an error in the BGPsec_Path 1061 attribute. Any of these errors in the BGPsec_Path attribute are 1062 handled as per RFC7606 [11]. BGPsec speakers MUST handle these errors 1063 using the "treat-as-withdraw" approach as defined in RFC7606 [11]. 1065 Next, the BGPsec speaker examines the Signature_Blocks in the 1066 BGPsec_Path attribute. A Signature_Block corresponding to an 1067 algorithm suite that the BGPsec speaker does not support is not 1068 considered in validation. If there is no Signature_Block 1069 corresponding to an algorithm suite that the BGPsec speaker supports, 1070 then the BGPsec speaker MUST treat the update message in the same 1071 manner that the BGPsec speaker would treat an (unsigned) update 1072 message that arrived without a BGPsec_Path attribute. 1074 For each remaining Signature_Block (corresponding to an algorithm 1075 suite supported by the BGPsec speaker), the BGPsec speaker iterates 1076 through the Signature segments in the Signature_Block, starting with 1077 the most recently added segment (and concluding with the least 1078 recently added segment). Note that there is a one-to-one 1079 correspondence between Signature segments and Secure_Path segments 1080 within the BGPsec_Path attribute. The following steps make use of 1081 this correspondence. 1083 o (Step 0): For clarity, let us number the Secure_Path and 1084 corresponding Signature Segments from 1 to N as follows. Let 1085 Secure_Path Segment 1 and Signature Segment 1 be the segments 1086 produced by the origin AS. Let Secure_Path Segment 2 and Signature 1087 Segment 2 be the segments added by the next AS after the origin. 1088 Continue this method of numbering and ultimately let Signature 1089 Segment N be the Signature Segment that is currently being 1090 verified and let Secure_Path Segment N be the corresponding 1091 Secure_Path Segment. 1093 o (Step I): Locate the public key needed to verify the signature (in 1094 the current Signature segment). To do this, consult the valid 1095 RPKI router certificate data and look up all valid (AS, SKI, 1096 Public Key) triples in which the AS matches the AS number in the 1097 corresponding Secure_Path segment. Of these triples that match 1098 the AS number, check whether there is an SKI that matches the 1099 value in the Subject Key Identifier field of the Signature 1100 segment. If this check finds no such matching SKI value, then 1101 mark the entire Signature_Block as 'Not Valid' and proceed to the 1102 next Signature_Block. 1104 o (Step II): Compute the digest function (for the given algorithm 1105 suite) on the appropriate data. 1107 In order to verify the digital signature in Signature Segment N, 1108 construct the following sequence of octets to be hashed. 1110 Sequence of Octets to be Hashed 1111 +------------------------------------+ 1112 | Target AS Number | 1113 +------------------------------------+ -\ 1114 | Signature Segment : N-1 | \ 1115 +------------------------------------+ | 1116 | Secure_Path Segment : N | | 1117 +------------------------------------+ \ 1118 ... > For N Hops 1119 +------------------------------------+ / 1120 | Signature Segment : 1 | | 1121 +------------------------------------+ | 1122 | Secure_Path Segment : 2 | / 1123 +------------------------------------+ -/ 1124 | Secure_Path Segment : 1 | 1125 +------------------------------------+ 1126 | Algorithm Suite Identifier | 1127 +------------------------------------+ 1128 | AFI | 1129 +------------------------------------+ 1130 | SAFI | 1131 +------------------------------------+ 1132 | NLRI | 1133 +------------------------------------+ 1135 For the first segment to be processed (the most recently added 1136 segment), the 'Target AS Number' is the AS number of the BGPsec 1137 speaker validating the update message. Note that if a BGPsec 1138 speaker uses multiple AS Numbers (e.g., the BGPsec speaker is a 1139 member of a confederation), the AS number used here MUST be the AS 1140 number announced in the OPEN message for the BGP session over 1141 which the BGPsec update was received. 1143 For each other Signature Segment, the 'Target AS Number' is the AS 1144 number in the Secure_Path segment that corresponds to the 1145 Signature Segment added immediately after the one being processed. 1146 (That is, in the Secure_Path segment that corresponds to the 1147 Signature segment that the validator just finished processing.) 1149 The Secure_Path and Signature Segment are obtained from the 1150 BGPsec_Path attribute. The Address Family Identifier (AFI), 1151 Subsequent Address Family Identifier (SAFI), and Network Layer 1152 Reachability Information (NLRI) fields are obtained from the 1153 MP_REACH_NLRI attribute. Additionally, in the Prefix field of the 1154 NLRI (from MP_REACH_NLRI), all of the trailing bits MUST be set to 1155 zero when constructing this sequence. 1157 o (Step III): Use the signature validation algorithm (for the given 1158 algorithm suite) to verify the signature in the current segment. 1159 That is, invoke the signature validation algorithm on the 1160 following three inputs: the value of the Signature field in the 1161 current segment; the digest value computed in Step II above; and 1162 the public key obtained from the valid RPKI data in Step I above. 1163 If the signature validation algorithm determines that the 1164 signature is invalid, then mark the entire Signature_Block as 'Not 1165 Valid' and proceed to the next Signature_Block. If the signature 1166 validation algorithm determines that the signature is valid, then 1167 continue processing Signature Segments (within the current 1168 Signature_Block). 1170 If all Signature Segments within a Signature_Block pass validation 1171 (i.e., all segments are processed and the Signature_Block has not yet 1172 been marked 'Not Valid'), then the Signature_Block is marked as 1173 'Valid'. 1175 If at least one Signature_Block is marked as 'Valid', then the 1176 validation algorithm terminates and the BGPsec update message is 1177 deemed to be 'Valid'. (That is, if a BGPsec update message contains 1178 two Signature_Blocks then the update message is deemed 'Valid' if the 1179 first Signature_Block is marked 'Valid' OR the second Signature_Block 1180 is marked 'Valid'.) 1182 6. Algorithms and Extensibility 1184 6.1. Algorithm Suite Considerations 1186 Note that there is currently no support for bilateral negotiation 1187 (using BGP capabilities) between BGPsec peers to use a particular 1188 (digest and signature) algorithm suite. This is because the algorithm 1189 suite used by the sender of a BGPsec update message must be 1190 understood not only by the peer to whom it is directly sending the 1191 message, but also by all BGPsec speakers to whom the route 1192 advertisement is eventually propagated. Therefore, selection of an 1193 algorithm suite cannot be a local matter negotiated by BGP peers, but 1194 instead must be coordinated throughout the Internet. 1196 To this end, a mandatory algorithm suites document exists which 1197 specifies a mandatory-to-use 'current' algorithm suite for use by all 1198 BGPsec speakers [10]. 1200 We anticipate that, in the future, the mandatory algorithm suites 1201 document will be updated to specify a transition from the 'current' 1202 algorithm suite to a 'new' algorithm suite. During the period of 1203 transition (likely a small number of years), all BGPsec update 1204 messages SHOULD simultaneously use both the 'current' algorithm suite 1205 and the 'new' algorithm suite. (Note that Sections 3 and 4 specify 1206 how the BGPsec_Path attribute can contain signatures, in parallel, 1207 for two algorithm suites.) Once the transition is complete, use of 1208 the old 'current' algorithm will be deprecated, use of the 'new' 1209 algorithm will be mandatory, and a subsequent 'even newer' algorithm 1210 suite may be specified as recommended to implement. Once the 1211 transition has successfully been completed in this manner, BGPsec 1212 speakers SHOULD include only a single Signature_Block (corresponding 1213 to the 'new' algorithm). 1215 6.2. Extensibility Considerations 1217 This section discusses potential changes to BGPsec that would require 1218 substantial changes to the processing of the BGPsec_Path and thus 1219 necessitate a new version of BGPsec. Examples of such changes 1220 include: 1222 o A new type of signature algorithm that produces signatures of 1223 variable length 1225 o A new type of signature algorithm for which the number of 1226 signatures in the Signature_Block is not equal to the number of 1227 ASes in the Secure_Path (e.g., aggregate signatures) 1229 o Changes to the data that is protected by the BGPsec signatures 1230 (e.g., attributes other than the AS path) 1232 In the case that such a change to BGPsec were deemed desirable, it is 1233 expected that a subsequent version of BGPsec would be created and 1234 that this version of BGPsec would specify a new BGP path attribute, 1235 let's call it BGPsec_Path_Two, which is designed to accommodate the 1236 desired changes to BGPsec. In such a case, the mandatory algorithm 1237 suites document would be updated to specify algorithm suites 1238 appropriate for the new version of BGPsec. 1240 At this point a transition would begin which is analogous to the 1241 algorithm transition discussed in Section 6.1. During the transition 1242 period all BGPsec speakers should simultaneously include both the 1243 BGPsec_Path attribute and the new BGPsec_Path_Two attribute. Once 1244 the transition is complete, the use of BGPsec_Path could then be 1245 deprecated, at which point BGPsec speakers should include only the 1246 new BGPsec_Path_Two attribute. Such a process could facilitate a 1247 transition to a new BGPsec semantics in a backwards compatible 1248 fashion. 1250 7. Security Considerations 1252 For a discussion of the BGPsec threat model and related security 1253 considerations, please see [14]. 1255 7.1 Security Guarantees 1257 When used in conjunction with Origin Validation (see [19] and [20]), 1258 a BGPsec speaker who receives a valid BGPsec update message, 1259 containing a route advertisement for a given prefix, is provided with 1260 the following security guarantees: 1262 o The origin AS number corresponds to an autonomous system that has 1263 been authorized, in the RPKI, by the IP address space holder to 1264 originate route advertisements for the given prefix. 1266 o For each AS in the path, a BGPsec speaker authorized by the holder 1267 of the AS number intentionally chose (in accordance with local 1268 policy) to propagate the route advertisement to the subsequent AS 1269 in the path. 1271 That is, the recipient of a valid BGPsec update message is assured 1272 that the update propagated via the sequence of ASes listed in the 1273 Secure_Path portion of the BGPsec_Path attribute. (It should be noted 1274 that BGPsec does not offer any guarantee that the data packets would 1275 flow along the indicated path; it only guarantees that the BGP update 1276 conveying the path indeed propagated along the indicated path.) 1277 Furthermore, the recipient is assured that this path terminates in an 1278 autonomous system that has been authorized by the IP address space 1279 holder as a legitimate destination for traffic to the given prefix. 1281 Note that although BGPsec provides a mechanism for an AS to validate 1282 that a received update message has certain security properties, the 1283 use of such a mechanism to influence route selection is completely a 1284 matter of local policy. Therefore, a BGPsec speaker can make no 1285 assumptions about the validity of a route received from an external 1286 BGPsec peer. That is, a compliant BGPsec peer may (depending on the 1287 local policy of the peer) send update messages that fail the validity 1288 test in Section 5. Thus, a BGPsec speaker MUST completely validate 1289 all BGPsec update messages received from external peers. (Validation 1290 of update messages received from internal peers is a matter of local 1291 policy, see Section 5). 1293 7.2 On the Removal of BGPsec Signatures 1295 There may be cases where a BGPsec speaker deems 'Valid' (as per the 1296 validation algorithm in Section 5.2) a BGPsec update message that 1297 contains both a 'Valid' and a 'Not Valid' Signature_Block. That is, 1298 the update message contains two sets of signatures corresponding to 1299 two algorithm suites, and one set of signatures verifies correctly 1300 and the other set of signatures fails to verify. In this case, the 1301 protocol specifies that a BGPsec speaker choosing to propagate the 1302 route advertisement in such an update message SHOULD add its 1303 signature to each of the Signature_Blocks. Thus the BGPsec speaker 1304 creates a signature using both algorithm suites and creates a new 1305 update message that contains both the 'Valid' and the 'Not Valid' set 1306 of signatures (from its own vantage point). 1308 To understand the reason for such a design decision consider the case 1309 where the BGPsec speaker receives an update message with both a set 1310 of algorithm A signatures which are 'Valid' and a set of algorithm B 1311 signatures which are 'Not Valid'. In such a case it is possible 1312 (perhaps even likely, depending on the state of the algorithm 1313 transition) that some of the BGPsec speaker's peers (or other 1314 entities further 'downstream' in the BGP topology) do not support 1315 algorithm A. Therefore, if the BGPsec speaker were to remove the 'Not 1316 Valid' set of signatures corresponding to algorithm B, such entities 1317 would treat the message as though it were unsigned. By including the 1318 'Not Valid' set of signatures when propagating a route advertisement, 1319 the BGPsec speaker ensures that 'downstream' entities have as much 1320 information as possible to make an informed opinion about the 1321 validation status of a BGPsec update. 1323 Note also that during a period of partial BGPsec deployment, a 1324 'downstream' entity might reasonably treat unsigned messages 1325 differently from BGPsec updates that contain a single set of 'Not 1326 Valid' signatures. That is, by removing the set of 'Not Valid' 1327 signatures the BGPsec speaker might actually cause a downstream 1328 entity to 'upgrade' the status of a route advertisement from 'Not 1329 Valid' to unsigned. Finally, note that in the above scenario, the 1330 BGPsec speaker might have deemed algorithm A signatures 'Valid' only 1331 because of some issue with RPKI state local to its AS (for example, 1332 its AS might not yet have obtained a CRL indicating that a key used 1333 to verify an algorithm A signature belongs to a newly revoked 1334 certificate). In such a case, it is highly desirable for a 1335 downstream entity to treat the update as 'Not Valid' (due to the 1336 revocation) and not as 'unsigned' (which would happen if the 'Not 1337 Valid' Signature_Blocks were removed). 1339 A similar argument applies to the case where a BGPsec speaker (for 1340 some reason such as lack of viable alternatives) selects as its best 1341 path (to a given prefix) a route obtained via a 'Not Valid' BGPsec 1342 update message. In such a case, the BGPsec speaker should propagate a 1343 signed BGPsec update message, adding its signature to the 'Not Valid' 1344 signatures that already exist. Again, this is to ensure that 1345 'downstream' entities are able to make an informed decision and not 1346 erroneously treat the route as unsigned. It should also be noted 1347 that due to possible differences in RPKI data observed at different 1348 vantage points in the network, a BGPsec update deemed 'Not Valid' at 1349 an upstream BGPsec speaker may be deemed 'Valid' by another BGP 1350 speaker downstream. 1352 Indeed, when a BGPsec speaker signs an outgoing update message, it is 1353 not attesting to a belief that all signatures prior to its are valid. 1354 Instead it is merely asserting that: 1356 o The BGPsec speaker received the given route advertisement with the 1357 indicated NLRI and Secure_Path; and 1359 o The BGPsec speaker chose to propagate an advertisement for this 1360 route to the peer (implicitly) indicated by the 'Target AS'. 1362 7.3 Mitigation of Denial of Service Attacks 1364 The BGPsec update validation procedure is a potential target for 1365 denial of service attacks against a BGPsec speaker. Here we consider 1366 the mitigation only of denial of service attacks that are specific to 1367 BGPsec. 1369 To mitigate the effectiveness of such denial of service attacks, 1370 BGPsec speakers should implement an update validation algorithm that 1371 performs expensive checks (e.g., signature verification) after 1372 performing less expensive checks (e.g., syntax checks). The 1373 validation algorithm specified in Section 5.2 was chosen so as to 1374 perform checks which are likely to be expensive after checks that are 1375 likely to be inexpensive. However, the relative cost of performing 1376 required validation steps may vary between implementations, and thus 1377 the algorithm specified in Section 5.2 may not provide the best 1378 denial of service protection for all implementations. 1380 Additionally, sending update messages with very long AS paths (and 1381 hence a large number of signatures) is a potential mechanism to 1382 conduct denial of service attacks. For this reason, it is important 1383 that an implementation of the validation algorithm stops attempting 1384 to verify signatures as soon as an invalid signature is found. (This 1385 ensures that long sequences of invalid signatures cannot be used for 1386 denial of service attacks.) Furthermore, implementations can mitigate 1387 such attacks by only performing validation on update messages that, 1388 if valid, would be selected as the best path. That is, if an update 1389 message contains a route that would lose out in best path selection 1390 for other reasons (e.g., a very long AS path) then it is not 1391 necessary to determine the BGPsec-validity status of the route. 1393 7.4 Additional Security Considerations 1395 The mechanism of setting the pCount field to zero is included in this 1396 specification to enable route servers in the control path to 1397 participate in BGPsec without increasing the effective length of the 1398 AS-PATH. However, entities other than route servers could 1399 conceivably use this mechanism (set the pCount to zero) to attract 1400 traffic (by reducing the effective length of the AS-PATH) 1401 illegitimately. This risk is largely mitigated if every BGPsec 1402 speaker drops incoming update messages that set pCount to zero but 1403 come from a peer that is not a route server. However, note that a 1404 recipient of a BGPsec update message within which an upstream entity 1405 two or more hops away has set pCount to zero is unable to verify for 1406 themselves whether pCount was set to zero legitimately. 1408 BGPsec does not provide protection against attacks at the transport 1409 layer. As with any BGP session, an adversary on the path between a 1410 BGPsec speaker and its peer is able to perform attacks such as 1411 modifying valid BGPsec updates to cause them to fail validation, 1412 injecting (unsigned) BGP update messages without BGPsec_Path 1413 attributes, injecting BGPsec update messages with BGPsec_Path 1414 attributes that fail validation, or causing the peer to tear-down the 1415 BGP session. The use of BGPsec does nothing to increase the power of 1416 an on-path adversary -- in particular, even an on-path adversary 1417 cannot cause a BGPsec speaker to believe a BGPsec-invalid route is 1418 valid. However, as with any BGP session, BGPsec sessions SHOULD be 1419 protected by appropriate transport security mechanisms. 1421 8. IANA Considerations 1423 This document registers a new capability in the registry of BGP 1424 Capabilities. The description for the new capability is "BGPsec 1425 Capability". The reference for the new capability is this document 1426 (i.e., the RFC that replaces draft-ietf-sidr-bgpsec-protocol), see 1427 Section 2.1. 1429 This document registers a new path attribute in the registry of BGP 1430 Path Attributes. The code for this new attribute is "BGPsec_Path". 1431 The reference for the new capability is this document (i.e., the RFC 1432 that replaces draft-ietf-sidr-bgpsec-protocol), see Section 3. 1434 This document does not create any new IANA registries. 1436 9. Contributors 1438 9.1. Authors 1440 Rob Austein 1441 Dragon Research Labs 1442 sra@hactrn.net 1444 Steven Bellovin 1445 Columbia University 1446 smb@cs.columbia.edu 1448 Randy Bush 1449 Internet Initiative Japan 1450 randy@psg.com 1452 Russ Housley 1453 Vigil Security 1454 housley@vigilsec.com 1456 Matt Lepinski 1457 New College of Florida 1458 mlepinski@ncf.edu 1460 Stephen Kent 1461 BBN Technologies 1462 kent@bbn.com 1464 Warren Kumari 1465 Google 1466 warren@kumari.net 1468 Doug Montgomery 1469 USA National Institute of Standards and Technology 1470 dougm@nist.gov 1472 Kotikalapudi Sriram 1473 USA National Institute of Standards and Technology 1474 kotikalapudi.sriram@nist.gov 1476 Samuel Weiler 1477 Parsons 1478 weiler+ietf@watson.org 1480 9.2. Acknowledgements 1482 The authors would like to thank Michael Baer, Luke Berndt, Oliver 1483 Borchert, Wes George, Jeff Haas, Sharon Goldberg, Ed Kern, David 1484 Mandelberg, Doug Maughan, Pradosh Mohapatra, Chris Morrow, Russ 1485 Mundy, Sandy Murphy, Keyur Patel, Mark Reynolds, Heather Schiller, 1486 Jason Schiller, John Scudder, Ruediger Volk and David Ward for their 1487 valuable input and review. 1489 10. Normative References 1491 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1492 Levels", BCP 14, RFC 2119, March 1997. 1493 [2] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 1494 Gateway Protocol 4", RFC 4271, January 2006. 1496 [3] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1497 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 1499 [4] Vohra, Q. and E. Chen, "BGP Support for Four-Octet AS Number 1500 Space", RFC 6793, December 2012. 1502 [5] Traina, P., McPherson, D., and J. Scudder, "Autonomous System 1503 Confederations for BGP", RFC 5065, August 2007. 1505 [6] Scudder, J. and R. Chandra, "Capabilities Advertisement with 1506 BGP-4", RFC 5492, February 2009. 1508 [7] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1509 Origin Authorizations (ROAs)", RFC 6482, February 2012. 1511 [8] Patel, K., Ward, D., and R. Bush, "Extended Message support for 1512 BGP", draft-ietf-idr-bgp-extended-messages (work in progress), 1513 May 2016. 1515 [9] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec 1516 Router Certificates, Certificate Revocation Lists, and 1517 Certification Requests", draft-ietf-sidr-bgpsec-pki-profiles 1518 (work in progress), June 2016. 1520 [10] Turner, S., "BGP Algorithms, Key Formats, & Signature Formats", 1521 draft-ietf-sidr-bgpsec-algs (work in progress), April 2016. 1523 [11] Chen, E., Scudder, J., Mohapatra, P., and K. Patel, "Revised 1524 Error Handling for BGP UPDATE Messages", RFC 7606, August 2015. 1526 11. Informative References 1528 [12] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure 1529 Internet Routing", RFC 6480, February 2012. 1531 [13] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET 1532 and AS_CONFED_SET in BGP", RFC 6472, December 2011. 1534 [14] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 1535 7132, February 2014. 1537 [15] Bush, R. and R. Austein, "The Resource Public Key 1538 Infrastructure (RPKI) to Router Protocol", draft-ietf-sidr- 1539 rpki-rtr-rfc6810-bis (work in progress), March 2016. 1541 [16] Bush, R., Turner, S., and K. Patel, "Router Keying for BGPsec", 1542 draft-ietf-sidr-rtr-keying (work in progress), June 2016. 1544 [17] Bush, R., "BGPsec Operational Considerations", draft-ietf-sidr- 1545 bgpsec-ops (work in progress), June 2016. 1547 [18] George, W. and S. Murphy, "BGPsec Considerations for AS 1548 Migration", draft-ietf-sidr-as-migration (work in progress), 1549 April 2016. 1551 [19] Huston, G. and G. Michaelson, "Validation of Route Origination 1552 Using the Resource Certificate Public Key Infrastructure (PKI) 1553 and Route Origin Authorizations (ROAs)", RFC 6483, February 1554 2013. 1556 [20] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, 1557 "BGP Prefix Origin Validation", RFC 6811, January 2013. 1559 Author's Address 1561 Matthew Lepinski (editor) 1562 New College of Florida 1563 5800 Bay Shore Road 1564 Sarasota, FL 34243 1565 USA 1567 Email: mlepinski@ncf.edu 1569 Kotikalapudi Sriram (editor) 1570 National Institute of Standards and Technology 1571 100 Bureau Drive 1572 Gaithersburg, MD 20899 1573 USA 1575 Email: kotikalapudi.sriram@nist.gov