idnits 2.17.1 draft-sriram-bgpsec-design-choices-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 217: '... BGPsec update message MUST use the MP_REACH_NLRI attribute [RFC4760]...' RFC 2119 keyword, line 941: '...wing: "All BGPsec update messages MUST...' RFC 2119 keyword, line 944: '... of RFC 4271 [RFC4271] MUST be followed."...' RFC 2119 keyword, line 1371: '... BGPsec router MUST handle any synta...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 19, 2018) is 2289 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3779' is defined on line 2029, but no explicit reference was found in the text == Unused Reference: 'RFC4055' is defined on line 2034, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 2060, but no explicit reference was found in the text == Unused Reference: 'RFC5652' is defined on line 2071, but no explicit reference was found in the text == Unused Reference: 'RFC6480' is defined on line 2085, but no explicit reference was found in the text == Unused Reference: 'RFC6483' is defined on line 2094, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-14 == Outdated reference: A later version (-36) exists of draft-ietf-idr-bgp-extended-messages-24 == Outdated reference: A later version (-13) exists of draft-sriram-replay-protection-design-discussion-09 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-11 -- Duplicate reference: draft-ietf-sidr-bgpsec-protocol, mentioned in 'Mandelberg1', was also mentioned in 'Borchert'. == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-13 -- Duplicate reference: draft-ietf-sidr-bgpsec-protocol, mentioned in 'Mandelberg2', was also mentioned in 'Mandelberg1'. -- Obsolete informational reference (is this intentional?): RFC 4893 (Obsoleted by RFC 6793) -- Obsolete informational reference (is this intentional?): RFC 8208 (Obsoleted by RFC 8608) Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent Submission K. Sriram, Ed. 3 Internet-Draft USA NIST 4 Intended status: Informational January 19, 2018 5 Expires: July 23, 2018 7 BGPsec Design Choices and Summary of Supporting Discussions 8 draft-sriram-bgpsec-design-choices-16 10 Abstract 12 This document captures the design rationale of the initial draft of 13 the BGPsec protocol specification. The designers needed to balance 14 many competing factors, and this document lists the decisions that 15 were made in favor of or against each design choice. This document 16 also presents brief summaries of the arguments that aided the 17 decision process. Where appropriate, this document also provides 18 brief notes on design decisions that changed as the specification was 19 reviewed and updated by the IETF SIDR working group, resulting in RFC 20 8205. These notes highlight the differences and provide pointers to 21 details and rationale about those design changes. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 23, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Creating Signatures and the Structure of BGPsec Update 59 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Origin Validation Using ROA . . . . . . . . . . . . . . . 4 61 2.2. Attributes Signed by an Originating AS . . . . . . . . . 5 62 2.3. Attributes Signed by an Upstream AS . . . . . . . . . . . 6 63 2.4. What Attributes Are Not Signed . . . . . . . . . . . . . 7 64 2.5. Receiving Router Actions . . . . . . . . . . . . . . . . 8 65 2.6. Prepending of ASes in AS Path . . . . . . . . . . . . . . 9 66 2.7. What RPKI Data Need be Included in Updates . . . . . . . 9 67 3. Withdrawal Protection . . . . . . . . . . . . . . . . . . . . 10 68 3.1. Withdrawals Not Signed . . . . . . . . . . . . . . . . . 10 69 3.2. Signature Expire Time for Withdrawal Protection (a.k.a. 70 Mitigation of Replay Attacks) . . . . . . . . . . . . . . 10 71 3.3. Should Route Expire Time be Communicated in a Separate 72 Message . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 3.4. Effect of Expire-Time Updates in BGPsec on RFD . . . . . 13 74 4. Signature Algorithms and Router Keys . . . . . . . . . . . . 14 75 4.1. Signature Algorithms . . . . . . . . . . . . . . . . . . 14 76 4.2. Agility of Signature Algorithms . . . . . . . . . . . . . 15 77 4.3. Sequential Aggregate Signatures . . . . . . . . . . . . . 16 78 4.4. Protocol Extensibility . . . . . . . . . . . . . . . . . 17 79 4.5. Key Per Router (Rogue Router Problem) . . . . . . . . . . 18 80 4.6. Router ID . . . . . . . . . . . . . . . . . . . . . . . . 18 81 5. Optimizations and Resource Sizing . . . . . . . . . . . . . . 18 82 5.1. Update Packing and Repacking . . . . . . . . . . . . . . 19 83 5.2. Signature Per Prefix vs. Signature Per Update . . . . . . 19 84 5.3. Maximum BGPsec Update PDU Size . . . . . . . . . . . . . 20 85 5.4. Temporary Suspension of Attestations and Validations . . 21 86 6. Incremental Deployment and Negotiation of BGPsec . . . . . . 22 87 6.1. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 22 88 6.2. Inclusion of Address Family in Capability Advertisement . 22 89 6.3. Incremental Deployment: Capability Negotiation . . . . . 23 90 6.4. Partial Path Signing . . . . . . . . . . . . . . . . . . 23 91 6.5. Consideration of Stub ASes with Resource Constraints: 92 Encouraging Early Adoption . . . . . . . . . . . . . . . 24 93 6.6. Proxy Signing . . . . . . . . . . . . . . . . . . . . . . 25 94 6.7. Multiple Peering Sessions Between ASes . . . . . . . . . 26 95 7. Interaction of BGPsec with Common BGP Features . . . . . . . 26 96 7.1. Peer Groups . . . . . . . . . . . . . . . . . . . . . . . 26 97 7.2. Communities . . . . . . . . . . . . . . . . . . . . . . . 27 98 7.3. Consideration of iBGP Speakers and Confederations . . . . 28 99 7.4. Consideration of Route Servers in IXPs . . . . . . . . . 28 100 7.5. Proxy Aggregation (a.k.a. AS_SETs) . . . . . . . . . . . 29 101 7.6. 4-Byte AS Numbers . . . . . . . . . . . . . . . . . . . . 30 102 8. BGPsec Validation . . . . . . . . . . . . . . . . . . . . . . 30 103 8.1. Sequence of BGPsec Validation Processing in a Receiver . 30 104 8.2. Signing and Forwarding Updates when Signatures Failed 105 Validation . . . . . . . . . . . . . . . . . . . . . . . 32 106 8.3. Enumeration of Error Conditions . . . . . . . . . . . . . 32 107 8.4. Procedure for Processing Unsigned Updates . . . . . . . . 33 108 8.5. Response to Syntactic Errors in Signatures and 109 Recommendation for Reaction . . . . . . . . . . . . . . . 34 110 8.6. Enumeration of Validation States . . . . . . . . . . . . 35 111 8.7. Mechanism for Transporting Validation State through iBGP 36 112 9. Operational Considerations . . . . . . . . . . . . . . . . . 38 113 9.1. Interworking with BGP Graceful Restart . . . . . . . . . 38 114 9.2. BCP Recommendations for Minimizing Churn: Certificate 115 Expiry/Revocation and Signature Expire Time . . . . . . . 39 116 9.3. Outsourcing Update Validation . . . . . . . . . . . . . . 39 117 9.4. New Hardware Capability . . . . . . . . . . . . . . . . . 40 118 9.5. Signed Peering Registrations . . . . . . . . . . . . . . 40 119 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 120 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 121 12. Informative References . . . . . . . . . . . . . . . . . . . 41 122 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 46 123 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 47 124 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48 126 1. Introduction 128 The goal of BGPsec effort is to enhance the security of BGP by 129 enabling full AS path validation based on cryptographic principles. 130 Standards work on route origin validation based on a Resource 131 certificate PKI (RPKI) is already completed or nearing completion in 132 the IETF SIDR WG. The BGPsec effort is aimed at taking advantage of 133 the same RPKI infrastructure developed in the SIDR WG to add 134 cryptographic signatures to BGP updates, so that routers can perform 135 full AS path validation [RFC7132] [RFC7353] [RFC8205]. The BGPsec 136 protocol specification RFC was published recently [RFC8205]. The key 137 high-level design goals of the BGPsec protocol are as follow 138 [RFC7353]: 140 o Rigorous path validation for all announced prefixes; not merely 141 showing that a path is not impossible. 143 o Incremental deployment capability; no flag-day requirement for 144 global deployment. 146 o Protection of AS paths only in inter-domain routing (eBGP); not 147 applicable to iBGP (or to IGPs). 149 o Aim for no increase in provider's data exposure (e.g., require no 150 disclosure of peering relations, etc.). 152 This document provides design justifications for the initial draft of 153 the BGPsec protocol specification [I-D.lepinski-bgpsec-protocol]. 154 The designers needed to balance many competing factors, and this 155 document lists the decisions that were made in favor of or against 156 each design choice. This document also presents brief summaries of 157 the discussions that weighed in the pros and cons and aided the 158 decision process. Where appropriate, this document provides brief 159 notes (starting with "Note:") on design decisions that changed from 160 the approach taken in the initial draft of the BGPsec protocol 161 specification as the specification was reviewed and updated by the 162 IETF SIDR working group, resulting in [RFC8205]. The notes provide 163 pointers to the details and/or discussion about the design changes. 165 The design choices and discussions are presented under the following 166 eight broad categories (with many subtopics within each category): 167 (1) Creating Signatures and the Structure of BGPsec Update Messages, 168 (2) Withdrawal Protection, (3) Signature Algorithms and Router Keys, 169 (4) Optimizations and Resource Sizing, (5) Incremental Deployment and 170 Negotiation of BGPsec, (6) Interaction of BGPsec with Common BGP 171 Features, (7) BGPsec Validation, and (8) Operational Considerations. 173 2. Creating Signatures and the Structure of BGPsec Update Messages 175 2.1. Origin Validation Using ROA 177 2.1.1. Decision 179 Route origin validation using Route Origin Authorization (ROA) 180 [RFC6482] [RFC6811] is necessary and complements AS path attestation 181 based on signed updates. Thus, BGPsec design makes use of the origin 182 validation capability facilitated by the ROAs in RPKI. 184 Note: In the finalized BGPsec protocol specification [RFC8205], 185 BGPsec is synonymous with cryptographic AS path attestation. Origin 186 validation and BGPsec (path signatures) are the two key pieces of the 187 SIDR WG solution for BGP security. 189 2.1.2. Discussion 191 Route origin validation using RPKI constructs as developed in the 192 IETF SIDR WG is a necessary component of BGP security. It provides 193 cryptographic validation that the first hop AS is authorized to 194 originate a route for the prefix in question. 196 2.2. Attributes Signed by an Originating AS 198 2.2.1. Decision 200 An originating AS will sign over the NLRI length, NLRI prefix, its 201 own AS number (ASN), the next ASN, the signature algorithm suite ID, 202 and a signature Expire Time (see Section 3.2) for the update. The 203 update signatures will be carried in a new optional, non-transitive 204 BGP attribute. 206 Note: The finalized BGPsec protocol specification [RFC8205] differs 207 from the above. There is no mention of a signature Expire Time field 208 in the BGPsec update in RFC 8205. Further, there are some additional 209 details concerning attributes signed by the origin AS that can be 210 found in Figure 8 in Section 4.2 of RFC 8205 [RFC8205]. In 211 particular, the signed data also includes the Address Family 212 Identifier (AFI) in RFC 8205. By adding the AFI in the data covered 213 by signature, a specific security concern was alleviated; see SIDR 214 list post [Mandelberg1] and the discussion thread that followed on 215 the topic. The AFI is obtained from the MP_REACH_NLRI attribute in 216 the BGPsec update. It is stated in Section 4.1 of RFC 8205 that 217 BGPsec update message MUST use the MP_REACH_NLRI attribute [RFC4760] 218 to encode the prefix. 220 2.2.2. Discussion 222 The next hop ASN is included in the data covered by the signature. 223 Without that the AS path cannot be secured; for example, it can be 224 shortened (by a MITM) without being detected. 226 It was decided that only the originating AS needs to insert a 227 signature Expire Time in the update, as it is the originator of the 228 route. The origin AS also will re-originate, i.e., beacon, the 229 update prior to the Expire Time of the advertisement (see 230 Section 3.2). (For an explanation of why upstream ASes do not insert 231 their respective signature Expire Times, please see Section 3.2.2.) 233 Note: Expire Time and beaconing were eventually replaced by router 234 key rollover. The BGPsec protocol [RFC8205] is expected to make use 235 of router key rollover to mitigate against replay attacks and 236 withdrawal suppression [I-D.ietf-sidrops-bgpsec-rollover] 237 [I-D.sriram-replay-protection-design-discussion]. 239 It was decided that each signed update would include only one NLRI 240 prefix. If more than one NLRI prefix were included, and an upstream 241 AS elected to propagate the advertisement for a subset of the 242 prefixes, then the signature(s) on the update would break (see 243 Section 5.1 and Section 5.2). If a mechanism were employed to 244 preserve prefixes that were dropped, this would reveal info to later 245 ASes that is not revealed in normal BGP operation. Thus, a tradeoff 246 was made to preserve the level of route info exposure that is 247 intrinsic to BGP over the performance hit implied by limiting each 248 update to carry only one prefix. 250 The signature data is carried in an optional, non-transitive BGP 251 attribute. The attribute is optional because this is the standard 252 mechanism available in BGP to propagate new types of data. It was 253 decided that the attribute should be non-transitive because of 254 concern about the impact of sending the (potentially large) 255 signatures to routers that don't understand them. Also, if a router 256 that doesn't understand BGPsec somehow gets a message with the 257 signatures attribute then it would be undesirable for that router to 258 forward the signatures to all its neighbors, especially those who do 259 not understand BGPsec and may choke if they receive many updates with 260 large optional BGP attributes. It is envisioned that BGPsec and 261 traditional BGP will co-exist while BGPsec is deployed incrementally. 263 2.3. Attributes Signed by an Upstream AS 265 In the context of BGPsec and throughout this document, an "upstream 266 AS" simply refers to an AS that is further along in an AS path 267 (origin AS being the nearest to a prefix). In principle, an AS that 268 is upstream from an originating AS would digitally sign the combined 269 information including the NLRI length, NLRI prefix, AS path, next 270 ASN, signature algorithm suite ID, and Expire Time. There are 271 multiple choices for what is signed by an upstream AS as follows. 272 Method 1: Signature protects the combination of NLRI length, NLRI 273 prefix, AS path, next ASN, signature algorithm suite ID, and Expire 274 Time; or Method 2: Signature protects just the combination of 275 previous signature (i.e., signature of the neighbor AS who forwarded 276 the update) and next ASN; or Method 3: Signature protects everything 277 that was received from preceding AS plus next (i.e., target) ASN; 278 thus, ASi signs over NLRI length, NLRI prefix, signature algorithm 279 suite ID, Expire Time, {ASi, AS(i-1), AS(i-2), ..., AS2, AS1}, 280 AS(i+1)(i.e., next ASN), and {Sig(i-1), Sig(i-2), ..., Sig2, Sig1}. 282 Note: Please see the notes in Section 2.2.1 and Section 2.2.2 about 283 elimination of Expire Time field in the finalized BGPsec protocol 284 specification [RFC8205]. 286 2.3.1. Decision 288 It was decided that that Method 2 will be used. Please see 289 [I-D.lepinski-bgpsec-protocol] for additional protocol details and 290 syntax. 292 Note: The finalized BGPsec protocol specification [RFC8205] 293 essentially uses Method 3 (except for Expire Time). Additional 294 details concerning attributes signed by an upstream AS can be found 295 in Figure 8 in Section 4.2 of RFC 8205 [RFC8205]. The decision to go 296 with Method 3 (with suitable additions to the data signed) was 297 motivated by a security concern that was associated with Method 2; 298 see SIDR list post [Mandelberg2] and the discussion thread that 299 followed on the topic. Also, there is a strong rationale for the 300 sequence octets to be hashed (as shown in Figure 8 in Section 4.2 of 301 RFC 8205) and this sequencing of data is motivated by implementation 302 efficiency considerations; see SIDR list post [Borchert] for an 303 explanation. 305 2.3.2. Discussion 307 The rationale for this choice (Method 2) was as follows. Signatures 308 are performed over hash blocks. When the number of bytes to be 309 signed exceeds one hash block, then the remaining bytes will overflow 310 into a second hash block, which results in performance penalty. So 311 it is advantageous to minimize the number of bytes being hashed. 312 Also, an analysis of the three options noted above did not identify 313 any vulnerabilities associated with this approach. 315 2.4. What Attributes Are Not Signed 317 2.4.1. Decision 319 Any attributes other than those identified in Section 2.2 and 320 Section 2.3 are not signed. Examples of such attributes are 321 Community Attribute, NO-EXPORT Attribute, Local_Pref, etc. 323 2.4.2. Discussion 325 The above stated attributes that are not signed are viewed as local 326 (e.g., do not need to propagate beyond next hop) or lack clear 327 security needs. NO-EXPORT is sent over a secured next-hop and does 328 not need signing. BGPsec design should work with any transport layer 329 protections. It is well understood that the transport layer must be 330 protected hop by hop (if only to prevent malicious session 331 termination). 333 2.5. Receiving Router Actions 335 2.5.1. Decision 337 The expected router actions on receipt of a signed update are 338 described by the following example. Consider an update that was 339 originated by AS1 with NLRI prefix p and has traversed the AS path 340 [AS(i-1) AS(i-2) .... AS2 AS1] before arriving at ASi. Let the 341 Expire Time (inserted by AS1) for the signature in this update be 342 denoted as Te. Let AlgID represent the ID of the signature algorithm 343 suite that is in use. The update is to be processed at ASi and 344 possibly forwarded to AS(i+1). Let the attestations (signatures) 345 inserted by each router in the AS path be denoted by Sig1, Sig2, ..., 346 Sig(i-2), and Sig(i-1) corresponding to AS1, AS2, ... , AS(i-2), and 347 AS(i-1), respectively. 349 The method (#2 in Section 2.3) selected for signing requires a 350 receiving router in ASi to perform the following actions: 352 o Validate the route origin pair (p, AS1) by performing a ROA match. 354 o Verify that Te is greater than the clock time at the router 355 performing these checks. 357 o Check Sig1 with inputs {NLRI length, p, AlgID, Te, AS1, AS2}. 359 o Check Sig2 with inputs {Sig1, AS3}. 361 o Check Sig3 with inputs {Sig2, AS4}. 363 o ... 365 o ... 367 o Check Sig(i-2) with inputs {Sig(i-3), AS(i-1)}. 369 o Check Sig(i-1) with inputs {Sig(i-2), ASi}. 371 o If the route that has been verified is selected as the best path 372 (for prefix p), then generate Sig(i) with inputs {Sig(i-1), 373 AS(i+1)}, and generate an update including Sig(i) to AS(i+1). 375 Note: The above description of BGPsec update validation and 376 forwarding differs in its details from the published BGPsec protocol 377 specification [RFC8205]. Please see Sections 4 and 5 of [RFC8205]. 379 2.5.2. Discussion 381 See Section 8.1 for suggestions regarding efficient sequencing of 382 BGPsec validation processing in a receiving router. Some or all the 383 validation actions may be performed by an off-board server (see 384 Section 9.3). 386 2.6. Prepending of ASes in AS Path 388 2.6.1. Decision 390 Prepending will be allowed. Prepending is defined as including more 391 than one instance of the AS number (ASN) of the router that is 392 signing the update. 394 Note: The finalized protocol specification uses a pCount field 395 associated with each AS in the path to indicate the number of 396 prepends for that AS (see Figure 5, Section 3.1 of [RFC8205]). 398 2.6.2. Discussion 400 The draft-00 version of the protocol specification calls for a 401 signature to be associated with each prepended AS. The optimization 402 of having just one signature for multiple prepended ASes will be 403 pursued later (i.e., beyond draft-00 specification). If such 404 optimization is used, a replication count would be included (in the 405 signed update) to specify how many times an AS was prepended. 407 2.7. What RPKI Data Need be Included in Updates 409 2.7.1. Decision 411 Concerning inclusion of RPKI data in an update, it was decided that 412 only the Subject Key Identifier (SKI) of the router cert must be 413 included in a signed update. This info identifies the router 414 certificate, based on the SKI generation criteria defined in 415 [RFC6487]. 417 2.7.2. Discussion 419 It was discussed if each router public key certificate should be 420 included in a signed update. Inclusion of this information might be 421 helpful for routers that do not have access to RPKI servers or 422 temporarily lose connectivity to them. It is safe to assume that in 423 majority of network environments, intermittent connectivity would not 424 be a problem. So it is best to avoid this complexity because 425 majority of the use environments do not have connectivity 426 constraints. Because the SKI of a router certificate is a hash of 427 the public key of that certificate, it suffices to select the public 428 key from that certificate. This design assumes that each BGPsec 429 router has access to a cache containing the relevant data from 430 (validated) router certificates. 432 3. Withdrawal Protection 434 3.1. Withdrawals Not Signed 436 3.1.1. Decision 438 Withdrawals are not signed. 440 3.1.2. Discussion 442 In the current BGP protocol, any AS can withdraw, at any time, any 443 prefix it previously announced. The rationale for not signing 444 withdrawals is that BGPsec assumes use of transport security between 445 neighboring BGPsec routers. Thus, no external entity can inject an 446 update that withdraws a route or replay a previously transmitted 447 update containing a withdrawal. Because the rationale for 448 withdrawing a route is not visible to a neighboring BGPsec router, 449 there are residual vulnerabilities associated with withdrawals. For 450 example, a router that advertised a (valid) route may fail to 451 withdraw that route when it is no longer viable. A router also might 452 re-advertise a route that it previously withdrew, before the route is 453 again viable. This latter vulnerability is mitigated by the Expire 454 Time value in an AS path signature (see Section 3.2). 456 Repeated withdrawals and announcements for a prefix can run up the 457 BGP RFD penalty and may result in unreachability for that prefix at 458 upstream routers. But what can the attacker gain from doing so? 459 This phenomenon is intrinsic to the design and operation of RFD. 461 3.2. Signature Expire Time for Withdrawal Protection (a.k.a. 462 Mitigation of Replay Attacks) 464 3.2.1. Decision 466 Note: As mentioned earlier in Section 2.2.2, the Expire Time approach 467 to mitigation of replay attacks and withdrawal suppression was 468 subsequently changed to an approach based on router key rollover 469 [I-D.ietf-sidrops-bgpsec-rollover] 470 [I-D.sriram-replay-protection-design-discussion]. 472 Only the originating AS inserts a signature Expire Time in the 473 update; all other ASes along an AS path do not insert Expire Times 474 associated with their respective signatures. Further, the 475 originating AS will re-originate a route sufficiently in advance of 476 the Expire Time of its signature so that other ASes along an AS path 477 will typically receive the re-originated route well ahead of the 478 current Expire Time for that route. 480 The duration of the signature Expire Time is recommended to be on the 481 order of days (preferably) but it may be on the order of hours (about 482 4 to 8 hours) in some cases, where extra replay protection is 483 perceived to be critical. 485 Each AS should stagger the Expire Time values in the routes it 486 originates. Re-origination will be done, say, at time Tb after 487 origination or the last re-origination, where Tb will equal a certain 488 percentage of the Expire Time, Te (for example, Tb = 0.75 x Te). The 489 percentage will be configurable and additional guidance can be 490 provided via an operational considerations document later. Further, 491 the actual re-origination time should to be jittered with a uniform 492 random distribution over a short interval {Tb1, Tb2} centered at Tb. 494 It is also recommended that a receiving BGPsec router should detect 495 if the only attribute change in an announcement (relative to the 496 current best path) is the expire time (besides, of course, the 497 signatures). In that case, assuming that the update is found valid, 498 the route processor should not re-announce the route to non-BGPsec 499 peers. (It should sign and re-announce the route to only BGPsec 500 speakers.) This procedure will reduce BGP chattiness for the non- 501 BGPsec border routers. 503 3.2.2. Discussion 505 Mitigation of BGPsec update replay attacks can be thought of as 506 protection against malicious re-advertisement of withdrawn routes. 507 If each AS along a path were to insert its own signature Expire Time, 508 then there would be much additional BGP chattiness and increase in 509 BGP processing load due to the need to detect and react to multiple 510 (possibly redundant) signature Expire Times. Furthermore, there 511 would be no extra benefit from the point of view of mitigation of 512 replay attacks as compared to having a single Expire Time 513 corresponding to the signature of the originating AS. 515 The recommended Expire Time value is on the order of days but 4 to 8 516 hours may used in some cases on the basis of perceived need for extra 517 protection from replay attacks. Thus, different ASes may choose 518 different values based on the perceived need to protect against 519 malicious route replays. (A shorter Expire Time reduces the window 520 during which an AS can maliciously replay the route. However, 521 shorter Expire Time values cause routes to be refreshed more often, 522 and thus causes more BGP chatter.) Even a 4 hours duration seems 523 long enough to keep the re-origination workload manageable. For 524 example, if 500K routes are re-originated every 4 hours, it amounts 525 to an increase in BGP update load of 35 updates per second; this can 526 be considered reasonable. However, further analysis is needed to 527 confirm these recommendations. 529 It was stated above that originating AS will re-originate a route 530 sufficiently in advance of its Expire Time. What is considered 531 sufficiently in advance? For this, modeling should be performed to 532 determine the 95th-percentile convergence time of update propagation 533 in BGPsec enabled Internet. 535 Each BGPsec router should stagger the Expire Time values in the 536 updates it originates, especially during table dumps to a neighbor or 537 during its own recovery from a BGP session failure. By doing this, 538 the re-origination (i.e., beaconing) workload at the router will be 539 dispersed. 541 3.3. Should Route Expire Time be Communicated in a Separate Message 543 3.3.1. Decision 545 The idea of sending a new signature expire time in a special message 546 (rather than re-transmitting the entire update with signatures) was 547 considered. However, it was decided not to do this. Re-origination 548 to communicate a new signature Expire Time will be done by 549 propagation of a normal update message; no special type of message 550 will be required. 552 3.3.2. Discussion 554 It was suggested that if re-beaconing of signature Expire Time is 555 carried in a separate special message, then update processing load 556 may be reduced. But it was recognized that such re-beaconing message 557 necessarily entails AS path and prefix information, and hence cannot 558 be separated from the update. 560 It was observed that at the edge of the Internet, there are frequent 561 updates that may result from simple situations like BGP session being 562 switched from one interface to another (e.g., from primary to backup) 563 between two peering ASes (e.g., customer and provider). With 564 traditional BGP, these updates do not propagate beyond the two ASes 565 involved. But with BGPsec, the customer AS will put in a new 566 signature Expire Time each time such an event happens, and hence the 567 update will need to propagate throughout the Internet (limited only 568 by best path selection process). It was accepted that this cost of 569 added churn will be unavoidable. 571 3.4. Effect of Expire-Time Updates in BGPsec on RFD 573 3.4.1. Decision 575 With regard to the Route Flap Damping (RFD) protocol 576 [RFC2439][JunOS][CiscoIOS], no differential treatment is required for 577 Expire-Time triggered (re-beaconed) BGPsec updates. 579 However, it was noted that it would be preferable if these updates 580 did not cause route churn (and perhaps not even require any RFD 581 related processing), since they are identical except for the change 582 in the Expire Time value. The way this can be accomplished is by not 583 assigning RFD penalty to Expire-Time triggered updates. If the 584 community agrees, this could be accommodated, but a change to the 585 BGP-RFD protocol specification will be required. 587 3.4.2. Discussion 589 Summary: 591 The decision is supported by the following observations: (1) Expire 592 Time-triggered updates are generally not preceded by withdrawals, and 593 hence the path hunting and associated RFD exacerbation 594 [Mao02][RIPE580] problems are not anticipated; (2) Such updates would 595 not normally change the best path (unless another concurrent event 596 impacts the best path); (3) Expire Time-triggered updates would have 597 negligible impact on RFD penalty accumulation because the re- 598 advertisement interval is much longer relative to the half-time of 599 decay of RFD penalty. Elaborating further on reason #3 above, it may 600 be noted that the re-advertisements (i.e., beacons) of a route for a 601 given address prefix from a given peer will be received at intervals 602 of a few or several hours (see Section 3.2). During that time 603 period, any incremental contribution to RFD penalty due to a Expire 604 Time-triggered update would decay sufficiently to have negligible (if 605 any) impact on damping the address prefix in consideration. 606 Additional details of this analysis and justification can be found 607 below. 609 Further Details of the Analysis and Justification: 611 The frequency with which RFD penalty increments may be triggered for 612 a given prefix from a given peer is the same as the re-beaconing 613 frequency for that prefix from its origin AS. The re-beaconing 614 frequency is on the order of once every few or several hours (see 615 Section 3.2). The incremental RFD penalty assigned to a prefix due 616 to a re-beaconed update varies depending on the implementation. For 617 example, it appears that JunOS implementation [JunOS] would assign a 618 penalty of 1000 or 500 depending on whether the re-beaconed update is 619 regarded as a re-advertisement or an attribute change, respectively. 620 Normally, a re-beaconed update would be treated as a case of 621 attribute change. The Cisco implementation [CiscoIOS] on the other 622 hand assigns an RFD penalty only in the case of an actual flap (i.e., 623 a route is available, then unavailable, or vice versa). So it 624 appears that Cisco implementation of RFD would not assign any penalty 625 for a re-beaconed update (i.e., a route was already advertised 626 previously; not withdrawn; and the re-beaconed update is merely 627 updating the expire time attribute). Even if one assumes that an RFD 628 penalty of 500 is assigned (corresponding to attribute change in 629 JunOS RFD implementation), it can be illustrated that the incremental 630 affect it would have on damping the prefix in consideration would be 631 negligible. The reason for this is as follows. The half-time of RFD 632 penalty decay is normally set to 15 minutes, whereas the re-beaconing 633 frequency is on the order of once every few or several hours. An 634 incremental penalty of 500 would decay to 31.25 in one hour; 0.12 in 635 two hours; 3x10^(-5) in three hours. It may also be noted that the 636 threshold for route suppression is 3000 in JunOS and 2000 in Cisco 637 IOS. Based on the foregoing analysis, it may be concluded that 638 routine re-beaconing by itself would not result in RFD suppression of 639 routes in the BGPsec protocol. 641 4. Signature Algorithms and Router Keys 643 4.1. Signature Algorithms 645 4.1.1. Decision 647 Initially, ECDSA with Curve P-256 and SHA-256 will be used for 648 generating BGPsec path signatures. One other signature algorithm, 649 e.g., RSA-2048 will also be used during prototyping and testing. The 650 use of a second signature algorithm is needed to verify the ability 651 of the BGPsec implementations to change from a current algorithm to 652 the next algorithm. 654 Note: The BGPsec cryptographic algorithms document [RFC8208] 655 specifies only ECDSA with Curve P-256 and SHA-256. 657 4.1.2. Discussion 659 Initially, choice of RSA-2048 algorithm for BGPsec update signatures 660 was considered because it is being used ubiquitously in the RPKI 661 system. However, the use of ECDSA P-256 algorithm was decided 662 because it yields a smaller signature size, and hence the update size 663 and in turn the RIB size needed in BGPsec routers would be much 664 smaller [RIB_size]. 666 Testing with two different signature algorithms (e.g., ECDSA P-256 667 and RSA-2048) for transition from one to the other will increase 668 confidence in prototype implementations. 670 For Elliptic Curve Cryptography (ECC) algorithms, according to 671 [RFC6090], optimizations and specialized algorithms (e.g., for speed- 672 ups) have active IPR, but the basic (unoptimized) algorithms do not 673 have IPR encumbrances. 675 Note: Recently, even open source implementations have incorporated 676 certain cryptographic optimizations and demonstrated significant 677 performance speedup [Gueron]. Researchers continue to devote 678 significant efforts to demonstrate substantial speedup for ECDSA as 679 part of BGPsec implementations [Mehmet1] [Mehmet2]. 681 4.2. Agility of Signature Algorithms 683 4.2.1. Decision 685 During the transition period from one algorithm, i.e., current 686 algorithm, to the next (new) algorithm, the updates will carry two 687 sets of signatures (i.e., two Signature-List Blocks), one 688 corresponding to each algorithm. Each Signature-List Block will be 689 preceded by its type-length field and an algorithm-suite identifier. 690 A BGPsec speaker that has been upgraded to handle the new algorithm 691 should validate both Signature-List Blocks, and then add its 692 corresponding signature to each Signature-List Block for forwarding 693 the update to the next AS. A BGPsec speaker that has not been 694 upgraded to handle the new algorithm will strip off the Signature- 695 List Block of the new algorithm, and forward the update after adding 696 its own sig to the Signature-List Block of the current algorithm. 698 It was decided that there will be at most two Signature-List Blocks 699 per update. 701 Note: Signature-List Block is Signature_Block in RFC 8205. The 702 algorithm agility scheme described in the published BGPsec protocol 703 specification is consistent with the above; see Section 6.1 of 704 [RFC8205]. 706 4.2.2. Discussion 708 A length field in the Signature-List Block allows for delineation of 709 the two signature blocks. Hence, a BGPsec router that doesn't know 710 about a particular algorithm suite (and hence doesn't know how long 711 signatures were for that algorithm suite) could still skip over the 712 corresponding Signature-List Block when parsing the message. 714 The overlap period between the two algorithms is expected to last two 715 to four years. The RIB memory and cryptographic processing capacity 716 will have to be sized to cope with such overlap periods when updates 717 would contain two sets of signatures [RIB_size]. 719 The lifetime of a signature algorithm is anticipated to be much 720 longer than the duration of a transition period from current to new 721 algorithm. It is fully expected that all ASes will have converted to 722 the required new algorithm within a certain amount of time that is 723 much shorter than the interval in which a subsequent newer algorithm 724 may be investigated and standardized for BGPsec. Hence, the need for 725 more than two Signature-List Blocks per update is not envisioned. 727 4.3. Sequential Aggregate Signatures 729 4.3.1. Decision 731 There is currently weak or no support for the Sequential Aggregate 732 Signature (SAS) approach. Please see in the discussion section below 733 for a brief description of what SAS is and what its pros and cons 734 are. 736 4.3.2. Discussion 738 In Sequential Aggregate Signature (SAS) method, there would be only 739 one (aggregated) signature per signature block, irrespective of the 740 number of AS hops. For example, ASn (nth AS) takes as input the 741 signatures of all previous ASes [AS1, ..., AS(n-1)] and produces a 742 single composite signature. This composite signature has the 743 property that a recipient who has the public keys for AS1, ..., ASn 744 can verify (using only the single composite signature) that all of 745 the ASes actually signed the message. SAS could potentially result 746 in savings in bandwidth, PDU size, and maybe in RIB size but the 747 signature generation and validation costs will be higher as compared 748 to one signature per AS hop. 750 SAS schemes exist in the literature, typically based on RSA or 751 equivalent. For SAS with RSA and for the cryptographic strength 752 needed for BGPsec signatures, a 2048-bit signature size (RSA-2048) 753 would be required. However, without SAS, ECDSA with 512-bit 754 signature (256-bit key) would suffice for equivalent cryptographic 755 strength. The larger signature size of RSA used with SAS undermines 756 the advantages of SAS, because the average hop count, i.e., number of 757 ASes, for a route is about 3.8. In the end, it may turn out that SAS 758 has more complexity and does not provide sufficient savings in PDU 759 size or RIB size to merit its use. Further exploration of this is 760 needed to better understand SAS properties and applicability for 761 BGPsec. There is also a concern that SAS is not a time-tested 762 cryptographic technique and thus its adoption is potentially risky. 764 4.4. Protocol Extensibility 766 There is a clearly a need to specify a transition path from a current 767 protocol specification to a new version. When changes to the 768 processing of the BGPsec path signatures are required, that will 769 require a new version of BGPsec. Examples of this include changes to 770 the data that is protected by the BGPsec signatures or adoption of a 771 signature algorithm in which the number of signatures in the 772 signature block may not correspond to one signature per AS in the AS- 773 PATH (e.g., aggregate signatures). 775 4.4.1. Decision 777 The protocol-version transition mechanism here is analogous to the 778 algorithm transition discussed in Section 4.2. During the transition 779 period from one protocol version (i.e., current version) to the next 780 (new) version, updates will carry two sets of signatures (i.e., two 781 Signature-List Blocks), one corresponding to each version. A 782 protocol-version identifier is associated with each Signature-List 783 Block. Hence, each Signature-List Block will be preceded by its 784 type-length field and a protocol-version identifier. A BGPsec 785 speaker that has been upgraded to handle the new version should 786 validate both Signature-List Blocks, and then add its corresponding 787 signature to each Signature-List Block for forwarding the update to 788 the next AS. A BGPsec speaker that has not been upgraded to handle 789 the new protocol version will strip off the Signature-List Block of 790 the new version, and forward the update with an attachment of its own 791 signature to the Signature-List Block of the current version. 793 Note: Signature-List Block is Signature_Block in RFC 8205. The 794 details of protocol extensibility (i.e., transition to a new version 795 of BGPsec) in the published BGPsec protocol specification (see 796 Section 6.3 in [RFC8205]) differ somewhat from the above. In 797 particular, the protocol-version identifier is not part of the BGPsec 798 update. Instead, it is negotiated during BGPsec capability exchange 799 during the BGPsec session negotiation. 801 4.4.2. Discussion 803 In the case that change to BGPsec is deemed desirable, it is expected 804 that a subsequent version of BGPsec would be created and that this 805 version of BGPsec would specify a new BGP Path Attribute, let's call 806 it BGPsec_PATH_SIG_TWO, which is designed to accommodate the desired 807 changes to BGPsec. At this point a transition would begin which is 808 analogous to the algorithm transition discussed in Section 4.2. 810 During the transition period, all BGPsec speakers will simultaneously 811 include both the BGPsec_Path_Signatures (current) attribute and the 812 new BGPsec_PATH_SIG_TWO attribute. Once the transition is complete, 813 the use of BGPsec_Path_Signatures could then be deprecated, at which 814 point BGPsec speakers will include only the new BGPsec_PATH_SIG_TWO 815 attribute. Such a process could facilitate a transition to a new 816 BGPsec semantics in a backwards compatible fashion. 818 4.5. Key Per Router (Rogue Router Problem) 820 4.5.1. Decision 822 Within each AS, each individual BGPsec router can have a unique pair 823 of private and public keys [RFC8207]. 825 4.5.2. Discussion 827 Given unique key pair per router, if a router is compromised, its key 828 pair can be revoked independently, without disrupting the other 829 routers in the AS. Each per-router key-pair will be represented in 830 an end-entity certificate issued under the CA cert of the AS. The 831 Subject Key Identifier (SKI) in the signature points to the router 832 certificate (and thus the unique public key) of the router that 833 affixed its signature, so that a validating router can reliably 834 identify the public key to use for signature verification. 836 4.6. Router ID 838 4.6.1. Decision 840 The router certificate Subject name will be the string "router" 841 followed by a decimal representation of a 4-byte AS number followed 842 by the router ID. See the current RFCs for preferred standard 843 textual representations for 4-byte ASNs [RFC5396] and router IDs 844 [RFC6891]. 846 4.6.2. Discussion 848 Every X.509 certificate requires a Subject name. The stylized 849 Subject name adopted here is intended to facilitate debugging, by 850 including the ASN and router ID. 852 5. Optimizations and Resource Sizing 853 5.1. Update Packing and Repacking 855 With traditional BGP protocol [RFC4271], an originating BGP router 856 normally packs multiple prefix announcements into one update if the 857 prefixes all share the same BGP attributes. When an upstream BGP 858 router forwards eBGP updates to its peers, it can also pack multiple 859 prefixes (based on shared AS path and attributes) into one update. 860 The update propagated by the upstream BGP router may include only a 861 subset of the prefixes that were packed in a received update. 863 5.1.1. Decision 865 Each update contains exactly one prefix. This avoids the complexity 866 that would be otherwise inevitable if the origin had packed and 867 signed multiple prefixes in an update and an upstream AS decided to 868 propagate an update containing only a subset of the prefixes in that 869 update. BGPsec recommendation regarding packing and repacking may be 870 be revisited when optimizations are considered in the future. 872 5.1.2. Discussion 874 Currently, with traditional BGP, there are, on average, approximately 875 4 prefixes announced per update [RIB_size]. So the number of BGP 876 updates (carrying announcements) is about 4 times fewer, on average, 877 as compared to the number of prefixes announced. 879 The current decision is to include only one prefix per secured update 880 (see Section 2.2 and Section 2.3). When optimizations are considered 881 in the future, the possibility of packing multiple prefixes into an 882 update can be considered. (Please see Section 5.2 for a discussion 883 of signature per prefix vs. signature per update.) Repacking could 884 be performed if signatures were generated on a per prefix basis. 885 However, one problem regarding this approach, i.e., multiple prefixes 886 in a BGP update but with a separate signature for each prefix, is 887 that the resulting BGP update violates the basic definition of a BGP 888 update. That is because the different prefixes will have different 889 signature and expire-time attributes, while a BGP update (by 890 definition) must have the same set of shared attributes for all 891 prefixes it carries. 893 5.2. Signature Per Prefix vs. Signature Per Update 895 5.2.1. Decision 897 The initial design calls for including exactly one prefix per update, 898 hence there is only one signature in each secured update (modulo 899 algorithm transition conditions). Optimizations will be examined 900 later. 902 5.2.2. Discussion 904 Some notes to assist in future optimization discussions: In the 905 general case of one signature per update, multiple prefixes may be 906 signed with one signature together with their shared AS path, next 907 ASN, and Expire Time. If signature per update is used, then there 908 are potentially savings in update PDU size as well as RIB memory 909 size. But if there are any changes made to the announced prefix set 910 along the AS path, then the AS where the change occurs would need to 911 insert an Explicit Path Attribute (EPA)[I-D.draft-clynn-s-bgp]. The 912 EPA conveys information regarding what the prefix set contained prior 913 to the change. There would be one EPA for each AS that made such a 914 modification, and there would be a way to associate each EPA with its 915 corresponding AS. This enables an upstream AS to be able to know and 916 to verify what was announced and signed by prior ASes in the AS path 917 (in spite of changes made to the announced prefix set along the way). 918 The EPA adds complexity to processing (signature generation and 919 validation), further increases the size of updates and, thus of the 920 RIB, and exposes data to downstream ASes that would not otherwise be 921 exposed. Not all the pros and cons of packing and repacking in the 922 context of signature per prefix vs. signature per update (with 923 packing) have been evaluated. But the current recommendation is for 924 having only one prefix per update (no packing); so there is no need 925 for the EPA attribute. 927 5.3. Maximum BGPsec Update PDU Size 929 The current BGP update message PDU size is limited to 4096 bytes 930 [RFC4271]. The question was raised if BGPsec would require a larger 931 update PDU size. 933 5.3.1. Decision 935 The current thinking is that the max PDU size should be increased to 936 64 KB [I-D.ietf-idr-bgp-extended-messages] so that there is 937 sufficient room to accommodate two signature-list blocks (i.e., one 938 block with a current algorithm and another block with a new signature 939 algorithm during a future transition period) for long AS paths. 941 Note: RFC 8205 states the following: "All BGPsec update messages MUST 942 conform to BGP's maximum message size. If the resulting message 943 exceeds the maximum message size, then the guidelines in Section 9.2 944 of RFC 4271 [RFC4271] MUST be followed." 946 5.3.2. Discussion 948 The current maximum message size for BGP updates is 4096 octets. 949 There is effort underway in the IETF to extend it to a larger size 950 [I-D.ietf-idr-bgp-extended-messages]. BGPsec will conform to 951 whatever maximum message size that is available for BGP while 952 adhering to the guidelines in Section 9.2 of RFC 4271 [RFC4271]. 954 Note: Estimates for the average and maximum sizes anticipated for 955 BGPsec update messages are provided in [MsgSize]. 957 5.4. Temporary Suspension of Attestations and Validations 959 5.4.1. Decision 961 If a BGPsec-capable router needs to temporarily suspend/defer signing 962 and/or validation of BGPsec updates during periods of route processor 963 overload, the router may do so even though such suspension/deferment 964 is not desirable. The specification does not forbid that. Following 965 any temporary suspension, the router should subsequently send signed 966 updates corresponding to the updates for which validation and signing 967 were skipped. The router also may choose to skip only validation but 968 still sign and forward updates during periods of congestion. 970 5.4.2. Discussion 972 In some situations, a BGPsec router may be unable to keep up with the 973 workload of performing signing and/or validation. This can happen, 974 for example, during BGP session recovery when a router has to send 975 the entire routing table to a recovering router in a neighboring AS 976 (see [CPUworkload]). So it is possible that a BGPsec router 977 temporarily pauses performing validation or signing of updates. When 978 the work load eases, the BGPsec router should clear the validation or 979 signing backlog, and send signed updates corresponding to the updates 980 for which validation and signing were skipped. During periods of 981 overload, the router may simply send unsigned updates (with 982 signatures dropped), or may sign and forward the updates with 983 signatures (even though the router itself has not yet verified the 984 signatures it received). 986 A BGPsec-capable AS may request (out-of-band) a BGPsec-capable peer 987 AS never to downgrade a signed update to an unsigned update. 988 However, in partial deployment scenarios, it is not possible for a 989 BGPsec router to require a BGPsec-capable eBGP peer to send only 990 signed updates, except for prefixes originated by the peer's AS. 992 Note: If BGPsec has not been negotiated with a peer, then a BGPsec 993 router forwards only unsigned updates to that peer. For this, the 994 sending router follows the reconstruction procedure of Section 4.4 in 995 [RFC8205] to generate an AS_PATH attribute corresponding to the 996 BGPsec_PATH attribute in a received signed update. If the above 997 mentioned temporary suspension is ever applied, then the same AS_PATH 998 reconstruction procedure should be utilized. 1000 6. Incremental Deployment and Negotiation of BGPsec 1002 6.1. Downgrade Attacks 1004 6.1.1. Decision 1006 No attempt will be made in BGPsec design to prevent downgrade 1007 attacks, i.e., a BGPsec-capable router sending unsigned updates when 1008 it is capable of sending signed updates. 1010 6.1.2. Discussion 1012 BGPsec allows routers to temporarily suspend signing updates (see 1013 Section 5.4). Therefore, it would be contradictory if we were to try 1014 to incorporate in the BGPsec protocol a way to detect and reject 1015 downgrade attacks. One proposed way for detecting downgrade attacks 1016 was considered, based on signed peering registrations (see 1017 Section 9.5). 1019 6.2. Inclusion of Address Family in Capability Advertisement 1021 6.2.1. Decision 1023 It was decided that during capability negotiation, the address family 1024 for which the BGPsec speaker is advertising support for BGPsec will 1025 be shared using the Address Family Identifier (AFI). Initially, two 1026 address families would be included, namely, IPv4 and IPv6. BGPsec 1027 for use with other address families may be specified in the future. 1028 Simultaneous use of the two (i.e., IPv4 and IPv6) address families 1029 for the same BGPsec session will require that the BGPsec speaker must 1030 include two instances of this capability (one for each address 1031 family) during BGPsec capability negotiation. 1033 6.2.2. Discussion 1035 If new address families are supported in the future, they will be 1036 added in future versions of the specification. A comment was made 1037 that too many version numbers are bad for interoperability. Re- 1038 negotiation on the fly to add a new address family (i.e., without 1039 changeover to new version number) is desirable. 1041 6.3. Incremental Deployment: Capability Negotiation 1043 6.3.1. Decision 1045 BGPsec will be incrementally deployable. BGPsec routers will use 1046 capability negotiation to agree to run BGPsec between them. If a 1047 BGPsec router's peer does not agree to run BGPsec, then the BGPsec 1048 router will run only traditional BGP with that peer, i.e., it will 1049 not send BGPsec (i.e., signed) updates to the peer. 1051 Note: See Section 7.9 of [RFC8205] for a discussion of incremental/ 1052 partial deployment considerations. Also, see Section 6 of [RFC8207] 1053 where it is described that edge sites (stub ASes) can sign updates 1054 that they originate but receive only unsigned updates. This 1055 facilitates less expensive upgrade to BGPsec in resource-limited stub 1056 ASes, and expedites incremental deployment. 1058 6.3.2. Discussion 1060 During partial deployment, there will be BGPsec islands as a result 1061 of this approach to incremental deployment. Updates that originate 1062 within a BGPsec island will generally propagate with signed AS paths 1063 to the edges of that island. As BGPsec adoption grows, the BGPsec 1064 islands will expand outward (subsuming non-BGPsec portions of the 1065 Internet) and/or pairs of islands may join to form larger BGPsec 1066 islands. 1068 6.4. Partial Path Signing 1070 Partial path signing means that a BGPsec AS can be permitted to sign 1071 an update that was received unsigned from a downstream neighbor. 1072 That is, the AS would add its ASN to the AS path and sign the 1073 (previously unsigned) update to other neighboring (upstream) BGPsec 1074 ASes. It was decided that this should not be permitted. 1076 6.4.1. Decision 1078 It was decided that partial path signing in BGPsec will not be 1079 allowed. A BGPsec update must be fully signed, i.e., each AS in the 1080 AS-PATH must sign the update. So in a signed update there must be a 1081 signature corresponding each AS in the AS path. 1083 6.4.2. Discussion 1085 Partial path signing (as described above) implies that the AS path is 1086 not rigorously protected. Rigorous AS path protection is a key 1087 requirement of BGPsec [RFC7353]. Partial path signing clearly re- 1088 introduces the following attack vulnerability: If a BGPsec speaker is 1089 allowed to sign an unsigned update, and if signed (i.e., partially or 1090 fully signed) updates would be preferred to unsigned updates, then a 1091 faulty, misconfigured or subverted BGPsec speaker can manufacture any 1092 unsigned update it wants (with insertion of a valid origin AS) and 1093 add a signature to it to increase the chance that its update will be 1094 preferred. 1096 6.5. Consideration of Stub ASes with Resource Constraints: Encouraging 1097 Early Adoption 1099 6.5.1. Decision 1101 The protocol permits each pair of BGPsec-capable ASes to negotiate 1102 BGPsec use asymmetrically. Thus, a stub AS (or downstream customer 1103 AS) can agree to perform BGPsec only in the transmit direction and 1104 speak traditional BGP in the receive direction. In this arrangement, 1105 the ISP's (upstream) AS will not send signed updates to this stub or 1106 customer AS. Thus, the stub AS can avoid the need to hardware 1107 upgrade its route processor and RIB memory to support BGPsec update 1108 validation. 1110 6.5.2. Discussion 1112 Various other options were also considered for accommodating a 1113 resource-constrained stub AS as discussed below: 1115 1. An arrangement that can be effected outside of BGPsec 1116 specification is as follows. Through a private arrangement 1117 (invisible to other ASes), an ISP's AS (upstream AS) can truncate 1118 the stub AS (or downstream AS) from the path and sign the update 1119 as if the prefix is originating from ISP's AS (even though the 1120 update originated unsigned from the customer AS). This way the 1121 path will appear fully signed to the rest of the network. This 1122 alternative will require the owner of the prefix at the stub AS 1123 to issue a ROA for the upstream AS, so that the upstream AS is 1124 authorized to originate routes for the prefix. 1126 2. Another type of arrangement that can also be effected outside of 1127 the BGPsec specification is as follows. Stub AS does not sign 1128 updates but obtains an RPKI (CA) certificate, issues a router 1129 certificate under that CA certificate. It passes on the private 1130 key for the router certificate to its upstream provider. That 1131 ISP (i.e., the second hop AS) would insert a signature on behalf 1132 the stub AS using the private key obtained from the stub AS. 1133 This arrangement is called proxy signing (see Section 6.6). 1135 3. An extended ROA is created that includes the stub AS as the 1136 originator of the prefix and the upstream provider as the second 1137 hop AS, and partial signatures would be allowed (i.e., stub AS 1138 need not sign the updates). It is recognized that this approach 1139 is also authoritative and not trust based. It was observed that 1140 the extended ROA is not much different from what is done with ROA 1141 (in its current form) when a PI address is originated from a 1142 provider's AS. This approach was rejected due to possible 1143 complications with creation and use of a new RPKI object, namely, 1144 the extended ROA. Also, the validating BGPsec router has to 1145 perform a level of indirection with approach, i.e., it must 1146 detect if an update is not fully signed and then look for the 1147 extended ROA to validate. 1149 4. Another method based on a different form of indirection would be 1150 as follows: Customer (stub) AS registers something like a Proxy 1151 Signer Authorization, which authorizes the second hop (i.e., 1152 provider) AS to sign on behalf of the customer AS using the 1153 provider's own key [Dynamics]. This method allows for fully 1154 signed updates (unlike the Extended ROA based approach). But 1155 this approach also requires the creation of a new RPKI object, 1156 namely, the Proxy Signer Authorization. In this approach, the 1157 second hop AS and validating ASes have to perform a level of 1158 indirection. This approach was also rejected. 1160 The various inputs regarding ISP preferences were taken into 1161 consideration, and eventually the decision in favor of asymmetric 1162 BGPsec was reached (Section 6.5.1). A stub AS that does asymmetric 1163 BGPsec has the advantage that it needs to minimally upgrade to BGPsec 1164 so it can sign updates to its upstream while it receives only 1165 unsigned updates. Thus,it can avoid the cost of increased processing 1166 and memory needed to perform update validations and to store signed 1167 updates in the RIBs, respectively. 1169 6.6. Proxy Signing 1171 6.6.1. Decision 1173 An ISP's AS (or upstream AS) can proxy sign BGP announcements for a 1174 customer (downstream) AS provided that the customer AS obtains an 1175 RPKI (CA) certificate, issues a router certificate under that CA 1176 certificate, and it passes on the private key for that certificate to 1177 its upstream provider. That ISP (i.e., the second hop AS) would 1178 insert a signature on behalf the customer AS using the private key 1179 provided by the customer AS. This is a private arrangement between 1180 the two ASes, and is invisible to other ASes. Thus, this arrangement 1181 is not part of the BGPsec protocol specification. 1183 BGPsec will not make any special provisions for an ISP to use its own 1184 private key to proxy sign updates for a customer's AS. This type of 1185 proxy signing is considered a bad idea. 1187 6.6.2. Discussion 1189 Consider a scenario when a customer's AS (say, AS8) is multi-homed to 1190 two ISPs, i.e., AS8 peers with AS1 and AS2 of ISP-1 and ISP-2, 1191 respectively. In this case AS8 would have an RPKI (CA) certificate; 1192 it issues two separate router certificates (corresponding to AS1 and 1193 AS2) under that CA certificate; and it passes on the respective 1194 private keys for those two certificates to its upstream providers AS1 1195 and AS2. Thus,AS8 has proxy signing service from both its upstream 1196 ASes. In the future, if the customer AS8 disconnects from ISP-2, 1197 then it would revoke the router certificate corresponding to AS2. 1199 6.7. Multiple Peering Sessions Between ASes 1201 6.7.1. Decision 1203 No problems are anticipated when BGPsec capable ASes have multiple 1204 peering sessions between them (between distinct routers). 1206 6.7.2. Discussion 1208 In traditional BGP, multiple peering sessions, between different 1209 pairs of routers (between two neighboring ASes) may be simultaneously 1210 used for load sharing. Similarly, BGPsec capable ASes can also have 1211 multiple peering sessions between them. Because routers in an AS can 1212 have distinct private keys, the same update when propagated over 1213 these multiple peering sessions will result in multiple updates that 1214 may differ in their signatures. The peer (upstream) AS will apply 1215 its normal procedures for selecting a best path from those multiple 1216 updates (and updates from other peers). 1218 This decision regarding load balancing (vs. using one peering as 1219 primary for carrying data and another as backup) is entirely local 1220 and is up to the two neighboring ASes. 1222 7. Interaction of BGPsec with Common BGP Features 1224 7.1. Peer Groups 1226 In the traditional BGP, the idea of peer groups is used in BGP 1227 routers to save on processing when generating and sending updates. 1228 Multiple peers for whom the same policies apply can be organized into 1229 peer groups. A peer group can typically have tens (maybe as high as 1230 300) of ASes in it. 1232 7.1.1. Decision 1234 It was decided that BGPsec updates are generated to target unique AS 1235 peers, so there is no support for peer groups in BGPsec. 1237 7.1.2. Discussion 1239 BGPsec router processing can make use of peer groups preceding the 1240 signing of updates to peers. Some of the update processing prior to 1241 forwarding to members of a peer group can be done only once per 1242 update as is done in traditional BGP. Prior to forwarding the 1243 update, a BGPsec speaker adds the peer's ASN to the data that needs 1244 to be signed and signs the update for each peer AS in the group 1245 individually. 1247 If updates were to be signed per peer group, that would require 1248 divulging information about the forward AS-set that constitutes a 1249 peer group (since the ASN of each peer would have to be included in 1250 the update). Some ISPs do not like to share this kind of information 1251 globally. 1253 7.2. Communities 1255 The need to provide protection in BGPsec for the community attribute 1256 was discussed. 1258 7.2.1. Decision 1260 Community attribute(s) will not be included in what is signed in 1261 BGPsec. 1263 7.2.2. Discussion 1265 The community attribute - in its current definition - may be 1266 inherently defective, from a security standpoint. A substantial 1267 amount of work is needed on semantics of the community attribute, and 1268 additional work on its security aspects also needs to be done. The 1269 community attribute is not necessarily transitive; it is often used 1270 only between neighbors. In those contexts, transport security 1271 mechanisms suffice to provide integrity and authentication. (There 1272 is no need to sign data when it is passed only between peers.) It 1273 was suggested that one could include only the transitive community 1274 attributes in what is signed and propagated (across the AS path). It 1275 was noted that there is a flag available (i.e., unused) in the 1276 community attribute, and it might be used by BGPsec (in some 1277 fashion). However, little information is available at this point 1278 about the use and function of this flag. It was speculated that 1279 potentially this flag could be used to indicate to BGPsec if the 1280 community attribute needs protection. For now, community attributes 1281 will not be secured by BGPsec path signatures. 1283 7.3. Consideration of iBGP Speakers and Confederations 1285 7.3.1. Decision 1287 An iBGP speaker that is also an eBGP speaker, and that executes 1288 BGPsec, will necessarily carry BGPsec data and perform eBGPsec 1289 functions. Confederations are eBGP clouds for administrative 1290 purposes and contain multiple Member-ASes. A Member-AS is not 1291 required to sign updates sent to another Member-AS within the same 1292 confederation. However, if BGPsec signing is applied in eBGP within 1293 a confederation, i.e., each Member-AS signs to the next Member-AS in 1294 the path within the confederation, then upon egress from the 1295 confederation, the Member-AS at the boundary must remove any and all 1296 signatures applied within the confederation. The Member-AS at the 1297 boundary of the confederation will sign the update to an external 1298 eBGPsec peer using the public AS number of the confederation and its 1299 private key. The BGPsec specification will not specify how to 1300 perform this process. 1302 Note: In RFC 8205, signing a BGPsec update between Member-ASes within 1303 a confederation is required if the update were to propagate with 1304 signatures within the confederation. A Confed_Segment flag exists in 1305 each Secure_Path segment, and when set, it indicates that the 1306 corresponding signature belongs to a Member-AS. At the confederation 1307 boundary, all signatures with Confed_Segment flags set are removed 1308 from the update. RFC 8205 specifies in detail how all of this done. 1309 Please see Section 3.1 (Figure 5) and Section 4.3 in [RFC8205] for 1310 the details. 1312 7.3.2. Discussion 1314 This topic may need to be revisited to flesh out the details 1315 carefully. 1317 7.4. Consideration of Route Servers in IXPs 1319 7.4.1. Decision 1321 BGPsec (individual draft-00) makes no special provisions to 1322 accommodate route servers in Internet Exchange Points (IXPs) . 1324 Note: The above decision changed subsequently. RFC 8205 allows 1325 accommodation for IXPs, especially for the case of transparent route 1326 servers. The pCount (AS prepend count) field is set to 0 for 1327 transparent route servers (see Section 4.2 of [RFC8205]). The 1328 operational guidance for preventing misuse of pCount=0 is given in 1329 Section 7.2 of RFC 8205. Also, see Section 8.4 for a discussion of 1330 security considerations concerning pCount=0. 1332 7.4.2. Discussion 1334 There are basically three methods that an IXP may use to propagate 1335 routes: (A) Direct bilateral peering through the IXP, (B) BGP peering 1336 between clients via a peering with a route server at the IXP (without 1337 IXP inserting its ASN in the path), and (C) BGP peering with an IXP 1338 route server, where the IXP inserts its ASN in the path. (Note: 1339 IXP's route server does not change the NEXT_HOP attribute even if it 1340 inserts its ASN in the path.) It is very rare for an IXP to use 1341 Method C because it is less attractive for the clients if their AS 1342 path length increases by one due to the IXP. A measure of the extent 1343 of use of Method A vs. Method B is given in terms of the 1344 corresponding IP traffic load percentages. As an example, at a major 1345 European IXP, these percentages are about 80% and 20% for Methods A 1346 and B, respectively (this data is based on private communication with 1347 IXPs circa 2011). However, as the IXP grows (in terms of number of 1348 clients), it tends to migrate more towards Method B, because of the 1349 difficulties of managing up to n x (n-1)/2 direct inter-connections 1350 between n peers in Method A. 1352 To the extent an IXP is providing direct bilateral peering between 1353 clients (Method A), that model works naturally with BGPsec. Also, if 1354 the route server in the IXP plays the role of a regular BGPsec 1355 speaker (minus the routing part for payload) and inserts its own ASN 1356 in the path (Method C), then that model would also work well in the 1357 BGPsec Internet and this case is trivially supported in BGPsec. 1359 7.5. Proxy Aggregation (a.k.a. AS_SETs) 1361 7.5.1. Decision 1363 Proxy aggregation (i.e., use of AS_SETs in the AS path) will not be 1364 supported in BGPsec. There is no provision in BGPsec to sign an 1365 update when an AS_SET is part of an AS path. If a BGPsec capable 1366 router receives an update that contains an AS_SET and also finds that 1367 the update is signed, then the router will consider the update 1368 malformed (i.e., protocol error). 1370 Note: In Section 5.2 of RFC 8205, it is specified that a receiving 1371 BGPsec router MUST handle any syntactical or protocol errors in the 1372 BGPsec_PATH attribute by using the "treat-as-withdraw" approach as 1373 defined in RFC 7606 [RFC7606]. 1375 7.5.2. Discussion 1377 Proxy aggregation does occur in the Internet today, but is it very 1378 rare. Only a very small fraction (about 0.1%) of observed updates 1379 contain AS_SETs in the AS path [ASset]. Since traditional BGP 1380 currently allows for proxy aggregation with inclusion of AS_SETs in 1381 the AS path, it is necessary that BGPsec specify what action a 1382 receiving router must take in case such an update is received with 1383 attestation. BCP 172 [RFC6472] recommends against the use of AS_SETs 1384 in updates, so it is anticipated that the use of AS_SETs will 1385 diminish over time. 1387 7.6. 4-Byte AS Numbers 1389 Not all (currently deployed) BGP speakers are capable of dealing with 1390 4-byte ASNs [RFC4893]. The standard mechanism used to accommodate 1391 such speakers requires a peer AS to translate each 4-byte ASN in the 1392 AS path to a reserved 2-byte ASN (23456) before forwarding the 1393 update. This mechanism is incompatible with use of BGPsec, since the 1394 ASN translation is equivalent to a route modification attack and will 1395 cause signatures corresponding to the translated 4-byte ASNs to fail 1396 validation. 1398 7.6.1. Decision 1400 BGP speakers that are BGPsec-capable are required to process 4-byte 1401 ASNs. 1403 7.6.2. Discussion 1405 It is reasonable to assume that upgrades for 4-byte ASN support will 1406 be in place prior to deployment of BGPsec. 1408 8. BGPsec Validation 1410 8.1. Sequence of BGPsec Validation Processing in a Receiver 1412 It is natural to ask in what sequence a receiver must perform BGPsec 1413 update validation so that if a failure were to occur (i.e., update 1414 was determined to be invalid) the processor would have spent the 1415 least amount of processing or other resources. 1417 8.1.1. Decision 1419 There was agreement that the following sequence of receiver 1420 operations is quite meaningful, and are included in the individual 1421 draft-00 BGPsec specification [I-D.lepinski-bgpsec-protocol]. 1423 However, the ordering of validation processing steps is not a 1424 normative part of the BGPsec specification. 1426 1. Verify that the signed update is syntactically correct. For 1427 example, check if the number of signatures match with the number 1428 of ASes in the AS path (after duly accounting for AS prepending). 1430 2. Verify that the origin AS is authorized to advertise the prefix 1431 in question. This verification is based on data from ROAs, and 1432 does not require any crypto operations. 1434 3. Verify that the advertisement has not yet expired. 1436 4. Verify that the target ASN in the signature data matches the ASN 1437 of the router that is processing the advertisement. Note that 1438 the target ASN check is also a non-crypto operation and is fast. 1440 5. Validate the signature data starting from the most recent AS to 1441 the origin. 1443 6. Locate the public key for the router from which the advertisement 1444 was received, using the SKI from the signature data. 1446 7. Hash the data covered by the signature algorithm. Invoke the 1447 signature validation algorithm on the following three inputs: the 1448 locally computed hash, the received signature, and the public 1449 key. There will be one output: valid or invalid. 1451 8. Repeat steps 5 and 6 for each preceding signature in the 1452 Signature-List Block, until the signature data for the origin AS 1453 is encountered and processed, or until either of these steps 1454 fails. 1456 Note: Significant refinements to the above list occurred in the 1457 progress towards RFC 8205. The detailed syntactic error checklist is 1458 presented and explained in Section 5.2 of [RFC8205]. Also, a logical 1459 sequence of steps to be followed in the validation of 1460 Signature_Blocks is described in Section 5.2 of [RFC8205]. 1462 8.1.2. Discussion 1464 The suggested sequence of receiver operations described above were 1465 discussed and are viewed as appropriate, if the goal is to minimize 1466 computational costs associated with cryptographic operations. One 1467 additional interesting suggestion was that when there are two 1468 Signature-List Blocks in an update, the validating router can first 1469 verify whichever of the two algorithms is cheaper to save on 1470 processing. If that Signature-List Block verifies, then the router 1471 can skip validating the other Signature-List Block. 1473 8.2. Signing and Forwarding Updates when Signatures Failed Validation 1475 8.2.1. Decision 1477 A BGPsec router should sign and forward a signed update to upstream 1478 peers if it selected the update as the best path, regardless of 1479 whether the update passed or failed validation (at this router). 1481 8.2.2. Discussion 1483 The availability of RPKI data at different routers (in the same or 1484 different ASes) may differ, depending on the sources used to acquire 1485 RPKI data. Hence an update may fail validation in one AS and the 1486 same update may pass validation in another AS. Also, an update may 1487 fail validation at one router in an AS and the same update may pass 1488 validation at another router in the same AS. 1490 A BCP may be published later in which some conditions of update 1491 failure are identified which may be unambiguous cases for rejecting 1492 the update, in which case the router must not select the AS path in 1493 the update. These cases are TBD. 1495 8.3. Enumeration of Error Conditions 1497 Enumeration of error conditions and the recommendations for reactions 1498 to them are still under discussion. 1500 8.3.1. Decision 1502 TBD. Also, please see Section 8.5 for the decision and discussion 1503 specifically related to syntactic errors in signatures. 1505 Note: Section 5.2 of RFC 8205 describes detection of syntactic and 1506 protocol errors in BGPsec updates as well as how the updates with 1507 such errors are to be handled. 1509 8.3.2. Discussion 1511 The list here is a first cut at some possible error conditions and 1512 recommended receiver reactions in response to detection of those 1513 errors. Refinements will follow after further discussions. 1515 E1 Abnormalities that a peer (i.e., preceding AS) should definitely 1516 not have propagated to a receiving eBGPsec router. Examples: (A) 1517 The number of signatures does not match the number of ASes in the 1518 AS path (after accounting for AS prepending); (B) There is an 1519 AS_SET in the received update and the update has signatures; (C) 1520 Other syntactic errors with signatures. 1522 Reaction: See Section 8.5. 1524 E2 Situations where a receiving eBGPsec router cannot find the cert 1525 for an AS in the AS_PATH. 1527 Reaction: Mark the update as "Invalid". It is acceptable to 1528 consider the update in best path selection. If it is chosen, then 1529 the router should sign and propagate the update. 1531 E3 Situations where a receiving eBGPsec router cannot find a ROA for 1532 the {prefix, origin} pair in the update. 1534 Reaction: Same as in (E2) above. 1536 E4 The receiving eBGPsec router verifies signatures and finds that 1537 the update is Invalid (even though its peer might not have known, 1538 e.g., due to RPKI skew). 1540 Reaction: Same as in (E2) above. 1542 In some networks, best path selection policy may specify choosing 1543 an unsigned update over one with invalid signature(s). Hence, the 1544 signatures must not be stripped even if the update is "Invalid". 1545 No evil bit is set in the update (when it is Invalid) because an 1546 upstream peer may not get that same answer when it tries to 1547 validate. 1549 8.4. Procedure for Processing Unsigned Updates 1551 An update may come in unsigned from an eBGP peer or internally (e.g., 1552 as an iBGP update). In the latter case, the route is being 1553 originated from within the AS in consideration. 1555 8.4.1. Decision 1557 If an unsigned route is received from an eBGP peer, and if it is 1558 selected, then the route will be forwarded unsigned to other eBGP 1559 peers, even BGPsec-capable peers. If the route originated in this AS 1560 (IGP or iBGP) and is unsigned, then it should be signed and announced 1561 to external BGPsec-capable peers. 1563 8.4.2. Discussion 1565 There is also a possibility that an update received in IGP (or iBGP) 1566 may have private AS numbers in the AS path. These private AS numbers 1567 would normally appear in the right most portion of the AS path. It 1568 was noted that in this case, the private AS numbers to the right 1569 would be removed (as done in traditional BGP), and then the update 1570 will be signed by the originating AS and announced to BGPsec-capable 1571 eBGP peers. 1573 Note: See Section 7.5 [RFC8205] for operational considerations for 1574 BGPsec in the context of private AS numbers. 1576 8.5. Response to Syntactic Errors in Signatures and Recommendation for 1577 Reaction 1579 Note: The contents in this subsection (i.e., Section 8.5) differ 1580 substantially from the syntactic and protocol error handling 1581 recommendations for BGPsec in RFC 8205. Hence, the reader may skip 1582 reading this subsection and instead read Section 5.2 of [RFC8205]. 1583 This section (Section 8.5) is kept here for the sake of archival 1584 value concerning design discussions. 1586 Different types of error conditions were discussed in Section 8.3. 1587 Here the focus is only on syntactic error conditions in signatures. 1589 8.5.1. Decision 1591 If there are syntactic error conditions such as (a) AS_SET and 1592 Signature-List Block (or Signature_Block per RFC 8205) both appear in 1593 an update, or (b) the number of signatures does not match the number 1594 of ASes (after accounting for any AS prepending), or (c) a parsing 1595 issue occurs with the BGPsec_Path_Signatures attribute, then the 1596 update (with the signatures stripped) will still be considered in the 1597 best path selection algorithm (**Note: This is not true in RFC 1598 8205**). If the update is selected as the best path, then the update 1599 will be propagated unsigned. The error condition will be logged 1600 locally. 1602 A BGPsec router will follow whatever the current IETF (IDR WG) 1603 recommendations are for notifying a peer that it is sending malformed 1604 messages. 1606 In the case when there are two Signature-List Blocks in an update, 1607 and one or more syntactic errors are found to occur within one of 1608 them but the other one is free of any syntactic errors, then the 1609 update will still be considered in the best path selection algorithm 1610 after the syntactically bad Signature-List Block has been removed 1611 (**Note: This is not true in RFC 8205**). If the update is selected 1612 as the best path, then the update will be propagated with only one 1613 (i.e., the error-free) Signature-List Block. The error condition 1614 will be logged locally. 1616 8.5.2. Discussion 1618 As stated above, a BGPsec router will follow whatever the current 1619 IETF (IDR WG) recommendations are for notifying a peer that it is 1620 sending malformed messages. Question: If the error is persistent, 1621 and there is a full BGP table dump occurring, then would there be 1622 500K such errors resulting in 500K notify messages sent to the erring 1623 peer? The answer was that rate limiting would be applied to the 1624 notify messages which should prevent any overload due to these 1625 messages. 1627 8.6. Enumeration of Validation States 1629 Various validation conditions are possible which can be mapped to 1630 validation states for possible input to BGPsec decision process. 1631 These conditions can be related to whether an update is signed, 1632 Expire Time checked, route origin validation checked against a ROA, 1633 signatures verification passed, etc. 1635 8.6.1. Decision 1637 It was decided that BGPsec validation outcomes will be mapped to one 1638 of only two validation states: (1) Valid - passed all validation 1639 checks (i.e., Expire Time check, route origin and Signature-List 1640 Block validation), and (2) Invalid - all other possibilities. 1641 "Invalid" would include situations such as (1) did not perform 1642 validation due to lack of or insufficient RPKI data, (2) signature 1643 Expire Time check failed, (3) route origin validation failed, and (4) 1644 signature checks were performed and one or more of them failed. 1646 Note: Expire Time is obsolete (see the notes in Section 2.2.1 and 1647 Section 2.2.2). RFC 8205 uses the states 'Valid' and 'Not Valid', 1648 but only with respect to AS path validation (i.e., not including the 1649 result of origin validation); see Section 5.1 of [RFC8205]). 'Not 1650 Valid' includes all conditions in which path validation was attempted 1651 but a 'Valid' result could not be reached (note: path validation is 1652 not attempted in case of syntactic or protocol errors in a BGPsec 1653 update; see Section 5.2 of [RFC8205]). Each Relying Party (RP) is 1654 expected to devise its own policy to suitably factor in the results 1655 from origin validation [RFC6811] and path validation [RFC8205] in its 1656 path selection decision. 1658 8.6.2. Discussion 1660 It may be noted that the result of update validation is just an 1661 additional input for the BGP decision process. The router's local 1662 policy ultimately has control over what action (regarding BGP path 1663 selection) is taken. 1665 Initially, four validation states were considered: (1) Update is not 1666 signed; (2) Update is signed but router does not have corresponding 1667 RPKI data to perform validation check; (3) Invalid (validation check 1668 performed and failed); (4) Valid (validation check performed and 1669 passed). Later, it was decided that BGPsec validation outcomes will 1670 be mapped to one of only two validation states as stated above. It 1671 was observed that an update can be invalid for many different 1672 reasons. To begin to differentiate these numerous reasons and to try 1673 to enumerate different flavors of the Invalid state is not likely to 1674 be constructive in route selection decision, and may even introduce 1675 to new vulnerability in the system. However, some questions remain 1676 such as the following. 1678 Question: Is there a need to define a separate validation state for 1679 the case when update is not signed but {prefix, origin} pair matched 1680 with ROA information? This question was discussed, and a tentative 1681 conclusion was that this is in principle similar to validation based 1682 on partial path signatures and that was ruled out earlier (see 1683 Section 6.4). So there is no need to add another validation state 1684 for this case; treat it as "Unverified" (i.e., "Invalid") considering 1685 that it is unsigned. Questions still remain, e.g., would the relying 1686 party want to give the update in consideration a higher preference 1687 over another unsigned update that failed origin validation or over a 1688 signed update that failed both signature and ROA validation? 1690 8.7. Mechanism for Transporting Validation State through iBGP 1692 8.7.1. Decision 1694 BGPsec validation need be performed only at eBGP edges. The 1695 validation status of a BGP signed/unsigned update may be conveyed via 1696 iBGP from an ingress edge router to an egress edge router. Local 1697 policy in the AS will determine how the validation status is conveyed 1698 internally, using various pre-existing mechanisms, e.g., setting a 1699 BGP community, or modifying a metric value such as Local_Pref or MED. 1700 A signed update that cannot be validated (except those with syntax 1701 errors) should be forwarded with signatures from the ingress to the 1702 egress router, where it is signed when propagated towards other 1703 eBGPsec speakers in neighboring ASes. Based entirely on local policy 1704 settings, an egress router may trust the validation status conveyed 1705 by an ingress router or it may perform its own validation. The 1706 latter approach may be used at an operator's discretion, under 1707 circumstances when RPKI skew is known to happen at different routers 1708 within an AS. 1710 Note: An extended community for carrying origin validation state in 1711 iBGP has been specified in RFC 8097 [RFC8097]). 1713 8.7.2. Discussion 1715 The attribute used to represent the validation state can be carried 1716 between ASes if desired. ISPs may like to carry it over their eBGP 1717 links between their own ASes (e.g., sibling ASes). A peer (or 1718 customer) may receive it over an eBGP link from a provider, and may 1719 want to use it to shortcut their own validation check. However, the 1720 peer (or customer) should be aware that this validation-state 1721 attribute is just a preview of a neighbor's validation and must 1722 perform their own validation check to be sure of the actual state of 1723 update's validation. Question: Should validation state propagation 1724 be protected by attestation in case it has utility for diagnostics 1725 purposes? It was decided not to protect the validation state 1726 information using signatures. 1728 The following are intended only as suggestions to be considered by AS 1729 operators. 1731 The following Validation states may be needed for propagation via 1732 iBGP between edge routers in an AS: 1734 o Validation states communicated in iBGP for an unsigned update 1735 (route origin validation result): (1) Valid, (2) Invalid, (3) 'Not 1736 Found' (see [RFC6811]), (4) Validation Deferred. 1738 * An update could be unsigned for two reasons but they need not 1739 be distinguished: (a) Because it had no signatures (came in 1740 unsigned from an eBGP peer), or (b) Signatures were present but 1741 stripped. 1743 o Validation states communicated in iBGP for a Signed update: (1) 1744 Valid, (2) Invalid, (3) Validation Deferred. 1746 The reason for conveying the additional "Validation Deferred" state 1747 may be stated as follows. An ingress edge Router A receiving an 1748 update from an eBGPsec peer may not attempt to validate signatures 1749 (e.g., in a processor overload situation), and in that case Router A 1750 should convey "Validation Deferred" state for that signed update (if 1751 selected for best path) in iBGP to other edge routers. Then an 1752 egress edge Router B upon receiving the update from ingress Router A 1753 would be able to perform its own validation (origin validation for 1754 unsigned update or origin/signature validation for signed update). 1755 As stated before, the egress Router B may always choose to perform 1756 its own validation when it receives an update from iBGP (independent 1757 of the validation status conveyed in iBGP) to account for the 1758 possibility of RPKI data skew at different routers. These various 1759 choices are local and entirely up to operator discretion. 1761 9. Operational Considerations 1763 Note: Significant thought has been devoted to operations and 1764 management considerations post publication of individual draft-00 of 1765 BGPsec specification. For this, the reader is referred to [RFC8207] 1766 and Section 7 of [RFC8205]. 1768 9.1. Interworking with BGP Graceful Restart 1770 BGP Graceful Restart (BGP-GR) [RFC4724] is a mechanism currently used 1771 to facilitate non-stop packet forwarding when the control plane is 1772 recovering from a fault (i.e., BGP session is restarted), but the 1773 data plane is functioning. A question was asked regarding if there 1774 are any special concerns about how BGP-GR works while BGPsec is 1775 operational? Also, what happens if the BGP router operation 1776 transitions from traditional BGP operation to BGP-GR to BGPsec, in 1777 that order? 1779 9.1.1. Decision 1781 No decision was made relative to this issue (at the time of 1782 publication of individual draft-00 of BGPsec specification). 1784 Note: See Section 7.7 of [RFC8205] for comments concerning the 1785 operation of Graceful Restart with BGPsec. They are consistent with 1786 the discussion below. 1788 9.1.2. Discussion 1790 BGP-GR can be implemented with BGPsec just as it is currently 1791 implemented with traditional BGP. The Restart State bit, Forwarding 1792 State bit, End-of-RIB marker, Staleness marker (in RIB-in), and 1793 Selection_Deferral_Timer are key parameters associated with BGP-GR 1794 [RFC4724]. These parameters would apply to BGPsec just as they do 1795 with traditional BGP. 1797 Regarding what happens if the BGP router transitions from traditional 1798 BGP to BGP-GR to BGPsec, the answer would simply be as follows. If 1799 there is software upgrade to BGPsec during BGP-GR (assuming upgrade 1800 is being done on a live BGP speaker), then the BGP-GR session should 1801 be terminated before a BGPsec session is initiated. Once the eBGPsec 1802 peering session is established, then the receiving eBGPsec speaker 1803 will see signed updates from the sending (newly upgraded) eBGPsec 1804 speaker. There is no apparent harm (it may, in fact, be desirable) 1805 if the receiving speaker continues to use previously-learned unsigned 1806 BGP routes from the sending speaker until they are replaced by new 1807 BGPsec routes. However, if the Forwarding State bit is set to zero 1808 by the sending speaker (i.e., the newly upgraded speaker) during 1809 BGPsec session negotiation, then the receiving speaker would mark all 1810 previously-learned unsigned BGP routes from that sending speaker as 1811 "Stale" in its RIB-in. Then, as BGPsec updates are received 1812 (possibly interspersed with unsigned BGP updates), the "Stale" routes 1813 will be replaced or refreshed. 1815 9.2. BCP Recommendations for Minimizing Churn: Certificate Expiry/ 1816 Revocation and Signature Expire Time 1818 9.2.1. Decision 1820 This is still work in progress. 1822 9.2.2. Discussion 1824 BCP recommendations for minimizing churn in BGPsec have been 1825 discussed. There are potentially various strategies on how routers 1826 should react to events such as certificate expiry/revocation, 1827 signature Expire Time exhaustion, etc. [Dynamics]. The details will 1828 be documented in the near future after additional work is completed. 1830 9.3. Outsourcing Update Validation 1832 9.3.1. Decision 1834 Update signature validation and signing can be outsourced to an off- 1835 board server or processor. 1837 9.3.2. Discussion 1839 Possibly an off-router box (one or more per AS) can be used that 1840 performs path validation. For example, these capabilities might be 1841 incorporated into a route reflector. At an ingress router, one needs 1842 the RIB-in entries validated; not the RIB-out entries. So the off- 1843 router box is probably unlike the traditional route reflector; it 1844 sits at the network edge and validates all incoming BGPsec updates. 1845 Thus,it appears that each router passes each BGPsec update it 1846 receives to the off-router box and receives a validation result 1847 before it stores the route in the RIB-in. Question: What about 1848 failure modes here? They would be dependent on (1) How much of the 1849 control plane is outsourced; (2) Reliability of the off-router box 1850 (or, equivalently communication to and from it); and (3) How 1851 centralized vs. distributed is this arrangement? When any kind of 1852 outsourcing is done, the user needs to be watchful and ensure that 1853 the outsourcing does not cross trust/security boundaries. 1855 9.4. New Hardware Capability 1857 9.4.1. Decision 1859 It is assumed that BGPsec routers (PE routers and route reflectors) 1860 will require significantly upgraded hardware - much more memory for 1861 RIBs and hardware crypto assistance. However, stub ASes would not 1862 need to make such upgrades because they can negotiate asymmetric 1863 BGPsec capability with their upstream ASes, i.e., they sign updates 1864 to the upstream AS but receive only unsigned BGP updates (see 1865 Section 6.5). 1867 9.4.2. Discussion 1869 It is accepted that it might take several years to go beyond test 1870 deployment of BGPsec, because of the need for additional route 1871 processor CPU and memory. However, because BGPsec deployment will be 1872 incremental, and because signed updates are not sent outside of a set 1873 of contiguous BGPsec-enabled ASes, it is not clear how much 1874 additional (RIB) memory will be required during initial deployment. 1875 See (see [RIB_size]) for preliminary results on modeling and 1876 estimation of BGPsec RIB size and its projected growth. Hardware 1877 cryptographic support reduces the computation burden on the route 1878 processor, and offers good security for router private keys. 1879 However, given the incremental deployment model, it also is not clear 1880 how substantial a cryptographic processing load will be incurred, 1881 initially. 1883 Note: There are recent detailed studies that considered software 1884 optimizations for BGPsec. In [Mehmet1] and [Mehmet2], computational 1885 optimizations for cryptographic processing (i.e., ECDSA speedup) are 1886 considered for BGPsec implementations on general purpose CPUs. In 1887 [V_Sriram], software optimizations at the level of update processing 1888 and path selection are proposed and quantified for BGPsec 1889 implementations. 1891 9.5. Signed Peering Registrations 1893 9.5.1. Decision 1895 The idea of signed BGP peering registrations (for the purpose of path 1896 validation) was rejected. 1898 9.5.2. Discussion 1900 The idea of using a secure map of AS relationships to "validate" 1901 updates was discussed and rejected. The reason for not pursuing such 1902 solutions was that they cannot provide strong guarantees about the 1903 validity of updates. Using these techniques, one can say only that 1904 an update is 'plausible', but cannot say it is 'definitely' valid 1905 (based on signed peering relations alone). 1907 10. Security Considerations 1909 This document requires no security considerations. See [RFC8205] for 1910 security considerations for the BGPsec protocol. 1912 11. IANA Considerations 1914 This document includes no request to IANA. 1916 12. Informative References 1918 [ASset] Sriram, K. and D. Montgomery, "Measurement Data on AS_SET 1919 and AGGREGATOR: Implications for {Prefix, Origin} 1920 Validation Algorithms", IETF SIDR WG presentation, IETF 1921 78, July 2010, . 1924 [Borchert] 1925 Borchert, O. and M. Baer, "Subject: Modification request: 1926 draft-ietf-sidr-bgpsec-protocol-14", message to the IETF 1927 SIDR WG Mailing List, 10 February 2016, 1928 . 1931 [CiscoIOS] 1932 "Cisco IOS RFD implementation", 1933 . 1936 [CPUworkload] 1937 Sriram, K. and R. Bush, "Estimating CPU Cost of BGPSEC on 1938 a Router", Presented at RIPE-63; also at IETF-83 SIDR WG 1939 Meeting, March 2012, 1940 . 1943 [Dynamics] 1944 Sriram, K. and et al., "Potential Impact of BGPSEC 1945 Mechanisms on Global BGP Dynamics", December 2009, . 1948 [Gueron] Gueron, S. and V. Krasnov, "Fast and side channel 1949 protected implementation of the NIST P-256 Elliptic Curve 1950 for x86-64 platforms", OpenSSL patch ID 3149, October 1951 2013, . 1953 [I-D.draft-clynn-s-bgp] 1954 Lynn, C., Mukkelson, J., and K. Seo, "Secure BGP (S-BGP)", 1955 June 2003, . 1958 [I-D.ietf-idr-bgp-extended-messages] 1959 Bush, R., Patel, K., and D. Ward, "Extended Message 1960 support for BGP", draft-ietf-idr-bgp-extended-messages-24 1961 (work in progress), November 2017. 1963 [I-D.ietf-sidrops-bgpsec-rollover] 1964 Weis, B., Gagliano, R., and K. Patel, "BGPsec Router 1965 Certificate Rollover", draft-ietf-sidrops-bgpsec- 1966 rollover-04 (work in progress), December 2017. 1968 [I-D.lepinski-bgpsec-protocol] 1969 Lepinski, M., "BGPSEC Protocol Specification", draft- 1970 lepinski-bgpsec-protocol-00 (work in progress), March 1971 2011. 1973 [I-D.sriram-replay-protection-design-discussion] 1974 Sriram, K. and D. Montgomery, "Design Discussion and 1975 Comparison of Protection Mechanisms for Replay Attack and 1976 Withdrawal Suppression in BGPsec", draft-sriram-replay- 1977 protection-design-discussion-09 (work in progress), 1978 October 2017. 1980 [JunOS] "Juniper JunOS RFD implementation", 1981 . 1985 [Mandelberg1] 1986 Mandelberg, D., "Subject: wglc for draft-ietf-sidr-bgpsec- 1987 protocol-11 (Specific topic: Include Address Family 1988 Identifier in the data protected under signature -- to 1989 alleviate security concern)", message to the IETF SIDR WG 1990 Mailing List, 10 February 2015, . 1993 [Mandelberg2] 1994 Mandelberg, D., "Subject: draft-ietf-sidr-bgpsec-protocol- 1995 13's security guarantees (Specific topic: Sign all of the 1996 preceding signed data (rather than just the immediate, 1997 previous signature) -- to alleviate security concern)", 1998 message to the IETF SIDR WG Mailing List, 26 August 2015, 1999 . 2002 [Mao02] Mao, Z. and et al., "Route-flap Damping Exacerbates 2003 Internet Routing Convergence", August 2002, 2004 . 2006 [Mehmet1] Adalier, M., "Efficient and Secure Elliptic Curve 2007 Cryptography Implementation of Curve P-256", NIST Workshop 2008 on ECC Standards , June 2015, 2009 . 2012 [Mehmet2] Adalier, M., Sriram, K., Borchert, O., Lee, K., and D. 2013 Montgomery, "High Performance BGP Security: Algorithms and 2014 Architectures", North American Network Operator Group 2015 Meeting NANOG-69, February 2017, 2016 . 2018 [MsgSize] Sriram, K., "Decoupling BGPsec Documents and Extended 2019 Messages draft", Presented in the IETF SIDROPS WG 2020 Meeting, IETF-98, March 2017, 2021 . 2025 [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route 2026 Flap Damping", RFC 2439, DOI 10.17487/RFC2439, November 2027 1998, . 2029 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 2030 Addresses and AS Identifiers", RFC 3779, 2031 DOI 10.17487/RFC3779, June 2004, 2032 . 2034 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 2035 Algorithms and Identifiers for RSA Cryptography for use in 2036 the Internet X.509 Public Key Infrastructure Certificate 2037 and Certificate Revocation List (CRL) Profile", RFC 4055, 2038 DOI 10.17487/RFC4055, June 2005, 2039 . 2041 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2042 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2043 DOI 10.17487/RFC4271, January 2006, 2044 . 2046 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 2047 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 2048 DOI 10.17487/RFC4724, January 2007, 2049 . 2051 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 2052 "Multiprotocol Extensions for BGP-4", RFC 4760, 2053 DOI 10.17487/RFC4760, January 2007, 2054 . 2056 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 2057 Number Space", RFC 4893, DOI 10.17487/RFC4893, May 2007, 2058 . 2060 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2061 Housley, R., and W. Polk, "Internet X.509 Public Key 2062 Infrastructure Certificate and Certificate Revocation List 2063 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2064 . 2066 [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of 2067 Autonomous System (AS) Numbers", RFC 5396, 2068 DOI 10.17487/RFC5396, December 2008, 2069 . 2071 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2072 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2073 . 2075 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 2076 Curve Cryptography Algorithms", RFC 6090, 2077 DOI 10.17487/RFC6090, February 2011, 2078 . 2080 [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using 2081 AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, 2082 DOI 10.17487/RFC6472, December 2011, 2083 . 2085 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 2086 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 2087 February 2012, . 2089 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 2090 Origin Authorizations (ROAs)", RFC 6482, 2091 DOI 10.17487/RFC6482, February 2012, 2092 . 2094 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 2095 Origination Using the Resource Certificate Public Key 2096 Infrastructure (PKI) and Route Origin Authorizations 2097 (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, 2098 . 2100 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 2101 X.509 PKIX Resource Certificates", RFC 6487, 2102 DOI 10.17487/RFC6487, February 2012, 2103 . 2105 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 2106 Austein, "BGP Prefix Origin Validation", RFC 6811, 2107 DOI 10.17487/RFC6811, January 2013, 2108 . 2110 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 2111 for DNS (EDNS(0))", STD 75, RFC 6891, 2112 DOI 10.17487/RFC6891, April 2013, 2113 . 2115 [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", 2116 RFC 7132, DOI 10.17487/RFC7132, February 2014, 2117 . 2119 [RFC7353] Bellovin, S., Bush, R., and D. Ward, "Security 2120 Requirements for BGP Path Validation", RFC 7353, 2121 DOI 10.17487/RFC7353, August 2014, 2122 . 2124 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 2125 Patel, "Revised Error Handling for BGP UPDATE Messages", 2126 RFC 7606, DOI 10.17487/RFC7606, August 2015, 2127 . 2129 [RFC8097] Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R. 2130 Bush, "BGP Prefix Origin Validation State Extended 2131 Community", RFC 8097, DOI 10.17487/RFC8097, March 2017, 2132 . 2134 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 2135 Specification", RFC 8205, DOI 10.17487/RFC8205, September 2136 2017, . 2138 [RFC8207] Bush, R., "BGPsec Operational Considerations", BCP 211, 2139 RFC 8207, DOI 10.17487/RFC8207, September 2017, 2140 . 2142 [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key 2143 Formats, and Signature Formats", RFC 8208, 2144 DOI 10.17487/RFC8208, September 2017, 2145 . 2147 [RIB_size] 2148 Sriram, K. and et al., "RIB Size Estimation for BGPSEC", 2149 June 2011, . 2152 [RIPE580] Bush, R. and et al., "RIPE-580: RIPE Routing Working Group 2153 Recommendations on Route-flap Damping", January 2013, 2154 . 2156 [V_Sriram] 2157 Sriram, V. and D. Montgomery, "Design and analysis of 2158 optimization algorithms to minimize cryptographic 2159 processing in BGP security protocols", Computer 2160 Communications, Vol. 106, pp. 75-85, July 2017, 2161 . 2164 Acknowledgements 2166 The authors would like to thank Jeff Haas and Wes George for serving 2167 as reviewers for this document for the Independent Submissions 2168 stream. The authors are grateful to Nevil Brownlee for shepherding 2169 this document through the Independent Submissions review process. 2170 Many thanks are also due to Michael Baer, Oliver Borchert, David 2171 Mandelberg, Sean Turner, Alvaro Retana, Matthias Waehlisch, Tim Polk, 2172 Russ Mundy, Wes Hardaker, Sharon Goldberg, Ed Kern, Chris Hall, Shane 2173 Amante, Luke Berndt, Doug Maughan, Pradosh Mohapatra, Mark Reynolds, 2174 Heather Schiller, Jason Schiller, Ruediger Volk, and David Ward for 2175 their review, comments, and suggestions during the course of this 2176 work. 2178 Contributors 2180 The following people have made significant contributions to this 2181 document and should be considered co-authors: 2183 Rob Austein 2184 Dragon Research Labs 2185 Email: sra@hactrn.net 2187 Steven Bellovin 2188 Columbia University 2189 Email: smb@cs.columbia.edu 2191 Randy Bush 2192 Internet Initiative Japan, Inc. 2193 Email: randy@psg.com 2195 Russ Housley 2196 Vigil Security, LLC 2197 Email: housley@vigilsec.com 2199 Stephen Kent 2200 BBN Technologies 2201 Email: kent@alum.mit.edu 2203 Warren Kumari 2204 Google 2205 Email: warren@kumari.net 2207 Matt Lepinski 2208 New College of Florida 2209 mlepinski@ncf.edu 2211 Doug Montgomery 2212 USA National Institute of Standards and Technology 2213 Email: dougm@nist.gov 2215 Chris Morrow 2216 Google, Inc. 2217 Email: morrowc@google.com 2219 Sandy Murphy 2220 SPARTA, Inc., a Parsons Company 2221 Email: sandy@tislabs.com 2223 Keyur Patel 2224 Arrcus 2225 Email: keyur@arrcus.com 2226 John Scudder 2227 Juniper Networks 2228 Email: jgs@juniper.net 2230 Samuel Weiler 2231 W3C/MIT 2232 Email: weiler@csail.mit.edu 2234 Author's Address 2236 Kotikalapudi Sriram (editor) 2237 USA NIST 2238 100 Bureau Drive 2239 Gaithersburg, MD 20899 2240 USA 2242 Email: ksriram@nist.gov