idnits 2.17.1 draft-sriram-bgpsec-design-choices-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 3, 2017) is 2670 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3779' is defined on line 1785, but no explicit reference was found in the text == Unused Reference: 'RFC5652' is defined on line 1799, but no explicit reference was found in the text == Unused Reference: 'RFC4055' is defined on line 1866, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 1878, but no explicit reference was found in the text == Unused Reference: 'RFC6480' is defined on line 1899, but no explicit reference was found in the text == Unused Reference: 'RFC6482' is defined on line 1903, but no explicit reference was found in the text == Unused Reference: 'RFC6483' is defined on line 1908, but no explicit reference was found in the text == Unused Reference: 'RFC6811' is defined on line 1919, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4893 (Obsoleted by RFC 6793) == Outdated reference: A later version (-36) exists of draft-ietf-idr-bgp-extended-messages-14 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-21 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Sriram, Ed. 3 Internet-Draft USA NIST 4 Intended status: Informational January 3, 2017 5 Expires: July 7, 2017 7 BGPSEC Design Choices and Summary of Supporting Discussions 8 draft-sriram-bgpsec-design-choices-11 10 Abstract 12 This document has been written to capture the design rationale for 13 the individual draft-00 version of BGPSEC protocol specification (I- 14 D.lepinski-bgpsec-protocol-00). It lists the decisions that were 15 made in favor of or against each design choice, and presents brief 16 summaries of the arguments that aided the decision process. A 17 similar document can be published in the future as the BGPSEC design 18 discussions make further progress and additional design 19 considerations are discussed and finalized. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 7, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Creating Signatures and the Structure of BGPSEC Update 57 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Origin Validation Using ROA . . . . . . . . . . . . . . . 4 59 2.2. Attributes Signed by an Originating AS . . . . . . . . . 4 60 2.3. Attributes Signed by an Upstream AS . . . . . . . . . . . 5 61 2.4. What Attributes Are Not Signed . . . . . . . . . . . . . 6 62 2.5. Receiving Router Actions . . . . . . . . . . . . . . . . 6 63 2.6. Prepending of ASes in AS Path . . . . . . . . . . . . . . 7 64 2.7. What RPKI Data Need be Included in Updates . . . . . . . 8 65 3. Withdrawal Protection . . . . . . . . . . . . . . . . . . . . 8 66 3.1. Withdrawals Not Signed . . . . . . . . . . . . . . . . . 8 67 3.2. Signature Expire Time for Withdrawal Protection (a.k.a. 68 Mitigation of Replay Attacks) . . . . . . . . . . . . . . 9 69 3.3. Should Route Expire Time be Communicated in a Separate 70 Message . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 3.4. Effect of Expire-Time Updates in BGPSEC on RFD . . . . . 11 72 4. Signature Algorithms and Router Keys . . . . . . . . . . . . 13 73 4.1. Signature Algorithms . . . . . . . . . . . . . . . . . . 13 74 4.2. Agility of Signature Algorithms . . . . . . . . . . . . . 13 75 4.3. Sequential Aggregate Signatures . . . . . . . . . . . . . 14 76 4.4. Protocol Extensibility . . . . . . . . . . . . . . . . . 15 77 4.5. Key Per Router (Rouge Router Problem) . . . . . . . . . . 16 78 4.6. Router ID . . . . . . . . . . . . . . . . . . . . . . . . 16 79 5. Optimizations and Resource Sizing . . . . . . . . . . . . . . 16 80 5.1. Update Packing and Repacking . . . . . . . . . . . . . . 17 81 5.2. Signature Per Prefix vs. Signature Per Update . . . . . . 17 82 5.3. Max PDU Size and PDU Negotiation . . . . . . . . . . . . 18 83 5.4. Temporary Suspension of Attestations and Validations . . 19 84 6. Incremental Deployment and Negotiation of BGPSEC . . . . . . 19 85 6.1. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 20 86 6.2. Inclusion of Address Family in Capability Advertisement . 20 87 6.3. Incremental Deployment: Capability Negotiation . . . . . 20 88 6.4. Partial Path Signing . . . . . . . . . . . . . . . . . . 21 89 6.5. Consideration of Stub ASes with Resource Constraints: 90 Encouraging Early Adoption . . . . . . . . . . . . . . . 21 91 6.6. Proxy Signing . . . . . . . . . . . . . . . . . . . . . . 23 92 6.7. Multiple Peering Sessions Between ASes . . . . . . . . . 24 93 7. Interaction of BGPSEC with Common BGP Features . . . . . . . 24 94 7.1. Peer Groups . . . . . . . . . . . . . . . . . . . . . . . 24 95 7.2. Communities . . . . . . . . . . . . . . . . . . . . . . . 25 96 7.3. Consideration of iBGP Speakers and Confederations . . . . 25 97 7.4. Consideration of Route Servers in IXPs . . . . . . . . . 26 98 7.5. Proxy Aggregation (a.k.a. AS_SETs) . . . . . . . . . . . 27 99 7.6. 4-Byte AS Numbers . . . . . . . . . . . . . . . . . . . . 27 100 8. BGPSEC Validation . . . . . . . . . . . . . . . . . . . . . . 28 101 8.1. Sequence of BGPSEC Validation Processing in a Receiver . 28 102 8.2. Signing and Forwarding Updates when Signatures Failed 103 Validation . . . . . . . . . . . . . . . . . . . . . . . 29 104 8.3. Enumeration of Error Conditions . . . . . . . . . . . . . 29 105 8.4. Procedure for Processing Unsigned Updates . . . . . . . . 30 106 8.5. Response to Syntactic Errors in Signatures and 107 Recommendation for Reaction . . . . . . . . . . . . . . . 31 108 8.6. Enumeration of Validation States . . . . . . . . . . . . 32 109 8.7. Mechanism for Transporting Validation State through iBGP 33 110 9. Operational Considerations . . . . . . . . . . . . . . . . . 35 111 9.1. Interworking with BGP Graceful Restart . . . . . . . . . 35 112 9.2. BCP Recommendations for Minimizing Churn: Certificate 113 Expiry/Revocation and Signature Expire Time . . . . . . . 36 114 9.3. Outsourcing Update Validation . . . . . . . . . . . . . . 36 115 9.4. New Hardware Capability . . . . . . . . . . . . . . . . . 36 116 9.5. Signed Peering Registrations . . . . . . . . . . . . . . 37 117 10. Co-authors . . . . . . . . . . . . . . . . . . . . . . . . . 37 118 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 119 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 120 13. Security Considerations . . . . . . . . . . . . . . . . . . . 38 121 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 122 14.1. Normative References . . . . . . . . . . . . . . . . . . 38 123 14.2. Informative References . . . . . . . . . . . . . . . . . 39 124 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42 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 Work on prefix-origin validation based on a Resource certificate PKI 131 (RPKI) is already nearing completion in the IETF SIDR WG. The BGPSEC 132 effort is aimed at taking advantage of the same RPKI infrastructure 133 developed in the SIDR WG to add cryptographic signatures to BGP 134 updates, so that routers can perform full AS path validation 135 [RFC7132] [RFC7353] [I-D.ietf-sidr-bgpsec-overview] 136 [I-D.ietf-sidr-bgpsec-protocol]. The key high-level design goals of 137 BGPSEC protocol are as follow [RFC7353]: 139 o Rigorous path validation for all announced prefixes; not merely 140 showing that a path is not impossible. 141 o Incremental deployment capability; no flag-day requirement for 142 global deployment. 143 o Protection of AS paths only in inter-domain routing (eBGP); not 144 applicable to iBGP (or to IGPs). 146 o Aim for no increase in provider's data exposure (e.g., require no 147 disclosure of peering relations, etc). 149 This document is a companion to the earliest version of the BGPSEC 150 protocol specification submitted as individual draft-00 151 [I-D.lepinski-bgpsec-protocol], and is intended to provide design 152 justifications for this initial BGPSEC specification. This document 153 lists the decisions that were made in favor of or against various 154 design choices, and presents brief summaries of the discussions that 155 weighed in the pros and cons and aided the decision process. A 156 similar document can be published in the future as the BGPSEC design 157 discussions make further progress and additional design 158 considerations are discussed and finalized. 160 The design choices and discussions are presented under the following 161 eight broad categories (with many subtopics within each category): 162 (1) Creating Signatures and the Structure of BGPSEC Update Messages, 163 (2) Withdrawal Protection, (3) Signature Algorithms and Router Keys, 164 (4) Optimizations and Resource Sizing, (5) Incremental Deployment and 165 Negotiation of BGPSEC, (6) Interaction of BGPSEC with Common BGP 166 Features, (7) BGPSEC Validation, and (8) Operational Considerations. 168 2. Creating Signatures and the Structure of BGPSEC Update Messages 170 2.1. Origin Validation Using ROA 172 2.1.1. Decision 174 Prefix-Origin validation using Route Origin Authorization (ROA) is 175 necessary and complements AS path attestation based on signed 176 updates. Thus the BGPSEC design makes use of the origin AS 177 validation capability provided by the RPKI. 179 2.1.2. Discussion 181 Prefix-Origin validation using RPKI constructs as developed in the 182 IETF SIDR WG is a necessary component of BGPSEC, i.e., it provides 183 cryptographic validation that the first hop AS is authorized to 184 originate a route for the prefix in question. 186 2.2. Attributes Signed by an Originating AS 188 2.2.1. Decision 190 An originating AS will sign over the NLRI length, NLRI prefix, its 191 own ASN, the next ASN, the signature algorithm suite ID, and a 192 signature Expire Time (see Section 3.2) for the update. The update 193 signatures will be carried in a new optional, non-transitive BGP 194 attribute. 196 2.2.2. Discussion 198 The next hop ASN is included in the data covered by the signature. 199 Without that the AS path cannot be secured; for example, it can be 200 shortened (by a MITM) without being detected. 202 It was decided that only the originating AS needs to insert a 203 signature Expire Time in the update, as it is the originator of the 204 route. The origin AS also will re-originate, i.e., beacon, the 205 update prior to the Expire Time of said advertisement (see 206 Section 3.2). (For an explanation of why upstream ASes do not insert 207 their respective signature Expire Times, please see Section 3.2.2.) 209 It was decided that each signed update would include only one NLRI 210 prefix. If more than one NLRI prefix were included, and an upstream 211 AS elected to propagate the advertisement for a subset of the 212 prefixes, then the signature(s) on the update would break (see 213 Section 5.1 and Section 5.2). If a mechanism were employed to 214 preserve prefixes that were dropped, this would reveal info to later 215 ASes that is not revealed in normal BGP operation. Thus a tradeoff 216 was made to preserve the level of route info exposure that is 217 intrinsic to BGP over the performance hit implied by limiting each 218 update to carry only one prefix. 220 The signature data is carried in an optional, non-transitive BGP 221 attribute. The attribute is optional because this is the standard 222 mechanism available in BGP to propagate new types of data. It was 223 decided that the attribute should be non-transitive because of 224 concern that the impact of sending the (potentially large) signatures 225 to routers that don't understand them. Also, if a router that 226 doesn't understand BGPSEC somehow gets a message with the signatures 227 attribute then it would be undesirable for that router to forward the 228 signatures to all of its neighbors, especially those who do not 229 understand BGPSEC, and who may choke badly if they receive a very 230 large optional BGP attribute. 232 2.3. Attributes Signed by an Upstream AS 234 In the context of BGPSEC and throughout this document, an "upstream 235 AS" simply refers to an AS that is further along in an AS path 236 (origin AS being the nearest to a prefix). In principle, an AS that 237 is upstream from an originating AS would sign the combined 238 information including the NLRI length, NLRI prefix, AS path, next 239 ASN, signature algorithm suite ID, and Expire Time. There are 240 multiple choices for what is actually signed by an upstream AS: (1) 241 Sign over the combination of NLRI length, NLRI prefix, AS path, next 242 ASN, signature algorithm suite ID, and Expire Time; or (2) Sign over 243 just the combination of previous signature (i.e., signature of the 244 neighbor AS who forwarded the update) and next ASN; or (3) Sign over 245 everything that was received from preceding AS plus next ASN; thus, 246 ASi signs over NLRI length, NLRI prefix, signature algorithm suite 247 ID, Expire Time, {ASi, AS(i-1), AS(i-2), ..., AS2, AS1}, 248 AS(i+1)(i.e., next ASN), and {Sig(i-1), Sig(i-2), ..., Sig2, Sig1}. 250 2.3.1. Decision 252 It was decided that that Method 2 will be used. Please see 253 [I-D.lepinski-bgpsec-protocol] for additional protocol details and 254 syntax. 256 2.3.2. Discussion 258 The rationale for this choice (Method 2) was as follows. Signatures 259 are performed over hash blocks. When the number of bytes to be 260 signed exceeds one hash block, then the remaining bytes will overflow 261 into a second hash block, which results in performance penalty. So 262 it is advantageous to minimize the number of bytes being hashed. 263 Also, an analysis of the three options noted above did not indentify 264 any vulnerabilities associated with this approach. 266 2.4. What Attributes Are Not Signed 268 2.4.1. Decision 270 Any attributes other than those identified in Section 2.2 and 271 Section 2.3 are not signed. Examples of such attributes are 272 Community Attribute, NO-EXPORT Attribute, Local_Pref, etc. 274 2.4.2. Discussion 276 The above stated attributes that are not signed are viewed as local 277 (e.g., do not need to propagate beyond next hop) or lack clear 278 security needs. NO-EXPORT is sent over a secured next-hop and does 279 not need signing. BGPSEC design should work with any transport layer 280 protections. It is well understood that the transport layer must be 281 protected hop by hop (if only to prevent malicious session 282 termination). 284 2.5. Receiving Router Actions 285 2.5.1. Decision 287 The expected router actions on receipt of a signed update are 288 described by the following example. Consider an update that was 289 originated by AS1 with NLRI prefix p and has traversed the AS path 290 [AS(i-1) AS(i-2) .... AS2 AS1] before arriving at ASi. Let the 291 Expire Time (inserted by AS1) for the signature in this update be 292 denoted as Te. Let AlgID represent the ID of the signature algorithm 293 suite that is in use. The update is to be processed at ASi and 294 possibly forwarded to AS(i+1). Let the attestations (signatures) 295 inserted by each router in the AS path be denoted by Sig1, Sig2, ..., 296 Sig(i-2), and Sig(i-1) corresponding to AS1, AS2, ... , AS(i-2), and 297 AS(i-1), respectively. 299 The method (#2 in Section 2.3) selected for signing requires a 300 receiving router in ASi to perform the following actions: 302 o Validate the prefix-origin pair (p, AS1) by performing a ROA 303 match. 304 o Verify that Te is greater than the clock time at the router 305 performing these checks. 306 o Check Sig1 with inputs {NLRI length, p, AlgID, Te, AS1, AS2}. 307 o Check Sig2 with inputs {Sig1, AS3}. 308 o Check Sig3 with inputs {Sig2, AS4}. 309 o ... 310 o ... 311 o Check Sig(i-2) with inputs {Sig(i-3), AS(i-1)}. 312 o Check Sig(i-1) with inputs {Sig(i-2), ASi}. 313 o If the route that has been verified is selected as the best path 314 (for prefix p), then generate Sig(i) with inputs {Sig(i-1), 315 AS(i+1)}, and generate an update including Sig(i) to AS(i+1). 317 2.5.2. Discussion 319 See Section 8.1 for suggestions regarding efficient sequencing of 320 BGPSEC validation processing in a receiving router. Some or all of 321 the validation actions may be performed by an off-board server (see 322 Section 9.3). 324 2.6. Prepending of ASes in AS Path 326 2.6.1. Decision 328 Prepending will be allowed. Prepending is defined as including more 329 than one instance of the AS number of the router that is signing the 330 update. 332 2.6.2. Discussion 334 The draft-00 version of the protocol specification calls for a 335 signature to be associated with each prepended AS. The optimization 336 of having just one signature for multiple prepended ASes will be 337 pursued later (i.e., beyond draft-00 specification). If such 338 optimization is used, a replication count would be included (in the 339 signed update) to specify how many times an AS was prepended. 341 2.7. What RPKI Data Need be Included in Updates 343 2.7.1. Decision 345 Concerning inclusion of RPKI data in an update, it was decided that 346 only the Subject Key Identifier (SKI) of the router cert must be 347 included in a signed update. This info identifies the router 348 certificate, based on the SKI generation criteria defined in 349 [RFC6487]. 351 2.7.2. Discussion 353 It was discussed if each router public key certificate should be 354 included in a signed update. Inclusion of this information might be 355 helpful for routers that do not have access to RPKI servers or 356 temporarily lose connectivity to them. It is safe to assume that in 357 majority of network environments, intermittent connectivity would not 358 be a problem. So it is best to avoid this complexity because 359 majority of the use environments do not have connectivity 360 constraints. Because the SKI of a router certificate is a hash of 361 the public key of that certificate, it suffices to select the public 362 key from that certificate. This design assumes that each BGPSEC 363 router has access to a cache containing the relevant data from 364 (validated) router certificates. 366 3. Withdrawal Protection 368 3.1. Withdrawals Not Signed 370 3.1.1. Decision 372 Withdrawals are not signed. 374 3.1.2. Discussion 376 In the current BGP protocol, any AS can withdraw, at any time, any 377 prefix it previously announced. The rationale for not signing 378 withdrawals is that BGPSEC assumes use of transport security between 379 neighboring BGPSEC routers. Thus no external entity can inject an 380 update that withdraws a route, or replay a previously transmitted 381 update containing a withdrawal. Because the rationale for 382 withdrawing a route is not visible to a neighboring BGPSEC router, 383 there are residual vulnerabilities associated with withdrawals. For 384 example, a router that advertised a (valid) route may fail to 385 withdraw that route when it is no longer viable. A router also might 386 re-advertise a route that it previously withdrew, before the route is 387 again viable. This latter vulnerability is mitigated by the Expire 388 Time value in an AS path signature (see Section 3.2). 390 Repeated withdrawals and announcements for a prefix can run up the 391 BGP RFD penalty and may result in unreachability for that prefix at 392 upstream routers. But what can the attacker gain from doing so? 393 This phenomenon is intrinsic to the design and operation of RFD. 395 3.2. Signature Expire Time for Withdrawal Protection (a.k.a. 396 Mitigation of Replay Attacks) 398 3.2.1. Decision 400 Only the originating AS inserts a signature Expire Time in the 401 update; all other ASes along an AS path do not insert Expire Times 402 associated with their respective signatures. Further, the 403 originating AS will re-originate a route sufficiently in advance of 404 the Expire Time of its signature so that other ASes along an AS path 405 will typically receive the re-originated route well ahead of the 406 current Expire Time for that route. 408 The duration of the signature Expire Time is recommended to be on the 409 order of days (preferably) but it may be on the order of hours (about 410 4 to 8 hours) in some cases, where extra replay protection is 411 percieved to be critical. 413 Each AS should stagger the Expire Time values in the routes it 414 originates. Re-origination will be done, say, at time Tb after 415 origination or the last re-origination, where Tb will equal a certain 416 percentage of the Expire Time, Te (for example, Tb = 0.75 x Te). The 417 percentage will be configurable and additional guidance can be 418 provided via an operational considerations document later. Further, 419 the actual re-origination time ought to be jittered with a uniform 420 random distribution over a short interval {Tb1, Tb2} centered at Tb. 422 It is also recommended that a receiving BGPSEC router should detect 423 if the only attribute change in an announcement (relative to the 424 current best path) is the expire time (besides, of course, the 425 signatures). In that case, assuming that the update is found valid, 426 the route processor should not re-announce the route to BGP-4 only 427 (i.e., non-BGPSEC) peers. (It still has to sign and re-announce the 428 route to BGPSEC speakers.) This procedure will reduce BGP chattiness 429 for the non-BGPSEC border routers. 431 3.2.2. Discussion 433 Mitigation of (update) replay attacks can be thought of as protection 434 against malicious re-advertisement of withdrawn routes. If each AS 435 along a path were to insert its own signature Expire Time, then there 436 would be much additional BGP chattiness and increase in BGP 437 processing load due to the need to detect and react to multiple 438 (possibly redundant) signature Expire Times. Furthermore, there 439 would be no extra benefit from the point of view of mitigation of 440 replay attacks as compared to having a single Expire Time 441 corresponding to the signature of the originating AS. 443 The recommended Expire Time value is on the order of days but 4 to 8 444 hours may used in some cases on the basis of percieved need for extra 445 protection from replay attacks. Thus, different ASes may choose 446 different values based on the perceived need to protect against route 447 replays. (A shorter Expire Time reduces the window during which an 448 AS can replay the route, even if the route has been withdrawn by a 449 downstream AS. However, shorter Expire Time values cause routes to 450 be refreshed more often, and thus causes more BGP chatter.) Even a 4 451 hours duration seems adequate to keep the re-origination workload 452 manageable. For example, if 500K routes are re-originated every 4 453 hours, it amounts to an increase in BGP update load of at least 35 454 updates per second; this can be considered reasonable. However, 455 further analysis is needed to confirm these recommendations. 457 It was stated above that originating AS will re-originate a route 458 sufficiently in advance of its Expire Time. What is considered 459 sufficiently in advance? For this, modeling should be performed to 460 determine the 95th-percentile convergence time of update propagation 461 in BGPSEC enabled Internet. 463 Each BGPSEC router should stagger the Expire Time values in the 464 updates it originates, especially during table dumps to a neighbor or 465 during its own recovery from a BGP session failure. By doing this, 466 the re-origination (i.e., beaconing) workload at the router will be 467 dispersed. 469 3.3. Should Route Expire Time be Communicated in a Separate Message 471 3.3.1. Decision 473 The idea of sending a new signature expire time in a special message 474 (rather than re-transmitting the entire update with signatures) was 475 considered. However, it was decided not to do this. Re-origination 476 to communicate a new signature Expire Time will be done by 477 propagation of a normal update message; no special type of message 478 will be required. 480 3.3.2. Discussion 482 It was suggested that if re-beaconing of signature Expire Time is 483 carried in a separate special message, then update processing load 484 may be reduced. But it was recognized that such re-beaconing message 485 necessarily entails AS path and prefix information, and hence cannot 486 be separated from the update. 488 It was observed that at the edge of the Internet, there are frequent 489 updates that may result from simple situations like BGP session being 490 switched from one interface to another (e.g., from primary to backup) 491 between two peering ASes (e.g., customer and provider). With BGP-4, 492 these updates do not propagate beyond the two ASes involved. But 493 with BGPSEC, the customer AS will put in a new signature Expire Time 494 each time such an event happens, and hence the update will need to 495 propagate throughout the Internet (limited only by best path 496 selection process). It was accepted that this cost of added churn 497 will be unavoidable. 499 3.4. Effect of Expire-Time Updates in BGPSEC on RFD 501 3.4.1. Decision 503 With regard to the Route Flap Damping (RFD) protocol 504 [RFC2439][JunOS][CiscoIOS], no differential treatment is required for 505 Expire-Time triggered (re-beaconed) BGPSEC updates. 507 However, it was noted that it would be preferable if these updates 508 did not cause route churn (and perhaps not even require any RFD 509 related processing), since they are identical except for the change 510 in the Expire Time value. The way this can be accomplished is by not 511 assigning RFD penalty to Expire-Time triggered updates. If the 512 community agrees, this could be accommodated, but a change to the 513 BGP-RFD protocol specification will be required. 515 3.4.2. Discussion 517 Summary: 519 The decision is supported by the following observations: (1) Expire 520 Time-triggered updates are generally not preceded by withdrawals, and 521 hence the path hunting and associated RFD exacerbation 522 [Mao02][RIPE580] problems are not anticipated; (2) Such updates would 523 not normally change the best path (unless another concurrent event 524 impacts the best path); (3) Expire Time-triggered updates would have 525 negligible impact on RFD penalty accumulation because the re- 526 advertisement interval is much longer relative to the half-time of 527 decay of RFD penalty. Elaborating further on reason #4 above, it may 528 be noted that the re-advertisements (i.e., beacons) of a route for a 529 given address prefix from a given peer will be received at intervals 530 of a few or several hours (see Section 3.2). During that time 531 period, any incremental contribution to RFD penalty due to a Expire 532 Time-triggered update would decay sufficiently to have negligible (if 533 any) impact on damping of said address prefix. Additional details of 534 this analysis and justification can be found below. 536 Further Details of the Analysis and Justification: 538 The frequency with which RFD penalty increments may be triggered for 539 a given prefix from a given peer is the same as the re-beaconing 540 frequency for that prefix from its origin AS. The re-beaconing 541 frequency is on the order of once every few or several hours (see 542 Section 3.2). The incremental RFD penalty assigned to a prefix due 543 to a re-beaconed update varies depending on the implementation. For 544 example, it appears that JunOS implementation [JunOS] would assign a 545 penalty of 1000 or 500 depending on whether the re-beaconed update is 546 regarded as a re-advertisement or an attribute change, respectively. 547 Normally, a re-beaconed update would be treated as a case of 548 attribute change. The Cisco implementation [CiscoIOS] on the other 549 hand assigns an RFD penalty only in the case of an actual flap (i.e., 550 a route is available, then unavailable, or vice versa). So it 551 appears that Cisco implementation of RFD would not assign any penalty 552 for a re-beaconed update (i.e., a route was already advertised 553 previously; not withdrawn; and the re-beaconed update is merely 554 updating the expire time attribute). Even if one assumes that an RFD 555 penalty of 500 is assigned (corresponding to attribute change in 556 JunOS RFD implementation), it can be illustrated that the incremental 557 affect it would have on damping the prefix in consideration would be 558 negligible. The reason for this is as follows. The half-time of RFD 559 penalty decay is normally set to 15 minutes, whereas the re-beaconing 560 frequency is on the order of once every few or several hours. An 561 incremental penalty of 500 would decay to 31.25 in one hour; 0.12 in 562 two hours; 3x10^(-5) in three hours. It may also be noted that the 563 threshold for route suppression is 3000 in JunOS and 2000 in Cisco 564 IOS. Based on the foregoing analysis, it may be concluded that 565 routine re-beaconing by itself would not result in RFD suppression of 566 routes in the BGPSEC protocol. 568 4. Signature Algorithms and Router Keys 570 4.1. Signature Algorithms 572 4.1.1. Decision 574 Initially, 256-bit ECDSA with SHA-256 will be used. One other 575 algorithm, e.g., 256-bit DSA also will be used during prototyping and 576 testing. The use of a second algorithm is needed to verify the 577 ability of the BGPSEC implementations to change from a current 578 algorithm to the next algorithm. 580 4.1.2. Discussion 582 Initially, choice of 2048-bit RSA algorithm for BGPSEC update 583 signatures was considered because it is being used ubiquitously in 584 the RPKI system. However, use of ECDSA-256 algorithm was decided 585 because it yields a smaller signature size, so that the RIB sizes 586 needed for BGPSEC would be much smaller [RIB_size]. 588 Testing with two different signature algorithms (256-bit ECDSA and 589 256-bit RSA) for transition from one to the other will increase 590 confidence in the prototyped protocol. 592 For Elliptic Curve Cryptography (ECC) algorithms, according to 593 [RFC6090], optimizations and specialized algorithms (e.g., for speed- 594 ups) have active IPR, but the basic (un-optimized) algorithms do not 595 have IPR encumbrances. 597 4.2. Agility of Signature Algorithms 599 4.2.1. Decision 601 During the transition period from one algorithm, i.e., current 602 algorithm, to the next (new) algorithm, the updates will carry two 603 sets of signatures (i.e., two Signature-List Blocks), one 604 corresponding to each algorithm. Each Signature-List Block will be 605 preceded by its type-length field and an algorithm-suite identifier. 606 A BGPSEC speaker that has been upgraded to handle the new algorithm 607 should validate both Signature-List Blocks, and then add its 608 corresponding signature to each Signature-List Block for forwarding 609 the update to the next AS. A BGPSEC speaker that has not been 610 upgraded to handle the new algorithm will strip off the Signature- 611 List Block of the new algorithm, and forward the update after adding 612 its own sig to the Signature-List Block of the current algorithm. 614 It was decided that there will be at most two Signature-List Blocks 615 per update. 617 4.2.2. Discussion 619 A length field in the Signature-List Block allows for delineation of 620 the two signature blocks. Hence, a BGPSEC router that doesn't know 621 about a particular algorithm suite (and hence doesn't know how long 622 signatures were for that algorithm suite) could still skip over the 623 corresponding Signature-List Block when parsing the message. 625 The overlap period between the two algorithms is expected to last two 626 to four years. The RIB memory and cryptographic processing capacity 627 will have to be sized to cope with such overlap periods when updates 628 would contain two sets of sigs [RIB_size]. 630 The lifetime of a signature algorithm is anticipated to be much 631 longer than the duration of a transition period from current to new 632 algorithm. It is fully expected that all ASes will have converted to 633 the required new algorithm within a certain amount of time that is 634 much shorter than the interval in which a subsequent newer algorithm 635 may be investigated and standardized for BGPSEC. Hence, the need for 636 more than two Signature-List Blocks per update is not envisioned. 638 4.3. Sequential Aggregate Signatures 640 4.3.1. Decision 642 There is currently weak or no support for the Sequential Aggregate 643 Signature (SAS) approach. Please see in the discussion section below 644 for a brief description of what SAS is and what its pros and cons 645 are. 647 4.3.2. Discussion 649 In Sequential Aggregate Signature (SAS) method, there would be only 650 one (aggregated) signature per signature block, irrespective of the 651 number of AS hops. For example, ASn (nth AS) takes as input the 652 signatures of all previous ASes [AS1, ..., AS(n-1)] and produces a 653 single composite signature. This composite signature has the 654 property that a recipient who has the public keys for AS1, ..., ASn 655 can verify (using only the single composite signature) that all of 656 the ASes actually signed the message. SAS could potentially result 657 in savings in bandwidth, PDU size, and maybe in RIB size but the 658 signature generation and validation costs will be higher as compared 659 to one signature per AS hop. 661 SAS schemes exist in the literature, typically based on RSA or 662 equivalent. In order to do SAS with RSA, and based on the algorithm 663 choices already adopted for the RPKI, a 2048-bit signature size would 664 be required. Without SAS, a DSA with 320- bit signature (1024-bit 665 key) or ECDSA with 512-bit signature (256-bit key) would suffice, for 666 equivalent cryptographic strength. The larger signature size of RSA 667 used with SAS undermines the advantages of SAS, because the average 668 hop count, i.e., number of ASes, for a route is about 3.8. In the 669 end, it may turn out that SAS has more complexity and does not 670 provide sufficient savings in PDU size or RIB size to merit its use. 671 Further exploration of this is needed to better understand SAS 672 properties and applicability for BGPSEC. There is also a concern 673 that SAS is not a time-tested cryptographic technique and thus its 674 adoption is potentially risky. 676 4.4. Protocol Extensibility 678 There is a clearly a need to specify a transition path from a current 679 protocol specification to a new version. When changes to the 680 processing of the BGPSEC_Path_Signatures are required, that will 681 require for a new version of BGPSEC. Examples of this include 682 changes to the data that is protected by the BGPSEC signatures or 683 adoption of a signature algorithm in which the number of signatures 684 in the Signature-List Block may not correspond to one signature per 685 AS in the AS-PATH (e.g., aggregate signatures). 687 4.4.1. Decision 689 The protocol-version transition mechanism here is analogous to the 690 algorithm transition discussed in Section 4.2. During the transition 691 period from one protocol version (i.e., current version) to the next 692 (new) version, updates will carry two sets of signatures (i.e., two 693 Signature-List Blocks), one corresponding to each version. A 694 protocol-version identifier is included with each Signature-List 695 Block. Hence, each Signature-List Block will be preceded by its 696 type-length field and a protocol-version identifier. A BGPSEC 697 speaker that has been upgraded to handle the new version should 698 validate both Signature-List Blocks, and then add its corresponding 699 signature to each Signature-List Block for forwarding the update to 700 the next AS. A BGPSEC speaker that has not been upgraded to handle 701 the new protocol version will strip off the Signature-List Block of 702 the new version, and forward the update with an attachment of its own 703 signature to the Signature-List Block of the current version. 705 4.4.2. Discussion 707 In the case that change to BGPSEC is deemed desirable, it is expected 708 that a subsequent version of BGPSEC would be created and that this 709 version of BGPSEC would specify a new BGP Path Attribute, let's call 710 it BGPSEC_PATH_SIG_TWO, which is designed to accommodate the desired 711 changes to BGPSEC. At this point a transition would begin which is 712 analogous to the algorithm transition discussed in Section 4.2. 714 During the transition period all BGPSEC speakers will simultaneously 715 include both the BGPSEC_PATH_SIGNATURES (curent) attribute and the 716 new BGPSEC_PATH_SIG_TWO attribute. Once the transition is complete, 717 the use of BGPSEC_PATH_SIGNATURES could then be deprecated, at which 718 point BGPSEC speakers will include only the new BGPSEC_PATH_SIG_TWO 719 attribute. Such a process could facilitate a transition to a new 720 BGPSEC semantics in a backwards compatible fashion. 722 4.5. Key Per Router (Rouge Router Problem) 724 4.5.1. Decision 726 Within each AS, each individual BGPSEC router can have a unique pair 727 of private and public keys. 729 4.5.2. Discussion 731 If a router is compromised, its key pair can be revoked 732 independently, without disrupting the other routers in the AS. Each 733 per-router key-pair will be represented in an end-entity certificate 734 issued under the CA cert of the AS. The Subject Key Identifier (SKI) 735 in the signature points to the router certificate (and thus the 736 unique public key) of the router that affixed its signature, so that 737 a validating router can reliably identify the public key to use for 738 signature verification. 740 4.6. Router ID 742 4.6.1. Decision 744 The router certificate Subject name will be the string "router" 745 followed by a decimal representation of a 4-byte AS number followed 746 by the router ID. See the current RFCs for preferred standard 747 textual representations for 4-byte ASNs [RFC5396] and router IDs 748 [RFC6891]. 750 4.6.2. Discussion 752 Every X.509 certificate requires a Subject name. The stylized 753 Subject name adopted here is intended to facilitate debugging, by 754 including the ASN and router ID. 756 5. Optimizations and Resource Sizing 757 5.1. Update Packing and Repacking 759 In the current BGP protocol (BGP-4) operation [RFC4271], an 760 originating BGP router normally packs multiple prefix (NLRI) 761 announcements into one update if the prefixes all share the same BGP 762 attributes. When an upstream BGP router forwards eBGP updates to its 763 peers, it can also pack multiple prefixes (based on shared AS path 764 and attributes) into one update. The update propagated by the 765 upstream BGP router may include only a subset of the prefixes that 766 were packed in a received update. 768 5.1.1. Decision 770 The initial draft-00 BGPSEC specification 771 [I-D.lepinski-bgpsec-protocol] does not accommodate update packing. 772 Each update contains exactly one prefix. This avoids the complexity 773 that would be otherwise inevitable if the origin had packed and 774 signed multiple prefixes in an update and an upstream AS decided to 775 propagate an update containing only a subset of the prefixes in that 776 update. BGPSEC recommendation regarding packing and repacking will 777 be revisited when optimizations are considered in the future. 779 5.1.2. Discussion 781 Currently, with BGP-4, there are, on average, approximately 4 782 prefixes announced per update [RIB_size]. So the number of BGP 783 updates (carrying announcements) is about 4 times fewer, on average, 784 as compared to the number of prefixes announced. 786 The current decision is to include only one prefix per secured update 787 (see Section 2.2 and Section 2.3). When optimizations are considered 788 in the future, the possibility of packing multiple prefixes into an 789 update can be considered. (Please see Section 5.2 for a discussion 790 of signature per prefix vs. signature per update.) Repacking could 791 be performed if signatures were generated on a per prefix basis. 792 However, one problem regarding this approach, i.e., multiple prefixes 793 in a BGP update but with a separate signature for each prefix, is 794 that the resuting BGP update violates the basic definition of a BGP 795 update. That is becuase the different prefixes will have different 796 signature and expire-time attibutes, while a BGP update (by 797 definition) must have the same set of shared attributes for all 798 prefixes it carries. 800 5.2. Signature Per Prefix vs. Signature Per Update 801 5.2.1. Decision 803 The initial design calls for including exactly one prefix per update, 804 hence there is only one signature in each secured update (modulo 805 algorithm transition conditions). Optimizations will be examined 806 later. 808 5.2.2. Discussion 810 Some notes to assist in future optimization discussions: In the 811 general case of one signature per update, multiple prefixes may be 812 signed with one signature together with their shared AS path, next 813 ASN, and Expire Time. If signature per update is used, then there 814 are potentially savings in update PDU size as well as RIB memory 815 size. But if there are any changes made to the announced prefix set 816 along the AS path, then the AS where the change occurs would need to 817 insert an Explicit Path Attribute (EPA)[I-D.draft-clynn-s-bgp]. The 818 EPA conveys information regarding what the prefix set contained prior 819 to the change. There would be one EPA for each AS that made such a 820 modification, and there would be a way to associate each EPA with its 821 corresponding AS. This enables an upstream AS to be able to know and 822 to verify what was announced and signed by prior ASs in the AS path 823 (in spite of changes made to the announced prefix set along the way). 824 The EPA adds complexity to processing (signature generation and 825 validation), further increases the size of updates and, thus of the 826 RIB, and exposes data to downstream ASes that would not otherwise be 827 exposed. Not all the pros and cons of packing and repacking in the 828 context of signature per prefix vs. signature per update (with 829 packing) have been evaluated. But the current recommendation is for 830 having only one prefix per update (no packing); so there is no need 831 for the EPA attribute. 833 5.3. Max PDU Size and PDU Negotiation 835 The current BGP-4 update PDU size is limited to 4096 bytes (4KB). 836 The probability of exceeding the current max PDU size of 4KB will be 837 higher for BGPSEC as compared to that for BGP-4 [RIB_size]. Hence, 838 there is need for adopting a higher max PDU size for BGPSEC. 840 5.3.1. Decision 842 The current thinking is that the max PDU size should be increased to 843 64 KB [I-D.ietf-idr-bgp-extended-messages] so that there is 844 sufficient room to accommodate two signature-list blocks (i.e., one 845 block with a current algorithm and another block with a new algorithm 846 during transition periods) for long paths. The larger max PDU also 847 may be required to accommodate multiple prefix announcements in an 848 update if some optimizations such as update packing are adopted in 849 future versions of the BGPSEC specification. 851 It was decided that the max PDU size negotiation will be done 852 explicitly (rather than implicitly as part of BGPSEC peering 853 initiation). 855 5.3.2. Discussion 857 It was argued that if BGPSEC negotiation included negotiation of the 858 larger max PDU size also, then it eliminates the need for checking a 859 new error condition (regarding max PDU size). But then it was viewed 860 as inadvisable to have two ways of doing something (i.e., implicit in 861 BGPSEC and also as a separate negotiation capability). It was 862 decided that having the larger max PDU size will be a separate 863 (explicit) capability negotiation. 865 5.4. Temporary Suspension of Attestations and Validations 867 5.4.1. Decision 869 A BGPSEC-capable router can temporarily suspend signing and/or 870 validation of updates during periods of route processor overload. 871 The router should later send signed updates corresponding to the 872 updates for which validation and signing were skipped. The router 873 also may choose to skip only validation but still sign and forward 874 updates during periods of congestion. 876 5.4.2. Discussion 878 In some situations, a BGPSEC router may be unable to keep up with the 879 workload of performing signing and/or validation. This can happen, 880 for example, during BGP session recovery when a router has to send 881 the entire routing table to a recovering router in a neighboring AS 882 (see [CPUworkload]). So it is not mandatory that a BGPSEC router 883 perform validation or signing of updates at all times. When the work 884 load eases, the BGPSEC router should play catch up, sending signed 885 updates corresponding to the updates for which validation and signing 886 were skipped. During periods of overload, the router may simply send 887 unsigned updates (with signatures dropped), or may sign and forward 888 the updates with signatures (even though the router itself has not 889 yet verified the signatures it received). 891 6. Incremental Deployment and Negotiation of BGPSEC 892 6.1. Downgrade Attacks 894 6.1.1. Decision 896 No attempt will be made in BGPSEC design to prevent downgrade 897 attacks, i.e., a BGPSEC-capable router sending unsigned updates when 898 it is capable of sending signed updates. 900 6.1.2. Discussion 902 BGPSEC allows routers to temporarily suspend signing updates (see 903 Section 5.4). Therefore, it would be contradictory if we were to try 904 to incorporate in the BGPSEC protocol a way to detect and reject 905 downgrade attacks. One proposed way for detecting downgrade attacks 906 was considered, based on signed peering registrations (see 907 Section 9.5). 909 6.2. Inclusion of Address Family in Capability Advertisement 911 6.2.1. Decision 913 It was decided that during capability negotiation, the address family 914 for which the BGPSEC speaker is advertising support for BGPSEC will 915 be shared using the Address Family Identifier (AFI). Initially, two 916 address families would be included, namely, IPv4 and IPv6. BGPSEC 917 for use with other address families may be specified in the future. 918 Simultaneous use of the two (i.e., IPv4 and IPv6) address families 919 for the same BGPSEC session will require that the BGPSEC speaker must 920 include two instances of this capability (one for each address 921 family) in the BGPSEC OPEN message. 923 6.2.2. Discussion 925 If new address families are supported in the future, they will be 926 added in future versions of the specification. A comment was made 927 that too many version numbers are bad for interoperability; Re- 928 negotiation on the fly to add a new address family (i.e., without 929 changeover to new version number) is desirable. 931 6.3. Incremental Deployment: Capability Negotiation 933 6.3.1. Decision 935 BGPSEC will be incrementally deployable. BGPSEC routers will use 936 capability negotiation to agree to run BGPSEC between them. If a 937 BGPSEC router's peer does not agree to run BGPSEC, then the BGPSEC 938 router will run only BGP-4 with that peer, i.e., it will not send 939 BGPSEC (i.e., signed) updates to the peer. 941 6.3.2. Discussion 943 During partial deployment, there will be BGPSEC islands as a result 944 of this approach to incremental deployment. Updates that originate 945 within a BGPSEC island will generally propagate with signed AS paths 946 to the edges of that island. As BGPsec adoption grows, the BGPsec 947 islands will expand outward (subsuming non-BGPsec portions of the 948 Internet) and/or pairs of islands may join together to form larger 949 BGPsec islands. 951 An explicit capability negotiation (outside of the BGPSEC protocol 952 initiation) will allow for negotiating a larger max PDU size (than 953 the current 4KB) between BGPSEC peers (see Section 5.3). 955 6.4. Partial Path Signing 957 Partial path signing means that a BGPSEC AS can be permitted to sign 958 an update that was received unsigned from a downstream neighbor. 959 That is, the AS would add its ASN to the AS path and sign the 960 (previously unsigned) update to other neighboring (upstream) BGPSEC 961 ASes. It was decided that this should not be permitted. 963 6.4.1. Decision 965 It was decided that partial path signing in BGPSEC will not be 966 allowed. A BGPSEC update must be fully signed, i.e., each AS in the 967 AS-PATH must sign the update. So in a signed update there must be a 968 signature corresponding each AS in the AS path. 970 6.4.2. Discussion 972 Partial path signing (as described above) implies that the AS path is 973 not rigorously protected. Rigorous AS path protection is a key 974 requirement of BGPSEC [RFC7353]. Partial path signing clearly re- 975 introduces the following attack vulnerability: If a BGPSEC speaker 976 can sign an unsigned update, and if signed (i.e., partially or fully 977 signed) updates would be preferred to unsigned updates, then a 978 faulty, misconfigured or subverted BGPSEC speaker can manufacture any 979 unsigned update it wants (with insertion of a valid origin AS) and 980 add a signature to it to increase the chance that its update will be 981 preferred. 983 6.5. Consideration of Stub ASes with Resource Constraints: Encouraging 984 Early Adoption 986 6.5.1. Decision 988 The protocol permits each pair of BGPSEC-capable ASes to negotiate 989 BGPSEC use asymmetrically. Thus a stub AS (or downstream customer 990 AS) can agree to perform BGPSEC only in the transmit direction and 991 speak BGP-4 in the receive direction. In this arrangement, the ISP's 992 (upstream) AS will not send signed updates to this stub or customer 993 AS. Thus the stub AS can avoid the need to upgrade its route 994 processor and RIB memory to support BGPSEC update validation. 996 6.5.2. Discussion 998 Various other options were also considered for accommodating a 999 resource-constrained stub AS as discussed below: 1001 1. An arrangement that can be effected outside of BGPSEC 1002 specification is as follows. Through a private arrangement 1003 (invisible to other ASes), an ISP's AS (upstream AS) can truncate 1004 the stub AS (or downstream AS) from the path and sign the update 1005 as if the prefix is originating from ISP's AS (even though the 1006 update originated unsigned from the customer AS). This way the 1007 path will appear fully signed to the rest of the network. This 1008 alternative will require the owner of the prefix at the stub AS 1009 to issue a ROA for the upstream AS, so that the upstream AS is 1010 authorized to originate routes for said prefix. 1011 2. Another type of arrangement that can also be effected outside of 1012 the BGPSEC specification is as follows. Stub AS does not sign 1013 updates but obtains an RPKI (CA) certificate, issues a router 1014 certificate under that CA certificate. It passes on the private 1015 key for the router certificate to its upstream provider. That 1016 ISP (i.e., the second hop AS) would insert a signature on behalf 1017 the stub AS using said private key obtained from the stub AS. 1018 3. An extended ROA is created that includes the stub AS as the 1019 originator of the prefix and the upstream provider as the second 1020 hop AS, and partial signatures would be allowed (i.e., stub AS 1021 need not sign the updates). It is recognized that this approach 1022 is also authoritative and not trust based. It was observed that 1023 the extended ROA is not much different from what is done with ROA 1024 (in its current form) when a PI address is originated from a 1025 provider's AS. This approach was rejected due to possible 1026 complications with creation and use of a new RPKI object, namely, 1027 the extended ROA. Also, the validating BGPSEC router has to 1028 perform a level of indirection with approach, i.e., it has to 1029 detect if an update is not fully signed and then look for the 1030 extended ROA to validate. 1031 4. Another method based on a different form of indirection would be 1032 as follows: Customer (stub) AS registers something like a Proxy 1033 Signer Authorization, which authorizes the second hop (i.e., 1034 provider) AS to sign on behalf of the customer AS using the 1035 provider's own key [Dynamics]. This method allows for fully 1036 signed updates (unlike the Extended ROA based approach). But 1037 this approach also requires the creation of a new RPKI object, 1038 namely, the Proxy Signer Authorization. In this approach the 1039 second hop AS has to perform a level of indirection. This 1040 approach was also rejected. 1042 The various inputs regarding ISP preferences were taken into 1043 consideration, and eventually the decision in favor of asymmetric 1044 BGPSEC was reached (Section 6.5.1). A stub AS that does asymmetric 1045 BGPSEC has the advantage that it needs to minimally upgrade to BGPSEC 1046 so it can sign updates to its upstream while it receives only 1047 unsigned updates. Thus it can avoid the cost of increased processing 1048 and memory needed to perform update validations and to store signed 1049 updates in the RIBs, respectively. 1051 6.6. Proxy Signing 1053 6.6.1. Decision 1055 An ISP's AS (or upstream AS) can proxy sign BGP announcements for a 1056 customer (downstream) AS provided that the customer AS obtains an 1057 RPKI (CA) certificate, issues a router certificate under that CA 1058 certificate, and it passes on the private key for that certificate to 1059 its upstream provider. That ISP (i.e., the second hop AS) would 1060 insert a signature on behalf the customer AS using the private key 1061 provided by the customer AS. This is a private arrangement between 1062 said parties and is invisible to other ASes. Thus, this arrangement 1063 is not part of the BGPSEC protocol specification 1065 BGPSEC will not make any special provisions for an ISP to use its own 1066 private key to proxy sign updates for a customer's AS. This type of 1067 proxy signing is considered a bad idea. 1069 6.6.2. Discussion 1071 Consider a scenario when a customer's AS (say, AS8) is multi-homed to 1072 two ISPs, i.e., AS8 peers with AS1 and AS2 of ISP-1 and ISP-2, 1073 respectively. In this case AS8 would have an RPKI (CA) certificate; 1074 it issues two separate router certificates (corresponding to AS1 and 1075 AS2) under that CA certificate; and it passes on the respective 1076 private keys for those two certificates to its upstream providers AS1 1077 and AS2. Thus AS8 has proxy signing service from both its upstream 1078 ASes. In the future, if the customer AS8 disconnects from ISP-2, 1079 then it would revoke the router certificate corresponding to AS2. 1081 6.7. Multiple Peering Sessions Between ASes 1083 6.7.1. Decision 1085 No problems are anticipated when BGPSEC capable ASes have multiple 1086 peering sessions between them (between distinct routers). 1088 6.7.2. Discussion 1090 As with BGP-4 ASes, BGPSEC capable ASes can also have multiple 1091 peering sessions between them. Because routers in an AS (can) have 1092 distinct private keys, the same update when propagated over these 1093 multiple peering sessions will result in multiple updates that will 1094 differ in their signatures. The peer (upstream) AS will apply its 1095 normal procedures for selecting a best path from those multiple 1096 updates (and updates from other peers). 1098 Multiple peering sessions, between different pairs of routers 1099 (between two neighboring ASes), may be simultaneously used for load 1100 sharing. This decision regarding load balancing (vs. using one 1101 peering as primary for carrying data and another as backup) is 1102 entirely local and is up to the two neighboring ASes. 1104 7. Interaction of BGPSEC with Common BGP Features 1106 7.1. Peer Groups 1108 In the current BGP-4, the idea of peer groups is used in BGP routers 1109 to save on processing when generating and sending updates. Multiple 1110 peers for whom the same policies apply can be organized into peer 1111 groups. A peer group can typically have tens (maybe as high as 300) 1112 of ASes in it. 1114 7.1.1. Decision 1116 It was decided that BGPSEC updates are generated to target unique AS 1117 peers, so there is no support for peer groups in BGPSEC. 1119 7.1.2. Discussion 1121 BGPSEC routers can use peer groups. Some of the update processing 1122 prior to forwarding to members of a peer group can be done only once 1123 per update as is done in BGP-4. Prior to forwarding the update, a 1124 BGPSEC speaker adds the peer's ASN to the data that needs to be 1125 signed and signs the update for each peer AS in the group 1126 individually. 1128 If updates were to be signed per peer group, that would require 1129 divulging information about the forward AS-set that constitutes a 1130 peer group (since the ASN of each peer would have to be included in 1131 the update). Some ISPs do not like to share this kind of information 1132 globally. 1134 7.2. Communities 1136 The need to provide protection in BGPSEC for the community attribute 1137 was discussed. 1139 7.2.1. Decision 1141 Community attribute(s) will not be included in what is signed in 1142 BGPSEC. 1144 7.2.2. Discussion 1146 The community attribute - in its current definition - may be 1147 inherently defective, from a security standpoint. A substantial 1148 amount of work is needed on semantics of the community attribute, and 1149 additional work on its security aspects also needs to be done. The 1150 community attribute is not necessarily transitive; it is often used 1151 only between neighbors. In those contexts, transport security 1152 mechanisms suffice to provide integrity and authentication. (There 1153 is no need to sign data when it is passed only between peers.) It 1154 was suggested that one could include only the transitive community 1155 attributes in what is signed and propagated (across the AS path). It 1156 was noted that there is a flag available (i.e., unused) in the 1157 community attribute, and it might be used by BGPSEC (in some 1158 fashion). However, little information is available at this point 1159 about the use and function of this flag. It was speculated that 1160 potentially this flag could be used to indicate to BGPSEC if the 1161 community attribute needs protection. For now, community attributes 1162 will not be secured by BGPSEC path signatures. 1164 7.3. Consideration of iBGP Speakers and Confederations 1166 7.3.1. Decision 1168 An iBGP speaker that is also an eBGP speaker, and that executes 1169 BGPSEC, will necessarily carry BGPSEC data and perform eBGPSEC 1170 functions. Confederations are eBGP clouds for administrative 1171 purposes and contain multiple sub-ASs. A sub-AS is not required to 1172 sign updates sent to the main AS; only the main AS will sign and 1173 propagate BGPSEC updates to eBGPSEC peer ASes. 1175 If updates are not signed (i.e., BGPSEC is not used) within a 1176 confederation boundary, then everything will work fine at a BGPSEC 1177 speaker in the confederation that is executing BGPSEC with external 1178 peers. If updates are signed (i.e., BGPSEC is used) within a 1179 confederation boundary, then the BGPSEC speaker will be required to 1180 remove any signatures applied within the confederation, and replace 1181 them with a single signature representing the (main) AS, which will 1182 be appropriate for external BGPSEC peers. The BGPSEC specification 1183 will not specify how to perform this process. 1185 7.3.2. Discussion 1187 This topic may need to be revisited to flesh out the details 1188 carefully. 1190 7.4. Consideration of Route Servers in IXPs 1192 7.4.1. Decision 1194 BGPSEC (draft-00 specification) makes no special provisions to 1195 accommodate route servers in Internet Exchange Points (IXPs) . 1197 7.4.2. Discussion 1199 There are basically three methods that an IXP may use to propagate 1200 routes: (A) Direct bilateral peering through the IXP, (B) BGP peering 1201 between clients via a peering with a route server at the IXP (without 1202 IXP inserting its ASN in the path), and (C) BGP peering with an IXP 1203 route server, where the IXP inserts its ASN in the path. (Note: 1204 IXP's route server does not change the NEXT_HOP attribute even if it 1205 inserts its ASN in the path.) It is very rare for an IXP to use 1206 Method C because it is less attractive for the clients if their AS 1207 path length increases by one due to the IXP. A measure of the extent 1208 of use of Method A vs. Method B is given in terms of the 1209 corresponding IP traffic load percentages. As an example, at a major 1210 European IXP, these percentages are about 80% and 20% for Methods A 1211 and B, respectively. However, as the IXP grows (in terms of number 1212 of clients), it tends to migrate more towards Method B, because of 1213 the difficulties of managing up to n x (n-1)/2 direct inter- 1214 connections between n peers in Method A. 1216 To the extent an IXP is providing direct bilateral peering between 1217 clients (Method A), that model works naturally with BGPSEC. Also, if 1218 the route server in the IXP plays the role of a regular BGPSEC 1219 speaker (minus the routing part for payload) and inserts its own ASN 1220 in the path (Method C), then that model would also work well in the 1221 BGPSEC Internet and this case is trivially supported in BGPSEC. 1223 However, the draft-00 version of BGPSEC specification does not 1224 accommodate the "transparent" route server model of Method B. 1226 7.5. Proxy Aggregation (a.k.a. AS_SETs) 1228 7.5.1. Decision 1230 Proxy aggregation (i.e., use of AS_SETs in the AS path) will not be 1231 supported in BGPSEC. That is to say that there is no provision in 1232 BGPSEC to sign an update when an AS_SET is part of an AS path. If a 1233 BGPSEC capable router receives an update that contains an AS_SET and 1234 also finds that the update is signed, then the router will strip the 1235 signatures and interpret the update as unsigned. If the update (with 1236 AS_SET) is selected as best path, it will be forwarded unsigned. 1238 7.5.2. Discussion 1240 Proxy aggregation does occur in the Internet today, but is it very 1241 rare. Only a very small fraction (about 0.1%) of observed updates 1242 contain AS_SETs in the AS path [ASset]. Since BGP-4 currently allows 1243 for proxy aggregation with inclusion of AS_SETs in the AS path, it is 1244 necessary that BGPSEC specify what action a receiving router must 1245 take in case such an update is received with attestation. A recently 1246 published BCP [RFC6472] recommends against the use of AS_SETs in 1247 updates, so it is anticipated that the use of AS_SETs will diminish 1248 over time. 1250 7.6. 4-Byte AS Numbers 1252 Not all (currently deployed) BGP speakers are capable of dealing with 1253 4-byte ASNs [RFC4893]. The standard mechanism used to accommodate 1254 such speakers requires a peer AS to translate each 4-byte ASN in a 1255 path into a reserved 2-byte ASN (AS 23456) before forwarding the 1256 update. This mechanism is incompatible with use of BGPSEC, since the 1257 ASN translation is equivalent to a route modification attack and will 1258 cause signatures corresponding to the translated 4-byte ASNs to fail 1259 validation. 1261 7.6.1. Decision 1263 BGP speakers that are BGPSEC-capable are required to process 4-byte 1264 ASNs. 1266 7.6.2. Discussion 1268 It is reasonable to assume that upgrades for 4-byte ASN support will 1269 be in place prior to deployment of BGPSEC. 1271 8. BGPSEC Validation 1273 8.1. Sequence of BGPSEC Validation Processing in a Receiver 1275 It is natural to ask in what sequence a receiver must perform BGPSEC 1276 update validation so that if a failure were to occur (i.e., update 1277 was determined to be invalid) the processor would have spent the 1278 least amount of processing or other resources. 1280 8.1.1. Decision 1282 There was agreement that the following sequence of receiver 1283 operations is quite meaningful, and are included in the initial 1284 draft-00 BGPSEC specification [I-D.lepinski-bgpsec-protocol]. 1285 However, the ordering of validation processing steps is not a 1286 normative part of the BGPSEC specification. 1288 1. Verify that the signed update is syntactically correct. For 1289 example, check if the number of sigs match with the number of 1290 ASes in the AS path (after duly accounting for AS prepending). 1291 2. Verify that the origin AS is authorized to advertise the prefix 1292 in question. This verification is based on data from ROAs, and 1293 does not require any crypto operations. 1294 3. Verify that the advertisement has not yet expired. 1295 4. Verify that the target ASN in the signature data matches the ASN 1296 of the router that is processing the advertisement. Note that 1297 the target ASN check is also a non-crypto operation and is fast. 1298 It is suggested that signature data be checked from the most 1299 recent AS to the origin. 1300 5. Locate the public key for the router from which the advertisement 1301 was received, using the SKI from the signature data. 1302 6. Hash the data covered by the signature algorithm. Invoke the 1303 signature validation algorithm on the following three inputs: the 1304 locally computed hash, the received signature, and the public 1305 key. There will be one output: valid or invalid. 1306 7. Repeat steps 5 and 6 for each preceding signature in the 1307 Signature-List Block, until the signature data for the origin AS 1308 is encountered and processed, or until either of these steps 1309 fails. 1311 8.1.2. Discussion 1313 The suggested sequence of receiver operations described above were 1314 discussed and are viewed as appropriate, if the goal is to minimize 1315 computational costs associated with cryptographic operations. One 1316 additional interesting suggestion was that when there are two 1317 Signature-List Blocks in an update, the validating router can first 1318 verify whichever of the two algorithms is cheaper to save on 1319 processing. If that Signature-List Block verifies, then the router 1320 can skip validating the other Signature- List Block. Of course, at 1321 the end of an algorithm transition period, many routers would support 1322 only the new algorithm because their old credentials would have 1323 expired. 1325 8.2. Signing and Forwarding Updates when Signatures Failed Validation 1327 8.2.1. Decision 1329 A BGPSEC router should sign and forward a signed update to upstream 1330 peers if it selected the update as the best path, regardless of 1331 whether the update passed or failed validation (at this router). 1332 (Note: The BGPSEC protocol specification or a companion BCP may later 1333 specify some conditions of failed update validation (TBD) under which 1334 a BGPSEC router must not select the AS path in the update.) 1336 8.2.2. Discussion 1338 The availability of RPKI data at different routers (in the same or 1339 different ASes) may differ, depending on the sources used to acquire 1340 RPKI data. Hence an update may fail validation in one AS and the 1341 same update may pass validation in another AS. Thus an update may 1342 fail validation at one router in an AS and the same update may pass 1343 validation at another router in the same AS. A BCP may be published 1344 later in which some conditions of update failure are identified which 1345 may be unambiguous cases for rejecting the update, in which case the 1346 router must not select the AS path in the update. These cases are 1347 TBD. 1349 8.3. Enumeration of Error Conditions 1351 Enumeration of error conditions and the recommendations for reactions 1352 to them are still under discussion. 1354 8.3.1. Decision 1356 TBD. Also, please see Section 8.5 for the decision and discussion 1357 specifically related to syntactic errors in signatures. 1359 8.3.2. Discussion 1361 The list here is a first cut at some possible error conditions and 1362 recommended receiver reactions in response to detection of those 1363 errors. Refinements will follow after further discussions. 1365 E1 Abnormalities that a peer (i.e., preceding AS) should definitely 1366 not have propagated to a receiving eBGPSEC router. Examples: (A) 1367 The number of signatures does not match the number of ASes in the 1368 AS path (after accounting for AS prepending); (B) There is an 1369 AS_SET in the received update and the update has signatures; (C) 1370 Other syntactic errors with sigs. 1372 Reaction: See Section 8.5. 1374 E2 Situations where a receiving eBGPSEC router can't find the cert 1375 for an AS in the AS_PATH. 1377 Reaction: Mark the update as "Invalid". It is acceptable to 1378 consider the update in best path selection. If it is chosen, then 1379 the router should sign and propagate the update. 1381 E3 Situations where a receiving eBGPSEC router can't find a ROA for 1382 the {prefix, origin} pair. 1384 Reaction: Same as in (E2) above. 1386 E4 The receiving eBGPSEC router verifies signatures and finds that 1387 the update is Invalid even though its peer might not have known 1388 (e.g., due to RPKI skew). 1390 Reaction: Same as in (E2) above. 1391 Note: Best route choice may involve choosing an unsigned update 1392 over one with "Invalid" signature(s). Hence, the signatures must 1393 not be stripped even if the update is "Invalid". No evil bit is 1394 set in the update (when it is Invalid) because an upstream peer 1395 may not get that same answer when it tries to validate. 1397 8.4. Procedure for Processing Unsigned Updates 1399 An update may come in unsigned from an eBGP peer or internally (e.g., 1400 as an iBGP update). In the latter case, the route is possibly being 1401 originated from within the AS in consideration, or from within an AS 1402 confederation. 1404 8.4.1. Decision 1406 If an unsigned route is received from an eBGP peer, and if it is 1407 selected, then the route will be forwarded unsigned to other eBGP 1408 peers, even BGPSEC-capable peers. If the route originated in this AS 1409 (IGP or iBGP) and is unsigned, then it should be signed and announced 1410 to external BGPSEC-capable peers. If the route originated in IGP (or 1411 iBGP) and is signed, then it was likely signed by ASes within a 1412 confederation. In this case, signatures from within the 1413 confederation would be processed and they would be deleted, and an 1414 origin AS signature will be added prior to announcement to eBGP 1415 (BGPSEC capable) peers (also see Section 7.3). 1417 8.4.2. Discussion 1419 There is also a possibility that an update received in IGP (or iBGP) 1420 may have private ASNs in the AS path. These private ASNs would 1421 normally appear in the right most portion of the AS path. It was 1422 noted that in this case, the private ASNs to the right would be 1423 removed (as done in BGP-4 currently?), and then the update will be 1424 signed by the originating AS and announced to eBGP (BGPSEC capable) 1425 peers. 1427 8.5. Response to Syntactic Errors in Signatures and Recommendation for 1428 Reaction 1430 Different types of error conditions were discussed in Section 8.3. 1431 Here the focus is only on syntactic error conditions in signatures. 1433 8.5.1. Decision 1435 If there are syntactic error conditions such as (a) AS_SET and 1436 Signature-List Block both appear in an update, or (b) the number of 1437 signatures does not match the number of ASes (after accounting for 1438 any AS prepending), or (c) a parsing issue occurs with the 1439 BGPSEC_Path_Signatures attribute, then the update (with the 1440 signatures stripped) will still be considered in the best path 1441 selection algorithm. If the update is selected as the best path, 1442 then the update will be propagated unsigned. The error condition 1443 will be logged locally. 1445 A BGPSEC router will follow whatever the current IETF (IDR WG) 1446 recommendations are for notifying a peer that it is sending malformed 1447 messages. 1449 In the case when there are two Signature-List Blocks in an update, 1450 and one or more syntactic errors are found to occur within one of the 1451 Signature-List Blocks but the other Signature-List Block is free of 1452 any syntactic errors, then the update will still be considered in the 1453 best path selection algorithm after the syntactically bad Signature- 1454 List Block has been removed. If the update is selected as the best 1455 path, then the update will be propagated with only one (i.e., the 1456 error-free) Signature-List Block. The error condition will be logged 1457 locally. 1459 8.5.2. Discussion 1461 As stated above, a BGPSEC router will follow whatever the current 1462 IETF (IDR WG) recommendations are for notifying a peer that it is 1463 sending malformed messages. Question: If the error is persistent, 1464 and there is a full BGP table dump occurring, then would there be 1465 500K such errors resulting in 500K notify messages sent to the erring 1466 peer? The answer was that rate limiting would be applied to the 1467 notify messages which should prevent any overload due to these 1468 messages. 1470 8.6. Enumeration of Validation States 1472 Various validation conditions (i.e., situations) are possible which 1473 can be mapped to validation states for possible input to BGPSEC 1474 decision process. These conditions can be related to whether or not 1475 an update is signed, Expire Time checked, AS origin validation 1476 checked against a ROA, signatures verification passed, etc. 1478 8.6.1. Decision 1480 It was decided that BGPSEC validation outcomes will be mapped to one 1481 of only two validation states: (1) Valid - passed all validation 1482 checks (i.e., Expire Time check, prefix-origin and Signature-List 1483 Block validation), and (2) Invalid - all other possibilities. 1485 It was decided subsequently that the terms "Valid" and "Invalid" will 1486 be generally not used in the context of update validation in BGPSEC. 1487 Instead the terms "Verified" and "Unverified" will be used. The term 1488 "Verified" would connote the same as "Valid" described above. The 1489 term "Unverified" would include all other situations such as (1) 1490 unverified due to lack of or insufficient RPKI data, (2) signature 1491 Expire-Time check failed, (3) prefix-origin validation failed, (4) 1492 signature checks were performed and one or more of them failed, (5) 1493 insufficient resources to process the signature blocks at this time, 1494 etc. 1496 The text in this document will be modified at a future date to 1497 consistently reflect this decision regarding the terminology change. 1498 For now we would continue to use the terms "Valid" and "Invalid" in 1499 the document. 1501 8.6.2. Discussion 1503 It may be noted that the result of update validation is just an 1504 additional input for the BGP decision process. The router 1505 configuration ultimately has control over what action (regarding BGP 1506 path selection) is taken. 1508 Initially, four validation states were considered: (1) Update is not 1509 signed; (2) Update is signed but router does not have corresponding 1510 RPKI data to perform validation check; (3) Invalid (validation check 1511 performed and failed); (4) Valid (validation check performed and 1512 passed). Later, it was decided that BGPSEC validation outcomes will 1513 be mapped to one of only two validation states as stated above. It 1514 was observed that an update can be invalid for many different 1515 reasons. To begin to differentiate these numerous reasons and to try 1516 to enumerate different flavors of the Invalid state is not likely to 1517 be constructive in route selection decision, and may even introduce 1518 to new vulnerability in the system. However, some questions remain 1519 such as the following. 1521 Question: Is there a need to define a separate validation state for 1522 the case when update is not signed but {prefix, origin} pair matched 1523 with ROA information? This question was discussed, and a tentative 1524 conclusion was that this is in principle similar to validation based 1525 on partial signatures and that was ruled out earlier. So there is no 1526 need to add another validation state for this case; treat it as 1527 "Unverified" (i.e., "Invalid"). Questions still remain, e.g., would 1528 the relying party want to give said update a higher preference over 1529 another unsigned update that failed ROA validation or over a signed 1530 update that failed both signature and ROA validation? 1532 8.7. Mechanism for Transporting Validation State through iBGP 1534 8.7.1. Decision 1536 BGPSEC validation need be performed only at eBGP edges. The 1537 validation status of a BGP signed/unsigned update may be conveyed via 1538 iBGP from an ingress edge router to an egress edge router. Local 1539 policy in the AS will determine the means by which the validation 1540 status is conveyed internally, using various pre-existing mechanisms, 1541 e.g., setting a BGP community, or modifying a metric value such as 1542 Local_Pref or MED. A signed update that cannot be validated (except 1543 those with syntax errors) should be forwarded with signatures from 1544 the ingress to the egress router, where it is signed when propagated 1545 towards other eBGPSEC speakers in neighboring ASs. Based entirely on 1546 local policy settings, an egress router may trust the validation 1547 status conveyed by an ingress router or it may perform its own 1548 validation. The latter approach may be used at an operator's 1549 discretion, under circumstances when RPKI skew is known to happen at 1550 different routers within an AS. 1552 8.7.2. Discussion 1554 The attribute used to represent the validation state can be carried 1555 between ASes if desired. ISPs may like to carry it over their eBGP 1556 links between their own ASes (e.g., AS701, AS702). A peer (or 1557 customer) may receive it over an eBGP link from a provider, and may 1558 want to use it to shortcut their own validation check. However, the 1559 peer (or customer) should be aware that this validation-state 1560 attribute is just a preview of a neighbor's validation and must 1561 perform their own validation check in order to be sure of the actual 1562 state of update's validation. Question: Should validation state 1563 propagation be protected by attestation in case it has utility for 1564 diagnostics purposes? It was decided not to protect the validation 1565 state information using signatures. 1567 The following are meant to be only as suggestions for the AS 1568 operator; none of what follows is part of the BGPSEC specification as 1569 such. 1571 The following Validation states may be needed for propagation via 1572 iBGP between edge routers in an AS: 1574 o Validation states communicated in iBGP for an unsigned update 1575 (Origin validation result): (1) Valid, (2) Invalid, (3) Unknown, 1576 (4) Validation Deferred. 1578 * An update could be unsigned for two reasons but they need not 1579 be distinguished: (a) Because it had no signatures (came in 1580 unsigned from an eBGP peer), or (b) Signatures were present but 1581 stripped due to syntax errors. 1582 o Validation states communicated in iBGP for a Signed update: (1) 1583 Valid, (2) Invalid, (3) Validation Deferred. 1585 The reason for conveying the additional "Validation Deferred" state 1586 may be stated as follows. An ingress edge Router A receiving an 1587 update from an eBGPSEC peer may not attempt to validate signatures 1588 (e.g., in a processor overload situation), and in that case Router A 1589 should convey "Validation Deferred" state for that signed update (if 1590 selected for best path) in iBGP to other edge routers. Then an 1591 egress edge Router B upon receiving the update from ingress Router A 1592 would be able to perform its own validation (origin validation for 1593 unsigned or signature validation for signed update). As stated 1594 before, the egress Router B always may choose to perform its own 1595 validation when it receives an update from iBGP (independent of the 1596 validation status conveyed in iBGP) to account for the possibility of 1597 RPKI data skew at different routers. These various choices are local 1598 and entirely up to operator discretion. 1600 9. Operational Considerations 1602 9.1. Interworking with BGP Graceful Restart 1604 BGP Graceful Restart (BGP-GR) [RFC4724] is a mechanism currently used 1605 to facilitate non-stop packet forwarding when the control plane is 1606 recovering from a fault (i.e., BGP session is restarted), but the 1607 data plane is functioning. A question was asked regarding if there 1608 are any special concerns about how BGP-GR works while BGPSEC is 1609 operational? Also, what happens if the BGP router operation 1610 transitions from BGP-4 to BGP-GR to BGPSEC, in that order? 1612 9.1.1. Decision 1614 No decision was made relative to this issue. 1616 9.1.2. Discussion 1618 BGP-GR can be implemented with BGPSEC just as it is currently 1619 implemented with BGP-4. The Restart State bit, Forwarding State bit, 1620 End-of-RIB marker, Staleness marker (in RIB-in), and 1621 Selection_Deferral_Timer are key parameters associated with BGP-GR 1622 [RFC4724]. These parameters would need to be incorporated into the 1623 BGPSEC session negotiation and/or operation just as the routers do 1624 now with the current BGP-4. 1626 Regarding what happens if the BGP router transitions from BGP-4 to 1627 BGP-GR to BGPSEC, the answer would simply be as follows. If there is 1628 software upgrade from BGP-4 to BGPSEC during BGP-GR (assuming upgrade 1629 is being done on a live BGP speaker), then the BGP-GR session would 1630 (should) be terminated before a BGPSEC session is initiated. Once 1631 the eBGPSEC peering session is established, then the receiving 1632 eBGPSEC speaker will see signed updates from the sending (newly 1633 upgraded) eBGPSEC speaker. There is no apparent harm (it may, in 1634 fact, be desirable) if the receiving speaker continues to use 1635 previously-learned BGP-4 routes from the sending speaker until they 1636 are replaced by new BGPSEC routes. However, if the Forwarding State 1637 bit is set to zero by the sending speaker (i.e., the newly upgraded 1638 speaker) during BGPSEC session negotiation, then the receiving 1639 speaker would mark all previously-learned BGP-4 routes from that 1640 sending speaker as "Stale" in its RIB-in. Then, as fresh BGPSEC 1641 updates (possibly mixed with some unsigned BGP-4 updates) come in, 1642 the "Stale" routes will be replaced or refreshed. 1644 9.2. BCP Recommendations for Minimizing Churn: Certificate Expiry/ 1645 Revocation and Signature Expire Time 1647 9.2.1. Decision 1649 This is still work in progress. 1651 9.2.2. Discussion 1653 BCP recommendations for minimizing churn in BGPSEC have been 1654 discussed. There are potentially various strategies on how routers 1655 should react in the events of certificate expiry/revocation and 1656 signature Expire Time exhaustion [Dynamics]. The details will be 1657 documented in the near future after additional work is completed. 1659 9.3. Outsourcing Update Validation 1661 9.3.1. Decision 1663 Update signature validation and signing can be outsourced to an off- 1664 board server or processor. 1666 9.3.2. Discussion 1668 Possibly an off-router box (one or more per AS) can be used that 1669 performs path validation. For example, these capabilities might be 1670 incorporated into a route reflector. At ingress, one needs the RIB- 1671 in entries validated; not the RIB-out entries. So the off-router box 1672 is probably unlike the traditional route reflector; it sits at net 1673 edge and validates all incoming BGPSEC updates. Thus it appears that 1674 each router passes each BGPSEC update it receives to the off-router 1675 box and receives a validation result before it stores the route in 1676 the RIB-in. Question: What about failure modes here? They would be 1677 dependent on (1) How much of the control plane is outsourced; (2) 1678 Reliability of the off-router box (or, equivalently communication to 1679 it); and (3) How centralized vs. distributed is this arrangement? 1680 When any kind of outsourcing is done, the user needs to be watchful 1681 and ensure that the outsourcing does not cross trust/security 1682 boundaries. 1684 9.4. New Hardware Capability 1686 9.4.1. Decision 1688 It is assumed that BGPSEC routers (PE routers and route reflectors) 1689 will have significantly upgraded hardware - much more memory for RIBs 1690 and hardware crypto assistance. However, stub ASes would not need to 1691 make such upgrades because they can negotiate asymmetric BGPSEC 1692 capability with their upstream ASes, i.e., they sign updates to the 1693 upstream AS but receive only BGP-4 (unsigned) updates (see 1694 Section 6.5). 1696 9.4.2. Discussion 1698 It is accepted that it might take several years to go beyond test 1699 deployment, because of the need for additional memory and processing 1700 capability. However, because BGPSEC deployment will be incremental, 1701 and because signed updates are not sent outside of a set of 1702 contiguous BGPSEC-enabled ASes, it is not clear how much additional 1703 (RIB) memory will be required during initial deployment. See (see 1704 [RIB_size]) for preliminary results on modeling and estimation of 1705 BGPSEC RIB size and its projected growth. Hardware cryptographic 1706 support reduces the computation burden on the route processor, and 1707 offers good security for router private keys. However, given the 1708 incremental deployment model, it also is not clear how substantial a 1709 cryptographic processing load will be incurred, initially. 1711 9.5. Signed Peering Registrations 1713 9.5.1. Decision 1715 The idea of signed BGP peering registrations (for the purpose of path 1716 validation) was rejected. 1718 9.5.2. Discussion 1720 The idea of using a secure map of AS relationships to "validate" 1721 updates was discussed and rejected. The reason for not pursuing such 1722 solutions was that they can't provide strong guarantees about the 1723 validity of updates. Using these techniques, one can say only that 1724 an update is 'plausible', but cannot say it is 'definitely' valid 1725 (based on signed peering relations alone). 1727 10. Co-authors 1729 Rob Austein sra@hactrn.net 1730 Internet Systems Consortium 1732 Steven Bellovin smb@cs.columbia.edu 1733 Columbia University 1735 Randy Bush randy@psg.com 1736 Internet Initiative Japan, Inc. 1738 Russ Housley housley@vigilsec.com 1739 Vigil Security 1740 Stephen Kent kent@bbn.com 1741 BBN Technologies 1743 Warren Kumari warren@kumari.net 1744 Google 1746 Matt Lepinski mlepinski@ncf.edu 1747 New College of Florida 1749 Doug Montgomery dougm@nist.gov 1750 USA NIST 1752 Kotikalapudi Sriram ksriram@nist.gov 1753 USA NIST 1755 Samuel Weiler weiler@watson.org 1756 Cobham 1758 11. Acknowledgements 1760 The authors would like to thank John Scudder, Ed Kern, Pradosh 1761 Mohapatra, Keyur Patel, David Ward, Rudiger Volk, Heather Schiller, 1762 Jason Schiller, Chris Morrow, Sandy Murphy, Russ Mundy, Mark 1763 Reynolds, Sean Turner, Sharon Goldberg, Chris Hall, Shane Amante, 1764 Luke Berndt, and Doug Maughan for their valuable input and review. 1766 12. IANA Considerations 1768 This memo includes no request to IANA. 1770 13. Security Considerations 1772 This memo requires no security considerations. See 1773 [I-D.ietf-sidr-bgpsec-protocol] for security considerations for the 1774 BGPSEC protocol. 1776 14. References 1778 14.1. Normative References 1780 [I-D.lepinski-bgpsec-protocol] 1781 Lepinski, M., "BGPSEC Protocol Specification", draft- 1782 lepinski-bgpsec-protocol-00 (work in progress), March 1783 2011. 1785 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1786 Addresses and AS Identifiers", RFC 3779, 1787 DOI 10.17487/RFC3779, June 2004, 1788 . 1790 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1791 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1792 DOI 10.17487/RFC4271, January 2006, 1793 . 1795 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 1796 Number Space", RFC 4893, DOI 10.17487/RFC4893, May 2007, 1797 . 1799 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1800 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1801 . 1803 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1804 for DNS (EDNS(0))", STD 75, RFC 6891, 1805 DOI 10.17487/RFC6891, April 2013, 1806 . 1808 14.2. Informative References 1810 [ASset] Sriram, K. and D. Montgomery, "Measurement Data on AS_SET 1811 and AGGREGATOR: Implications for {Prefix, Origin} 1812 Validation Algorithms", IETF SIDR WG presentation, IETF 1813 78, July 2010, . 1816 [CiscoIOS] 1817 "Cisco IOS RFD implementation", 1818 . 1821 [CPUworkload] 1822 Sriram, K. and R. Bush, "Estimating CPU Cost of BGPSEC on 1823 a Router", Presented at RIPE-63; also at IETF-83 SIDR WG 1824 Meeting, March 2012, 1825 . 1828 [Dynamics] 1829 Sriram, K. and et al., "Potential Impact of BGPSEC 1830 Mechanisms on Global BGP Dynamics", December 2009, . 1833 [I-D.draft-clynn-s-bgp] 1834 Lynn, C., Mukkelson, J., and K. Seo, "Secure BGP (S-BGP)", 1835 June 2003, . 1838 [I-D.ietf-idr-bgp-extended-messages] 1839 Bush, R., Patel, K., and D. Ward, "Extended Message 1840 support for BGP", draft-ietf-idr-bgp-extended-messages-14 1841 (work in progress), December 2016. 1843 [I-D.ietf-sidr-bgpsec-overview] 1844 Lepinski, M. and S. Turner, "An Overview of BGPsec", 1845 draft-ietf-sidr-bgpsec-overview-08 (work in progress), 1846 June 2016. 1848 [I-D.ietf-sidr-bgpsec-protocol] 1849 Lepinski, M. and K. Sriram, "BGPsec Protocol 1850 Specification", draft-ietf-sidr-bgpsec-protocol-21 (work 1851 in progress), December 2016. 1853 [JunOS] "Juniper JunOS RFD implementation", 1854 . 1858 [Mao02] Mao, Z. and et al., "Route-flap Damping Exacerbates 1859 Internet Routing Convergence", August 2002, 1860 . 1862 [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route 1863 Flap Damping", RFC 2439, DOI 10.17487/RFC2439, November 1864 1998, . 1866 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 1867 Algorithms and Identifiers for RSA Cryptography for use in 1868 the Internet X.509 Public Key Infrastructure Certificate 1869 and Certificate Revocation List (CRL) Profile", RFC 4055, 1870 DOI 10.17487/RFC4055, June 2005, 1871 . 1873 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 1874 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 1875 DOI 10.17487/RFC4724, January 2007, 1876 . 1878 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1879 Housley, R., and W. Polk, "Internet X.509 Public Key 1880 Infrastructure Certificate and Certificate Revocation List 1881 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1882 . 1884 [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of 1885 Autonomous System (AS) Numbers", RFC 5396, 1886 DOI 10.17487/RFC5396, December 2008, 1887 . 1889 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1890 Curve Cryptography Algorithms", RFC 6090, 1891 DOI 10.17487/RFC6090, February 2011, 1892 . 1894 [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using 1895 AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, 1896 DOI 10.17487/RFC6472, December 2011, 1897 . 1899 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1900 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 1901 February 2012, . 1903 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1904 Origin Authorizations (ROAs)", RFC 6482, 1905 DOI 10.17487/RFC6482, February 2012, 1906 . 1908 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 1909 Origination Using the Resource Certificate Public Key 1910 Infrastructure (PKI) and Route Origin Authorizations 1911 (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, 1912 . 1914 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1915 X.509 PKIX Resource Certificates", RFC 6487, 1916 DOI 10.17487/RFC6487, February 2012, 1917 . 1919 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 1920 Austein, "BGP Prefix Origin Validation", RFC 6811, 1921 DOI 10.17487/RFC6811, January 2013, 1922 . 1924 [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", 1925 RFC 7132, DOI 10.17487/RFC7132, February 2014, 1926 . 1928 [RFC7353] Bellovin, S., Bush, R., and D. Ward, "Security 1929 Requirements for BGP Path Validation", RFC 7353, 1930 DOI 10.17487/RFC7353, August 2014, 1931 . 1933 [RIB_size] 1934 Sriram, K. and et al., "RIB Size Estimation for BGPSEC", 1935 June 2011, . 1938 [RIPE580] Bush, R. and et al., "RIPE-580: RIPE Routing Working Group 1939 Recommendations on Route-flap Damping", January 2013, 1940 . 1942 Author's Address 1944 Kotikalapudi Sriram (editor) 1945 USA NIST 1946 100 Bureau Drive 1947 Gaithersburg, MD 20899 1948 USA 1950 Email: ksriram@nist.gov