idnits 2.17.1 draft-ietf-sidr-bgpsec-protocol-13.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 (July 6, 2015) is 3217 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 July 6, 2015 5 Expires: January 6, 2016 7 BGPsec Protocol Specification 8 draft-ietf-sidr-bgpsec-protocol-13 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 January 6, 2016. 44 Copyright Notice 46 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. BGPsec Negotiation . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. The BGPsec Capability . . . . . . . . . . . . . . . . . . 3 64 2.2. Negotiating BGPsec Support . . . . . . . . . . . . . . . . 4 65 3. The BGPsec_Path Attribute . . . . . . . . . . . . . . . . . . 6 66 3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.2. Signature_Block . . . . . . . . . . . . . . . . . . . . . 8 68 4. Generating a BGPsec Update . . . . . . . . . . . . . . . . . . 11 69 4.1. Originating a New BGPsec Update . . . . . . . . . . . . . 12 70 4.2. Propagating a Route Advertisement . . . . . . . . . . . . 15 71 4.3. Processing Instructions for Confederation Members . . . . 19 72 4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . . 21 73 5. Processing a Received BGPsec Update . . . . . . . . . . . . . 22 74 5.1. Overview of BGPsec Validation . . . . . . . . . . . . . . 25 75 5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . . 26 76 6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 30 77 6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 30 78 6.2. Extensibility Considerations . . . . . . . . . . . . . . . 30 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 80 7.1 Security Guarantees . . . . . . . . . . . . . . . . . . . . 31 81 7.2 On the Removal of BGPsec Signatures . . . . . . . . . . . . 32 82 7.3 Mitigation of Denial of Service Attacks . . . . . . . . . . 35 83 7.4 Additional Security Considerations . . . . . . . . . . . . . 35 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 85 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37 86 9.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 37 87 9.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 37 88 10. Normative References . . . . . . . . . . . . . . . . . . . . 38 89 11. Informative References . . . . . . . . . . . . . . . . . . . 38 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39 92 1. Introduction 93 This document describes BGPsec, a mechanism for providing path 94 security for Border Gateway Protocol (BGP) [2] route advertisements. 95 That is, a BGP speaker who receives a valid BGPsec update has 96 cryptographic assurance that the advertised route has the following 97 property: Every AS on the path of ASes listed in the update message 98 has explicitly authorized the advertisement of the route to the 99 subsequent AS in the path. 101 This document specifies a new optional (non-transitive) BGP path 102 attribute, BGPsec_Path. It also describes how a BGPsec-compliant BGP 103 speaker (referred to hereafter as a BGPsec speaker) can generate, 104 propagate, and validate BGP update messages containing this attribute 105 to obtain the above assurances. 107 BGPsec is intended to be used to supplement BGP Origin Validation 108 [19] and when used in conjunction with origin validation, it is 109 possible to prevent a wide variety of route hijacking attacks against 110 BGP. 112 BGPsec relies on the Resource Public Key Infrastructure (RPKI) 113 certificates that attest to the allocation of AS number and IP 114 address resources. (For more information on the RPKI, see [12] and 115 the documents referenced therein.) Any BGPsec speaker who wishes to 116 send, to external (eBGP) peers, BGP update messages containing the 117 BGPsec_Path needs to possess a private key associated with an RPKI 118 router certificate [9] that corresponds to the BGPsec speaker's AS 119 number. Note, however, that a BGPsec speaker does not need such a 120 certificate in order to validate received update messages containing 121 the BGPsec_Path attribute. 123 2. BGPsec Negotiation 125 This document defines a new BGP capability [6] that allows a BGP 126 speaker to advertise to a neighbor the ability to send or to receive 127 BGPsec update messages (i.e., update messages containing the 128 BGPsec_Path attribute). 130 2.1. The BGPsec Capability 132 This capability has capability code : TBD 134 The capability length for this capability MUST be set to 3. 136 The three octets of the capability value are specified as follows. 138 BGPsec Send Capability Value: 140 0 1 2 3 4 5 6 7 141 +---------------------------------------+ 142 | Version | Dir | Reserved | 143 +---------------------------------------+ 144 | | 145 +------ AFI -----+ 146 | | 147 +---------------------------------------+ 149 The first four bits of the first octet indicate the version of BGPsec 150 for which the BGP speaker is advertising support. This document 151 defines only BGPsec version 0 (all four bits set to zero). Other 152 versions of BGPsec may be defined in future documents. A BGPsec 153 speaker MAY advertise support for multiple versions of BGPsec by 154 including multiple versions of the BGPsec capability in its BGP OPEN 155 message. 157 The fifth bit of the first octet is a direction bit which indicates 158 whether the BGP speaker is advertising the capability to send BGPsec 159 update messages or receive BGPsec update messages. The BGP speaker 160 sets this bit to 0 to indicate the capability to receive BGPsec 161 update messages. The BGP speaker sets this bit to 1 to indicate the 162 capability to send BGPsec update messages. 164 The remaining three bits of the first octet are reserved for future 165 use. These bits are set to zero by the sender of the capability and 166 ignored by the receiver of the capability. 168 The second and third octets contain the 16-bit Address Family 169 Identifier (AFI) which indicates the address family for which the 170 BGPsec speaker is advertising support for BGPsec. This document only 171 specifies BGPsec for use with two address families, IPv4 and IPv6, 172 AFI values 1 and 2 respectively. BGPsec for use with other address 173 families may be specified in future documents. 175 2.2. Negotiating BGPsec Support 177 In order to indicate that a BGP speaker is willing to send BGPsec 178 update messages (for a particular address family), a BGP speaker 179 sends the BGPsec Capability (see Section 2.1) with the Direction bit 180 (the fifth bit of the first octet) set to 1. In order to indicate 181 that the speaker is willing to receive BGP update messages containing 182 the BGPsec_Path attribute (for a particular address family), a BGP 183 speaker sends the BGPsec capability with the Direction bit set to 0. 184 In order to advertise the capability to both send and receive BGPsec 185 update messages, the BGP speaker sends two copies of the BGPsec 186 capability (one with the direction bit set to 0 and one with the 187 direction bit set to 1). 189 Similarly, if a BGP speaker wishes to use BGPsec with two different 190 address families (i.e., IPv4 and IPv6) over the same BGP session, 191 then the speaker includes two instances of this capability (one for 192 each address family) in the BGP OPEN message. A BGP speaker MUST 193 support the BGP multiprotocol extension [3]. Additionally, a BGP 194 speaker MUST NOT advertise the capability of BGPsec support for a 195 particular AFI unless it has also advertised the multiprotocol 196 extension capability for the same AFI combination [3]. 198 In a session where BGP session, a peer is permitted to send update 199 messages containing the BGPsec_Path attribute if, and only if: 201 o The given peer sent the BGPsec capability for a particular version 202 of BGPsec and a particular address family with the Direction bit 203 set to 1; and 205 o The other peer sent the BGPsec capability for the same version of 206 BGPsec and the same address family with the Direction bit set to 207 0. 209 In such a session, we say that the use of (the particular version of) 210 BGPsec has been negotiated (for a particular address family). BGP 211 update messages without the BGPsec_Path attribute MAY be sent within 212 a session regardless of whether or not the use of BGPsec is 213 successfully negotiated. However, if BGPsec is not successfully 214 negotiated, then BGP update messages containing the BGPsec_Path 215 attribute MUST NOT be sent. 217 This document defines the behavior of implementations in the case 218 where BGPsec version zero is the only version that has been 219 successfully negotiated. Any future document which specifies 220 additional versions of BGPsec will need to specify behavior in the 221 case that support for multiple versions is negotiated. 223 BGPsec cannot provide meaningful security guarantees without support 224 for four-byte AS numbers. Therefore, any BGP speaker that announces 225 the BGPsec capability, MUST also announce the capability for four- 226 byte AS support [4]. If a BGP speaker sends the BGPsec capability but 227 not the four-byte AS support capability then BGPsec has not been 228 successfully negotiated, and update messages containing the 229 BGPsec_Path attribute MUST NOT be sent within such a session. 231 Note that BGPsec update messages can be quite large, therefore any 232 BGPsec speaker announcing the capability to receive BGPsec messages 233 SHOULD also announce support for the capability to receive BGP 234 extended messages [8]. 236 3. The BGPsec_Path Attribute 238 The BGPsec_Path attribute is a new optional non-transitive BGP path 239 attribute. 241 This document registers a new attribute type code for this attribute 242 : TBD 244 The BGPsec_Path attribute carries the secured information regarding 245 the path of ASes through which an update message passes. This 246 includes the digital signatures used to protect the path information. 247 We refer to those update messages that contain the BGPsec_Path 248 attribute as "BGPsec Update messages". The BGPsec_Path attribute 249 replaces the AS_PATH attribute in a BGPsec update message. That is, 250 update messages that contain the BGPsec_Path attribute MUST NOT 251 contain the AS_PATH attribute, and vice versa. 253 The BGPsec_Path attribute is made up of several parts. The following 254 high-level diagram provides an overview of the structure of the 255 BGPsec_Path attribute: 257 High-Level Diagram of the BGPsec_Path Attribute 258 +---------------------------------------------------------+ 259 | +-----------------+ | 260 | | Secure Path | | 261 | +-----------------+ | 262 | | AS X | | 263 | | pCount X | | 264 | | Flags X | | 265 | | AS Y | | 266 | | pCount Y | | 267 | | Flags Y | | 268 | | ... | | 269 | +-----------------+ | 270 | | 271 | +-----------------+ +-----------------+ | 272 | | Sig Block 1 | | Sig Block 2 | | 273 | +-----------------+ +-----------------+ | 274 | | Alg Suite 1 | | Alg Suite 2 | | 275 | | SKI X1 | | SKI X1 | | 276 | | Signature X1 | | Signature X1 | | 277 | | SKI Y1 | | SKI Y1 | | 278 | | Signature Y1 | | Signature Y1 | | 279 | | ... | | .... | | 280 | +-----------------+ +-----------------+ | 281 | | 282 +---------------------------------------------------------+ 284 The following is the specification of the format for the BGPsec_Path 285 attribute. 287 BGPsec_Path Attribute 289 +-------------------------------------------------------+ 290 | Secure_Path (variable) | 291 +-------------------------------------------------------+ 292 | Sequence of one or two Signature_Blocks (variable) | 293 +-------------------------------------------------------+ 295 The Secure_Path contains AS path information for the BGPsec update 296 message. This is logically equivalent to the information that is 297 contained in a non-BGPsec AS_PATH attribute. The information in 298 Secure_Path is used by BGPsec speakers in the same way that 299 information from the AS_PATH is used by non-BGPsec speakers. The 300 format of the Secure_Path is described below in Section 3.1. 302 The BGPsec_Path attribute will contain one or two Signature_Blocks, 303 each of which corresponds to a different algorithm suite. Each of 304 the Signature_Blocks will contain a signature segment for each AS 305 number (i.e., Secure_Path segment) in the Secure_Path. In the most 306 common case, the BGPsec_Path attribute will contain only a single 307 Signature_Block. However, in order to enable a transition from an 308 old algorithm suite to a new algorithm suite (without a flag day), it 309 will be necessary to include two Signature_Blocks (one for the old 310 algorithm suite and one for the new algorithm suite) during the 311 transition period. (See Section 6.1 for more discussion of algorithm 312 transitions.) The format of the Signature_Blocks is described below 313 in Section 3.2. 315 3.1. Secure_Path 317 Here we provide a detailed description of the Secure_Path information 318 in the BGPsec_Path attribute. 320 Secure_Path 322 +-----------------------------------------------+ 323 | Secure_Path Length (2 octets) | 324 +-----------------------------------------------+ 325 | One or More Secure_Path Segments (variable) | 326 +-----------------------------------------------+ 328 The Secure_Path Length contains the length (in octets) of the entire 329 Secure_Path (including the two octets used to express this length 330 field). As explained below, each Secure_Path segment is six octets 331 long. Note that this means the Secure_Path Length is two greater 332 than six times the number Secure_Path Segments (i.e., the number of 333 AS numbers in the path). 335 The Secure_Path contains one Secure_Path Segment for each (distinct) 336 Autonomous System in the path to the originating AS of the NLRI 337 specified in the update message. 339 Secure_Path Segment 341 +----------------------------+ 342 | AS Number (4 octets) | 343 +----------------------------+ 344 | pCount (1 octet) | 345 +----------------------------+ 346 | Flags (1 octet) | 347 +----------------------------+ 349 The AS Number is the AS number of the BGP speaker that added this 350 Secure_Path segment to the BGPsec_Path attribute. (See Section 4 for 351 more information on populating this field.) 353 The pCount field contains the number of repetitions of the associated 354 autonomous system number that the signature covers. This field 355 enables a BGPsec speaker to mimic the semantics of prepending 356 multiple copies of their AS to the AS_PATH without requiring the 357 speaker to generate multiple signatures. The pCount field is also 358 useful in managing route servers (see Section 4.2) and AS Number 359 migrations, see [18] for details. 361 The first bit of the Flags field is the Confed_Segment flag. The 362 Confed_Segment flag is set to one to indicate that the BGPsec speaker 363 that constructed this Secure_Path segment is sending the update 364 message to a peer AS within the same Autonomous System confederation 365 [5]. (That is, the Confed_Segment flag is set in a BGPsec update 366 message whenever, in a non-BGPsec update message, the BGP speaker's 367 AS would appear in a AS_PATH segment of type AS_CONFED_SEQUENCE.) In 368 all other cases the Confed_Segment flag is set to zero. 370 The remaining seven bits of the Flags MUST be set to zero by the 371 sender, and ignored by the receiver. Note, however, that the 372 signature is computed over all eight bits of the flags field. 374 3.2. Signature_Block 376 Here we provide a detailed description of the Signature_Blocks in the 377 BGPsec_Path attribute. 379 Signature_Block 381 +---------------------------------------------+ 382 | Signature_Block Length (2 octets) | 383 +---------------------------------------------+ 384 | Algorithm Suite Identifier (1 octet) | 385 +---------------------------------------------+ 386 | Sequence of Signature Segments (variable) | 387 +---------------------------------------------+ 389 The Signature_Block Length is the total number of octets in the 390 Signature_Block (including the two octets used to express this length 391 field). 393 The Algorithm Suite Identifier is a one-octet identifier specifying 394 the digest algorithm and digital signature algorithm used to produce 395 the digital signature in each Signature Segment. An IANA registry of 396 algorithm identifiers for use in BGPsec is specified in the BGPsec 397 algorithms document [10]. 399 A Signature_Block has exactly one Signature Segment for each 400 Secure_Path Segment in the Secure_Path portion of the BGPsec_Path 401 Attribute. (That is, one Signature Segment for each distinct AS on 402 the path for the NLRI in the Update message.) 404 Signature Segments 405 +---------------------------------------------+ 406 | Subject Key Identifier (20 octets) | 407 +---------------------------------------------+ 408 | Signature Length (2 octets) | 409 +---------------------------------------------+ 410 | Signature (variable) | 411 +---------------------------------------------+ 413 The Subject Key Identifier contains the value in the Subject Key 414 Identifier extension of the RPKI router certificate [9] that is used 415 to verify the signature (see Section 5 for details on validity of 416 BGPsec update messages). 418 The Signature Length field contains the size (in octets) of the value 419 in the Signature field of the Signature Segment. 421 The Signature contains a digital signature that protects the NLRI and 422 the BGPsec_Path attribute (see Sections 4 and 5 for details on 423 signature generation and validation, respectively). 425 4. Generating a BGPsec Update 427 Sections 4.1 and 4.2 cover two of the cases in which a BGPsec speaker 428 generates an update message containing the BGPsec_Path attribute. 429 The first case is that in which the BGPsec speaker originates a new 430 route advertisement (Section 4.1). That is, the BGPsec speaker is 431 constructing an update message in which the only AS to appear in the 432 BGPsec_Path is the speaker's own AS. The second case is that in 433 which the BGPsec speaker receives a route advertisement from a peer 434 and then decides to propagate the route advertisement to an external 435 (eBGP) peer (Section 4.2). That is, the BGPsec speaker has received 436 a BGPsec update message and is constructing a new update message for 437 the same NLRI in which the BGPsec_Path attribute will contain AS 438 number(s) other than the speaker's own AS. 440 The remaining case is where the BGPsec speaker sends the update 441 message to an internal (iBGP) peer. When originating a new route 442 advertisement and sending it to an internal peer, the BGPsec speaker 443 omits the BGPsec_Path attribute. When propagating a received route 444 advertisement to an internal peer, the BGPsec speaker typically 445 populates the BGPsec_Path attribute by copying the BGPsec_Path 446 attribute from the received update message. That is, the BGPsec_Path 447 attribute is copied verbatim. However, in the case that the BGPsec 448 speaker is performing an AS Migration, the BGPsec speaker may add an 449 additional signature on ingress before copying the BGPsec_Path 450 attribute (see [18] for more details). 452 Note that when a BGPsec speaker chooses to forward a BGPsec update 453 message to an iBGP peer, the BGPsec attribute SHOULD NOT be removed, 454 unless the peer doesn't support BGPsec. In particular, the BGPsec 455 attribute SHOULD NOT be removed even in the case where the BGPsec 456 update message has not been that has not successfully validated. (See 457 Section 5 for more information on validation, and Section 7 for the 458 security ramifications of removing BGPsec signatures.) 460 The information protected by the signature on a BGPsec update message 461 includes the AS number of the peer to whom the update message is 462 being sent. Therefore, if a BGPsec speaker wishes to send a BGPsec 463 update to multiple BGP peers, it MUST generate a separate BGPsec 464 update message for each unique peer AS to whom the update message is 465 sent. 467 A BGPsec update message MUST advertise a route to only a single NLRI. 468 This is because a BGPsec speaker receiving an update message with 469 multiple NLRI would be unable to construct a valid BGPsec update 470 message (i.e., valid path signatures) containing a subset of the NLRI 471 in the received update. If a BGPsec speaker wishes to advertise 472 routes to multiple NLRI, then it MUST generate a separate BGPsec 473 update message for each NLRI. Additionally, a BGPsec update message 474 MUST use the MP_REACH_NLRI [3] attribute to encode the NLRI. 476 In order to create or add a new signature to a BGPsec update message 477 with a given algorithm suite, the BGPsec speaker must possess a 478 private key suitable for generating signatures for this algorithm 479 suite. Additionally, this private key must correspond to the public 480 key in a valid Resource PKI end-entity certificate whose AS number 481 resource extension includes the BGPsec speaker's AS number [9]. Note 482 also that new signatures are only added to a BGPsec update message 483 when a BGPsec speaker is generating an update message to send to an 484 external peer (i.e., when the AS number of the peer is not equal to 485 the BGPsec speaker's own AS number). Therefore, a BGPsec speaker who 486 only sends BGPsec update messages to peers within its own AS, it does 487 not need to possess any private signature keys. 489 Section 4.3 contains special processing instructions for members of 490 an autonomous system confederation [5]. A BGPsec speaker that is not 491 a member of such a confederation MUST set the Flags field of the 492 Secure_Path Segment to zero in all BGPsec update messages it sends. 494 Section 4.4 contains instructions for reconstructing the AS_Path 495 attribute in cases where a BGPsec speaker receives an update message 496 with a BGPsec_Path attribute and wishes to propagate the update 497 message to a peer who does not support BGPsec. 499 4.1. Originating a New BGPsec Update 501 In an update message that originates a new route advertisement (i.e., 502 an update whose path will contain only a single AS number), when 503 sending the route advertisement to an external, BGPsec-speaking peer, 504 the BGPsec speaker creates a new BGPsec_Path attribute as follows. 506 First, the BGPsec speaker constructs the Secure_Path with a single 507 Secure_Path Segment. The AS in this path is the BGPsec speaker's own 508 AS number. In particular, this AS number MUST match an AS number in 509 the AS number resource extension field of the Resource PKI router 510 certificate(s) [9] that will be used to verify the digital 511 signature(s) constructed by this BGPsec speaker. 513 The BGPsec_Path attribute and the AS_Path attribute are mutually 514 exclusive. That is, any update message containing the BGPsec_Path 515 attribute MUST NOT contain the AS_Path attribute. The information 516 that would be contained in the AS_Path attribute is instead conveyed 517 in the Secure_Path portion of the BGPsec_Path attribute. 519 The Resource PKI enables the legitimate holder of IP address 520 prefix(es) to issue a signed object, called a Route Origination 521 Authorization (ROA), that authorizes a given AS to originate routes 522 to a given set of prefixes (see [7]). It is expected that most 523 relying parties will utilize BGPsec in tandem with origin validation 524 (see [19] and [20]). Therefore, it is RECOMMENDED that a BGPsec 525 speaker only originate a BGPsec update advertising a route for a 526 given prefix if there exists a valid ROA authorizing the BGPsec 527 speaker's AS to originate routes to this prefix. 529 The pCount field of the Secure_Path Segment is typically set to the 530 value 1. However, a BGPsec speaker may set the pCount field to a 531 value greater than 1. Setting the pCount field to a value greater 532 than one has the same semantics as repeating an AS number multiple 533 times in the AS_PATH of a non-BGPsec update message (e.g., for 534 traffic engineering purposes). Setting the pCount field to a value 535 greater than one permits this repetition without requiring a separate 536 digital signature for each repetition. 538 Typically, a BGPsec speaker will use only a single algorithm suite, 539 and thus create only a single Signature_Block in the BGPsec_Path 540 attribute. However, to ensure backwards compatibility during a 541 period of transition from a 'current' algorithm suite to a 'new' 542 algorithm suite, it will be necessary to originate update messages 543 that contain a Signature_Block for both the 'current' and the 'new' 544 algorithm suites (see Section 6.1). 546 When originating a new route advertisement, each Signature_Block MUST 547 consist of a single Signature Segment. The following describes how 548 the BGPsec speaker populates the fields of the Signature_Block. 550 The Subject Key Identifier field (see Section 3) is populated with 551 the identifier contained in the Subject Key Identifier extension of 552 the RPKI router certificate corresponding to the BGPsec speaker [9]. 553 This Subject Key Identifier will be used by recipients of the route 554 advertisement to identify the proper certificate to use in verifying 555 the signature. 557 The Signature field contains a digital signature that binds the NLRI 558 and BGPsec_Path attribute to the RPKI router certificate 559 corresponding to the BGPsec speaker. The digital signature is 560 computed as follows: 562 o Construct a sequence of octets by concatenating the Target AS 563 Number, the Secure_Path (Origin AS, pCount, and Flags), and the 564 Algorithm Suite Identifier. Then append to this sequence the 565 Address Family Identifier (AFI), Subsequent Address Family 566 Identifier (SAFI), and Network Layer Reachability Information 567 (NLRI) fields from the MP_REACH_NLRI attribute. Additionally, in 568 the Prefix field of the NLRI (from MP_REACH_NLRI), all of the 569 trailing bits MUST be set to zero when constructing this sequence. 570 In this sequence, the Target AS Number is the AS to whom the 571 BGPsec speaker intends to send the update message. (Note that the 572 Target AS number is the AS number announced by the peer in the 573 OPEN message of the BGP session within which the update is sent.) 574 Sequence of Octets to be Signed 575 +------------------------------------+ 576 | Target AS Number (4 octets) | 577 +------------------------------------+ 578 | Origin AS Number (4 octets) | ---\ 579 +------------------------------------+ \ 580 | pCount (1 octet) | > Secure_Path 581 +------------------------------------+ / 582 | Flags (1 octet) | ---/ 583 +------------------------------------+ 584 | Algorithm Suite Id. (1 octet) | 585 +------------------------------------+ 586 | AFI (2 octets) | ---\ 587 +------------------------------------+ \ 588 | SAFI (1 octet) | > MP_REACH_NLRI 589 +------------------------------------+ / 590 | NLRI (variable) | ---/ 591 +------------------------------------+ 593 o Apply to this octet sequence the digest algorithm (for the 594 algorithm suite of this Signature_Block) to obtain a digest value. 596 o Apply to this digest value the signature algorithm, (for the 597 algorithm suite of this Signature_Block) to obtain the digital 598 signature. Then populate the Signature Field with this digital 599 signature. 601 The Signature Length field is populated with the length (in octets) 602 of the Signature field. 604 4.2. Propagating a Route Advertisement 606 When a BGPsec speaker receives a BGPsec update message containing a 607 BGPsec_Path attribute (with one or more signatures) from an (internal 608 or external) peer, it may choose to propagate the route advertisement 609 by sending to its (internal or external) peers by creating a new 610 BGPsec advertisement for the same prefix. 612 If a BGPsec router has received only a non-BGPsec update message 613 (without the BGPsec_Path attribute), containing the AS_Path 614 attribute, from a peer for a given prefix then it MUST NOT attach a 615 BGPsec_Path attribute when it propagates the update message. (Note 616 that a BGPsec router may also receive a non-BGPsec update message 617 from an internal peer without the AS_Path attribute, i.e., with just 618 the NLRI in it. In that case, the prefix is originating from that AS 619 and hence the BGPsec speaker SHOULD sign and forward the update to 620 its external peers, as specified in Section 4.1.) 621 Conversely, if a BGPsec router has received a BGPsec update message 622 (with the BGPsec_Path attribute) from a peer for a given prefix and 623 it chooses to propagate that peer's route for the prefix, then it 624 SHOULD propagate the route as a BGPsec update message containing the 625 BGPsec_Path attribute. 627 Note that removing BGPsec signatures (i.e., propagating a route 628 advertisement without the BGPsec_Path attribute) has significant 629 security ramifications. (See Section 7 for discussion of the 630 security ramifications of removing BGPsec signatures.) Therefore, 631 when a route advertisement is received via a BGPsec update message, 632 propagating the route advertisement without the BGPsec_Path attribute 633 is NOT RECOMMENDED, unless the message is sent to a peer that did not 634 advertise the capability to receive BGPsec update messages (see 635 Section 4.4). 637 Furthermore, note that when a BGPsec speaker propagates a route 638 advertisement with the BGPsec_Path attribute it is not attesting to 639 the validation state of the update message it received. (See Section 640 7 for more discussion of the security semantics of BGPsec 641 signatures.) 643 If the BGPsec speaker is producing an update message which would, in 644 the absence of BGPsec, contain an AS_SET (e.g., the BGPsec speaker is 645 performing proxy aggregation), then the BGPsec speaker MUST NOT 646 include the BGPsec_Path attribute. In such a case, the BGPsec 647 speaker must remove any existing BGPsec_Path in the received 648 advertisement(s) for this prefix and produce a traditional (non- 649 BGPsec) update message. It should be noted that BCP 172 [13] 650 recommends against the use of AS_SET and AS_CONFED_SET in the AS_PATH 651 of BGP updates. 653 To generate the BGPsec_Path attribute on the outgoing update message, 654 the BGPsec speaker first prepends a new Secure_Path Segment (places 655 in first position) to the Secure_Path. The AS number in this 656 Secure_Path segment MUST match the AS number in the AS number 657 resource extension field of the Resource PKI router certificate(s) 658 that will be used to verify the digital signature(s) constructed by 659 this BGPsec speaker [9]. 661 The pCount is typically set to the value 1. A BGPsec speaker may set 662 the pCount field to a value greater than 1. (See Section 4.1 for a 663 discussion of setting pCount to a value greater than 1.) 665 A route server that participates in the BGP control path, but does 666 not act as a transit AS in the data plane, may choose to set pCount 667 to 0. This option enables the route server to participate in BGPsec 668 and obtain the associated security guarantees without increasing the 669 effective length of the AS path. (Note that BGPsec speakers compute 670 the effective length of the AS path by summing the pCount values in 671 the BGPsec_Path attribute, see Section 5.) However, when a route 672 server sets the pCount value to 0, it still inserts its AS number 673 into the Secure_Path segment, as this information is needed to 674 validate the signature added by the route server. (See [18] for a 675 discussion of setting pCount to 0 to facilitate AS Number Migration.) 676 BGPsec speakers SHOULD drop incoming update messages with pCount set 677 to zero in cases where the BGPsec speaker does not expect its peer to 678 set pCount to zero. (That is, pCount is only to be set to zero in 679 cases such as route servers or AS Number Migration where the BGPsec 680 speaker's peer expects pCount to be set to zero.) 682 If the received BGPsec update message contains two Signature_ Blocks 683 and the BGPsec speaker supports both of the corresponding algorithms 684 suites, then the new update message generated by the BGPsec speaker 685 SHOULD include both of the Signature_Blocks. If the received BGPsec 686 update message contains two Signature_Blocks and the BGPsec speaker 687 only supports one of the two corresponding algorithm suites, then the 688 BGPsec speaker MUST remove the Signature_Block corresponding to the 689 algorithm suite that it does not understand. If the BGPsec speaker 690 does not support the algorithm suites in any of the Signature_Blocks 691 contained in the received update message, then the BGPsec speaker 692 MUST NOT propagate the route advertisement with the BGPsec_Path 693 attribute. (That is, if it chooses to propagate this route 694 advertisement at all, it must do so as an unsigned BGP update 695 message). 697 Note that in the case where the BGPsec_Path has two Signature_Blocks 698 (corresponding to different algorithm suites), the validation 699 algorithm (see Section 5.2) deems a BGPsec update message to be 700 'Valid' if there is at least one supported algorithm suite (and 701 corresponding Signature_Block) that is deemed 'Valid'. This means 702 that a 'Valid' BGPsec update message may contain a Signature_Block 703 which is not deemed 'Valid' (e.g., contains signatures that the 704 BGPsec does not successfully verify). Nonetheless, such 705 Signature_Blocks MUST NOT be removed. (See Section 7 for a 706 discussion of the security ramifications of this design choice.) 708 For each Signature_Block corresponding to an algorithm suite that the 709 BGPsec speaker does support, the BGPsec speaker adds a new Signature 710 Segment to the Signature_Block. This Signature Segment is prepended 711 to the list of Signature Segments (placed in the first position) so 712 that the list of Signature Segments appear in the same order as the 713 corresponding Secure_Path segments. The BGPsec speaker populates the 714 fields of this new signature segment as follows. 716 The Subject Key Identifier field in the new segment is populated with 717 the identifier contained in the Subject Key Identifier extension of 718 the RPKI router certificate corresponding to the BGPsec speaker [9]. 720 This Subject Key Identifier will be used by recipients of the route 721 advertisement to identify the proper certificate to use in verifying 722 the signature. 724 The Signature field in the new segment contains a digital signature 725 that binds the NLRI and BGPsec_Path attribute to the RPKI router 726 certificate corresponding to the BGPsec speaker. The digital 727 signature is computed as follows: 729 o Construct a sequence of octets by concatenating the Target AS 730 number, the Secure_Path segment that is being added by the BGPsec 731 speaker constructing the signature, and the signature field of the 732 most recent Signature Segment (the one corresponding to AS from 733 whom the BGPsec speaker's AS received the announcement). Note 734 that the Target AS number is the AS number announced by the peer 735 in the OPEN message of the BGP session within which the BGPsec 736 update message is sent. 738 Sequence of Octets to be Signed 739 +--------------------------------------+ 740 | Target AS Number (4 octets) | 741 +--------------------------------------+ 742 | Signer's AS Number (4 octets) | ---\ 743 +--------------------------------------+ \ 744 | pCount (1 octet) | > Secure_Path 745 +--------- ----------------------------+ / 746 | Flags (1 octet) | ---/ 747 +--------------------------------------+ 748 | Most Recent Sig Field (variable) | 749 +--------------------------------------+ 751 o Apply to this octet sequence the digest algorithm (for the 752 algorithm suite of this Signature_Block) to obtain a digest value. 754 o Apply to this digest value the signature algorithm, (for the 755 algorithm suite of this Signature_Block) to obtain the digital 756 signature. Then populate the Signature Field with this digital 757 signature. 759 The Signature Length field is populated with the length (in octets) 760 of the Signature field. 762 4.3. Processing Instructions for Confederation Members 764 Members of autonomous system confederations [5] MUST additionally 765 follow the instructions in this section for processing BGPsec update 766 messages. 768 When a confederation member sends a BGPsec update message to a peer 769 that is a member of the same confederation, the confederation member 770 puts its (private) Member-AS Number (as opposed to the public AS 771 Confederation Identifier) in the AS Number field of the Secure_Path 772 Segment that it adds to the BGPsec update message. Furthermore, when 773 a confederation member sends a BGPsec update message to a peer that 774 is a member of the same confederation, the BGPsec speaker that 775 generates the Secure_Path Segment sets the Confed_Segment flag to 776 one. This means that in a BGPsec update message, an AS number 777 appears in a Secure_Path Segment with the Confed_Segment flag set 778 whenever, in a non-BGPsec update message, the AS number would appear 779 in a segment of type AS_CONFED_SEQUENCE in a non-BGPsec update 780 message. 782 Within a confederation, the verification of BGPsec signatures added 783 by other members of the confederation is optional. If a 784 confederation chooses not to have its members verify signatures added 785 by other confederation members, then when sending a BGPsec update 786 message to a peer that is a member of the same confederation, the 787 confederation members MAY set the Signature field within the 788 Signature_Segment that it generates to be zero (in lieu of 789 calculating the correct digital signature as described in Sections 790 4.1 and 4.2). Note that if a confederation chooses not to verify 791 digital signatures within the confederation, then BGPsec is able to 792 provide no assurances about the integrity of the (private) Member-AS 793 Numbers placed in Secure_Path segments where the Confed_Segment flag 794 is set to one. 796 When a confederation member receives a BGPsec update message from a 797 peer within the confederation and propagates it to a peer outside the 798 confederation, it needs to remove all of the Secure_Path Segments 799 added by confederation members as well as the corresponding Signature 800 Segments. To do this, the confederation member propagating the route 801 outside the confederation does the following: 803 o First, starting with the most recently added Secure_Path segment, 804 remove all of the consecutive Secure_Path segments that have the 805 Confed_Segment flag set to one. Stop this process once a 806 Scure_Path segment is reached which has its Confed_Segment flag 807 set to zero. Keep a count of the number of segments removed in 808 this fashion. 810 o Second, starting with the most recently added Signature Segment, 811 remove a number of Signature Segments equal to the number of 812 Secure_Path Segments removed in the previous step. (That is, 813 remove the K most recently added signature segments, where K is 814 the number of Secure_Path Segments removed in the previous step.) 816 o Finally, add a Secure_Path Segment containing, in the AS field, 817 the AS Confederation Identifier (the public AS number of the 818 confederation) as well as a corresponding Signature Segment. Note 819 that all fields other that the AS field are populated as per 820 Sections 4.1 and 4.2. 822 When validating a received BGPsec update message, confederation 823 members need to make the following adjustment to the algorithm 824 presented in Section 5.2. When a confederation member processes 825 (validates) a Signature Segment and its corresponding Secure_Path 826 Segment, the confederation member must note the following. For a 827 signature produced by a peer BGPsec speaker outside of a 828 confederation, the Target AS will always be the AS Confederation 829 Identifier (the public AS number of the confederation) as opposed to 830 the Member-AS Number. 832 To handle this case, when a BGPsec speaker (that is a confederation 833 member) processes a current Secure_Path Segment that has the 834 Confed_Segment flag set to zero, if the next most recently added 835 Secure_Path segment has the Confed_Segment flag set to one then, when 836 computing the digest for the current Secure_Path segment, the BGPsec 837 speaker takes the Target AS Number to be the AS Confederation 838 Identifier of the validating BGPsec speaker's own confederation. 839 (Note that the algorithm in Section 5.2 processes Secure_Path 840 Segments in order from most recently added to least recently added, 841 therefore this special case will apply to the first Secure_Path 842 segment that the algorithm encounters that has the Confed_Segment 843 flag set to zero.) 845 Finally, as discussed above, an AS confederation may optionally 846 decide that its members will not verify digital signatures added by 847 members. In such a federation, when a confederation member runs the 848 algorithm in Section 5.2, the confederation member, during processing 849 of a Signature_Segment, first checks whether the Confed_Sequence flag 850 in the corresponding Secure_Path segment is set to one. If the 851 Confed_Sequence flag is set to one in the corresponding Secure_Path 852 segment, the confederation member does not perform any further checks 853 on the Signature_Segment and immediately moves on to the next 854 Signature_Segment (and checks its corresponding Secure_Path segment). 855 Note that as specified in Section 5.2, it is an error when a BGPsec 856 speaker receives from a peer, who is not in the same AS 857 confederation, a BGPsec update containing a Confed_Sequence flag set 858 to one. (As discussed in Section 5.2, any error in the BGPsec_Path 859 attribute MUST be handled using the "treat-as-withdraw", approach as 860 defined in RFC WXYZ [11].) 862 4.4. Reconstructing the AS_PATH Attribute 864 BGPsec update messages do not contain the AS_PATH attribute. However, 865 the AS_PATH attribute can be reconstructed from the BGPsec_Path 866 attribute. This is necessary in the case where a route advertisement 867 is received via a BGPsec update message and then propagated to a peer 868 via a non-BGPsec update message (e.g., because the latter peer does 869 not support BGPsec). Note that there may be additional cases where an 870 implementation finds it useful to perform this reconstruction. 872 The AS_PATH attribute can be constructed from the BGPsec_Path 873 attribute as follows. Starting with an empty AS_PATH attribute, 874 process the Secure_Path segments in order from least-recently added 875 (corresponding to the origin) to most-recently added. For each 876 Secure_Path segment perform the following steps: 878 1. If the Confed_Segment flag in the Secure_Path segment is set to 879 one, then look at the most-recently added segment in the AS_PATH. 881 * In the case where the AS_PATH is empty or in the case where 882 the most-recently added segment is of type AS_SEQUENCE then 883 add (prepend to the AS_PATH) a new AS_PATH segment of type 884 AS_CONFED_SEQUENCE. This segment of type AS_CONFED_SEQUENCE 885 shall contain a number of elements equal to the pCount field 886 in the current Secure_Path segment. Each of these elements 887 shall be the AS number contained in the current Secure_Path 888 segment. (That is, if the pCount field is X, then the segment 889 of type AS_CONFED_SEQUENCE contains X copies of the 890 Secure_Path segment's AS Number field.) 892 * In the case where the most-recently added segment in the 893 AS_PATH is of type AS_CONFED_SEQUENCE then add (prepend to the 894 segment) a number of elements equal to the pCount field in the 895 current Secure_Path segment. The value of each of these 896 elements shall be the AS number contained in the current 897 Secure_Path segment. (That is, if the pCount field is X, then 898 add X copies of the Secure_Path segment's AS Number field to 899 the existing AS_CONFED_SEQUENCE.) 901 2. If the Confed_Segment flag in the Secure_Path segment is set to 902 zero, then look at the most-recently added segment in the 903 AS_PATH. 905 * In the case where the AS_PATH is empty, and the pCount field 906 in the Secure_Path segment is greater than zero, add (prepend 907 to the AS_PATH) a new AS_PATH segment of type AS_SEQUENCE. 908 This segment of type AS_SEQUENCE shall contain a number of 909 elements equal to the pCount field in the current Secure_Path 910 segment. Each of these elements shall be the AS number 911 contained in the current Secure_Path segment. (That is, if 912 the pCount field is X, then the segment of type AS_SEQUENCE 913 contains X copies of the Secure_Path segment's AS Number 914 field.) 916 * In the case where the most recently added segment in the 917 AS_PATH is of type AS_SEQUENCE then add (prepend to the 918 segment) a number of elements equal to the pCount field in the 919 current Secure_Path segment. The value of each of these 920 elements shall be the AS number contained in the current 921 Secure_Path segment. (That is, if the pCount field is X, then 922 add X copies of the Secure_Path segment's AS Number field to 923 the existing AS_SEQUENCE.) 925 5. Processing a Received BGPsec Update 927 Upon receiving a BGPsec update message from an external (eBGP) peer, 928 a BGPsec speaker SHOULD validate the message to determine the 929 authenticity of the path information contained in the BGPsec_Path 930 attribute. Typically, a BGPsec speaker will also wish to perform 931 origin validation (see [19] and [20]) on an incoming BGPsec update 932 message, but such validation is independent of the validation 933 described in this section. 935 Section 5.1 provides an overview of BGPsec validation and Section 5.2 936 provides a specific algorithm for performing such validation. (Note 937 that an implementation need not follow the specific algorithm in 938 Section 5.2 as long as the input/output behavior of the validation is 939 identical to that of the algorithm in Section 5.2.) During 940 exceptional conditions (e.g., the BGPsec speaker receives an 941 incredibly large number of update messages at once) a BGPsec speaker 942 MAY temporarily defer validation of incoming BGPsec update messages. 943 The treatment of such BGPsec update messages, whose validation has 944 been deferred, is a matter of local policy. However, an 945 implementation SHOULD ensure that deferment of validation and status 946 of deferred messages is visible to the operator. 948 The validity of BGPsec update messages is a function of the current 949 RPKI state. When a BGPsec speaker learns that RPKI state has changed 950 (e.g., from an RPKI validating cache via the RTR protocol), the 951 BGPsec speaker MUST re-run validation on all affected update messages 952 stored in its ADJ-RIB-IN. That is, when a given RPKI certificate 953 ceases to be valid (e.g., it expires or is revoked), all update 954 messages containing a signature whose SKI matches the SKI in the 955 given certificate must be re-assessed to determine if they are still 956 valid. If this reassessment determines that the validity state of an 957 update has changed then, depending on local policy, it may be 958 necessary to re-run best path selection. 960 BGPsec update messages do not contain an AS_PATH attribute. 961 Therefore, a BGPsec speaker MUST utilize the AS path information in 962 the BGPsec_Path attribute in all cases where it would otherwise use 963 the AS path information in the AS_PATH attribute. The only exception 964 to this rule is when AS path information must be updated in order to 965 propagate a route to a peer (in which case the BGPsec speaker follows 966 the instructions in Section 4). Section 4.4 provides an algorithm 967 for constructing an AS_PATH attribute from a BGPsec_Path attribute. 968 Whenever the use of AS path information is called for (e.g., loop 969 detection, or use of AS path length in best path selection) the 970 externally visible behavior of the implementation shall be the same 971 as if the implementation had run the algorithm in Section 4.4 and 972 used the resulting AS_PATH attribute as it would for a non-BGPsec 973 update message. 975 Many signature algorithms are non-deterministic. That is, many 976 signature algorithms will produce different signatures each time they 977 are run (even when they are signing the same data with the same key). 978 Therefore, if an implementation receives a BGPsec update from a peer 979 and later receives a second BGPsec update message from the same peer, 980 the implementation SHOULD treat the second message as a duplicate 981 update message if it differs from the first update message only in 982 the Signature fields (within the BGPsec_Path attribute). That is, if 983 all the fields in the second update are identical to the fields in 984 the first update message, except for the Signature fields, then the 985 second update message should be treated as a duplicate of the first 986 update message. Note that if other fields (e.g., the Subject Key 987 Identifier field) within a Signature segment differ between two 988 update messages then the two updates are not duplicates. 990 With regards to the processing of duplicate update messages, if the 991 first update message is valid, then an implementation SHOULD NOT run 992 the validation procedure on the second, duplicate update message 993 (even if the bits of the signature field are different). If the 994 first update message is not valid, then an implementation SHOULD run 995 the validation procedure on the second duplicate update message (as 996 the signatures in the second update may be valid even though the 997 first contained a signature that was invalid). 999 5.1. Overview of BGPsec Validation 1001 Validation of a BGPsec update messages makes use of data from RPKI 1002 certificates and signed Route Origination Authorizations (ROA). In 1003 particular, to validate update messages containing the BGPsec_Path 1004 attribute, it is necessary that the recipient have access to the 1005 following data obtained from valid RPKI certificates and ROAs: 1007 o For each valid RPKI router certificate, the AS Number, Public Key 1008 and Subject Key Identifier are required, 1010 o For each valid ROA, the AS Number and the list of IP address 1011 prefixes. 1013 Note that the BGPsec speaker could perform the validation of RPKI 1014 certificates and ROAs on its own and extract the required data, or it 1015 could receive the same data from a trusted cache that performs RPKI 1016 validation on behalf of (some set of) BGPsec speakers. (For example, 1017 the trusted cache could deliver the necessary validity information to 1018 the BGPsec speaker using the router key PDU [16] for the RTR protocol 1019 [15].) 1021 To validate a BGPsec update message containing the BGPsec_Path 1022 attribute, the recipient performs the validation steps specified in 1023 Section 5.2. The validation procedure results in one of two states: 1024 'Valid' and 'Not Valid'. 1026 It is expected that the output of the validation procedure will be 1027 used as an input to BGP route selection. That said, BGP route 1028 selection, and thus the handling of the validation states is a matter 1029 of local policy, and is handled using local policy mechanisms. 1030 Implementations SHOULD enable operators to set such local policy on a 1031 per-session basis. (That is, we expect some operators will choose to 1032 treat BGPSEC validation status differently for update messages 1033 received over different BGP sessions.) 1035 It is expected that BGP peers will generally prefer routes received 1036 via 'Valid' BGPsec update messages over both routes received via 'Not 1037 Valid' BGPsec update messages and routes received via update messages 1038 that do not contain the BGPsec_Path attribute. However, BGPsec 1039 specifies no changes to the BGP decision process. (See [17] for 1040 related operational considerations.) 1042 BGPsec validation needs only be performed at the eBGP edge. The 1043 validation status of a BGP signed/unsigned update MAY be conveyed via 1044 iBGP from an ingress edge router to an egress edge router via some 1045 mechanism, according to local policy within an AS. As discussed in 1046 Section 4, when a BGPsec speaker chooses to forward a (syntactically 1047 correct) BGPsec update message, it SHOULD be forwarded with its 1048 BGPsec_Path attribute intact (regardless of the validation state of 1049 the update message). Based entirely on local policy, an egress 1050 router receiving a BGPsec update message from within its own AS MAY 1051 choose to perform its own validation. 1053 5.2. Validation Algorithm 1055 This section specifies an algorithm for validation of BGPsec update 1056 messages. A conformant implementation MUST include a BGPsec update 1057 validation algorithm that is functionally equivalent to the 1058 externally visible behavior of this algorithm. 1060 First, the recipient of a BGPsec update message performs a check to 1061 ensure that the message is properly formed. Specifically, the 1062 recipient performs the following checks: 1064 1. Check to ensure that the entire BGPsec_Path attribute is 1065 syntactically correct (conforms to the specification in this 1066 document). 1068 2. Check that each Signature_Block contains one Signature segment 1069 for each Secure_Path segment in the Secure_Path portion of the 1070 BGPsec_Path attribute. (Note that the entirety of each 1071 Signature_Block must be checked to ensure that it is well formed, 1072 even though the validation process may terminate before all 1073 signatures are cryptographically verified.) 1075 3. Check that the update message does not contain an AS_PATH 1076 attribute. 1078 4. If the update message was received from a peer that is not a 1079 member of the BGPsec speaker's AS confederation, check to ensure 1080 that none of the Secure_Path segments contain a Flags field with 1081 the Confed_Sequence flag set to one. 1083 5. If the update message was received from a peer that is not 1084 expected to set pCount equal to zero (see Section 4.2) then check 1085 to ensure that the pCount field in the most-recently added 1086 Secure_Path segment is not equal to zero. 1088 If any of these checks fail, it is an error in the BGPsec_Path 1089 attribute. Any of these errors in the BGPsec_Path attribute are 1090 handled as per RFC WXYZ [11]. BGPsec speakers MUST handle these 1091 errors using the "treat-as-withdraw" approach as defined in RFC WXYZ 1092 [11]. 1094 Next, the BGPsec speaker examines the Signature_Blocks in the 1095 BGPsec_Path attribute. A Signature_Block corresponding to an 1096 algorithm suite that the BGPsec speaker does not support is not 1097 considered in validation. If there is no Signature_Block 1098 corresponding to an algorithm suite that the BGPsec speaker supports, 1099 then the BGPsec speaker MUST treat the update message in the same 1100 manner that the BGPsec speaker would treat an (unsigned) update 1101 message that arrived without a BGPsec_Path attribute. 1103 For each remaining Signature_Block (corresponding to an algorithm 1104 suite supported by the BGPsec speaker), the BGPsec speaker iterates 1105 through the Signature segments in the Signature_Block, starting with 1106 the most recently added segment (and concluding with the least 1107 recently added segment). Note that there is a one-to-one 1108 correspondence between Signature segments and Secure_Path segments 1109 within the BGPsec_Path attribute. The following steps make use of 1110 this correspondence. 1112 o (Step I): Locate the public key needed to verify the signature (in 1113 the current Signature segment). To do this, consult the valid 1114 RPKI router certificate data and look up all valid (AS, SKI, 1115 Public Key) triples in which the AS matches the AS number in the 1116 corresponding Secure_Path segment. Of these triples that match 1117 the AS number, check whether there is an SKI that matches the 1118 value in the Subject Key Identifier field of the Signature 1119 segment. If this check finds no such matching SKI value, then 1120 mark the entire Signature_Block as 'Not Valid' and proceed to the 1121 next Signature_Block. 1123 o (Step II): Compute the digest function (for the given algorithm 1124 suite) on the appropriate data. If the segment is not the (least 1125 recently added) segment corresponding to the origin AS, then the 1126 digest function should be computed on the following sequence of 1127 octets: 1129 Sequence of Octets to be Hashed 1131 +-------------------------------------------+ 1132 | AS Number of Target AS (4 octets) | 1133 +-------------------------------------------+ 1134 | AS Number (4 octets) | ---\ 1135 +-------------------------------------------+ \ 1136 | pCount (1 octet) | > Secure_Path 1137 +-------------------------------------------+ / 1138 | Flags (1 octet) | ---/ 1139 +-------------------------------------------+ 1140 | Sig Field in the Next Segment (variable) | 1141 +-------------------------------------------+ 1143 For the first segment to be processed (the most recently added 1144 segment), the 'AS Number of Target AS' is the AS number of the BGPsec 1145 speaker validating the update message. Note that if a BGPsec speaker 1146 uses multiple AS Numbers (e.g., the BGPsec speaker is a member of a 1147 confederation), the AS number used here MUST be the AS number 1148 announced in the OPEN message for the BGP session over which the 1149 BGPsec update was received. 1151 For each other Signature Segment, the 'AS Number of Target AS' is the 1152 AS number in the Secure_Path segment that corresponds to the 1153 Signature Segment added immediately after the one being processed. 1154 (That is, in the Secure_Path segment that corresponds to the 1155 Signature segment that the validator just finished processing.) 1157 The AS Number, pCount and Flags fields are taken from the Secure_Path 1158 segment that corresponds to the Signature segment currently being 1159 processed. The 'Signature Field in the Next Segment' is the 1160 Signature field found in the Signature segment that is next to be 1161 processed (that is, the next most recently added Signature Segment). 1163 Alternatively, if the segment being processed corresponds to the 1164 origin AS (i.e., if it is the least recently added segment), then the 1165 digest function should be computed on the following sequence of 1166 octets: 1168 Sequence of Octets to be Hashed 1169 +------------------------------------+ 1170 | AS Number of Target AS (4 octets) | 1171 +------------------------------------+ 1172 | Origin AS Number (4 octets) | ---\ 1173 +------------------------------------+ \ 1174 | pCount (1 octet) | > Secure_Path 1175 +------------------------------------+ / 1176 | Flags (1 octet) | ---/ 1177 +------------------------------------+ 1178 | Algorithm Suite Id. (1 octet) | 1179 +------------------------------------+ 1180 | AFI (2 octets) | ---\ 1181 +------------------------------------+ \ 1182 | SAFI (1 octet) | > MP_REACH_NLRI 1183 +------------------------------------+ / 1184 | NLRI (variable) | ---/ 1185 +------------------------------------+ 1187 The Address Family Identifier (AFI), Subsequent Address Family 1188 Identifier (SAFI), and Network Layer Reachability Information (NLRI) 1189 are obtained directly from the MP_REACH_NLRI attribute of the update 1190 message. However, in the Prefix field of the NLRI (from 1191 MP_REACH_NLRI), all of the trailing bits MUST be set to zero for the 1192 purpose of signature verification. The Algorithm Suite Identifier is 1193 obtained from the BGPsec_Path attribute being validated. The Origin 1194 AS Number, pCount, and Flags fields are taken from the Secure_Path 1195 segment corresponding to the Signature Segment currently being 1196 processed. 1198 The 'AS Number of Target AS' is the AS Number from the Secure_Path 1199 segment that was added immediately after the Secure_Path segment 1200 containing the Origin AS Number. (That is, the Secure_Path segment 1201 corresponding to the Signature segment that the receiver just 1202 finished processing prior to the current Signature segment.) 1204 o (Step III): Use the signature validation algorithm (for the given 1205 algorithm suite) to verify the signature in the current segment. 1206 That is, invoke the signature validation algorithm on the 1207 following three inputs: the value of the Signature field in the 1208 current segment; the digest value computed in Step II above; and 1209 the public key obtained from the valid RPKI data in Step I above. 1210 If the signature validation algorithm determines that the 1211 signature is invalid, then mark the entire Signature_Block as 'Not 1212 Valid' and proceed to the next Signature_Block. If the signature 1213 validation algorithm determines that the signature is valid, then 1214 continue processing Signature Segments (within the current 1215 Signature_Block). 1217 If all Signature Segments within a Signature_Block pass validation 1218 (i.e., all segments are processed and the Signature_Block has not yet 1219 been marked 'Not Valid'), then the Signature_Block is marked as 1220 'Valid'. 1222 If at least one Signature_Block is marked as 'Valid', then the 1223 validation algorithm terminates and the BGPsec update message is 1224 deemed to be 'Valid'. (That is, if a BGPsec update message contains 1225 two Signature_Blocks then the update message is deemed 'Valid' if the 1226 first Signature_Block is marked 'Valid' OR the second Signature_Block 1227 is marked 'Valid'.) 1229 6. Algorithms and Extensibility 1231 6.1. Algorithm Suite Considerations 1233 Note that there is currently no support for bilateral negotiation 1234 (using BGP capabilities) between BGPsec peers to use of a particular 1235 (digest and signature) algorithm suite. This is because the algorithm 1236 suite used by the sender of a BGPsec update message must be 1237 understood not only by the peer to whom he is directly sending the 1238 message, but also by all BGPsec speakers to whom the route 1239 advertisement is eventually propagated. Therefore, selection of an 1240 algorithm suite cannot be a local matter negotiated by BGP peers, but 1241 instead must be coordinated throughout the Internet. 1243 To this end, a mandatory algorithm suites document will be created 1244 which specifies a mandatory-to-use 'current' algorithm suite for use 1245 by all BGPsec speakers [10]. 1247 We anticipate that, in the future, the mandatory algorithm suites 1248 document will be updated to specify a transition from the 'current' 1249 algorithm suite to a 'new' algorithm suite. During the period of 1250 transition (likely a small number of years), all BGPsec update 1251 messages SHOULD simultaneously use both the 'current' algorithm suite 1252 and the 'new' algorithm suite. (Note that Sections 3 and 4 specify 1253 how the BGPsec_Path attribute can contain signatures, in parallel, 1254 for two algorithm suites.) Once the transition is complete, use of 1255 the old 'current' algorithm will be deprecated, use of the 'new' 1256 algorithm will be mandatory, and a subsequent 'even newer' algorithm 1257 suite may be specified as recommend to implement. Once the 1258 transition has successfully been completed in this manner, BGPsec 1259 speakers SHOULD include only a single Signature_Block (corresponding 1260 to the 'new' algorithm). 1262 6.2. Extensibility Considerations 1263 This section discusses potential changes to BGPsec that would require 1264 substantial changes to the processing of the BGPsec_Path and thus 1265 necessitate a new version of BGPsec. Examples of such changes 1266 include: 1268 o A new type of signature algorithm that produces signatures of 1269 variable length 1271 o A new type of signature algorithm for which the number of 1272 signatures in the Signature_Block is not equal to the number of 1273 ASes in the Secure_Path (e.g., aggregate signatures) 1275 o Changes to the data that is protected by the BGPsec signatures 1276 (e.g., attributes other than the AS path) 1278 In the case that such a change to BGPsec were deemed desirable, it is 1279 expected that a subsequent version of BGPsec would be created and 1280 that this version of BGPsec would specify a new BGP path attribute, 1281 let's call it BGPsec_PATH_TWO, which is designed to accommodate the 1282 desired changes to BGPsec. In such a case, the mandatory algorithm 1283 suites document would be updated to specify algorithm suites 1284 appropriate for the new version of BGPsec. 1286 At this point a transition would begin which is analogous to the 1287 algorithm transition discussed in Section 6.1. During the transition 1288 period all BGPsec speakers SHOULD simultaneously include both the 1289 BGPsec_Path attribute and the new BGPsec_PATH_TWO attribute. Once 1290 the transition is complete, the use of BGPsec_Path could then be 1291 deprecated, at which point BGPsec speakers SHOULD include only the 1292 new BGPsec_PATH_TWO attribute. Such a process could facilitate a 1293 transition to a new BGPsec semantics in a backwards compatible 1294 fashion. 1296 7. Security Considerations 1298 For a discussion of the BGPsec threat model and related security 1299 considerations, please see [14]. 1301 7.1 Security Guarantees 1303 When used in conjunction with Origin Validation (see [19] and [20]), 1304 a BGPsec speaker who receives a valid BGPsec update message, 1305 containing a route advertisement for a given prefix, is provided with 1306 the following security guarantees: 1308 o The origin AS number corresponds to an autonomous system that has 1309 been authorized, in the RPKI, by the IP address space holder to 1310 originate route advertisements for the given prefix. 1312 o For each AS in the path, a BGPsec speaker authorized by the holder 1313 of the AS number intentionally chose (in accordance with local 1314 policy) to propagate the route advertisement to the subsequent AS 1315 in the path. 1317 That is, the recipient of a valid BGPsec Update message is assured 1318 that the Secure_Path portion of the BGPsec_Path attribute corresponds 1319 to a sequence of autonomous systems who have all agreed in principle 1320 to forward packets to the given prefix along the indicated path. (It 1321 should be noted that BGPsec does not offer any guarantee that the 1322 data packets would flow along the indicated path; it only guarantees 1323 that the BGP update conveying the path indeed propagated along the 1324 indicated path.) Furthermore, the recipient is assured that this 1325 path terminates in an autonomous system that has been authorized by 1326 the IP address space holder as a legitimate destination for traffic 1327 to the given prefix. 1329 Note that although BGPsec provides a mechanism for an AS to validate 1330 that a received update message has certain security properties, the 1331 use of such a mechanism to influence route selection is completely a 1332 matter of local policy. Therefore, a BGPsec speaker can make no 1333 assumptions about the validity of a route received from an external 1334 BGPsec peer. That is, a compliant BGPsec peer may (depending on the 1335 local policy of the peer) send update messages that fail the validity 1336 test in Section 5. Thus, a BGPsec speaker MUST completely validate 1337 all BGPsec update messages received from external peers. (Validation 1338 of update messages received from internal peers is a matter of local 1339 policy, see Section 5). 1341 7.2 On the Removal of BGPsec Signatures 1343 There may be cases where a BGPsec speaker deems 'Valid' (as per the 1344 validation algorithm in Section 5.2) a BGPsec update message that 1345 contains both a 'Valid' and a 'Not Valid' Signature_Block. That is, 1346 the update message contains two sets of signatures corresponding to 1347 two algorithm suites, and one set of signatures verifies correctly 1348 and the other set of signatures fails to verify. In this case, the 1349 protocol specifies that a BGPsec speaker choosing to propagate the 1350 route advertisement in such an update message SHOULD add its 1351 signature to each of the Signature_Blocks. Thus the BGPsec speaker 1352 creates a signature using both algorithm suites and creates a new 1353 update message that contains both the 'Valid' and the 'Not Valid' set 1354 of signatures (from its own vantage point). 1356 To understand the reason for such a design decision consider the case 1357 where the BGPsec speaker receives an update message with both a set 1358 of algorithm A signatures which are 'Valid' and a set of algorithm B 1359 signatures which are 'Not Valid'. In such a case it is possible 1360 (perhaps even likely, depending on the state of the algorithm 1361 transition) that some of the BGPsec speaker's peers (or other 1362 entities further 'downstream' in the BGP topology) do not support 1363 algorithm A. Therefore, if the BGPsec speaker were to remove the 'Not 1364 Valid' set of signatures corresponding to algorithm B, such entities 1365 would treat the message as though it were unsigned. By including the 1366 'Not Valid' set of signatures when propagating a route advertisement, 1367 the BGPsec speaker ensures that 'downstream' entities have as much 1368 information as possible to make an informed opinion about the 1369 validation status of a BGPsec update. 1371 Note also that during a period of partial BGPsec deployment, a 1372 'downstream' entity might reasonably treat unsigned messages 1373 differently from BGPsec updates that contain a single set of 'Not 1374 Valid' signatures. That is, by removing the set of 'Not Valid' 1375 signatures the BGPsec speaker might actually cause a downstream 1376 entity to 'upgrade' the status of a route advertisement from 'Not 1377 Valid' to unsigned. Finally, note that in the above scenario, the 1378 BGPsec speaker might have deemed algorithm A signatures 'Valid' only 1379 because of some issue with RPKI state local to his AS (for example, 1380 his AS might not yet have obtained a CRL indicating that a key used 1381 to verify an algorithm A signature belongs to a newly revoked 1382 certificate). In such a case, it is highly desirable for a 1383 downstream entity to treat the update as 'Not Valid' (due to the 1384 revocation) and not as 'unsigned' (which would happen if the 'Not 1385 Valid' Signature_Blocks were removed). 1387 A similar argument applies to the case where a BGPsec speaker (for 1388 some reason such as lack of viable alternatives) selects as his best 1389 path (to a given prefix) a route obtained via a 'Not Valid' BGPsec 1390 update message. In such a case, the BGPsec speaker should propagate a 1391 signed BGPsec update message, adding his signature to the 'Not Valid' 1392 signatures that already exist. Again, this is to ensure that 1393 'downstream' entities are able to make an informed decision and not 1394 erroneously treat the route as unsigned. It should also be noted 1395 that due to possible differences in RPKI data observed at different 1396 vantage points in the network, a BGPsec update deemed 'Not Valid' at 1397 an upstream BGPsec speaker may be deemed 'Valid' by another BGP 1398 speaker downstream. 1400 Indeed, when a BGPsec speaker signs an outgoing update message, it is 1401 not attesting to a belief that all signatures prior to its are valid. 1402 Instead it is merely asserting that: 1404 o The BGPsec speaker received the given route advertisement with the 1405 indicated NLRI and Secure_Path; and 1407 o The BGPsec speaker chose to propagate an advertisement for this 1408 route to the peer (implicitly) indicated by the 'Target AS' 1410 7.3 Mitigation of Denial of Service Attacks 1412 The BGPsec update validation procedure is a potential target for 1413 denial of service attacks against a BGPsec speaker. Here we consider 1414 the mitigation only of denial of service attacks that are specific to 1415 BGPsec. 1417 To mitigate the effectiveness of such denial of service attacks, 1418 BGPsec speakers should implement an update validation algorithm that 1419 performs expensive checks (e.g., signature verification) after 1420 performing less expensive checks (e.g., syntax checks). The 1421 validation algorithm specified in Section 5.2 was chosen so as to 1422 perform checks which are likely to be expensive after checks that are 1423 likely to be inexpensive. However, the relative cost of performing 1424 required validation steps may vary between implementations, and thus 1425 the algorithm specified in Section 5.2 may not provide the best 1426 denial of service protection for all implementations. 1428 Additionally, sending update messages with very long AS paths (and 1429 hence a large number of signatures) is a potential mechanism to 1430 conduct denial of service attacks. For this reason, it is important 1431 that an implementation of the validation algorithm stops attempting 1432 to verify signatures as soon as an invalid signature is found. (This 1433 ensures that long sequences of invalid signatures cannot be used for 1434 denial of service attacks.) Furthermore, implementations can mitigate 1435 such attacks by only performing validation on update messages that, 1436 if valid, would be selected as the best path. That is, if an update 1437 message contains a route that would lose out in best path selection 1438 for other reasons (e.g., a very long AS path) then it is not 1439 necessary to determine the BGPsec-validity status of the route. 1441 7.4 Additional Security Considerations 1443 The mechanism of setting the pCount field to zero is included in this 1444 specification to enable route servers in the control path to 1445 participate in BGPsec without increasing the effective length of the 1446 AS-PATH. However, entities other than route servers could 1447 conceivably use this mechanism (set the pCount to zero) to attract 1448 traffic (by reducing the effective length of the AS-PATH) 1449 illegitimately. This risk is largely mitigated if every BGPsec 1450 speaker drops incoming update messages that set pCount to zero but 1451 come from a peer that is not a route server. However, note that a 1452 recipient of a BGPsec update message within which an upstream entity 1453 two or more hops away has set pCount to zero is unable to verify for 1454 themselves whether pCount was set to zero legitimately. 1456 BGPsec does not provide protection against attacks at the transport 1457 layer. As with any BGP session, an adversary on the path between a 1458 BGPsec speaker and its peer is able to perform attacks such as 1459 modifying valid BGPsec updates to cause them to fail validation, 1460 injecting (unsigned) BGP update messages without 1461 BGPsec_Path_Signature attributes, injecting BGPsec update messages 1462 with BGPsec_Path_Signature attributes that fail validation, or 1463 causing the peer to tear-down the BGP session. The use of BGPsec does 1464 nothing to increase the power of an on-path adversary -- in 1465 particular, even an on-path adversary cannot cause a BGPsec speaker 1466 to believe a BGPsec-invalid route is valid. However, as with any BGP 1467 session, BGPsec sessions SHOULD be protected by appropriate transport 1468 security mechanisms. 1470 One might be concerned about a potential attack in which an adversary 1471 replays a valid signature on an origin Secure_Path segment as though 1472 it were a signature on later Secure_Path segment (in a different 1473 update message). The only way such an attack could succeed would be 1474 if a structure of bits to be signed in Section 4.1 (origin segment) 1475 could also be parsed as a valid sequence of bits to be signed in 1476 Section 4.2 (later segment). This, in particular, would require that 1477 the length of the two structures match exactly, which cannot happen 1478 given the current choice of algorithms in [10]. We do not expect this 1479 to be a problem with future signature algorithms, as it is likely 1480 that signatures will get longer (instead of shorter) over time. 1481 However, authors of future revisions of the algorithms document [10] 1482 should take care to ensure that this attack remains infeasible. 1484 8. IANA Considerations 1486 This document registers a new capability in the registry of BGP 1487 Capabilities. The description for the new capability is "BGPsec 1488 Capability". The reference for the new capability is this document 1489 (i.e., the RFC that replaces draft-ietf-sidr-bgpsec-protocol). 1491 This document registers a new path attribute in the registry of BGP 1492 Path Attributes. The code for this new attribute is "BGPsec_PATH". 1493 The reference for the new capability is this document (i.e., the RFC 1494 that replaces draft-ietf-sidr-bgpsec-protocol). 1496 This document does not create any new IANA registries. 1498 9. Contributors 1500 9.1. Authors 1502 Rob Austein 1503 Dragon Research Labs 1504 sra@hactrn.net 1506 Steven Bellovin 1507 Columbia University 1508 smb@cs.columbia.edu 1510 Randy Bush 1511 Internet Initiative Japan 1512 randy@psg.com 1514 Russ Housley 1515 Vigil Security 1516 housley@vigilsec.com 1518 Matt Lepinski 1519 New College of Florida 1520 mlepinski.ietf@gmail.com 1522 Stephen Kent 1523 BBN Technologies 1524 kent@bbn.com 1526 Warren Kumari 1527 Google 1528 warren@kumari.net 1530 Doug Montgomery 1531 USA National Institute of Standards and Technology 1532 dougm@nist.gov 1534 Kotikalapudi Sriram 1535 USA National Institute of Standards and Technology 1536 kotikalapudi.sriram@nist.gov 1538 Samuel Weiler 1539 Parsons 1540 weiler+ietf@watson.org 1542 9.2. Acknowledgements 1544 The authors would like to thank Michael Baer, Luke Berndt, Sharon 1545 Goldberg, Ed Kern, Chris Morrow, Doug Maughan, Pradosh Mohapatra, 1546 Russ Mundy, Sandy Murphy, Keyur Patel, Mark Reynolds, Heather 1547 Schiller, Jason Schiller, John Scudder, Ruediger Volk and David Ward 1548 for their valuable input and review. 1550 10. Normative References 1552 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1553 Levels", BCP 14, RFC 2119, March 1997. 1555 [2] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 1556 Gateway Protocol 4", RFC 4271, January 2006. 1558 [3] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1559 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 1561 [4] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number 1562 Space", RFC 6793, December 2012. 1564 [5] Traina, P., McPherson, D., and J. Scudder, "Autonomous System 1565 Confederations for BGP", RFC 5065, August 2007. 1567 [6] Scudder, J. and R. Chandra, "Capabilities Advertisement with 1568 BGP-4", RFC 5492, February 2009. 1570 [7] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1571 Origin Authorizations (ROAs)", RFC 6482, February 2012. 1573 [8] Patel, K., Ward, D., and R. Bush, "Extended Message support for 1574 BGP", draft-ietf-idr-bgp-extended-messages (work in progress), 1575 January 2015. 1577 [9] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec 1578 Router Certificates, Certificate Revocation Lists, and 1579 Certification Requests", draft-ietf-sidr-bgpsec-pki-profiles 1580 (work in progress), November 2014. 1582 [10] Turner, S., "BGP Algorithms, Key Formats, & Signature Formats", 1583 draft-ietf-sidr-bgpsec-algs (work in progress), July 2014. 1585 [11] Scudder, J., Chen, E., Mohapatra, P., and K. Patel, "Revised 1586 Error Handling for BGP UPDATE Messages", draft-ietf-idr-error- 1587 handling (work in progress), December 2014. 1589 11. Informative References 1591 [12] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure 1592 Internet Routing", RFC 6480, February 2012. 1594 [13] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET 1595 and AS_CONFED_SET in BGP", RFC 6472, December 2011. 1597 [14] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 1598 7132, February 2014. 1600 [15] Bush, R. and R. Austein, "The Resource Public Key 1601 Infrastructure (RPKI) to Router Protocol", RFC 6810, January 1602 2013. 1604 [16] Bush, R., Patel, K., and S. Turner, "Router Key PDU for RPKI- 1605 Router Protocol", draft-ymbk-rpki-rtr-keys (work in progress), 1606 April 2013. 1608 [17] Bush, R., "BGPsec Operational Considerations", draft-ietf-sidr- 1609 bgpsec-ops (work in progress), May 2012. 1611 [18] George, W. and S. Murphy, "BGPsec Considerations for AS 1612 Migration", draft-ietf-sidr-as-migration (work in progress), 1613 July 2014. 1615 [19] Huston, G. and G. Michaelson, "Validation of Route Origination 1616 Using the Resource Certificate Public Key Infrastructure (PKI) 1617 and Route Origin Authorizations (ROAs)", RFC 6483, February 1618 2013. 1620 [20] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, 1621 "BGP Prefix Origin Validation", RFC 6811, January 2013. 1623 Author's Address 1625 Matthew Lepinski (editor) 1626 BBN Technologies 1627 10 Moulton St 1628 Cambridge, MA 55409 1629 US 1631 Phone: +1 617 873 5939 1632 Email: mlepinski.ietf@gmail.com