idnits 2.17.1 draft-clynn-s-bgp-protocol-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 3466 has weird spacing: '..._ enum rec...' == Line 3496 has weird spacing: '..._ enum yes...' == Line 3522 has weird spacing: '... AS set null ...' == Line 3523 has weird spacing: '..._ enum yes...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7619 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'X509S-BGP' is mentioned on line 2498, but not defined == Missing Reference: 'DSA' is mentioned on line 617, but not defined == Missing Reference: 'IANA-SAFI' is mentioned on line 1326, but not defined == Missing Reference: 'NLRI' is mentioned on line 3500, but not defined == Missing Reference: 'ORIGIN' is mentioned on line 3501, but not defined == Missing Reference: 'AS PATH' is mentioned on line 3502, but not defined == Missing Reference: 'ATOMIC AGG' is mentioned on line 3503, but not defined == Missing Reference: 'AGG' is mentioned on line 3504, but not defined == Missing Reference: 'COMM' is mentioned on line 3505, but not defined == Missing Reference: 'MPREACH' is mentioned on line 3507, but not defined == Missing Reference: 'EXT COMM' is mentioned on line 3508, but not defined == Missing Reference: 'System' is mentioned on line 3530, but not defined == Unused Reference: 'RFC2796' is defined on line 2718, but no explicit reference was found in the text == Unused Reference: 'RFC3107' is defined on line 2728, but no explicit reference was found in the text == Unused Reference: 'RFC3279' is defined on line 2731, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AFI' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-SAN' == Outdated reference: A later version (-26) exists of draft-ietf-idr-bgp4-20 ** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. 'SHA-1') -- No information found for draft-ietf-pkix-x509-IPaddr-AS-extn - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'X509EXT' == Outdated reference: A later version (-13) exists of draft-ietf-idr-as4bytes-05 == Outdated reference: A later version (-13) exists of draft-ietf-idr-restart-06 -- Possible downref: Non-RFC (?) normative reference: ref. 'CMS03' -- Possible downref: Non-RFC (?) normative reference: ref. 'DISCEX' == Outdated reference: A later version (-05) exists of draft-ietf-idr-bgp-dpa-04 -- Possible downref: Normative reference to a draft: ref. 'DPA' == Outdated reference: A later version (-09) exists of draft-ietf-idr-bgp-ext-communities-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'JSAC' -- Possible downref: Non-RFC (?) normative reference: ref. 'MRT' == Outdated reference: A later version (-02) exists of draft-murphy-bgp-vuln-00 -- Possible downref: Normative reference to a draft: ref. 'Murphy' == Outdated reference: A later version (-01) exists of draft-murphy-bgp-protect-00 -- Possible downref: Normative reference to a draft: ref. 'Murphy2' -- Possible downref: Non-RFC (?) normative reference: ref. 'NDSS00' ** Obsolete normative reference: RFC 1863 (Obsoleted by RFC 4223) ** Obsolete normative reference: RFC 1965 (Obsoleted by RFC 3065) ** Obsolete normative reference: RFC 2050 (Obsoleted by RFC 7020) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2796 (Obsoleted by RFC 4456) ** Obsolete normative reference: RFC 2828 (Obsoleted by RFC 4949) == Outdated reference: A later version (-10) exists of draft-ietf-idr-rfc2858bis-02 ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) -- Possible downref: Non-RFC (?) normative reference: ref. 'RVO' -- Possible downref: Non-RFC (?) normative reference: ref. 'SALTZER' -- Possible downref: Non-RFC (?) normative reference: ref. 'S-BGP' Summary: 16 errors (**), 0 flaws (~~), 30 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Charles Lynn 2 Internet Draft Joanne Mikkelson 3 draft-clynn-s-bgp-protocol-01.txt Karen Seo 4 Expires December 2003 BBN Technologies 5 June 2003 7 Secure BGP (S-BGP) 8 draft-clynn-s-bgp-protocol-01.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of [RFC2026]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This document specifies a protocol for the Internet community, and 32 requests discussion and suggestions for improvements. Please refer 33 to the current edition of the "Internet Official Protocol Standards" 34 (STD 1) for the standardization state and status of this protocol. 35 Distribution of this memo is unlimited. 37 Copyright (C) The Internet Society (June 2003). All Rights Reserved. 39 Abstract 41 The Border Gateway Protocol (BGP), which is used to distribute 42 routing information between autonomous systems (ASes), is a critical 43 component of the Internet's routing infrastructure. It is highly 44 vulnerable to a variety of malicious attacks both in theory and in 45 practice, due to the lack of a scalable means of verifying the 46 authenticity and legitimacy of BGP control traffic. This document is 47 a protocol specification for Secure BGP (S-BGP), an extension to 48 BGP-4. S-BGP adheres to the principle of least privilege and uses 49 countermeasures that create an authentication and authorization 50 system that addresses most of the security problems associated with 51 BGP. To facilitate adoption and deployment, S-BGP is designed to 52 minimize the overhead (processing, bandwidth, storage) added by its 53 countermeasures and to be interoperable with the current BGP so as to 54 be incrementally deployable. 56 Disclaimer 58 The views and specification here are those of the authors and are not 59 necessarily those of their employers. The authors and their 60 employers specifically disclaim responsibility for any problems 61 arising from correct or incorrect implementation or use of this 62 specification. 64 Table of Contents 66 Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . 1 67 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 68 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 69 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 2 70 Table of Figures . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. The Authorization and Authentication Problem . . . . . . . 5 74 1.2. Overview of the S-BGP Architecture . . . . . . . . . . . . 6 75 1.2.1. Public Key Infrastructure (PKI) . . . . . . . . . . . . . 7 76 1.2.1.1. PKI for Delegation of IP Address Blocks . . . . . . . . 7 77 1.2.1.2. PKI for Delegation of AS Numbers and Binding a Router 78 to an AS . . . . 8 79 1.2.1.3. Use of the Certificates in the PKIs . . . . . . . . . . 9 80 1.2.2. Attestations . . . . . . . . . . . . . . . . . . . . . . 10 81 1.2.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 1.3. Overview of an S-BGP Implementation . . . . . . . . . . . . 11 84 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 3. Attestation Path Attribute . . . . . . . . . . . . . . . . . 22 87 3.1. Attestation Path Attribute Formats . . . . . . . . . . . . 23 88 3.1.1. Route and Address Attestations . . . . . . . . . . . . . 23 89 3.1.2. RA Sequences and Aggregation . . . . . . . . . . . . . . 30 90 3.2. S-BGP Processing . . . . . . . . . . . . . . . . . . . . . 31 91 3.2.1. Route Attestation Processing . . . . . . . . . . . . . . 32 92 3.2.1.1. Route Attestation Validation . . . . . . . . . . . . . 34 93 3.2.1.2. Route Attestation Creation . . . . . . . . . . . . . . 37 94 3.2.2. BGP Processing Phases . . . . . . . . . . . . . . . . . . 41 95 3.2.2.1. Phase 1 Processing . . . . . . . . . . . . . . . . . . 41 96 3.2.2.2. Phase 2 Processing . . . . . . . . . . . . . . . . . . 42 97 3.2.2.3. Phase 3 Processing . . . . . . . . . . . . . . . . . . 42 98 3.2.3. S-BGP Processing . . . . . . . . . . . . . . . . . . . . 43 99 3.2.3.1. Receive Processing . . . . . . . . . . . . . . . . . . . 43 100 3.2.3.2. Send Processing . . . . . . . . . . . . . . . . . . . . 44 101 3.2.3.3. Background Processing . . . . . . . . . . . . . . . . . 46 102 3.2.3.4. Unknown Path Attributes and Canonicalization . . . . . 47 103 3.2.4. Interoperation with Non-S-BGP Speakers . . . . . . . . . 48 105 4. Processing Optimizations . . . . . . . . . . . . . . . . . . 49 107 5. Auditing and Event Reporting . . . . . . . . . . . . . . . . . 51 109 6. Infrastructure Support . . . . . . . . . . . . . . . . . . . . 51 111 7. Address Attestations . . . . . . . . . . . . . . . . . . . . 52 113 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 115 9. Security Considerations . . . . . . . . . . . . . . . . . . . 53 117 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 119 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 121 Appendix A. Example Certificates, Hashes, and Signatures . . . . 57 122 Appendix B. Configuration . . . . . . . . . . . . . . . . . . . . 58 123 Appendix C. Policy Support . . . . . . . . . . . . . . . . . . . 59 124 Appendix D. NOC Support . . . . . . . . . . . . . . . . . . . . . 75 126 Intellectual Property Rights . . . . . . . . . . . . . . . . . . 76 127 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 76 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 130 Table of Figures 132 Figure 1: Address Space PKI Structure . . . . . . . . . . . . . 8 133 Figure 2: AS Custodianship and Router ID PKI . . . . . . . . . . 9 134 Figure 3: Terminology Example . . . . . . . . . . . . . . . . . 21 135 Figure 4: Structure of an Address or Route Attestation . . . . 24 136 Figure 5: Route and Address Attestation and Authenticator 137 Headers . . . 24 138 Figure 6: Signer Part . . . . . . . . . . . . . . . . . . . . . 25 139 Figure 7: Formats of Issuer Name Forms . . . . . . . . . . . . 25 140 Figure 8: Signature Part . . . . . . . . . . . . . . . . . . . 26 141 Figure 9: CoverageMask Field . . . . . . . . . . . . . . . . . 27 142 Figure 10: Expiry Part . . . . . . . . . . . . . . . . . . . . . 27 143 Figure 11: ExplicitPA Part . . . . . . . . . . . . . . . . . . . 28 144 Figure 12: Prefix Encoding . . . . . . . . . . . . . . . . . . . 28 145 Figure 13: Target Part . . . . . . . . . . . . . . . . . . . . . 29 146 Figure 14: Aggregation Example . . . . . . . . . . . . . . . . . 30 148 1. Introduction 150 Internet routing is based on a distributed system composed of many 151 routers, grouped into management domains called Autonomous Systems 152 (ASes). Routing information is exchanged between ASes in Border 153 Gateway Protocol (BGP) [RFCbgp] UPDATE messages. 155 This critical component of the Internet's routing infrastructure has 156 proven to be highly vulnerable to a variety of attacks [Murphy], due 157 to the lack of a scalable means of verifying the authenticity and 158 legitimacy of BGP control traffic. 160 This document provides a protocol specification for Secure BGP 161 (S-BGP), an extension to BGP-4. S-BGP adheres to the principle of 162 least privilege [SALTZER] and uses countermeasures that create an 163 authentication and authorization system that addresses most of the 164 security problems associated with BGP. 166 To facilitate adoption and deployment, S-BGP is designed to minimize 167 the overhead (processing, bandwidth, storage) added by its 168 countermeasures and to be interoperable with the current BGP so as to 169 be incrementally deployable. 171 The S-BGP architecture is described in [JSAC]. It discusses BGP 172 vulnerabilities and security requirements and a high-level 173 description of S-BGP's components, and how the components work 174 together to address these vulnerabilities. [Murphy] also discusses 175 BGP vulnerabilities. 177 [JSAC] includes a comparison of this architecture with other 178 approaches that have been proposed, and an overview of performance 179 and operational issues. See also [Murphy2]. 181 The public key infrastructure (PKI) created to support the S-BGP 182 authorization and authentication mechanisms is described in more 183 detail in [DISCEX]. See also Appendix A, [X509EXT], and [X509S-BGP]. 185 [NDSS00] contains experimental data collected from a proof of concept 186 implementation of S-BGP in the GateD (TM) BGP implementation. 187 [CMS03] incorporates more recent data from the Route-Views site 188 [RVO]. A reference implementation in mrtd [MRT] is available from 189 the S-BGP web site [S-BGP]. 191 This document assumes that the reader is familiar with BGP, related 192 networking technology, and general security terms and concepts. 194 1.1. The Authorization and Authentication Problem 196 Security for BGP is defined by the correct operation of BGP speakers. 197 This definition is based on the observation that any successful 198 attack against BGP should result in other than correct operation, 199 presumably yielding degraded operation. Correct operation of BGP 200 depends upon the integrity, authenticity, and timeliness of the 201 routing information it distributes as well as each BGP speaker's 202 processing, storing, and distribution of this information in 203 accordance with both the BGP specification and with the (local, 204 possibly confidential) routing policies of the BGP speaker's AS. The 205 following statements characterize the primary correct operation 206 features of BGP. 208 1) Each UPDATE received by a BGP speaker from a peer was sent by the 209 indicated peer, was not modified en-route from the peer, and 210 contains routing information no less recent than the routing 211 information previously received for the indicated prefixes from 212 that peer. 214 2) The UPDATE was intended for receipt by the peer that received it. 216 3) The peer that sent the UPDATE was authorized to act on behalf of 217 its AS to advertise the routing information contained within the 218 UPDATE to BGP peers in the recipient AS. 220 4) The entity with the right to use an address space corresponding to 221 a reachable prefix advertised in an UPDATE was given custodianship 222 of that address space by a higher-level/parent entity. 224 5) The originating AS was authorized, by the entity(s) with the right 225 to use address space corresponding to the set of reachable 226 prefixes, to advertise those prefixes. 228 6) If the UPDATE indicates a withdrawn route, then the peer 229 withdrawing the route was a legitimate advertiser for that route, 230 prior to its withdrawal. 232 7) The peer that sent the UPDATE correctly applied the BGP rules and 233 its AS's routing policies in modifying, storing, and distributing 234 the UPDATE, in selecting the route, and in deriving forwarding 235 information from it. 237 8) The BGP speaker that received the UPDATE correctly applied the BGP 238 rules and its AS's routing policies in determining whether to 239 accept the UPDATE. 241 The countermeasures developed for S-BGP meet the first six of these 242 criteria, even in the face of subversion of BGP speakers (Byzantine 243 failures). However, because the local policy features of BGP allow a 244 speaker considerable latitude in determining how to process an 245 UPDATE, these countermeasures cannot meet the last two criteria, 246 i.e., such attacks could be attributed to local policies not visible 247 outside the AS. To address such attacks within BGP, the semantics of 248 BGP itself would have to change. Moreover, because UPDATEs do not 249 carry sequence numbers, a BGP speaker can generate an UPDATE based on 250 old information, e.g., withdrawing or reasserting a route based on 251 outdated information. Thus the temporal accuracy of UPDATEs, in the 252 face of Byzantine failures, is enforced only very coarsely by these 253 countermeasures. 255 1.2. Overview of the S-BGP Architecture 257 The design of S-BGP is based on several assumptions and constraints. 258 First, the countermeasures must not violate the BGP specifications, 259 e.g., any additional data carried in UPDATEs must make use of defined 260 extension mechanisms and the maximum (BGP) message size of 4096 bytes 261 must not be exceeded. Thus, for example, the address attestations, 262 certificates, and CRLs needed to support S-BGP are transmitted out- 263 of-band; and an optional, transitive, path attribute is used to carry 264 in-band S-BGP countermeasures data. A countermeasure must operate at 265 a rate comparable to the information that it protects as failure to 266 do so results in synchronization discrepancies that might be 267 exploited. Consequently, countermeasures protecting topology 268 information needs to function at the rate of UPDATE messages while 269 countermeasures related to the existence of ASes, networks, or S-BGP 270 speakers can function at a slower rate. The performance impact of 271 the countermeasures must be minimal. Finally, the countermeasures 272 should scale, as the Internet continues to grow at a well-documented, 273 substantial pace. See [JSAC] for a more detailed overview of S-BGP. 275 The approach adopted to securing BGP route distribution involves a 276 Public Key Infrastructure (PKI), a new transitive path attribute 277 containing "attestations", and the use of IPsec. These components 278 are used by an S-BGP speaker to validate the authenticity and data 279 integrity of BGP UPDATEs that it receives, and to verify the identity 280 and authorization of the senders. 282 A Public Key Infrastructure (PKI), based on X.509 v3 certificates 283 containing S-BGP private extensions [X509EXT] [X509S-BGP], is used to 284 provide assurance that the AS numbers and IP address prefixes being 285 advertised have been authorized for use by their respective 286 custodians. See [DISCEX] for a more detailed description of the PKI. 288 A new BGP optional transitive path attribute, the Attestation Path 289 Attribute (ATTEST), is used to carry digital signatures that protect 290 the prefixes (NLRI or MP_REACH_NLRI), the AS Path, and, optionally, 291 other transitive path attributes as a BGP UPDATE propagates between 292 ASes. 294 IPsec, in conjunction with a certificate issued to each BGP speaker, 295 provides authentication of BGP peers and provides data integrity for 296 the TCP peering connection. It also protects the connection from 297 replay attacks, as well as attacks on the TCP connection or the in- 298 transit BGP protocol messages. 300 1.2.1. Public Key Infrastructure (PKI) 302 S-BGP makes use of a Public Key Infrastructure (PKI), based on the 303 use of X.509 v3 certificates, that supports the authentication of IP 304 address block custodianship, AS number custodianship, AS 305 identification, and BGP router identification and authorization to 306 represent an AS. The PKI uses three new certificate extensions to 307 implement this functionality. See [RFC3280] for a description of 308 X.509 certificate and CRL formats. The concepts and terms address 309 attestation (AA) and route attestation (RA) are described and defined 310 in section 1.2.2. 312 An administrative framework [RFC2050] and personnel already exist to 313 manage the delegation of the right to use IP address prefixes and AS 314 numbers. S-BGP builds upon this existing infrastructure to manage 315 these certificates. The PKI that must be created to support S-BGP 316 will overlay the existing administrative framework, based on the 317 Regional Internet Registries (RIR), ISPs, etc. 319 1.2.1.1. PKI for Delegation of IP Address Blocks 321 The IPAddrBlocks certificate extension binds a set of IP address 322 families and prefixes to a public key. Certificates containing this 323 extension, in conjunction with address attestations, are used to 324 verify that the entity with the right to use an IP address space (the 325 private key holder) has authorized one or more ASes to advertise the 326 address space. The certificates are arranged into a hierarchy that 327 parallels the existing IP address administrative framework. 329 The IANA is the root certification authority (CA) of the PKI, and 330 each RIR is a registry CA below the root. The IANA as the S-BGP root 331 CA, cross certifies the RIR's registry CA. The third tier consists 332 of ISPs, and subscribers that have obtained their address space 333 assignment directly from an RIR. Additional tier(s) represent DSPs 334 or subscribers that have been assigned IP address blocks by their 335 provider. Note that only those entities that have the right to use 336 an IP address block need these certificates. Entities that are 337 "loaned" a portion of their provider's address space do not need a 338 certificate. Figure 1 illustrates this certification hierarchy, 339 showing the organizations that are represented at each tier. 341 IANA 342 All Addr blocks 343 | 344 +----------------------+-----------------------+ 345 | | | 346 APNIC Registry ARIN Registry ... RIPE Registry 347 APNIC Addr blocks ARIN Addr blocks RIPE Addr blocks 348 : | : 349 | 350 +----------+----+++-----+-----------+----+++-----+ 351 | | ||| | | ||| | 352 AT&T Org A ... MCI ISP 1 ... Sprint 353 Addr Addr Addr Addr Addr 354 block(s) block(s) block(s) block(s) block(s) 355 | | | | 356 ..--+--.. ..--+--.. ..--+--.. ..--+--.. 357 | | | | 358 Subscriber B DSP 2 Subscriber C ISP 3 359 Addr Addr Addr Addr 360 block(s) block(s) block(s) block(s) 361 | | 362 ... ... 364 Figure 1: Address Space PKI Structure 366 1.2.1.2. PKI for Delegation of AS Numbers and Binding a Router to an AS 368 The ASIdentifiers certificate extension binds a set of AS numbers to 369 a public key. The SBGPRouterId extension contained in certificates 370 issued to S-BGP speakers, binds an AS number and the router's BGP ID 371 to the speaker's public key. Together, these two certificate 372 extensions allow BGP speakers to authenticate one another, and to 373 verify that a given speaker is authorized to represent a specified 374 AS. Here too, IANA is the root CA and each RIR, at the second tier, 375 operates a registry CA. The third tier consists of ISPs, DSPs, and 376 subscribers. 378 The second certificate extension is issued at all tiers; and the 379 third at the bottom tier, to S-BGP speakers. The bottom tier 380 represents both ASes (as a management entity), and routers associated 381 with a higher tier organization. Note that only those entities that 382 have the right to use an AS number, that manage S-BGP speakers, or 383 that participate in an S-BGP peering session need these certificates. 384 Figure 2 illustrates a simple example of the hierarchy for these two 385 types of certificates, noting the organizations involved at the top 386 three tiers, and the ASes and routers that populate the bottom tier. 388 IANA 389 All AS Numbers 390 | 391 +----------------------+-----------------------+ 392 | | | 393 APNIC Registry ARIN Registry ... RIPE Registry 394 APNIC AS Numbers ARIN AS Numbers RIPE AS Numbers 395 : | : 396 | 397 +-----------+----+++-----+------------+----+++-------+ 398 | | ||| | | ||| | 399 AT&T Org A ... MCI ISP 1 ... Sprint 400 AS #s W,... AS# X AS #s Y,... AS Numbers AS #s Z,... 401 | | | | | 402 +---+---++++ ... +---+-+++++ ... +-----+-++++ 403 | |||| | ||||| | |||| 404 AS# W Routers AS# Y Routers AS# Z Routers 405 in AS W in AS Y in AS Z 407 Figure 2: AS Custodianship and Router ID PKI 409 1.2.1.3. Use of the Certificates in the PKI 411 The certificates described above are used to enable verification of: 413 * An organization's right to use a block of IP addresses 414 The IPAddrBlocks certificate extension (section 1.2.1.1) is used 415 to verify that an organization has the right to use a block of IP 416 addresses, and, using an address attestation, to authorize one or 417 more ASes to advertise them. The signature on an address 418 attestation must be verifiable using the public key in a 419 certificate containing IP address block(s) that are a superset of 420 the address prefixes in the address attestation. 422 * An organization's right to use an AS number 423 The ASIdentifiers certificate extension (section 1.2.1.2) is used 424 to verify that an AS number has been assigned to the holder of a 425 particular public key, e.g., an organization. They are used to 426 verify the certificates associated with an AS as a management 427 entity, and the certificates of the S-BGP speakers within those 428 ASes, through the AS number linkage and the usual subordinate 429 certificate validation checks. 431 * An AS's identity 432 The ASIdentifiers certificate extension (section 1.2.1.2) may be 433 used to verify the signature of an AS as a management entity on, 434 e.g., S-BGP information uploaded to S-BGP speakers -- extract 435 file(s) of address attestations, S-BGP speaker public keys, or 436 (S-BGP related) policy. Extract files are used to reduce the 437 volume of data that needs to be present at each S-BGP speaker. 439 * A router's identity and its association with an AS 440 The SBGPRouterId certificate extension (section 1.2.1.2) is used 441 to verify the signature of an S-BGP speaker on a route attestation 442 and, in conjunction with the ASIdentifiers extension, to make sure 443 that the router is authorized to act on behalf of its AS. 445 * Identity and authorization of a BGP peer 446 The SBGPRouterId certificate extension (section 1.2.1.2) may be 447 used by the BGP routers to authenticate each other when setting up 448 IPsec protected BGP peering sessions. Certificates without the 449 private extensions used by S-BGP may also be used for this 450 purpose, e.g., when a speaker's IPsec implementation cannot 451 process a certificate containing the S-BGP extensions. 453 1.2.2. Attestations 455 "Attestations" constitute the second major component of the S-BGP 456 architecture. They constitute the core of S-BGP, and represent a 457 conceptually straightforward means of achieving the critical security 458 assurances described above. It is the use of attestations, protected 459 by digital signatures, that permits S-BGP to counter Byzantine 460 attacks (including misconfiguration and typographic errors). 461 Attestations are signed and verified using the public keys from the 462 end-entity certificates of the PKI described above. They enable each 463 S-BGP speaker that receives a route advertisement to verify that each 464 AS along the path has been authorized by the preceding AS to 465 advertise the route, and that the originating AS has been authorized 466 to advertise those prefixes by the entity with the right to use each 467 IP address prefix contained in the UPDATE. 469 There are two types of attestations: 471 * Route attestations (RAs) - whose signer is an S-BGP speaker 472 authorized to represent an AS and the target is a transit AS, or 473 another AS providing third party advertisements for an AS that is 474 not running BGP. Route attestations are carried in a new BGP 475 optional transitive path attribute that contains digital 476 signatures protecting the transitive routing information. 478 * Address attestations (AAs) - whose signer is the entity that has 479 the right to use the address prefixes contained in the attestation 480 and the target is one or more ASes that are authorized to 481 originate routes to those prefixes, e.g., the organization's 482 internet service provider(s). 484 1.2.3. IPsec 486 IPsec [RFC2401, RFC2407, RFC2408, RFC2409], specifically the 487 encapsulating security payload (ESP) [RFC2406], is used to provide 488 BGP control traffic with data and partial sequence integrity, and 489 with peer entity authentication. Because it is implemented at the IP 490 layer, IPsec protects the integrity of the TCP connections used 491 between BGP speakers. Its anti-replay mechanisms detect and reject 492 replayed packets more quickly than TCP, helping to reduce the effect 493 of a denial of service attack. The IPsec anti-replay mechanisms plus 494 TCP sequence numbers ensure the "no less recent" requirement for 495 correct operation of BGP, relative to attacks mounted against inter- 496 router links. ESP may be used with the NULL confidentiality 497 algorithm [RFC2410], i.e., the BGP control traffic will be sent as 498 clear text. If confidentiality of BGP control traffic becomes an 499 issue, it will be easy to later enable the IPsec confidentiality 500 mechanisms where needed, without any changes to BGP. 502 1.3. Overview of an S-BGP Implementation 504 S-BGP adds three databases to a router. The originating AS database 505 is derived from the address attestations, and the public key database 506 is derived from the end-entity certificates of the S-BGP speakers. 507 An S-BGP speaker also has a database expressing the AS's S-BGP 508 related policy. 510 The originating AS database specifies, for each network prefix that 511 has been authorized for advertisement, the set of ASes that are 512 authorized to originate an advertisement of the prefix. The 513 authorization is provided by the entity with the right to use the IP 514 address prefix, and the authorization of that right can be traced 515 back to IANA through one of the RIRs. Each NOC verifies the address 516 attestations and the claim of right to use an address block back to 517 the IANA before generating a (signed) file that maps the prefixes to 518 their respective originating AS(es). This file can be uploaded to 519 each S-BGP speaker managed by the NOC (assuming that all the NOC's 520 ASes use the same verification policy). 522 Each time an UPDATE is received that advertises a route to a prefix 523 (NLRI or MP_REACH_NLRI), the database is consulted to verify that the 524 originating AS in the UPDATE is one authorized via an AA. 526 Implementation Note: 527 One way that the AA lookup table may be efficiently implemented is 528 by a radix trie built from the prefixes. This trie might be part 529 of a RIB. 531 The public key database contains, for each S-BGP speaker or AS, the 532 DSA public key(s) corresponding to the private key that some speaker 533 will use to sign route attestations in UPDATE messages sent to peers 534 in other ASes. Note that there may be multiple keys for a given RA 535 signer in the database due to key rollover; a key identifier is used 536 to distinguish between these keys. The NOC performs certificate 537 validation for each S-BGP speaker's and AS's end-entity certificates. 539 The certificate contains the AS identifier (number) for which the 540 speaker is being authorized to act, and is signed by a CA of the 541 entity that has the right to use that AS number. The validation 542 process traces the right to use the AS identifier back to IANA. A 543 speaker's identity (BGP Identifier), the AS that it represents, the 544 public key, and key identifier from the certificates which pass the 545 validation process are placed into a (signed) file that is uploaded 546 to each S-BGP speaker managed by the NOC (assuming that all the NOC's 547 ASes use the same verification policy). 549 Each time an UPDATE containing the ATTEST path attribute is received 550 that advertises a route, it contains a signed route attestation from 551 each exit speaker along the path (corresponding to the exit speaker 552 prepending its AS number to the AS Path attribute). The signature 553 covers the identity of the AS(es) to which the UPDATE is being 554 passed, as well as other transitive information in the UPDATE (e.g., 555 Origin, AS PATH, NLRI). A speaker that receives an UPDATE verifies 556 the signature on each RA in the ATTEST path attribute using the RA 557 specified public key from the public key database. 559 Implementation Note: 560 One way that the public key lookup table may be efficiently 561 implemented is by a radix trie built from the BGP identifiers or 562 AS identifiers. 564 A speaker may have a private DSA key that is used to sign route 565 attestations. Such a private key SHOULD NOT be shared with other 566 speakers. Alternatively, several speakers may use a shared private 567 key, bound to the AS for which the speakers are authorized to act. 568 It is RECOMMENDED that such a private key be stored in a hardware 569 token so as to minimize the chance of the shared key being 570 compromised. The shared key alternative can reduce the number of 571 public keys for an AS in the public key database from one per 572 inter-AS S-BGP speaker to a single key. 574 Each speaker contains a database with its AS's S-BGP related 575 configuration and policy information. Some parts of this information 576 may be common throughout an AS, while other parts may be specific to 577 the speaker, or to one of the speaker's peers, or even to particular 578 remote AS(es) for which the local administration wants special 579 handling. 581 See Appendix B for examples of general configuration items, and 582 Appendix C for examples of policy controls that a vendor might chose 583 to implement. 585 The BGP specification [RFCbgp] requires a speaker to retain in its 586 Loc-RIB (or Adj-RIB-In) the path attributes that were received with 587 each prefix. The S-BGP ATTEST path attribute is treated like any 588 other transitive path attribute in this respect; it needs to be 589 retained so it can be included in UPDATE messages sent to peers. 591 An RA is used to dynamically convey authorization from one AS to the 592 next along the AS path to use the advertisement as input to its route 593 selection process. In order to prevent some forms of cut and paste 594 attacks, an RA, signed by the exit speaker in an AS, includes the AS 595 number of the AS(es) to which the UPDATE will be sent. If an UPDATE 596 is to be sent directly to peers in multiple ASes, or indirectly via a 597 route reflector at a NAP, special configuration is required to 598 identify the ASes that need to be included in the target part of the 599 RA (see, e.g., sign-AS in Appendix C.3.1). 601 The fact that S-BGP signs transitive information in an UPDATE, and 602 that the signature is carried in a path attribute, means that, in 603 general, all of the other path attributes and NLRI information must 604 be known before the signature can be generated. Since the BGP 605 specification suggests that the path attributes be ordered by Type 606 Code, and that both the Type Code assigned to the ATTEST path 607 attribute may not be the largest Type Code ever assigned to 608 transitive information, and the IPv4 NLRI follow the path attributes 609 in an UPDATE message, the flow of control that may have been 610 implemented in the past may have to be altered in an S-BGP 611 implementation. This is analogous to the change that the 612 introduction of the MP_REACH_NLRI path attribute may have 613 necessitated. 615 Canonical Ordering of Information 617 The Digital Signature Algorithm (DSA) [DSA] provides an integrity 618 service by signing a cryptographic hash (SHA-1) [SHA-1] of the 619 information to be protected. The signer hashes the information and 620 signs it; the receiver hashes the information and the DSA determines 621 whether or not the computed hash matches the hash that was signed. 622 This means that the string of octets that the signer hashed must be 623 identical to the string of octets that the receiver hashes. If the 624 octets are not identical, signature verification will fail. 626 This leads to a requirement that the receiver be able to determine 627 the ordering of the octets that the signer hashed. The BGP 628 specification does not require that the ordering of all transitive 629 information be preserved when propagated by a BGP speaker. For 630 example, a BGP speaker is allowed to change: the order of ASes in an 631 AS_SET (including removal of duplicates); the partitioning of ASes 632 between adjacent AS_SEQUENCEs; the order of communities in the 633 Communities [RFC1997] and Extended Communities [EXT-COMM] path 634 attributes, or the ordering of prefixes in the NLRI or MP_REACH_NLRI 635 path attribute. To avoid this problem, S-BGP specifies a canonical 636 ordering for several pieces of information. 638 A signer MUST convert information to be advertised in an UPDATE to 639 the canonical representation before computing the hash to be signed, 640 and the receiver MUST convert the received information to the 641 canonical order before computing the hash required for signature 642 verification. Path attribute data in the Explicit Data part an RA 643 SHOULD be in canonical order. It is RECOMMENDED that speakers put 644 the information in the path attributes and NLRI fields of an UPDATE 645 in the canonical order whenever possible, as the CPU cost for all 646 receivers to verify that the ordering is canonical is usually less 647 than the cost to convert non-canonical information into the canonical 648 order. 650 Protection of Attributes whose Content Changes 652 The transitive information in an UPDATE message may change as the an 653 UPDATE is passed from one AS to the next. Three examples are the AS 654 PATH path attribute [RFCbgp], the community path attributes [RFC1997] 655 [EXT-COMM], and the NLRI [RFCbgp] [RFC2858]. When the protected 656 information changes, a receiving speaker will not be able to verify 657 the signatures on previous RAs unless it has access to the 658 information before the change. E.g., when AS adds a community to a 659 received community attribute, subsequent receivers need to be able to 660 determine the communities that were present before the addition. 662 S-BGP meets this requirement by including in each RA an area 663 (ExplicitPA) where a speaker that is changing protected transitive 664 information MUST store a canonicalized copy of the information as it 665 was before the change. Note that the RA where the information is 666 stored is the RA that was received, not the RA added by the speaker 667 making the change. The rules for computing the hash of the protected 668 information are specifically defined so as to allow this change to 669 the ExplicitPA part of a received RA without invalidating the 670 signature. 672 Changes to the NLRI or MP_REACH_NLRI MUST also be recorded. Whenever 673 the NLRI are changed, e.g., one or more prefixes are removed, or 674 prefixes are aggregated, a canonicalized copy of the original NLRI 675 information MUST be placed into the ExplicitPA part of an RA. Note 676 that a consequence of this requirement is that one cannot make the 677 size of an S-BGP protected UPDATE message smaller by splitting the 678 received NLRI into multiple UPDATE messages. It is the originator's 679 responsibility to limit the size of the NLRI included in an UPDATE to 680 allow for the addition of RAs as the UPDATE passes from AS to AS 681 through the network. The originator is the responsible agent, since 682 it is the originator's networks that will be unreachable if one of 683 their UPDATEs becomes too large to meet the BGP 4 KByte maximum 684 packet size limit. In particular, if an ISP knows that some prefixes 685 that it originates are multihomed to other ASes, a conservative 686 strategy would be to place those prefixes into separate UPDATE 687 message(s). See. e.g., max-origin in Appendix C.4.3. 689 In other cases, e.g., the AS PATH path attribute, the change that an 690 AS makes is usually predictable. I.e., an AS inserts its AS number 691 one or more times to the list of ASes in the first AS_SEQUENCE. In 692 situations where changes to a path attribute are the predictable 693 changes, there is no need to record a copy of the pre-changed 694 attribute in the ExplicitPA part of an RA; i.e., doing so is 695 OPTIONAL. In the case of the AS PATH attribute, there are also 696 situations where the change is not predictable, e.g., when 697 aggregation has introduced an AS_SET. When changes are made that are 698 different than the predictable change, a copy of the pre-changed 699 information MUST be saved in the ExplicitPA part of an RA. 701 Aggregation 703 BGP uses "aggregation" for multiple purposes. It can be used to: 705 1) combine more specific prefixes into a less specific prefix in 706 routes that a speaker originates; 707 2) reduce the number of entries in the routing table (Loc-RIB, etc.), 708 and consequently to: 709 3) reduce the number of entries in the (hardware) forwarding tables; 710 4) reduce the number of UPDATE messages that need to be sent to peers 711 and stored in their Adj-RIB-Ins; 712 5) reduce the size of the information passed to peers; and 713 6) hide information from ASes to which a speaker advertises routes 714 that the speaker received from other AS(es). 716 Aggregation in S-BGP is consistent with all but the last purpose 717 (although it generally may be an AS hop after aggregation before (5) 718 can be realized). The ability to hide information is inconsistent 719 with the ability to verify that the information supplied has not been 720 inappropriately modified. S-BGP sacrifices information hiding to 721 achieve integrity, authorization, and authenticity. 723 An S-BGP speaker that performs route aggregation places into the 724 Attestation path attribute all of the RAs from the routes that it is 725 aggregating, after first making explicit the protected transitive 726 information in each of those routes. 728 2. Terminology 730 There are several terms, e.g., "last RA" and "first RA", that are 731 used throughout this document which may not be intuitive, leading to 732 confusion and possible misunderstanding. Those terms are defined 733 here as they will be used in this document. The terms are ordered 734 for readability instead of alphabetically. 736 Keywords 737 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 738 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in 739 this document, are to be interpreted as described in [RFC2119]. 741 Protected Transitive Information 742 The transitive routing information that S-BGP protects using 743 digital signatures. The term includes both the address prefixes 744 in either the NLRI field or the MP_REACH_NLRI path attribute, as 745 well as a configurable set of other path attributes that contain 746 information distributed beyond a single AS hop. Examples of the 747 latter are the Origin and Community path attributes. 749 Certification Authority (CA) 750 An entity that issues digital certificates (especially X.509 751 certificates) and vouches for the binding between the data items 752 in a certificate. [RFC2828] 754 Certificate 755 A certificate document in the form of a digital data object (a 756 data object used by a computer) that contains a sequence of data 757 items and to which is appended a computed digital signature value 758 that depends on that sequence of data. A digital certificate 759 binds an identity to a public key value, and possibly to 760 additional data items. [RFC2828] 762 Certificates contain several items of information, including the 763 subject's public key, that are validated by a Certification 764 Authority which then digitally signs the information using its 765 private key. See [RFC3280]. Certificates used with S-BGP contain 766 private extensions used [X509EXT] to convey authorization to use 767 IP address blocks, AS identifiers, or [X509S-BGP] to bind a BGP 768 Identifier to a specific router and AS. 770 Certificates containing S-BGP extensions are issued to the CAs of 771 Regional Internet Registries (APNIC, ARIN, RIPE, etc.), 772 organizations that have the right to use IP address blocks or 773 Autonomous System numbers. End-entity certificates containing one 774 of the extensions are issued to networks, Autonomous Systems, and 775 BGP speakers (routers). Other end-entity certificates are issued 776 for management purposes, e.g., authentication of the S-BGP 777 certificate, CRL, and AA repositories, and for access control of 778 changes to the content of a repository. 780 Each NOC uploads its certificates, CRLs, and address attestations 781 to one of the replicated S-BGP repositories, and subsequently 782 downloads all the certificates, CRLs, and address attestations for 783 local validation, processing, and distribution to S-BGP speakers. 785 End Entity 786 An entity that is the subject of a public key certificate and that 787 is using, or is permitted and able to use, the matching private 788 key only for a purpose or purposes other than signing a digital 789 certificate or CRL; i.e., an entity that is not a CA. [RFC2828] 791 S-BGP end entities include networks, autonomous systems, S-BGP 792 speakers, the individual administrators and operators of an 793 autonomous system, and the S-BGP repositories. See [DISCEX]. 795 Certificate Extract 796 A condensation of the information in a certificate to only that 797 needed by an S-BGP speaker for ongoing S-BGP operation -- the 798 speaker's identity (BGP Identifier), public key, key identifier, 799 and AS number. The S-BGP related certificates are downloaded from 800 one of the S-BGP repositories by a NOC, verified according to 801 local policy, and extracted. The extracted certificates are 802 periodically uploaded to the S-BGP speakers in the AS. The 803 extracted information MAY be signed using the NOC/AS's private 804 key, so the integrity of, and authorization to use the 805 information, can assured by verification of the NOC's signature 806 covering the file. Alternate mechanisms MAY be used to assure the 807 integrity of the information. 809 Certificate Revocation Lists (CRLs) 810 A data structure that enumerates digital certificates that have 811 been invalidated by their issuer prior to when they were scheduled 812 to expire. [RFC2828] 814 A CRL is digitally signed by a Certification Authority using its 815 private key. See [RFC3280]. 817 Attestation Path Attribute (ATTEST) 818 A new BGP optional transitive path attribute used to carry S-BGP 819 countermeasure information. An attestation path attribute 820 consists of the standard BGP path attribute header (Flags, Type 821 Code, and Length) followed by a sequence of Attestations. 823 Address Attestation (AA) 824 An address attestation consists of an attestation header followed 825 by a sequence of five parts: Signer, Signature, Expiry, 826 ExplicitPA, and Target. An address attestation conveys 827 authorization by the entity with the right to use a block of IP 828 addresses (the signer) for one or more ASes (the targets) to 829 originate an advertisement for the prefix(es) specified in the 830 ExplicitPA part. 832 Each organization that generates AAs uploads them to one of the 833 replicated S-BGP repositories. 835 Address Attestation Extract 836 A condensation of the information in an AA to only that needed by 837 an S-BGP speaker for ongoing S-BGP operation -- the set of valid 838 prefixes and their authorized originating AS(es). The AAs are 839 downloaded from one of the S-BGP repositories by a NOC, verified 840 according to local policy, and extracted. The extracted AAs are 841 periodically uploaded to the S-BGP speakers in the AS. The 842 extracted information MAY be signed using the NOC/AS's private 843 key, so the integrity of, and authorization to use the 844 information, can assured by verification of the NOC's signature 845 covering the file. Alternate mechanisms MAY be used to assure the 846 integrity of the information. 848 Signer (Part of an AA or RA) 849 The Signer part contains information that identifies the entity 850 that signed the attestation so that the entity's public key can be 851 found to verify the signature. An signer is usually identified by 852 an IP v4 or v6 address, but may also be identified by an AS number 853 or a DNS name. 855 Signature (Part of an AA or RA) 856 The Signature part identifies the digital hash function and 857 signature algorithm used to sign the attestation. Also present 858 are the bytes of the signature and a key identifier that specifies 859 which public key belonging to the signer should be used to verify 860 the signature. 862 The Signature part of an RA has a bit mask identifying the path 863 attributes that are protected by the digital signature. The 864 digital signature protects the Expiry, ExplicitPA, and Target 865 parts of an AA or RA. 867 The algorithm specified in this document, the Digital Signature 868 Standard [DSS] and the Secure Hash Algorithm, revision 1 [SHA-1], 869 MUST be implemented in all S-BGP speakers. 871 Expiry (Part of an AA or RA) 872 The Expiry part contains the date after which the attestation is 873 no longer valid. 875 Also present in the expiry part of an RA are the "A-bit" (used to 876 indicate path aggregation) and the RASC field. 878 ExplicitPA (Part of an AA or RA) 879 The ExplicitPA part contains a canonicalized version of the 880 protected transitive information covered by the digital signature. 882 Explicit Data 883 When a canonicalized copy of the protected transitive information 884 is placed into the ExplicitPA part of an attestation, it is called 885 explicit data. 887 Implicit Data 888 When the protected transitive information can be derived from 889 either the UPDATE's NLRI or path attributes, or from data in a 890 previous RA, it may be omitted from the ExplicitPA part of an RA. 891 The omitted, redundant, information is called implicit data. Use 892 of implicit data reduces the size of an RA. 894 Target (Part of an AA or RA) 895 The semantics of the Target part differs between AAs and RAs. 897 In an AA, it contains the AS number(s) of the ASes that are being 898 authorized by the signer of the AA to originate the prefixes in 899 the prefix pseudo path attribute (see 3.1.1, part e) in the 900 ExplicitPA part. 902 The Target part of an RA contains the AS number of the AS (or 903 ASes, e.g., when route reflectors are being used) that is being 904 authorized by the signer (e.g., an S-BGP capable exit border 905 router) to place the route into its Adj-RIB-In. 907 Authenticator (of an extract file) 908 An authenticator consists of at least the identity of the signer, 909 the key identifier of the public key to be used in verifying the 910 signature, and the signature information. Different vendors MAY 911 use alternate mechanisms for the encoding of extract files and for 912 the encoding of the signature information. 914 Some vendors MAY omit the authenticator, when alternate mechanisms 915 provide the integrity and authenticity of the extract file 916 content. 918 Route Attestation (RA) 919 An RA consists of an attestation header followed by a sequence of 920 five parts: Signer, Signature, Expiry, ExplicitPA, and Target. A 921 route attestation is used to ensure the integrity and authenticity 922 of the protected transitive information being propagated in BGP 923 UPDATE messages. An RA is prepended to the RA section of the 924 attestation path attribute by an AS's S-BGP capable exit border 925 router. The RA section in an attestation path attribute contains 926 an ordered sequence of one or more RA sequences. 928 Generated RA 929 Each S-BGP capable exit border router of an AS prepends an RA to 930 the RA sequence contained within an UPDATE's attestation path 931 attribute prior to propagating the UPDATE. The prepended RA is 932 referred to as the locally generated RA. 934 RA Sequence 935 As a BGP advertisement propagates through an internet, each S-BGP 936 capable exit border router prepends a locally generated and signed 937 RA to the RA section of the attestation path attribute in UPDATE 938 messages sent to external peers (analogous to the prepending of an 939 AS number to the AS PATH path attribute). See Figure 3, which 940 depicts three ASes and a schematic of the UPDATE message that 941 would be sent by the exit border routers (N.8 and U.7). In the 942 figure, the advertisement is being propagated from right to left. 943 The ordered sequence of RAs in the attestation path attribute is 944 referred to as an RA sequence. 946 RA Sequence Count (RASC) 947 A count of the number of (remaining) RAs in an RA sequence, 948 including the RA containing the count. It is used to 949 (recursively) linearize the RAs in an aggregation tree. The 950 aggregation tree is necessary to enable speakers to resolve and 951 validate implicit data. When combined with the identify of the RA 952 signer, the count enables detection of the malicious removal of, 953 or insertion of, RAs in an attestation path attribute. 955 UPDATE UPDATE 956 Sent to AS 2 by AS 8 Sent to AS 8 by AS 5 957 +--------------------------+ +--------------------------+ 958 | Path Attributes: | | Path Attributes: | 959 | AS Path: 8,8,5 | | AS Path: 5 | 960 | ... (Other path attrs) | | ... (Other path attrs) | 961 | Attestations: | | Attestations: | 962 Last RA --> | RA: | | | 963 | Signer: U.0.0.7 | | | 964 | Sig: ... | | | 965 | Expiry | | | 966 | Date: ... | | | 967 | A-bit: 0 | | | 968 | RASC: 2 | | | 969 | ExpPA | | | 970 Explicit -> | Prefixes:10.1/16 | | | 971 Data -> | AS Path: 8,8,5 | | | 972 | Target: AS 2 | | | 973 First RA -> | RA: | | RA: | 974 | Signer: N.0.0.8 | | Signer: N.0.0.8 | 975 | Sig: ... | | Sig: ... | 976 | Expiry: | | Expiry: | 977 | Date: ... | | Date: ... | 978 | A-bit: 0 | | A-bit: 0 | 979 | RASC: 1 | | RASC: 1 | 980 | ExpPA: | | ExpPA: | 981 Implicit -> | | | Prefixes:10.1/16 | 982 Data -> | | | AS Path: 5 | 983 | Target: AS 8 | | Target: AS 8 | 984 | NLRI: 10.1/16 | | NLRI: 10.1/16 | 985 +--------------------------+ +--------------------------+ 986 | | 987 AS 2 | AS 8 | AS 5 988 ..................... | ..................... | ............ 989 :+-------+ +-------+: V :+-------+ +-------+: V :+-------+ : 990 :|BGP Id | |BGP Id |: :|BGP Id | |BGP Id |: :|BGP Id | : 991 <-- :|F.0.0.1| |F.0.0.3|: <-- :|U.0.0.7| |U.0.0.5|: <-- :|N.0.0.8| : 992 :+-------+ +-------+: :+-------+ +-------+: :+-------+ : 993 :...................: :...................: :..........: 994 <-- Direction of UPDATE Propagation Origin AS 995 .... +--+ 996 : : Autonomous System | | S-BGP border router 997 :..: +--+ 999 Figure 3: Terminology Example 1001 First RA (in an RA Sequence) 1002 The RA inserted by the Origin AS; the final RA in an RA Sequence. 1003 The RASC in the last RA is 1. 1005 Last RA (in an RA Sequence) 1006 When an AS receives an advertisement, the RA immediately following 1007 the attestation path attribute header is called the "Last RA", 1008 i.e., the RA added to the attestation path attribute by the peer 1009 from which the UPDATE was received. The RA designated by the term 1010 Last RA changes on exit from each S-BGP capable AS; the First RA 1011 does not. 1013 Previous, Current, and Next RA (in an RA Sequence) 1014 When processing an RA sequence, on RA at a time, the Current RA 1015 begins with the Last RA and ends with the First RA. The RA 1016 processed immediately before the Current RA is called the Previous 1017 RA; in the diagram it is to the left of the Current RA. The RA 1018 that will be processed next is called the Next RA. The Next RA is 1019 the one that was inserted before the current RA. In the diagram, 1020 the Next RA is to the right of the Current RA. 1022 RA Sub-Sequence 1023 When an S-BGP speaker performs aggregation, the received RA 1024 sequences from each of the UPDATEs that are being aggregated are 1025 concatenated into a new RA sequence representing the aggregate. 1026 Each individual RA sequence is called an RA sub-sequence of the 1027 aggregated RA sequence. 1029 When aggregation is performed, the received RA sequences of each 1030 advertisement that is to be part of the aggregate are concatenated 1031 before the locally generated RA is prepended. The RASC field of 1032 the locally generated RA is set to one more than the number of RAs 1033 that were concatenated. Equivalently, it is set to 1 plus the sum 1034 of the RASC fields of the first RA in each of the RA sub-sequences 1035 being aggregated. 1037 3. Attestation Path Attribute (ATTEST) 1039 S-BGP uses a new optional, transitive BGP path attribute to 1040 distribute in-band security information to BGP routers in UPDATE 1041 messages. The attestation path attribute (ATTEST) contains an 1042 ordered list of Route Attestations. The use of in-band security 1043 information makes the dynamics of the protection mechanisms match the 1044 dynamics of topology changes. This is especially important when, 1045 e.g., a major fiber cut necessitates new peerings that do not exist 1046 under normal conditions. In these extraordinary situations, the 1047 ATTEST path attribute MAY also contain a set of Address Attestations, 1048 to handle the case where an organization needs to temporarily use a 1049 new provider. The ordering of the RAs in the route attestation 1050 section is described in sections 2 and 3.1.2. 1052 One route attestation is prepended to the RA sequence in the 1053 attestation path attribute in an UPDATE message by each S-BGP capable 1054 Autonomous System (AS) through which the UPDATE is propagated. It is 1055 prepended by the AS's exit border router and identifies (in the 1056 Target part) the AS(es) that are being authorized to use the route -- 1057 usually the AS(es) to which the UPDATE message is being sent. The RA 1058 contains a digital signature that protects both the protected 1059 transitive information being announced to the receiving AS(es) and 1060 the identity of those AS(es). The identity of a receiving AS is 1061 necessary both to protect against some forms of cut and splice 1062 attacks and to provide explicit authorization for the speakers in the 1063 receiving AS to use the information in the advertisement. One 1064 consequence of this requirement is that a speaker can no longer 1065 simply forward the contents of an UPDATE message to peers in 1066 different neighboring ASes unless each of those ASes has been 1067 included in the list of ASes in the target field of the RA. See, 1068 e.g., sign-AS in Appendix C.3.1. 1070 The capability to include multiple ASes in the Target part of an 1071 attestation may also be used when, e.g., the current and receiving 1072 ASes receive UPDATEs from a common external route reflector. 1074 The attestation path attribute has Type Code *IANA-TBD*. 1076 The BGP path attribute header is as described in [RFCbgp]. The 1077 following sections describe the attestation path attribute's value. 1079 3.1. Attestation Path Attribute Formats 1081 Address attestations and route attestations share a common format, 1082 described in section 3.1.1. Each logically related set of fields in 1083 an attestation is called a "part". An S-BGP part code is assigned to 1084 the section for RAs and AAs, as well as to each part of an 1085 attestation. 1087 3.1.1. Route and Address Attestations 1089 The parts within an attestation MUST appear in the order shown in 1090 Figure 4. 1092 Each part of an attestation starts with a four-bit Part Code field. 1093 Following the Part Code field is a 12-bit Length field that contains 1094 the length in octets of the value (remainder of the attestation 1095 part). I.e., the length does not include the two octets containing 1096 the Part Code and Length fields. 1098 The parts of an address or route attestation are as follows: 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Object Type/Length(length = 2)| 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 1103 | Signer (variable length) 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 1105 | Signature (variable length) 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... ----- 1107 | Expiry (length = 8 for RAs, 6 for AAs) ^ 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | 1109 | ExplicitPA (variable length) Signed 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | 1111 | Target (variable length) v 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... ----- 1114 Figure 4: Structure of an Address or Route Attestation 1116 a) Attestation Objects (Part Codes 8, 9, and 14): 1118 The Part Code is 8 for a route attestation, and 9 for an address 1119 attestation. Part Code 14 is reserved for an extract file 1120 authenticator, if a vendor chooses to use this encoding. The 1121 twelve-bit length is the length of the rest of the attestation 1122 (not including the Part Code and Length). 1124 0 1 1125 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 |1 0 0 0| RALength | RA 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 |1 0 0 1| AALength | AA 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 |1 1 1 0| AuthenticatorLength | Encoding for an optional 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extract File Authenticator 1138 Figure 5: Route and Address Attestation and Authenticator Headers 1140 b) Signer part (Part Code 1): 1142 The Signer part identifies the entity which signed the 1143 attestation. The public key required to verify the signature is 1144 in a certificate issued to this entity. The signer can be 1145 described by one of four name formats: a four-octet AS number, a 1146 four-octet IPv4 address, a sixteen-octet IPv6 address, or a 1147 variable length DNS name. DNS format names MUST NOT be terminated 1148 by a NIL character. The AFI field is a two-octet field following 1149 the SignerLength field that indicates the format of the following 1150 identifier. The values for this field are taken from the Address 1151 Family Identifier number space of [IANA-AFI]. I.e., it is 1 for 1152 an IPv4 address, 2 for an IPv6 address, 18 for an AS number, and 1153 16 for a DNS name. The SignerLength field contains two plus the 1154 length of the identifier in the SignerData field. 1156 0 1 2 3 1157 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 |0 0 0 1| SignerLength | AFI | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 | SignerData (variable length) 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1164 Figure 6: Signer Part 1166 The SignerData field contains the identity of the signer encoded 1167 in one of the following four formats: 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 | AS Number (length 4) | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 | IPv4 (length 4) | 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | IPv6 (length 16) | 1179 | | 1180 | | 1181 | | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | Textual DNS Name (N octets, not NIL terminated) 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 1188 Figure 7: Formats of Signer Name Forms 1190 Note that S-BGP encodes all AS numbers as four octet quantities, 1191 see [AS4Bytes]. 1193 c) Signature part (Part Code 2): 1195 The Signature part contains the information necessary to verify 1196 the integrity of the protected transitive information associated 1197 with the attestation. The signature algorithm identifier, 1198 SigAlgID, follows the SignatureLength field and is one octet long. 1199 Currently one signature algorithm is defined, DSA with the SHA-1 1200 hash; this algorithm is assigned an ID of 2 [IANA-SAN]. 1202 The next field is a one-octet KeyId used to identify which of 1203 multiple valid public keys for the signer was used to generate the 1204 signature. For DSA, the value is the (last octet of) the 1205 SubjectKeyIdentifier field in the Subject Key Identifier extension 1206 in the signer's certificate. 1208 Following the KeyId is a one-octet CoverageLen field, providing 1209 the length in octets of the immediately following CoverageMask 1210 field. 1212 The final field in the Signature part is the signature itself, 1213 which for DSA consists of R (20 octets) followed by S (20 octets). 1215 0 1 2 3 1216 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 |0 0 1 0| SignatureLength | SigAlgID | KeyId | 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | CoverageLen | CoverageMask (variable length) 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | SignatureBytes (40 octets for DSA signature...) | 1223 | (20 octets of DSA R) | 1224 | (20 octets of DSA S) | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 Figure 8: Signature Part 1229 The CoverageMask field identifies which BGP path attributes are 1230 protected by the signature. Only RAs have a CoverageMask; AAs do 1231 not, and set the CoverageLen field to zero. Each bit corresponds 1232 to a Path Attribute Type Code. For each path attribute covered by 1233 the signature, the corresponding CoverageMask bit MUST be set to 1234 1. The NLRI is assigned bit zero (for either the IPv4 NLRI at the 1235 end of an UPDATE message, or for the MP_REACH_NLRI path attribute 1236 (see e, ExplicitPA part, below). 1238 In order to allow path attributes defined in the future to be part 1239 of the protected transitive information, the coverage bits are 1240 placed in ascending order starting at the leftmost bit in the 1241 network byte order mask. In the following diagram the zero bits 1242 identify attributes that are never protected due to their non- 1243 transitive usage, 1 indicates attributes that MUST always 1244 protected (when present), and the "?" bits correspond to 1245 attributes which MAY be protected, according to local policy. 1246 Note that the ATTEST path attribute itself is never protected. 1248 0 1 1249 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1251 |? ? 1 0 0 0 ? ? ? 0 0 ? 0 0 0 0 ? 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1254 0: NLRI or MP_REACH_NLRI; 1: ORIGIN; 2: AS PATH; 1255 6: ATOMIC AGGREGATE; 7: AGGREGATOR; 8: COMMUNITIES 1256 11: DPA; 16: EXTENDED COMMUNITY; ... (others to be defined) 1258 Figure 9: CoverageMask Field 1260 d) Expiry part (Part Code 3): 1262 The Expiry part specifies the date after which the attestation 1263 should not be considered valid. The Part Code field is four bits, 1264 and the following Length field is 12 bits. Note that the length 1265 is always 6 for RAs (which include the A-bit and RASC fields) and 1266 4 for AAs (which do not). 1268 The first field after ExpiryLength occupies two octets and 1269 contains the four-digit year, followed by a one-octet field whose 1270 four least significant bits contain the month (1 to 12), followed 1271 by a one-octet field containing the day (1 to 31). The 1272 attestation is not valid after the specified year, month, and day. 1274 The Expiry part of an RA contains in addition a two-octet field 1275 containing the 1-bit A-bit and 11-bit RASC sub-fields. The RASC 1276 field indicates how many RAs, including the RA containing the 1277 field, remain in the RA sequence of which this RA is a member (see 1278 section 2). The A-bit field indicates whether or not the speaker 1279 performed route aggregation: 1 indicates it did, and 0 indicates 1280 it did not. 1282 0 1 2 3 1283 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 Expiry |0 0 1 1|ExpiryLength(AA=4,RA=6)| Year, e.g., 2002 = 0x7d2 | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | 0 |Month:4|0 0 0 Day:8 | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 |A| RASC |(RAs only) 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 Figure 10: Expiry Part 1294 e) ExplicitPA part (Part Code 4): 1296 The ExplicitPA part may contain a canonicalized version of the 1297 protected transitive information. The path attributes to be 1298 protected are specified by local policy and indicated by a bit in 1299 the CoverageMask as described above. The validation process must 1300 be able to find the actual values protected by the digital 1301 signature (to verify it) even though the values of the actual NLRI 1302 or path attributes may change as an UPDATE message is propagated 1303 from AS to AS. Information in the ExplicitPAs field is encoded as 1304 standard BGP path attributes with path attribute Flags, Type Code, 1305 and Length (see [RFCbgp]). The the information in the attribute 1306 value field is canonicalized. The individual path attributes in 1307 the ExplicitPAs field (and as hashed for signature computation and 1308 verification) MUST be sorted by ascending path attribute Type 1309 Code. 1311 0 1 2 3 1312 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 |0 1 0 0| ExplicitPALength | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 1316 | ExplicitPAs (variable length) -- sequence of path attributes 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 1319 Figure 11: ExplicitPA Part 1321 Prefixes, from either the NLRI field or from the MP_REACH_NLRI 1322 path attribute, are encoded in the ExplicitPAs field as an 1323 optional transitive path attribute with Type Code 0, as shown in 1324 the figure below. The attribute value consists of a two-octet 1325 AddressFamilyIndicator field (see [IANA-AFI]), a one-octet SAFI 1326 field (see [IANA-SAFI] [RFC2858]), a one-octet maximum prefix 1327 length field, and one or more prefixes. In the case of IPv4 NLRI, 1328 the AddressFamilyIndicator field contains 1 (IPv4) and the SAFI is 1329 usually 1 (unicast). The individual prefixes MUST be sorted by 1330 ascending
(but encoded in the standard way 1331 -- as a one-octet bit count and the number of prefix octets 1332 required to hold the specified number of bits; unused bits MUST be 1333 zero). Having the speaker that creates the RA sort the prefixes 1334 simplifies RA validation for all speakers that receive an RA. 1335 Since the prefix information uses path attribute Type Code 0, the 1336 prefixes will, when present, be the first entry in the ExplicitPAs 1337 field. 1339 0 1 2 3 1340 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1342 |1 1 0 E 0 0 0 0| Type Code 0 | Length :Extended Length 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | AddressFamilyIndicator | SAFI | MaxPrefixLen | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | PrefixLength | Prefix (other PrefixLength/Prefix pairs) 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1349 Figure 12: Prefix Encoding 1351 This canonicalized encoding is used to make the prefix information 1352 invariant between NLRI and MP_REACH_NLRI, since IPv4 prefixes may 1353 be encoded in either format, and the encoding may change as an 1354 UPDATE message propagates through ASes. When canonicalizing the 1355 (IPv4) NLRI field, the AddressFamilyIndicator MUST be set to 1, 1356 and the SAFI to 1 when the IPv4 addresses are unicast, or to 2 1357 when the IPv4 addresses are multicast (within the 224/4 prefix). 1359 The maximum prefix length field, MaxPrefixLen, is zero in RAs. In 1360 an AA, it indicates the maximum prefix length of any more specific 1361 prefix that the prefix owner is authorizing to be advertised. 1362 This is used to thwart an attack where a more specific prefix is 1363 received, e.g., from an adversary or an AS not running S-BGP. If 1364 an advertisement for a more-specific is received, it is an 1365 auditable event and MUST be rejected. Note that AA information is 1366 applied to all UPDATEs received, not just those containing an 1367 ATTEST path attribute. 1369 f) Target part (Part Code 5): 1371 The Target part identifies the subject of the attestation. The 1372 target of an RA is the AS number of the BGP speaker(s) to which 1373 the UPDATE message will be sent, directly, or indirectly via a 1374 route reflector. The target of an AA is a list of AS numbers of 1375 the ASes being authorized to originate a route to the prefixes in 1376 the ExplicitData part, e.g., when the organization owning the 1377 prefixes is multihomed to different ASes. The length of the 1378 Target part is variable, and the number of AS numbers present may 1379 be computed by subtracting two octets from the TargetLength and 1380 dividing by four. AS numbers MUST be encoded as four octet values 1381 not as two octets values. 1383 The AFI field contains 18, per [IANA-AFI], to indicate the target 1384 uses the AS number format. 1386 0 1 2 3 1387 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 |0 1 0 1| TargetLength | AFI = 18 (AS number) | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 | AS number | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 | (possibly more AS numbers) 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1396 Figure 13: Target Part 1398 3.1.2. RA Sequences and Aggregation 1400 The order of RAs in the RA sequence in an ATTEST path attribute is 1401 fairly straightforward when there is no aggregation. Each exit 1402 border speaker prepends its locally generated and signed RA to the RA 1403 sequence in the ATTEST path attribute before advertising the route to 1404 an external peer. The RASC (RA Sequence Count) field in the Expiry 1405 part of the locally generated RA is set to one more than the RASC 1406 field of the Last RA in the received ATTEST path attribute, or to one 1407 in a locally originated advertisement. The A-bit is set to 0. 1409 Aggregation requires that the RA sequences from each of the routes 1410 being aggregated be concatenated into a single RA sequence. There 1411 are no ordering requirements on the concatenation operation. Figure 1412 14 illustrates RA lcl concatenating two RA sequences: RA a, RA b, RA 1413 c; and RA z. RA a and RA z are the Last RAs in their respective RA 1414 sequences. Note that in this example, the RA sequence RA a, RA b, RA 1415 c is itself the result of an aggregation, however RA lcl does not 1416 need to be cognizant of that fact when concatenating the individual 1417 RA sequences. When the aggregator's RA (RA lcl) is generated and 1418 prepended to the concatenated RA sequence the A-bit is set to 1 and 1419 the RASC field is set to one more than the sum of the RASC fields of 1420 the Last RAs in each of the RA sequences being concatenated (in the 1421 example, 1 for the lcl RA, plus 3 from RA a, plus 1 from RA z). 1423 RA lcl | RA a RA b RA c | RA z 1424 from aggregator | Last in seq. ----------------------> | Last in seq. 1425 +--------------+ +----------+ +----------+ +----------+ +----------+ 1426 | (other data) | | | | | | | | | 1427 | RASC: 5 | | RASC: 3 | | RASC: 1 | | RASC: 1 | | RASC: 1 | 1428 | A-bit: 1 | | A-bit: 1 | | A-bit: 0 | | A-bit: 0 | | A-bit: 0 | 1429 +--------------+ +----------+ +----------+ +----------+ +----------+ 1431 Figure 14: Aggregation Example 1433 An S-BGP speaker can (recursively) locate the RA sub-sequences which 1434 were concatenated during aggregation as follows. When an RA with the 1435 A-bit set is located, say RA lcl in the figure, its RASC field 1436 contains the number of RAs in the aggregate associated with that RA 1437 (lcl): 5. If the number is less than one, a parse error should be 1438 handled. The RA sequences that were concatenated are found by 1439 subtracting 1 (representing the RA of the aggregator, RA lcl) from 1440 the working count (resulting in 4). The RASC field of the next RA, 3 1441 from RA a, is used to determine the RA sequence length of a RA sub- 1442 sequence in the aggregation; that count is subtracted from the 1443 working count (resulting in 1). If the number is less than zero, a 1444 parse error should be handled. If the count is greater than zero 1445 there is another RA sub-sequence in the aggregation. The number of 1446 RAs in the Previous RA sub-sequence, 3, is skipped to locate the Last 1447 RA in the Next RA sub-sequence, i.e., RA z. Its RASC count 1448 determines the length of the next of the RA sub-sequences. The 1449 process is repeated until the working count reaches zero. 1451 This deconstruction of the RA sequences in an aggregate is used by 1452 S-BGP speakers to determine the correspondence between the AS numbers 1453 in the AS_SET created by aggregation and the individual RA sequences, 1454 so that the authorized originating AS and path can be validated (see 1455 section 3.2.2.2). 1457 3.2. S-BGP Processing 1459 Initialization of security functions is performed. 1461 The certificates and/or the public keys of the peers are loaded for 1462 use by IPsec. 1464 When the BGP process is initialized, the S-BGP DSA parameters are 1465 initialized from, e.g., a trusted S-BGP root certificate. A working 1466 copy of the trusted NOC's public key should be initialized, e.g., 1467 from the trusted NOC's certificate. The validated public key 1468 information for the S-BGP speakers should be loaded; an 1469 implementation may insure the integrity and authenticity of the 1470 authorized public keys by using the NOC's public key to verify a 1471 signature of the data. Similarly, the integrity and authenticity of 1472 the address attestation information used to verify the legitimacy of 1473 an originating AS should be verified. Note that digital signatures 1474 are not required if an alternate mechanism to insure integrity and 1475 authenticity of the information is being used. 1477 Implementation Note: 1478 Depending on the implementation chosen for the AA cache, this 1479 action may have the side effect of constructing a routing table 1480 without any Adj-RIB-Ins. 1482 The private key which the speaker will use to sign route attestations 1483 is activated for use. Private keys SHOULD be stored in cryptographic 1484 hardware, e.g., in a PCMCIA card, and activated via a software 1485 method. An implementation MAY choose to check that the public key 1486 corresponding to the private key that will be used to sign RAs is in 1487 the public key file by signing, e.g., a random number, and then 1488 trying to verify the signature. If the signature cannot be verified, 1489 the speaker's configuration needs to be corrected. 1491 A non-volatile cache of validated routes (containing RAs) MAY also be 1492 preloaded, with the routes all marked as inactive. If the cache is 1493 preloaded, the integrity and authenticity of the data SHOULD be 1494 verified. One way to implement the verification is to have the S-BGP 1495 speaker sign a hash of the data it wrote to the cache using its 1496 private key. 1498 S-BGP specific policy for the speaker, its peers, and other speakers 1499 and autonomous systems can be loaded on restarts. There SHOULD be a 1500 mechanism to ensure the integrity and authenticity of the configured 1501 policy. One way would be for the NOC to sign it using its private 1502 key. 1504 IPsec SAs are negotiated for each peering session as they are 1505 created. 1507 Additional support, described in the sections to follow and Appendix 1508 C, is recommended to help manage the incremental deployment of S-BGP. 1510 3.2.1. Route Attestation Processing 1512 The processing of route attestations, which are used to validate the 1513 integrity of the AS path and other protected transitive information, 1514 consists of several steps. 1516 The structure and internal consistency of the ATTEST path attribute 1517 and the attestations that it contains needs to be checked. If an 1518 error is detected, a parse error is handled. 1520 The signatures in received RAs are verified. In order to verify an 1521 RA's signature, all the signed information (the Expiry, ExplicitPA, 1522 and Target parts) of the RA must be identified. The Expiry and 1523 Target parts contain all the data needed for their verification. 1524 However, the ExplicitPA part will usually not contain all the data 1525 identified by the CoverageMask field in the Signature part; some data 1526 might be implicit. Any implicit data in the Last RA is obtained from 1527 the NLRI and/or path attributes in the advertisement. Any implicit 1528 data in a subsequent RA is located by looking for that data in the 1529 previous RA (or in the aggregator's RA when the current RA is the 1530 Last RA in an RA sub-sequence). Note that the ExplicitPA's length 1531 field has to be adjusted to include the length of the resolved 1532 implicit data. 1534 RA validation also includes both verifying that each AS in the AS 1535 path has a corresponding RA, and verifying that the protected 1536 transitive information is consistent through all the RAs in the 1537 advertisement. 1539 Routes (per prefix) that are successfully validated SHOULD be so 1540 marked in the Adj-RIB-In and, per local policy, preferred over routes 1541 that are not protected by S-BGP mechanisms. Use of routes that 1542 cannot be validated is a local policy issue; see, e.g., Appendix 1543 C.5.1,2,3,4. Routes for which validation fails SHOULD NOT, per local 1544 policy, be candidates for the route selection process. Note: if all 1545 routes for a given prefix result in verification failures (as opposed 1546 to being un-protected), local policy MAY specify that such a route be 1547 used; see, e.g., only-route in Appendix C.1. 1549 Sending an Advertisement 1551 Whenever an advertisement is sent to an external peer, the BGP 1552 speaker SHOULD generate and sign an RA. The contents of the RA is 1553 as follows: 1555 The Signer part contains either the speaker's BGP Router 1556 Identifier, encoded as an IPv4 address, when the speaker has its 1557 own key; or, when a single key is to be used by multiple speakers 1558 in an AS, the Signer part encodes the AS number using the AS name 1559 form. 1561 The Signature part contains: an AlgorithmIdentifier field with the 1562 value 2 [IANA-SAN], indicating DSA with the SHA-1 hash; the KeyId 1563 field contains the least significant byte of the speaker's Subject 1564 Public Key Identifier; the CoverageMask field is set to a mask of 1565 the protected transitive information that appears in the UPDATE; 1566 the CoverageLen field is set to the number of bytes required to 1567 hold the CoverageMask field; and the SignatureBytes field is set 1568 to the network order concatenation of the 20-byte "R" and 20-byte 1569 "S" values generated by the DSA. 1571 The Expiry part contains: an expiration date that is in the 1572 future. Note that a new advertisement MUST be sent before the 1573 selected expiration date. Selection of the expiration date is a 1574 local policy decision. The A-bit and RASC field are set as 1575 follows: 1577 If the speaker is originating the route, there will be no 1578 received RAs, so the RA signed by the speaker will be the only 1579 RA in the attestation path attribute. Its RASC field is set to 1580 1. The A-bit is set to 0. 1582 If the speaker is neither originating the route nor performing 1583 path aggregation, the RA is prepended to the RAs that were 1584 received with the AS path used in the UPDATE. Its RASC field 1585 is set to 1 more than the contents of the RASC field in the 1586 Last RA in the received attestation path attribute. The A-bit 1587 is set to 0. 1589 If the speaker is performing path aggregation, then the RA 1590 signed by the speaker is prepended to the concatenation of the 1591 RA sequences associated with each of the routes that are being 1592 aggregated. Its RASC field is set to 1 more than the sum of 1593 the total number of RAs in the concatenation. The A-bit is set 1594 to 1. 1596 3.2.1.1. Route Attestation Validation 1598 Several steps are necessary to validate an RA sequence. First, the 1599 protected transitive information for all RAs in the sequence must be 1600 determined, including resolution of any implicit data. Second, any 1601 canonicalization rules must be performed (this applies to the 1602 NLRI/MP_REACH_NLRI field, and the AS PATH path attribute). Each part 1603 of the RA involved in validation must be checked. Then the prefixes 1604 in the NLRI field or MP_REACH_NLRI path attribute must be validated 1605 against both the authorized prefixes from the RA sequence(s), and, 1606 for each prefix, its originating AS must be matched with cached AA 1607 information. Finally, the digital signature of each RA must be 1608 verified. The actions which should be taken if validation fails at 1609 different stages of this process are local policy decisions. 1611 Protected Transitive Information 1613 To verify a given RA, all path attributes for which the 1614 corresponding bit is set in the CoverageMask field are required to 1615 resolve implicit data as input to the signature verification 1616 function. Path attributes marked as protected in the CoverageMask 1617 which are not in the RA's ExplicitPAs field are implicit data that 1618 has to be resolved. 1620 For the Last RA in the sequence, implicit data is located in the 1621 NLRI and/or path attributes parts of the UPDATE message. That 1622 data must be canonicalized before it is used. Once canonicalized, 1623 all data for the Last RA is explicit. See section 3.2.3.4 for 1624 discussion of validation of unknown path attributes. If data for 1625 a path attribute is already explicit in the Last RA, it MUST be 1626 compared to the unprotected data from the path attribute. 1628 For the subsequent RAs, any implicit data is copied from the now 1629 explicit data in the previous RA. The propagation of resolved 1630 data from one RA to the next RA is repeated for all RAs in the 1631 sequence, until all the RAs have been processed. 1633 When processing the RA sub-sequences, any implicit data in the 1634 Last RA is copied from the RA corresponding to the aggregation 1635 point, i.e., the one with the A-bit set (see section 3.1.2). The 1636 individual RA sub-sequences are then processed as above until the 1637 all the RAs in the RA sub-sequence have been processed. 1639 Canonicalization 1641 Path attributes are canonicalized to simplify the validation 1642 process. Of the currently defined path attributes, a canonical 1643 form is defined only for the AS PATH and the MP_REACH_NLRI path 1644 attributes. For all the other protected path attributes, their 1645 contents are copied verbatim into the ExplicitPAs field. 1647 For the AS PATH attribute, adjacent AS_SEQUENCE segments are 1648 merged into a single segment (up to the standard limit of 255 ASes 1649 in a segment). The ASes in an AS_SET segment are sorted in 1650 numerically increasing order. Note that all AS numbers in the 1651 ExplicitPA part are four-octet quantities. 1653 Since IPv4 address prefixes may be carried in either the NLRI part 1654 of an UPDATE message or in the MP_REACH_NLRI path attribute, and 1655 can in fact be converted from one representation to the other as 1656 an UPDATE message is propagated through successive ASes, 1657 canonicalization is used to make the protected prefix information 1658 invariant between the two encodings (see 3.1.1, part e). 1660 The prefixes in the NLRI and MP_REACH_NLRI path attribute are 1661 sorted for canonicalization. Canonicalization of an implicit NLRI 1662 requires that a path attribute header of Type Code 0 be generated 1663 for the NLRI, as well as an AFI and a SAFI, so that the NLRI is 1664 represented in the same format as if it had been in an 1665 MP_REACH_NLRI path attribute (section 3.1.1, part e). An 1666 MP_REACH_NLRI path attribute is canonicalized by changing the 1667 Flags to mandatory transitive and the Type Code to 0, so that the 1668 prefixes in an MP_REACH_NLRI path attribute may be compared 1669 against a canonicalized NLRI. 1671 Propagation of Explicit Data to the Next RA 1673 Special handling is required when propagating explicit prefix and 1674 AS PATH information from one RA to the next one in an RA sequence. 1676 The AS number corresponding to the Previous RA MUST be one of the 1677 AS(es) in the target of the Current RA. 1679 The AS PATH for the Current RA is computed by removing the Last AS 1680 number (possibly repeated due to prepending). The AS number 1681 removed MUST belong to the AS that authorized the signer of the 1682 Previous RA. 1684 Aggregations require that the AS_SET be disassembled and the AS 1685 PATH for each sub-sequence of RAs be determined. The AS PATH path 1686 attribute for the Last RA in each sub-sequence MUST be explicit in 1687 the ExplicitPAs field, so this disassembly is straightforward. 1688 Validation requires that each AS number in the AS_SET be 1689 represented in one or more of the sub-sequence AS PATHs. 1690 Otherwise, verification fails. 1692 Validation of Signed RA Parts 1694 The Expiry part contains an expiration date. If the verification 1695 occurs at a time after the expiration date, validation fails 1696 (subject to local policy). 1698 The Target part of an RA describes the AS number(s) to which the 1699 route was advertised. Validation MUST ensure that for each RA 1700 (except the first RA in an RA sequence or an aggregated RA sub- 1701 sequence, i.e., RAs for which there is no Next RA), the AS number 1702 of the signer is one of the AS numbers in the Target part of the 1703 Next RA. 1705 Special validation of the Last RA in a sequence must be performed 1706 when this Last RA has any explicit data. Since explicit data in 1707 the Last RA should match the equivalent implicit data found in the 1708 UPDATE's path attributes and NLRI, validation MUST ensure that the 1709 path attributes and NLRI in the UPDATE are the same as the 1710 explicit data in the Last RA. 1712 Explicit data for a Path attribute that does not need to be 1713 canonicalized should be byte-compared against the corresponding 1714 path attribute. The AS PATH path attribute in the UPDATE and the 1715 NLRI or MP_REACH_NLRI path attribute is canonicalized and then 1716 byte-compared against the AS PATH and NLRI in the ExplicitPA data, 1717 if present. If any path attribute in the UPDATE does not match 1718 the corresponding path attribute in the ExplicitPAs field of the 1719 Last RA, validation fails. Policy may dictate that in the case of 1720 failure the signed, explicit version of the path attribute be 1721 used, if the signature verification succeeds. 1723 These steps of verification may be carried out before or while 1724 finding and canonicalizing implicit data. The ExplicitPA part of 1725 an RA is validated through the following validation steps and 1726 signature verification. 1728 Validation of Prefixes 1730 Prefixes found in the NLRI or MP_REACH_NLRI path attribute MUST be 1731 validated against Address Attestation information. The AAs 1732 specify the ASes authorized to originate a route for a prefix and 1733 the maximum length of a prefix. Throughout this section "NLRI" 1734 refers to a canonicalized NLRI. 1736 The AS which originated a prefix is determined from the RA 1737 sequence. If no aggregation has occurred, the First RA in the 1738 sequence will contain one AS number. This AS number is used to 1739 validate all the prefixes in the NLRI. If aggregation has 1740 occurred, the First RA of each RA sub-sequence will provide the 1741 originating AS number and the set of prefixes that it originated. 1743 If not all prefixes in the NLRI were advertised by at least one of 1744 the originating AS numbers, validation (for those prefixes) fails; 1745 this is an auditable event. Policy may allow use of all prefixes 1746 except those failing AA validation. For each prefix in the NLRI, 1747 an AA must be present which lists the originating AS number in its 1748 Target, and the prefix length must not exceed the length specified 1749 by MaxPrefixLen. Otherwise, validation fails; failure is an 1750 auditable event. Again, policy may allow use of the sub-set of 1751 prefixes for which AA validation is successful. 1753 Signature Verification 1755 The signature of an RA MUST be verified. Verification of the 1756 signature requires that each protected path attribute be placed 1757 into the ExplicitPA part. If any path attributes were implicit, a 1758 new ExplicitPA part must be temporarily constructed for this 1759 purpose. Note that this construction is logical and does not 1760 specify how it is affected by an implementation. The length field 1761 of the ExplicitPA part must be set to include all the (temporarily 1762 constructed) explicit data. The path attributes MUST be sorted in 1763 the ExplicitPAs field by the path attribute Type Code, in 1764 increasing numerical order. Note that the canonicalized NLRI will 1765 be first, with Type Code 0. If no implicit data is used, sorting 1766 should not necessary because an S-BGP speaker MUST sort them when 1767 it generated the RA it advertised. The signature is verified over 1768 the Expiry part, the constructed ExplicitPA part, and the Target 1769 part. They are hashed as a logically contiguous block. The 1770 public key used for verification is determined from the name in 1771 the Signer part of the RA and the KeyId field in the Signature 1772 part. If signature verification fails, possibly because the 1773 required key is not in the public key database, validation of the 1774 RA fails; this is an auditable event. Failure because the 1775 required key is missing from the database MAY be an indication to 1776 the NOC to look for new public keys. 1778 3.2.1.2. Route Attestation Creation 1780 This section describes the steps necessary to create a Route 1781 Attestation. The NLRI which will be advertised with the route must 1782 be available so that it can be signed. If aggregation has been 1783 performed, the RA sequences for each aggregated route must be 1784 available and the ExplicitPA part of the Last RA in each RA sub 1785 sequence MUST have all data explicit. When route aggregation is not 1786 being performed only the RA sequence received for the route being 1787 advertised is needed. 1789 Implementation Note: 1790 Several parts and fields of an RA created by a given S-BGP speaker 1791 change slowly. These include the Signer part, the expiration date 1792 fields of the Expiry part, and the SignatureAlgorithmID and KeyId 1793 fields of the Signature part. An S-BGP speaker MAY choose to 1794 initialize these values at the initialization of the BGP process, 1795 and then update them as needed. 1797 The most involved step of creating an RA is determining the 1798 CoverageMask and building the ExplicitPA part. The signature part 1799 cannot be completed until this has been done. After the discussion 1800 of the construction of the parts of the new RA, details of how the 1801 ExplicitPA parts of the Next (or subsequent) RA(s) in each RA 1802 sequence may be altered to reduce the size of the attestation 1803 attribute are provided. 1805 Attestation Object Type 1806 The Part Code in the Attestation Object Type field is set to 8 1807 (RA). The value of the AttestationLength field cannot be 1808 determined until the ExplicitPA part has been (logically) 1809 constructed with the explicit form of the protected transitive 1810 information. 1812 Signer part 1814 The signer of an RA is an S-BGP speaker. It is identified either 1815 by the speaker's BGP Identifier (when the speaker signs using its 1816 own DSA key), or by the number of the AS that authorized the 1817 speaker to act as its agent (when a single DSA key is used by 1818 multiple speakers). A BGP Identifier is encoded using the IPv4 1819 name form; an AS number is encoded using the four-octet AS number 1820 name form. 1822 Note: One reason to have a single key pair used by multiple 1823 speakers is to allow the rapid deployment of new S-BGP 1824 speakers in an AS (the key can be distributed through the 1825 S-BGP Repositories and be globally available before a new 1826 router is deployed). One reason to use per-speaker keys is 1827 to reduce the impact of a key compromise. One can install a 1828 new router and have it use a shared key, then switch to a 1829 per-speaker key after enough time has elapsed for it to be 1830 propagated through the S-BGP repositories to all AS's S-BGP 1831 speakers. 1833 Signature part 1835 The SignatureAlgorithmID and KeyId are determined by the 1836 Certificate as well. The SignatureLength field and CoverageLen 1837 field of the Signature part are computed after the coverage mask 1838 has been determined. 1840 The coverage mask is computed using information about which path 1841 attributes are being placed in the UPDATE message, which path 1842 attributes were protected by the RA sequence(s) from the route(s) 1843 being covered, and policy. Only the path attributes which S-BGP 1844 may protect (see section 3.1.1, part c) and which are present in 1845 the UPDATE may have the corresponding bit in the coverage mask set 1846 to 1. Unknown path attributes may also be covered if the path 1847 attribute was protected by the Last RA in the received RA 1848 sequence. Local policy may specify particular path attributes 1849 that are not protected (including unknown attributes) when 1850 originating an UPDATE; the corresponding bits for these should be 1851 set to 0 in the coverage mask; see, e.g., send-explicit in 1852 Appendix C.5.5. Policy may specify not protecting a path 1853 attribute unless it was protected in a received RA. 1855 Once the bits of the coverage mask have been specified, the length 1856 of the coverage mask, in octets, and the length of the Signature 1857 part are known, and the Signature part (less the signature itself) 1858 is complete. 1860 Expiry part 1862 The Len field of the Expiry part has the value 6 for an RA. The 1863 expiration date is set per local policy. Operational experience 1864 will provide guidance in selecting a good value, e.g., N days in 1865 the future. The smaller the value, the more frequently an 1866 advertisement will be required to simply extend the validity 1867 period. 1869 The RASC field should be computed as one more than the sum of the 1870 RASC fields of the set of RA sequences which will be placed before 1871 the new RA in the attestation attribute, as described in section 1872 3.1.2. If aggregation has been performed by this speaker, the 1873 A-bit is set to 1, else it is set to 0. 1875 ExplicitPA part 1877 For each path attribute marked as protected by the coverage mask, 1878 a (logical) copy of the path attribute is placed in the ExplicitPA 1879 part so that the correct signature can be computed. 1881 The explicit path attribute data MUST be in the canonical form so 1882 that it can be verified by another S-BGP speaker, including 1883 comparison against canonicalized implicit path attributes. This 1884 means that the NLRI/MP_REACH_NLRI are canonicalized to a path 1885 attribute with Type Code of 0 and that the prefixes MUST be sorted 1886 in ascending order by prefix/prefix length (not the prefix 1887 length/prefix encoding used for prefixes) (see section 3.2.1.2). 1888 All protected path attributes are hashed as part of the 1889 ExplicitPAs field. S-BGP speakers MUST sort the path attributes 1890 by Type Code in ascending numerical order in the ExplicitPAs 1891 field. Once the explicit path attributes are identified, the 1892 Length field of the ExplicitPA part may be set. Generally, the 1893 explicit data will subsequently be removed (made implicit) after 1894 signature generation to reduce the size of UPDATEs sent to peers; 1895 see, e.g., C.5.5,6. 1897 Target part 1899 The Target field is computed from the AS number(s) of the peer(s) 1900 to which the route is being advertised (or of the next forwarding 1901 hop peers in the case of external route reflection). See, e.g., 1902 sign-AS in C.3.1. 1904 Implementation Note: 1905 When the target contains a single AS number and the UPDATE will 1906 be sent to peers in multiple ASes, it can be more efficient to 1907 create the Expiry and ExplicitPA parts of the RA first, as 1908 described here. This way, a common hash may be computed that 1909 excludes the Target, and final individual hashes may then be 1910 computed for each RA from the common hash and the Target part 1911 for each RA. 1913 Signature 1915 After all parts of the RA are constructed, the signature can be 1916 computed. It covers the Expiry, ExplicitPA, and Target parts, 1917 which are hashed as one contiguous block. The hash is signed, 1918 using the key specified by the Signer part and the KeyId field of 1919 the Signature part. The resulting signature is copied into the 1920 Signature field of the Signature part. 1922 Explicit and Implicit Data in Received RAs 1924 After the new RA has been constructed, the new RA is prepended to 1925 the received RA sequence to produce the RA sequence which is 1926 placed in the attestation attribute. If the local speaker has 1927 performed aggregation, the received RA sequences for each 1928 aggregated route (in which the Last RAs have Explicit Data for at 1929 least the NLRI and AS PATH) are concatenated into one sequence as 1930 described in section 3.1.2 before the locally generated RA is 1931 prepended. 1933 Further processing of these received sequences SHOULD be done, 1934 however. Since most path attributes can be implicitly derived from 1935 the previous RA in a sequence (section 3.2.1.1), UPDATE message sizes 1936 can be reduced if explicit path attributes listed in the received 1937 sequences' RAs can be removed. Explicit data can be removed from the 1938 Last RA when the data can be deduced from the explicit data in the 1939 newly generated RA. The processing done here will speak only of the 1940 Last RA in each received RA sequence, assuming that other ASes also 1941 have converted explicit data to implicit whenever possible before 1942 prepending their locally generated RA. It is possible that this is 1943 not the case; a speaker may recursively apply the processing here to 1944 all RAs in an RA sequence; see, e.g., C.5.5,6 and C.6.4. 1946 If the S-BGP speaker creating the new RA did not perform aggregation, 1947 there is only one received RA sequence. The speaker may compare each 1948 explicit path attribute in the Last RA of this sequence against the 1949 explicit path attributes in the new RA. If a given path attribute is 1950 identical, including the path attribute Flags, then this path 1951 attribute MAY be removed from the ExplicitPAs field of the Last RA. 1953 The ExplicitPA's Length field in the Last RA must be altered to 1954 reflect the removal. 1956 Implementation Note: 1957 More efficient comparison of transitive path attributes in an 1958 UPDATE to the corresponding ones of the Last received RA maybe 1959 achieved, at the cost of more memory, by making all covered path 1960 attributes in the Last RA explicit, or at least being able to 1961 locate the canonicalized path attributes that were received -- the 1962 path attributes MUST be saved per the BGP specification. 1964 If any path attributes other than those with predictable changes, 1965 e.g., the AS PATH, differ, then the data must be left explicit in the 1966 Last received RA. Any unknown protected path attributes will be 1967 retained as explicit data as the speaker will set the Partial bit in 1968 the unknown path attribute Flags, thus creating a difference between 1969 the new RA and the Last received RA. If the new RA does not protect 1970 a path attribute covered by the Last RA, this path attribute must be 1971 left in the ExplicitPA of the Last RA. 1973 The AS PATH as computed for the explicit data of the new RA will 1974 differ from the Last received RA. However, when it is possible to 1975 compute the correct AS PATH attribute for the Last RA (by simply 1976 removing the Last AS number from the AS PATH sequence) (section 1977 3.2.1.1), the explicit AS PATH entry MAY be removed from the 1978 ExplicitPAs field of the Last received RA. 1980 If the S-BGP speaker creating the new RA has performed aggregation, 1981 the same process may be followed for the Last RA of each received RA 1982 sequence in the aggregate. However the AS PATH attribute and the 1983 canonicalized NLRI MUST appear in the ExplicitPA of the Last RA of 1984 each RA sub-sequence, because aggregation removes the information 1985 necessary to reconstruct that information from the AS PATH and NLRI 1986 in the new RA. 1988 3.2.2. BGP Processing Phases 1990 The S-BGP Decision Process differs from the specifications of BGP-4 1991 [RFCbgp], and route servers [RFC1863] in the following ways. 1993 3.2.2.1. Phase 1 Processing 1995 The degree of preference for each route received from an external 1996 peer calculated during Phase 1 MAY take into consideration the 1997 results of the verification of received RAs, and/or the presence of 1998 AA information for each advertised prefix. 2000 The attestation path attribute MUST be passed to all internal peers 2001 that are sent an advertisement. 2003 3.2.2.2. Phase 2 Processing 2005 In general, the Phase 2 installation of the best route for each 2006 distinct prefix in the appropriate Loc-RIB is unchanged. However, an 2007 implementation that performs either asynchronous or on-demand 2008 verification of attestations (or their signatures) MAY modify this 2009 step to initiate and/or await the results of the attestation 2010 verification step. 2012 3.2.2.3. Phase 3 Processing 2014 A new step is added to Phase 3. Before disseminating routes in the 2015 Loc-RIB to each external peer, the speaker SHOULD include a signed RA 2016 that contains the protected transitive information. As an aid to 2017 incremental deployment, a speaker MUST support a per-peer 2018 configuration capability to not send an Attestation Path Attribute to 2019 a peer; see, e.g., send-RA in C.2.3. 2021 Implementation Note: 2022 An implementation MAY cache the RAs so created to reduce time 2023 required to create and sign an RA for use with subsequent 2024 advertisements of the same route to the same peer; see, e.g., 2025 out-cache-depth, C.4.7. 2027 Protected data is made explicit in a prepended RA and whenever it 2028 either differs from the NLRI/MP_REACH_NLRI or protected transitive 2029 path attributes, or the data cannot be derived from explicit data in 2030 a previous RA. The AS PATH MUST be included in the CoverageMask 2031 filed. 2033 When prepending the created or cached RA to the (possibly empty) set 2034 of RAs in the received attestation attribute, any protected path 2035 attributes that are either identical or predictable to the value in 2036 the ExplicitPA part of the Last received RA SHOULD be made implicit 2037 (by removing it from the peer RA's ExplicitPAs field and adjusting 2038 the ExplicitPA part's Length field accordingly), thus reducing the 2039 size of the attestations; see, e.g., c.5.5,6. They MAY also be 2040 removed from all subsequent RAs, up to, but not including, the point 2041 where the values differ. 2043 The only predictable change in path attributes at the current time is 2044 for the AS PATH attribute, where a predictable change is defined to 2045 be the simple addition of the Last AS numbers to the last AS_SEQUENCE 2046 in the AS path. 2048 Use of S-BGP within Confederations [RFC1965], while straight forward 2049 since all members of a Confederation are presumed to be part of the 2050 same management domain, are outside the scope of this specification. 2052 3.2.3. S-BGP Processing 2054 The use of S-BGP and the attestation attribute affects processing and 2055 sending of UPDATEs as well as the routing policy and decision 2056 functions, including choice of routes to use and advertise. An 2057 example of additions to local policies appears in Appendix C. The 2058 processing specific to the attestation attribute and the changes 2059 necessary to the three BGP decision phases are described in sections 2060 3.1.1 and 3.1.2; they are referred to in this section, which presents 2061 an overview of all changes necessary to support S-BGP. 2063 3.2.3.1. Receive Processing 2065 After an UPDATE has been received by an S-BGP speaker, it must 2066 perform all of the usual BGP processing, with the addition of S-BGP 2067 processing in certain places. 2069 The first S-BGP change is in the addition of more syntax and 2070 consistency checking of an UPDATE message. The attestation attribute 2071 must be syntactically correct. The lengths of the attestations must 2072 add up to the length of the attestation path attribute. The lengths 2073 of the parts of each attestation must add up to the length of the 2074 attestation. There must be exactly as many remaining RAs in the RA 2075 sequence as claimed by the RASC field of the each RA, any RA sub- 2076 sequences from aggregation must have the correct number of RAs as 2077 specified in the RASC of the RA sub-sequence's Last RA, and the 2078 lengths of these RA sub-sequences must be equal to one less than the 2079 number in the RASC of the aggregator's RA. 2081 After syntax checking, the speaker must ensure that any necessary 2082 implicit data from the UPDATE is available. Validation need not 2083 occur at this stage (including steps to ensure that implicit and 2084 explicit data is the same), but the implicit data must be available 2085 at the time of validation. It is sufficient that the RAs are stored 2086 in such a way that the storage of the other path attributes from the 2087 same UPDATE is available at the time of validation. 2089 Note that RAs received from internal peers MAY be configured to not 2090 have their signatures verified as that happens when an advertisement 2091 is received from an external peer. 2093 Likewise, RA validation (section 3.2.1.1) may occur at another time. 2094 It is also not necessary to perform all steps of validation at once. 2095 After syntax checking and preservation of potentially implicit path 2096 attributes, the S-BGP speaker may return to the usual UPDATE 2097 processing. Or, it may do all validation except for signature 2098 verification, as the latter requires far more computation, at least 2099 when performed in software. Full validation could be undertaken 2100 here, especially if the signature verification can be moved to 2101 another processor (section 4), but this may be less efficient when a 2102 flood of UPDATEs is received. 2104 Because of the time it takes to verify a signature in software, it 2105 may be more efficient to delay signature validation when a received 2106 route is not selected as the best route to one of the prefixes, i.e., 2107 in cases where there is a already a more preferred route. The 2108 reduction in signature verification operations can be significant, 2109 especially when a speaker has a large number of external peers. 2110 However, when the S-BGP information becomes relevant for route 2111 selection, the RAs must be validated. This may be when the route is 2112 selected as the best route to some prefix; validation must then occur 2113 before the route may be used (placed into the Loc-RIB) or 2114 subsequently advertised (placed into an Adj-RIB-Out). RA validation 2115 can also be scheduled during idle time, so that if a route validated 2116 this way is later selected as the best route, the validation may 2117 already have been completed. See, e.g., verify-RA in C.4.1. 2119 Policy may choose to use a route because it is the only route 2120 available for a certain prefix; in this case the RAs would not need 2121 to be validated; see, e.g., only-route in C.5.1,2,3 and C.1. When 2122 another route arrives for that prefix, and local policy would use 2123 information carried in the RAs to selecting a route, both routes must 2124 then be validated. Or alternately, if the best route is chosen 2125 without using RA information, only validation of the best route would 2126 be necessary (unless validation fails, causing another route to be 2127 selected). 2129 Note that no S-BGP changes are necessary to validate route 2130 withdrawals. Since withdrawals cause the route to be removed from 2131 the Adj-RIB-In, either the S-BGP speaker has already removed the 2132 route because its validation failed (or the route was never 2133 advertised), so the withdrawal has no effect, or validation has 2134 succeeded, so the peer withdrawing the route has previously 2135 advertised the route, and the withdrawal is authorized. 2137 Caching of more than the most recently received route for a prefix 2138 can reduce processing computational overhead due to S-BGP, at the 2139 cost of more memory. The BGP specification requires retention of the 2140 most recent UPDATE per peer per prefix in the Adj-RIB-In. Additional 2141 caching, discussed in section 4, would occur at this point in 2142 processing. 2144 The next part of UPDATE processing affected by S-BGP is the decision 2145 function (see section 3.2.2). 2147 3.2.3.2. Send Processing 2149 An important aspect of the decision function which needs special 2150 attention for S-BGP is aggregation. Local policy describing when 2151 aggregation should be performed must take into account the fact that 2152 the UPDATE message size can increase quite dramatically when S-BGP 2153 protected routes are aggregated, as the attestation attribute for the 2154 aggregated route must include all RAs from each contributing route, 2155 and the full AS PATH and NLRI/MP_REACH_NLRI must be present in the 2156 ExplicitPA part of the Last RA for each received RA sequence. A 2157 configuration parameter for the maximum aggregated attestation 2158 attribute size must be introduced and taken into consideration when 2159 applying aggregation policies. Otherwise, an aggregation may force 2160 the UPDATE size past the maximum of 4096 octets. 2162 Three situations may arise after a route has been selected use and is 2163 to be advertised. The route may be advertised to a peer in the same 2164 AS. The route may have been received from an external peer, and an 2165 RA must be created and signed by the speaker. Or the speaker's AS 2166 may be originating a route. 2168 The first situation does not require the creation of an RA, since an 2169 RA is not prepended to the RA sequence when a route is forwarded to 2170 peers in the same AS (confederations are different ASes). 2172 The second situation imposes some requirements on the code which 2173 produces an UPDATE message to advertise an UPDATE. As the path 2174 attributes are being placed into the UPDATE, the attestation 2175 attribute must be created. This requires building a new RA sequence 2176 if aggregation has occurred. A new RA is then prepending to the RA 2177 sequence. In order to create the new RA, all other path attributes 2178 and the NLRI must be available, as well as the AS number of the 2179 peer(s) to which the UPDATE will be sent. If the speaker performed 2180 aggregation to create the route, the RA sequences from all routes 2181 which were aggregated must be available. The AS PATH attribute and 2182 the NLRI/MP_REACH_NLRI attribute must be present in the form which 2183 they will take in the UPDATE message. If the route is to be 2184 forwarded to more than one AS, it is more efficient though not 2185 required, to have the full list of ASes available as well. Then the 2186 new RA can be created, as described in section 3.2.1.2. Note that a 2187 BGP implementation may require some change to the method of building 2188 UPDATE messages to allow all protectable path attributes and the NLRI 2189 to be available while creating the attestation attribute; support for 2190 the Multiprotocol Reachable path attribute requires similar changes. 2192 The creation of an RA requires a signature to be computed. If the 2193 signature is computed asynchronously (e.g., another processor is 2194 devoted to cryptographic operations), the UPDATE message may not be 2195 available to be sent immediately after the path attributes and NLRI 2196 are written to the message. Thus it may be necessary for some BGP 2197 implementations to be changed to allow for queueing of completely 2198 formated UPDATE messages until after the signature has been computed 2199 and inserted into the Last RA. 2201 After the signature is computed, a speaker may wish to cache this new 2202 RA, so that if it needs to be advertised again, the signature does 2203 not need to be recomputed. Caching is discussed in section 4. Note 2204 that it is important that if two UPDATE messages are to be sent to 2205 the same peer, and the first requires a signature computation but the 2206 second is found in the send cache (so no signature is needed) or only 2207 withdraws routes, the second UPDATE message MUST be queued until the 2208 first has been sent so that the order of UPDATE messages is 2209 preserved. 2211 The third situation for advertising a route occurs when an S-BGP 2212 speaker originates a route. Care must be taken that the NLRI is not 2213 allowed to grow too large. A configuration parameter is necessary to 2214 limit the size of the NLRI such that enough space is left in the 2215 4096-octet BGP message to allow inclusion of the longest expected RA 2216 sequence for that route; see, e.g., max-origin in C.4.3. This 2217 configuration should account for the radius of the Internet in ASes 2218 from the point of view of the originating AS. It may be necessary to 2219 send multiple UPDATE messages with smaller NLRI where one would have 2220 been sufficient were S-BGP not being used. The NLRI must be 2221 restricted in size at the originating speaker because an UPDATE 2222 message cannot be split to reduce the UPDATE message size when it is 2223 protected by an RA. Splitting the NLRI actually increases the UPDATE 2224 size as the old, large NLRI must be made explicit in the Last 2225 received RA, when it could have been implicit if the NLRI had not 2226 been changed. Once the NLRI for a given UPDATE message has been 2227 determined, the UPDATE can be built as usual for an S-BGP speaker. 2228 The only difference at this point from the second situation above is 2229 that the attestation attribute is new. The creation of the RA 2230 requires the same information as is needed for the second situation 2231 above. Similarly, the signature computation may be delayed, and a 2232 send cache of RAs for originated routes may be created. 2234 3.2.3.3. Background Processing 2236 Some processing of local S-BGP information may occur as a background 2237 process. 2239 Since RAs, public keys, and AA information eventually expire, 2240 attention must be paid to keep routing information current. The NOC 2241 may upload new public keys, AA information, or policy to an S-BGP 2242 speaker. 2244 Locally stored public keys and AA information that have expired 2245 should be removed. Any routes that were validated using expired 2246 information are no longer valid; they should be either re-validated, 2247 as newer public keys or AA information becomes available, or the 2248 Phase 2 decision process should be run to select alternate routes. 2249 This might result in sending withdrawals and advertising a new, 2250 validated route. Local policy may allow expired routes to remain, 2251 e.g., in general, in cases where no other route is available, or when 2252 all other routes have failed validation. 2254 RAs which have expired must also be handled. This includes removing 2255 routes which were validated by the expired RAs, as they are no longer 2256 valid, and finding a new best route. Expired RAs must also be 2257 removed from any RA caches (section 4). Both RAs received in UPDATEs 2258 and RAs created and signed by the speaker may be cached. RAs created 2259 by the speaker could either be removed from the send cache, so that 2260 they are re-computed when the route is next advertised, or they may 2261 be left and simply re-signed (after updating the Expiry part) if the 2262 public key for the speaker is still valid. In either case, if the 2263 expired RA was created for a route originated by the speaker, the 2264 route must be advertised again, with a new RA. If a soon to expired 2265 RA was prepended to an RA sequence by a speaker and the route is 2266 still in the Loc-RIB and none of the received RAs have expired, that 2267 route should be re-advertised with a newly signed RA. Efficiency 2268 would suggest that a re-advertisement be delayed if one of the other 2269 RAs will expire before the locally generated RAs. 2271 Depending on the implementation of S-BGP, especially of the receive 2272 and send RA caches if they are used, there may be a need for other 2273 periodic clean up. For example, a receive RA cache for a given peer 2274 might not be deleted immediately when the session is terminated, so 2275 that if the session is re-established the RAs received would not need 2276 to be re-verified; see, e.g., [BGPRES]. However, if the session is 2277 not re-established within a reasonable interval, the cached routes 2278 might be removed. Depending on the implementation, this may require 2279 a periodic processing of the cache. 2281 Finally, idle time may be used to verify RAs in the, e.g., second 2282 best routes, which have not yet been verified. Since it might be 2283 advertised in the future, if RAs are verified during idle time, the 2284 verification computation might be completed before selection as the 2285 best route. (Delayed verification of RAs is discussed in section 2286 3.2.3.1.) 2288 3.2.3.4. Unknown Path Attributes and Canonicalization 2290 An S-BGP speaker can handle unknown protected path attributes 2291 provided that they do not need canonicalization during the 2292 verification of an RA. During verification, an implicit path 2293 attribute which does not need to be canonicalized may be byte- 2294 compared against the explicit path attribute found in the RA's 2295 ExplicitPA part (section 3.2.1.1). Thus validation can succeed 2296 despite the fact that the path attribute is unknown. When an RA 2297 protecting an unknown path attribute is forwarded as part of an 2298 advertised route, the unknown path attribute must be placed in the 2299 Last RA's explicit data as well as in the new RA's explicit data, 2300 since the speaker for which the path attribute is unknown sets the 2301 Partial bit in the Path Attribute Flags. This causes the path 2302 attribute to change, requiring it to be placed in the explicit data 2303 of the Last RA of the received RA sequence, as usual (section 2304 3.2.1.2). If local policy stipulates removal of the unknown path 2305 attribute, it will still be placed in the explicit data of the Last 2306 RA, and the corresponding bit will not be set to 1 in the new RA's 2307 CoverageMask field. 2309 Currently only the AS PATH and NLRI/MP_REACH_NLRI path attributes 2310 need be canonicalized for verification (section 3.2.1.1). However, 2311 if an unknown path attribute is defined in the future such that the 2312 implicit form of the path attribute from the UPDATE must be 2313 canonicalized before it may be compared against the path attribute in 2314 the explicit data of the Last RA, S-BGP cannot properly validate the 2315 unknown path attribute. The signature verification may be carried 2316 out properly, but the implicit and explicit forms of the path 2317 attribute will not match. Also, any RAs subsequent to the Last RA 2318 which carry the unknown path attribute in an implicit form cannot be 2319 validated. 2321 It is not sufficient to simply allow validation to fail. Policy may 2322 allow subsequent RAs to be considered validated by the Last RA. 2323 Since the S-BGP speaker does not know how to handle the unknown path 2324 attribute, the fact that the implicit and explicit data do or do not 2325 match does not indicate whether the data is valid. If the implicit 2326 and explicit data do not match, it cannot be determined that this is 2327 because canonicalization is necessary or because the implicit data 2328 has been changed. If they do match, it cannot be determined that 2329 canonicalization would have produced non-matching data, such that 2330 validation should fail. 2332 It may be safe to assume that if the implicit and explicit data do 2333 match and the signature verification succeeds that validation has 2334 succeeded, but only if it can be determined when a path attribute 2335 requires canonicalization. A method for dealing with the issue of 2336 future path attributes which should be protected by S-BGP and which 2337 also need canonicalization has not been determined. Two simple 2338 possibilities include disallowing new attributes from having 2339 canonicalization rules, which could cause every RA in a sequence to 2340 store this path attribute in the ExplicitPA, or disallowing S-BGP 2341 protection of new path attributes which need canonicalization until 2342 all S-BGP speakers can handle the new path attribute. This issue 2343 needs further study. Specifications for new path attributes SHOULD 2344 specify whether or not they require canonicalization, and if so how 2345 the canonicalization is performed. 2347 3.2.4. Interoperation with Non-S-BGP Speakers 2349 The design of S-BGP allows gradual deployment of S-BGP capability 2350 throughout an internet. The expected deployment scenario is for 2351 initial deployment by large, well interconnected, ASes. They have 2352 more customers that would benefit from S-BGP assurances. Over time 2353 more ASes would support S-BGP. Another scenario is for a group of 2354 users to decide to deploy S-BGP to protect their routing 2355 infrastructure. 2357 As S-BGP is incrementally deployed it would be possible for an UPDATE 2358 message to traverse both ASes that do and ASes that do not recognize 2359 and/or process the attestation path attribute. While rules and 2360 algorithms can be specified that permit some security benefits to be 2361 realized when an S-BGP protected UPDATE traverses non-S-BGP ASes, 2362 those algorithms, and their related policy controls, are sufficiently 2363 complex relative to the additional security realized that this 2364 specification does NOT RECOMMENDED that they be implemented. 2366 In the expected deployment scenario, having S-BGP protected UPDATEs 2367 pass between ASes that are using S-BGP ONLY via an AS(es) not using 2368 S-BGP would be the exception, rather than the common case. Thus 2369 there would be little to be gained from the added complexity. 2371 In addition, this specification RECOMMENDs that an AS that supports 2372 S-BGP processing only add RAs for the prefixes that the AS 2373 originates, or which were received from a peer that prepended an RA 2374 to the attestation path attribute. This has two advantages. First, 2375 the volume of routes that carry the attestation path attribute would 2376 be significantly less that the total number of routes in the 2377 Internet; this translates to significantly reduced memory 2378 requirements. Reduced memory requirements may enable more ISPs to 2379 use S-BGP without having to add more memory to their S-BGP speakers. 2380 Second, if a route is protected by S-BGP, then one has assurances 2381 that the route is authorized all the way to destination network. 2383 Since the binding between origin AS and network prefix by address 2384 attestations is both authoritative and completely out-of-band, a 2385 speaker that has S-BGP capability can perform origin verification 2386 without having to perform any attestation path attribute processing. 2388 4. Processing Optimizations 2390 There are several processing options that can be used to improve the 2391 efficiency of an S-BGP implementation. Some choices, such as the 2392 addition of cryptographic hardware or the use of RA caches, might 2393 depend on the placement of the router, e.g., is it used at a NAP or 2394 at a customer site. 2396 Use of Implicit Data 2398 Protected data should be implicit in all prepended RAs unless it 2399 either differs from the NLRI/MP_REACH_NLRI or protected transitive 2400 path attributes, or the data cannot be derived from explicit data 2401 in a previous RA. When the data in an RA that is being prepended 2402 to an attestation is the same as the data in the Last RA that was 2403 received from a peer AS, it SHOULD be made implicit (by removing 2404 it from the Last received RA), thus reducing the size of the 2405 attestations. 2407 Cryptographic Operations on Another Processor 2409 The time required to perform cryptographic operations is quite 2410 substantial compared to the time required to do other processing 2411 of UPDATE messages. As such, a performance improvement *might* be 2412 realized by moving the signing and verifying operations to another 2413 processor instead of doing them in software. This could be 2414 specialized hardware attached to the router, via either an 2415 external interface or a PCMCIA card, or it could be a general- 2416 purpose computer, such as a PC on a router blade, to which the 2417 router may pass crypto requests. Adding any such processing will 2418 cause the cryptographic operations to be performed asynchronously, 2419 so special attention must be paid to handling and synchronization 2420 issues. Note that performing the SHA-1 hash in hardware might not 2421 be faster than doing the hashing in software, as marshalling and 2422 passing the data to be hashed to a crypto processor takes both 2423 additional space, time, and scheduling overhead. 2425 It has been observed that the advertised performance of some 2426 vendor's cryptographic accelerators may not be achievable due to 2427 the large number of public keys (10s of thousands when S-BGP is 2428 fully deployed) that are needed to verify the RA signatures. The 2429 performance loss was due to the limited memory available for 2430 public keys combined with the need for sequential transactions to 2431 unload a public key (to make room for another), load the needed 2432 key and obtain the key id assigned by the accelerator, and to then 2433 pass that key id, the hash, and signature data to the accelerator 2434 for verification. A "key agile" accelerator design that is 2435 capable of accepting the public key, hash, and signature data in a 2436 single transaction could avoid this problem. 2438 Use of a hardware cryptographic processor that protects the 2439 private key(s) used to sign the hashed information provides better 2440 security than techniques that hold the private key(s) in router 2441 memory. 2443 An external processor may also allow parallel execution of 2444 signing/verifying; since multiple RAs may be signed (for 2445 advertising to multiple peers) or verified (multiple RAs are 2446 received in an attestation attribute), this may produce a 2447 noticeable performance improvement. 2449 Performing signature verification in software and signature 2450 generation on a token might be advantageous (especially if the 2451 token is not public key agile). 2453 RA Caching 2455 Retention of a peer's Adj-RIB-In after a peering session has been 2456 terminated can speed the reestablishment of a subsequent peering 2457 session. BGPs that implement [BGPRES] will automatically gain 2458 this benefit. 2460 Another possible optimization involves caching RAs, both those 2461 received from other peers, and those created by the speaker and 2462 sent to other peers. Caching helps reduce the number of 2463 verifications and signatures necessary to handle route flaps. If 2464 a route is flapping and the received RAs for both have been 2465 verified once, a cache will allow the already-verified RAs to be 2466 used to validate the route each time it flaps, reducing processing 2467 overhead. Likewise, a flapping route being advertised by the peer 2468 requires sending multiple locally-generated RAs; in this case a 2469 cache of sent RAs can reduce the number of signatures to be 2470 computed. 2472 5. Auditing and Event Reporting 2474 Security relevant events SHOULD be recorded and/or reported to a 2475 management station. 2477 There SHOULD be a way to limit the rate at which events are reported 2478 to a NOC. It is RECOMMENDED that rate limiting be applied on a per- 2479 speaker basis. Per-event limits MAY be implemented. 2481 The audit information should include: the identity of the signer, if 2482 it can be determined; the identity of the authorizing AS, if it can 2483 be determined; the peer from which the message was received; and the 2484 type of error or problem detected. 2486 For a missing key, the key owner and key identifier should be 2487 reported. 2489 For a missing AA, the prefix and originating AS should be reported. 2491 6. Infrastructure Support 2493 Operation and deployment of S-BGP requires supporting infrastructure. 2494 S-BGP uses X.509 v3 certificates consistent with the PKIX 2495 specification [RFC3280] that include private extensions for the 2496 delegation of IP address blocks and AS numbers as well as the binding 2497 of a BGP Identifier to an AS. The extensions are defined in 2498 [X509EXT] and [X509S-BGP]. The Regional Internet Registries need the 2499 capability to securely obtain an organization's public key and a 2500 Certification Authority (CA) capability to generate subordinate CA 2501 certificates containing the extensions that are used to delegate the 2502 right to use IP address prefixes and AS numbers, and to make the 2503 signed certificates available to the organizations to whom the 2504 resources have been delegated. 2506 ISPs need CA capability to create end entity certificates with the 2507 appropriate extensions for their ASes, networks, S-BGP speakers, and 2508 operations personnel. They may also need the capability to issue 2509 subordinate CA certificates if they further delegate the right to use 2510 some of their address space to their multi-homed BGP customers (as 2511 opposed to loaning portions of their address space). 2513 The S-BGP architecture calls for the storage and distribution of all 2514 S-BGP related certificates, CRLs, and AAs in a distributed global 2515 repository with servers replicated at well-connected points 2516 throughout the Internet. Initial mechanisms for the communication of 2517 certificates, CRLs, and AAs to one of these repositories by 2518 certificate owners, CRL signers, and AA issuers have been developed, 2519 as has software for the repositories and for use by NOCs to manage 2520 their S-BGP assets. 2522 The management of an AS is responsible for posting their locally 2523 generated certificates, CRLs, and AAs to the repository and for 2524 periodically downloading the information in the repository for local 2525 processing and distribution to their S-BGP speakers. The HTTPS 2526 protocol is used for update (POST) and retrieval (GET) transactions 2527 with the repositories. 2529 The AS's management is responsible for certificate verification. The 2530 format of certificate extracts and the mechanisms for their 2531 communication to the S-BGP speakers within as AS are vendor specific. 2533 The extracted information should contain a representation of the 2534 following fields: Subject name, Subject Public Key Info (the DSA 2535 public key), Subject Key Identifier, the IP Address Block Certificate 2536 Extension, the Autonomous System Identifier Certificate Extension, 2537 and the Router Authorization Certificate Extension. 2539 7. Address Attestations 2541 The owners of IP address blocks, i.e., those organizations which have 2542 been issued a certificate containing an IP Address Block Certificate 2543 Extension, need to generate and sign an AA that authorizes one or 2544 more ASes to advertise those address blocks. The resulting AAs MUST 2545 be sent to one of the top-level repositories as described in the 2546 previous section. 2548 8. IANA Considerations 2550 IANA should assign BGP Type Code *IANA-TBD* to the attestation path 2551 attribute ("ATTEST"). Replace *IANA-TBD* with the number in section 2552 3. 2554 IANA assigned the eight bit value 2 to the DSAwithSAH1 on 31 Oct 2000 2555 and listed it in the Signature Algorithm Number table at 2556 http://www.isi.edu/in-notes/iana/assignments/sig-alg-numbers. That 2557 URL is no available on the IANA web page. Reference [IANA-SAN] 2558 should be updated with the correct URL. 2560 IANA should create a name space for the Attestation Part Codes, e.g., 2561 attest-numbers. Values defined in this specification are: 2563 0 Reserved 8 Route Attestation 2564 1 Signer Part 9 Address Attestation 2565 2 Signature Part 10 CRLs 2566 3 Expiry Part 11 Certificates 2567 4 ExplicitPA Part 12 2568 5 Target Part 13 2569 6 14 Extract file authenticator 2570 7 15 Reserved for escape mechanism 2572 Unassigned attestation Part Codes may be assign by IANA when 2573 presented with working group consensus. 2575 9. Security Considerations 2577 Security is central to the design of this protocol, and these 2578 security considerations permeate this specification. 2580 Security considerations related to public key technology are given in 2581 [RFC3280]. 2583 10. Acknowledgments 2585 Many individuals contributed to the design and development of S-BGP. 2586 As members of the architecture team, Stephen Kent, Martha Steenstrup, 2587 and Luis Sanchez provided critical input to the design of the 2588 attestation and PKI schemes, evaluation of other approaches, and 2589 analysis of performance and operational issues. Sean Kennedy and 2590 John Hawkinson provided invaluable insight into real world Internet 2591 engineering and operational issues. The authors would also like to 2592 thank Michelle Casagni for her help with the analysis and Dennis 2593 Rockwell and Nicholas Shectman for their help with the proof of 2594 concept implementation. Additional thanks to Rick Altmann, Kavita 2595 Baball, Ed Bubnis, Sue-fen Cuti, Shelby Evans, Mark Fausett, Pete 2596 Fischer, Pete Foley, Charlie Gardiner, Christine Jones, Joe Kraska, 2597 Bob Masters, JB Mitchell, Tony Stein, and Carmela Stuart for their 2598 work developing the supporting repository, NOC, and certification 2599 authority software that will be needed to support S-BGP 2600 operationally. 2602 This work was made possible by support from NSA and DARPA. 2604 11. References 2606 The following references are normative. 2608 [DSS] Federal Information Processing Standards Publication (FIPS 2609 PUB) 186-1, "Digital Signature Standard (DSS)", U.S. 2610 Department of Commerce / National Institute of Standards 2611 and Technology, December 1998. 2613 [IANA-AFI] http://www.iana.org/assignments/address-family-numbers. 2615 [IANA-SAFI]http://www.iana.org/assignments/safi-namespace. 2617 [IANA-SAN] http://www.iana.org/assignments/sig-alg-numbers. 2619 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 2620 3", RFC 2026, BCP 00009, October 1996. 2622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2623 Requirement Level", BCP 14, RFC 2119, March 1997. 2625 [RFCbgp] Rekhter, Y., Li, T., Hares, S., "A Border Gateway Protocol 2626 4 (BGP-4)", draft-ietf-idr-bgp4-20.txt 2628 [SHA-1] Federal Information Processing Standards Publication (FIPS 2629 PUB) 180-1, "Secure Hash Standard", U.S. Department of 2630 Commerce / National Institute of Standards and Technology, 2631 April 1995. 2632 or D. Eastlake 3rd, P. Jones, "US Secure Hash Algorithm 1 2633 (SHA1), RFC 3174, September 2001. 2635 [X509EXT] Lynn, C., Kent, S., Seo, K., "X.509 Extensions for IP 2636 Addresses and AS Identifiers", 2637 draft-ietf-pkix-x509-IPaddr-AS-extn-01.txt, June 2003. 2639 [X509S-BGP]Lynn, C., "S-BGP Authorization PKI -- X.509 Extensions and 2640 Profile", draft-clynn-bgp-x509-auth-02.txt, February 2002. 2642 The following references are informative. 2644 [AS4Bytes] Vohra, Q., Chen, E., "BGP support for four-octet AS number 2645 space", draft-ietf-idr-as4bytes-05.txt, May 2002. 2647 [BGPRES] Sangli, S. R., Rekhter, Y., Fernando, R., Scudder, J. G., 2648 Chen, E., "Graceful Restart Mechanism for BGP", 2649 draft-ietf-idr-restart-06.txt, January 2003. 2651 [CMS03] Kent, S., "Securing the Border Gateway Protocol: A Status 2652 Update", Seventh IFIP TC-6 TC-11 Conference on 2653 Communications and Multimedia Security, October 2-3, 2003, 2654 Turin, Italy 2656 [DISCEX] Lynn, C., Seo, K., "Design and Analysis of the Secure 2657 Border Gateway Protocol (S-BGP)", IEEE DISCEX Conference, 2658 January, 2000. 2660 [DPA] Chen, E., Bates, T., "Destination Preference Attribute for 2661 BGP", draft-ietf-idr-bgp-dpa-04.txt, January 1996 2663 [EXT-COMM] Sangli, S., Tappan, D., Rekhter, Y., "BGP Extended 2664 Communities Attribute", 2665 draft-ietf-idr-bgp-ext-communities-05.txt, May 2002. 2667 [JSAC] Kent, S., Lynn, C., Seo, K., "Secure Border Gateway 2668 Protocol (S-BGP)", IEEE JSAC Issue on Network Security, 2669 April 2000. 2671 [MRT] http://www.merit.edu/~mrt, 2672 http://www.merit.edu/mrt/mrt_doc 2674 [Murphy] Murphy, S., "BGP Security Vulnerabilities Analysis", 2675 draft-murphy-bgp-vuln-00.txt, February 2002. 2677 [Murphy2] Murphy, S., "BGP Security Protections", 2678 draft-murphy-bgp-protect-00.txt, February 2002. 2680 [NDSS00] Kent, S., Lynn, C., Mikkelson, J., Seo, K., "Secure Border 2681 Gateway Protocol (S-BGP) -- Real World Performance and 2682 Deployment Issues", Proceedings of the Network and 2683 Distributed System Security Symposium, San Diego 2684 California, February 2000. 2686 [RFC1863] Haskin, D., "A BGP/IDRP Route Server alternative to a full 2687 mesh routing", RFC 1863, October 1995. 2689 [RFC1965] Traina, P., "Autonomous System Confederations for BGP", 2690 RFC 1965, June 1996 2692 [RFC1997] Chandra, R., Li, T., Traina, P., "BGP Communities 2693 Attribute", RFC 1997, August 1996 2695 [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., 2696 Postel, J., "Internet Registry IP Allocation Guidelines", 2697 RFC 2050, BCP 00012, November 1996. 2699 [RFC2401] Kent, S., Atkinson, R., "Security Architecture for the 2700 Internet Protocol", RFC 2401, November 1998. 2702 [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 2703 (ESP)", RFC 2406, November 1998. 2705 [RFC2407] Piper, D., "The Internet IP Security Domain of 2706 Interpretation for ISAKMP", RFC 2407, November 1998. 2708 [RFC2408] Maughan, D., Schertler, M., Schneider, M., Turner, J., 2709 "Internet Security Association and Key Management Protocol 2710 (ISAKMP)", RFC 2408, November 1998. 2712 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange 2713 (IKE)", RFC 2409, November 1998. 2715 [RFC2410] Glenn, R., Kent, S., "The NULL Encryption Algorithm and 2716 Its Use With IPsec", RFC 2410, November 1998. 2718 [RFC2796] Bates, T., Chandra, R., Chen, E., "BGP Route Reflection - 2719 An Alternative to Full Mesh IBGP", RFC 2796, April 2000. 2721 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May 2722 2000. 2724 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., Katz, D., 2725 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 2726 also draft-ietf-idr-rfc2858bis-02.txt, April 2002. 2728 [RFC3107] Rekhter, Y., Rosen, E., "Carrying Label Information in 2729 BGP-4", RFC 3107, May 2001. 2731 [RFC3279] Polk, W., Housley, R., Bassham, L., "Algorithms and 2732 Identifiers for the Internet X.509 Public Key 2733 Infrastructure Certificate and Certificate Revocation List 2734 (CRL) Profile", RFC 3279, April 2002. 2736 [RFC3280] Housley, R., Polk, W., Ford, W., Solo, D., "Internet X.509 2737 Public Key Infrastructure Certificate and Certificate 2738 Revocation List (CRL) Profile", RFC 3280, April 2002. 2740 [RVO] www.routeviews.org, /bgpdata and /route-views6/bgpdata. 2742 [SALTZER] Saltzer, J. and Schroder, M., "The Protection of 2743 Information in Computer Systems", IEEE Proceedings, 63(9), 2744 March 1975. 2746 [S-BGP] http://www.ir.bbn.com/projects/s-bgp 2748 Appendix A. Example Certificates, Hashes, and Signatures 2750 This informational appendix will be provided in a subsequent version 2751 of this document when all the TDB values have been assigned. 2753 PKI Examples 2755 Root CA Certificate 2756 text 2757 PEM 2759 Grandfather CA Certificate 2760 text 2761 PEM 2763 ISP CA Certificate 2765 ISP AS End-entity Certificate 2767 ISP Network End-entity Certificate 2769 Network Address Attestation 2770 text 2771 hex 2773 Router S-BGP End-entity Certificate 2775 ISP NOC Operator End-entity Certificate 2777 Repository CA Certificate 2779 Repository End-entity Certificate 2780 (db and SSL?) 2782 S-BGP UPDATE Message 2783 text 2784 hex 2786 Appendix B. Configuration 2788 S-BGP requires additional configuration information. This 2789 informational appendix describes configuration items that an S-BGP 2790 implementation might implement. 2792 Where to find and how to activate and use the RA signing private key. 2794 Where to find the NOC's public key. 2796 The name of the file(s) containing AA extracts, public key extracts, 2797 and S-BGP policy. 2799 Per NOC, how to negotiate an IPsec transport-mode ESP security 2800 association for upload to speakers, if required. 2802 Per peer, how to negotiate an IPsec transport-mode ESP security 2803 association. 2805 Appendix C. Policy Support 2807 This informational Appendix describes policies that an S-BGP 2808 implementation might implement. 2810 Secure BGP policy enables the incremental deployment of S-BGP, easier 2811 introduction of new S-BGP capable ASes and speakers, and the ability 2812 to work around misconfiguration in other ASes. For these reasons 2813 S-BGP policy is applied in a hierarchical manner such that policy may 2814 be specialized for particular ASes, speakers, or prefixes as 2815 appropriate by an S-BGP capable speaker. The policy levels are: 2817 * Global 2818 Policy set at the global level applies to all UPDATEs regardless 2819 of the prefixes being advertised, or the ASes or speakers from 2820 which they were originated or through which or to which they were 2821 advertised. Global policy must be set, and is the default when no 2822 more specific policy overrides it. 2824 * Autonomous System (AS) 2825 AS policy may be used when needed to override global policy, and 2826 is applied based on the AS from which an UPDATE was originated or 2827 through which or to which an UPDATE is advertised. 2829 * Speaker 2830 Speaker policy may be used when needed to override both global and 2831 AS policy, and is applied based on the individual speaker from 2832 which an UPDATE or RA was originated or to which an UPDATE is 2833 advertised. 2835 * Prefix 2836 Prefix policy may be used when needed to override global, AS, and 2837 speaker policy, and is applied based on a specific prefix. 2839 All policy is available at the global level; some policy is available 2840 for specialization to the AS, speaker, and/or prefix level. More 2841 specific policy always takes precedence. 2843 C.1. Policy Control Classes 2845 Consistent routing necessitates that BGP speakers apply the same 2846 algorithm on the same routing information. Therefore, some S-BGP 2847 functionality may need to be: 2849 * activated or deactivated based on speaker and AS capabilities, 2851 * configured for specific topologies and peering relationships, 2853 * tuned and optimized for performance and interoperability, 2854 * incrementally deployed to allow for interoperability of S-BGP 2855 capable and non-capable speakers, 2857 * extensible for the protection of new features added to BGP, and 2859 * workable around misconfigurations. 2861 These functional requirements are listed in order of significance and 2862 represent the control classes into which S-BGP policy is categorized. 2863 This section defines and categorizes the available S-BGP policy 2864 settings. 2866 Some policies provide an "only-route" setting. This setting implies 2867 that a received route may be selected even if some portion of the 2868 S-BGP verification process fails. If no other route successfully 2869 verifies for a given prefix, then a non-verified route for which the 2870 "only-route" policy applies may be selected; otherwise, no route 2871 would exist for the given prefix. This policy setting is more 2872 forgiving than outright route rejection, especially in the case of 2873 system misconfiguration, but does introduce a security risk. 2874 However, an attacker would not only have to send an invalid route 2875 update such that it passes an "only-route" policy, but also prevent 2876 all other valid routes from being received by a speaker. 2878 Several policy settings are represented as a set of BGP path 2879 attribute identifiers. Only transitive path attributes (i.e., path 2880 attributes available for S-BGP protection) may be specified in these 2881 policies. Currently defined transitive path attributes include the 2882 following. 2884 NLRI or MP_REACH_NLRI Type Code 0, only within S-BGP route 2885 attestations 2886 ORIGIN Type Code 1 2887 AS PATH Type Code 2 2888 ATOMIC AGGREGATE Type Code 6 2889 AGGREGATOR Type Code 7 2890 COMMUNITY Type Code 8 2891 DPA Type Code 11 2892 EXTENDED COMMUNITY Type Code 16 2894 Additional transitive path attributes may be protected as they are 2895 defined within the BGP protocol. 2897 The NOC provides each S-BGP speaker a policy configuration file in 2898 addition to the AA and certificate extract files. The integrity of 2899 and the authorization to use the S-BGP policy is assured by the 2900 signing of the file by the NOC with, e.g., the NOC's or AS's private 2901 key. 2903 C.2. Activation 2905 General S-BGP functionality is activated or deactivated based on the 2906 following policy. 2908 C.2.1 enable-AA 2910 The "enable-AA" policy directs an S-BGP speaker to perform, or not 2911 perform, AA verification of the NLRI within received UPDATEs. This 2912 policy is applied only at the global level, and available settings 2913 include: 2915 yes AA verification of NLRI received in UPDATEs is 2916 performed. 2917 no AA verification of NLRI received in UPDATEs is not 2918 performed. 2920 The default setting is "yes"; under normal operation an S-BGP speaker 2921 should always perform NLRI origination verification using AA 2922 information. However, an S-BGP speaker newly introduced into the 2923 network may not have received AA extracts required to perform AA 2924 verification, in which case the policy may be set to "no". 2926 If this policy is set to "no", then all other policy pertaining to AA 2927 verification is not activated. 2929 C.2.2 enable-RA 2931 The "enable-RA" policy directs an S-BGP speaker to process, or not 2932 process, RAs within received UPDATEs. This policy is applied only at 2933 the global level, and available settings include: 2935 yes Processing of RAs received in UPDATEs is performed. 2936 no Processing of RAs received in UPDATEs is not 2937 performed. 2939 The default setting is "yes"; under normal operation S-BGP should 2940 always process received RAs. However, an S-BGP speaker may lack 2941 public keys required to perform RA verification of UPDATEs, or an 2942 S-BGP speaker may not peer with any other S-BGP capable speaker. In 2943 such cases the policy is best set to "no". 2945 If this policy is set to "no", then all other policy pertaining to 2946 inbound route attestations is not activated. 2948 C.2.3 send-attest 2950 The "send-attest" policy directs an S-BGP speaker to include, or not 2951 include, an attestation path attribute in outbound advertisements. 2952 This policy is applied at the global and peer (speaker) levels, and 2953 available settings include: 2955 yes An attestation path attribute is included within 2956 outbound advertisements for locally originated routes 2957 and for transit advertisements that contained an 2958 attestation path attribute. 2959 no No attestation path attribute is included in outbound 2960 advertisements, and any attestation path attribute is 2961 removed before sending a transit advertisement. 2963 The default setting is "yes"; under normal operation an S-BGP speaker 2964 should always prepend a locally generated RA within the attestation 2965 path attribute of all transit or locally originated outbound 2966 advertisements. The "no" policy setting is used when a speaker peers 2967 with a non S-BGP capable speaker. In this case, no attestation path 2968 attribute is included within the outbound advertisements. 2970 If this policy is set to "no", then all other policy pertaining to 2971 outbound advertisements is not activated. 2973 C.3. Configuration 2975 The following policy is used in configuring an S-BGP speaker for a 2976 particular topology and set of peering relationships. 2978 C.3.1 sign-AS 2980 The "sign-AS" policy allows multiple targets (peer ASes) to be 2981 identified in an RA when a single UPDATE is to be sent to multiple 2982 external peers. The target of an RA is the set of ASes being 2983 authorized to use and advertise the route associated with the RA. 2984 The default target is the AS of the speaker to which the route is 2985 being sent. In the case of external route reflectors, however, 2986 multiple targets will need to be specified because the advertised 2987 route is further propagated to the other speakers in communication 2988 with the route reflector. This policy is applied only at the peer 2989 (speaker) level and consists of a list of unique AS numbers. 2991 Note that internal route reflectors are often used for iBGP; the 2992 "sign-AS" policy does not apply in such a case because RAs are not 2993 generated and included within UPDATEs sent to internal peers. 2994 However, external route reflectors may be used at network access 2995 points (NAPs), for example, to forward received UPDATEs to multiple 2996 external speakers. 2998 C.3.2 peer-auth 3000 The "peer-auth" policy specifies which entity, if any, is responsible 3001 for performing peer authentication through the use of IPsec. This 3002 policy is applied at the global and peer levels, and available 3003 settings include: 3005 bgp The BGP speaker is responsible for performing peer 3006 authentication. 3007 system The system on which the BGP speaker resides is 3008 responsible for performing peer authentication. 3009 no No peer authentication is performed. 3011 The default policy setting is "system". Speakers on either side of a 3012 peering relationship must have consistent settings for this policy. 3014 C.3.3 peer-key 3016 The "peer-key" policy specifies the key to use for purposes of peer 3017 authentication. 3019 C.3.4 upload-port 3021 The "upload-port" policy specifies the port number and protocol over 3022 which information such as the extract and policy files is uploaded 3023 from the NOC. 3025 C.4. Tuning and Optimization 3027 Policy for tuning and optimizing the performance of a S-BGP speaker 3028 is defined as follows. 3030 C.4.1 verify-RA 3032 The "verify-RA" policy determines the time at which the RAs within a 3033 received S-BGP UPDATE undergo signature verification. This policy is 3034 applied only at the global level, and the available settings include: 3036 receipt RAs are verified prior to the route's inclusion within 3037 the Adj-RIB-In. 3038 selection RAs are verified prior to the route's inclusion within 3039 the Loc-RIB. 3040 background RAs are queued for verification at the time of the 3041 route's inclusion within the Adj-RIB-In; RAs must be 3042 verified prior to the route's inclusion within the 3043 Loc-RIB. 3045 The "receipt" setting results in the verification of all received 3046 UPDATEs. Any invalid route is detected and reported upon receiving 3047 the route, regardless of Phase 2 route selection. The early 3048 detection of invalid routes requires resources be allocated to 3049 cryptographic verification of routes that may never be selected. 3050 Greater resource efficiency is achieved by setting the policy to 3051 "selection", which is the default setting. The "background" setting 3052 combines the earlier detection of invalid routes with greater 3053 resource efficiency. 3055 C.4.2 multi-route 3057 The "multi-route" policy applies only in the case of UPDATEs that 3058 have undergone route aggregation. A given prefix may be included in 3059 multiple paths of the aggregated route. This policy directs an S-BGP 3060 speaker performing AA verification of aggregated routes for a common 3061 prefix. This policy is applied at the global and prefix levels, and 3062 available settings include: 3064 all All paths to a common prefix within a received UPDATE 3065 must be valid. 3066 one At least one path to a common prefix within a received 3067 UPDATE must be valid. 3069 The default setting is "all"; ensuring that all aggregated routes to 3070 a common prefix are valid provides greater security. The "one" 3071 setting is a more permissive alternative. 3073 C.4.3 max-origin 3075 The "max-origin" policy specifies the maximum sized NLRI to be 3076 included within originated UPDATE. This policy is applied at the 3077 global and speaker levels, and is used only in the origination, not 3078 propagation, of routes. A maximum NLRI size is used to leave 3079 sufficient space within an UPDATE for the attestation path attribute, 3080 which grows in size during propagation. 3082 The "max-origin" policy specifies the percentage of the space in an 3083 originated UPDATE less the NLRI that may be used for NLRI. 3084 Determination of the value of this policy includes factors such as 3085 expected aggregation or UPDATE NLRI splitting and the diameter of the 3086 Internet, in ASes. The default setting for this policy is 75 3087 percent, i.e., three quarters of the remaining space in an UPDATE 3088 without NLRI may be used for NLRI. 3090 C.4.4 prefix-class 3092 The "prefix-class" policy is used to tag specific prefixes. Prefixes 3093 within different classes are not aggregated in a single UPDATE. This 3094 policy is applied only at the prefix level and is used only in the 3095 origination, not propagation, of routes. By default, all prefixes 3096 are assigned to the same class. 3098 This policy is significant in when an AS has multi-homed customers. 3099 A multi-homed customer authorizes multiple ASes to advertise routes 3100 for its prefix(es). At some AS, the route advertised by one 3101 originating AS for a prefix from a multi-homed customer will not be 3102 the best route (the route from one of the other originating ASes will 3103 be better) and, therefore, it will not be propagated further. The 3104 UPDATE that advertised the route may still be advertised for the 3105 other prefixes contained within the UPDATE'S NLRI; the multi-homed 3106 prefix is removed prior to the further propagation of the UPDATE. 3107 Modification of the NLRI requires that all the NLRI be included as 3108 explicit data within the Last received RA, which increases the size 3109 of the UPDATE. To prevent this situation, multi-homed prefixes may 3110 be assigned to a different prefix class and originated in separate 3111 UPDATEs. 3113 C.4.5 aggregate-any 3115 The "aggregate-any" policy indicates whether a S-BGP speaker may 3116 aggregate a verified and non-verified routes into a single UPDATE. 3117 This policy is applied only at the global level, and available 3118 settings include: 3120 yes Aggregation of verified and non-verified routes is 3121 allowed. 3122 no Aggregation of verified and non-verified routes is not 3123 allowed. 3125 The default setting is "no"; under normal operation a S-BGP speaker 3126 should not aggregate verified routes with non-verified routes. A 3127 more permissive alternative is provided by the "yes" setting. Use of 3128 this policy requires further study. 3130 C.4.6 in-cache-depth 3132 The "in-cache-depth" policy specifies the number of received 3133 attestation path attributes to cache for a prefix. The cache may be 3134 used to reduce the computational resources required for cryptographic 3135 verification of received UPDATEs at the expense of requiring more 3136 memory. An inbound attestation cache may be maintained for each 3137 neighboring speaker. Note that the BGP specification requires that 3138 the most recently received route for each prefix from each peer be 3139 retained in the peer's Adj-RIB-In; this policy specifies how many 3140 additional routes should be cached. 3142 C.4.7 out-cache-depth 3144 The "out-cache-depth" policy specifies the number of outbound 3145 attestation path attributes to cache. The cache may be used to 3146 reduce the computational resources required for signature generation 3147 for outbound UPDATEs at the expense of requiring more memory. An 3148 outbound attestation cache may be maintained for each neighboring 3149 speaker; this policy specifies how many routes should be cached. 3151 C.5. Incremental Deployment 3153 The following policy allows for the incremental deployment of S-BGP, 3154 during which time not all BGP speakers will implement the S-BGP 3155 security countermeasures. 3157 C.5.1 require-AA 3159 The "require-AA" policy specifies the prefixes for which AAs are 3160 required, or not required, from the ASes originating routes to those 3161 prefixes. This policy is applied at the global (i.e., all prefixes), 3162 AS (i.e., prefixes originated by a particular AS), or prefix level. 3163 Available policy settings include: 3165 yes AA required for originating AS of prefix within NLRI 3166 of received route. 3167 no No AA required for originating AS of prefix within 3168 NLRI of received route. 3169 only-route If no AA exists for originating AS of a prefix in the 3170 NLRI of a received UPDATE, use the route only if no 3171 other verified route exists. 3173 The default setting is "yes"; under normal operations S-BGP should 3174 perform AA verification of all prefixes in advertised in received 3175 UPDATEs. However, during incremental deployment many prefix owners 3176 will not have issued AAs for their prefixes. To allow routes to 3177 these prefixes to be used, the "only-route" setting is used. The 3178 "no" setting will not accept routes to prefixes that do not have an 3179 AA; it may be used in, e.g., closed user groups that do not want 3180 routes to unprotected destinations. 3182 C.5.2 require-RA 3184 The "require-RA" policy specifies requirements for RA presence in 3185 received UPDATEs, and is applied at the global (i.e., all route 3186 UPDATEs), AS (i.e., UPDATEs received from or transiting a particular 3187 AS), and speaker (i.e., UPDATE received from a particular speaker) 3188 level. Available policy settings include: 3190 yes RA required; signature must be successfully verified. 3191 no-verify RA required; signature is not verified. 3192 no No RA required. 3193 only-route RA required; if invalid signature, use route if no 3194 other verified route exits. 3196 The default policy is "yes"; under normal operation S-BGP should 3197 always require and verify RAs in all received UPDATEs. The 3198 "only-route" setting provides a more permissive alternative. In the 3199 case that an S-BGP speaker lacks the public key required for RA 3200 verification, the "no-verify" setting requires an RA but no 3201 cryptographic verification is performed. The "no" policy setting 3202 allows for speakers to accept UPDATEs from neighboring speakers that 3203 are not S-BGP capable. If, however, the "no" policy is set and an 3204 UPDATE that contains RAs is received, then the RAs are processed and 3205 verified. 3207 C.5.3 new-speaker 3209 A "new speaker" is an RA signer for which there is no public key in 3210 the database. The "new-speaker" policy directs an S-BGP speaker to 3211 either reject or accept an UPDATE that cannot be verified due to a 3212 missing public key. This policy is applied at the global and AS 3213 levels, and available settings include: 3215 reject Reject routes received for which there is no public 3216 key. 3217 accept Accept routes received for which there is no public 3218 key. 3219 only-route Accept routes received for which there is no public 3220 key when no other verified route for a prefix exists. 3222 The default policy setting is "reject". Strict security requires the 3223 successful verification of all received routes. A more permissive 3224 alternative is the "only-route" setting. The "accept" setting is 3225 useful when an AS forgets to renew an expired key, or starts sending 3226 RAs before the public key has been propagated throughout the 3227 Internet. 3229 C.5.4 new-prefix 3231 A "new prefix" is a prefix for which a speaker has no origination AA 3232 information. The "new-prefix" policy instructs an S-BGP speaker how 3233 to handle a received UPDATE that contains a prefix for which no AA 3234 information exists and, therefore, cannot undergo AA verification. 3236 This policy is applied at the global, AS, and prefix levels, and 3237 available settings include: 3239 reject Reject route for a prefix with no AA information. 3240 accept Accept route for a prefix with no AA information. 3242 Policy defaults to the "reject" setting. The "accept" policy setting 3243 is useful when a prefix owner has never issued an AA, or fails to 3244 reissue an expired AA. This policy only applies when there is no AA 3245 information for a prefix, not when the authorized originating ASes 3246 are specified but the route identifies a different originating AS. 3248 C.5.5 send-explicit 3250 The "send-explicit" policy directs an S-BGP speaker to include, or 3251 not include, protected path attributes as explicit data within the 3252 locally generated. This policy may be applied at the global (i.e., 3253 all generated RAs) and speaker (i.e., generated RAs intended for a 3254 particular peer speaker) levels. The available settings for this 3255 policy are: 3257 yes Protected path attributes in locally generated RAs are 3258 included as explicit data. 3259 no Protected path attributes in locally generated RAs are 3260 not included as explicit data, i.e., they are implicit 3261 data. 3263 The default setting is "no"; under normal operation when the content 3264 of a path attribute does not change, an S-BGP speaker should not 3265 include protected path attributes as explicit in the generated RAs 3266 prepended to outbound UPDATEs. Protected path attributes are 3267 included as explicit data by setting this policy to "yes". The 3268 "mask-explicit" policy (see section C.6.4) overrides the "no" 3269 setting. 3271 A speaker in a peer AS to which a UPDATE is sent MAY change explicit 3272 data to implicit prior to the further propagation of the UPDATE to 3273 reduce the size of the UPDATE if the data has not changed (see 3274 section C.5.6). 3276 C.5.6 make-implicit 3278 The "make-implicit" policy directs an S-BGP speaker to change, or not 3279 change, explicitly protected path attributes in the Last received RA 3280 in a received UPDATE to implicit data when advertising it to external 3281 peers. This only applies to protected path attributes that have not 3282 been modified by the speaker; all modified path attributes that are 3283 protected must be included as explicit in the Last received RA. This 3284 policy is applied at the global and peer levels, and available 3285 settings include: 3287 yes Explicit path attributes in Last received RAs are made 3288 implicit. 3289 no Explicit path attributes in Last received RAs remain 3290 as explicit. 3292 Under default operations all the data in the ExplicitPA part of the 3293 Last received RA should be implicit, i.e., the ExplicitPA part is 3294 empty and this policy setting does not apply. 3296 The default setting is "yes", which allows a speaker to reduce the 3297 size of an UPDATE by removing redundant explicit data from the RAs in 3298 its advertisements. If all the RAs within an UPDATE included an 3299 explicit copy of all protected path attributes the UPDATE may grow 3300 too large for the 4 KB UPDATE limit. The "no" setting is available 3301 to allow protected path attributes to remain as explicit within the 3302 Last received RA. This may be used when a newly defined transitive 3303 path attribute is introduced into BGP. The canonicalized format of 3304 new path attributes may not be known, and consequently, such path 3305 attributes should remain explicit in RAs. 3307 C.6. Extensibility 3309 The following policy allows an S-BGP speaker to be easily extended to 3310 handle new transitive BGP path attributes. 3312 C.6.1 mask-require 3314 The "mask-require" policy specifies the path attributes that must be 3315 protected within received RAs. If an RA in a received UPDATE does 3316 not protect all the path attributes specified by this policy, then 3317 the route must be rejected. This policy is applied at the global 3318 (i.e., all RAs), AS (i.e., RAs generated by or transiting a 3319 particular AS), and speaker (i.e., RAs generated by a particular 3320 speaker) levels. By default, the "mask-require" policy specifies 3321 that the ORIGIN and AS PATH path attributes, in addition to the NLRI, 3322 be protected within received RAs because they represent route 3323 information essential for the operation of S-BGP. 3325 C.6.2 mask-ignore 3327 The "mask-ignore" policy specifies path attributes that, except for 3328 the case of signature verification, should not cause a received 3329 UPDATE to be rejected. A path attribute to be ignored as indicated 3330 by this policy does not need to be verified for semantics or correct 3331 propagation. However, an ignored but protected path attribute needs 3332 to be sufficiently valid to result in the successful signature 3333 verification of an RA. By default, the "mask-ignore" policy is an 3334 empty set, specifying no path attributes to be ignored during 3335 verification, and is applied at the global, AS, and speaker levels. 3337 C.6.3 mask-protect 3339 The "mask-protect" policy specifies the path attributes that must be 3340 protected within locally generated RAs prepended to outbound UPDATEs. 3341 This policy is applied at the global and speaker levels. By default, 3342 the "mask-protect" policy specifies that all defined transitive path 3343 attributes be protected in generated RAs. In addition to the path 3344 attributes specified by this policy, all path attributes protected by 3345 the Last received RA must be protected. 3347 The NLRI, ORIGIN, and AS PATH represent route information essential 3348 for the operation of S-BGP and should always be protected. It is 3349 recommended that other transitive path attributes included within an 3350 UPDATE be protected, as well, to ensure greater security. However, 3351 protection of path attributes that may change frequently from speaker 3352 to speaker (e.g., communities) increases the size of RAs. Each time 3353 that a protected path attribute is modified at a speaker during route 3354 propagation an explicit copy must be included within the Last 3355 received RA. Additionally, splitting an UPDATE that contains an 3356 attestation path attribute into multiple UPDATEs only results in 3357 UPDATEs even greater in size because the protected path attributes 3358 need to be included as explicit data. This policy allows path 3359 attributes, particularly those less essential to correct operation, 3360 to be excluded from protection in consideration of the size and 3361 growth of UPDATEs. 3363 C.6.4 mask-explicit 3365 The "mask-explicit" policy directs an S-BGP speaker to include 3366 specific protected path attributes as explicit date within locally 3367 generated RAs prepended to outbound UPDATEs. This policy only 3368 applies in the case that the "send-explicit" policy (see section 3369 C.5.5) is set to "no", and is applied at the global and speaker 3370 levels. By default, the "mask-explicit" policy does not specify that 3371 any defined transitive path attributes be included as explicit within 3372 generated RAs. 3374 Transitive path attributes protected by S-BGP may need to undergo 3375 canonicalization prior to signature generation and verification. Not 3376 all S-BGP speakers may know the canonicalized format of a path 3377 attribute, especially in the case of one newly defined, and therefore 3378 such path attributes should be included as explicit date (in 3379 canonicalized form) within the RAs generated by the speaker that 3380 included the path attribute within an UPDATE. Therefore, this policy 3381 is important in enabling the incremental deployment of newly defined 3382 path attributes. 3384 C.7. Incremental Deployment Policy Examples 3386 When an S-BGP capable router is first installed (before the AS is 3387 ready to use the S-BGP protections) it should "turn S-BGP off". The 3388 following policy settings are used. 3390 Policy Level Setting 3391 ----------- ------ ------- 3392 enable-AA global no 3393 enable-RA global no 3394 send-attest global no 3396 The next step in deployment, might be to just perform NLRI 3397 origination verification, but not make any route selections based on 3398 the results; i.e., just report failures. 3400 Policy Level Setting 3401 ----------- ------ ------- 3402 enable-AA global yes 3403 require-AA global no 3404 enable-RA global no 3405 send-attest global no 3407 When all the BGP speakers are ready to use the S-BGP protection 3408 mechanisms to select routes, but peer ASes are not S-BGP capable, the 3409 speakers may initially only perform AA verification. Such a speaker 3410 would use the following policy settings. 3412 Policy Level Setting 3413 ----------- ------ ------- 3414 enable-AA global yes 3415 enable-RA global no 3416 send-attest global no 3418 Now consider an S-BGP speaker that peers with all non S-BGP capable 3419 speakers except for speaker x within AS X. Lets assume that no other 3420 speakers in AS X are S-BGP capable. Policy is set as below. 3422 Policy Level Setting 3423 ----------- ------ ------- 3424 enable-AA global yes 3425 enable-RA global yes 3426 require-RA global no 3427 require-RA speaker x yes 3428 send-attest global no 3429 send-attest speaker x yes 3431 Now, assume that all ASes and their associated speakers are S-BGP 3432 capable except for peer AS Y. 3434 Policy Level Setting 3435 ----------- ------ ------- 3436 enable-AA global yes 3437 enable-RA global yes 3438 require-RA global yes 3439 require-RA AS Y no 3440 send-attest global yes 3441 send-attest AS Y no 3443 C.8. Summary 3445 Columns heading abbreviations: 3446 G Global 3447 A AS 3448 S Speaker or peer 3449 P Prefix 3451 A default value is enclosed in [...]. 3453 Policy Section Class G A S P Type Values 3454 --------------- ------- ------------- - - - - ------- ------ 3455 enable-AA 3.1.1 Activation X _ _ _ enum [yes] 3456 no 3457 require-AA 3.4.1 Deployment X X _ X enum [yes] 3458 only-route 3459 no 3460 enable-RA 3.1.2 Activation X _ _ _ enum [yes] 3461 no 3462 require-RA 3.4.2 Deployment X X X _ enum [yes] 3463 no-verify 3464 only-route 3465 no 3466 verify-RA 3.3.1 Tuning and X _ _ _ enum receipt 3467 Optimization [selection] 3468 background 3469 new-speaker 3.4.3 Deployment X X _ _ enum [reject] 3470 only-route 3471 accept 3472 new-prefix 3.4.4 Deployment X X _ X enum [reject] 3473 accept 3474 multi-route 3.3.2 Tuning and X _ _ X enum [all] 3475 Optimization one 3476 mask-require 3.5.1 Extensibility X X X _ bitmask [NLRI] 3477 [ORIGIN] 3478 [AS PATH] 3479 ATOMIC AGG 3480 AGG 3481 COMM 3482 DPA 3483 MPREACH 3484 EXT COMM 3485 mask-ignore 3.5.2 Extensibility X X X _ bitmask NLRI 3486 ORIGIN 3487 AS PATH 3488 ATOMIC AGG 3489 AGG 3490 COMM 3491 DPA 3492 MPREACH 3493 EXT COMM 3494 send-attest 3.1.3 Activation X _ X _ enum [yes] 3495 no 3496 send-explicit 3.4.5 Deployment X _ X _ enum yes 3497 [no] 3498 make-implicit 3.4.6 Deployment X _ X _ enum [yes] 3499 no 3500 mask-protect 3.5.3 Extensibility X _ X _ bitmask [NLRI] 3501 [ORIGIN] 3502 [AS PATH] 3503 [ATOMIC AGG] 3504 [AGG] 3505 [COMM] 3506 [DPA] 3507 [MPREACH] 3508 [EXT COMM] 3509 mask-explicit 3.5.4 Extensibility X _ X _ bitmask NLRI 3510 ORIGIN 3511 AS PATH 3512 ATOMIC AGG 3513 AGG 3514 COMM 3515 DPA 3516 MPREACH 3517 EXT COMM 3518 max-origin 3.3.3 Tuning and X _ X _ percent 75% 3519 Optimization 3520 prefix-class 3.3.4 Tuning and _ _ _ X integer 0 3521 Optimization 3522 sign-AS 3.2.1 Configuration _ _ X _ AS set null set 3523 aggregate-any 3.3.5 Tuning and X _ _ _ enum yes 3524 Optimization [no] 3525 in-cache-depth 3.3.6 Tuning and X _ X _ integer 1 3526 Optimization 3527 out-cache-depth 3.3.7 Tuning and X _ X _ integer 1 3528 Optimization 3529 peer-auth 3.2.2 Configuration X _ X _ enum BGP 3530 [System] 3531 No 3532 peer-key 3.2.3 Configuration X _ _ _ integer no key 3533 upload-port 3.2.4 Configuration X _ _ _ integer 3535 Appendix D. NOC Support 3537 This informational appendix describes operations that a NOC that uses 3538 S-BGP would perform. 3540 S-BGP uses out-of-band distribution of Address Attestations, 3541 Certificate Revocation Lists, and Certificates. An S-BGP speaker 3542 will eventually need the public key from the certificate of each RA 3543 signer, and will eventually need an Address Attestation for each 3544 prefix in one of its Adj-RIBs-Ins. There are two tiers in the 3545 distribution hierarchy. 3547 The first tier consists of servers at several well-known and highly 3548 connected locations such as a major peering points or ISPs. These 3549 servers are sent certificates and CRLs by the registries and 3550 organizations given the right to use AS numbers or IP address blocks. 3551 End organizations that are given the right to use IP address blocks 3552 create and sign Address Attestations that authorize their provider's 3553 AS to advertise their address block, and send the AAs to the servers. 3555 The second tier consists of the NOCs of the organizations that manage 3556 ASes. They transfer from the first tier servers the set of AAs, 3557 certificates, and CRLs. The NOC then validates the information 3558 received, digests it, and uploads the digested information to their 3559 S-BGP speakers. 3561 This preprocessing by the NOC has several advantages. First, the 3562 verification of the AAs, certificates, and CRLs is performed only 3563 once instead of having each S-BGP speaker duplicate the work. 3564 Second, digesting the information significantly reduces the volume of 3565 data that is sent to and stored in the speakers. Third, by receiving 3566 pre-validated data, the time for the S-BGP speaker to reboot from a 3567 catastrophic loss of memory is significantly reduced. Forth, in the 3568 event of a catastrophic loss of inter-AS routing, the information can 3569 still be uploaded to speakers using intra-AS routing. 3571 Certification functions performed by the NOC: 3573 Generate public/private key pair for the AS. 3575 Send the AS's public key to registry for inclusion in the 3576 certificate transferring the right to use the AS number to the 3577 organization. 3579 Generate public/private key pairs for each authorized S-BGP 3580 speaker in the AS and issue them each a certificate. Copies of 3581 the certificates are sent to an S-BGP repository. 3583 Generate a public/private key pair for the organization's 3584 ownership of IP address blocks. The public key is sent to the IP 3585 address delegation registry for inclusion in the certificate 3586 transferring the right to use the address blocks to the 3587 organization. 3589 Intellectual Property Rights 3591 The IETF takes no position regarding the validity or scope of any 3592 intellectual property or other rights that might be claimed to 3593 pertain to the implementation or use of the technology described in 3594 this document or the extent to which any license under such rights 3595 might or might not be available; neither does it represent that it 3596 has made any effort to identify any such rights. Information on the 3597 IETF's procedures with respect to rights in standards-track and 3598 standards-related documentation can be found in BCP-11. Copies of 3599 claims of rights made available for publication and any assurances of 3600 licenses to be made available, or the result of an attempt made to 3601 obtain a general license or permission for the use of such 3602 proprietary rights by implementors or users of this specification can 3603 be obtained from the IETF Secretariat. 3605 The IETF invites any interested party to bring to its attention any 3606 copyrights, patents or patent applications, or other proprietary 3607 rights which may cover technology that may be required to practice 3608 this standard. Please address the information to the IETF Executive 3609 Director. 3611 Full Copyright Statement 3613 This document and translations of it may be copied and furnished to 3614 others, and derivative works that comment on or otherwise explain it 3615 or assist in its implementation may be prepared, copied, published 3616 and distributed, in whole or in part, without restriction of any 3617 kind, provided that the above copyright notice and this paragraph are 3618 included on all such copies and derivative works. However, this 3619 document itself may not be modified in any way, such as by removing 3620 the copyright notice or references to the Internet Society or other 3621 Internet organizations, except as needed for the purpose of 3622 developing Internet standards in which case the procedures for 3623 copyrights defined in the Internet Standards process shall be 3624 followed, or as required to translate it into languages other than 3625 English. 3627 The limited permissions granted above are perpetual and will not be 3628 revoked by the Internet Society or its successors or assigns. 3630 This document and the information contained herein is provided on an 3631 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3632 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3633 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3634 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3635 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3637 Author's Addresses 3639 Charles Lynn 3640 BBN Technologies 3641 10 Moulton Street 3642 Cambridge, MA 02138 3643 USA 3644 E-mail: CLynn@BBN.Com 3645 Telephone: 617-873-3367 3647 Joanne Mikkelson 3648 BBN Technologies 3649 10 Moulton Street 3650 Cambridge, MA 02138 3651 USA 3652 E-mail: JMMikkel@BBN.Com 3653 Telephone: 617-873-4598 3655 Karen Seo 3656 BBN Technologies 3657 10 Fawcett Street 3658 Cambridge, MA 02138 3659 USA 3660 E-mail: KSeo@BBN.Com 3661 Telephone: 617-873-3152