idnits 2.17.1 draft-ietf-sidr-bgpsec-protocol-23.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (April 27, 2017) is 2527 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) == Missing Reference: 'This RFC' is mentioned on line 1773, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AF' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-14 == Outdated reference: A later version (-08) exists of draft-ietf-sidr-slurm-04 == Outdated reference: A later version (-04) exists of draft-ietf-sidrops-bgpsec-rollover-00 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 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 NCF 4 Intended status: Standards Track K. Sriram, Ed. 5 Expires: October 29, 2017 NIST 6 April 27, 2017 8 BGPsec Protocol Specification 9 draft-ietf-sidr-bgpsec-protocol-23 11 Abstract 13 This document describes BGPsec, an extension to the Border Gateway 14 Protocol (BGP) that provides security for the path of autonomous 15 systems (ASes) through which a BGP update message passes. BGPsec is 16 implemented via an optional non-transitive BGP path attribute that 17 carries digital signatures produced by each autonomous system that 18 propagates the update message. The digital signatures provide 19 confidence that every AS on the path of ASes listed in the update 20 message has explicitly authorized the advertisement of the route. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 29, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. BGPsec Negotiation . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. The BGPsec Capability . . . . . . . . . . . . . . . . . . 4 60 2.2. Negotiating BGPsec Support . . . . . . . . . . . . . . . 5 61 3. The BGPsec_Path Attribute . . . . . . . . . . . . . . . . . . 6 62 3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.2. Signature_Block . . . . . . . . . . . . . . . . . . . . . 10 64 4. BGPsec Update Messages . . . . . . . . . . . . . . . . . . . 11 65 4.1. General Guidance . . . . . . . . . . . . . . . . . . . . 11 66 4.2. Constructing the BGPsec_Path Attribute . . . . . . . . . 14 67 4.3. Processing Instructions for Confederation Members . . . . 18 68 4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . 19 69 5. Processing a Received BGPsec Update . . . . . . . . . . . . . 21 70 5.1. Overview of BGPsec Validation . . . . . . . . . . . . . . 22 71 5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . 23 72 6. Algorithms and Extensibility . . . . . . . . . . . . . . . . 27 73 6.1. Algorithm Suite Considerations . . . . . . . . . . . . . 27 74 6.2. Considerations for the SKI Size . . . . . . . . . . . . . 28 75 6.3. Extensibility Considerations . . . . . . . . . . . . . . 28 76 7. Operations and Management Considerations . . . . . . . . . . 29 77 7.1. Capability Negotiation Failure . . . . . . . . . . . . . 29 78 7.2. Preventing Misuse of pCount=0 . . . . . . . . . . . . . . 29 79 7.3. Early Termination of Signature Verification . . . . . . . 30 80 7.4. Non-Deterministic Signature Algorithms . . . . . . . . . 30 81 7.5. Private AS Numbers . . . . . . . . . . . . . . . . . . . 30 82 7.6. Robustness Considerations for Accessing RPKI Data . . . . 32 83 7.7. Graceful Restart . . . . . . . . . . . . . . . . . . . . 32 84 7.8. Robustness of Secret Random Number in ECDSA . . . . . . . 32 85 7.9. Incremental/Partial Deployment Considerations . . . . . . 33 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 87 8.1. Security Guarantees . . . . . . . . . . . . . . . . . . . 33 88 8.2. On the Removal of BGPsec Signatures . . . . . . . . . . . 34 89 8.3. Mitigation of Denial of Service Attacks . . . . . . . . . 35 90 8.4. Additional Security Considerations . . . . . . . . . . . 36 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 92 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39 93 10.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . 39 94 10.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . 40 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 40 97 11.2. Informative References . . . . . . . . . . . . . . . . . 42 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 100 1. Introduction 102 This document describes BGPsec, a mechanism for providing path 103 security for Border Gateway Protocol (BGP) [RFC4271] route 104 advertisements. That is, a BGP speaker who receives a valid BGPsec 105 update has cryptographic assurance that the advertised route has the 106 following property: Every AS on the path of ASes listed in the update 107 message has explicitly authorized the advertisement of the route to 108 the subsequent AS in the path. 110 This document specifies an optional (non-transitive) BGP path 111 attribute, BGPsec_Path. It also describes how a BGPsec-compliant BGP 112 speaker (referred to hereafter as a BGPsec speaker) can generate, 113 propagate, and validate BGP update messages containing this attribute 114 to obtain the above assurances. 116 BGPsec is intended to be used to supplement BGP Origin Validation 117 [RFC6483][RFC6811] and when used in conjunction with origin 118 validation, it is possible to prevent a wide variety of route 119 hijacking attacks against BGP. 121 BGPsec relies on the Resource Public Key Infrastructure (RPKI) 122 certificates that attest to the allocation of AS number and IP 123 address resources. (For more information on the RPKI, see RFC 6480 124 [RFC6480] and the documents referenced therein.) Any BGPsec speaker 125 who wishes to send, to external (eBGP) peers, BGP update messages 126 containing the BGPsec_Path needs to possess a private key associated 127 with an RPKI router certificate [I-D.ietf-sidr-bgpsec-pki-profiles] 128 that corresponds to the BGPsec speaker's AS number. Note, however, 129 that a BGPsec speaker does not need such a certificate in order to 130 validate received update messages containing the BGPsec_Path 131 attribute (see Section 5.2). 133 1.1. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 2. BGPsec Negotiation 141 This document defines a BGP capability [RFC5492] that allows a BGP 142 speaker to advertise to a neighbor the ability to send or to receive 143 BGPsec update messages (i.e., update messages containing the 144 BGPsec_Path attribute). 146 2.1. The BGPsec Capability 148 This capability has capability code: TBD 150 The capability length for this capability MUST be set to 3. 152 The three octets of the capability format are specified in Figure 1. 154 0 1 2 3 4 5 6 7 155 +---------------------------------------+ 156 | Version | Dir | Unassigned | 157 +---------------------------------------+ 158 | | 159 +------ AFI -----+ 160 | | 161 +---------------------------------------+ 163 Figure 1: BGPsec Capability format. 165 The first four bits of the first octet indicate the version of BGPsec 166 for which the BGP speaker is advertising support. This document 167 defines only BGPsec version 0 (all four bits set to zero). Other 168 versions of BGPsec may be defined in future documents. A BGPsec 169 speaker MAY advertise support for multiple versions of BGPsec by 170 including multiple versions of the BGPsec capability in its BGP OPEN 171 message. 173 The fifth bit of the first octet is a direction bit which indicates 174 whether the BGP speaker is advertising the capability to send BGPsec 175 update messages or receive BGPsec update messages. The BGP speaker 176 sets this bit to 0 to indicate the capability to receive BGPsec 177 update messages. The BGP speaker sets this bit to 1 to indicate the 178 capability to send BGPsec update messages. 180 The remaining three bits of the first octet are unassigned and for 181 future use. These bits are set to zero by the sender of the 182 capability and ignored by the receiver of the capability. 184 The second and third octets contain the 16-bit Address Family 185 Identifier (AFI) which indicates the address family for which the 186 BGPsec speaker is advertising support for BGPsec. This document only 187 specifies BGPsec for use with two address families, IPv4 and IPv6, 188 AFI values 1 and 2 respectively [IANA-AF]. BGPsec for use with other 189 address families may be specified in future documents. 191 2.2. Negotiating BGPsec Support 193 In order to indicate that a BGP speaker is willing to send BGPsec 194 update messages (for a particular address family), a BGP speaker 195 sends the BGPsec Capability (see Section 2.1) with the Direction bit 196 (the fifth bit of the first octet) set to 1. In order to indicate 197 that the speaker is willing to receive BGP update messages containing 198 the BGPsec_Path attribute (for a particular address family), a BGP 199 speaker sends the BGPsec capability with the Direction bit set to 0. 200 In order to advertise the capability to both send and receive BGPsec 201 update messages, the BGP speaker sends two copies of the BGPsec 202 capability (one with the direction bit set to 0 and one with the 203 direction bit set to 1). 205 Similarly, if a BGP speaker wishes to use BGPsec with two different 206 address families (i.e., IPv4 and IPv6) over the same BGP session, 207 then the speaker includes two instances of this capability (one for 208 each address family) in the BGP OPEN message. A BGP speaker MUST NOT 209 announce BGPsec capability if it does not support the BGP 210 multiprotocol extension [RFC4760]. Additionally, a BGP speaker MUST 211 NOT advertise the capability of BGPsec support for a particular AFI 212 unless it has also advertised the multiprotocol extension capability 213 for the same AFI [RFC4760]. 215 In a BGPsec peering session, a peer is permitted to send update 216 messages containing the BGPsec_Path attribute if, and only if: 218 o The given peer sent the BGPsec capability for a particular version 219 of BGPsec and a particular address family with the Direction bit 220 set to 1; and 222 o The other (receiving) peer sent the BGPsec capability for the same 223 version of BGPsec and the same address family with the Direction 224 bit set to 0. 226 In such a session, it can be said that the use of the particular 227 version of BGPsec has been negotiated for a particular address 228 family. Traditional BGP update messages (i.e. unsigned, containing 229 AS_PATH attribute) MAY be sent within a session regardless of whether 230 or not the use of BGPsec is successfully negotiated. However, if 231 BGPsec is not successfully negotiated, then BGP update messages 232 containing the BGPsec_Path attribute MUST NOT be sent. 234 This document defines the behavior of implementations in the case 235 where BGPsec version zero is the only version that has been 236 successfully negotiated. Any future document which specifies 237 additional versions of BGPsec will need to specify behavior in the 238 case that support for multiple versions is negotiated. 240 BGPsec cannot provide meaningful security guarantees without support 241 for four-byte AS numbers. Therefore, any BGP speaker that announces 242 the BGPsec capability, MUST also announce the capability for four- 243 byte AS support [RFC6793]. If a BGP speaker sends the BGPsec 244 capability but not the four-byte AS support capability then BGPsec 245 has not been successfully negotiated, and update messages containing 246 the BGPsec_Path attribute MUST NOT be sent within such a session. 248 3. The BGPsec_Path Attribute 250 The BGPsec_Path attribute is an optional non-transitive BGP path 251 attribute. 253 This document registers an attribute type code for this attribute: 254 BGPsec_Path (see Section 9). 256 The BGPsec_Path attribute carries the secured information regarding 257 the path of ASes through which an update message passes. This 258 includes the digital signatures used to protect the path information. 259 The update messages that contain the BGPsec_Path attribute are 260 referred to as "BGPsec Update messages". The BGPsec_Path attribute 261 replaces the AS_PATH attribute in a BGPsec update message. That is, 262 update messages that contain the BGPsec_Path attribute MUST NOT 263 contain the AS_PATH attribute, and vice versa. 265 The BGPsec_Path attribute is made up of several parts. The high- 266 level diagram in Figure 2 provides an overview of the structure of 267 the BGPsec_Path attribute. 269 +---------------------------------------------------------+ 270 | +-----------------+ | 271 | | Secure Path | | 272 | +-----------------+ | 273 | | pCount X | | 274 | | Flags X | | 275 | | AS X | | 276 | | pCount Y | | 277 | | Flags Y | | 278 | | AS Y | | 279 | | ... | | 280 | +-----------------+ | 281 | | 282 | +-----------------+ +-----------------+ | 283 | | Sig Block 1 | | Sig Block 2 | | 284 | +-----------------+ +-----------------+ | 285 | | Alg Suite 1 | | Alg Suite 2 | | 286 | | SKI X1 | | SKI X2 | | 287 | | Signature X1 | | Signature X2 | | 288 | | SKI Y1 | | SKI Y2 | | 289 | | Signature Y1 | | Signature Y2 | | 290 | | ... | | .... | | 291 | +-----------------+ +-----------------+ | 292 | | 293 +---------------------------------------------------------+ 295 Figure 2: High-level diagram of the BGPsec_Path attribute. 297 Figure 3 provides the specification of the format for the BGPsec_Path 298 attribute. 300 +-------------------------------------------------------+ 301 | Secure_Path (variable) | 302 +-------------------------------------------------------+ 303 | Sequence of one or two Signature_Blocks (variable) | 304 +-------------------------------------------------------+ 306 Figure 3: BGPsec_Path attribute format. 308 The Secure_Path contains AS path information for the BGPsec update 309 message. This is logically equivalent to the information that is 310 contained in a non-BGPsec AS_PATH attribute. The information in 311 Secure_Path is used by BGPsec speakers in the same way that 312 information from the AS_PATH is used by non-BGPsec speakers. The 313 format of the Secure_Path is described below in Section 3.1. 315 The BGPsec_Path attribute will contain one or two Signature_Blocks, 316 each of which corresponds to a different algorithm suite. Each of 317 the Signature_Blocks will contain a Signature Segment for each AS 318 number (i.e., Secure_Path Segment) in the Secure_Path. In the most 319 common case, the BGPsec_Path attribute will contain only a single 320 Signature_Block. However, in order to enable a transition from an 321 old algorithm suite to a new algorithm suite (without a flag day), it 322 will be necessary to include two Signature_Blocks (one for the old 323 algorithm suite and one for the new algorithm suite) during the 324 transition period. (See Section 6.1 for more discussion of algorithm 325 transitions.) The format of the Signature_Blocks is described below 326 in Section 3.2. 328 3.1. Secure_Path 330 A detailed description of the Secure_Path information in the 331 BGPsec_Path attribute is provided here. 333 +-----------------------------------------------+ 334 | Secure_Path Length (2 octets) | 335 +-----------------------------------------------+ 336 | One or More Secure_Path Segments (variable) | 337 +-----------------------------------------------+ 339 Figure 4: Secure_Path format. 341 The specification for the Secure_Path field is provided in Figure 4 342 and Figure 5. The Secure_Path Length contains the length (in octets) 343 of the entire Secure_Path (including the two octets used to express 344 this length field). As explained below, each Secure_Path Segment is 345 six octets long. Note that this means the Secure_Path Length is two 346 greater than six times the number Secure_Path Segments (i.e., the 347 number of AS numbers in the path). 349 The Secure_Path contains one Secure_Path Segment (see Figure 5) for 350 each Autonomous System in the path to the originating AS of the 351 prefix specified in the update message. (Note: Repeated Autonomous 352 Systems are compressed out using the pCount field as discussed 353 below.) 354 +------------------------------------------------------+ 355 | pCount (1 octet) | 356 +------------------------------------------------------+ 357 | Confed_Segment flag (1 bit) | Unassigned (7 bits) | (Flags) 358 +------------------------------------------------------+ 359 | AS Number (4 octets) | 360 +------------------------------------------------------+ 362 Figure 5: Secure_Path Segment format. 364 The AS Number (in Figure 5) is the AS number of the BGP speaker that 365 added this Secure_Path Segment to the BGPsec_Path attribute. (See 366 Section 4 for more information on populating this field.) 368 The pCount field contains the number of repetitions of the associated 369 autonomous system number that the signature covers. This field 370 enables a BGPsec speaker to mimic the semantics of prepending 371 multiple copies of their AS to the AS_PATH without requiring the 372 speaker to generate multiple signatures. Note that Section 9.1.2.2 373 ("Breaking Ties") in [RFC4271] mentions "number of AS numbers" in the 374 AS_PATH attribute that is used in the route selection process. This 375 metric (number of AS numbers) is the same as the AS path length 376 obtained in BGPsec by summing the pCount values in the BGPsec_Path 377 attribute. The pCount field is also useful in managing route servers 378 (see Section 4.2), AS confederations (see Section 4.3), and AS Number 379 migrations (see [I-D.ietf-sidr-as-migration] for details). 381 The left most (i.e. the most significant) bit of the Flags field in 382 Figure 5 is the Confed_Segment flag. The Confed_Segment flag is set 383 to one to indicate that the BGPsec speaker that constructed this 384 Secure_Path Segment is sending the update message to a peer AS within 385 the same Autonomous System confederation [RFC5065]. (That is, a 386 sequence of consecutive Confed_Segment flags are set in a BGPsec 387 update message whenever, in a non-BGPsec update message, an AS_PATH 388 segment of type AS_CONFED_SEQUENCE occurs.) In all other cases the 389 Confed_Segment flag is set to zero. 391 The remaining seven bits of the Flags are unassigned and MUST be set 392 to zero by the sender, and ignored by the receiver. Note, however, 393 that the signature is computed over all eight bits of the flags 394 field. 396 As stated earlier in Section 2.2, BGPsec peering requires that the 397 peering ASes MUST each support four-byte AS numbers. Currently- 398 assigned two-byte AS numbers are converted into four-byte AS numbers 399 by setting the two high-order octets of the four-octet field to zero 400 [RFC6793]. 402 3.2. Signature_Block 404 A detailed description of the Signature_Blocks in the BGPsec_Path 405 attribute is provided here using Figure 6 and Figure 7. 407 +---------------------------------------------+ 408 | Signature_Block Length (2 octets) | 409 +---------------------------------------------+ 410 | Algorithm Suite Identifier (1 octet) | 411 +---------------------------------------------+ 412 | Sequence of Signature Segments (variable) | 413 +---------------------------------------------+ 415 Figure 6: Signature_Block format. 417 The Signature_Block Length in Figure 6 is the total number of octets 418 in the Signature_Block (including the two octets used to express this 419 length field). 421 The Algorithm Suite Identifier is a one-octet identifier specifying 422 the digest algorithm and digital signature algorithm used to produce 423 the digital signature in each Signature Segment. An IANA registry of 424 algorithm identifiers for use in BGPsec is specified in the BGPsec 425 algorithms document [I-D.ietf-sidr-bgpsec-algs]. 427 A Signature_Block in Figure 6 has exactly one Signature Segment (see 428 Figure 7) for each Secure_Path Segment in the Secure_Path portion of 429 the BGPsec_Path Attribute. (That is, one Signature Segment for each 430 distinct AS on the path for the prefix in the Update message.) 432 +---------------------------------------------+ 433 | Subject Key Identifier (SKI) (20 octets) | 434 +---------------------------------------------+ 435 | Signature Length (2 octets) | 436 +---------------------------------------------+ 437 | Signature (variable) | 438 +---------------------------------------------+ 440 Figure 7: Signature Segment format. 442 The Subject Key Identifier (SKI) field in Figure 7 contains the value 443 in the Subject Key Identifier extension of the RPKI router 444 certificate [RFC6487] that is used to verify the signature (see 445 Section 5 for details on validity of BGPsec update messages). The 446 SKI field has a fixed 20 octets size. See Section 6.2 for 447 considerations for the SKI size. 449 The Signature Length field contains the size (in octets) of the value 450 in the Signature field of the Signature Segment. 452 The Signature in Figure 7 contains a digital signature that protects 453 the prefix and the BGPsec_Path attribute (see Section 4 and Section 5 454 for details on signature generation and validation, respectively). 456 4. BGPsec Update Messages 458 Section 4.1 provides general guidance on the creation of BGPsec 459 Update Messages -- that is, update messages containing the 460 BGPsec_Path attribute. 462 Section 4.2 specifies how a BGPsec speaker generates the BGPsec_Path 463 attribute to include in a BGPsec Update message. 465 Section 4.3 contains special processing instructions for members of 466 an autonomous system confederation [RFC5065]. A BGPsec speaker that 467 is not a member of such a confederation MUST NOT set the 468 Confed_Segment flag in its Secure_Path Segment (i.e. leave the flag 469 bit at default value zero) in all BGPsec update messages it sends. 471 Section 4.4 contains instructions for reconstructing the AS_PATH 472 attribute in cases where a BGPsec speaker receives an update message 473 with a BGPsec_Path attribute and wishes to propagate the update 474 message to a peer who does not support BGPsec. 476 4.1. General Guidance 478 The information protected by the signature on a BGPsec update message 479 includes the AS number of the peer to whom the update message is 480 being sent. Therefore, if a BGPsec speaker wishes to send a BGPsec 481 update to multiple BGP peers, it MUST generate a separate BGPsec 482 update message for each unique peer AS to whom the update message is 483 sent. 485 A BGPsec update message MUST advertise a route to only a single 486 prefix. This is because a BGPsec speaker receiving an update message 487 with multiple prefixes would be unable to construct a valid BGPsec 488 update message (i.e., valid path signatures) containing a subset of 489 the prefixes in the received update. If a BGPsec speaker wishes to 490 advertise routes to multiple prefixes, then it MUST generate a 491 separate BGPsec update message for each prefix. Additionally, a 492 BGPsec update message MUST use the MP_REACH_NLRI [RFC4760] attribute 493 to encode the prefix. 495 The BGPsec_Path attribute and the AS_PATH attribute are mutually 496 exclusive. That is, any update message containing the BGPsec_Path 497 attribute MUST NOT contain the AS_PATH attribute. The information 498 that would be contained in the AS_PATH attribute is instead conveyed 499 in the Secure_Path portion of the BGPsec_Path attribute. 501 In order to create or add a new signature to a BGPsec update message 502 with a given algorithm suite, the BGPsec speaker MUST possess a 503 private key suitable for generating signatures for this algorithm 504 suite. Additionally, this private key must correspond to the public 505 key in a valid Resource PKI end-entity certificate whose AS number 506 resource extension includes the BGPsec speaker's AS number 507 [I-D.ietf-sidr-bgpsec-pki-profiles]. Note also that new signatures 508 are only added to a BGPsec update message when a BGPsec speaker is 509 generating an update message to send to an external peer (i.e., when 510 the AS number of the peer is not equal to the BGPsec speaker's own AS 511 number). 513 The Resource PKI enables the legitimate holder of IP address 514 prefix(es) to issue a signed object, called a Route Origination 515 Authorization (ROA), that authorizes a given AS to originate routes 516 to a given set of prefixes (see RFC 6482 [RFC6482]). It is expected 517 that most relying parties will utilize BGPsec in tandem with origin 518 validation (see RFC 6483 [RFC6483] and RFC 6811 [RFC6811]). 519 Therefore, it is RECOMMENDED that a BGPsec speaker only originate a 520 BGPsec update advertising a route for a given prefix if there exists 521 a valid ROA authorizing the BGPsec speaker's AS to originate routes 522 to this prefix. 524 If a BGPsec router has received only a non-BGPsec update message 525 containing the AS_PATH attribute (instead of the BGPsec_Path 526 attribute) from a peer for a given prefix, then it MUST NOT attach a 527 BGPsec_Path attribute when it propagates the update message. (Note 528 that a BGPsec router may also receive a non-BGPsec update message 529 from an internal peer without the AS_PATH attribute, i.e., with just 530 the NLRI in it. In that case, the prefix is originating from that 531 AS, and if it is selected for advertisement, the BGPsec speaker 532 SHOULD attach a BGPsec_Path attribute and send a signed route (for 533 that prefix) to its external BGPsec-speaking peers.) 535 Conversely, if a BGPsec router has received a BGPsec update message 536 (with the BGPsec_Path attribute) from a peer for a given prefix and 537 it chooses to propagate that peer's route for the prefix, then it 538 SHOULD propagate the route as a BGPsec update message containing the 539 BGPsec_Path attribute. 541 Note that removing BGPsec signatures (i.e., propagating a route 542 advertisement without the BGPsec_Path attribute) has significant 543 security ramifications. (See Section 8 for discussion of the 544 security ramifications of removing BGPsec signatures.) Therefore, 545 when a route advertisement is received via a BGPsec update message, 546 propagating the route advertisement without the BGPsec_Path attribute 547 is NOT RECOMMENDED, unless the message is sent to a peer that did not 548 advertise the capability to receive BGPsec update messages (see 549 Section 4.4). 551 Furthermore, note that when a BGPsec speaker propagates a route 552 advertisement with the BGPsec_Path attribute it is not attesting to 553 the validation state of the update message it received. (See 554 Section 8 for more discussion of the security semantics of BGPsec 555 signatures.) 557 If the BGPsec speaker is producing an update message which would, in 558 the absence of BGPsec, contain an AS_SET (e.g., the BGPsec speaker is 559 performing proxy aggregation), then the BGPsec speaker MUST NOT 560 include the BGPsec_Path attribute. In such a case, the BGPsec 561 speaker MUST remove any existing BGPsec_Path in the received 562 advertisement(s) for this prefix and produce a traditional (non- 563 BGPsec) update message. It should be noted that BCP 172 [RFC6472] 564 recommends against the use of AS_SET and AS_CONFED_SET in the AS_PATH 565 of BGP updates. 567 The case where the BGPsec speaker sends a BGPsec update message to an 568 iBGP peer is quite simple. When originating a new route 569 advertisement and sending it to a BGPsec-capable iBGP peer, the 570 BGPsec speaker omits the BGPsec_Path attribute. When originating a 571 new route advertisement and sending it to a non-BGPsec iBGP peer, the 572 BGPsec speaker includes an empty AS_PATH attribute in the update 573 message. (An empty AS_PATH attribute is one whose length field 574 contains the value zero [RFC4271].) When a BGPsec speaker chooses to 575 forward a BGPsec update message to an iBGP peer, the BGPsec_Path 576 attribute SHOULD NOT be removed, unless the peer doesn't support 577 BGPsec. In the case when an iBGP peer doesn't support BGPsec, then a 578 BGP update with AS_PATH is reconstructed from the BGPsec update and 579 then forwarded (see Section 4.4). In particular, when forwarding to 580 a BGPsec-capable iBGP (or eBGP) peer, the BGPsec_Path attribute 581 SHOULD NOT be removed even in the case where the BGPsec update 582 message has not been successfully validated. (See Section 5 for more 583 information on validation, and Section 8 for the security 584 ramifications of removing BGPsec signatures.) 586 All BGPsec update messages MUST conform to BGP's maximum message 587 size. If the resulting message exceeds the maximum message size, 588 then the guidelines in Section 9.2 of RFC 4271 [RFC4271] MUST be 589 followed. 591 4.2. Constructing the BGPsec_Path Attribute 593 When a BGPsec speaker receives a BGPsec update message containing a 594 BGPsec_Path attribute (with one or more signatures) from an (internal 595 or external) peer, it may choose to propagate the route advertisement 596 by sending it to its other (internal or external) peers. When 597 sending the route advertisement to an internal BGPsec-speaking peer, 598 the BGPsec_Path attribute SHALL NOT be modified. When sending the 599 route advertisement to an external BGPsec-speaking peer, the 600 following procedures are used to form or update the BGPsec_Path 601 attribute. 603 To generate the BGPsec_Path attribute on the outgoing update message, 604 the BGPsec speaker first generates a new Secure_Path Segment. Note 605 that if the BGPsec speaker is not the origin AS and there is an 606 existing BGPsec_Path attribute, then the BGPsec speaker prepends its 607 new Secure_Path Segment (places in first position) onto the existing 608 Secure_Path. 610 The AS number in this Secure_Path Segment MUST match the AS number in 611 the Subject field of the Resource PKI router certificate that will be 612 used to verify the digital signature constructed by this BGPsec 613 speaker (see Section 3.1.1 in [I-D.ietf-sidr-bgpsec-pki-profiles] and 614 RFC 6487 [RFC6487]). 616 The pCount field of the Secure_Path Segment is typically set to the 617 value 1. However, a BGPsec speaker may set the pCount field to a 618 value greater than 1. Setting the pCount field to a value greater 619 than one has the same semantics as repeating an AS number multiple 620 times in the AS_PATH of a non-BGPsec update message (e.g., for 621 traffic engineering purposes). 623 To prevent unnecessary processing load in the validation of BGPsec 624 signatures, a BGPsec speaker SHOULD NOT produce multiple consecutive 625 Secure_Path Segments with the same AS number. This means that to 626 achieve the semantics of prepending the same AS number k times, a 627 BGPsec speaker SHOULD produce a single Secure_Path Segment -- with 628 pCount of k -- and a single corresponding Signature Segment. 630 A route server that participates in the BGP control plane, but does 631 not act as a transit AS in the data plane, may choose to set pCount 632 to 0. This option enables the route server to participate in BGPsec 633 and obtain the associated security guarantees without increasing the 634 length of the AS path. (Note that BGPsec speakers compute the length 635 of the AS path by summing the pCount values in the BGPsec_Path 636 attribute, see Section 5.) However, when a route server sets the 637 pCount value to 0, it still inserts its AS number into the 638 Secure_Path Segment, as this information is needed to validate the 639 signature added by the route server. See 640 [I-D.ietf-sidr-as-migration] for a discussion of setting pCount to 0 641 to facilitate AS Number Migration. Also, see Section 4.3 for the use 642 of pCount=0 in the context of an AS confederation. See Section 7.2 643 for operational guidance for configuring a BGPsec router for setting 644 pCount=0 and/or accepting pCount=0 from a peer. 646 Next, the BGPsec speaker generates one or two Signature_Blocks. 647 Typically, a BGPsec speaker will use only a single algorithm suite, 648 and thus create only a single Signature_Block in the BGPsec_Path 649 attribute. However, to ensure backwards compatibility during a 650 period of transition from a 'current' algorithm suite to a 'new' 651 algorithm suite, it will be necessary to originate update messages 652 that contain a Signature_Block for both the 'current' and the 'new' 653 algorithm suites (see Section 6.1). 655 If the received BGPsec update message contains two Signature_Blocks 656 and the BGPsec speaker supports both of the corresponding algorithm 657 suites, then the new update message generated by the BGPsec speaker 658 MUST include both of the Signature_Blocks. If the received BGPsec 659 update message contains two Signature_Blocks and the BGPsec speaker 660 only supports one of the two corresponding algorithm suites, then the 661 BGPsec speaker MUST remove the Signature_Block corresponding to the 662 algorithm suite that it does not understand. If the BGPsec speaker 663 does not support the algorithm suites in any of the Signature_Blocks 664 contained in the received update message, then the BGPsec speaker 665 MUST NOT propagate the route advertisement with the BGPsec_Path 666 attribute. (That is, if it chooses to propagate this route 667 advertisement at all, it MUST do so as an unsigned BGP update 668 message. See Section 4.4 for more information on converting to an 669 unsigned BGP message.) 671 Note that in the case where the BGPsec_Path has two Signature_Blocks 672 (corresponding to different algorithm suites), the validation 673 algorithm (see Section 5.2) deems a BGPsec update message to be 674 'Valid' if there is at least one supported algorithm suite (and 675 corresponding Signature_Block) that is deemed 'Valid'. This means 676 that a 'Valid' BGPsec update message may contain a Signature_Block 677 which is not deemed 'Valid' (e.g., contains signatures that BGPsec 678 does not successfully verify). Nonetheless, such Signature_Blocks 679 MUST NOT be removed. (See Section 8 for a discussion of the security 680 ramifications of this design choice.) 682 For each Signature_Block corresponding to an algorithm suite that the 683 BGPsec speaker does support, the BGPsec speaker MUST add a new 684 Signature Segment to the Signature_Block. This Signature Segment is 685 prepended to the list of Signature Segments (placed in the first 686 position) so that the list of Signature Segments appears in the same 687 order as the corresponding Secure_Path Segments. The BGPsec speaker 688 populates the fields of this new Signature Segment as follows. 690 The Subject Key Identifier field in the new segment is populated with 691 the identifier contained in the Subject Key Identifier extension of 692 the RPKI router certificate corresponding to the BGPsec speaker 693 [I-D.ietf-sidr-bgpsec-pki-profiles]. This Subject Key Identifier 694 will be used by recipients of the route advertisement to identify the 695 proper certificate to use in verifying the signature. 697 The Signature field in the new segment contains a digital signature 698 that binds the prefix and BGPsec_Path attribute to the RPKI router 699 certificate corresponding to the BGPsec speaker. The digital 700 signature is computed as follows: 702 o For clarity, let us number the Secure_Path and corresponding 703 Signature Segments from 1 to N as follows. Let Secure_Path 704 Segment 1 and Signature Segment 1 be the segments produced by the 705 origin AS. Let Secure_Path Segment 2 and Signature Segment 2 be 706 the segments added by the next AS after the origin. Continue this 707 method of numbering and ultimately let Secure_Path Segment N and 708 Signature Segment N be those that are being added by the current 709 AS. The current AS (Nth AS) is signing and forwarding the update 710 to the next AS (i.e. (N+1)th AS) in the chain of ASes that form 711 the AS path. 713 o In order to construct the digital signature for Signature Segment 714 N (the Signature Segment being produced by the current AS), first 715 construct the sequence of octets to be hashed as shown in 716 Figure 8. This sequence of octets includes all the data that the 717 Nth AS attests to by adding its digital signature in the update 718 which is being forwarded to a BGPsec speaker in the (N+1)th AS. 719 (For the design rationale for choosing the specific structure in 720 Figure 8, please see [Borchert].) 721 +------------------------------------+ 722 | Target AS Number | 723 +------------------------------------+ ---\ 724 | Signature Segment : N-1 | \ 725 +------------------------------------+ | 726 | Secure_Path Segment : N | | 727 +------------------------------------+ \ 728 ... > Data from 729 +------------------------------------+ / N Segments 730 | Signature Segment : 1 | | 731 +------------------------------------+ | 732 | Secure_Path Segment : 2 | | 733 +------------------------------------+ / 734 | Secure_Path Segment : 1 | / 735 +------------------------------------+---/ 736 | Algorithm Suite Identifier | 737 +------------------------------------+ 738 | AFI | 739 +------------------------------------+ 740 | SAFI | 741 +------------------------------------+ 742 | Prefix | 743 +------------------------------------+ 745 Figure 8: Sequence of octets to be hashed. 747 The elements in this sequence (Figure 8) MUST be ordered exactly 748 as shown. The 'Target AS Number' is the AS to whom the BGPsec 749 speaker intends to send the update message. (Note that the 750 'Target AS Number' is the AS number announced by the peer in the 751 OPEN message of the BGP session within which the update is sent.) 752 The Secure_Path and Signature Segments (1 through N-1) are 753 obtained from the BGPsec_Path attribute. Finally, the Address 754 Family Identifier (AFI), Subsequent Address Family Identifier 755 (SAFI), and Prefix fields are obtained from the MP_REACH_NLRI 756 attribute [RFC4760]. Additionally, in the Prefix field all of the 757 trailing bits MUST be set to zero when constructing this sequence. 759 o Apply to this octet sequence (in Figure 8) the digest algorithm 760 (for the algorithm suite of this Signature_Block) to obtain a 761 digest value. 763 o Apply to this digest value the signature algorithm, (for the 764 algorithm suite of this Signature_Block) to obtain the digital 765 signature. Then populate the Signature Field (in Figure 7) with 766 this digital signature. 768 The Signature Length field (in Figure 7) is populated with the length 769 (in octets) of the value in the Signature field. 771 4.3. Processing Instructions for Confederation Members 773 Members of autonomous system confederations [RFC5065] MUST 774 additionally follow the instructions in this section for processing 775 BGPsec update messages. 777 When a BGPsec speaker in an AS confederation receives a BGPsec update 778 from a peer that is external to the confederation and chooses to 779 propagate the update within the confederation, then it first adds a 780 signature signed to its own Member-AS (i.e. the Target AS number is 781 the BGPsec speaker's Member-AS number). In this internally modified 782 update, the newly added Secure_Path Segment contains the public AS 783 number (i.e. Confederation Identifier), the Segment's pCount value 784 is set to 0, and Confed_Segment flag is set to one. Setting pCount=0 785 in this case helps ensure that the AS path length is not 786 unnecessarily incremented. The newly added signature is generated 787 using a private key corresponding to the public AS number of the 788 confederation. The BGPsec speaker propagates the modified update to 789 its peers within the confederation. 791 Any BGPsec_Path modifications mentioned below in the context of 792 propagation of the update within the confederation are in addition to 793 the modification described above (i.e. with pCount=0). 795 When a BGPsec speaker sends a BGPsec update message to a peer that 796 belongs within its own Member-AS, the confederation member SHALL NOT 797 modify the BGPsec_Path attribute. When a BGPsec speaker sends a 798 BGPsec update message to a peer that is within the same confederation 799 but in a different Member-AS, the BGPsec speaker puts its Member-AS 800 number in the AS Number field of the Secure_Path Segment that it adds 801 to the BGPsec update message. Additionally, in this case, the 802 Member-AS that generates the Secure_Path Segment sets the 803 Confed_Segment flag to one. Further, the signature is generated with 804 a private key corresponding to the BGPsec speaker's Member-AS Number. 805 (Note: In this document, intra-Member-AS peering is regarded as iBGP 806 and inter-Member-AS peering is regarded as eBGP. The latter is also 807 known as confederation-eBGP.) 809 Within a confederation, the verification of BGPsec signatures added 810 by other members of the confederation is optional. Note that if a 811 confederation chooses not to verify digital signatures within the 812 confederation, then BGPsec is able to provide no assurances about the 813 integrity of the Member-AS Numbers placed in Secure_Path Segments 814 where the Confed_Segment flag is set to one. 816 When a confederation member receives a BGPsec update message from a 817 peer within the confederation and propagates it to a peer outside the 818 confederation, it needs to remove all of the Secure_Path Segments 819 added by confederation members as well as the corresponding Signature 820 Segments. To do this, the confederation member propagating the route 821 outside the confederation does the following: 823 o First, starting with the most recently added Secure_Path Segment, 824 remove all of the consecutive Secure_Path Segments that have the 825 Confed_Segment flag set to one. Stop this process once a 826 Secure_Path Segment is reached which has its Confed_Segment flag 827 set to zero. Keep a count of the number of segments removed in 828 this fashion. 830 o Second, starting with the most recently added Signature Segment, 831 remove a number of Signature Segments equal to the number of 832 Secure_Path Segments removed in the previous step. (That is, 833 remove the K most recently added Signature Segments, where K is 834 the number of Secure_Path Segments removed in the previous step.) 836 o Finally, add a Secure_Path Segment containing, in the AS field, 837 the AS Confederation Identifier (the public AS number of the 838 confederation) as well as a corresponding Signature Segment. Note 839 that all fields other than the AS field are populated as per 840 Section 4.2. 842 Finally, as discussed above, an AS confederation MAY optionally 843 decide that its members will not verify digital signatures added by 844 members. In such a confederation, when a BGPsec speaker runs the 845 algorithm in Section 5.2, the BGPsec speaker, during the process of 846 Signature verifications, first checks whether the Confed_Segment flag 847 in a Secure_Path Segment is set to one. If the flag is set to one, 848 the BGPsec speaker skips the verification for the corresponding 849 Signature, and immediately moves on to the next Secure_Path Segment. 850 Note that as specified in Section 5.2, it is an error when a BGPsec 851 speaker receives from a peer, who is not in the same AS 852 confederation, a BGPsec update containing a Confed_Segment flag set 853 to one. 855 4.4. Reconstructing the AS_PATH Attribute 857 BGPsec update messages do not contain the AS_PATH attribute. 858 However, the AS_PATH attribute can be reconstructed from the 859 BGPsec_Path attribute. This is necessary in the case where a route 860 advertisement is received via a BGPsec update message and then 861 propagated to a peer via a non-BGPsec update message (e.g., because 862 the latter peer does not support BGPsec). Note that there may be 863 additional cases where an implementation finds it useful to perform 864 this reconstruction. Before attempting to reconstruct an AS_PATH for 865 the purpose of forwarding an unsigned (non-BGPsec) update to a peer, 866 a BGPsec speaker MUST perform the basic integrity checks listed in 867 Section 5.2 to ensure that the received BGPsec update is properly 868 formed. 870 The AS_PATH attribute can be constructed from the BGPsec_Path 871 attribute as follows. Starting with a blank AS_PATH attribute, 872 process the Secure_Path Segments in order from least-recently added 873 (corresponding to the origin) to most-recently added. For each 874 Secure_Path Segment perform the following steps: 876 1. If the Secure_Path Segment has pCount=0, then do nothing (i.e. 877 move on to process the next Secure_Path Segment). 879 2. If the Secure_Path Segment has pCount greater than 0 and the 880 Confed_Segment flag is set to one, then look at the most-recently 881 added segment in the AS_PATH. 883 * In the case where the AS_PATH is blank or in the case where 884 the most-recently added segment is of type AS_SEQUENCE, add 885 (prepend to the AS_PATH) a new AS_PATH segment of type 886 AS_CONFED_SEQUENCE. This segment of type AS_CONFED_SEQUENCE 887 shall contain a number of elements equal to the pCount field 888 in the current Secure_Path Segment. Each of these elements 889 shall be the AS number contained in the current Secure_Path 890 Segment. (That is, if the pCount field is X, then the segment 891 of type AS_CONFED_SEQUENCE contains X copies of the 892 Secure_Path Segment's AS Number field.) 894 * In the case where the most-recently added segment in the 895 AS_PATH is of type AS_CONFED_SEQUENCE then add (prepend to the 896 segment) a number of elements equal to the pCount field in the 897 current Secure_Path Segment. The value of each of these 898 elements shall be the AS number contained in the current 899 Secure_Path Segment. (That is, if the pCount field is X, then 900 add X copies of the Secure_Path Segment's AS Number field to 901 the existing AS_CONFED_SEQUENCE.) 903 3. If the Secure_Path Segment has pCount greater than 0 and the 904 Confed_Segment flag is set to zero, then look at the most- 905 recently added segment in the AS_PATH. 907 * In the case where the AS_PATH is blank or in the case where 908 the most-recently added segment is of type AS_CONFED_SEQUENCE, 909 add (prepend to the AS_PATH) a new AS_PATH segment of type 910 AS_SEQUENCE. This segment of type AS_SEQUENCE shall contain a 911 number of elements equal to the pCount field in the current 912 Secure_Path Segment. Each of these elements shall be the AS 913 number contained in the current Secure_Path Segment. (That 914 is, if the pCount field is X, then the segment of type 915 AS_SEQUENCE contains X copies of the Secure_Path Segment's AS 916 Number field.) 918 * In the case where the most recently added segment in the 919 AS_PATH is of type AS_SEQUENCE then add (prepend to the 920 segment) a number of elements equal to the pCount field in the 921 current Secure_Path Segment. The value of each of these 922 elements shall be the AS number contained in the current 923 Secure_Path Segment. (That is, if the pCount field is X, then 924 add X copies of the Secure_Path Segment's AS Number field to 925 the existing AS_SEQUENCE.) 927 As part of the above described procedure, the following additional 928 actions are performed in order not to exceed the size limitations of 929 AS_SEQUENCE and AS_CONFED_SEQUENCE. While adding the next 930 Secure_Path Segment (with its prepends, if any) to the AS_PATH being 931 assembled, if it would cause the AS_SEQUENCE (or AS_CONFED_SEQUENCE) 932 at hand to exceed the limit of 255 AS numbers per segment [RFC4271] 933 [RFC5065], then the BGPsec speaker would follow the recommendations 934 in RFC 4271 [RFC4271] and RFC 5065 [RFC5065] of creating another 935 segment of the same type (AS_SEQUENCE or AS_CONFED_SEQUENCE) and 936 continue filling that. 938 Finally, one special case of reconstruction of AS_PATH is when the 939 BGPsec_Path attribute is absent. As explained in Section 4.1, when a 940 BGPsec speaker originates a prefix and sends it to a BGPsec-capable 941 iBGP peer, the BGPsec_Path is not attached. So when received from a 942 BGPsec-capable iBGP peer, no BGPsec_Path attribute in a BGPsec update 943 is equivalent to an empty AS_PATH [RFC4271]. 945 5. Processing a Received BGPsec Update 947 Upon receiving a BGPsec update message from an external (eBGP) peer, 948 a BGPsec speaker SHOULD validate the message to determine the 949 authenticity of the path information contained in the BGPsec_Path 950 attribute. Typically, a BGPsec speaker will also wish to perform 951 origin validation (see RFC 6483 [RFC6483] and RFC 6811 [RFC6811]) on 952 an incoming BGPsec update message, but such validation is independent 953 of the validation described in this section. 955 Section 5.1 provides an overview of BGPsec validation and Section 5.2 956 provides a specific algorithm for performing such validation. (Note 957 that an implementation need not follow the specific algorithm in 958 Section 5.2 as long as the input/output behavior of the validation is 959 identical to that of the algorithm in Section 5.2.) During 960 exceptional conditions (e.g., the BGPsec speaker receives an 961 incredibly large number of update messages at once) a BGPsec speaker 962 MAY temporarily defer validation of incoming BGPsec update messages. 963 The treatment of such BGPsec update messages, whose validation has 964 been deferred, is a matter of local policy. However, an 965 implementation SHOULD ensure that deferment of validation and status 966 of deferred messages is visible to the operator. 968 The validity of BGPsec update messages is a function of the current 969 RPKI state. When a BGPsec speaker learns that RPKI state has changed 970 (e.g., from an RPKI validating cache via the RPKI-to-Router protocol 971 [I-D.ietf-sidr-rpki-rtr-rfc6810-bis]), the BGPsec speaker MUST re-run 972 validation on all affected update messages stored in its Adj-RIB-In 973 [RFC4271]. For example, when a given RPKI router certificate ceases 974 to be valid (e.g., it expires or is revoked), all update messages 975 containing a signature whose SKI matches the SKI in the given 976 certificate MUST be re-assessed to determine if they are still valid. 977 If this reassessment determines that the validity state of an update 978 has changed then, depending on local policy, it may be necessary to 979 re-run best path selection. 981 BGPsec update messages do not contain an AS_PATH attribute. The 982 Secure_Path contains AS path information for the BGPsec update 983 message. Therefore, a BGPsec speaker MUST utilize the AS path 984 information in the Secure_Path in all cases where it would otherwise 985 use the AS path information in the AS_PATH attribute. The only 986 exception to this rule is when AS path information must be updated in 987 order to propagate a route to a peer (in which case the BGPsec 988 speaker follows the instructions in Section 4). Section 4.4 provides 989 an algorithm for constructing an AS_PATH attribute from a BGPsec_Path 990 attribute. Whenever the use of AS path information is called for 991 (e.g., loop detection, or use of AS path length in best path 992 selection) the externally visible behavior of the implementation 993 shall be the same as if the implementation had run the algorithm in 994 Section 4.4 and used the resulting AS_PATH attribute as it would for 995 a non-BGPsec update message. 997 5.1. Overview of BGPsec Validation 999 Validation of a BGPsec update message makes use of data from RPKI 1000 router certificates. In particular, it is necessary that the 1001 recipient have access to the following data obtained from valid RPKI 1002 router certificates: the AS Number, Public Key and Subject Key 1003 Identifier from each valid RPKI router certificate. 1005 Note that the BGPsec speaker could perform the validation of RPKI 1006 router certificates on its own and extract the required data, or it 1007 could receive the same data from a trusted cache that performs RPKI 1008 validation on behalf of (some set of) BGPsec speakers. (For example, 1009 the trusted cache could deliver the necessary validity information to 1010 the BGPsec speaker using the router key PDU for the RPKI-to-Router 1011 protocol [I-D.ietf-sidr-rpki-rtr-rfc6810-bis].) 1013 To validate a BGPsec update message containing the BGPsec_Path 1014 attribute, the recipient performs the validation steps specified in 1015 Section 5.2. The validation procedure results in one of two states: 1016 'Valid' and 'Not Valid'. 1018 It is expected that the output of the validation procedure will be 1019 used as an input to BGP route selection. That said, BGP route 1020 selection, and thus the handling of the validation states is a matter 1021 of local policy, and is handled using local policy mechanisms. 1022 Implementations SHOULD enable operators to set such local policy on a 1023 per-session basis. (That is, it is expected that some operators will 1024 choose to treat BGPsec validation status differently for update 1025 messages received over different BGP sessions.) 1027 BGPsec validation needs only be performed at the eBGP edge. The 1028 validation status of a BGP signed/unsigned update MAY be conveyed via 1029 iBGP from an ingress edge router to an egress edge router via some 1030 mechanism, according to local policy within an AS. As discussed in 1031 Section 4, when a BGPsec speaker chooses to forward a (syntactically 1032 correct) BGPsec update message, it SHOULD be forwarded with its 1033 BGPsec_Path attribute intact (regardless of the validation state of 1034 the update message). Based entirely on local policy, an egress 1035 router receiving a BGPsec update message from within its own AS MAY 1036 choose to perform its own validation. 1038 5.2. Validation Algorithm 1040 This section specifies an algorithm for validation of BGPsec update 1041 messages. A conformant implementation MUST include a BGPsec update 1042 validation algorithm that is functionally equivalent to the 1043 externally visible behavior of this algorithm. 1045 First, the recipient of a BGPsec update message performs a check to 1046 ensure that the message is properly formed. Both syntactical and 1047 protocol violation errors are checked. BGPsec_Path attribute MUST be 1048 present when a BGPsec update is received from an external (eBGP) 1049 BGPsec peer and also when such an update is propagated to an internal 1050 (iBGP) BGPsec peer (see Section 4.2). The error checks specified in 1051 Section 6.3 of [RFC4271] are performed, except that for BGPsec 1052 updates the checks on the AS_PATH attribute do not apply and instead 1053 the following checks on BGPsec_Path attribute are performed: 1055 1. Check to ensure that the entire BGPsec_Path attribute is 1056 syntactically correct (conforms to the specification in this 1057 document). 1059 2. Check that AS number in the most recently added Secure_Path 1060 Segment (i.e. the one corresponding to the eBGP peer from which 1061 the update message was received) matches the AS number of that 1062 peer as specified in the BGP OPEN message. (Note: This check is 1063 performed only at an ingress BGPsec routers where the update is 1064 first received from a peer AS.) 1066 3. Check that each Signature_Block contains one Signature Segment 1067 for each Secure_Path Segment in the Secure_Path portion of the 1068 BGPsec_Path attribute. (Note that the entirety of each 1069 Signature_Block MUST be checked to ensure that it is well formed, 1070 even though the validation process may terminate before all 1071 signatures are cryptographically verified.) 1073 4. Check that the update message does not contain an AS_PATH 1074 attribute. 1076 5. If the update message was received from an BGPsec peer that is 1077 not a member of the BGPsec speaker's AS confederation, check to 1078 ensure that none of the Secure_Path Segments contain a Flags 1079 field with the Confed_Segment flag set to one. 1081 6. If the update message was received from a BGPsec peer that is a 1082 member of the BGPsec speaker's AS confederation, check to ensure 1083 that the Secure_Path Segment corresponding to that peer contains 1084 a Flags field with the Confed_Segment flag set to one. 1086 7. If the update message was received from a peer that is not 1087 expected to set pCount=0 (see Section 4.2 and Section 4.3) then 1088 check to ensure that the pCount field in the most-recently added 1089 Secure_Path Segment is not equal to zero. (Note: See router 1090 configuration guidance related to this in Section 7.2.) 1092 8. Using the equivalent of AS_PATH corresponding to the Secure_Path 1093 in the update (see Section 4.4), check that the local AS number 1094 is not present in the AS path (i.e. rule out AS loop). 1096 If any of these checks fail, it is an error in the BGPsec_Path 1097 attribute. BGPsec speakers MUST handle any syntactical or protocol 1098 errors in the BGPsec_Path attribute using the "treat-as-withdraw" 1099 approach as defined in RFC 7606 [RFC7606]. (Note: Since the AS 1100 number of a transparent route server does appear in the Secure_Path 1101 with pCount=0, the route server MAY check if its local AS is listed 1102 in the Secure_Path, and this check MAY be included in the loop 1103 detection check listed above.) 1105 Next, the BGPsec speaker examines the Signature_Blocks in the 1106 BGPsec_Path attribute. A Signature_Block corresponding to an 1107 algorithm suite that the BGPsec speaker does not support is not 1108 considered in validation. If there is no Signature_Block 1109 corresponding to an algorithm suite that the BGPsec speaker supports, 1110 then in order to consider the update in the route selection process, 1111 the BGPsec speaker MUST strip the Signature_Block(s), reconstruct the 1112 AS_PATH from the Secure_Path (see Section 4.4), and treat the update 1113 as if it was received as an unsigned BGP update. 1115 For each remaining Signature_Block (corresponding to an algorithm 1116 suite supported by the BGPsec speaker), the BGPsec speaker iterates 1117 through the Signature Segments in the Signature_Block, starting with 1118 the most recently added segment (and concluding with the least 1119 recently added segment). Note that there is a one-to-one 1120 correspondence between Signature Segments and Secure_Path Segments 1121 within the BGPsec_Path attribute. The following steps make use of 1122 this correspondence. 1124 o (Step 1): Let there be K AS hops in a received BGPsec_Path 1125 attribute that is to be validated. Let AS(1), AS(2), ..., AS(K+1) 1126 denote the sequence of AS numbers from the origin AS to the 1127 validating AS. Let Secure_Path Segment N and Signature Segment N 1128 in the BGPsec_Path attribute refer to those corresponding to AS(N) 1129 (where N = 1, 2, ..., K). The BGPsec speaker that is processing 1130 and validating the BGPsec_Path attribute resides in AS(K+1). Let 1131 Signature Segment N be the Signature Segment that is currently 1132 being verified. 1134 o (Step 2): Locate the public key needed to verify the signature (in 1135 the current Signature Segment). To do this, consult the valid 1136 RPKI router certificate data and look up all valid (AS, SKI, 1137 Public Key) triples in which the AS matches the AS number in the 1138 corresponding Secure_Path Segment. Of these triples that match 1139 the AS number, check whether there is an SKI that matches the 1140 value in the Subject Key Identifier field of the Signature 1141 Segment. If this check finds no such matching SKI value, then 1142 mark the entire Signature_Block as 'Not Valid' and proceed to the 1143 next Signature_Block. 1145 o (Step 3): Compute the digest function (for the given algorithm 1146 suite) on the appropriate data. 1148 In order to verify the digital signature in Signature Segment N, 1149 construct the sequence of octets to be hashed as shown in Figure 9 1150 (using the notations defined in Step 1). (Note that this sequence 1151 is the same sequence that was used by AS(N) that created the 1152 Signature Segment N (see Section 4.2 and Figure 8).) 1154 +------------------------------------+ 1155 | Target AS Number | 1156 +------------------------------------+ ---\ 1157 | Signature Segment : N-1 | \ 1158 +------------------------------------+ | 1159 | Secure_Path Segment : N | | 1160 +------------------------------------+ \ 1161 ... > Data from 1162 +------------------------------------+ / N Segments 1163 | Signature Segment : 1 | | 1164 +------------------------------------+ | 1165 | Secure_Path Segment : 2 | | 1166 +------------------------------------+ / 1167 | Secure_Path Segment : 1 | / 1168 +------------------------------------+---/ 1169 | Algorithm Suite Identifier | 1170 +------------------------------------+ 1171 | AFI | 1172 +------------------------------------+ 1173 | SAFI | 1174 +------------------------------------+ 1175 | Prefix | 1176 +------------------------------------+ 1178 Figure 9: The Sequence of octets to be hashed for signature 1179 verification of Signature Segment N; N = 1,2, ..., K, where K is the 1180 number of AS hops in the BGPsec_Path attribute. 1182 The elements in this sequence (Figure 9) MUST be ordered exactly 1183 as shown. For the first segment to be processed (the most 1184 recently added segment (i.e. N = K) given that there are K hops 1185 in the Secure_Path), the 'Target AS Number' is AS(K+1), the AS 1186 number of the BGPsec speaker validating the update message. Note 1187 that if a BGPsec speaker uses multiple AS Numbers (e.g., the 1188 BGPsec speaker is a member of a confederation), the AS number used 1189 here MUST be the AS number announced in the OPEN message for the 1190 BGP session over which the BGPsec update was received. 1192 For each other Signature Segment (N smaller than K), the 'Target 1193 AS Number' is AS(N+1), the AS number in the Secure_Path Segment 1194 that corresponds to the Signature Segment added immediately after 1195 the one being processed. (That is, in the Secure_Path Segment 1196 that corresponds to the Signature Segment that the validator just 1197 finished processing.) 1199 The Secure_Path and Signature Segment are obtained from the 1200 BGPsec_Path attribute. The Address Family Identifier (AFI), 1201 Subsequent Address Family Identifier (SAFI), and Prefix fields are 1202 obtained from the MP_REACH_NLRI attribute [RFC4760]. 1203 Additionally, in the Prefix field all of the trailing bits MUST be 1204 set to zero when constructing this sequence. 1206 o (Step 4): Use the signature validation algorithm (for the given 1207 algorithm suite) to verify the signature in the current segment. 1208 That is, invoke the signature validation algorithm on the 1209 following three inputs: the value of the Signature field in the 1210 current segment; the digest value computed in Step 3 above; and 1211 the public key obtained from the valid RPKI data in Step 2 above. 1212 If the signature validation algorithm determines that the 1213 signature is invalid, then mark the entire Signature_Block as 'Not 1214 Valid' and proceed to the next Signature_Block. If the signature 1215 validation algorithm determines that the signature is valid, then 1216 continue processing Signature Segments (within the current 1217 Signature_Block). 1219 If all Signature Segments within a Signature_Block pass validation 1220 (i.e., all segments are processed and the Signature_Block has not yet 1221 been marked 'Not Valid'), then the Signature_Block is marked as 1222 'Valid'. 1224 If at least one Signature_Block is marked as 'Valid', then the 1225 validation algorithm terminates and the BGPsec update message is 1226 deemed to be 'Valid'. (That is, if a BGPsec update message contains 1227 two Signature_Blocks then the update message is deemed 'Valid' if the 1228 first Signature_Block is marked 'Valid' OR the second Signature_Block 1229 is marked 'Valid'.) 1231 6. Algorithms and Extensibility 1233 6.1. Algorithm Suite Considerations 1235 Note that there is currently no support for bilateral negotiation 1236 (using BGP capabilities) between BGPsec peers to use a particular 1237 (digest and signature) algorithm suite. This is because the 1238 algorithm suite used by the sender of a BGPsec update message MUST be 1239 understood not only by the peer to whom it is directly sending the 1240 message, but also by all BGPsec speakers to whom the route 1241 advertisement is eventually propagated. Therefore, selection of an 1242 algorithm suite cannot be a local matter negotiated by BGP peers, but 1243 instead must be coordinated throughout the Internet. 1245 To this end, a mandatory algorithm suites document exists which 1246 specifies a mandatory-to-use 'current' algorithm suite for use by all 1247 BGPsec speakers [I-D.ietf-sidr-bgpsec-algs]. 1249 It is anticipated that, in the future, the mandatory algorithm suites 1250 document will be updated to specify a transition from the 'current' 1251 algorithm suite to a 'new' algorithm suite. During the period of 1252 transition, all BGPsec update messages SHOULD simultaneously use both 1253 the 'current' algorithm suite and the 'new' algorithm suite. (Note 1254 that Section 3 and Section 4 specify how the BGPsec_Path attribute 1255 can contain signatures, in parallel, for two algorithm suites.) Once 1256 the transition is complete, use of the old 'current' algorithm will 1257 be deprecated, use of the 'new' algorithm will be mandatory, and a 1258 subsequent 'even newer' algorithm suite may be specified as 1259 recommended to implement. Once the transition has successfully been 1260 completed in this manner, BGPsec speakers SHOULD include only a 1261 single Signature_Block (corresponding to the 'new' algorithm). 1263 6.2. Considerations for the SKI Size 1265 Depending on the method of generating key identifiers [RFC7093], the 1266 size of the SKI in a RPKI router certificate may vary. The SKI field 1267 in the BGPsec_Path attribute has a fixed 20 octets size (see 1268 Figure 7). If the SKI is longer than 20 octets, then use the 1269 leftmost 20 octets of the SKI (excluding the tag and length) 1270 [RFC7093]. If the SKI value is shorter than 20 octets, then pad the 1271 SKI (excluding the tag and length) to the right (least significant 1272 octets) with octets having zero values. 1274 6.3. Extensibility Considerations 1276 This section discusses potential changes to BGPsec that would require 1277 substantial changes to the processing of the BGPsec_Path and thus 1278 necessitate a new version of BGPsec. Examples of such changes 1279 include: 1281 o A new type of signature algorithm that produces signatures of 1282 variable length 1284 o A new type of signature algorithm for which the number of 1285 signatures in the Signature_Block is not equal to the number of 1286 ASes in the Secure_Path (e.g., aggregate signatures) 1288 o Changes to the data that is protected by the BGPsec signatures 1289 (e.g., attributes other than the AS path) 1291 In the case that such a change to BGPsec were deemed desirable, it is 1292 expected that a subsequent version of BGPsec would be created and 1293 that this version of BGPsec would specify a new BGP path attribute, 1294 let's call it BGPsec_Path_Two, which is designed to accommodate the 1295 desired changes to BGPsec. In such a case, the mandatory algorithm 1296 suites document would be updated to specify algorithm suites 1297 appropriate for the new version of BGPsec. 1299 At this point a transition would begin which is analogous to the 1300 algorithm transition discussed in Section 6.1. During the transition 1301 period all BGPsec speakers SHOULD simultaneously include both the 1302 BGPsec_Path attribute and the new BGPsec_Path_Two attribute. Once 1303 the transition is complete, the use of BGPsec_Path could then be 1304 deprecated, at which point BGPsec speakers should include only the 1305 new BGPsec_Path_Two attribute. Such a process could facilitate a 1306 transition to a new BGPsec semantics in a backwards compatible 1307 fashion. 1309 7. Operations and Management Considerations 1311 Some operations and management issues that are closely relevant to 1312 BGPsec protocol specification and its deployment are highlighted 1313 here. The Best Current Practices concerning operations and 1314 deployment of BGPsec are provided in [I-D.ietf-sidr-bgpsec-ops]. 1316 7.1. Capability Negotiation Failure 1318 Section 2.2 describes the negotiation required to establish a BGPsec- 1319 capable peering session. Not only must the BGPsec capability be 1320 exchanged (and agreed on), but the BGP multiprotocol extension 1321 [RFC4760] for the same AFI and the four-byte AS capability [RFC6793] 1322 MUST also be exchanged. Failure to properly negotiate a BGPsec 1323 session, due to a missing capability, for example, may still result 1324 in the exchange of BGP (unsigned) updates. It is RECOMMENDED that an 1325 implementation log the failure to properly negotiate a BGPsec 1326 session. Also, an implementation MUST have the ability to prevent a 1327 BGP session from being established if configured for only BGPsec use. 1329 7.2. Preventing Misuse of pCount=0 1331 A peer that is an Internet Exchange Point (IXP) (i.e. Route Server) 1332 with a transparent AS is expected to set pCount=0 in its Secure_Path 1333 Segment while forwarding an update to a peer (see Section 4.2). 1334 Clearly, such an IXP MUST configure its BGPsec router to set pCount=0 1335 in its Secure_Path Segment. This also means that a BGPsec speaker 1336 MUST be configured so that it permits pCount=0 from an IXP peer. Two 1337 other cases where pCount is set to zero are in the context AS 1338 confederation (see Section 4.3) and AS migration 1339 [I-D.ietf-sidr-as-migration]. In these two cases, pCount=0 is set 1340 and accepted within the same AS (albeit the AS has two different 1341 identities). Note that if a BGPsec speaker does not expect a peer AS 1342 to set its pCount=0, and if an update received from that peer 1343 violates this, then the update MUST be considered to be in error (see 1344 the list of checks in Section 5.2). See Section 8.4 for a discussion 1345 of security considerations concerning pCount=0. 1347 7.3. Early Termination of Signature Verification 1349 During the validation of a BGPsec update, route processor performance 1350 speedup can be achieved by incorporating the following observations. 1351 An update is deemed 'Valid' if at least one of the Signature_Blocks 1352 is marked as 'Valid' (see Section 5.2). Therefore, if an update 1353 contains two Signature_Blocks and the first one verified is found 1354 'Valid', then the second Signature_Block does not have to be 1355 verified. And if the update is chosen for best path, then the BGPsec 1356 speaker adds its signature (generated with the respective algorithm) 1357 to each of the two Signature_Blocks and forwards the update. Also, a 1358 BGPsec update is deemed 'Not Valid' if at least one signature in each 1359 of the Signature_Blocks is invalid. This principle can also be used 1360 for route processor workload savings, i.e. the verification for a 1361 Signature_Block terminates early when the first invalid signature is 1362 encountered. 1364 7.4. Non-Deterministic Signature Algorithms 1366 Many signature algorithms are non-deterministic. That is, many 1367 signature algorithms will produce different signatures each time they 1368 are run (even when they are signing the same data with the same key). 1369 Therefore, if a BGPsec router receives a BGPsec update from a peer 1370 and later receives a second BGPsec update message from the same peer 1371 for the same prefix with the same Secure_Path and SKIs, the second 1372 update MAY differ from the first update in the signature fields (for 1373 a non-deterministic signature algorithm). However, the two sets of 1374 signature fields will not differ if the sender caches and reuses the 1375 previous signature. For a deterministic signature algorithm, the 1376 signature fields MUST be identical between the two updates. On the 1377 basis of these observations, an implementation MAY incorporate 1378 optimizations in update validation processing. 1380 7.5. Private AS Numbers 1382 It is possible that a stub customer of an ISP employs a private AS 1383 number. Such a stub customer cannot publish a ROA in the global RPKI 1384 for the private AS number and the prefixes that they use. Also, the 1385 global RPKI cannot support private AS numbers (i.e. BGPsec speakers 1386 in private ASes cannot be issued router certificates in the global 1387 RPKI). For interactions between the stub customer (with private AS 1388 number) and the ISP, the following two scenarios are possible: 1390 1. The stub customer sends an unsigned BGP update for a prefix to 1391 the ISP's AS. An edge BGPsec speaker in the ISP's AS may choose 1392 to propagate the prefix to its non-BGPsec and BGPsec peers. If 1393 so, the ISP's edge BGPsec speaker MUST strip the AS_PATH with the 1394 private AS number, and then (a) re-originate the prefix without 1395 any signatures towards its non-BGPsec peer and (b) re-originate 1396 the prefix including its own signature towards its BGPsec peer. 1397 In both cases (i.e. (a) and (b)), the prefix MUST have a ROA in 1398 the global RPKI authorizing the ISP's AS to originate it. 1400 2. The ISP and the stub customer may use a local RPKI repository 1401 (using a mechanism such as described in [I-D.ietf-sidr-slurm]). 1402 Then there can be a ROA for the prefix originated by the stub AS, 1403 and the eBGP speaker in the stub AS can be a BGPsec speaker 1404 having a router certificate, albeit the ROA and router 1405 certificate are valid only locally. With this arrangement, the 1406 stub AS sends a signed update for the prefix to the ISP's AS. An 1407 edge BGPsec speaker in the ISP's AS validates the update using 1408 RPKI data based the local RPKI view. Further, it may choose to 1409 propagate the prefix to its non-BGPsec and BGPsec peers. If so, 1410 the ISP's edge BGPsec speaker MUST strip the Secure_Path and the 1411 Signature Segment received from the stub AS with the private AS 1412 number, and then (a) re-originate the prefix without any 1413 signatures towards its non-BGPsec peer and (b) re-originate the 1414 prefix including its own signature towards its BGPsec peer. In 1415 both cases (i.e. (a) and (b)), the prefix MUST have a ROA in the 1416 global RPKI authorizing the ISP's AS to originate it. 1418 It is possible that private AS numbers are used in an AS 1419 confederation [RFC5065]. BGPsec protocol requires that when a BGPsec 1420 update propagates through a confederation, each Member-AS that 1421 forwards it to a peer Member-AS MUST sign the update (see 1422 Section 4.3). However, the global RPKI cannot support private AS 1423 numbers. In order for the BGPsec speakers in Member-ASes with 1424 private AS numbers to have digital certificates, there MUST be a 1425 mechanism in place in the confederation that allows establishment of 1426 a local, customized view of the RPKI, augmenting the global RPKI 1427 repository data as needed. Since this mechanism (for augmenting and 1428 maintaining a local image of RPKI data) operates locally within an AS 1429 or AS confederation, it need not be standard based. However, a 1430 standard-based mechanism can be used (see [I-D.ietf-sidr-slurm]). 1431 Recall that in order to prevent exposure of the internals of AS 1432 confederations, a BGPsec speaker exporting to a non-member removes 1433 all intra-confederation Secure_Path Segments and Signatures (see 1434 Section 4.3). 1436 7.6. Robustness Considerations for Accessing RPKI Data 1438 The deployment structure, technologies and best practices concerning 1439 global RPKI data to reach routers (via local RPKI caches) are 1440 described in [RFC6810] [I-D.ietf-sidr-rpki-rtr-rfc6810-bis] 1441 [I-D.ietf-sidr-publication] [RFC7115] [I-D.ietf-sidr-bgpsec-ops] 1442 [I-D.ietf-sidr-delta-protocol]. For example, serial-number based 1443 incremental update mechanisms are used for efficient transfer of just 1444 the data records that have changed since last update [RFC6810] 1445 [I-D.ietf-sidr-rpki-rtr-rfc6810-bis]. Update notification file is 1446 used by relying parties (RPs) to discover whether any changes exist 1447 between the state of the global RPKI repository and the RP's cache 1448 [I-D.ietf-sidr-delta-protocol]. The notification describes the 1449 location of the files containing the snapshot and incremental deltas 1450 which can be used by the RP to synchronize with the repository. 1451 Making use of these technologies and best practices results in 1452 enabling robustness, efficiency, and better security for the BGPsec 1453 routers and RPKI caches in terms of the flow of RPKI data from 1454 repositories to RPKI caches to routers. With these mechanisms, it is 1455 believed that an attacker wouldn't be able to meaningfully correlate 1456 RPKI data flows with BGPsec RP (or router) actions, thus avoiding 1457 attacks that may attempt to determine the set of ASes interacting 1458 with an RP via the interactions between the RP and RPKI servers. 1460 7.7. Graceful Restart 1462 During Graceful Restart (GR), restarting and receiving BGPsec 1463 speakers MUST follow the procedures specified in [RFC4724] for 1464 restarting and receiving BGP speakers, respectively. In particular, 1465 the behavior of retaining the forwarding state for the routes in the 1466 Loc-RIB [RFC4271] and marking them as stale as well as not 1467 differentiating between stale and other information during forwarding 1468 will be the same as specified in [RFC4724]. 1470 7.8. Robustness of Secret Random Number in ECDSA 1472 The Elliptic Curve Digital Signature Algorithm (ECDSA) with curve 1473 P-256 is used for signing updates in BGPsec 1474 [I-D.ietf-sidr-bgpsec-algs]. For ECDSA, it is stated in Section 6.3 1475 of [FIPS186-4] that a new secret random number "k" shall be generated 1476 prior to the generation of each digital signature. A high entropy 1477 random bit generator (RBG) must be used for generating "k", and any 1478 potential bias in the "k" generation algorithm must be mitigated (see 1479 methods described in [FIPS186-4] [SP800-90A]). 1481 7.9. Incremental/Partial Deployment Considerations 1483 How will migration from BGP to BGPsec look like? What are the 1484 benefits for the first adopters? Initially small groups of 1485 contiguous ASes would be doing BGPsec. There would be possibly one 1486 or more such groups in different geographic regions of the global 1487 Internet. Only the routes originated within each group and 1488 propagated within its borders would get the benefits of cryptographic 1489 AS path protection. As BGPsec adoption grows, each group grows in 1490 size and eventually they join together to form even larger BGPsec 1491 capable groups of contiguous ASes. The benefit for early adopters 1492 starts with AS path security within the contiguous-AS regions spanned 1493 by their respective groups. Over time they would see those 1494 contiguous-AS regions grow much larger. 1496 During partial deployment, if an AS in the path doesn't support 1497 BGPsec, then BGP goes back to traditional mode, i.e. BGPsec updates 1498 are converted to unsigned updates before forwarding to that AS (see 1499 Section 4.4). At this point, the assurance that the update 1500 propagated via the sequence of ASes listed is lost. In other words, 1501 for the BGPsec routers residing in the ASes starting from the origin 1502 AS to the AS before the one not supporting BGPsec, the assurance can 1503 be still provided, but not beyond that (for the updates in 1504 consideration). 1506 8. Security Considerations 1508 For a discussion of the BGPsec threat model and related security 1509 considerations, please see RFC 7132 [RFC7132]. 1511 8.1. Security Guarantees 1513 When used in conjunction with Origin Validation (see RFC 6483 1514 [RFC6483] and RFC 6811 [RFC6811]), a BGPsec speaker who receives a 1515 valid BGPsec update message, containing a route advertisement for a 1516 given prefix, is provided with the following security guarantees: 1518 o The origin AS number corresponds to an autonomous system that has 1519 been authorized, in the RPKI, by the IP address space holder to 1520 originate route advertisements for the given prefix. 1522 o For each AS in the path, a BGPsec speaker authorized by the holder 1523 of the AS number intentionally chose (in accordance with local 1524 policy) to propagate the route advertisement to the subsequent AS 1525 in the path. 1527 That is, the recipient of a valid BGPsec update message is assured 1528 that the update propagated via the sequence of ASes listed in the 1529 Secure_Path portion of the BGPsec_Path attribute. (It should be 1530 noted that BGPsec does not offer any guarantee that the data packets 1531 would flow along the indicated path; it only guarantees that the BGP 1532 update conveying the path indeed propagated along the indicated 1533 path.) Furthermore, the recipient is assured that this path 1534 terminates in an autonomous system that has been authorized by the IP 1535 address space holder as a legitimate destination for traffic to the 1536 given prefix. 1538 Note that although BGPsec provides a mechanism for an AS to validate 1539 that a received update message has certain security properties, the 1540 use of such a mechanism to influence route selection is completely a 1541 matter of local policy. Therefore, a BGPsec speaker can make no 1542 assumptions about the validity of a route received from an external 1543 (eBGP) BGPsec peer. That is, a compliant BGPsec peer may (depending 1544 on the local policy of the peer) send update messages that fail the 1545 validity test in Section 5. Thus, a BGPsec speaker MUST completely 1546 validate all BGPsec update messages received from external peers. 1547 (Validation of update messages received from internal peers is a 1548 matter of local policy, see Section 5.) 1550 8.2. On the Removal of BGPsec Signatures 1552 There may be cases where a BGPsec speaker deems 'Valid' (as per the 1553 validation algorithm in Section 5.2) a BGPsec update message that 1554 contains both a 'Valid' and a 'Not Valid' Signature_Block. That is, 1555 the update message contains two sets of signatures corresponding to 1556 two algorithm suites, and one set of signatures verifies correctly 1557 and the other set of signatures fails to verify. In this case, the 1558 protocol specifies that a BGPsec speaker choosing to propagate the 1559 route advertisement in such an update message MUST add its signature 1560 to each of the Signature_Blocks (see Section 4.2). Thus the BGPsec 1561 speaker creates a signature using both algorithm suites and creates a 1562 new update message that contains both the 'Valid' and the 'Not Valid' 1563 set of signatures (from its own vantage point). 1565 To understand the reason for such a design decision, consider the 1566 case where the BGPsec speaker receives an update message with both a 1567 set of algorithm A signatures which are 'Valid' and a set of 1568 algorithm B signatures which are 'Not Valid'. In such a case it is 1569 possible (perhaps even likely, depending on the state of the 1570 algorithm transition) that some of the BGPsec speaker's peers (or 1571 other entities further 'downstream' in the BGP topology) do not 1572 support algorithm A. Therefore, if the BGPsec speaker were to remove 1573 the 'Not Valid' set of signatures corresponding to algorithm B, such 1574 entities would treat the message as though it were unsigned. By 1575 including the 'Not Valid' set of signatures when propagating a route 1576 advertisement, the BGPsec speaker ensures that 'downstream' entities 1577 have as much information as possible to make an informed opinion 1578 about the validation status of a BGPsec update. 1580 Note also that during a period of partial BGPsec deployment, a 1581 'downstream' entity might reasonably treat unsigned messages 1582 differently from BGPsec updates that contain a single set of 'Not 1583 Valid' signatures. That is, by removing the set of 'Not Valid' 1584 signatures the BGPsec speaker might actually cause a downstream 1585 entity to 'upgrade' the status of a route advertisement from 'Not 1586 Valid' to unsigned. Finally, note that in the above scenario, the 1587 BGPsec speaker might have deemed algorithm A signatures 'Valid' only 1588 because of some issue with RPKI state local to its AS (for example, 1589 its AS might not yet have obtained a CRL indicating that a key used 1590 to verify an algorithm A signature belongs to a newly revoked 1591 certificate). In such a case, it is highly desirable for a 1592 downstream entity to treat the update as 'Not Valid' (due to the 1593 revocation) and not as 'unsigned' (which would happen if the 'Not 1594 Valid' Signature_Blocks were removed enroute). 1596 A similar argument applies to the case where a BGPsec speaker (for 1597 some reason such as lack of viable alternatives) selects as its best 1598 path (to a given prefix) a route obtained via a 'Not Valid' BGPsec 1599 update message. In such a case, the BGPsec speaker should propagate 1600 a signed BGPsec update message, adding its signature to the 'Not 1601 Valid' signatures that already exist. Again, this is to ensure that 1602 'downstream' entities are able to make an informed decision and not 1603 erroneously treat the route as unsigned. It should also be noted 1604 that due to possible differences in RPKI data observed at different 1605 vantage points in the network, a BGPsec update deemed 'Not Valid' at 1606 an upstream BGPsec speaker may be deemed 'Valid' by another BGP 1607 speaker downstream. 1609 Indeed, when a BGPsec speaker signs an outgoing update message, it is 1610 not attesting to a belief that all signatures prior to its are valid. 1611 Instead it is merely asserting that: 1613 o The BGPsec speaker received the given route advertisement with the 1614 indicated prefix, AFI, SAFI, and Secure_Path; and 1616 o The BGPsec speaker chose to propagate an advertisement for this 1617 route to the peer (implicitly) indicated by the 'Target AS 1618 Number'. 1620 8.3. Mitigation of Denial of Service Attacks 1622 The BGPsec update validation procedure is a potential target for 1623 denial of service attacks against a BGPsec speaker. The mitigation 1624 of denial of service attacks that are specific to the BGPsec protocol 1625 is considered here. 1627 To mitigate the effectiveness of such denial of service attacks, 1628 BGPsec speakers should implement an update validation algorithm that 1629 performs expensive checks (e.g., signature verification) after 1630 performing less expensive checks (e.g., syntax checks). The 1631 validation algorithm specified in Section 5.2 was chosen so as to 1632 perform checks which are likely to be expensive after checks that are 1633 likely to be inexpensive. However, the relative cost of performing 1634 required validation steps may vary between implementations, and thus 1635 the algorithm specified in Section 5.2 may not provide the best 1636 denial of service protection for all implementations. 1638 Additionally, sending update messages with very long AS paths (and 1639 hence a large number of signatures) is a potential mechanism to 1640 conduct denial of service attacks. For this reason, it is important 1641 that an implementation of the validation algorithm stops attempting 1642 to verify signatures as soon as an invalid signature is found. (This 1643 ensures that long sequences of invalid signatures cannot be used for 1644 denial of service attacks.) Furthermore, implementations can 1645 mitigate such attacks by only performing validation on update 1646 messages that, if valid, would be selected as the best path. That 1647 is, if an update message contains a route that would lose out in best 1648 path selection for other reasons (e.g., a very long AS path) then it 1649 is not necessary to determine the BGPsec-validity status of the 1650 route. 1652 8.4. Additional Security Considerations 1654 The mechanism of setting the pCount field to zero is included in this 1655 specification to enable route servers in the control path to 1656 participate in BGPsec without increasing the length of the AS path. 1657 Two other scenarios where pCount=0 is utilized are in the context AS 1658 confederation (see Section 4.3) and AS migration 1659 [I-D.ietf-sidr-as-migration]. In these two scenarios, pCount=0 is 1660 set and also accepted within the same AS (albeit the AS has two 1661 different identities). However, entities other than route servers, 1662 confederation ASes or migrating ASes could conceivably use this 1663 mechanism (set the pCount to zero) to attract traffic (by reducing 1664 the length of the AS path) illegitimately. This risk is largely 1665 mitigated if every BGPsec speaker follows the operational guidance in 1666 Section 7.2 for configuration for setting pCount=0 and/or accepting 1667 pCount=0 from a peer. However, note that a recipient of a BGPsec 1668 update message within which an upstream entity two or more hops away 1669 has set pCount to zero is unable to verify for themselves whether 1670 pCount was set to zero legitimately. 1672 There is a possibility of passing a BGPsec update via tunneling 1673 between colluding ASes. For example, say, AS-X does not peer with 1674 AS-Y, but colludes with AS-Y, signs and sends a BGPsec update to AS-Y 1675 by tunneling. AS-Y can then further sign and propagate the BGPsec 1676 update to its peers. It is beyond the scope of the BGPsec protocol 1677 to detect this form of malicious behavior. BGPsec is designed to 1678 protect messages sent within BGP (i.e. within the control plane) - 1679 not when the control plane in bypassed. 1681 A variant of the collusion by tunneling mentioned above can happen in 1682 the context of AS confederations. When a BGPsec router (outside of a 1683 confederation) is forwarding an update to a Member-AS in the 1684 confederation, it signs the update to the public AS number of the 1685 confederation and not to the member's AS number (see Section 4.3). 1686 The Member-AS can tunnel the signed update to another Member-AS as 1687 received (i.e. without adding a signature). The update can then be 1688 propagated using BGPsec to other confederation members or to BGPsec 1689 neighbors outside of the confederation. This kind of operation is 1690 possible, but no grave security or reachability compromise is feared 1691 for the following reasons: (1) The confederation members belong to 1692 one organization and strong internal trust is expected; and (2) 1693 Recall that the signatures that are internal to the confederation 1694 MUST be removed prior to forwarding the update to an outside BGPsec 1695 router (see Section 4.3). 1697 BGPsec does not provide protection against attacks at the transport 1698 layer. As with any BGP session, an adversary on the path between a 1699 BGPsec speaker and its peer is able to perform attacks such as 1700 modifying valid BGPsec updates to cause them to fail validation, 1701 injecting (unsigned) BGP update messages without BGPsec_Path 1702 attributes, injecting BGPsec update messages with BGPsec_Path 1703 attributes that fail validation, or causing the peer to tear-down the 1704 BGP session. The use of BGPsec does nothing to increase the power of 1705 an on-path adversary -- in particular, even an on-path adversary 1706 cannot cause a BGPsec speaker to believe a BGPsec-invalid route is 1707 valid. However, as with any BGP session, BGPsec sessions SHOULD be 1708 protected by appropriate transport security mechanisms (see the 1709 Security Considerations section in [RFC4271]). 1711 There is a possibility of replay attacks which are defined as 1712 follows. In the context of BGPsec, a replay attack occurs when a 1713 malicious BGPsec speaker in the AS path suppresses a prefix 1714 withdrawal (implicit or explicit). Further, a replay attack is said 1715 to occur also when a malicious BGPsec speaker replays a previously 1716 received BGPsec announcement for a prefix that has since been 1717 withdrawn. The mitigation strategy for replay attacks involves 1718 router certificate rollover; please see 1719 [I-D.ietf-sidrops-bgpsec-rollover] for details. 1721 9. IANA Considerations 1723 IANA is requested to register a new BGP capability from Section 2.1 1724 in the BGP Capabilities Code registry's "IETF Review" range. The 1725 description for the new capability is "BGPsec Capability". The 1726 reference for the new capability is this document (i.e. the RFC that 1727 replaces draft-ietf-sidr-bgpsec-protocol). 1729 IANA is also requested to register a new path attribute from 1730 Section 3 in the BGP Path Attributes registry. The code for this new 1731 attribute is "BGPsec_Path". The reference for the new attribute is 1732 this document (i.e. the RFC that replaces draft-ietf-sidr-bgpsec- 1733 protocol). 1735 IANA is requested to define the "BGPsec Capability" registry in the 1736 Resource Public Key Infrastructure (RPKI) group. The registry is as 1737 shown in Figure 10 with values assigned from Section 2.1: 1739 +------+------------------------------------+------------+ 1740 | Bits | Field | Reference | 1741 +------+------------------------------------+------------+ 1742 | 0-3 | Version | [This RFC] | 1743 | | Value = 0x0 | | 1744 +------+------------------------------------+------------+ 1745 | 4 | Direction | [This RFC] | 1746 | |(Both possible values 0 and 1 are | | 1747 | | fully specified by this RFC) | | 1748 +------+------------------------------------+------------+ 1749 | 5-7 | Unassigned | [This RFC] | 1750 | | Value = 000 (in binary) | | 1751 +------+------------------------------------+------------+ 1753 Figure 10: IANA registry for BGPsec Capability. 1755 The Direction bit (4th bit) has value either 0 or 1, and both values 1756 are fully specified by this document (i.e. the RFC that replaces 1757 draft-ietf-sidr-bgpsec-protocol). Future Version values and future 1758 values of the Unassigned bits are assigned using the "Standards 1759 Action" registration procedures defined in RFC 5226 [RFC5226]. 1761 IANA is requested to define the "BGPsec_Path Flags" registry in the 1762 RPKI group. The registry is as shown in Figure 11 with one value 1763 assigned from Section 3.1: 1765 +------+-------------------------------------------+------------+ 1766 | Flag | Description | Reference | 1767 +------+-------------------------------------------+------------+ 1768 | 0 | Confed_Segment | [This RFC] | 1769 | | Bit value = 1 means Flag set | | 1770 | | (indicates Confed_Segment) | | 1771 | | Bit value = 0 is default | | 1772 +------+-------------------------------------------+------------+ 1773 | 1-7 | Unassigned | [This RFC] | 1774 | | Value: All 7 bits set to zero | | 1775 +------+-------------------------------------------+------------+ 1777 Figure 11: IANA registry for BGPsec_Path Flags field. 1779 Future values of the Unassigned bits are assigned using the 1780 "Standards Action" registration procedures defined in RFC 5226 1781 [RFC5226]. 1783 10. Contributors 1785 10.1. Authors 1787 Rob Austein 1788 Dragon Research Labs 1789 sra@hactrn.net 1791 Steven Bellovin 1792 Columbia University 1793 smb@cs.columbia.edu 1795 Randy Bush 1796 Internet Initiative Japan 1797 randy@psg.com 1799 Russ Housley 1800 Vigil Security 1801 housley@vigilsec.com 1803 Matt Lepinski 1804 New College of Florida 1805 mlepinski@ncf.edu 1807 Stephen Kent 1808 BBN Technologies 1809 kent@bbn.com 1811 Warren Kumari 1812 Google 1813 warren@kumari.net 1815 Doug Montgomery 1816 USA National Institute of Standards and Technology 1817 dougm@nist.gov 1819 Kotikalapudi Sriram 1820 USA National Institute of Standards and Technology 1821 kotikalapudi.sriram@nist.gov 1823 Samuel Weiler 1824 W3C/MIT 1825 weiler@csail.mit.edu 1827 10.2. Acknowledgements 1829 The authors would like to thank Michael Baer, Oliver Borchert, David 1830 Mandelberg, Mehmet Adalier, Sean Turner, John Scudder, Wes George, 1831 Jeff Haas, Keyur Patel, Alvaro Retana, Nevil Brownlee, Matthias 1832 Waehlisch, Sandy Murphy, Chris Morrow, Tim Polk, Russ Mundy, Wes 1833 Hardaker, Sharon Goldberg, Ed Kern, Doug Maughan, Pradosh Mohapatra, 1834 Mark Reynolds, Heather Schiller, Jason Schiller, Ruediger Volk, and 1835 David Ward for their review, comments, and suggestions during the 1836 course of this work. Thanks are also due to many IESG reviewers 1837 whose comments greatly helped improve the clarity, accuracy, and 1838 presentation in the document. 1840 11. References 1842 11.1. Normative References 1844 [I-D.ietf-sidr-bgpsec-algs] 1845 Turner, S. and O. Borchert, "BGPsec Algorithms, Key 1846 Formats, & Signature Formats", draft-ietf-sidr-bgpsec- 1847 algs-18 (work in progress), April 2017. 1849 [I-D.ietf-sidr-bgpsec-pki-profiles] 1850 Reynolds, M., Turner, S., and S. Kent, "A Profile for 1851 BGPsec Router Certificates, Certificate Revocation Lists, 1852 and Certification Requests", draft-ietf-sidr-bgpsec-pki- 1853 profiles-21 (work in progress), January 2017. 1855 [IANA-AF] "Address Family Numbers", 1856 . 1859 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1860 Requirement Levels", BCP 14, RFC 2119, 1861 DOI 10.17487/RFC2119, March 1997, 1862 . 1864 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1865 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1866 DOI 10.17487/RFC4271, January 2006, 1867 . 1869 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 1870 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 1871 DOI 10.17487/RFC4724, January 2007, 1872 . 1874 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1875 "Multiprotocol Extensions for BGP-4", RFC 4760, 1876 DOI 10.17487/RFC4760, January 2007, 1877 . 1879 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 1880 System Confederations for BGP", RFC 5065, 1881 DOI 10.17487/RFC5065, August 2007, 1882 . 1884 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1885 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1886 DOI 10.17487/RFC5226, May 2008, 1887 . 1889 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 1890 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 1891 2009, . 1893 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1894 Origin Authorizations (ROAs)", RFC 6482, 1895 DOI 10.17487/RFC6482, February 2012, 1896 . 1898 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1899 X.509 PKIX Resource Certificates", RFC 6487, 1900 DOI 10.17487/RFC6487, February 2012, 1901 . 1903 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1904 Autonomous System (AS) Number Space", RFC 6793, 1905 DOI 10.17487/RFC6793, December 2012, 1906 . 1908 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1909 Patel, "Revised Error Handling for BGP UPDATE Messages", 1910 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1911 . 1913 11.2. Informative References 1915 [Borchert] 1916 Borchert, O. and M. Baer, "Modification request: draft- 1917 ietf-sidr-bgpsec-protocol-14", IETF SIDR WG Mailing List 1918 message , February 10, 2016, 1919 . 1922 [FIPS186-4] 1923 "FIPS Standards Publication 186-4: Digital Signature 1924 Standard", July 2013, 1925 . 1928 [I-D.ietf-sidr-as-migration] 1929 George, W. and S. Murphy, "BGPSec Considerations for AS 1930 Migration", draft-ietf-sidr-as-migration-06 (work in 1931 progress), December 2016. 1933 [I-D.ietf-sidr-bgpsec-ops] 1934 Bush, R., "BGPsec Operational Considerations", draft-ietf- 1935 sidr-bgpsec-ops-16 (work in progress), January 2017. 1937 [I-D.ietf-sidr-delta-protocol] 1938 Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, 1939 "RPKI Repository Delta Protocol (RRDP)", draft-ietf-sidr- 1940 delta-protocol-08 (work in progress), March 2017. 1942 [I-D.ietf-sidr-publication] 1943 Weiler, S., Sonalker, A., and R. Austein, "A Publication 1944 Protocol for the Resource Public Key Infrastructure 1945 (RPKI)", draft-ietf-sidr-publication-12 (work in 1946 progress), March 2017. 1948 [I-D.ietf-sidr-rpki-rtr-rfc6810-bis] 1949 Bush, R. and R. Austein, "The Resource Public Key 1950 Infrastructure (RPKI) to Router Protocol, Version 1", 1951 draft-ietf-sidr-rpki-rtr-rfc6810-bis-09 (work in 1952 progress), February 2017. 1954 [I-D.ietf-sidr-slurm] 1955 Mandelberg, D., Ma, D., and T. Bruijnzeels, "Simplified 1956 Local internet nUmber Resource Management with the RPKI", 1957 draft-ietf-sidr-slurm-04 (work in progress), March 2017. 1959 [I-D.ietf-sidrops-bgpsec-rollover] 1960 Weis, B., Gagliano, R., and K. Patel, "BGPsec Router 1961 Certificate Rollover", draft-ietf-sidrops-bgpsec- 1962 rollover-00 (work in progress), March 2017. 1964 [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using 1965 AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, 1966 DOI 10.17487/RFC6472, December 2011, 1967 . 1969 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1970 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 1971 February 2012, . 1973 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 1974 Origination Using the Resource Certificate Public Key 1975 Infrastructure (PKI) and Route Origin Authorizations 1976 (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, 1977 . 1979 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 1980 Infrastructure (RPKI) to Router Protocol", RFC 6810, 1981 DOI 10.17487/RFC6810, January 2013, 1982 . 1984 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 1985 Austein, "BGP Prefix Origin Validation", RFC 6811, 1986 DOI 10.17487/RFC6811, January 2013, 1987 . 1989 [RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods 1990 for Generating Key Identifiers Values", RFC 7093, 1991 DOI 10.17487/RFC7093, December 2013, 1992 . 1994 [RFC7115] Bush, R., "Origin Validation Operation Based on the 1995 Resource Public Key Infrastructure (RPKI)", BCP 185, 1996 RFC 7115, DOI 10.17487/RFC7115, January 2014, 1997 . 1999 [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", 2000 RFC 7132, DOI 10.17487/RFC7132, February 2014, 2001 . 2003 [SP800-90A] 2004 "NIST 800-90A: Deterministic Random Bit Generator 2005 Validation System", October 2015, 2006 . 2009 Authors' Addresses 2011 Matthew Lepinski (editor) 2012 NCF 2013 5800 Bay Shore Road 2014 Sarasota FL 34243 2015 USA 2017 Email: mlepinski@ncf.edu 2019 Kotikalapudi Sriram (editor) 2020 NIST 2021 100 Bureau Drive 2022 Gaithersburg MD 20899 2023 USA 2025 Email: kotikalapudi.sriram@nist.gov