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