idnits 2.17.1 draft-ietf-sidr-bgpsec-protocol-04.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.) 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 (July 16, 2012) is 4294 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 1448, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6480 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 6 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 July 16, 2012 5 Expires: January 17, 2013 7 BGPSEC Protocol Specification 8 draft-ietf-sidr-bgpsec-protocol-04 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 January 17, 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 . . . . . . . . . . . . . . . . . . . . . 9 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. Reconstructing the AS_Path Attribute . . . . . . . . . . . 19 68 4.4. Processing Instructions for Confederation Members . . . . 19 69 5. Processing a Received BGPSEC Update . . . . . . . . . . . . . 21 70 5.1. Validation Algorithm . . . . . . . . . . . . . . . . . . . 22 71 6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 26 72 6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 26 73 6.2. Extensibility Considerations . . . . . . . . . . . . . . . 27 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 75 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 76 8.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 31 77 8.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 32 78 9. Normative References . . . . . . . . . . . . . . . . . . . . . 32 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33 81 1. Introduction 83 This document describes BGPSEC, a mechanism for providing path 84 security for Border Gateway Protocol (BGP) [1] route advertisements. 85 That is, a BGP speaker who receives a valid BGPSEC update has 86 cryptographic assurance that the advertised route has the following 87 two properties: 89 1. The route was originated by an AS that has been explicitly 90 authorized by the holder of the IP address prefix to originate 91 route advertisements for that prefix. 93 2. Every AS listed in the AS_Path attribute of the update explicitly 94 authorized the advertisement of the route to the subsequent AS in 95 the AS_Path. 97 This document specifies a new optional (non-transitive) BGP path 98 attribute, BGPSEC_Path_Signatures. It also describes how a BGPSEC- 99 compliant BGP speaker (referred to hereafter as a BGPSEC speaker) can 100 generate, propagate, and validate BGP update messages containing this 101 attribute to obtain the above assurances. 103 BGPSEC relies on the Resource Public Key Infrastructure (RPKI) 104 certificates that attest to the allocation of AS number and IP 105 address resources. (For more information on the RPKI, see [6] and 106 the documents referenced therein.) Any BGPSEC speaker who wishes to 107 send BGP update messages to external peers (eBGP) containing the 108 BGPSEC_Path_Signatures must have an RPKI end-entity certificate (as 109 well as the associated private signing key) corresponding to the 110 BGPSEC speaker's AS number. Note, however, that a BGPSEC speaker 111 does not require such a certificate in order to validate update 112 messages containing the BGPSEC_Path_Signatures attribute. 114 2. BGPSEC Negotiation 116 This document defines a new BGP capability [4]that allows a BGP 117 speaker to advertise to its neighbors the ability to send and/or 118 receive BGPSEC update messages (i.e., update messages containing the 119 BGPSEC_Path_Signatures attribute). 121 This capability has capability code : TBD 123 The capability length for this capability MUST be set to 5. 125 The three octets of the capability value are specified as follows. 127 Capability Value: 129 0 1 2 3 4 5 6 7 130 +---------------------------------------+ 131 | Send | Receive | Reserved | Version | 132 +---------------------------------------+ 133 | AFI | 134 +---------------------------------------+ 135 | | 136 +---------------------------------------+ 137 | Reserved | 138 +---------------------------------------+ 139 | SAFI | 140 +---------------------------------------+ 142 The high order bit (bit 0) of the first octet is set to 1 to indicate 143 that the sender is able to send BGPSEC update messages, and is set to 144 zero otherwise. The next highest order bit (bit 1) of this octet is 145 set to 1 to indicate that the sender is able to receive BGPSEC update 146 messages, and is set to zero otherwise. The next two bits of the 147 capability value (bits 2 and 3) are reserved for future use. These 148 reserved bits should be set to zero by the sender and ignored by the 149 receiver. 151 The four low order bits (4, 5, 6 and 7) of the first octet indicate 152 the version of BGPSEC for which the BGP speaker is advertising 153 support. This document defines only BGPSEC version 0 (all four bits 154 set to zero). Other versions of BGPSEC may be defined in future 155 documents. A BGPSEC speaker MAY advertise support for multiple 156 versions of BGPSEC by including multiple versions of the BGPSEC 157 capability in its BGP OPEN message. 159 If there does not exist at least one version of BGPSEC that is 160 supported by both peers in a BGP session, then the use of BGPSEC has 161 not been negotiated. (That is, in such a case, messages containing 162 the BGPSEC_Path_Signatures MUST NOT be sent.) 164 If version 0 is the only version of BGPSEC for which both peers (in a 165 BGP session) advertise support, then the use of BGPSEC has been 166 negotiated and the BGPSEC peers MUST adhere to the specification of 167 BGPSEC provided in this document. (If there are multiple versions of 168 BGPSEC which are supported by both peers, then the behavior of those 169 peers is outside the scope of this document.) 171 The second and third octets contain the 16-bit Address Family 172 Identifier (AFI) which indicates the address family for which the 173 BGPSEC speaker is advertising support for BGPSEC. This document only 174 specifies BGPSEC for use with two address families, IPv4 and IPv6, 175 AFI values 1 and 2 respectively. BGPSEC for use with other address 176 families may be specified in future documents. 178 The fourth octet in the capability is reserved. It is anticipated 179 that this octet will not be used until such a time as the reserved 180 octet in the Multi-protocol extensions capability advertisement [2] 181 is specified for use. The reserved octet should be set to zero by 182 the sender and ignored by the receiver. 184 The fifth octet in the capability contains the 8-bit Subsequent 185 Address Family Identifier (SAFI). This value is encoded as in the 186 BGP multiprotocol extensions [2]. 188 Note that if the BGPSEC speaker wishes to use BGPSEC with two 189 different address families (i.e., IPv4 and IPv6) over the same BGP 190 session, then the speaker must include two instances of this 191 capability (one for each address family) in the BGP OPEN message. A 192 BGPSEC speaker SHOULD NOT advertise the capability of BGPSEC support 193 for any combination unless it has also advertises the 194 multiprotocol extension capability for the same 195 combination [2]. 197 By indicating support for receiving BGPSEC update messages, a BGP 198 speaker is, in particular, indicating that the following are true: 200 o The BGP speaker understands the BGPSEC_Path_Signatures attribute 201 (see Section 3). 203 o The BGP speaker supports 4-byte AS numbers (see RFC 4893). 205 Note that BGPSEC update messages can be quite large, therefore any 206 BGPSEC speaker announcing the capability to receive BGPSEC messages 207 SHOULD also announce support for the capability to receive BGP 208 extended messages [9]. 210 A BGP speaker MUST NOT send an update message containing the 211 BGPSEC_Path_Signatures attribute within a given BGP session unless 212 both of the following are true: 214 o The BGP speaker indicated support for sending BGPSEC update 215 messages in its open message. 217 o The peer of the BGP speaker indicated support for receiving BGPSEC 218 update messages in its open message. 220 3. The BGPSEC_Path_Signatures Attribute 222 The BGPSEC_Path_Signatures attribute is a new optional (non- 223 transitive) BGP path attribute. 225 This document registers a new attribute type code for this attribute 226 : TBD 228 The BGPSEC_Path_Signatures algorithm carries the secured AS Path 229 information, including the digital signatures that protect this AS 230 Path information. We refer to those update messages that contain the 231 BGPSEC_Path_Signatures attribute as "BGPSEC Update messages". The 232 BGPSEC_Path_Signatures attribute replaces the AS_PATH attribute, in a 233 BGPSEC update message. That is, update messages that contain the 234 BGPSEC_Path_Signatures attribute MUST NOT contain the AS_PATH 235 attribute. 237 The BGPSEC_Path_Signatures attribute is made up of several parts. 238 The following high-level diagram provides an overview of the 239 structure of the BGPSEC_Path_Signatures attribute: 241 High-Level Diagram of the BGPSEC_Path_Signatures Attribute 242 BGPSEC_Path_Signatures 243 +---------------------------------------------------------+ 244 | +-----------------+ | 245 | | Secure Path | +-----------------+ | 246 | +-----------------+ | Additional Info | | 247 | | AS X | +-----------------+ | 248 | | pCount X | | Info Type | | 249 | | Flags X | | Info Length | | 250 | | AS Y | | Info Value | | 251 | | pCount Y | +-----------------+ | 252 | | Flags Y | | 253 | | ... | | 254 | +-----------------+ | 255 | | 256 | +-----------------+ +-----------------+ | 257 | | Sig Block 1 | | Sig Block 2 | | 258 | +-----------------+ +-----------------+ | 259 | | Alg Suite 1 | | Alg Suite 2 | | 260 | | SKI X | | SKI X | | 261 | | Sig Length X | | Sig Length X | | 262 | | Signature X | | Signature X | | 263 | | SKI Length Y | | SKI Length Y | | 264 | | SKI Y | | SKI Y | | 265 | | Sig Length Y | | Sig Length Y | | 266 | | Signature Y | | Signature Y | | 267 | | ... | | .... | | 268 | +-----------------+ +-----------------+ | 269 | | 270 +---------------------------------------------------------+ 272 The following is a more detailed explanation of the format of the 273 BGPSEC_Path_Signatures attribute. 275 BGPSEC_Path_Signatures Attribute 277 +-------------------------------------------------------+ 278 | Secure_Path (variable) | 279 +-------------------------------------------------------+ 280 | Additional_Info (variable) | 281 +-------------------------------------------------------+ 282 | Sequence of one or two Signature_Blocks (variable) | 283 +-------------------------------------------------------+ 285 The Secure_Path contains AS Path information for the BGPSEC update 286 message. This is logically equivalent to the information that would 287 be contained in the AS_PATH attribute. A BGPSEC update message 288 containing the BGPSEC_PATH_SIGNATURES attribute MUST NOT contain the 289 AS_PATH attribute. The format of the Secure_Path is described below 290 in Section 3.1. 292 The Additional_Info contains additional signed information about the 293 update message. Additional_Info is specified as a type-length-value 294 field for future extensibility. However, this specification defines 295 only a single (null) type of Additional Info which has zero length. 296 It is anticipated that future specifications may specify semantics 297 for Info Types other than zero. See Section 3.2 below for more 298 detail. 300 The BGPSEC_Path_Signatures attribute will contain one or two 301 Signature_Blocks, each of which corresponds to a different algorithm 302 suite. Each of the Signature_Blocks will contain a signature segment 303 for each AS number (i.e, secure path segment) in the Secure_Path. In 304 the most common case, the BGPSEC_Path_Signatures attribute will 305 contain only a single Signature_Block. However, in order to enable a 306 transition from an old algorithm suite to a new algorithm suite, it 307 will be necessary to include two Signature_Blocks (one for the old 308 algorithm suite and one for the new algorithm suite) during the 309 transition period. (See Section 6.1 for more discussion of algorithm 310 transitions.) The format of the Signature_Blocks is described below 311 in Section 3.3. 313 3.1. Secure_Path 315 Here we provide a detailed description of the Secure_Path information 316 in the BGPSEC_Path_Signatures attribute. 318 Secure_Path 320 +-----------------------------------------------+ 321 | Secure_Path Length (2 octets) | 322 +-----------------------------------------------+ 323 | One or More Secure_Path Segments (variable) | 324 +-----------------------------------------------+ 326 The Secure_Path Length contains the length (in octets) of the 327 variable-length sequence of Secure_Path Segments. As explained 328 below, each Secure_Path segment is six octets long. Note that this 329 means the Secure_Path Length is six times the number Secure_Path 330 Segments (i.e., the number of AS numbers in the path). 332 The Secure_Path contains one Secure_Path segment for each (distinct) 333 Autonomous System in the path to the NLRI specified in the update 334 message. 336 Secure_Path Segment 338 +----------------------------+ 339 | AS Number (4 octets) | 340 +----------------------------+ 341 | pCount (1 octet) | 342 +----------------------------+ 343 | Flags (1 octet) | 344 +----------------------------+ 346 The AS Number is the AS number of the BGP speaker that added this 347 Secure_Path segment to the BGPSEC_Path_Signatures attribute. (See 348 Section 4 for more information on populating this field.) 350 The pCount field contains the number of repetitions of the associated 351 autonomous system number that the signature covers. This field 352 enables a BGPSEC speaker to mimic the semantics of adding multiple 353 copies of their AS to the AS_PATH without requiring the speaker to 354 generate multiple signatures. 356 The first bit of the Flags field is the Entering_Confed flag. The 357 Entering_Confed flag is set to one in the Secure_Path Segment 358 corresponding to the first Autonomous System in a confederation [3]. 359 (That is, the Secure_Path Segment corresponding to the AS that would 360 otherwise have created an AS_Path segment of type AS_Confed_Sequence 361 in a non-BGSPEC update message.) In all other cases the 362 Entering_Confed flag is set to zero. 364 The remaining seven bits of the Flags field are reserved for future 365 use. These bits MUST be set to zero by the sender. The receiver 366 uses the entire Flags octet to verify the digital signature 367 (regardless of what value the reserved bits contain), but otherwise 368 ignores the reserved flags (see Section 4 for sender instructions and 369 Section 5 for receiver validation instructions). 371 EDITOR'S NOTE: The unused portion of the signed flags field provides 372 the possibility of adding in the future (in a backwards compatible 373 fashion) a new feature that requires some per-AS signed bits. For 374 example, one could use a couple bits from this flag field to mark 375 some property of the connection between two ASes. 377 3.2. Additional_Info 379 Here we provide a detailed description of the Additional_Info in the 380 BGPSEC_Path_Signatures attribute. 382 Additional_Info 384 +---------------------------------------------+ 385 | Info Type (1 octet) | 386 +---------------------------------------------+ 387 | Info Length (1 octet) | 388 +---------------------------------------------+ 389 | Info Value (variable) | 390 +---------------------------------------------+ 392 The Info Type field is a one-octet value that identifies the type of 393 additional information included in the Info Value field. This 394 specification defines a single (null) type of Additional_Info. The 395 Info Type for this null type is zero. 397 The Info Length field contains the length in octets of the Info Value 398 field. For the (null) Info Type zero specified in this document, the 399 Info Length MUST be zero. 401 The syntax and semantics contained in the Info Value field depends on 402 the type contained in the Info Type field. For the (null) Info Type 403 zero specified in this document, the Info Value field is empty (since 404 the Info Length field must be zero). 406 Implementations compliant with this specification MUST set the Info 407 Type to zero in BGPSEC update messages for route advertisements that 408 they originate (see Section 4.1 for more details). When an 409 implementation compliant with this specification receives a BGPSEC 410 update message with an Info Type field that it does not understand 411 (i.e., an Info Type other than zero), the implementation MUST use the 412 Additional_Info when it verifies digital signatures (as per Section 413 5.1). However, other than signature verification, the implementation 414 MUST ignore the Info Value field when it does not understand the Info 415 Type. 417 EDITOR'S NOTE: In a previous version of this document there was an 418 Expire Time that was used to provide protection against replay of old 419 (stale) digital signatures or failure to propagate a withdrawal 420 message. This mechanism was removed from the current version of the 421 document. Please see the SIDR mailing list for discussions related 422 to protection against replay attacks. Depending on the result of 423 discussions within the SIDR working group this Additional Info field 424 could at some future point be used to re-introduce Expire Time, or 425 some other octets used in a future replay protection mechanism. The 426 authors believe that the current instructions whereby the sender uses 427 a null Additional_Info type and the receiver ignores Additional_Info 428 types that it does not understand provides an opportunity to use 429 these octets in the future in a backwards-compatible fashion. 431 3.3. Signature_Block 433 Here we provide a detailed description of the Signature_Blocks in the 434 BGPSEC_Path_Signatures attribute. 436 Signature_Block 438 +---------------------------------------------+ 439 | Algorithm Suite Identifier (1 octet) | 440 +---------------------------------------------+ 441 | Signature_Block Length (2 octets) | 442 +---------------------------------------------+ 443 | Sequence of Signature Segments (variable) | 444 +---------------------------------------------+ 446 The Algorithm Suite Identifier is a one-octet identifier specifying 447 the digest algorithm and digital signature algorithm used to produce 448 the digital signature in each Signature Segment. An IANA registry of 449 algorithm identifiers for use in BGPSEC is created in the BGPSEC 450 algorithms document[12]. 452 The Signature_Block Length is the total number of octets in all 453 Signature Segments (i.e., the total size of the variable-length 454 portion of the Signature_Block.) 456 A Signature_Block has exactly one Signature Segment for each 457 Secure_Path Segment in the Secure_Path portion of the 458 BGPSEC_Path_Signatures Attribute. (That is, one Signature Segment 459 for each distinct AS on the path for the NLRI in the Update message.) 461 Signature Segments 462 +---------------------------------------------+ 463 | Subject Key Identifier (20 octets) | 464 +---------------------------------------------+ 465 | Signature Length (2 octets) | 466 +---------------------------------------------+ 467 | Signature (variable) | 468 +---------------------------------------------+ 470 The Subject Key Identifier contains the value in the Subject Key 471 Identifier extension of the RPKI end-entity certificate that is used 472 to verify the signature (see Section 5 for details on validity of 473 BGPSEC update messages). 475 The Signature Length field contains the size (in octets) of the value 476 in the Signature field of the Signature Segment. 478 The Signature contains a digital signature that protects the NLRI and 479 the BGPSEC_Path_Signatures attribute (see Sections 4 and 5 for 480 details on generating and verifying this signature, respectively). 482 4. Generating a BGPSEC Update 484 Sections 4.1 and 4.2 cover two cases in which a BGPSEC speaker may 485 generate an update message containing the BGPSEC_Path_Signatures 486 attribute. The first case is that in which the BGPSEC speaker 487 originates a new route advertisement (Section 4.1). That is, the 488 BGPSEC speaker is constructing an update message in which the only AS 489 to appear in the BGPSEC_Path_Signatures is the speaker's own AS. The 490 second case is that in which the BGPSEC speaker receives a route 491 advertisement from a peer and then decides to propagate the route 492 advertisement to an external (eBGP) peer (Section 4.2). That is, the 493 BGPSEC speaker has received a BGPSEC update message and is 494 constructing a new update message for the same NLRI in which the 495 BGPSEC_Path_Signatures attribute will contain AS number(s) other than 496 the speaker's own AS. 498 In the remaining case where the BGPSEC speaker is sending the update 499 message to an internal (iBGP) peer, the BGPSEC speaker populates the 500 BGPSEC_Path_Signatures attribute by copying the 501 BGPSEC_Path_Signatures attribute from the received update message. 502 That is, the BGPSEC_Path_Signatures attribute is copied verbatim. 503 Note that in the case that a BGPSEC speaker chooses to forward to an 504 iBGP peer a BGPSEC update message that has not been successfully 505 validated (see Section 5), the BGPSEC_Path_Signatures attribute 506 SHOULD NOT be removed. (See Section 7 for the security ramifications 507 of removing BGPSEC signatures.) 509 The information protected by the signature on a BGPSEC update message 510 includes the AS number of the peer to whom the update message is 511 being sent. Therefore, if a BGPSEC speaker wishes to send a BGPSEC 512 update to multiple BGP peers, it MUST generate a separate BGPSEC 513 update message for each unique peer AS to which the update message is 514 sent. 516 A BGPSEC update message MUST advertise a route to only a single NLRI. 517 This is because a BGPSEC speaker receiving an update message with 518 multiple NLRI would be unable to construct a valid BGPSEC update 519 message (i.e., valid path signatures) containing a subset of the NLRI 520 in the received update. If a BGPSEC speaker wishes to advertise 521 routes to multiple NLRI, then it MUST generate a separate BGPSEC 522 update message for each NLRI. 524 Note that in order to create or add a new signature to a BGPSEC 525 update message with a given algorithm suite, the BGPSEC speaker must 526 possess a private key suitable for generating signatures for this 527 algorithm suite. Additionally, this private key must correspond to 528 the public key in a valid Resource PKI end-entity certificate whose 529 AS number resource extension includes the BGPSEC speaker's AS number 530 [11]. Note also that new signatures are only added to a BGPSEC 531 update message when a BGPSEC speaker is generating an update message 532 to send to an external peer (i.e., when the AS number of the peer is 533 not equal to the BGPSEC speaker's own AS number). Therefore, a 534 BGPSEC speaker who only sends BGPSEC update messages to peers within 535 its own AS, it does not need to possess any private signature keys. 537 4.1. Originating a New BGPSEC Update 539 In an update message that originates a new route advertisement (i.e., 540 an update whose path will contain only a single AS number), when 541 sending the route advertisement to an external, BGPSEC-speaking peer, 542 the BGPSEC speaker creates a new BGPSEC_Path_Signatures attribute as 543 follows. 545 First, the BGPSEC speaker constructs the Secure_Path with a single 546 Secure_Path Segment. The AS in this path is the BGPSEC speaker's own 547 AS number. In particular, this AS number MUST match the AS number in 548 the AS number resource extension field of the Resource PKI end-entity 549 certificate(s) that will be used to verify the digital signature(s) 550 constructed by this BGPSEC speaker. 552 Note that the BGPSEC_Path_Signatures attribute and the AS4_Path 553 attribute are mutually exclusive. That is, any update message 554 containing the BGPSEC_Path_Signatures attribute MUST NOT contain the 555 AS4_Path attribute nor the AS_Path attribute. The information that 556 would be contained in the AS4_Path (or AS_Path) attribute is instead 557 conveyed in the Secure_Path portion of the BGPSEC_Path_Signatures 558 attribute. 560 Note that the Resource PKI enables the legitimate holder of IP 561 address prefix(es) to issue a signed object, called a Route 562 Origination Authorization (ROA), that authorizes a given AS to 563 originate routes to a given set of prefixes (see [7]). Note that 564 validation of a BGPSEC update message will fail (i.e., the validation 565 algorithm, specified in Section 5.1, returns 'Not Good') unless there 566 exists a valid ROA authorizing the first AS in the Secure_Path 567 portion of the BGPSEC_Path_Signatures attribute to originate routes 568 to the prefix being advertised. Therefore, a BGPSEC speaker SHOULD 569 NOT originate a BGPSEC update advertising a route for a given prefix 570 unless there exists a valid ROA authorizing the BGPSEC speaker's AS 571 to originate routes to this prefix. 573 The pCount field of the Secure_Path Segment is typically set to the 574 value 1. However, a BGPSEC speaker may set the pCount field to a 575 value greater than 1. Setting the pCount field to a value greater 576 than one has the same semantics as repeating an AS number multiple 577 times in the AS_PATH of a non-BGPSEC update message (e.g., for 578 traffic engineering purposes). Setting the pCount field to a value 579 greater than one permits this repetition without requiring a separate 580 digital signature for each repetition. 582 If the BGPSEC speaker is not a member of an autonomous system 583 confederation [3], then the Flags field of the Secure_Path Segment 584 MUST be set to zero. (Members of a confederation should follow the 585 special processing instructions for confederation members in Section 586 4.4.) 588 The BGPSEC speaker next constructs the Additional_Info portion of the 589 BGPSEC_Path_Signatures attribute. The Info Type MUST be set to zero 590 and the Info Length MUST also be set to zero. The Info Value field 591 is empty (has length zero). It is anticipated that future 592 specifications may specify values of Info Type other than zero. 593 Therefore, BGPSEC receivers compliant with this specification must be 594 able to accept Additional_Info fields with non-zero Info Type. Such 595 receivers will use the Additional_Field to verify digital signatures 596 (see Section 5) but will otherwise ignore Additional_Field non-zero 597 Info Fields. 599 Typically, a BGPSEC speaker will use only a single algorithm suite, 600 and thus create only a single Signature_Block in the 601 BGPSEC_Path_Signatures attribute. However, to ensure backwards 602 compatibility during a period of transition from a 'current' 603 algorithm suite to a 'new' algorithm suite, it will be necessary to 604 originate update messages that contain a Signature_Block for both the 605 'current' and the 'new' algorithm suites (see Section 6.1). 607 When originating a new route advertisement, each Signature_Block MUST 608 consist of a single Signature Segment. The following describes how 609 the BGPSEC speaker populates the fields of the Signature_Block. 611 The Subject Key Identifier field (see Section 3) is populated with 612 the identifier contained in the Subject Key Identifier extension of 613 the RPKI end-entity certificate used by the BGPSEC speaker. This 614 Subject Key Identifier will be used by recipients of the route 615 advertisement to identify the proper certificate to use in verifying 616 the signature. 618 The Signature field contains a digital signature that binds the NLRI 619 and BGPSEC_Path_Signatures attribute to the RPKI end-entity 620 certificate used by the BGPSEC speaker. The digital signature is 621 computed as follows: 623 o Construct a sequence of octets by concatenating the Target AS 624 Number, the Secure_Path (Origin AS, pCount, and Flags), the 625 Additional_Info (Info Type, Info Length, and Info Value), 626 Algorithm Suite Identifier, and NLRI. The Target AS Number is the 627 AS to whom the BGPSEC speaker intends to send the update message. 628 (Note that the Target AS number is the AS number announced by the 629 peer in the OPEN message of the BGP session within which the 630 update is sent.) 632 Sequence of Octets to be Signed 633 +------------------------------------+ 634 | Target AS Number (4 octets) | 635 +------------------------------------+ 636 | Origin AS Number (4 octets) | ---\ 637 +------------------------------------+ \ 638 | pCount (1 octet) | > Secure_Path 639 +------------------------------------+ / 640 | Flags (1 octet) | ---/ 641 +------------------------------------+ 642 | Info Type (1 octet) | ---\ 643 +------------------------------------+ \ 644 | Info Length (1 octet) | > Additional_Info 645 +------------------------------------+ / 646 | Info Value (variable) | ---/ 647 +------------------------------------+ 648 | Algorithm Suite Id. (1 octet) | 649 +------------------------------------+ 650 | NLRI Length (1 octet) | 651 +------------------------------------+ 652 | NLRI Prefix (variable) | 653 +------------------------------------+ 655 o Apply to this octet sequence the digest algorithm (for the 656 algorithm suite of this Signature_Block) to obtain a digest value. 658 o Apply to this digest value the signature algorithm, (for the 659 algorithm suite of this Signature_Block) to obtain the digital 660 signature. Then populate the Signature Field with this digital 661 signature. 663 The Signature Length field is populated with the length (in octets) 664 of the Signature field. 666 4.2. Propagating a Route Advertisement 668 When a BGPSEC speaker receives a BGPSEC update message containing a 669 BGPSEC_Path_Signatures attribute (with one or more signatures) from 670 an (internal or external) peer, it may choose to propagate the route 671 advertisement by sending to its (internal or external) peers by 672 creating a new BGPSEC advertisement for the same prefix. 674 If a BGPSEC router has received only non-BGPSEC update messages 675 (without the BGPSEC_Path_Signatures attribute), containing the 676 AS_Path attribute, from a peer for a given prefix and if it chooses 677 to propagate that peer's route for the prefix, then it MUST NOT 678 attach any BGPSEC_Path_Signatures attribute to the corresponding 679 update being propagated. (Note that a BGPSEC router may also receive 680 a non-BGPSEC update message from an internal peer without the AS_Path 681 attribute, i.e., with just the NLRI in it. In that case, the prefix 682 is originating from that AS and hence the BGPSEC speaker SHOULD sign 683 and forward the update to its external peers, as specified in Section 684 4.1.) 686 Conversely, if a BGPSEC router has received a BGPSEC update message 687 (with the BGPSEC_Path_Signatures attribute) from a peer for a given 688 prefix and it chooses to propagate that peer's route for the prefix, 689 then it SHOULD propagate the route as a BGPSEC update message 690 containing the BGPSEC_Path_Signatures attribute. However, the BGPSEC 691 speaker MAY propagate the route as a (unsigned) BGP update message 692 without the BGPSEC_Path_Signatures attribute. 694 Note that removing BGPSEC signatures (i.e., propagating a route 695 advertisement without the BGPSEC_Path_Signatures attribute) has 696 significant security ramifications. (See Section 7 for discussion of 697 the security ramifications of removing BGPSEC signatures.) 698 Therefore, when a route advertisement is received via a BGPSEC update 699 message, propagating the route advertisement without the 700 BGPSEC_Path_Signatures attribute is NOT RECOMMENDED. Furthermore, 701 note that when a BGPSEC speaker propagates a route advertisement with 702 the BGPSEC_Path_Signatures attribute it is not attesting to the 703 validation state of the update message it received. (See Section 7 704 for more discussion of the security semantics of BGPSEC signatures.) 706 If the BGPSEC speaker is producing an update message which would, in 707 the absence of BGPSEC, contain an AS_SET (e.g., the BGPSEC speaker is 708 performing proxy aggregation), then the BGPSEC speaker MUST NOT 709 include the BGPSEC_Path_Signatures attribute. In such a case, the 710 BGPSEC speaker must remove any existing BGPSEC_Path_Signatures in the 711 received advertisement(s) for this prefix and produce a standard 712 (non-BGPSEC) update message. It should be noted that BCP 172 [5] 713 recommends against the use of AS_SET and AS_CONFED_SET in AS_PATH in 714 BGP updates. 716 To generate the BGPSEC_Path_Signatures attribute on the outgoing 717 update message, the BGPSEC speaker first prepends a new Secure_Path 718 Segment (places in first position) to the Secure_Path. The AS number 719 in this Secure_Path segment MUST match the AS number in the AS number 720 resource extension field of the Resource PKI end-entity 721 certificate(s) that will be used to verify the digital signature(s) 722 constructed by this BGPSEC speaker. 724 The pCount is typically set to the value 1. A BGPSEC speaker may set 725 the pCount field to a value greater than 1. (See Section 4.1 for a 726 discussion of setting pCount to a value greater than 1.) A route 727 server that participates in the BGP control path, but does not act as 728 a transit AS in the data plane, may choose to set pCount to 0. This 729 option enables the route server to participate in BGPSEC and obtain 730 the associated security guarantees without increasing the effective 731 length of the AS path. (Note that BGPSEC speakers compute the 732 effective length of the AS path by summing the pCount values in the 733 BGPSEC_Path_Signatures attribute, see Section 5.) However, when a 734 route server sets the pCount value to 0, it still inserts its AS 735 number into the Secure_Path segment, as this information is needed to 736 validate the signature added by the route server. Note that the 737 option of setting pCount to 0 is intended only for use by route 738 servers that desire not to increase the effective AS-PATH length of 739 routes they advertise. The pCount field SHOULD NOT be set to 0 in 740 other circumstances. BGPSEC speakers SHOULD drop incoming update 741 messages with pCount set to zero in cases where the BGPSEC speaker 742 does not expect its peer to set pCount to zero (i.e., cases where the 743 peer is not acting as a route server). 745 If the BGPSEC speaker is not a member of an autonomous system 746 confederation [3], then the Flags field of the Secure_Path Segment 747 MUST be set to zero. (Members of a confederation should follow the 748 special processing instructions for confederation members in Section 749 4.4.) 751 The BGPSEC speaker next copies the Additional_Info portion of the 752 BGPSEC_Path_Signatures directly from the received update message to 753 the new update message (that it is constructing). Note that the 754 BGPSEC speaker MUST NOT change the Additional_Info as any change to 755 Additional_Info will cause the new BGPSEC update message to fail 756 validation (see Section 5). 758 If the received BGPSEC update message contains two Signature_ Blocks 759 and the BGPSEC speaker supports both of the corresponding algorithms 760 suites, then the new update message generated by the BGPSEC speaker 761 SHOULD include both of the Signature_Blocks. If the received BGPSEC 762 update message contains two Signature_Blocks and the BGPSEC speaker 763 only supports one of the two corresponding algorithm suites, then the 764 BGPSEC speaker MUST remove the Signature_Block corresponding to the 765 algorithm suite that it does not understand. If the BGPSEC speaker 766 does not support the algorithm suites in any of the Signature_Blocks 767 contained in the received update message, then the BGPSEC speaker 768 MUST NOT propagate the route advertisement with the 769 BGPSEC_Path_Signatures attribute (i.e., propagate it as an unsigned 770 BGP update message). 772 Note that in the case where there are two Signature_Blocks 773 (corresponding to different algorithm suites) that the validation 774 algorithm (see Section 5.1) deems a BGPSEC update message to be 775 'Good' if there is at least one supported algorithm suite (and 776 corresponding Signature_Block) that is deemed 'Good'. This means 777 that a 'Good' BGPSEC update message may contain a Signature_Block 778 which is not deemed 'Good' (e.g., contains signatures that the BGPSEC 779 does not successfully verify). Nonetheless, such Signature_Blocks 780 MUST NOT be removed. (See Section 7 for a discussion of the security 781 ramifications of this design choice.) 783 For each Signature_Block corresponding to an algorithm suite that the 784 BGPSEC speaker does support, the BGPSEC speaker then adds a new 785 Signature Segment to the Signature_Block. This Signature Segment is 786 prepended to the list of Signature Segments (placed in the first 787 position) so that the list of Signature Segments appears in the same 788 order as the corresponding Secure_Path segments in the Secure_Path 789 portion of the BGPSEC_Path_Signatures attribute. The BGPSEC speaker 790 populates the fields of this new signature segment as follows. 792 The Subject Key Identifier field in the new segment is populated with 793 the identifier contained in the Subject Key Identifier extension of 794 the RPKI end-entity certificate used by the BGPSEC speaker. This 795 Subject Key Identifier will be used by recipients of the route 796 advertisement to identify the proper certificate to use in verifying 797 the signature. 799 The Signature field in the new segment contains a digital signature 800 that binds the NLRI and BGPSEC_Path_Signatures attribute to the RPKI 801 end-entity certificate used by the BGPSEC speaker. The digital 802 signature is computed as follows: 804 o Construct a sequence of octets by concatenating the Target AS 805 number, the Secure_Path segment that is being added by the BGPSEC 806 speaker constructing the signature, and the signature field of the 807 most recent Signature Segment (the one corresponding to AS from 808 whom the BGPSEC speaker's AS received the announcement). Note 809 that the Target AS number is the AS number announced by the peer 810 in the OPEN message of the BGP session within which the BGPSEC 811 update message is sent. 813 Sequence of Octets to be Signed 814 +--------------------------------------+ 815 | Target AS Number (4 octets) | 816 +--------------------------------------+ 817 | Signer's AS Number (4 octets) | ---\ 818 +--------------------------------------+ \ 819 | pCount (1 octet) | > Secure_Path 820 +--------- ----------------------------+ / 821 | Flags (1 octet) | ---/ 822 +--------------------------------------+ 823 | Most Recent Sig Field (variable) | 824 +--------------------------------------+ 826 o Apply to this octet sequence the digest algorithm (for the 827 algorithm suite of this Signature_Block) to obtain a digest value. 829 o Apply to this digest value the signature algorithm, (for the 830 algorithm suite of this Signature_Block) to obtain the digital 831 signature. Then populate the Signature Field with this digital 832 signature. 834 The Signature Length field is populated with the length (in octets) 835 of the Signature field. 837 4.3. Reconstructing the AS_Path Attribute 839 EDITOR'S NOTE: This is a place-holder section. Given that BGPSEC 840 update messages do not contain the AS_Path attribute, this document 841 needs to include a clearly specified algorithm for reconstructing the 842 AS_Path attribute from the data in the BGPSEC_Path_Signatures 843 attribute. (For example, when propagating a path received via BGPSEC 844 to a non-BGPSEC peer.) This algorithm for reconstructing the AS_Path 845 will appear in the next version of this document. In essence, the 846 algorithm is: For each Secure_Path Segment put into the AS_Path 847 pCount copies of the AS number field of the segment --- and if you 848 see the Entering_Confed flag is set to one, then add an 849 AS_Confed_Sequence to the AS_Path. 851 4.4. Processing Instructions for Confederation Members 853 Members of autonomous system confederations [3] must additionally 854 follow the instructions in this section for processing BGPSEC update 855 messages. 857 When a confederation member sends a BGPSEC update message to a peer 858 who is a member of the same confederation, the confederation member 859 puts its (private) Member-AS Number (as opposed to the public AS 860 Confederation Identifier) in the AS Number field of the Secure_Path 861 Segment that it adds to the BGPSEC update message. 863 Furthermore, when sending a BGPSEC update message to a peer who is a 864 member of the same confederation, the first confederation member to 865 add a Secure_Path Segment to a BGPSEC update message sets the 866 Entering_Cofed flag in the Flags field to be one in the Secure_Path 867 Segment that it produces. In the case where the route advertisement 868 originates within a confederation, the member AS that originates the 869 route and sends it to a peer is the member AS that sets its 870 Entering_Confed flag to one. In the case where the route 871 advertisement is received from outside the confederation, it is the 872 member AS that receives the route advertisement from a peer outside 873 the confederation and propagates it to a peer inside the 874 confederation that sets its Entering_Confed flag to one. Note that 875 this is the same of the confederation member who would have added a 876 new AS_Path segment of type AS_Confed_Sequence to the AS_Path 877 attribute in a non-BGPSEC update message. 879 When a confederation member receives a BGPSEC update message from a 880 peer within the confederation and propagates it to a peer outside the 881 confederation, it must remove all of the Secure_Path Segments added 882 by confederation members as well as the corresponding Signature 883 Segments. To do this, the confederation member propagating the route 884 outside the confederation does the following: 886 o First, search through the Secure_Path, going from most recently 887 added segment to least recently added segment, and find first 888 Secure_Path Segment with the Entering_Confed flag to set to one. 889 (That is, of all the Secure_Path Segments with the Entering_Confed 890 flag set to one, find the one that was most recently added.) 892 o Second, remove the Secure_Path Segment found in previous step 893 along with all more recently added Secure_Path Segments. Keep a 894 count of the number of segments removed in this fashion. 896 o Third, starting with the most recently added Signature Segment, 897 remove a number of Signature Segments equal to the number of 898 Secure_Path Segments removed in the previous step. (That is, 899 remove the K most recently added signature segments, where K is 900 the number of Secure_Path Segments removed in the previous step.) 902 o Finally, add a Secure_Path Segment containing, in the AS field, 903 the AS Confederation Identifier (the public AS number of the 904 confederation) as well as a corresponding Signature Segment. Note 905 that all fields other that the AS field are populated as per 906 Sections 4.1 and 4.2. 908 When validating a received BGPSEC update message, confederation 909 members must make the following adjustment to the algorithm presented 910 in Section 5.1. That is, when a confederation member is processing 911 (validating) a Signature Segment and its corresponding Secure_Path 912 Segment, the confederation member must note that when a signature is 913 produced by a BGPSEC speaker outside of a confederation, the Target 914 AS will always be the AS Confederation Identifier (the public AS 915 number of the confederation) as opposed to the Member-AS Number. To 916 handle this case, when processing a current Secure_Path Segment, if 917 the next most recently added Secure_Path segment has the 918 Entering_Confed flag set then ,when computing the digest for the 919 current Secure_Path segment, take the Target AS Number to be the AS 920 Confederation Identifier of the validating BGPSEC speaker's own 921 confederation. (Note that the algorithm in Section 5.1 processes 922 Secure_Path Segments in order from most recently added to least 923 recently added, therefore the algorithm encounters the 924 Entering_Confed flag immediately before it encounters the Secure_Path 925 segment that requires using the AS Confederation Identifier to 926 validate.) 928 5. Processing a Received BGPSEC Update 930 Validation of a BGPSEC update messages makes use of data from RPKI 931 certificates and signed Route Origination Authorizations (ROA). In 932 particular, to validate update messages containing the 933 BGPSEC_Path_Signatures attribute, it is necessary that the recipient 934 have access to the following data obtained from valid RPKI 935 certificates and ROAs: 937 o For each valid RPKI end-entity certificate containing an AS Number 938 extension, the AS Number, Public Key and Subject Key Identifier 939 are required, 941 o For each valid ROA, the AS Number and the list of IP address 942 prefixes. 944 Note that the BGPSEC speaker could perform the validation of RPKI 945 certificates and ROAs on its own and extract the required data, or it 946 could receive the same data from a trusted cache that performs RPKI 947 validation on behalf of (some set of) BGPSEC speakers. (The latter 948 case in analogous to the use of the RPKI-RTR protocol [13] for origin 949 validation.) 951 To validate a BGPSEC update message containing the 952 BGPSEC_Path_Signatures attribute, the recipient performs the 953 validation steps specified in Section 5.1. The validation procedure 954 results in one of two states: 'Good' and 'Not Good'. 956 It is expected that the output of the validation procedure will be 957 used as an input to BGP route selection. However, BGP route 958 selection and thus the handling of the two validation states is a 959 matter of local policy, and shall be handled using existing local 960 policy mechanisms. It is expected that BGP peers will generally 961 prefer routes received via 'Good' BGPSEC update messages over routes 962 received via 'Not Good' BGPSEC update messages as well as routes 963 received via update messages that do not contain the 964 BGPSEC_Path_Signatures attribute. However, BGPSEC specifies no 965 changes to the BGP decision process and leaves to the operator the 966 selection of an appropriate policy mechanism to achieve the 967 operator's desired results within the BGP decision process. 969 BGPSEC validation needs only be performed at eBGP edge. The 970 validation status of a BGP signed/unsigned update MAY be conveyed via 971 iBGP from an ingress edge router to an egress edge router. Local 972 policy in the AS determines the specific means for conveying the 973 validation status through various pre-existing mechanisms (e.g., 974 modifying an attribute). As discussed in Section 4, when a BGPSEC 975 speaker chooses to forward a (syntactically correct) BGPSEC update 976 message, it SHOULD be forwarded with its BGPSEC_Path_Signatures 977 attribute intact (regardless of the validation state of the update 978 message). Based entirely on local policy settings, an egress router 979 MAY trust the validation status conveyed by an ingress router or it 980 MAY perform its own validation. 982 Upon receiving a BGPSEC update message, a BGPSEC speaker SHOULD sum 983 the pCount values within BGPSEC_Path_Signatures attribute to 984 determine the effective length of the AS Path. The BGPSEC speaker 985 SHOULD use this sum of pCount values in precisely the same way as it 986 uses the length of the AS Path in non-BGPSEC update messages. 988 5.1. Validation Algorithm 990 This section specifies an algorithm for validation of BGPSEC update 991 messages. A conformant implementation MUST include a BGPSEC update 992 validation algorithm that is functionally equivalent to the external 993 behavior of this algorithm. 995 First, the recipient of a BGPSEC update message performs a check to 996 ensure that the message is properly formed. Specifically, the 997 recipient performs the following checks: 999 o Check to ensure that the entire BGPSEC_Path_Signatures attribute 1000 is syntactically correct (conforms to the specification in this 1001 document). 1003 o Check that each Signature_Block contains one Signature segment for 1004 each Secure_Path segment in the Secure_Path portion of the 1005 BGPSEC_Path_Signatures attribute. (Note that the entirety of each 1006 Signature_Block must be checked to ensure that it is well formed, 1007 even though the validation process may terminate before all 1008 signatures are cryptographically verified.) 1010 If there are two Signature_Blocks within the BGPSEC_Path_Signatures 1011 attribute and one of them is poorly formed (or contains the wrong 1012 number of Signature segments) , then the recipient should log that an 1013 error occurred, strip off that particular Signature_Block and process 1014 the update message as though it arrived with a single 1015 Signature_Block. If the BGPSEC_Path_Signatures attribute contains a 1016 syntax error that is not local to one of two Signature_Blocks, then 1017 the recipient should log that an error occurred and drop the update 1018 message containing the error. Similarly, if an update message 1019 contains both the BGPSEC_Path_Signatures attribute and either an 1020 AS_Path or AS4_Path attribute, then the recipient should log that an 1021 error occurred and drop the update message containing the error. 1023 Next, the BGPSEC speaker verifies that the origin AS is authorized to 1024 advertise the prefix in question. To do this, consult the valid ROA 1025 data to obtain a list of AS numbers that are associated with the 1026 given IP address prefix in the update message. Then locate the last 1027 (least recently added) AS number in the Secure_Path portion of the 1028 BGPSEC_Path_Signatures attribute. If the origin AS in the 1029 Secure_Path is not in the set of AS numbers associated with the given 1030 prefix, then the BGPSEC update message is 'Not Good' and the 1031 validation algorithm terminates. 1033 Finally, the BGPSEC speaker examines the Signature_Blocks in the 1034 BGPSEC_Path_Signatures attribute. A Signature_Block corresponding to 1035 an algorithm suite that the BGPSEC speaker does not support is not 1036 considered in validation. If there does not exist a Signature_Block 1037 corresponding to an algorithm suite that the BGPSEC speaker supports, 1038 then the BGPSEC speaker MUST treat the update message in the same 1039 manner that the BGPSEC speaker would treat an (unsigned) update 1040 message that arrived without a BGPSEC_Path_Signatures attribute. 1042 For each remaining Signature_Block (corresponding to an algorithm 1043 suite supported by the BGPSEC speaker), the BGPSEC speaker iterates 1044 through the Signature segments in the Signature_Block, starting with 1045 the most recently added segment (and concluding with the least 1046 recently added segment). Note that there is a one-to-one 1047 correspondence between Signature segments and Secure_Path segments 1048 within the BGPSEC_Path_Signatures attribute. The following steps 1049 make use of this correspondence. 1051 o (Step I): Locate the public key needed to verify the signature (in 1052 the current Signature segment). To do this, consult the valid 1053 RPKI end-entity certificate data and look up all valid (AS, SKI, 1054 Public Key) triples in which the AS matches the AS number in the 1055 corresponding Secure_Path segment. Of these triples that match 1056 the AS number, check whether there is an SKI that matches the 1057 value in the Subject Key Identifier field of the Signature 1058 segment. If this check finds no such matching SKI value, then 1059 mark the entire Signature-List Block as 'Not Good' and proceed to 1060 the next Signature-List Block. 1062 o (Step II): Compute the digest function (for the given algorithm 1063 suite) on the appropriate data. If the segment is not the (least 1064 recently added) segment corresponding to the origin AS, then the 1065 digest function should be computed on the following sequence of 1066 octets: 1068 Sequence of Octets to be Hashed 1070 +-------------------------------------------+ 1071 | AS Number of Target AS (4 octets) | 1072 +-------------------------------------------+ 1073 | AS Number (4 octets) | ---\ 1074 +-------------------------------------------+ \ 1075 | pCount (1 octet) | > Secure_Path 1076 +-------------------------------------------+ / 1077 | Flags (1 octet) | ---/ 1078 +-------------------------------------------+ 1079 | Sig Field in the Next Segment (variable) | 1080 +-------------- ----------------------------+ 1082 For the first segment to be processed (the most recently added 1083 segment), the 'AS Number of Target AS' is the AS number of the BGPSEC 1084 speaker validating the update message. Note that if a BGPSEC speaker 1085 uses multiple AS Numbers (e.g., the BGPSEC speaker is a member of a 1086 confederation), the AS number used here MUST be the AS number 1087 announced in the OPEN message for the BGP session over which the 1088 BGPSEC update was received. 1090 For each other Signature Segment, the 'AS Number of Target AS' is the 1091 AS number in the Secure_Path segment that corresponds to the 1092 Signature Segment added immediately after the one being processed. 1093 (That is, in the Secure_Path segment that corresponds to the 1094 Signature segment that the validator just finished processing.) 1095 The AS Number, pCount and Flags fields are taken from the Secure_Path 1096 segment that corresponds to the Signature segment currently being 1097 processed. The 'Signature Field in the Next Segment' is the 1098 Signature field found in the Signature segment that is next to be 1099 processed (that is, the next most recently added Signature Segment). 1101 Alternatively, if the segment being processed corresponds to the 1102 origin AS (i.e., if it is the least recently added segment), then the 1103 digest function should be computed on the following sequence of 1104 octets: 1106 Sequence of Octets to be Hashed 1107 +------------------------------------+ 1108 | AS Number of Target AS (4 octets) | 1109 +------------------------------------+ 1110 | Origin AS Number (4 octets) | ---\ 1111 +------------------------------------+ \ 1112 | pCount (1 octet) | > Secure_Path 1113 +------------------------------------+ / 1114 | Flags (1 octet) | ---/ 1115 +------------------------------------+ 1116 | Info Type (1 octet) | ---\ 1117 +------------------------------------+ \ 1118 | Info Length (1 octet) | > Additional_Info 1119 +------------------------------------+ / 1120 | Info Value (variable) | ---/ 1121 +------------------------------------+ 1122 | Algorithm Suite Id. (1 octet) | 1123 +------------------------------------+ 1124 | NLRI Length (1 octet) | 1125 +------------------------------------+ 1126 | NLRI Prefix (variable) | 1127 +------------------------------------+ 1129 The NLRI Length, NLRI Prefix, Additional_Info, and Algorithm Suite 1130 Identifier are all obtained in a straight forward manner from the 1131 NLRI of the update message or the BGPSEC_Path_Signatures attribute 1132 being validated. The Origin AS Number, pCount, and Flags fields are 1133 taken from the Secure_Path segment corresponding to the Signature 1134 Segment currently being processed. 1136 The 'AS Number of Target AS' is the AS Number from the Secure_Path 1137 segment that was added immediately after the Secure_Path segment 1138 containing the Origin AS Number. (That is, the Secure_Path segment 1139 corresponding to the Signature segment that the receiver just 1140 finished processing prior to the current Signature segment.) 1141 o (Step III): Use the signature validation algorithm (for the given 1142 algorithm suite) to verify the signature in the current segment. 1143 That is, invoke the signature validation algorithm on the 1144 following three inputs: the value of the Signature field in the 1145 current segment; the digest value computed in Step II above; and 1146 the public key obtained from the valid RPKI data in Step I above. 1147 If the signature validation algorithm determines that the 1148 signature is invalid, then mark the entire Signature-List Block as 1149 'Not Good' and proceed to the next Signature_Block. If the 1150 signature validation algorithm determines that the signature is 1151 valid, then continue processing Signature-Segments (within the 1152 current Signature-List Block). 1154 If all Signature-Segments within a Signature-List Block pass 1155 validation (i.e., all segments are processed and the Signature-List 1156 Block has not yet been marked 'Not Good'), then the Signature_Block 1157 is marked as 'Good'. 1159 If at least one Signature_Block is marked as 'Good', then the 1160 validation algorithm terminates and the BGPSEC update message is 1161 deemed to be 'Good'. (That is, if a BGPSEC update message contains 1162 two Signature_Blocks then the update message is deemed 'Good' if the 1163 first Signature_Block is marked 'Good' OR the second Signature_Block 1164 is marked 'Good'.) 1166 6. Algorithms and Extensibility 1168 6.1. Algorithm Suite Considerations 1170 Note that there is currently no support for bilateral negotiation 1171 between BGPSEC peers to use of a particular (digest and signature) 1172 algorithm suite using BGP capabilities. This is because the 1173 algorithm suite used by the sender of a BGPSEC update message must be 1174 understood not only by the peer to whom he is directly sending the 1175 message, but also by all BGPSEC speakers to whom the route 1176 advertisement is eventually propagated. Therefore, selection of an 1177 algorithm suite cannot be a local matter negotiated by BGP peers, but 1178 instead must be coordinated throughout the Internet. 1180 To this end, a mandatory algorithm suites document will be created 1181 which specifies a mandatory-to-use 'current' algorithm suite for use 1182 by all BGPSEC speakers [12]. Additionally, the document specifies an 1183 additional 'new' algorithm suite that is recommended to implement. 1185 It is anticipated that in the future the mandatory algorithm suites 1186 document will be updated to specify a transition from the 'current' 1187 algorithm suite to the 'new' algorithm suite. During the period of 1188 transition (likely a small number of years), all BGPSEC update 1189 messages SHOULD simultaneously use both the 'current' algorithm suite 1190 and the 'new' algorithm suite. (Note that Sections 3 and 4 specify 1191 how the BGPSEC_Path_Signatures attribute can contain signatures, in 1192 parallel, for two algorithm suites.) Once the transition is 1193 complete, use of the old 'current' algorithm will be deprecated, use 1194 of the 'new' algorithm will be mandatory, and a subsequent 'even 1195 newer' algorithm suite may be specified as recommend to implement. 1196 Once the transition has successfully been completed in this manner, 1197 BGPSEC speakers SHOULD include only a single Signature_Block 1198 (corresponding to the 'new' algorithm). 1200 6.2. Extensibility Considerations 1202 This section discusses potential changes to BGPSEC that would require 1203 substantial changes to the processing of the BGPSEC_Path_Signatures 1204 and thus necessitate a new version of BGPSEC. Examples of such 1205 changes include: 1207 o A new type of signature algorithm that produces signatures of 1208 variable length 1210 o A new type of signature algorithm for which the number of 1211 signatures in the Signature_Block is not equal to the number of 1212 ASes in the Secure_Path (e.g., aggregate signatures) 1214 o Changes to the data that is protected by the BGPSEC signatures 1215 (e.g., attributes other than the AS path) 1217 In the case that such a change to BGPSEC were deemed desirable, it is 1218 expected that a subsequent version of BGPSEC would be created and 1219 that this version of BGPSEC would specify a new BGP Path Attribute, 1220 let's call it BGPSEC_PATH_SIG_TWO, which is designed to accommodate 1221 the desired changes to BGPSEC. In such a case, the mandatory 1222 algorithm suites document would be updated to specify algorithm 1223 suites appropriate for the new version of BGPSEC. 1225 At this point a transition would begin which is analogous to the 1226 algorithm transition discussed in Section 6.2. During the transition 1227 period all BGPSEC speakers SHOULD simultaneously include both the 1228 BGPSEC_PATH_SIGNATURES attribute and the new BGPSEC_PATH_SIG_TWO 1229 attribute. Once the transition is complete, the use of 1230 BGPSEC_PATH_SIGNATURES could then be deprecated, at which point 1231 BGPSEC speakers SHOULD include only the new BGPSEC_PATH_SIG_TWO 1232 attribute. Such a process could facilitate a transition to a new 1233 BGPSEC semantics in a backwards compatible fashion. 1235 7. Security Considerations 1237 For discussion of the BGPSEC threat model and related security 1238 considerations, please see [10]. 1240 A BGPSEC speaker who receives a valid BGPSEC update message, 1241 containing a route advertisement for a given prefix, is provided with 1242 the following security guarantees: 1244 o The origin AS number corresponds to an autonomous system that has 1245 been authorized by the IP address space holder to originate route 1246 advertisements for the given prefix. 1248 o For each AS number in the AS Path, a BGPSEC speaker authorized by 1249 the holder of the AS number intentionally chose (in accordance 1250 with local policy) to propagate the route advertisement to the 1251 next AS in the Secure_Path. 1253 That is, the recipient of a valid BGPSEC Update message is assured 1254 that the Secure_Path corresponds to a sequence of autonomous systems 1255 who have all agreed in principle to forward packets to the given 1256 prefix along the indicated path. (It should be noted that BGPSEC 1257 does not offer a precise guarantee that the data packets would 1258 propagate along the indicated path; it only guarantees that the BGP 1259 update conveying the path indeed propagated along the indicated 1260 path.) Furthermore, the recipient is assured that this path 1261 terminates in an autonomous system that has been authorized by the IP 1262 address space holder as a legitimate destination for traffic to the 1263 given prefix. 1265 Note that although BGPSEC provides a mechanism for an AS to validate 1266 that a received update message has certain security properties, the 1267 use of such a mechanism to influence route selection is completely a 1268 matter of local policy. Therefore, a BGPSEC speaker can make no 1269 assumptions about the validity of a route received from an external 1270 BGPSEC peer. That is, a compliant BGPSEC peer may (depending on the 1271 local policy of the peer) send update messages that fail the validity 1272 test in Section 5. Thus, a BGPSEC speaker MUST completely validate 1273 all BGPSEC update messages received from external peers. (Validation 1274 of update messages received from internal peers is a matter of local 1275 policy, see Section 5). 1277 Note that there may be cases where a BGPSEC speaker deems 'Good' (as 1278 per the validation algorithm in Section 5.1) a BGPSEC update message 1279 that contains both a 'Good' and a 'Not Good' Signature_Block. That 1280 is, the update message contains two sets of signatures corresponding 1281 to two algorithm suites, and one set of signatures verifies correctly 1282 and the other set of signatures fails to verify. In this case, the 1283 protocol specifies that if the BGPSEC speaker propagates the route 1284 advertisement received in such an update message then the BGPSEC 1285 speaker SHOULD add its signature to each of the Signature_Blocks 1286 using both the corresponding algorithm suite. Thus the BGPSEC 1287 speaker creates a signature using both algorithm suites and creates a 1288 new update message that contains both the 'Good' and the 'Not Good' 1289 set of signatures (from its own vantage point). 1291 To understand the reason for such a design decision consider the case 1292 where the BGPSEC speaker receives an update message with both a set 1293 of algorithm A signatures which are 'Good' and a set of algorithm B 1294 signatures which are 'Not Good'. In such a case it is possible 1295 (perhaps even quite likely) that some of the BGPSEC speaker's peers 1296 (or other entities further 'downstream' in the BGP topology) do not 1297 support algorithm A. Therefore, if the BGPSEC speaker were to remove 1298 the 'Not Good' set of signatures corresponding to algorithm B, such 1299 entities would treat the message as though it were unsigned. By 1300 including the 'Not Good' set of signatures when propagating a route 1301 advertisement, the BGPSEC speaker ensures that 'downstream' entities 1302 have as much information as possible to make an informed opinion 1303 about the validation status of a BGPSEC update. 1305 Note also that during a period of partial BGPSEC deployment, a 1306 'downstream' entity might reasonably treat unsigned messages 1307 different from BGPSEC updates that contain a single set of 'Not Good' 1308 signatures. That is, by removing the set of 'Not Good' signatures 1309 the BGPSEC speaker might actually cause a downstream entity to 1310 'upgrade' the status of a route advertisement from 'Not Good' to 1311 unsigned. Finally, note that in the above scenario, the BGPSEC 1312 speaker might have deemed algorithm A signatures 'Good' only because 1313 of some issue with RPKI state local to his AS (for example, his AS 1314 might not yet have obtained a CRL indicating that a key used to 1315 verify an algorithm A signature belongs to a newly revoked 1316 certificate). In such a case, it is highly desirable for a 1317 downstream entity to treat the update as 'Not Good' (due to the 1318 revocation) and not as 'unsigned' (which would happen if the 'Not 1319 Good' Signature_Blocks were removed). 1321 A similar argument applies to the case where a BGPSEC speaker (for 1322 some reason such as lack of viable alternatives) selects as his best 1323 route to a given prefix a route obtained via a 'Not Good' BGPSEC 1324 update message. (That is, a BGPSEC update containing only 'Not Good' 1325 Signature-List Blocks.) In such a case, the BGPSEC speaker should 1326 propagate a signed BGPSEC update message, adding his signature to the 1327 'Not Good' signatures that already exist. Again, this is to ensure 1328 that 'downstream' entities are able to make an informed decision and 1329 not erroneously treat the route as unsigned. It may also be noted 1330 here that due to possible differences in RPKI data at different 1331 vantage points in the network, a BGPSEC update that was deemed 'Not 1332 Good' at an upstream BGPSEC speaker may indeed be deemed 'Good' at 1333 another BGP speaker downstream. 1335 Therefore, it is important to note that when a BGPSEC speaker signs 1336 an outgoing update message, it is not attesting to a belief that all 1337 signatures prior to its are valid. Instead it is merely asserting 1338 that: 1340 o The BGPSEC speaker received the given route advertisement with the 1341 indicated NLRI and Secure_Path; and 1343 o The BGPSEC speaker chose to propagate an advertisement for this 1344 route to the peer (implicitly) indicated by the 'Target AS' 1346 The BGPSEC update validation procedure is a potential target for 1347 denial of service attacks against a BGPSEC speaker. To mitigate the 1348 effectiveness of such denial of service attacks, BGPSEC speakers 1349 should implement an update validation algorithm that performs 1350 expensive checks (e.g., signature verification) after performing less 1351 expensive checks (e.g., syntax checks). The validation algorithm 1352 specified in Section 5.1 was chosen so as to perform checks which are 1353 likely to be expensive after checks that are likely to be 1354 inexpensive. However, the relative cost of performing required 1355 validation steps may vary between implementations, and thus the 1356 algorithm specified in Section 5.1 may not provide the best denial of 1357 service protection for all implementations. 1359 The mechanism of setting the pCount field to zero is included in this 1360 specification to enable route servers in the control path to 1361 participate in BGPSEC without increasing the effective length of the 1362 AS-PATH. However, entities other than route servers could 1363 conceivably use this mechanism (set the pCount to zero) to attract 1364 traffic (by reducing the effective length of the AS-PATH) 1365 illegitimately. This risk is largely mitigated if every BGPSEC 1366 speaker drops incoming update messages that set pCount to zero but 1367 come from a peer that is not a route server. However, note that a 1368 recipient of a BGPSEC update message in which an upstream entity that 1369 is two or more hops away set pCount to zero is unable to verify for 1370 themselves whether pCount was set to zero legitimately. 1372 Finally, BGPSEC does not provide protection against all attacks at 1373 the transport layer. An adversary on the path between a BGPSEC 1374 speaker and its peer is able to perform attacks such as modifying 1375 valid BGPSEC updates to cause them to fail validation, injecting 1376 (unsigned) BGP update messages without BGPSEC_Path_Signature 1377 attributes, or injecting BGPSEC update messages with 1378 BGPSEC_Path_Signature attributes that fail validation, or causing the 1379 peer to tear-down the BGP session. Therefore, BGPSEC implementations 1380 MUST support appropriate transport security mechanisms. 1382 EDITOR'S NOTE: Do we want to mandate a specific transport security 1383 mechanism (e.g., TCP-AO)? 1385 8. Contributors 1387 8.1. Authors 1389 Rob Austein 1390 Dragon Research Labs 1391 sra@hactrn.net 1393 Steven Bellovin 1394 Columbia University 1395 smb@cs.columbia.edu 1397 Randy Bush 1398 Internet Initiative Japan 1399 randy@psg.com 1401 Russ Housley 1402 Vigil Security 1403 housley@vigilsec.com 1405 Matt Lepinski 1406 BBN Technologies 1407 lepinski@bbn.com 1409 Stephen Kent 1410 BBN Technologies 1411 kent@bbn.com 1413 Warren Kumari 1414 Google 1415 warren@kumari.net 1417 Doug Montgomery 1418 USA National Institute of Standards and Technology 1419 dougm@nist.gov 1421 Kotikalapudi Sriram 1422 USA National Institute of Standards and Technology 1423 kotikalapudi.sriram@nist.gov 1425 Samuel Weiler 1426 Cobham 1427 weiler+ietf@watson.org 1429 8.2. Acknowledgements 1431 The authors would like to thank Luke Berndt, Sharon Goldberg, Ed 1432 Kern, Chris Morrow, Doug Maughan, Pradosh Mohapatra, Russ Mundy, 1433 Sandy Murphy, Keyur Patel, Mark Reynolds, Heather Schiller, Jason 1434 Schiller, John Scudder, Ruediger Volk and David Ward for their 1435 valuable input and review. 1437 9. Normative References 1439 [1] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 1440 Gateway Protocol 4", RFC 4271, January 2006. 1442 [2] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1443 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 1445 [3] Traina, P., McPherson, D., and J. Scudder, "Autonomous System 1446 Confederations for BGP", RFC 5065, August 2007. 1448 [4] Scudder, J. and R. Chandra, "Capabilities Advertisement with 1449 BGP-4", RFC 5492, February 2009. 1451 [5] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET 1452 and AS_CONFED_SET in BGP", RFC 6472, December 2011. 1454 [6] Lepinski, M. and S. Kent, "Recommendation for Not Using AS_SET 1455 and AS_CONFED_SET in BGP", RFC 6480, February 2012. 1457 [7] Lepinski, M., Kent, S., and D. Kong, "Recommendation for Not 1458 Using AS_SET and AS_CONFED_SET in BGP", RFC 6482, 1459 February 2012. 1461 [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1462 Levels", BCP 14, RFC 2119, March 1997. 1464 [9] Patel, K., Ward, D., and R. Bush, "Extended Message support for 1465 BGP", March 2011. 1467 [10] Kent, S., "Threat Model for BGP Path Security", February 2012. 1469 [11] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPSEC 1470 Router Certificates, Certificate Revocation Lists, and 1471 Certification Requests", December 2011. 1473 [12] Turner, S., "BGP Algorithms, Key Formats, & Signature Formats", 1474 March 2012. 1476 [13] Bush, R. and R. Austein, "The RPKI/Router Protocol", 1477 February 2012. 1479 Author's Address 1481 Matthew Lepinski (editor) 1482 BBN 1483 10 Moulton St 1484 Cambridge, MA 55409 1485 US 1487 Phone: +1 617 873 5939 1488 Email: mlepinski@bbn.com