idnits 2.17.1 draft-ietf-rpsec-bgpsecrec-03.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 689. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 666. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 673. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 679. ** 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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 237: '...tate that the AS routing graph MUST be...' RFC 2119 keyword, line 255: '... security system SHOULD address how to...' RFC 2119 keyword, line 261: '...utonomous System SHOULD only originate...' RFC 2119 keyword, line 280: '... the ATOMIC_AGGREGATE attribute SHOULD...' RFC 2119 keyword, line 300: '...a security system in operation, SHOULD...' (42 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 (October 25, 2005) is 6757 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) ** Downref: Normative reference to an Informational RFC: RFC 2196 (ref. '1') ** Obsolete normative reference: RFC 1771 (ref. '3') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2385 (ref. '4') (Obsoleted by RFC 5925) ** Downref: Normative reference to an Informational RFC: RFC 3562 (ref. '5') ** Obsolete normative reference: RFC 3682 (ref. '6') (Obsoleted by RFC 5082) Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: April 28, 2006 Comcast 6 October 25, 2005 8 BGP Security Requirements 9 draft-ietf-rpsec-bgpsecrec-03 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 April 28, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 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 securing peering 48 relationships between BGP speakers, and authenticating the routing 49 information carried within BGP. 51 1. Introduction 53 1.1. System Description 55 BGP is described in RFC1771 [3], and, more recently, in an updated 56 specification,RFC4271 [7], as a path-vector routing protocol. BGP 57 speakers typically exchange information about reachable destinations 58 (expressed as address prefixes) in an internetwork through pair-wise 59 peering sessions. Once this information has been exchanged, each BGP 60 speaker locally determines a loop free path to each reachable 61 destination, based on local policy or policy indicators which may be 62 carried in the UPDATE, and the AS_PATH data carried in the BGP UPDATE 63 messages. 65 Each BGP speaker represents an Autonomous System (AS). All of the 66 BGP speakers within an AS operate under a common administrative 67 policy. 69 1.2. Threats 71 Violations of security for network and information systems generally 72 fall under one of the three categories as defined in RFC 2196 [1]: 74 o Unauthorized access to resources and/or information 76 o Unintended and/or unauthorized disclosure of information 78 o Denial of service 80 A number of attacks can be realized which, if exploited, can lead to 81 one of the above mentioned security violations. Attacks against 82 communications are typically classified as passive or active 83 wiretapping attacks. Passive attacks are ones where an attacker 84 simply observes information traversing the network, violating 85 confidentiality or identifying a means of engaging in further 86 attacks. Active attacks are ones where the attacker modifies data in 87 transit. Such attacks include replay attacks, message insertion, 88 message deletion, and message modification attacks. Some attacks may 89 be effected by sending data from any where in the Internet. Other 90 active attacks require a "man-in-the-middle" capability, i.e., the 91 attacker must be in a position where traffic passes through an 92 attacker-controlled device. Attacks against BGP may be used by an 93 attacker to facilitate a wide variety of active or passive 94 wiretapping attacks against subscriber traffic. 96 Attacks that do not involve direct manipulation of BGP, and the 97 information contained within BGP, are outside the scope of this 98 document. 100 Because ASes are autonomous in their operation, it is not possible to 101 mandate secure operation by all ASes, nor would it be advisable to 102 assume such operation. Thus the primary goal of BGP security 103 measures is to provide data to AS operators to enable BGP speakers to 104 reject advertisements (UPDATE messages) that are not valid. For 105 example, UPDATE messages that represent erroneous binding of prefixes 106 to an origin AS, or that advertise invalid paths (as defined later in 107 this document) should be rejected. Because BGP peering sessions take 108 place in the context of TCP, the authentication and integrity 109 guarantees usually association with TCP need to be provided in the 110 face of possible active wiretapping attacks. Using the terminology 111 established in RFC 3552 [2], these peering sessions should be 112 afforded data origin and peer entity authentication and connection- 113 oriented integrity. 115 Security for subscriber traffic is outside the scope of this 116 document, and of BGP security in general. IETF standards for 117 subscriber data security, e.g., IPsec, TLS, and S/MIME should be 118 employed for such purposes. While adoption of BGP security measures 119 may preclude certain classes of attacks on subscriber traffic, these 120 measures are not a substitute for use of subscriber-based security 121 mechanisms of the sort noted above. 123 1.3. Areas to secure 125 There are two primary points where BGP may be secured; the data 126 payload of the protocol and the data semantics of the protocol. 128 The session between two BGP speakers can be secured such that the BGP 129 data received by the BGP speakers can by cryptographically verified 130 to have been transmitted by the peer BGP speaker and not a replay of 131 previously transmitted legitimate data. There are several existing 132 IETF standards to choose from to ensure that this system functions 133 with greater effectiveness than the current system. An example might 134 be IPsec. Some in the Operator community have expressed concerns 135 that a requiring cryptographic validation could open another vector 136 for a denial-of-service attack by flooding the processor with bogus 137 packets which must be cryptographically invalidated before being 138 discarded. 140 There are also several questions we can ask about the information 141 contained within a received UPDATE. 143 o Is the originating Autonomous System authorized to propagate the 144 prefix we have received? 146 o Does the AS_PATH, received via an UPDATE, represent a valid path 147 through the network? 149 The verification of AS_PATH validity falls into two distinct 150 categories. These categories are ordered from least to most 151 rigorous. 153 o Does the AS_PATH specified actually exist as a path in the network 154 topology and, based on the AS_PATH, is it possible to traverse 155 that path to reach a given prefix? This AS_PATH Feasibility Check 156 will be referred to later in this document. 158 o Has the UPDATE actually traveled the path? 160 2. Underlying Assumptions regarding BGP 162 In order to properly identify security requirements it is important 163 to articulate the fundamental aspects of BGP as related to security 164 requirements. The following list presents the basic parameters and 165 application concepts of BGP that are assumed by this document. 167 o Peer Communication: BGP traffic travels over TCP between peers, so 168 BGP speakers assume the data delivery guarantees of TCP in a 169 benign environment. This includes ordered, error-free delivery of 170 application traffic from a peer identified by an IP address, plus 171 integrity of the control aspects of TCP. From a security 172 perspective, these guarantees need to be enforced in the context 173 of possible active wiretapping. 175 o Routing and Reachability: BGP is a protocol used to convey routing 176 and reachability information both internal and external to an 177 Autonomous System. Typically, interior BGP (iBGP) is used to 178 distribute prefix reachability information in conjunction with an 179 Interior Gateway Protocol (IGP) and is used by a distinct network 180 administrative entity to convey internal routing policy regarding 181 external and internal information. Exterior BGP (eBGP) is 182 typically used to distribute route/prefix reachability information 183 between two distinct routing entities and is used to signal eBGP 184 preferences and policy decisions. 186 o Inter-AS UPDATE Message assumptions: When an AS distributes 187 reachability information to a peer it is done with the intent of 188 affecting routing decisions by the peer. For example, with regard 189 to a block of addresses, AS-A may send peer AS-B a less specific 190 advertisement and peer AS-C a "more" specific advertisement. This 191 prefix distribution decision may have been made to provide a means 192 for failure resolution between AS-A and AS-C, i.e., to provide a 193 backup path for the addresses in question. However, it should be 194 noted that while AS-A tries to influence the routing decisions of 195 AS-B and downstream ASes, AS-A is only providing inputs to a local 196 decision by AS-B, a decision that is very much influenced by 197 AS-B's local policy over which AS-A has no control. Update 198 messages are sent between AS peers with the implicit assumption 199 that those messages will be forwarded to others. A notable 200 exception to this assumption is the use of policy-based mechanisms 201 between peers such as the NO-EXPORT community. It is important to 202 note that an UPDATE message itself generally is not re- 203 transmitted. Instead, the specific UPDATE message is regenerated 204 continually as it passes from BGP speaker to BGP speaker. 205 Furthermore, UPDATE messages have no mechanism for freshness (e.g. 206 timestamps or sequence numbers). This indicates that messages may 207 appear valid at any point in the life of a BGP peering session. 209 While the AS_PATH information is typically transitive it is, 210 currently, not clearly mandated and many times is removed for 211 various utilitarian reasons. 213 o It is important to note that while preferences regarding routing 214 can be explicitly managed with direct peers it is markedly more 215 difficult to influence routing decisions by ASes that are not 216 directly adjacent. 218 o Inter-AS withdrawal message assumptions: The processing model of 219 BGP RFC4271 [7] indicates that only the peer advertising NLRI 220 information may withdraw it. There are several instances where a 221 withdrawal may occur. Typical reasons for withdrawal include the 222 determination of a better path, peer session failure, or local 223 policy change. There is no specified mechanism for indicating to 224 a peer the reason for a route withdrawal. Each withdrawal 225 received via a valid peering session must be taken at face value. 226 There is no existing method to ensure that an AS will properly 227 respond to a withdrawal message, e.g. withdraw the route and send 228 such announcement to its neighbors. Nor do mechanisms exist to 229 ensure that old UPDATES are not re-propagated after a route was 230 withdrawn before it is legitimately re-advertised. 232 o AS_PATH assumptions: Aside from the use of AS_SET, the AS_PATH is 233 typically considered to be an ordered list of the Autonomous 234 Systems that an UPDATE has traversed. In most cases the rightmost 235 AS in the list is the origin AS, or at least the AS responsible 236 for the announcement of the NLRI information contained in the 237 UPDATE. Specifications state that the AS routing graph MUST be 238 loop free. This indicates that UPDATES received from an external 239 peer which contain the local AS will be rejected. Prepending one 240 or more instances of an AS number on inbound advertisements (where 241 the external peer's AS number is prepended) and outbound 242 advertisements (where the local AS number is prepended) is a 243 commonly used method to bias routing. Prepending a peer AS number 244 on inbound UPDATEs is employed for biasing internal routing and 245 forwarding management while prepending one's own AS number on 246 outbound advertisement is typically used to bias forwarding and 247 routing changes in external networks. The latter practice is 248 explicitly permitted by the BGP specification while the former is 249 not. Some operators, insert a remote AS number in an UPDATE, in 250 order to cause the UPDATE to be dropped by that AS so that traffic 251 will not traverse a given path. Though this practice appears to 252 be unintended in the design in BGP, anecdotal evidence is that its 253 use is not totally insignificant. While such a practice can be 254 beneficial to legitimate operators, it presents a strong potential 255 for misuse. A proposed security system SHOULD address how to 256 either address this concern or give specific information on this 257 topic for consideration by the Operational community. 259 o Route Origination: BGP speakers may originate routes based either 260 configured internal data or via data received from peers via 261 UPDATES. An Autonomous System SHOULD only originate a prefix to 262 its external peers if that prefix has been allocated to the 263 administrators of that system, or if authorized by the prefix 264 holder. 266 o Originating a route without the ability to forward the traffic 267 associated with that route is, in most cases, in conflict with the 268 intent of the BGP specification, notable exceptions include: 270 * Deployments that make use of route servers which are separate 271 from forwarding devices 273 * Deployments that use the propagation of prefixes in order to 274 effectively block high bandwidth attacks (e.g. DDoS) against 275 specific IP addresses (and the associated oversubscription of 276 resources) 278 o Aggregation and de-aggregation: According to RFC4271 [7], if a BGP 279 speaker chooses to aggregate a set of more specific prefixes into 280 a less specific prefix then the ATOMIC_AGGREGATE attribute SHOULD 281 be set. This creates a significant potential loophole in an 282 attempt to secure BGP based on the RFC specifications because some 283 orignation information is removed (i.e. the more-specific 284 information which triggered the generation of the aggregate). 286 3. Operational Requirements 288 We have determined, through discussion with several large 289 internetwork operators and equipment vendors, that the following 290 attributes are important to the ongoing performance of interdomain 291 routing systems such as BGP. 293 3.1. Convergence speed 295 Convergence speed is a major concern to many operators of large scale 296 internetworking systems. Networks, and internetworks, are carrying 297 ever increasing amounts of information that is time and delay 298 sensitive; increasing convergence times can adversely affect the 299 usability of the network, and the ability of an internetwork to grow. 300 BGP's convergence speed, with a security system in operation, SHOULD 301 be equivalent to BGP running without the security system in 302 operation. This includes the preservation of optimizations currently 303 used to produce acceptable convergence speeds on current hardware, 304 including UPDATE packing, peer groups, etc. Two types of 305 verification MAY be offered for the NLRI and the AS_PATH in order to 306 allow for a selection of optimizations: 308 o Contents of the UPDATE message SHOULD be authenticated in real- 309 time as the UPDATE message is processed. 311 o The route information base MAY be authenticated periodically or in 312 an event-driven manner by scanning the route-table data and 313 verifying the originating AS and the validity of the AS_PATH list. 315 All BGP implementations that implement security MUST utilize at least 316 one of the above methods for validating routing information. Real 317 time verification is preferred in order to prevent transitive 318 failures based on periodic or event-driven scan intervals. 320 It is recognized that achieving these goals might prove very 321 difficult or even impossible. 323 3.2. Incremental deployment 325 It will not be feasible to deploy a newly secured BGP protocol 326 throughout the public Internet instantaneously. It also may not be 327 possible to deploy a such a protocol to all routers in a large AS at 328 one time. Because of this, there are several requirements that any 329 proposed mechanism to secure BGP must consider. 331 o A BGP security mechanism MUST enable each BGP speaker to configure 332 use of the security mechanism on a per-peer basis. 334 o A BGP security mechanism MUST provide backward compatibility in 335 the message formatting, transmission, and processing of routing 336 information carried through a mixed security environment. Message 337 formatting in a fully secured environment MAY be handled in a non- 338 backward compatible fashion though care must be taken to ensure 339 when traversing intermediate routers which don't support the new 340 format. 342 o In an environment where both secured and non-secured systems are 343 interoperating a mechanism MUST exist for secured systems to 344 identify whether an originator intended the information to be 345 secured. 347 3.3. Conditions for initialization 349 A key factor in the robust nature of the existing internal and 350 external relationships maintained in today's Internet is the ability 351 to maintain and return to a significantly converged state without the 352 need to rely on systems external to the routing system (the equipment 353 that is performing the forwarding). In order to ensure the rapid 354 initialization and/or return to service of failed nodes it is 355 important to reduce reliance on external systems to the greatest 356 extent possible. Therefore, proposed systems SHOULD NOT require 357 connections to external systems, beyond those directly involved in 358 peering relationships, in order to return to full service. Proposed 359 systems MAY require post initialization synchronization with external 360 systems in order to synchronize security information. 362 3.4. Local controls for secure UPDATE acceptance 364 Each secured environment (e.g. public Internet vs. private 365 internetwork) may have different levels of requirements in terms of 366 what is acceptable or unacceptable. In environments that require 367 strict security it may not be acceptable to temporarily route to a 368 destination while waiting for security verification to be performed. 369 However, in many environments the rapidity of route installation may 370 be of paramount importance, e.g. in order to facilitate the common 371 occurrence of route withdrawal due to network failure. Based on the 372 two divergent requirements, the following criteria apply: 374 o The security system MUST support a range of possible outputs for 375 local determination of the trust level for a specific route so 376 that routing preference and policy can be applied to its inclusion 377 in the RIB. Any given route should be trustable to a locally 378 configured degree, based on the completeness of security 379 information with a received UPDATE and other factors. 381 o The security system SHOULD allow the operator to determine whether 382 speed of convergence is more important than security or security 383 is more important than the speed of convergence. This facilitates 384 the incremental deployment of security on systems not designed to 385 support increased processing requirements imposed by the security 386 system. 388 4. Infrastructure Requirements 390 BGP security mechanisms MAY make use of a security infrastructure to 391 distribute authenticated data that is an input to routing decisions. 392 Such data may be needed to verify whether a given AS is authorized to 393 originate an advertisement for a specified prefix, whether an given 394 organization is the recognized holder of a block of address space or 395 of an AS number, etc. Any infrastructure used to distribute data in 396 support of BGP security is subject to the following criteria: 398 o It MUST be resilient to attacks on the integrity of the data it 399 contains. 401 o It MUST enable network operators to verify the origin of the data. 403 o It MUST be sufficiently available so as to not degrade the 404 existing pace of network operations. 406 o It SHOULD not introduce new organizational entities that have to 407 be trusted in order to establish the authenticity of the data. 409 5. The Trust Model 411 In discussion with the operations community, concerns have emerged 412 regarding the viability of a security system that requires agreement 413 on a trust model dependent on a single root. Current operational 414 practice has many providers engaging in bilateral agreements that 415 grant primacy to local policy choices. The viability of a solution 416 may well rest on the business imperatives of the provider community 417 which may be unwilling to surrender their perceived autonomy or 418 unable to come to communal agreement on this topic. 420 In other environments, deployments may require an authority which has 421 been decided by law or other institutional mandate. Moreover, these 422 two deployment types (single-rooted hierarchy or arbitrary 423 association) may "touch" (i.e. be part of the same co-extensive BGP 424 topology). 426 Solutions MUST account for these differing types of deployments. 428 If two internetworks using differing trust models are interconnected 429 they MUST be able to interoperate using locally determined levels of 430 trust to compensate for differences in their trust models. Some 431 acknowledgement is made that this requirement might render it 432 difficult to discern an attack from a difference in trust model or 433 implementation. Any proposed solution MUST mitigate this risk. 435 6. The AS_PATH Attribute and NLRI Authentication 437 BGP distributes routing information across the Internet (between BGP 438 speakers) using BGP UPDATE messages. The UPDATE message contains 439 withdrawn routes, path attributes and NLRI (Network Layer 440 Reachability Information, synonymous with advertised prefix). For 441 the remainder of this section, we will focus on the AS_PATH Attribute 442 and the NLRI. Attributes such as LOCAL_PREF are not transitive and, 443 as such, are protected by BGP session security. 445 The AS_PATH for specific prefixes may be protected in any proposed 446 security system in four ways: 448 o Authorization of Originating AS: For the purposes of authorization 449 of the originating AS, verifiable means that it MUST be possible 450 to verify that the origin AS has been authorized to originate the 451 route by the prefix holder(s). 453 o Announcing AS Check: For all BGP peers, a BGP Implementation MUST 454 ensure that the first element of the AS_PATH list corresponds to 455 the locally configured AS of the peer from which the UPDATE was 456 received. 458 o AS_PATH Feasibility Check: The AS_PATH list MUST correspond to a 459 valid list of autonomous systems according to the first 460 verification category listed in the "Areas to Secure" Section 461 above. 463 o Update Transit Check: Routing information carried through BGP 464 SHOULD include information that can be used to verify the 465 readvertisement or modification by each autonomous system through 466 which the UPDATE has passed. This check is somewhat more rigorous 467 than the "verifiable list of autonomous systems" above. 469 All of these checks SHOULD be made available to network operators. 470 Each network operator will decide, on a local basis, which of these 471 checks to enable. 473 There are many ways in which a differential between the speed of 474 prefix/AS path attribute propagation and the information validating 475 the prefix/AS_PATH attribute information can be exploited to attack 476 the routing system on a transient basis. These types of attacks 477 primarily exploit the time it takes to follow the withdrawal of a 478 route via an UPDATE. As a result of this potential for temporary 479 disruption, BGP security solutions MUST be capable of distributing 480 security information at the same rate as the BGP announcements and 481 withdrawals propagate. 483 All data needed by BGP routers to evaluate the validity of an 484 advertisement MUST be made available to the routers in a timeframe 485 consistent with the rate at which advertsisements characteristics 486 change. Two examples are: 488 o the distribution of information about the AS(es) authorized to 489 advertise a given block of IP addresses (or an address space), 491 o the distribution of information about connectivity between 492 autonomous systems and about autonomous system policies. 494 Note that in today's operational Internet, the first two pieces of 495 information, or their analogues, are not a part of the BGP routing 496 system per se (e.g. information in Routing or Address registries.) 497 They are consulted by operators on an irregular basis and are not 498 consulted in real time by the routing system. Policy information is 499 explicitly carried in the routing system and inconsistently expressed 500 and consulted by operators. However, the ability to change the 501 connectivity in real time is an important feature of the current 502 Internet. 504 7. Address Allocation and Advertisement 506 As part of the regular operation of the Internet, addresses allocated 507 to one organization may be, and are quite commonly, advertised by 508 different organizations. Common reasons for this practice include 509 multi-homing and route reduction for the purposes of resource 510 conservation (e.g. aggregation). There are two modes of delegation: 512 o A BGP speaker and listener have chosen to restrict the number of 513 received prefixes for the listener. The listener has chosen to 514 honor route announcements sent in a summary fashion by the 515 speaker. 517 o Address space that is being delegated is part of a larger 518 allocation that is held by an autonomous system. The holder then 519 delegates the smaller block to another AS for purposes of 520 advertisement. This mode is commonly observed in multi-homing. 522 These two modes lead to a single common requirement: Any BGP Security 523 solution MUST support the ability of an address block holder to 524 declare (in a secure fashion) the AS(es) that the holder authorizes 525 to originate routes to its address block(s) or any portion thereof 526 regardless of the relationship of the entities. 528 An associated delegation criteria is the requirement to allow for 529 non-BGP stub networks. As a result, all secured BGP implementations 530 MUST allow for the contemporaneous origination of a route for a 531 prefix by more than one AS. 533 8. Logging 535 In order to facilitate auditing and troubleshooting, a logging 536 capability MUST be implemented that will indicate both negative and 537 positive event behaviors. This data SHALL be for consumption of the 538 AS operating the device which is producing the logs. Further, the 539 information MAY be combined with data from other is ASes or devices 540 with different implementations within the same AS for purposes of 541 event correlation and tracking. Here follow some considerations in 542 this regard: 544 o The data generated by logging may be very large depending on the 545 number of peers, the number of prefixes received, the 546 authentication model used, and routing policies. As such, 547 efficient data structures and storage mechanisms MUST be developed 548 to allow for an effective means of reproducing incidents and 549 outages 551 o Path and NLRI attributes MUST be logged using a standard format. 552 The format MUST be scalable with the amount of data logged and the 553 frequency of log generation. The frequency of log generation 554 should be controllable by the operator. The logging mechanisms 555 for the tracked information MUST be standardized across all 556 platforms. Logging ability both on and off line is considered 557 highly desirable. 559 9. NLRI and Path Attribute Tracking 561 The ability for a receiver to know the identity of each AS that 562 originates and/or forwards a routing UPDATE is a desirable trait. In 563 order to rapidly identify attack points and parties at fault for 564 route table disruption, it is important to be able to track and log 565 prefix origination information along with associated security 566 information. 568 This capability can be afforded by implementation of the 569 aforementioned directive that any security system SHOULD provide a 570 method to allow the receiver of an UPDATE to verify that the 571 originator is actually authorized to originate the update, and that 572 the AS's listed in the AS_PATH actually forwarded the update. 574 10. Transport Layer Protection 576 Transport protection is an important aspect of BGP routing protocol 577 security. The potential to create a linked transport/NLRI/AS_PATH 578 authentication mechanism should not be overlooked and may provide for 579 the accelerated deployment of a BGP security system. Current 580 security mechanisms for BGP transport (e.g. TCP-MD5 [4] and GTSM 581 [6]) are inadequate and require significant operator interaction to 582 maintain a respectable level of security. 584 Transport protection systems MAY function as a component of the BGP 585 routing protocol security mechanism. This includes the use of the 586 same key generation/management systems as the rest of the security 587 system. 589 Any proposed security mechanism MUST include provisions for securing 590 both internal BGP and external BGP peering sessions. 592 11. Key Management 594 Current implementations and deployments of TCP-MD5 [4] exhibit 595 serious shortcomings with regard of key management as described in 596 RFC 3562 [5]. 598 Key maintenance can be especially onerous for operators. The number 599 of keys required and the maintenance of keys (update/withdraw/renew) 600 has had an additive effect as a barrier to deployment. Thus 601 automated means of managing keys, to reduce operational burdens, MUST 602 be available throughout BGP security systems. These security systems 603 MUST be resistant to compromise of session-level or device-level 604 keys, i.e., the security implications of such compromises MUST be 605 limited. 607 12. References 609 [1] Fraser, "RFC 2196 - Site Security Handbook", September 1997. 611 [2] Rescorla, Korver, and Internet Architecture Board, "RFC 3552 - 612 Guidelines for Writing RFC Text on Security Considerations", 613 July 2003. 615 [3] Rekhter and Li, "RFC 1771 - A Border Gateway Protocol 4 616 (BGP-4)", March 1995. 618 [4] Heffernan, "RFC 2385 - Protection of BGP Sessions via the TCP 619 MD5 Signature Option", August 1998. 621 [5] Leech, "RFC 3562 - Key Management Considerations for the TCP MD5 622 Signature Option", July 2003. 624 [6] Gill, Heasley, and Meyer, "RFC 3682 - The Generalized TTL 625 Security Mechanism (GTSM)", February 2004. 627 [7] Rekhter, Li, and Hares, "RFC 4271 - A Border Gateway Protocol 4 628 (BGP-4)", October 2005. 630 Appendix A. Acknowledgements 632 The following individuals contributed to the development and review 633 of this draft. Steve Kent, Russ White, Sandy Murphy, Jeff Haas, Bora 634 Akyol, Susan Hares, Mike Tibodeau, Thomas Renzy, Kaarthik Sivakumar, 635 Tao Wan, Radia Perlman, and Merike Kaeo. 637 This draft was developed based on conversations with various network 638 operators including Chris Morrow, Jared Mauch, Tim Battles, and Ryan 639 McDowell. 641 Authors' Addresses 643 Blaine Christian (editor) 644 KMC Telecom Solutions 645 1545 U.S. Highway 206 646 Bedminster, NJ 07921 647 US 649 Tony Tauber (editor) 650 Comcast 651 27 Industrial Avenue 652 Chelmsford, MA 01824 653 US 655 Email: ttauber@1-4-5.net 657 Intellectual Property Statement 659 The IETF takes no position regarding the validity or scope of any 660 Intellectual Property Rights or other rights that might be claimed to 661 pertain to the implementation or use of the technology described in 662 this document or the extent to which any license under such rights 663 might or might not be available; nor does it represent that it has 664 made any independent effort to identify any such rights. Information 665 on the procedures with respect to rights in RFC documents can be 666 found in BCP 78 and BCP 79. 668 Copies of IPR disclosures made to the IETF Secretariat and any 669 assurances of licenses to be made available, or the result of an 670 attempt made to obtain a general license or permission for the use of 671 such proprietary rights by implementers or users of this 672 specification can be obtained from the IETF on-line IPR repository at 673 http://www.ietf.org/ipr. 675 The IETF invites any interested party to bring to its attention any 676 copyrights, patents or patent applications, or other proprietary 677 rights that may cover technology that may be required to implement 678 this standard. Please address the information to the IETF at 679 ietf-ipr@ietf.org. 681 Disclaimer of Validity 683 This document and the information contained herein are provided on an 684 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 685 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 686 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 687 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 688 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 689 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 691 Copyright Statement 693 Copyright (C) The Internet Society (2005). This document is subject 694 to the rights, licenses and restrictions contained in BCP 78, and 695 except as set forth therein, the authors retain all their rights. 697 Acknowledgment 699 Funding for the RFC Editor function is currently provided by the 700 Internet Society.