idnits 2.17.1 draft-ietf-sidr-bgpsec-protocol-05.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (September 7, 2012) is 4248 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 1592, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6480 (ref. '6') == Outdated reference: A later version (-09) exists of draft-ietf-sidr-bgpsec-threats-02 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-bgpsec-threats (ref. '10') == Outdated reference: A later version (-21) exists of draft-ietf-sidr-bgpsec-pki-profiles-03 == Outdated reference: A later version (-18) exists of draft-ietf-sidr-bgpsec-algs-02 -- No information found for draft-ietf-sidr-rtr - is the name correct? -- Possible downref: Normative reference to a draft: ref. '13' Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Lepinski, Ed. 3 Internet-Draft BBN 4 Intended status: Standards Track September 7, 2012 5 Expires: March 11, 2013 7 BGPSEC Protocol Specification 8 draft-ietf-sidr-bgpsec-protocol-05 10 Abstract 12 This document describes BGPSEC, an extension to the Border Gateway 13 Protocol (BGP) that provides security for the AS-PATH attribute in 14 BGP update messages. BGPSEC is implemented via a new optional non- 15 transitive BGP path attribute that carries a digital signature 16 produced by each autonomous system on the AS-PATH. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [8]. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 11, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. BGPSEC Negotiation . . . . . . . . . . . . . . . . . . . . . . 3 60 3. The BGPSEC_Path_Signatures Attribute . . . . . . . . . . . . . 6 61 3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.2. Additional_Info . . . . . . . . . . . . . . . . . . . . . 10 63 3.3. Signature_Block . . . . . . . . . . . . . . . . . . . . . 11 64 4. Generating a BGPSEC Update . . . . . . . . . . . . . . . . . . 12 65 4.1. Originating a New BGPSEC Update . . . . . . . . . . . . . 13 66 4.2. Propagating a Route Advertisement . . . . . . . . . . . . 16 67 4.3. Processing Instructions for Confederation Members . . . . 20 68 4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . . 22 69 5. Processing a Received BGPSEC Update . . . . . . . . . . . . . 23 70 5.1. Overview of BGPSEC Validation . . . . . . . . . . . . . . 25 71 5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . . 26 72 6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 30 73 6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 30 74 6.2. Extensibility Considerations . . . . . . . . . . . . . . . 31 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 76 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35 77 8.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 35 78 8.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 36 79 9. Normative References . . . . . . . . . . . . . . . . . . . . . 36 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 82 1. Introduction 84 This document describes BGPSEC, a mechanism for providing path 85 security for Border Gateway Protocol (BGP) [1] route advertisements. 86 That is, a BGP speaker who receives a valid BGPSEC update has 87 cryptographic assurance that the advertised route has the following 88 two properties: 90 1. The route was originated by an AS that has been explicitly 91 authorized by the holder of the IP address prefix to originate 92 route advertisements for that prefix. 94 2. Every AS listed in the AS_Path attribute of the update explicitly 95 authorized the advertisement of the route to the subsequent AS in 96 the AS_Path. 98 This document specifies a new optional (non-transitive) BGP path 99 attribute, BGPSEC_Path_Signatures. It also describes how a BGPSEC- 100 compliant BGP speaker (referred to hereafter as a BGPSEC speaker) can 101 generate, propagate, and validate BGP update messages containing this 102 attribute to obtain the above assurances. 104 BGPSEC relies on the Resource Public Key Infrastructure (RPKI) 105 certificates that attest to the allocation of AS number and IP 106 address resources. (For more information on the RPKI, see [6] and 107 the documents referenced therein.) Any BGPSEC speaker who wishes to 108 send BGP update messages to external peers (eBGP) containing the 109 BGPSEC_Path_Signatures must have an RPKI end-entity certificate (as 110 well as the associated private signing key) corresponding to the 111 BGPSEC speaker's AS number. Note, however, that a BGPSEC speaker 112 does not require such a certificate in order to validate update 113 messages containing the BGPSEC_Path_Signatures attribute. 115 2. BGPSEC Negotiation 117 This document defines a new BGP capability [4]that allows a BGP 118 speaker to advertise to its neighbors the ability to send and/or 119 receive BGPSEC update messages (i.e., update messages containing the 120 BGPSEC_Path_Signatures attribute). 122 This capability has capability code : TBD 124 The capability length for this capability MUST be set to 5. 126 The three octets of the capability value are specified as follows. 128 Capability Value: 130 0 1 2 3 4 5 6 7 131 +---------------------------------------+ 132 | Send | Receive | Reserved | Version | 133 +---------------------------------------+ 134 | AFI | 135 +---------------------------------------+ 136 | | 137 +---------------------------------------+ 138 | Reserved | 139 +---------------------------------------+ 140 | SAFI | 141 +---------------------------------------+ 143 The high order bit (bit 0) of the first octet is set to 1 to indicate 144 that the sender is able to send BGPSEC update messages, and is set to 145 zero otherwise. The next highest order bit (bit 1) of this octet is 146 set to 1 to indicate that the sender is able to receive BGPSEC update 147 messages, and is set to zero otherwise. The next two bits of the 148 capability value (bits 2 and 3) are reserved for future use. These 149 reserved bits should be set to zero by the sender and ignored by the 150 receiver. 152 The four low order bits (4, 5, 6 and 7) of the first octet indicate 153 the version of BGPSEC for which the BGP speaker is advertising 154 support. This document defines only BGPSEC version 0 (all four bits 155 set to zero). Other versions of BGPSEC may be defined in future 156 documents. A BGPSEC speaker MAY advertise support for multiple 157 versions of BGPSEC by including multiple versions of the BGPSEC 158 capability in its BGP OPEN message. 160 If there does not exist at least one version of BGPSEC that is 161 supported by both peers in a BGP session, then the use of BGPSEC has 162 not been negotiated. (That is, in such a case, messages containing 163 the BGPSEC_Path_Signatures MUST NOT be sent.) 165 If version 0 is the only version of BGPSEC for which both peers (in a 166 BGP session) advertise support, then the use of BGPSEC has been 167 negotiated and the BGPSEC peers MUST adhere to the specification of 168 BGPSEC provided in this document. (If there are multiple versions of 169 BGPSEC which are supported by both peers, then the behavior of those 170 peers is outside the scope of this document.) 172 The second and third octets contain the 16-bit Address Family 173 Identifier (AFI) which indicates the address family for which the 174 BGPSEC speaker is advertising support for BGPSEC. This document only 175 specifies BGPSEC for use with two address families, IPv4 and IPv6, 176 AFI values 1 and 2 respectively. BGPSEC for use with other address 177 families may be specified in future documents. 179 The fourth octet in the capability is reserved. It is anticipated 180 that this octet will not be used until such a time as the reserved 181 octet in the Multi-protocol extensions capability advertisement [2] 182 is specified for use. The reserved octet should be set to zero by 183 the sender and ignored by the receiver. 185 The fifth octet in the capability contains the 8-bit Subsequent 186 Address Family Identifier (SAFI). This value is encoded as in the 187 BGP multiprotocol extensions [2]. 189 Note that if the BGPSEC speaker wishes to use BGPSEC with two 190 different address families (i.e., IPv4 and IPv6) over the same BGP 191 session, then the speaker must include two instances of this 192 capability (one for each address family) in the BGP OPEN message. A 193 BGPSEC speaker SHOULD NOT advertise the capability of BGPSEC support 194 for any combination unless it has also advertises the 195 multiprotocol extension capability for the same 196 combination [2]. 198 By indicating support for receiving BGPSEC update messages, a BGP 199 speaker is, in particular, indicating that the following are true: 201 o The BGP speaker understands the BGPSEC_Path_Signatures attribute 202 (see Section 3). 204 o The BGP speaker supports 4-byte AS numbers (see RFC 4893). 206 Note that BGPSEC update messages can be quite large, therefore any 207 BGPSEC speaker announcing the capability to receive BGPSEC messages 208 SHOULD also announce support for the capability to receive BGP 209 extended messages [9]. 211 A BGP speaker MUST NOT send an update message containing the 212 BGPSEC_Path_Signatures attribute within a given BGP session unless 213 both of the following are true: 215 o The BGP speaker indicated support for sending BGPSEC update 216 messages in its open message. 218 o The peer of the BGP speaker indicated support for receiving BGPSEC 219 update messages in its open message. 221 3. The BGPSEC_Path_Signatures Attribute 223 The BGPSEC_Path_Signatures attribute is a new optional (non- 224 transitive) BGP path attribute. 226 This document registers a new attribute type code for this attribute 227 : TBD 229 The BGPSEC_Path_Signatures algorithm carries the secured AS Path 230 information, including the digital signatures that protect this AS 231 Path information. We refer to those update messages that contain the 232 BGPSEC_Path_Signatures attribute as "BGPSEC Update messages". The 233 BGPSEC_Path_Signatures attribute replaces the AS_PATH attribute, in a 234 BGPSEC update message. That is, update messages that contain the 235 BGPSEC_Path_Signatures attribute MUST NOT contain the AS_PATH 236 attribute. 238 The BGPSEC_Path_Signatures attribute is made up of several parts. 239 The following high-level diagram provides an overview of the 240 structure of the BGPSEC_Path_Signatures attribute: 242 High-Level Diagram of the BGPSEC_Path_Signatures Attribute 243 BGPSEC_Path_Signatures 244 +---------------------------------------------------------+ 245 | +-----------------+ | 246 | | Secure Path | +-----------------+ | 247 | +-----------------+ | Additional Info | | 248 | | AS X | +-----------------+ | 249 | | pCount X | | Info Type | | 250 | | Flags X | | Info Length | | 251 | | AS Y | | Info Value | | 252 | | pCount Y | +-----------------+ | 253 | | Flags Y | | 254 | | ... | | 255 | +-----------------+ | 256 | | 257 | +-----------------+ +-----------------+ | 258 | | Sig Block 1 | | Sig Block 2 | | 259 | +-----------------+ +-----------------+ | 260 | | Alg Suite 1 | | Alg Suite 2 | | 261 | | SKI X | | SKI X | | 262 | | Sig Length X | | Sig Length X | | 263 | | Signature X | | Signature X | | 264 | | SKI Length Y | | SKI Length Y | | 265 | | SKI Y | | SKI Y | | 266 | | Sig Length Y | | Sig Length Y | | 267 | | Signature Y | | Signature Y | | 268 | | ... | | .... | | 269 | +-----------------+ +-----------------+ | 270 | | 271 +---------------------------------------------------------+ 273 The following is a more detailed explanation of the format of the 274 BGPSEC_Path_Signatures attribute. 276 BGPSEC_Path_Signatures Attribute 278 +-------------------------------------------------------+ 279 | Secure_Path (variable) | 280 +-------------------------------------------------------+ 281 | Additional_Info (variable) | 282 +-------------------------------------------------------+ 283 | Sequence of one or two Signature_Blocks (variable) | 284 +-------------------------------------------------------+ 286 The Secure_Path contains AS Path information for the BGPSEC update 287 message. This is logically equivalent to the information that would 288 be contained in the AS_PATH attribute. A BGPSEC update message 289 containing the BGPSEC_PATH_SIGNATURES attribute MUST NOT contain the 290 AS_PATH attribute. The path information is used by BGPSEC speakers 291 in the same way that information from the AS_PATH is used by non- 292 BGPSEC speakers. The format of the Secure_Path is described below in 293 Section 3.1. 295 The Additional_Info contains additional signed information about the 296 update message. Additional_Info is specified as a type-length-value 297 field for future extensibility. However, this specification defines 298 only a single (null) type of Additional Info which has zero length. 299 It is anticipated that future specifications may specify semantics 300 for Info Types other than zero. See Section 3.2 below for more 301 detail. 303 The BGPSEC_Path_Signatures attribute will contain one or two 304 Signature_Blocks, each of which corresponds to a different algorithm 305 suite. Each of the Signature_Blocks will contain a signature segment 306 for each AS number (i.e, secure path segment) in the Secure_Path. In 307 the most common case, the BGPSEC_Path_Signatures attribute will 308 contain only a single Signature_Block. However, in order to enable a 309 transition from an old algorithm suite to a new algorithm suite, 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.3. 316 3.1. Secure_Path 318 Here we provide a detailed description of the Secure_Path information 319 in the BGPSEC_Path_Signatures 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 330 variable-length sequence of Secure_Path Segments. As explained 331 below, each Secure_Path segment is six octets long. Note that this 332 means the Secure_Path Length is six times the number Secure_Path 333 Segments (i.e., the number of 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 NLRI specified in the update 337 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_Signatures attribute. (See 351 Section 4 for 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 adding multiple 356 copies of their AS to the AS_PATH without requiring the speaker to 357 generate multiple signatures. 359 The first bit of the Flags field is the Confed_Segment flag. The 360 Confed_Segment flag is set to one to indicate that the BGPSEC speaker 361 that constructed this Secure_Path segment is sending the update 362 message to a peer AS within the same Autonomous System confederation 363 [3]. (That is, the Confed_Segment flag is set in a BGPSEC update 364 message whenever in a non-BGPSEC update message the BGP speaker's AS 365 would appear in a AS_PATH segment of type AS_CONFED_SEQUENCE.) In 366 all other cases the Confed_Segment flag is set to zero. 368 The remaining seven bits of the Flags field are reserved for future 369 use. These bits MUST be set to zero by the sender. The receiver 370 uses the entire Flags octet to verify the digital signature 371 (regardless of what value the reserved bits contain), but otherwise 372 ignores the reserved flags (see Section 4 for sender instructions and 373 Section 5 for receiver validation instructions). 375 EDITOR'S NOTE: The unused portion of the signed flags field provides 376 the possibility of adding in the future (in a backwards compatible 377 fashion) a new feature that requires some per-AS signed bits. For 378 example, one could use a couple bits from this flag field to mark 379 some other property (besides being in the same confederation) of the 380 connection between two peer ASes. 382 3.2. Additional_Info 384 Here we provide a detailed description of the Additional_Info in the 385 BGPSEC_Path_Signatures attribute. 387 Additional_Info 389 +---------------------------------------------+ 390 | Info Type (1 octet) | 391 +---------------------------------------------+ 392 | Info Length (1 octet) | 393 +---------------------------------------------+ 394 | Info Value (variable) | 395 +---------------------------------------------+ 397 The Info Type field is a one-octet value that identifies the type of 398 additional information included in the Info Value field. This 399 specification defines a single (null) type of Additional_Info. The 400 Info Type for this null type is zero. 402 The Info Length field contains the length in octets of the Info Value 403 field. For the (null) Info Type zero specified in this document, the 404 Info Length MUST be zero. 406 The syntax and semantics contained in the Info Value field depends on 407 the type contained in the Info Type field. For the (null) Info Type 408 zero specified in this document, the Info Value field is empty (since 409 the Info Length field must be zero). 411 Implementations compliant with this specification MUST set the Info 412 Type to zero in BGPSEC update messages for route advertisements that 413 they originate (see Section 4.1 for more details). When an 414 implementation compliant with this specification receives a BGPSEC 415 update message with an Info Type field that it does not understand 416 (i.e., an Info Type other than zero), the implementation MUST use the 417 Additional_Info when it verifies digital signatures (as per Section 418 5.2). However, other than signature verification, the implementation 419 MUST ignore the Info Value field when it does not understand the Info 420 Type. 422 EDITOR'S NOTE: In a previous version of this document there was an 423 Expire Time that was used to provide protection against replay of old 424 (stale) digital signatures or failure to propagate a withdrawal 425 message. This mechanism was removed from the current version of the 426 document. Please see the SIDR mailing list for discussions related 427 to protection against replay attacks. Depending on the result of 428 discussions within the SIDR working group this Additional Info field 429 could at some future point be used to re-introduce Expire Time, or 430 some other octets used in a future replay protection mechanism. The 431 authors believe that the current instructions whereby the sender uses 432 a null Additional_Info type and the receiver ignores Additional_Info 433 types that it does not understand provides an opportunity to use 434 these octets in the future in a backwards-compatible fashion. 436 3.3. Signature_Block 438 Here we provide a detailed description of the Signature_Blocks in the 439 BGPSEC_Path_Signatures attribute. 441 Signature_Block 443 +---------------------------------------------+ 444 | Algorithm Suite Identifier (1 octet) | 445 +---------------------------------------------+ 446 | Signature_Block Length (2 octets) | 447 +---------------------------------------------+ 448 | Sequence of Signature Segments (variable) | 449 +---------------------------------------------+ 451 The Algorithm Suite Identifier is a one-octet identifier specifying 452 the digest algorithm and digital signature algorithm used to produce 453 the digital signature in each Signature Segment. An IANA registry of 454 algorithm identifiers for use in BGPSEC is created in the BGPSEC 455 algorithms document[12]. 457 The Signature_Block Length is the total number of octets in all 458 Signature Segments (i.e., the total size of the variable-length 459 portion of the Signature_Block.) 461 A Signature_Block has exactly one Signature Segment for each 462 Secure_Path Segment in the Secure_Path portion of the 463 BGPSEC_Path_Signatures Attribute. (That is, one Signature Segment 464 for each distinct AS on the path for the NLRI in the Update message.) 465 Signature Segments 466 +---------------------------------------------+ 467 | Subject Key Identifier (20 octets) | 468 +---------------------------------------------+ 469 | Signature Length (2 octets) | 470 +---------------------------------------------+ 471 | Signature (variable) | 472 +---------------------------------------------+ 474 The Subject Key Identifier contains the value in the Subject Key 475 Identifier extension of the RPKI end-entity certificate that is used 476 to verify the signature (see Section 5 for details on validity of 477 BGPSEC update messages). 479 The Signature Length field contains the size (in octets) of the value 480 in the Signature field of the Signature Segment. 482 The Signature contains a digital signature that protects the NLRI and 483 the BGPSEC_Path_Signatures attribute (see Sections 4 and 5 for 484 details on generating and verifying this signature, respectively). 486 4. Generating a BGPSEC Update 488 Sections 4.1 and 4.2 cover two cases in which a BGPSEC speaker may 489 generate an update message containing the BGPSEC_Path_Signatures 490 attribute. The first case is that in which the BGPSEC speaker 491 originates a new route advertisement (Section 4.1). That is, the 492 BGPSEC speaker is constructing an update message in which the only AS 493 to appear in the BGPSEC_Path_Signatures is the speaker's own AS. The 494 second case is that in which the BGPSEC speaker receives a route 495 advertisement from a peer and then decides to propagate the route 496 advertisement to an external (eBGP) peer (Section 4.2). That is, the 497 BGPSEC speaker has received a BGPSEC update message and is 498 constructing a new update message for the same NLRI in which the 499 BGPSEC_Path_Signatures attribute will contain AS number(s) other than 500 the speaker's own AS. 502 In the remaining case where the BGPSEC speaker is sending the update 503 message to an internal (iBGP) peer, the BGPSEC speaker populates the 504 BGPSEC_Path_Signatures attribute by copying the 505 BGPSEC_Path_Signatures attribute from the received update message. 506 That is, the BGPSEC_Path_Signatures attribute is copied verbatim. 507 Note that in the case that a BGPSEC speaker chooses to forward to an 508 iBGP peer a BGPSEC update message that has not been successfully 509 validated (see Section 5), the BGPSEC_Path_Signatures attribute 510 SHOULD NOT be removed. (See Section 7 for the security ramifications 511 of removing BGPSEC signatures.) 513 The information protected by the signature on a BGPSEC update message 514 includes the AS number of the peer to whom the update message is 515 being sent. Therefore, if a BGPSEC speaker wishes to send a BGPSEC 516 update to multiple BGP peers, it MUST generate a separate BGPSEC 517 update message for each unique peer AS to which the update message is 518 sent. 520 A BGPSEC update message MUST advertise a route to only a single NLRI. 521 This is because a BGPSEC speaker receiving an update message with 522 multiple NLRI would be unable to construct a valid BGPSEC update 523 message (i.e., valid path signatures) containing a subset of the NLRI 524 in the received update. If a BGPSEC speaker wishes to advertise 525 routes to multiple NLRI, then it MUST generate a separate BGPSEC 526 update message for each NLRI. 528 Note that in order to create or add a new signature to a BGPSEC 529 update message with a given algorithm suite, the BGPSEC speaker must 530 possess a private key suitable for generating signatures for this 531 algorithm suite. Additionally, this private key must correspond to 532 the public key in a valid Resource PKI end-entity certificate whose 533 AS number resource extension includes the BGPSEC speaker's AS number 534 [11]. Note also that new signatures are only added to a BGPSEC 535 update message when a BGPSEC speaker is generating an update message 536 to send to an external peer (i.e., when the AS number of the peer is 537 not equal to the BGPSEC speaker's own AS number). Therefore, a 538 BGPSEC speaker who only sends BGPSEC update messages to peers within 539 its own AS, it does not need to possess any private signature keys. 541 4.1. Originating a New BGPSEC Update 543 In an update message that originates a new route advertisement (i.e., 544 an update whose path will contain only a single AS number), when 545 sending the route advertisement to an external, BGPSEC-speaking peer, 546 the BGPSEC speaker creates a new BGPSEC_Path_Signatures attribute as 547 follows. 549 First, the BGPSEC speaker constructs the Secure_Path with a single 550 Secure_Path Segment. The AS in this path is the BGPSEC speaker's own 551 AS number. In particular, this AS number MUST match the AS number in 552 the AS number resource extension field of the Resource PKI end-entity 553 certificate(s) that will be used to verify the digital signature(s) 554 constructed by this BGPSEC speaker. 556 Note that the BGPSEC_Path_Signatures attribute and the AS4_Path 557 attribute are mutually exclusive. That is, any update message 558 containing the BGPSEC_Path_Signatures attribute MUST NOT contain the 559 AS4_Path attribute nor the AS_Path attribute. The information that 560 would be contained in the AS4_Path (or AS_Path) attribute is instead 561 conveyed in the Secure_Path portion of the BGPSEC_Path_Signatures 562 attribute. 564 Note that the Resource PKI enables the legitimate holder of IP 565 address prefix(es) to issue a signed object, called a Route 566 Origination Authorization (ROA), that authorizes a given AS to 567 originate routes to a given set of prefixes (see [7]). Note that 568 validation of a BGPSEC update message will fail (i.e., the validation 569 algorithm, specified in Section 5.2, returns 'Not Good') unless there 570 exists a valid ROA authorizing the first AS in the Secure_Path 571 portion of the BGPSEC_Path_Signatures attribute to originate routes 572 to the prefix being advertised. Therefore, a BGPSEC speaker SHOULD 573 NOT originate a BGPSEC update advertising a route for a given prefix 574 unless there exists a valid ROA authorizing the BGPSEC speaker's AS 575 to originate routes to this prefix. 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). Setting the pCount field to a value 583 greater than one permits this repetition without requiring a separate 584 digital signature for each repetition. 586 If the BGPSEC speaker is not a member of an autonomous system 587 confederation [3], then the Flags field of the Secure_Path Segment 588 MUST be set to zero. (Members of a confederation should follow the 589 special processing instructions for confederation members in Section 590 4.4.) 592 The BGPSEC speaker next constructs the Additional_Info portion of the 593 BGPSEC_Path_Signatures attribute. The Info Type MUST be set to zero 594 and the Info Length MUST also be set to zero. The Info Value field 595 is empty (has length zero). It is anticipated that future 596 specifications may specify values of Info Type other than zero. 597 Therefore, BGPSEC receivers compliant with this specification must be 598 able to accept Additional_Info fields with non-zero Info Type. Such 599 receivers will use the Additional_Field to verify digital signatures 600 (see Section 5) but will otherwise ignore Additional_Field non-zero 601 Info Fields. 603 Typically, a BGPSEC speaker will use only a single algorithm suite, 604 and thus create only a single Signature_Block in the 605 BGPSEC_Path_Signatures attribute. However, to ensure backwards 606 compatibility during a period of transition from a 'current' 607 algorithm suite to a 'new' algorithm suite, it will be necessary to 608 originate update messages that contain a Signature_Block for both the 609 'current' and the 'new' algorithm suites (see Section 6.1). 611 When originating a new route advertisement, each Signature_Block MUST 612 consist of a single Signature Segment. The following describes how 613 the BGPSEC speaker populates the fields of the Signature_Block. 615 The Subject Key Identifier field (see Section 3) is populated with 616 the identifier contained in the Subject Key Identifier extension of 617 the RPKI end-entity certificate used by the BGPSEC speaker. This 618 Subject Key Identifier will be used by recipients of the route 619 advertisement to identify the proper certificate to use in verifying 620 the signature. 622 The Signature field contains a digital signature that binds the NLRI 623 and BGPSEC_Path_Signatures attribute to the RPKI end-entity 624 certificate used by the BGPSEC speaker. The digital signature is 625 computed as follows: 627 o Construct a sequence of octets by concatenating the Target AS 628 Number, the Secure_Path (Origin AS, pCount, and Flags), the 629 Additional_Info (Info Type, Info Length, and Info Value), 630 Algorithm Suite Identifier, and NLRI. The Target AS Number is the 631 AS to whom the BGPSEC speaker intends to send the update message. 632 (Note that the Target AS number is the AS number announced by the 633 peer in the OPEN message of the BGP session within which the 634 update is sent.) 635 Sequence of Octets to be Signed 636 +------------------------------------+ 637 | Target AS Number (4 octets) | 638 +------------------------------------+ 639 | Origin AS Number (4 octets) | ---\ 640 +------------------------------------+ \ 641 | pCount (1 octet) | > Secure_Path 642 +------------------------------------+ / 643 | Flags (1 octet) | ---/ 644 +------------------------------------+ 645 | Info Type (1 octet) | ---\ 646 +------------------------------------+ \ 647 | Info Length (1 octet) | > Additional_Info 648 +------------------------------------+ / 649 | Info Value (variable) | ---/ 650 +------------------------------------+ 651 | Algorithm Suite Id. (1 octet) | 652 +------------------------------------+ 653 | NLRI Length (1 octet) | 654 +------------------------------------+ 655 | NLRI Prefix (variable) | 656 +------------------------------------+ 658 o Apply to this octet sequence the digest algorithm (for the 659 algorithm suite of this Signature_Block) to obtain a digest value. 661 o Apply to this digest value the signature algorithm, (for the 662 algorithm suite of this Signature_Block) to obtain the digital 663 signature. Then populate the Signature Field with this digital 664 signature. 666 The Signature Length field is populated with the length (in octets) 667 of the Signature field. 669 4.2. Propagating a Route Advertisement 671 When a BGPSEC speaker receives a BGPSEC update message containing a 672 BGPSEC_Path_Signatures attribute (with one or more signatures) from 673 an (internal or external) peer, it may choose to propagate the route 674 advertisement by sending to its (internal or external) peers by 675 creating a new BGPSEC advertisement for the same prefix. 677 If a BGPSEC router has received only non-BGPSEC update messages 678 (without the BGPSEC_Path_Signatures attribute), containing the 679 AS_Path attribute, from a peer for a given prefix and if it chooses 680 to propagate that peer's route for the prefix, then it MUST NOT 681 attach any BGPSEC_Path_Signatures attribute to the corresponding 682 update being propagated. (Note that a BGPSEC router may also receive 683 a non-BGPSEC update message from an internal peer without the AS_Path 684 attribute, i.e., with just the NLRI in it. In that case, the prefix 685 is originating from that AS and hence the BGPSEC speaker SHOULD sign 686 and forward the update to its external peers, as specified in Section 687 4.1.) 689 Conversely, if a BGPSEC router has received a BGPSEC update message 690 (with the BGPSEC_Path_Signatures attribute) from a peer for a given 691 prefix and it chooses to propagate that peer's route for the prefix, 692 then it SHOULD propagate the route as a BGPSEC update message 693 containing the BGPSEC_Path_Signatures attribute. However, the BGPSEC 694 speaker MAY propagate the route as a (unsigned) BGP update message 695 without the BGPSEC_Path_Signatures attribute. 697 Note that removing BGPSEC signatures (i.e., propagating a route 698 advertisement without the BGPSEC_Path_Signatures attribute) has 699 significant security ramifications. (See Section 7 for discussion of 700 the security ramifications of removing BGPSEC signatures.) 701 Therefore, when a route advertisement is received via a BGPSEC update 702 message, propagating the route advertisement without the 703 BGPSEC_Path_Signatures attribute is NOT RECOMMENDED. Furthermore, 704 note that when a BGPSEC speaker propagates a route advertisement with 705 the BGPSEC_Path_Signatures attribute it is not attesting to the 706 validation state of the update message it received. (See Section 7 707 for more discussion of the security semantics of BGPSEC signatures.) 709 If the BGPSEC speaker is producing an update message which would, in 710 the absence of BGPSEC, contain an AS_SET (e.g., the BGPSEC speaker is 711 performing proxy aggregation), then the BGPSEC speaker MUST NOT 712 include the BGPSEC_Path_Signatures attribute. In such a case, the 713 BGPSEC speaker must remove any existing BGPSEC_Path_Signatures in the 714 received advertisement(s) for this prefix and produce a standard 715 (non-BGPSEC) update message. It should be noted that BCP 172 [5] 716 recommends against the use of AS_SET and AS_CONFED_SET in AS_PATH in 717 BGP updates. 719 To generate the BGPSEC_Path_Signatures attribute on the outgoing 720 update message, the BGPSEC speaker first prepends a new Secure_Path 721 Segment (places in first position) to the Secure_Path. The AS number 722 in this Secure_Path segment MUST match the AS number in the AS number 723 resource extension field of the Resource PKI end-entity 724 certificate(s) that will be used to verify the digital signature(s) 725 constructed by this BGPSEC speaker. 727 The pCount is typically set to the value 1. A BGPSEC speaker may set 728 the pCount field to a value greater than 1. (See Section 4.1 for a 729 discussion of setting pCount to a value greater than 1.) A route 730 server that participates in the BGP control path, but does not act as 731 a transit AS in the data plane, may choose to set pCount to 0. This 732 option enables the route server to participate in BGPSEC and obtain 733 the associated security guarantees without increasing the effective 734 length of the AS path. (Note that BGPSEC speakers compute the 735 effective length of the AS path by summing the pCount values in the 736 BGPSEC_Path_Signatures attribute, see Section 5.) However, when a 737 route server sets the pCount value to 0, it still inserts its AS 738 number into the Secure_Path segment, as this information is needed to 739 validate the signature added by the route server. Note that the 740 option of setting pCount to 0 is intended only for use by route 741 servers that desire not to increase the effective AS-PATH length of 742 routes they advertise. The pCount field SHOULD NOT be set to 0 in 743 other circumstances. BGPSEC speakers SHOULD drop incoming update 744 messages with pCount set to zero in cases where the BGPSEC speaker 745 does not expect its peer to set pCount to zero (i.e., cases where the 746 peer is not acting as a route server). 748 If the BGPSEC speaker is not a member of an autonomous system 749 confederation [3], then the Flags field of the Secure_Path Segment 750 MUST be set to zero. (Members of a confederation should follow the 751 special processing instructions for confederation members in Section 752 4.4.) 754 The BGPSEC speaker next copies the Additional_Info portion of the 755 BGPSEC_Path_Signatures directly from the received update message to 756 the new update message (that it is constructing). Note that the 757 BGPSEC speaker MUST NOT change the Additional_Info as any change to 758 Additional_Info will cause the new BGPSEC update message to fail 759 validation (see Section 5). 761 If the received BGPSEC update message contains two Signature_ Blocks 762 and the BGPSEC speaker supports both of the corresponding algorithms 763 suites, then the new update message generated by the BGPSEC speaker 764 SHOULD include both of the Signature_Blocks. If the received BGPSEC 765 update message contains two Signature_Blocks and the BGPSEC speaker 766 only supports one of the two corresponding algorithm suites, then the 767 BGPSEC speaker MUST remove the Signature_Block corresponding to the 768 algorithm suite that it does not understand. If the BGPSEC speaker 769 does not support the algorithm suites in any of the Signature_Blocks 770 contained in the received update message, then the BGPSEC speaker 771 MUST NOT propagate the route advertisement with the 772 BGPSEC_Path_Signatures attribute (i.e., propagate it as an unsigned 773 BGP update message). 775 Note that in the case where there are two Signature_Blocks 776 (corresponding to different algorithm suites) that the validation 777 algorithm (see Section 5.2) deems a BGPSEC update message to be 778 'Good' if there is at least one supported algorithm suite (and 779 corresponding Signature_Block) that is deemed 'Good'. This means 780 that a 'Good' BGPSEC update message may contain a Signature_Block 781 which is not deemed 'Good' (e.g., contains signatures that the BGPSEC 782 does not successfully verify). Nonetheless, such Signature_Blocks 783 MUST NOT be removed. (See Section 7 for a discussion of the security 784 ramifications of this design choice.) 786 For each Signature_Block corresponding to an algorithm suite that the 787 BGPSEC speaker does support, the BGPSEC speaker then adds a new 788 Signature Segment to the Signature_Block. This Signature Segment is 789 prepended to the list of Signature Segments (placed in the first 790 position) so that the list of Signature Segments appears in the same 791 order as the corresponding Secure_Path segments in the Secure_Path 792 portion of the BGPSEC_Path_Signatures attribute. The BGPSEC speaker 793 populates the fields of this new signature segment as follows. 795 The Subject Key Identifier field in the new segment is populated with 796 the identifier contained in the Subject Key Identifier extension of 797 the RPKI end-entity certificate used by the BGPSEC speaker. This 798 Subject Key Identifier will be used by recipients of the route 799 advertisement to identify the proper certificate to use in verifying 800 the signature. 802 The Signature field in the new segment contains a digital signature 803 that binds the NLRI and BGPSEC_Path_Signatures attribute to the RPKI 804 end-entity certificate used by the BGPSEC speaker. The digital 805 signature is computed as follows: 807 o Construct a sequence of octets by concatenating the Target AS 808 number, the Secure_Path segment that is being added by the BGPSEC 809 speaker constructing the signature, and the signature field of the 810 most recent Signature Segment (the one corresponding to AS from 811 whom the BGPSEC speaker's AS received the announcement). Note 812 that the Target AS number is the AS number announced by the peer 813 in the OPEN message of the BGP session within which the BGPSEC 814 update message is sent. 816 Sequence of Octets to be Signed 817 +--------------------------------------+ 818 | Target AS Number (4 octets) | 819 +--------------------------------------+ 820 | Signer's AS Number (4 octets) | ---\ 821 +--------------------------------------+ \ 822 | pCount (1 octet) | > Secure_Path 823 +--------- ----------------------------+ / 824 | Flags (1 octet) | ---/ 825 +--------------------------------------+ 826 | Most Recent Sig Field (variable) | 827 +--------------------------------------+ 829 o Apply to this octet sequence the digest algorithm (for the 830 algorithm suite of this Signature_Block) to obtain a digest value. 832 o Apply to this digest value the signature algorithm, (for the 833 algorithm suite of this Signature_Block) to obtain the digital 834 signature. Then populate the Signature Field with this digital 835 signature. 837 The Signature Length field is populated with the length (in octets) 838 of the Signature field. 840 4.3. Processing Instructions for Confederation Members 842 Members of autonomous system confederations [3] must additionally 843 follow the instructions in this section for processing BGPSEC update 844 messages. 846 When a confederation member sends a BGPSEC update message to a peer 847 that is a member of the same confederation, the confederation member 848 puts its (private) Member-AS Number (as opposed to the public AS 849 Confederation Identifier) in the AS Number field of the Secure_Path 850 Segment that it adds to the BGPSEC update message. Furthermore, when 851 a confederation member sends a BGPSEC update message to a peer that 852 is a member of the same confederation, the BGPSEC speaker that 853 generates the Secure_Path Segment sets the Confed_Segment flag to 854 one. Note that this means that in a BGPSEC update message, an AS 855 number appears in a Secure_Path Segment with the Confed_Segment flag 856 set to one, in precisely those circumstances where the AS number 857 would appear in a segment of type AS_CONFED_SEQUENCE in a non-BGPSEC 858 update message. 860 Within a confederation, the verification of BGPSEC signatures added 861 by other members of the confederation is optional. If a 862 confederation chooses to have its members not verify signatures added 863 by other confederation members, then when sending a BGPSEC update 864 message to a peer that is a member of the same confederation, the 865 confederation MAY set the Signature field within the 866 Signature_Segment that it generates to be zero (in lieu of 867 calculating the correct digital signature as described in Sections 868 4.1 and 4.2). Note that if a confederation chooses not to verify 869 digital signatures within the confederation, then BGPSEC is able to 870 provide no assurances about the integrity of the (private) Member-AS 871 Numbers placed in Secure_Path segments where the Confed_Segment flag 872 is set to one. 874 When a confederation member receives a BGPSEC update message from a 875 peer within the confederation and propagates it to a peer outside the 876 confederation, it must remove all of the Secure_Path Segments added 877 by confederation members as well as the corresponding Signature 878 Segments. To do this, the confederation member propagating the route 879 outside the confederation does the following: 881 o First, starting with the least recently added Secure_Path 882 segments, remove all of the consecutive Secure_Path segments that 883 have the Confed_Segment flag set to one. Stop this process once a 884 Scure_Path segment is reached which has its Confed_Segment flag 885 set to zero. Keep a count of the number of segments removed in 886 this fashion. 888 o Second, starting with the most recently added Signature Segment, 889 remove a number of Signature Segments equal to the number of 890 Secure_Path Segments removed in the previous step. (That is, 891 remove the K most recently added signature segments, where K is 892 the number of Secure_Path Segments removed in the previous step.) 894 o Finally, add a Secure_Path Segment containing, in the AS field, 895 the AS Confederation Identifier (the public AS number of the 896 confederation) as well as a corresponding Signature Segment. Note 897 that all fields other that the AS field are populated as per 898 Sections 4.1 and 4.2. 900 When validating a received BGPSEC update message, confederation 901 members must make the following adjustment to the algorithm presented 902 in Section 5.2. When a confederation member processes (validates) a 903 Signature Segment and its corresponding Secure_Path Segment, the 904 confederation member must note that for a signature produced by a 905 BGPSEC speaker outside of a confederation, the Target AS will always 906 be the AS Confederation Identifier (the public AS number of the 907 confederation) as opposed to the Member-AS Number. 909 To handle this case, when a BGPSEC speaker (that is a confederation 910 member) processes a current Secure_Path Segment that has the 911 Confed_Segment flag set to zero, if the next most recently added 912 Secure_Path segment has the Confed_Segment flag set to one then, when 913 computing the digest for the current Secure_Path segment, the BGPSEC 914 speaker takes the Target AS Number to be the AS Confederation 915 Identifier of the validating BGPSEC speaker's own confederation. 916 (Note that the algorithm in Section 5.2 processes Secure_Path 917 Segments in order from most recently added to least recently added, 918 therefore this special case will apply to the first Secure_Path 919 segment that the algorithm encounters that has the Confed_Segment 920 flag set to one.) 922 Finally, as discussed above, an AS confederation may optionally 923 decide that its members will not verify digital signatures added by 924 members. In such a federation, when a confederation member runs the 925 algorithm in Section 5.2, when processing a Signature_Segment, the 926 confederation member first checks whether the Confed_Sequence flag in 927 the corresponding Secure_Path segment is set to one. If the 928 Confed_Sequence flag is set to one in the corresponding Secure_Path 929 segment, the confederation member does not perform any further checks 930 on the Signature_Segment and immediately moves on to the next 931 Signature_Segment (and checks its corresponding Secure_Path segment). 932 Note that as specified in Section 5.2, it is an error for a BGPSEC 933 speaker to receive a BGPSEC update messages containing a Secure_Path 934 segment with the Confed_Sequence flag set to one from a peer who is 935 not a member of the same AS confederation. (Such an error is treated 936 in exactly the same way as receipt of a non-BGPSEC update message 937 containing an AS_CONFED_SEQUENCE from a peer that is not a member of 938 the same AS confederation.) 940 4.4. Reconstructing the AS_PATH Attribute 942 BGPSEC update messages do not contain the AS_PATH attribute. Note, 943 however, that the AS_PATH attribute can be reconstructed from the 944 BGPSEC_Path_Signatures attribute. This is necessary in the case 945 where a route advertisement is received via a BGPSEC update message 946 and then propagated to a peer via a non-BGPSEC update message. There 947 may be additional cases where an implementation finds it useful to 948 perform this reconstruction. 950 The AS_PATH attribute can be constructed from the 951 BGPSEC_Path_Signatures attribute as follows. Starting with an empty 952 AS_PATH attribute, process the Secure_Path segments in order from 953 least-recently added (corresponding to the origin) to most-recently 954 added. For each Secure_Path segment perform the following steps: 956 1. If the Confed_Segment flag in the Secure_Path segment is set to 957 one, then look at the most-recently added segment in the AS_PATH. 959 * In the case where the AS_PATH is empty or in the case where 960 the most-recently added segment is of type AS_SEQUENCE then 961 add (prepend to the AS_PATH) a new AS_PATH segment of type 962 AS_CONFED_SEQUENCE. This segment of type AS_CONFED_SEQUENCE 963 shall contain a number of elements equal to the pCount field 964 in the current Secure_Path segment. Each of these elements 965 shall be the AS number contained in the current Secure_Path 966 segment. (That is, if the pCount field is X, then the segment 967 of type AS_CONFED_SEQUENCE contains X copies of the 968 Secure_Path segment's AS Number field.) 970 * In the case where the most recently added segment in the 971 AS_PATH is of type AS_CONFED_SEQUENCE then add (prepend to the 972 segment) a number of elements equal to the pCount field in the 973 current Secure_Path segment. The value of each of these 974 elements shall be the AS number contained in the current 975 Secure_Path segment. (That is, if the pCount field is X, then 976 add X copies of the Secure_Path segment's AS Number field to 977 the existing AS_CONFED_SEQUENCE.) 979 2. If the Confed_Segment flag in the Secure_Path segment is set to 980 zero, then look at the most-recently added segment in the 981 AS_PATH. 983 * In the case where the AS_PATH is empty then add (prepend to 984 the AS_PATH) a new AS_PATH segment of type AS_SEQUENCE. This 985 segment of type AS_SEQUENCE shall contain a number of elements 986 equal to the pCount field in the current Secure_Path segment. 987 Each of these elements shall be the AS number contained in the 988 current Secure_Path segment. (That is, if the pCount field is 989 X, then the segment of type AS_SEQUENCE contains X copies of 990 the Secure_Path segment's AS Number field.) 992 * In the case where the most recently added segment in the 993 AS_PATH is of type AS_SEQUENCE then add (prepend to the 994 segment) a number of elements equal to the pCount field in the 995 current Secure_Path segment. The value of each of these 996 elements shall be the AS number contained in the current 997 Secure_Path segment. (That is, if the pCount field is X, then 998 add X copies of the Secure_Path segment's AS Number field to 999 the existing AS_SEQUENCE.) 1001 5. Processing a Received BGPSEC Update 1003 Upon receiving a BGPSEC update message from an external (eBGP) peer, 1004 a BGPSEC speaker SHOULD validate the message to determine the 1005 authenticity of the AS PATH information contained in the 1006 BGPSEC_Path_Signatures attribute. Section 5.1 provides an overview 1007 of BGPSEC validation and Section 5.2 provides a specific algorithm 1008 for performing such validation. (Note that an implementation need 1009 not follow the specific algorithm in Section 5.2 as long as the input 1010 output behavior of the validation is identical to that of the 1011 algorithm in Section 5.2.) During exceptional conditions (e.g., the 1012 BGPSEC speaker receives an incredibly large number of update messages 1013 at once) a BGPSEC speaker MAY defer validation of incoming BGPSEC 1014 update messages. The treatment of such BGPSEC update messages, whose 1015 validation has been deferred, is a matter of local policy. 1016 Implementations that support such deferment of validation MUST 1017 perform validation of these messages as soon as possible (i.e., as 1018 soon as resources are available to perform validation) and MUST re- 1019 run best path selection once the validation status of such update 1020 messages is known. 1022 BGPSEC update messages do not contain an AS_PATH attribute. 1023 Therefore, a BGPSEC speaker MUST utilize the AS path information in 1024 the BGPSEC_Path_Signatures attribute in all cases where it would 1025 otherwise use the AS path information in the AS_PATH attribute. The 1026 only exception to this rule is when AS path information must be 1027 updated in order to propagate a route to a peer (in which case the 1028 BGPSEC speaker follows the instructions in Section 4). Section 4.4 1029 provides an algorithm for constructing an AS_PATH attribute from a 1030 BGPSEC_Path_Signatures attribute. Whenever the use of AS path 1031 information is called for (e.g., loop detection, or use of AS path 1032 length in best path selection) the externally visible behavior of the 1033 implementation shall be the same as if the implementation had run the 1034 algorithm in Section 4.4 and used the resulting AS_PATH attribute as 1035 it would for a non-BGPSEC update message. However, in practice, it 1036 is expected that most implementations will not actually run the 1037 algorithm from Section 4.4, and will instead transform the 1038 BGPSEC_Path_Signatures attribute directly into some internal 1039 representation of AS path. 1041 Many signature algorithms are non-deterministic. That is, many 1042 signature algorithms will produce different signatures each time they 1043 are run (even when they are signing the same data with the same key). 1044 Therefore, if an implementation receives a BGPSEC update from a peer 1045 and later receives a second BGPSEC update message from the same peer, 1046 the implementation SHOULD treat the second message as a duplicate 1047 update message if it differs from the first update message only in 1048 the Signature fields (within the BGPSEC_Path_Signatures attribute). 1049 That is, if all the fields in the second update are identical to the 1050 fields in the first update message, except for the Signature fields, 1051 then the second update message should be treated as a duplicate of 1052 the first update message. Note that if other fields (e.g., the 1053 Subject Key Identifier field) within a Signature segment differ 1054 between two update messages then the two updates are not duplicates. 1056 With regards to the processing of duplicate update messages, if the 1057 first update message is valid, then an implementation SHOULD NOT run 1058 the validation procedure on the second, duplicate update message 1059 (even if the bits of the signature field are different). If the 1060 first update message is not valid, then an implementation SHOULD run 1061 the validation procedure on the second duplicate update message (as 1062 the signatures in the second update may be valid even though the 1063 first contained a signature that was invalid). 1065 5.1. Overview of BGPSEC Validation 1067 Validation of a BGPSEC update messages makes use of data from RPKI 1068 certificates and signed Route Origination Authorizations (ROA). In 1069 particular, to validate update messages containing the 1070 BGPSEC_Path_Signatures attribute, it is necessary that the recipient 1071 have access to the following data obtained from valid RPKI 1072 certificates and ROAs: 1074 o For each valid RPKI end-entity certificate containing an AS Number 1075 extension, the AS Number, Public Key and Subject Key Identifier 1076 are required, 1078 o For each valid ROA, the AS Number and the list of IP address 1079 prefixes. 1081 Note that the BGPSEC speaker could perform the validation of RPKI 1082 certificates and ROAs on its own and extract the required data, or it 1083 could receive the same data from a trusted cache that performs RPKI 1084 validation on behalf of (some set of) BGPSEC speakers. (The latter 1085 case in analogous to the use of the RPKI-RTR protocol [13] for origin 1086 validation.) 1088 To validate a BGPSEC update message containing the 1089 BGPSEC_Path_Signatures attribute, the recipient performs the 1090 validation steps specified in Section 5.2. The validation procedure 1091 results in one of two states: 'Good' and 'Not Good'. 1093 It is expected that the output of the validation procedure will be 1094 used as an input to BGP route selection. However, BGP route 1095 selection and thus the handling of the two validation states is a 1096 matter of local policy, and shall be handled using existing local 1097 policy mechanisms. It is expected that BGP peers will generally 1098 prefer routes received via 'Good' BGPSEC update messages over routes 1099 received via 'Not Good' BGPSEC update messages as well as routes 1100 received via update messages that do not contain the 1101 BGPSEC_Path_Signatures attribute. However, BGPSEC specifies no 1102 changes to the BGP decision process and leaves to the operator the 1103 selection of an appropriate policy mechanism to achieve the 1104 operator's desired results within the BGP decision process. 1106 BGPSEC validation needs only be performed at eBGP edge. The 1107 validation status of a BGP signed/unsigned update MAY be conveyed via 1108 iBGP from an ingress edge router to an egress edge router. Local 1109 policy in the AS determines the specific means for conveying the 1110 validation status through various pre-existing mechanisms (e.g., 1111 modifying an attribute). As discussed in Section 4, when a BGPSEC 1112 speaker chooses to forward a (syntactically correct) BGPSEC update 1113 message, it SHOULD be forwarded with its BGPSEC_Path_Signatures 1114 attribute intact (regardless of the validation state of the update 1115 message). Based entirely on local policy settings, an egress router 1116 MAY trust the validation status conveyed by an ingress router or it 1117 MAY perform its own validation. 1119 5.2. Validation Algorithm 1121 This section specifies an algorithm for validation of BGPSEC update 1122 messages. A conformant implementation MUST include a BGPSEC update 1123 validation algorithm that is functionally equivalent to the external 1124 behavior of this algorithm. 1126 First, the recipient of a BGPSEC update message performs a check to 1127 ensure that the message is properly formed. Specifically, the 1128 recipient performs the following checks: 1130 1. Check to ensure that the entire BGPSEC_Path_Signatures attribute 1131 is syntactically correct (conforms to the specification in this 1132 document). 1134 2. Check that each Signature_Block contains one Signature segment 1135 for each Secure_Path segment in the Secure_Path portion of the 1136 BGPSEC_Path_Signatures attribute. (Note that the entirety of 1137 each Signature_Block must be checked to ensure that it is well 1138 formed, even though the validation process may terminate before 1139 all signatures are cryptographically verified.) 1141 3. Check that the update message does not contain both a 1142 BGPSEC_Path_Signatures attribute and an AS_PATH attribute. 1144 4. If the update message was received from a peer that is not a 1145 member of the BGPSEC speaker's AS confederation, check to ensure 1146 that none of the Secure_Path segments contain a Flags field with 1147 the Confed_Sequence flag set to one. 1149 5. If the update message was received from a peer that is not 1150 expected to set pCount equal to zero (see Section 4.2) then check 1151 to ensure that the pCount field in the most-recently added 1152 Secure_Path segment is not equal to zero. 1154 If there are two Signature_Blocks within the BGPSEC_Path_Signatures 1155 attribute and one of them is poorly formed (or contains the wrong 1156 number of Signature segments) , then the recipient should log that an 1157 error occurred, strip off that particular Signature_Block and process 1158 the update message as though it arrived with a single 1159 Signature_Block. If the BGPSEC_Path_Signatures attribute contains an 1160 error that is not local to one of two Signature_Blocks, then the 1161 recipient should log that an error occurred and drop the update 1162 message containing the error. (In particular, if any of checks 3-5 1163 above fail, the recipient should log that an error occurred and drop 1164 the update message containing the error.) 1166 Next, the BGPSEC speaker verifies that the origin AS is authorized to 1167 advertise the prefix in question. To do this, consult the valid ROA 1168 data to obtain a list of AS numbers that are associated with the 1169 given IP address prefix in the update message. Then locate the last 1170 (least recently added) AS number in the Secure_Path portion of the 1171 BGPSEC_Path_Signatures attribute. If the origin AS in the 1172 Secure_Path is not in the set of AS numbers associated with the given 1173 prefix, then the BGPSEC update message is 'Not Good' and the 1174 validation algorithm terminates. 1176 Finally, the BGPSEC speaker examines the Signature_Blocks in the 1177 BGPSEC_Path_Signatures attribute. A Signature_Block corresponding to 1178 an algorithm suite that the BGPSEC speaker does not support is not 1179 considered in validation. If there does not exist a Signature_Block 1180 corresponding to an algorithm suite that the BGPSEC speaker supports, 1181 then the BGPSEC speaker MUST treat the update message in the same 1182 manner that the BGPSEC speaker would treat an (unsigned) update 1183 message that arrived without a BGPSEC_Path_Signatures attribute. 1185 For each remaining Signature_Block (corresponding to an algorithm 1186 suite supported by the BGPSEC speaker), the BGPSEC speaker iterates 1187 through the Signature segments in the Signature_Block, starting with 1188 the most recently added segment (and concluding with the least 1189 recently added segment). Note that there is a one-to-one 1190 correspondence between Signature segments and Secure_Path segments 1191 within the BGPSEC_Path_Signatures attribute. The following steps 1192 make use of this correspondence. 1194 o (Step I): Locate the public key needed to verify the signature (in 1195 the current Signature segment). To do this, consult the valid 1196 RPKI end-entity certificate data and look up all valid (AS, SKI, 1197 Public Key) triples in which the AS matches the AS number in the 1198 corresponding Secure_Path segment. Of these triples that match 1199 the AS number, check whether there is an SKI that matches the 1200 value in the Subject Key Identifier field of the Signature 1201 segment. If this check finds no such matching SKI value, then 1202 mark the entire Signature-List Block as 'Not Good' and proceed to 1203 the next Signature-List Block. 1205 o (Step II): Compute the digest function (for the given algorithm 1206 suite) on the appropriate data. If the segment is not the (least 1207 recently added) segment corresponding to the origin AS, then the 1208 digest function should be computed on the following sequence of 1209 octets: 1211 Sequence of Octets to be Hashed 1213 +-------------------------------------------+ 1214 | AS Number of Target AS (4 octets) | 1215 +-------------------------------------------+ 1216 | AS Number (4 octets) | ---\ 1217 +-------------------------------------------+ \ 1218 | pCount (1 octet) | > Secure_Path 1219 +-------------------------------------------+ / 1220 | Flags (1 octet) | ---/ 1221 +-------------------------------------------+ 1222 | Sig Field in the Next Segment (variable) | 1223 +-------------- ----------------------------+ 1225 For the first segment to be processed (the most recently added 1226 segment), the 'AS Number of Target AS' is the AS number of the BGPSEC 1227 speaker validating the update message. Note that if a BGPSEC speaker 1228 uses multiple AS Numbers (e.g., the BGPSEC speaker is a member of a 1229 confederation), the AS number used here MUST be the AS number 1230 announced in the OPEN message for the BGP session over which the 1231 BGPSEC update was received. 1233 For each other Signature Segment, the 'AS Number of Target AS' is the 1234 AS number in the Secure_Path segment that corresponds to the 1235 Signature Segment added immediately after the one being processed. 1236 (That is, in the Secure_Path segment that corresponds to the 1237 Signature segment that the validator just finished processing.) 1239 The AS Number, pCount and Flags fields are taken from the Secure_Path 1240 segment that corresponds to the Signature segment currently being 1241 processed. The 'Signature Field in the Next Segment' is the 1242 Signature field found in the Signature segment that is next to be 1243 processed (that is, the next most recently added Signature Segment). 1245 Alternatively, if the segment being processed corresponds to the 1246 origin AS (i.e., if it is the least recently added segment), then the 1247 digest function should be computed on the following sequence of 1248 octets: 1250 Sequence of Octets to be Hashed 1251 +------------------------------------+ 1252 | AS Number of Target AS (4 octets) | 1253 +------------------------------------+ 1254 | Origin AS Number (4 octets) | ---\ 1255 +------------------------------------+ \ 1256 | pCount (1 octet) | > Secure_Path 1257 +------------------------------------+ / 1258 | Flags (1 octet) | ---/ 1259 +------------------------------------+ 1260 | Info Type (1 octet) | ---\ 1261 +------------------------------------+ \ 1262 | Info Length (1 octet) | > Additional_Info 1263 +------------------------------------+ / 1264 | Info Value (variable) | ---/ 1265 +------------------------------------+ 1266 | Algorithm Suite Id. (1 octet) | 1267 +------------------------------------+ 1268 | NLRI Length (1 octet) | 1269 +------------------------------------+ 1270 | NLRI Prefix (variable) | 1271 +------------------------------------+ 1273 The NLRI Length, NLRI Prefix, Additional_Info, and Algorithm Suite 1274 Identifier are all obtained in a straight forward manner from the 1275 NLRI of the update message or the BGPSEC_Path_Signatures attribute 1276 being validated. The Origin AS Number, pCount, and Flags fields are 1277 taken from the Secure_Path segment corresponding to the Signature 1278 Segment currently being processed. 1280 The 'AS Number of Target AS' is the AS Number from the Secure_Path 1281 segment that was added immediately after the Secure_Path segment 1282 containing the Origin AS Number. (That is, the Secure_Path segment 1283 corresponding to the Signature segment that the receiver just 1284 finished processing prior to the current Signature segment.) 1286 o (Step III): Use the signature validation algorithm (for the given 1287 algorithm suite) to verify the signature in the current segment. 1288 That is, invoke the signature validation algorithm on the 1289 following three inputs: the value of the Signature field in the 1290 current segment; the digest value computed in Step II above; and 1291 the public key obtained from the valid RPKI data in Step I above. 1292 If the signature validation algorithm determines that the 1293 signature is invalid, then mark the entire Signature-List Block as 1294 'Not Good' and proceed to the next Signature_Block. If the 1295 signature validation algorithm determines that the signature is 1296 valid, then continue processing Signature-Segments (within the 1297 current Signature-List Block). 1299 If all Signature-Segments within a Signature-List Block pass 1300 validation (i.e., all segments are processed and the Signature-List 1301 Block has not yet been marked 'Not Good'), then the Signature_Block 1302 is marked as 'Good'. 1304 If at least one Signature_Block is marked as 'Good', then the 1305 validation algorithm terminates and the BGPSEC update message is 1306 deemed to be 'Good'. (That is, if a BGPSEC update message contains 1307 two Signature_Blocks then the update message is deemed 'Good' if the 1308 first Signature_Block is marked 'Good' OR the second Signature_Block 1309 is marked 'Good'.) 1311 6. Algorithms and Extensibility 1313 6.1. Algorithm Suite Considerations 1315 Note that there is currently no support for bilateral negotiation 1316 between BGPSEC peers to use of a particular (digest and signature) 1317 algorithm suite using BGP capabilities. This is because the 1318 algorithm suite used by the sender of a BGPSEC update message must be 1319 understood not only by the peer to whom he is directly sending the 1320 message, but also by all BGPSEC speakers to whom the route 1321 advertisement is eventually propagated. Therefore, selection of an 1322 algorithm suite cannot be a local matter negotiated by BGP peers, but 1323 instead must be coordinated throughout the Internet. 1325 To this end, a mandatory algorithm suites document will be created 1326 which specifies a mandatory-to-use 'current' algorithm suite for use 1327 by all BGPSEC speakers [12]. Additionally, the document specifies an 1328 additional 'new' algorithm suite that is recommended to implement. 1330 It is anticipated that in the future the mandatory algorithm suites 1331 document will be updated to specify a transition from the 'current' 1332 algorithm suite to the 'new' algorithm suite. During the period of 1333 transition (likely a small number of years), all BGPSEC update 1334 messages SHOULD simultaneously use both the 'current' algorithm suite 1335 and the 'new' algorithm suite. (Note that Sections 3 and 4 specify 1336 how the BGPSEC_Path_Signatures attribute can contain signatures, in 1337 parallel, for two algorithm suites.) Once the transition is 1338 complete, use of the old 'current' algorithm will be deprecated, use 1339 of the 'new' algorithm will be mandatory, and a subsequent 'even 1340 newer' algorithm suite may be specified as recommend to implement. 1341 Once the transition has successfully been completed in this manner, 1342 BGPSEC speakers SHOULD include only a single Signature_Block 1343 (corresponding to the 'new' algorithm). 1345 6.2. Extensibility Considerations 1347 This section discusses potential changes to BGPSEC that would require 1348 substantial changes to the processing of the BGPSEC_Path_Signatures 1349 and thus necessitate a new version of BGPSEC. Examples of such 1350 changes include: 1352 o A new type of signature algorithm that produces signatures of 1353 variable length 1355 o A new type of signature algorithm for which the number of 1356 signatures in the Signature_Block is not equal to the number of 1357 ASes in the Secure_Path (e.g., aggregate signatures) 1359 o Changes to the data that is protected by the BGPSEC signatures 1360 (e.g., attributes other than the AS path) 1362 In the case that such a change to BGPSEC were deemed desirable, it is 1363 expected that a subsequent version of BGPSEC would be created and 1364 that this version of BGPSEC would specify a new BGP Path Attribute, 1365 let's call it BGPSEC_PATH_SIG_TWO, which is designed to accommodate 1366 the desired changes to BGPSEC. In such a case, the mandatory 1367 algorithm suites document would be updated to specify algorithm 1368 suites appropriate for the new version of BGPSEC. 1370 At this point a transition would begin which is analogous to the 1371 algorithm transition discussed in Section 6.2. During the transition 1372 period all BGPSEC speakers SHOULD simultaneously include both the 1373 BGPSEC_PATH_SIGNATURES attribute and the new BGPSEC_PATH_SIG_TWO 1374 attribute. Once the transition is complete, the use of 1375 BGPSEC_PATH_SIGNATURES could then be deprecated, at which point 1376 BGPSEC speakers SHOULD include only the new BGPSEC_PATH_SIG_TWO 1377 attribute. Such a process could facilitate a transition to a new 1378 BGPSEC semantics in a backwards compatible fashion. 1380 7. Security Considerations 1382 For discussion of the BGPSEC threat model and related security 1383 considerations, please see [10]. 1385 A BGPSEC speaker who receives a valid BGPSEC update message, 1386 containing a route advertisement for a given prefix, is provided with 1387 the following security guarantees: 1389 o The origin AS number corresponds to an autonomous system that has 1390 been authorized by the IP address space holder to originate route 1391 advertisements for the given prefix. 1393 o For each AS number in the AS Path, a BGPSEC speaker authorized by 1394 the holder of the AS number intentionally chose (in accordance 1395 with local policy) to propagate the route advertisement to the 1396 next AS in the Secure_Path. 1398 That is, the recipient of a valid BGPSEC Update message is assured 1399 that the Secure_Path corresponds to a sequence of autonomous systems 1400 who have all agreed in principle to forward packets to the given 1401 prefix along the indicated path. (It should be noted that BGPSEC 1402 does not offer a precise guarantee that the data packets would 1403 propagate along the indicated path; it only guarantees that the BGP 1404 update conveying the path indeed propagated along the indicated 1405 path.) Furthermore, the recipient is assured that this path 1406 terminates in an autonomous system that has been authorized by the IP 1407 address space holder as a legitimate destination for traffic to the 1408 given prefix. 1410 Note that although BGPSEC provides a mechanism for an AS to validate 1411 that a received update message has certain security properties, the 1412 use of such a mechanism to influence route selection is completely a 1413 matter of local policy. Therefore, a BGPSEC speaker can make no 1414 assumptions about the validity of a route received from an external 1415 BGPSEC peer. That is, a compliant BGPSEC peer may (depending on the 1416 local policy of the peer) send update messages that fail the validity 1417 test in Section 5. Thus, a BGPSEC speaker MUST completely validate 1418 all BGPSEC update messages received from external peers. (Validation 1419 of update messages received from internal peers is a matter of local 1420 policy, see Section 5). 1422 Note that there may be cases where a BGPSEC speaker deems 'Good' (as 1423 per the validation algorithm in Section 5.2) a BGPSEC update message 1424 that contains both a 'Good' and a 'Not Good' Signature_Block. That 1425 is, the update message contains two sets of signatures corresponding 1426 to two algorithm suites, and one set of signatures verifies correctly 1427 and the other set of signatures fails to verify. In this case, the 1428 protocol specifies that if the BGPSEC speaker propagates the route 1429 advertisement received in such an update message then the BGPSEC 1430 speaker SHOULD add its signature to each of the Signature_Blocks 1431 using both the corresponding algorithm suite. Thus the BGPSEC 1432 speaker creates a signature using both algorithm suites and creates a 1433 new update message that contains both the 'Good' and the 'Not Good' 1434 set of signatures (from its own vantage point). 1436 To understand the reason for such a design decision consider the case 1437 where the BGPSEC speaker receives an update message with both a set 1438 of algorithm A signatures which are 'Good' and a set of algorithm B 1439 signatures which are 'Not Good'. In such a case it is possible 1440 (perhaps even quite likely) that some of the BGPSEC speaker's peers 1441 (or other entities further 'downstream' in the BGP topology) do not 1442 support algorithm A. Therefore, if the BGPSEC speaker were to remove 1443 the 'Not Good' set of signatures corresponding to algorithm B, such 1444 entities would treat the message as though it were unsigned. By 1445 including the 'Not Good' set of signatures when propagating a route 1446 advertisement, the BGPSEC speaker ensures that 'downstream' entities 1447 have as much information as possible to make an informed opinion 1448 about the validation status of a BGPSEC update. 1450 Note also that during a period of partial BGPSEC deployment, a 1451 'downstream' entity might reasonably treat unsigned messages 1452 different from BGPSEC updates that contain a single set of 'Not Good' 1453 signatures. That is, by removing the set of 'Not Good' signatures 1454 the BGPSEC speaker might actually cause a downstream entity to 1455 'upgrade' the status of a route advertisement from 'Not Good' to 1456 unsigned. Finally, note that in the above scenario, the BGPSEC 1457 speaker might have deemed algorithm A signatures 'Good' only because 1458 of some issue with RPKI state local to his AS (for example, his AS 1459 might not yet have obtained a CRL indicating that a key used to 1460 verify an algorithm A signature belongs to a newly revoked 1461 certificate). In such a case, it is highly desirable for a 1462 downstream entity to treat the update as 'Not Good' (due to the 1463 revocation) and not as 'unsigned' (which would happen if the 'Not 1464 Good' Signature_Blocks were removed). 1466 A similar argument applies to the case where a BGPSEC speaker (for 1467 some reason such as lack of viable alternatives) selects as his best 1468 route to a given prefix a route obtained via a 'Not Good' BGPSEC 1469 update message. (That is, a BGPSEC update containing only 'Not Good' 1470 Signature-List Blocks.) In such a case, the BGPSEC speaker should 1471 propagate a signed BGPSEC update message, adding his signature to the 1472 'Not Good' signatures that already exist. Again, this is to ensure 1473 that 'downstream' entities are able to make an informed decision and 1474 not erroneously treat the route as unsigned. It may also be noted 1475 here that due to possible differences in RPKI data at different 1476 vantage points in the network, a BGPSEC update that was deemed 'Not 1477 Good' at an upstream BGPSEC speaker may indeed be deemed 'Good' at 1478 another BGP speaker downstream. 1480 Therefore, it is important to note that when a BGPSEC speaker signs 1481 an outgoing update message, it is not attesting to a belief that all 1482 signatures prior to its are valid. Instead it is merely asserting 1483 that: 1485 o The BGPSEC speaker received the given route advertisement with the 1486 indicated NLRI and Secure_Path; and 1488 o The BGPSEC speaker chose to propagate an advertisement for this 1489 route to the peer (implicitly) indicated by the 'Target AS' 1491 The BGPSEC update validation procedure is a potential target for 1492 denial of service attacks against a BGPSEC speaker. To mitigate the 1493 effectiveness of such denial of service attacks, BGPSEC speakers 1494 should implement an update validation algorithm that performs 1495 expensive checks (e.g., signature verification) after performing less 1496 expensive checks (e.g., syntax checks). The validation algorithm 1497 specified in Section 5.2 was chosen so as to perform checks which are 1498 likely to be expensive after checks that are likely to be 1499 inexpensive. However, the relative cost of performing required 1500 validation steps may vary between implementations, and thus the 1501 algorithm specified in Section 5.2 may not provide the best denial of 1502 service protection for all implementations. 1504 The mechanism of setting the pCount field to zero is included in this 1505 specification to enable route servers in the control path to 1506 participate in BGPSEC without increasing the effective length of the 1507 AS-PATH. However, entities other than route servers could 1508 conceivably use this mechanism (set the pCount to zero) to attract 1509 traffic (by reducing the effective length of the AS-PATH) 1510 illegitimately. This risk is largely mitigated if every BGPSEC 1511 speaker drops incoming update messages that set pCount to zero but 1512 come from a peer that is not a route server. However, note that a 1513 recipient of a BGPSEC update message in which an upstream entity that 1514 is two or more hops away set pCount to zero is unable to verify for 1515 themselves whether pCount was set to zero legitimately. 1517 Finally, BGPSEC does not provide protection against all attacks at 1518 the transport layer. An adversary on the path between a BGPSEC 1519 speaker and its peer is able to perform attacks such as modifying 1520 valid BGPSEC updates to cause them to fail validation, injecting 1521 (unsigned) BGP update messages without BGPSEC_Path_Signature 1522 attributes, or injecting BGPSEC update messages with 1523 BGPSEC_Path_Signature attributes that fail validation, or causing the 1524 peer to tear-down the BGP session. Therefore, BGPSEC implementations 1525 MUST support appropriate transport security mechanisms. 1527 EDITOR'S NOTE: Do we want to mandate a specific transport security 1528 mechanism (e.g., TCP-AO)? 1530 8. Contributors 1532 8.1. Authors 1534 Rob Austein 1535 Dragon Research Labs 1536 sra@hactrn.net 1538 Steven Bellovin 1539 Columbia University 1540 smb@cs.columbia.edu 1542 Randy Bush 1543 Internet Initiative Japan 1544 randy@psg.com 1546 Russ Housley 1547 Vigil Security 1548 housley@vigilsec.com 1550 Matt Lepinski 1551 BBN Technologies 1552 lepinski@bbn.com 1554 Stephen Kent 1555 BBN Technologies 1556 kent@bbn.com 1558 Warren Kumari 1559 Google 1560 warren@kumari.net 1562 Doug Montgomery 1563 USA National Institute of Standards and Technology 1564 dougm@nist.gov 1566 Kotikalapudi Sriram 1567 USA National Institute of Standards and Technology 1568 kotikalapudi.sriram@nist.gov 1569 Samuel Weiler 1570 Cobham 1571 weiler+ietf@watson.org 1573 8.2. Acknowledgements 1575 The authors would like to thank Luke Berndt, Sharon Goldberg, Ed 1576 Kern, Chris Morrow, Doug Maughan, Pradosh Mohapatra, Russ Mundy, 1577 Sandy Murphy, Keyur Patel, Mark Reynolds, Heather Schiller, Jason 1578 Schiller, John Scudder, Ruediger Volk and David Ward for their 1579 valuable input and review. 1581 9. References 1583 [1] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 1584 Gateway Protocol 4", RFC 4271, January 2006. 1586 [2] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1587 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 1589 [3] Traina, P., McPherson, D., and J. Scudder, "Autonomous System 1590 Confederations for BGP", RFC 5065, August 2007. 1592 [4] Scudder, J. and R. Chandra, "Capabilities Advertisement with 1593 BGP-4", RFC 5492, February 2009. 1595 [5] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET 1596 and AS_CONFED_SET in BGP", RFC 6472, December 2011. 1598 [6] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure 1599 Internet Routing", RFC 6480, February 2012. 1601 [7] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1602 Origin Authorizations (ROAs)", RFC 6482, February 2012. 1604 [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1605 Levels", BCP 14, RFC 2119, March 1997. 1607 [9] Patel, K., Ward, D., and R. Bush, "Extended Message support for 1608 BGP", draft-ietf-idr-bgp-extended-messages, July 2012. 1610 [10] Kent, S., and A. Chi, "Threat Model for BGP Path Security", 1611 draft-ietf-sidr-bgpsec-threats-02, February 2012. 1613 [11] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPSEC 1614 Router Certificates, Certificate Revocation Lists, and 1615 Certification Requests", 1616 draft-ietf-sidr-bgpsec-pki-profiles-03, April 2012. 1618 [12] Turner, S., "BGP Algorithms, Key Formats, & Signature Formats", 1619 draft-ietf-sidr-bgpsec-algs-02, March 2012. 1621 [13] Bush, R. and R. Austein, "The RPKI/Router Protocol", 1622 draft-ietf-sidr-rtr-26, February 2012. 1624 Author's Address 1626 Matthew Lepinski (editor) 1627 BBN 1628 10 Moulton St 1629 Cambridge, MA 55409 1630 US 1632 Phone: +1 617 873 5939 1633 Email: mlepinski@bbn.com