idnits 2.17.1 draft-ietf-rpsec-bgpsecrec-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 814. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o It SHOULD not introduce new organizational entities that have to be trusted in order to establish the authenticity of the data. -- 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 (November 3, 2008) is 5653 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Protocol Security B. Christian, Ed. 3 Requirements Microsoft 4 Internet-Draft T. Tauber, Ed. 5 Intended status: Informational Comcast 6 Expires: May 7, 2009 November 3, 2008 8 BGP Security Requirements 9 draft-ietf-rpsec-bgpsecrec-10 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 7, 2009. 36 Abstract 38 The security of BGP, the Border Gateway Protocol, is critical to the 39 proper operation of large-scale internetworks, both public and 40 private. While securing the information transmitted between two BGP 41 speakers is a relatively easy technical matter, securing BGP, as a 42 routing system, is more complex. This document describes a set of 43 requirements for securing BGP and the routing information carried 44 within BGP. 46 Table of Contents 48 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 49 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2.1. System Description . . . . . . . . . . . . . . . . . . . . 3 51 2.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.3. Areas to secure . . . . . . . . . . . . . . . . . . . . . 4 53 3. Underlying Assumptions regarding BGP . . . . . . . . . . . . . 5 54 4. Operational Requirements . . . . . . . . . . . . . . . . . . . 8 55 4.1. Convergence speed . . . . . . . . . . . . . . . . . . . . 8 56 4.2. Incremental deployment . . . . . . . . . . . . . . . . . . 9 57 4.3. Conditions for initialization . . . . . . . . . . . . . . 9 58 4.4. Local controls for secure UPDATE acceptance . . . . . . . 10 59 4.5. Processing on Routers . . . . . . . . . . . . . . . . . . 10 60 4.6. Configuration on Routers . . . . . . . . . . . . . . . . . 11 61 5. Infrastructure Requirements . . . . . . . . . . . . . . . . . 11 62 6. The Trust Model . . . . . . . . . . . . . . . . . . . . . . . 12 63 7. The AS_PATH Attribute and NLRI Authentication . . . . . . . . 12 64 8. Address Allocation and Advertisement . . . . . . . . . . . . . 14 65 9. Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 10. NLRI and Path Attribute Tracking . . . . . . . . . . . . . . . 15 67 11. Transport Layer Protection . . . . . . . . . . . . . . . . . . 15 68 12. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 16 69 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 70 14. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 15.1. Normative References . . . . . . . . . . . . . . . . . . . 16 73 15.2. Informative References . . . . . . . . . . . . . . . . . . 16 74 Appendix 1. Acknowledgements . . . . . . . . . . . . . . . . . . 17 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 76 Intellectual Property and Copyright Statements . . . . . . . . . . 18 78 1. Requirements Language 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [RFC2119]. 84 2. Introduction 86 2.1. System Description 88 BGP is described in RFC4271 [RFC4271], as a path-vector routing 89 protocol. BGP speakers typically exchange information about 90 reachable destinations (expressed as address prefixes) in an 91 internetwork through pair-wise peering sessions. Once this 92 information has been exchanged, each BGP speaker locally determines a 93 loop free path to each reachable destination, based on local policy 94 or policy indicators such as community values and LOCAL_PREF which 95 may be carried in the UPDATE, and the AS_PATH data carried in the BGP 96 UPDATE messages. 98 Each BGP speaker represents an Autonomous System (AS). All of the 99 BGP speakers within an AS operate under a common administrative 100 policy. 102 2.2. Threats 104 Violations of security for network and information systems generally 105 fall under one of the three categories as defined in RFC 2196 106 [RFC2196]: 108 o Unauthorized access to resources and/or information 110 o Unintended and/or unauthorized disclosure of information 112 o Denial of service 114 A number of attacks can be realized which, if exploited, can lead to 115 one of the above mentioned security violations. Attacks against 116 communications are typically classified as passive or active 117 wiretapping attacks. Passive attacks are ones where an attacker 118 simply observes information traversing the network, violating 119 confidentiality or identifying a means of engaging in further 120 attacks. Active attacks are ones where the attacker modifies data in 121 transit. Such attacks include replay attacks, message insertion, 122 message deletion, and message modification attacks. Some attacks may 123 be effected by sending data from any where in the Internet. Other 124 active attacks require a "man-in-the-middle" capability, i.e., the 125 attacker must be in a position where traffic passes through an 126 attacker-controlled device. Attacks against BGP may be used by an 127 attacker to facilitate a wide variety of active or passive 128 wiretapping attacks against subscriber traffic. 130 Attacks that do not involve direct manipulation of BGP, and the 131 information contained within BGP, are outside the scope of this 132 document, except as relates to transport layer of the BGP session as 133 discussed here and in related documents. 135 Because ASes are autonomous in their operation, it is not possible to 136 mandate secure operation by all ASes, nor would it be advisable to 137 assume such operation. Thus the primary goal of BGP security 138 measures is to provide data to AS operators to enable BGP speakers to 139 reject advertisements (UPDATE messages) that are not valid. For 140 example, UPDATE messages that represent erroneous binding of prefixes 141 to an origin AS, or that advertise invalid paths (as defined later in 142 this document) should be rejected. Because BGP peering sessions take 143 place in the context of TCP, the authentication and integrity 144 guarantees usually associated with TCP need to be provided in the 145 face of possible active wiretapping attacks. Using the terminology 146 established in RFC 3552 [RFC3552], these peering sessions should be 147 afforded data origin and peer entity authentication and connection- 148 oriented integrity. 150 Security for subscriber traffic is outside the scope of this 151 document, and of BGP security in general. IETF standards for 152 subscriber data security, e.g., IPsec, TLS, and S/MIME should be 153 employed for such purposes. While adoption of BGP security measures 154 may preclude certain classes of attacks on subscriber traffic, these 155 measures are not a substitute for use of subscriber-based security 156 mechanisms of the sort noted above. 158 2.3. Areas to secure 160 There are two primary points where BGP may be secured; the data 161 payload of the protocol and the data semantics of the protocol. 163 The session between two BGP speakers can be secured such that the BGP 164 data received by the BGP speakers can be cryptographically verified 165 to have been transmitted by the peer BGP speaker and not a replay of 166 previously transmitted legitimate data. There are several existing 167 IETF standards to choose from to ensure that this system functions 168 with greater effectiveness than the current system. An example might 169 be IPsec. Some in the Operator community have expressed concerns 170 that requiring cryptographic validation could open another vector for 171 a denial-of-service attack by flooding the processor with bogus 172 packets which must be cryptographically invalidated before being 173 discarded. Thus, any cryptographic mechanism used to secure BGP 174 sessions MUST be evaluated with regard to this denial of service 175 concern. 177 There are also several questions we can ask about the information 178 contained within a received UPDATE. 180 o Is the originating Autonomous System authorized to propagate the 181 prefix we have received? 183 o Does the AS_PATH, received via an UPDATE, represent a valid path 184 through the network? 186 The determination of AS_PATH validity falls into two distinct 187 categories. These categories are ordered from least to most 188 rigorous. 190 o Does the AS_PATH specified actually exist as a path in the network 191 topology and, based on the AS_PATH, is it possible to traverse 192 that path to reach a given prefix? This AS_PATH Feasibility Check 193 will be referred to later in this document. 195 o Has the UPDATE actually traveled via the path in the UPDATE? 197 3. Underlying Assumptions regarding BGP 199 In order to properly identify security requirements it is important 200 to articulate the fundamental aspects of BGP as related to security 201 requirements. The following list presents the basic parameters and 202 application concepts of BGP that are assumed by this document. 204 o Peer Communication: BGP traffic travels over TCP between peers, so 205 BGP speakers assume the data delivery guarantees of TCP in a 206 benign environment. This includes ordered, error-free delivery of 207 application traffic from a peer identified by an IP address, plus 208 integrity of the control aspects of TCP. From a security 209 perspective, these guarantees need to be enforced in the context 210 of possible active wiretapping. 212 o Routing and Reachability: BGP is a protocol used to convey routing 213 and reachability information both internal and external to an 214 Autonomous System. Typically, interior BGP (iBGP) is used to 215 distribute prefix reachability information in conjunction with an 216 Interior Gateway Protocol (IGP) and is used by a distinct network 217 administrative entity to convey internal routing policy regarding 218 external and internal information. Exterior BGP (eBGP) is 219 typically used to distribute route/prefix reachability information 220 between two distinct routing entities and is used to signal eBGP 221 preferences and policy decisions on an inter-AS basis. 223 o Inter-AS UPDATE Message assumptions: When an AS distributes 224 reachability information to a peer it is done with the intent of 225 affecting routing decisions by the peer. For example, with regard 226 to a block of addresses represented by a prefix, AS-A may send 227 peer AS-B an advertisement which is less specific (shorter in 228 length of mask) and peer AS-C a more specific advertisement 229 (longer mask). This prefix distribution decision may have been 230 made to provide a means for failure resolution between AS-A and 231 AS-C, i.e., to provide a backup path for the addresses in 232 question. However, it should be noted that while AS-A tries to 233 influence the routing decisions of AS-B and downstream ASes, AS-A 234 is only providing inputs to a local decision by AS-B, a decision 235 that is ultimately controlled by AS-B's local policy over which 236 AS-A has no control. UPDATE messages are sent between AS peers 237 with the tacit authorization for those messages to be forwarded to 238 others. A notable exception to this assumption is the use of 239 policy-based mechanisms between peers such as the NO-EXPORT 240 community. It is important to note that an UPDATE message itself 241 generally is not re-transmitted. Instead, an UPDATE message is 242 regenerated continually as it passes from BGP speaker to BGP 243 speaker. Furthermore, UPDATE messages have no mechanism to 244 indicate freshness (e.g., timestamps or sequence numbers). This 245 implies that messages may appear valid at any point in the life of 246 a BGP peering session. While the AS_PATH information is typically 247 transitive it is, currently, not clearly mandated and many times 248 is modified for various utilitarian reasons. 250 o It is important to note that while preferences regarding routing 251 can be explicitly managed with direct peers it is markedly more 252 difficult to influence routing decisions by ASes that are not 253 directly adjacent. 255 o Inter-AS withdrawal message assumptions: The processing model of 256 BGP RFC4271 [RFC4271] indicates that only the peer advertising 257 NLRI information may withdraw it. There are several instances 258 where a withdrawal may occur. Typical reasons for withdrawal 259 include the determination of a better path, peer session failure, 260 or local policy change. There is no specified mechanism for 261 indicating to a peer the reason for a route withdrawal. Each 262 withdrawal received via a valid peering session must be taken at 263 face value. There is no existing method to ensure that an AS will 264 properly respond to a withdrawal message, e.g., withdraw the route 265 and send such announcement to its neighbors. Nor do mechanisms 266 exist to ensure that old UPDATES are not re-propagated after a 267 route was withdrawn and before it is legitimately re-advertised. 269 o AS_PATH assumptions: Aside from the use of AS_SET, the AS_PATH is 270 defined as an ordered list of the Autonomous Systems that an 271 UPDATE has traversed. The rightmost AS in the list is understood 272 to be the originator of the BGP announcement. Specifications 273 state that the AS routing graph MUST be loop free. This indicates 274 that UPDATES received from an external peer which contain the 275 local AS will be rejected. Prepending one or more instances of an 276 AS number on inbound advertisements (where the external peer's AS 277 number is prepended) and outbound advertisements (where the local 278 AS number is prepended) is a commonly used method to bias routing. 279 Prepending a peer AS number on inbound UPDATEs is employed for 280 biasing internal routing and forwarding management while 281 prepending one's own AS number on outbound advertisement is 282 typically used to bias forwarding and routing changes in external 283 networks. The latter practice is explicitly permitted by RFC4271 284 [RFC4271], but the former is not. Some operators, insert a remote 285 AS number in an UPDATE, in order to cause the UPDATE to be dropped 286 by that AS so that traffic will not traverse a given path. Though 287 this practice appears to run counter to the design of BGP, 288 anecdotal evidence is that its use is not totally insignificant. 289 While such a practice can be beneficial to legitimate operators, 290 it presents a strong potential for misuse. A proposed security 291 system SHOULD address how to either address this concern or give 292 specific information on this topic for consideration by the 293 Operational community. 295 o Route Origination: BGP speakers may originate routes based on 296 either configured internal data or on data received from peers via 297 UPDATES. An Autonomous System SHOULD only originate a prefix to 298 its external peers if that prefix has been allocated to the 299 administrators of that system, or if authorized by the prefix 300 holder. 302 o Originating a route without the ability to forward the traffic 303 associated with that route is, in most cases, in conflict with the 304 intent of the BGP specification, notable exceptions include: 306 * Deployments that make use of route servers which are separate 307 from forwarding devices 309 * Deployments that use the temporary propagation of prefixes in 310 order to effectively block high bandwidth attacks (e.g., DDoS) 311 against specific IP addresses (and the associated 312 oversubscription of resources) 314 o Aggregation and de-aggregation: According to RFC4271 [RFC4271], if 315 a BGP speaker chooses to aggregate a set of more specific prefixes 316 into a less specific prefix then the ATOMIC_AGGREGATE attribute 317 SHOULD be set. This creates a significant challenge for solutions 318 to secure BGP because some origination information is removed 319 (i.e. the more-specific information which triggered the generation 320 of the aggregate). Proposed solutions MUST indicate how 321 aggregation will be accommodated. 323 4. Operational Requirements 325 We have determined, through discussion with several large 326 internetwork operators and equipment vendors, that the following 327 attributes are important to the ongoing performance of interdomain 328 routing systems such as BGP. 330 4.1. Convergence speed 332 Convergence speed is a major concern to many operators of large scale 333 internetworking systems. Networks, and internetworks, are carrying 334 ever increasing amounts of information that is time and delay 335 sensitive; increasing convergence times can adversely affect the 336 usability of the network, and the ability of an internetwork to grow. 337 BGP's convergence speed, with a security system in operation, SHOULD 338 strive towards equivalence to BGP running without the security system 339 in operation. This includes the preservation of optimizations 340 currently used to produce acceptable convergence speeds on current 341 hardware, including UPDATE packing, peer groups, etc. Two types of 342 verification MAY be offered for the NLRI and the AS_PATH in order to 343 allow for a selection of optimizations: 345 o Contents of the UPDATE message SHOULD be authenticated in real- 346 time as the UPDATE message is processed. 348 o The route information base MAY be authenticated periodically or in 349 an event-driven manner by scanning the route-table data and 350 verifying the originating AS and the validity of the AS_PATH list. 352 All BGP implementations that implement security MUST utilize at least 353 one of the above methods for validating routing information. Real 354 time verification is preferred in order to prevent transient failures 355 based on periodic or event-driven scan intervals. See the section on 356 "Local controls ..." below for more discussion. 358 It is recognized that achieving all of these goals might prove very 359 difficult or even impossible. 361 4.2. Incremental deployment 363 It will not be feasible to deploy a newly secured BGP protocol 364 throughout the public Internet instantaneously. It also may not be 365 possible to deploy such a protocol to all routers in a large AS at 366 one time. Any proposed solution MUST support an incremental 367 deployment which will provide some benefit for those who participate. 368 Because of this, there are several requirements that any proposed 369 mechanism to secure BGP must consider. 371 o A BGP security mechanism MUST enable each BGP speaker to configure 372 use of the security mechanism on a per-peer basis. 374 o A BGP security mechanism MUST provide backward compatibility in 375 the message formatting, transmission, and processing of routing 376 information carried through a mixed security environment. Message 377 formatting in a fully secured environment MAY be handled in a non- 378 backward compatible fashion though care must be taken to ensure 379 UPDATES can traverse intermediate routers which don't support the 380 new format. 382 o In an environment where both secured and non-secured systems are 383 interoperating a mechanism MUST exist for secured systems to 384 identify whether an originator intended the information to be 385 secured. 387 o Proposed solutions MUST provide comment and analysis of what 388 security services the solution will provide in the case of 389 incremental deployment scenarios (e.g, contiguous islands, non- 390 contiguous islands, universal deployment). 392 o In an environment where secured service is in the process of being 393 deployed a mechanism MUST exist to support a transition free of 394 service interruption (caused by the deployment per se). 396 4.3. Conditions for initialization 398 A key factor in the robust nature of the existing internal and 399 external relationships maintained in today's Internet is the ability 400 to maintain and return to a significantly converged state without the 401 need to rely on systems external to the routing system (the equipment 402 that is performing the forwarding). In order to ensure the rapid 403 initialization and/or return to service of failed nodes it is 404 important to reduce reliance on these external systems to the 405 greatest extent possible. Therefore, proposed systems SHOULD NOT 406 require connections to external systems, beyond those directly 407 involved in peering relationships, in order to return to full 408 service. Proposed systems MAY require post initialization 409 synchronization with external systems in order to synchronize 410 security information. 412 4.4. Local controls for secure UPDATE acceptance 414 Each secured environment (e.g., public Internet vs. private 415 internetwork) may have different metrics of what is acceptable or 416 unacceptable with regard to routing security. In environments that 417 require strict security it may not be acceptable to temporarily route 418 to a destination while waiting for path validation to be performed. 419 However, in many environments the rapidity of route installation may 420 be of paramount importance, e.g., in order to facilitate the common 421 occurrence of route withdrawal due to network failure. Based on the 422 two divergent requirements, the following criteria apply: 424 o The security system MUST support a range of possible outputs for 425 local determination of the trust level for a specific route so 426 that routing preference and policy can be applied to its inclusion 427 in the RIB. Any given route should be trustable to a locally 428 configured degree, based on the completeness of security 429 information with a received UPDATE and other factors. However, 430 experience in the security community suggests that trying to 431 assign trust ratings to inputs to a decision process usually adds 432 considerable complexity to the management of the process. This 433 complexity, in turn, may undermine the security offered by the 434 process. 436 o The security system SHOULD allow the operator to determine whether 437 speed of convergence is more important than security, or whether 438 security is more important than the speed of convergence. This 439 facilitates the incremental deployment of security on systems not 440 designed to support increased processing requirements imposed by 441 the security system. 443 4.5. Processing on Routers 445 The introduction of mechanisms to improve routing security will 446 generally increase the processing performed by a router. The 447 increased processing typically will result from additional checks 448 performed to determine the validity of UPDATEs, especially if these 449 checks entail cryptographic operations. Since currently deployed 450 routers generally do not have hardware to accelerate cryptographic 451 operations, these operations could impose a significant processing 452 burden under some circumstances. Thus proposed solutions should be 453 evaluated carefully with regard to the processing burden they may 454 impose, since deployment may be impeded if network operators perceive 455 that a solution will impose a processing burden which either: 457 o provokes substantial capital expense, or 459 o threatens to destabilize routers. 461 Given the pervasive number of BGP-speaking routers in a typical ISP 462 deployment, solutions can increase their appeal by minimizing the 463 burden imposed on all BGP routers in favor of confining significant 464 work loads to a relatively small number of devices. 466 Optional features or increased assurance that provokes more pervasive 467 processing load MAY be made available for deployments where the 468 additional resources are economically justifiable. 470 Some statement as to the expected performance measures and scaling as 471 a function of prefixes, peers, NLRI, etc. MUST be included with any 472 proposed solution. 474 4.6. Configuration on Routers 476 It is undesirable to have long or very detailed configuration on 477 routers, especially it needs to be synchronized on all of them. Long 478 configuration makes operating the device more difficult, and having 479 to do very detailed configuration may hinder the adoption of the 480 security solution; it should be possible to "just start using it" if 481 possible. 483 As above, a statement as to the expected configuration burden as a 484 function of routers, peers, NLRI, ASNs, etc. MUST be included with 485 any proposed solution. Additionally, some consideration SHOULD be 486 given and statement made as to frequency of changes in the case of 487 dynamic data. 489 5. Infrastructure Requirements 491 BGP security mechanisms MAY make use of a security infrastructure to 492 distribute authenticated data that is an input to routing decisions. 493 Such data may be needed to verify whether a given AS is authorized to 494 originate an advertisement for a specified prefix, whether an given 495 organization is the recognized holder of a block of address space or 496 of an AS number, etc. Any infrastructure used to distribute data in 497 support of BGP security is subject to the following criteria: 499 o It MUST be resilient to attacks on the integrity of the data it 500 contains. 502 o It MUST enable network operators to verify the entity which 503 originated the data. 505 o It MUST be sufficiently available so as to not degrade the 506 existing pace of network operations. 508 o It SHOULD not introduce new organizational entities that have to 509 be trusted in order to establish the authenticity of the data. 511 6. The Trust Model 513 In discussion with the operations community, concerns have emerged 514 regarding the viability of a security system that requires agreement 515 on a trust model dependent on a single root. Current operational 516 practice has many providers engaging in bilateral agreements and 517 preserving the primacy of local policy choices. The viability of a 518 solution may well rest on the business imperatives of the provider 519 community who may be unwilling to surrender their perceived autonomy 520 or unable to come to communal agreement on this topic. 522 In other environments, deployments may require an authority which has 523 been selected by law or other institutional mandate. Moreover, these 524 two deployment types (single-rooted hierarchy or arbitrary 525 association) may "touch" (i.e. be part of the same co-extensive BGP 526 topology). 528 Solutions MUST account for these differing types of deployments. 530 If two internetworks using differing trust models are interconnected 531 they MUST be able to interoperate using locally determined levels of 532 assurance to compensate for differences in these trust models. Some 533 acknowledgement is made that this requirement might render it 534 difficult to discern an attack from a difference in trust model or 535 implementation. Any proposed solution MUST mitigate this risk. 537 7. The AS_PATH Attribute and NLRI Authentication 539 BGP distributes routing information across the Internet (between BGP 540 speakers) using BGP UPDATE messages. The UPDATE message contains 541 withdrawn routes, path attributes and NLRI (Network Layer 542 Reachability Information, synonymous with advertised prefix(es)). 543 For the remainder of this section, we will focus on the AS_PATH 544 Attribute and the NLRI. Attributes such as MED are not transitive 545 and, as such, are protected by BGP session security. 547 The AS_PATH for specific prefixes may be protected in any proposed 548 security system in four ways, outlined below. 550 o Authorization of Originating AS: For the purposes of authorization 551 of the originating AS, authorization means that it MUST be 552 possible to verify that the origin AS has been authorized to 553 originate the route by the prefix holder(s). 555 o Announcing AS Check: For all BGP peers, a BGP Implementation MUST 556 ensure that the first element of the AS_PATH list corresponds to 557 the locally configured AS of the peer from which the UPDATE was 558 received. 560 o AS_PATH Feasibility Check: The AS_PATH list may correspond to a 561 valid list of autonomous systems according to the first 562 verification category listed in the "Areas to Secure" Section 563 above. Further study will determine the extent to which this is a 564 security requirement. 566 o Update Transit Check: Routing information carried through BGP may 567 include information that can be used to verify the re- 568 advertisement or modification by each autonomous system through 569 which the UPDATE has passed. This check is more rigorous than the 570 "valid list of autonomous systems" above. Further study will 571 determine the extent to which this is a security requirement. 573 The results of all of these checks should be made available to 574 network operators. Each network operator will decide, on a local 575 basis, which of these checks to enable. 577 There are many ways in which any difference between the speed of 578 prefix/AS path attribute propagation and the availability of the 579 information needed to validate the prefix/AS_PATH attribute 580 information can be exploited to attack the routing system on a 581 transient basis. These types of attacks primarily exploit the time 582 it takes to follow the withdrawal of a route via an UPDATE. As a 583 result of this potential for temporary disruption, BGP security 584 solutions MUST be capable of distributing security information at the 585 same rate as the BGP announcements and withdrawals propagate. 587 All data needed by BGP routers to evaluate the validity of an 588 advertisement MUST be made available to the routers in a timeframe 589 consistent with the rate at which advertisement characteristics 590 change. Two examples are: 592 o the distribution of information about the AS(es) authorized to 593 advertise a given block of IP addresses, 595 o the distribution of information about connectivity between 596 autonomous systems and about autonomous system policies 598 Note that in today's operational Internet, the first two pieces of 599 information, or their analogues, are not a part of the BGP routing 600 system per se (e.g., information in Routing or Address registries.) 601 They are consulted by most operators on an irregular basis and are 602 not consulted in real time by the routing system. Policy information 603 that is explicitly carried in the routing system is inconsistently 604 expressed and consulted in Routing registries by operators. For 605 instance, most providers are reticent to define their interconnection 606 arrangements as transit or non-transit in Routing registries; some 607 may do so, most do not. However, the ability to change inter-AS 608 traffic flows in real time is an important feature of the current 609 Internet. 611 8. Address Allocation and Advertisement 613 As part of the regular operation of the Internet, addresses allocated 614 to one organization may be, and are quite commonly, advertised by 615 ASes belonging to other organizations. Common reasons for this 616 practice include multi-homing and route reduction for the purposes of 617 resource conservation (e.g., aggregation). There are two modes of 618 delegation: 620 o A BGP speaker and listener have chosen to restrict the number of 621 received prefixes for the listener. The listener has chosen to 622 honor route announcements sent in a summary fashion by the 623 speaker. 625 o Address space that is being delegated is part of a larger 626 allocation that is held by an autonomous system. The holder then 627 delegates the smaller block to another AS for purposes of 628 advertisement. This mode is commonly observed in multi-homing. 630 These two modes lead to a single common requirement: Any BGP Security 631 solution MUST support the ability of an address block holder to 632 declare (in a secure fashion) the AS(es) that the holder authorizes 633 to originate routes to its address block(s) or any portion thereof 634 regardless of the relationship of the entities. 636 An associated delegation criteria is the requirement to allow for 637 non-BGP stub networks. As a result, all secured BGP implementations 638 MUST allow for the contemporaneous origination of a route for a 639 prefix by more than one AS. 641 9. Logging 643 In order to facilitate auditing and troubleshooting, a logging 644 capability MUST be implemented that will indicate both negative and 645 positive event behaviors. This data SHALL be for consumption of the 646 AS operating the device that is producing the logs. Further, the 647 information MAY be combined with data from other is ASes or devices 648 with different implementations within the same AS for purposes of 649 event correlation and tracking. Here follow some considerations in 650 this regard: 652 o The data generated by logging may be very large depending on the 653 number of peers, the number of prefixes received, the 654 authentication model used, and routing policies. As such, 655 efficient data structures and storage mechanisms MUST be developed 656 to allow for an effective means of reproducing incidents and 657 outages 659 o Path and NLRI attributes MUST be logged using a standard format. 660 The format MUST be scalable with the amount of data logged and the 661 frequency of log generation. The frequency of log generation 662 should be controllable by the operator. The logging mechanisms 663 for the tracked information MUST be standardized across all 664 platforms. Logging ability both on and off line is considered 665 highly desirable. 667 10. NLRI and Path Attribute Tracking 669 The ability for a receiver to know the identity of each AS that 670 originates and/or forwards a routing UPDATE is a desirable trait. In 671 order to rapidly identify attack points and parties at fault for 672 route table disruption, it is important to be able to track and log 673 prefix origination information along with associated security 674 information. 676 This capability can be afforded by implementation of the 677 aforementioned directive that any security system SHOULD provide a 678 method to allow the receiver of an UPDATE to verify that the 679 originator is actually authorized to originate the update, and that 680 the AS's listed in the AS_PATH actually forwarded the update. 682 11. Transport Layer Protection 684 Transport protection is an important aspect of BGP routing protocol 685 security. The potential to create a linked transport/NLRI/AS_PATH 686 authentication mechanism should not be overlooked and may provide for 687 the accelerated deployment of a BGP security system. A detailed 688 treatment of this topic is being developed in BGP Session Security 689 Requirements [BGP Session Security Requirements]. 691 Any proposed security mechanism MUST include provisions for securing 692 both internal BGP and external BGP peering sessions. 694 12. Key Management 696 Current implementations and deployments of TCP-MD5 [RFC2385] exhibit 697 serious shortcomings with regard of key management as described in 698 RFC 3562 [RFC3562]. 700 Key management can be especially onerous for operators. The number 701 of keys required and the maintenance of keys (issue/revoke/renew) has 702 had an additive effect as a barrier to deployment. Thus automated 703 means of managing keys, to reduce operational burdens, MUST be 704 available in proposed BGP security systems. These security systems 705 MUST be resistant to compromise of session-level or device-level 706 keys, i.e., the security implications of such compromises MUST be 707 limited. 709 13. IANA Considerations 711 This document asks nothing of IANA. 713 14. Security Considerations 715 This document describes requirements for securing BGP as envisioned 716 by the community. Its completeness is likely not exhaustive but 717 represents the broadest consensus. As the understanding of the 718 issues and possible residual vulnerabilities are refined, so these 719 requirements may be revised in successor documents. 721 15. References 723 15.1. Normative References 725 [RFC2119] Bradner, "RFC 2119 - Key words for use in RFCs to Indcate 726 Requirements Levels", March 1997. 728 [RFC4271] Rekhter, Li, and Hares, "RFC 4271 - A Border Gateway 729 Protocol 4 (BGP-4)", October 2005. 731 15.2. Informative References 733 [RFC2196] Fraser, "RFC 2196 - Site Security Handbook", 734 September 1997. 736 [RFC3552] Rescorla, Korver, and Internet Architecture Board, "RFC 737 3552 - Guidelines for Writing RFC Text on Security 738 Considerations", July 2003. 740 [RFC2385] Heffernan, "RFC 2385 - Protection of BGP Sessions via the 741 TCP MD5 Signature Option", August 1998. 743 [RFC3562] Leech, "RFC 3562 - Key Management Considerations for the 744 TCP MD5 Signature Option", July 2003. 746 [BGP Session Security Requirements] 747 Behringer, "BGP Session Security Requirements 748 (draft-ietf-rpsec-bgp-session-sec-req-01.txt)", 749 August 2007. 751 1. Acknowledgements 753 The following individuals contributed to the development and review 754 of this draft. Steve Kent, Russ White, Sandy Murphy, Jeff Haas, Bora 755 Akyol, Susan Hares, Mike Tibodeau, Thomas Renzy, Kaarthik Sivakumar, 756 Tao Wan, Radia Perlman, Pekka Savola, Iljitsch van Beijnum, Curtis 757 Villamizar, Joe Touch, Geoff Huston, and Merike Kaeo. 759 This draft was developed based on conversations with various network 760 operators including Chris Morrow, Jared Mauch, Tim Battles, and Ryan 761 McDowell. 763 Authors' Addresses 765 Blaine Christian (editor) 766 Microsoft 768 Tony Tauber (editor) 769 Comcast 770 27 Industrial Avenue 771 Chelmsford, MA 01824 772 US 774 Email: ttauber@1-4-5.net 776 Full Copyright Statement 778 Copyright (C) The IETF Trust (2008). 780 This document is subject to the rights, licenses and restrictions 781 contained in BCP 78, and except as set forth therein, the authors 782 retain all their rights. 784 This document and the information contained herein are provided on an 785 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 786 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 787 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 788 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 789 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 790 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 792 Intellectual Property 794 The IETF takes no position regarding the validity or scope of any 795 Intellectual Property Rights or other rights that might be claimed to 796 pertain to the implementation or use of the technology described in 797 this document or the extent to which any license under such rights 798 might or might not be available; nor does it represent that it has 799 made any independent effort to identify any such rights. Information 800 on the procedures with respect to rights in RFC documents can be 801 found in BCP 78 and BCP 79. 803 Copies of IPR disclosures made to the IETF Secretariat and any 804 assurances of licenses to be made available, or the result of an 805 attempt made to obtain a general license or permission for the use of 806 such proprietary rights by implementers or users of this 807 specification can be obtained from the IETF on-line IPR repository at 808 http://www.ietf.org/ipr. 810 The IETF invites any interested party to bring to its attention any 811 copyrights, patents or patent applications, or other proprietary 812 rights that may cover technology that may be required to implement 813 this standard. Please address the information to the IETF at 814 ietf-ipr@ietf.org.