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