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