idnits 2.17.1 draft-ietf-rpsec-bgpsecrec-02.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 680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 670. ** 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 235: '...tate that the AS topology MUST be loop...' RFC 2119 keyword, line 256: '... security system SHOULD address how to...' RFC 2119 keyword, line 279: '... the ATOMIC_AGGREGATE attribute SHOULD...' RFC 2119 keyword, line 297: '...a security system in operation, SHOULD...' RFC 2119 keyword, line 302: '... verification MAY be offered for the...' (38 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 (July 19, 2005) is 6855 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: January 20, 2006 Comcast 6 July 19, 2005 8 BGP Security Requirements 9 draft-ietf-rpsec-bgpsecrec-02 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 January 20, 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, as a path-vector routing protocol. BGP speakers 57 typically exchange information about reachable destinations 58 (expressed as address prefixes) in an internetwork through pairwise 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, policy indicators (or policies) 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 attacks 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. 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, of BGP security in general. IETF standards for subscriber 117 data security, e.g., IPsec, TLS, and S/MIME should be employed for 118 such purposes. While adoption of BGP security measures may preclude 119 certain classes of attacks on subscriber traffic, these measures are 120 not a substitute for use of subscriber-based security mechanisms of 121 the sort noted above. 123 1.3 Areas to secure 125 There are two primary points where BGP may be secured. If we examine 126 the system description presented above those points are as follows. 128 o The session between two BGP speakers can be secured such that the 129 BGP data received by the BGP speakers can by cryptographically 130 verified to have been transmitted by the peer BGP speaker. There 131 are several existing IETF standards to choose from to ensure that 132 this system functions with greater effectiveness than the current 133 system. Examples include IPsec and TLS. 135 o The originator and the propagators of prefix information may have 136 their routing preference, such as the LOCAL_PREF Attribute, 137 information verified such that the intent of their preferences 138 with respect to a specific prefix is preserved. 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 viable 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 travelled 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 TCP 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 IGP and is used by a distinct network administrative entity to 180 convey internal routing policy regarding external and internal 181 information. Exterior BGP (eBGP) is typically used to distribute 182 route/prefix reachability information between two distinct routing 183 entities and is used to signal eBGP preferences and policy 184 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, an AS-A 189 sends peer AS-B a less specific advertisement and peer AS-C a 190 "more" specific advertisement. This prefix distribution decision 191 may have been made to provide a means for failure resolution 192 between AS-A and AS-C. However, it should be noted that while 193 AS-A tries to influence the routing decisions of AS-B and 194 downstream ASes, AS-A is only providing inputs to a local decision 195 by AS-B, a decision that is very much influenced by AS-B's local 196 policy over which AS-A has no control. Update messages are sent 197 between AS peers with the implicit assumption that those messages 198 will be forwarded to others. A notable exception to this 199 assumption is the use of various policy based mechanisms between 200 peers such as the NO-EXPORT community. In this document an 201 important aspect of the UPDATE message to note is that the 202 specific UPDATE message itself is typically not re-transmitted. 203 Instead, the specific UPDATE message is regenerated continually as 204 it passes from BGP speaker to BGP speaker. Furthermore, UPDATE 205 messages have no mechanism for freshness (e.g. timestamps or 206 sequence numbers). This indicates that messages may appear valid 207 at any point in the life of a BGP peering session. While the 208 AS_PATH information is typically transitive it is, currently, not 209 clearly mandated and many times is removed for various utilitarian 210 reasons. 212 o It is important to note that while preference regarding routing 213 can be explicity managed with direct peers it is markedly more 214 difficult to influence routing decisions with ASes not directly 215 adjacent. 217 o Inter-AS withdrawal message assumptions: The processing model of 218 BGP RFC1771 [3] indicates that only the peer advertising NLRI 219 information may withdraw it. There are several instances where a 220 withdrawal may occur. Typical reasons for withdrawal include the 221 determination of a better path, peer session failure, or local 222 policy change. There is no specified mechanism for indicating, to 223 an external peer, the reason for a route withdrawal. Each 224 withdrawal received from a valid peering session must be taken at 225 face value. There is no existing method to ensure that an AS will 226 properly propagate withdrawal messages received from its external 227 peers nor do mechanisms exist to ensure that old UPDATES are not 228 re-propagated. 230 o AS_PATH assumptions: Aside from the use of AS_SET, the AS_PATH is 231 typically considered to be an ordered list of the Autonomous 232 Systems that an update has traversed. In most cases the rightmost 233 AS in the list is the origin AS, or at least the AS responsible 234 for the management of the NLRI information associated with the 235 first AS. Specifications state that the AS topology MUST be loop 236 free. This indicates that updates received from an external peer 237 which contain the local AS will be rejected. The prepending of AS 238 information for received updates and transmitted updates is 239 generally permitted and is common practice. Prepended AS 240 information on inbound advertisements (where the external peers AS 241 is prepended) and outbound advertisements (where the local AS 242 number is prepended) is a commonly used method to effect 243 forwarding changes. Prepending a peer AS on inbound reception is 244 accomplished for internal routing and forwarding management while 245 prepending one's own AS on outbound advertisement is typically 246 accomplished to effect forwarding and routing changes in external 247 networks. The common practice is to prepend (possibly multiple) 248 instances of either one's own AS number or that of the neighbor 249 from which an update was heard. Another practice, according to 250 some operators, involves inserting a remote AS number, in order to 251 cause the update to be dropped by that AS so that traffic will not 252 traverse a given path. Though this practice appears to be 253 unintended in the design in BGP, anecdotal evidence is that its 254 use is not totally insignificant. While such a practice can be 255 beneficial to legitimate operators, it presents a strong potential 256 for misuse. A proposed security system SHOULD address how to 257 either address this concern or give specific information on this 258 topic for consideration by the Operational community. 260 o Route Origination: BGP speakers may originate routes based on 261 various internal and external data. An Autonomous System should 262 only originate a prefix to its external peers if that prefix has 263 been somehow allocated to the administrators of that system, or 264 authorized by the prefix holders. 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 extensive use of separate route servers 271 and forwarding devices 273 * Deployments that use the propagation of prefixes in order to 274 effectively block high bandwidth attacks against specific IP 275 addresses (and the associated oversubscription of resources). 277 o Aggregation and de-aggregation: According to RFC1771 [3], if a BGP 278 speaker chooses to aggregate a set of more specific prefixes into 279 a less specific prefix then the ATOMIC_AGGREGATE attribute SHOULD 280 be set. This creates a significant potential loophole in an 281 attempt to secure BGP based on the RFC specifications. 283 3. Operational Requirements 285 We have determined, through discussion with several large 286 internetwork operators and equipment vendors, that the following 287 attributes are important to the ongoing performance of interdomain 288 routing systems such as BGP. 290 3.1 Convergence speed 292 Convergence speed is a major concern to many operators of large scale 293 internetworking systems. Networks, and internetworks, are carrying 294 ever increasing amounts of information that is time and delay 295 sensitive; increasing convergence times can adversely affect the 296 usability of the network, and the ability of an internetwork to grow. 297 BGP's convergence speed, with a security system in operation, SHOULD 298 be equivalent to BGP running without the security system in 299 operation. This includes the preservation of optimizations currently 300 used to produce acceptable convergence speeds on current hardware, 301 including update packing, peer groups, and others. Two types of 302 verification MAY be offered for the NLRI and the AS_PATH in order to 303 allow for a selection of optimizations: 305 o Contents of the UPDATE message SHOULD be authenticated in real- 306 time as the UPDATE message is processed. 308 o The route information base MAY be authenticated periodically or in 309 an event-driven manner by scanning the data and verifying the 310 originating AS and the validity of the AS_PATH list. 312 All BGP implementations that implement security MUST utilize at least 313 one of the above methods for validating routing information. Real 314 time verification is preferred in order to prevent transitive 315 failures based on periodic or event-driven scan intervals. 317 3.2 Incremental deployment 319 We will not be able to deploy a newly secured BGP protocol 320 instantaneously and will be unable to dictate a partitioning of large 321 ASes by network operators. Because of this, there are several 322 requirements that any proposed mechanism to secure BGP must consider. 324 o A BGP security mechanism MUST enable each BGP speaker to configure 325 use of the security mechanism on a per-peer basis. 327 o MUST provide backward compatibility in the message formatting, 328 transmission, and processing of routing information carried 329 through a mixed security environment. Message formatting in a 330 fully secured environment MAY be handled in a non-backward 331 compatible fashion though care must be taken to ensure when 332 traversing intermediate routers which don't support the new 333 format. 335 o In an environment where both secured and non-secured systems are 336 interoperating a mechanism MUST exist for secured systems to 337 identify whether an originator intended the information to be 338 secured. 340 3.3 Conditions for initialization 342 A key factor in the robust nature of the existing internal and 343 external relationships maintained in todays Internet provider space 344 is the ability to maintain and return to a significantly converged 345 state without the need to rely on systems external to the routing 346 system (the physical equipment that is performing the forwarding). 347 In order to ensure the rapid initialization and/or return to service 348 of failed nodes it is important to reduce reliance on external 349 systems to the greatest extent possible. Therefore, proposed systems 350 SHOULD NOT require connections to external systems, beyond those 351 directly involved in peering relationships, in order to return to 352 full service. Proposed systems MAY require post initialization 353 synchronization with external systems in order to synchronize 354 security information. 356 3.4 Local controls for secure UPDATE acceptance 358 Each secured environment may have different levels of requirements in 359 terms of what is acceptable or unacceptable. In environments that 360 require strict security it may not be acceptable to temporarily route 361 to a destination while waiting for security verification to be 362 performed. However, in many commercial environments the rapidity of 363 route installation may be of paramount importance; in order to 364 facilitate the more common occurence of route withdrawal due to 365 network failure. Based on the two divergent requirements, the 366 following criteria apply. 368 o The security system MUST support a range of possible outputs for 369 local determination of the trust level for a specific route so 370 that routing preference and policy can be applied to its inclusion 371 in the RIB. Any given route should be trustable to a locally 372 configured degree, based on the completeness of security 373 information for the update and other factors. 375 o The security system SHOULD allow the operator to determine whether 376 the speed of convergence is more important than security 377 operations, or security operations are more important than the 378 speed of convergence. This facilitates the incremental deployment 379 of security on systems not designed to support increased 380 processing requirements imposed by the security system. 382 4. Infrastructure Requirements 384 In the case that proposed BGP security mechanisms make use of a 385 security infrastructure to distribute authenticated data that is an 386 input to routing decisions. Such data may be needed to verify 387 whether a given AS is authorized to originate an advertisement for a 388 specified prefix, whether an given organization is the recognized 389 holder of a block of address space or of an AS number, etc. Any 390 infrastructure used to distribute data in support of BGP security is 391 subject to the following criteria: 393 o It MUST be resilient to attacks on the integrity of the data it 394 contains. 396 o It MUST enable network operators to verify the origin of the data. 398 o It MUST be sufficiently available so as to not degrade the 399 existing pace of network operations. 401 o It SHOULD not introduce new organizational entities that have to 402 be trusted in order to establish the authenticity of the data. 404 5. The Trust Model 406 In discussion with the operations community, concerns have emerged 407 regarding the viability of a security system which requires agreement 408 on a hierachical trust model dependent on a single root. Current 409 operational practice has many providers engaging in bilateral 410 agreements which local policy choices remaining sacrosanct. The 411 viability of a solution may well rest on the business imperatives of 412 the provider community which may be unwilling to surrender their 413 percieved autonomy or unable to come to communal agreement on this 414 topic. 416 In other environments, deployments may require an authority which has 417 been decided by law or other institutional mandate. Moreover, these 418 two deployment types (single-rooted heirarchy or arbitrary 419 association) may "touch" (i.e. be part of the same co-extensive BGP 420 topology). 422 Solutions MUST account for these differing types of deployments. 424 If two internetworks using differing trust models are interconnected 425 they MUST be able to interoperate using locally determined levels of 426 trust to compensate for differences in their trust models. Some 427 acknowledgement is made that this requirement might render it 428 difficult to discern an attack from a difference in trust model or 429 implementation. Any proposed solution MUST mitigate this risk. 431 6. The AS_PATH Attribute and NLRI Authentication 433 BGP distributes routing information across the Internet (between BGP 434 speakers) using BGP UPDATE messages. The UPDATE message contains 435 withdrawn routes, path attributes and one or more NLRIs (Network 436 Layer Reachability Information is synonymous with advertised prefix). 437 For the remainder of this section, we will focus on the AS_PATH 438 Attribute and the NLRI. Attributes such as local pref are locally 439 specific and, as such, are protected by BGP session security. 441 The AS_PATH for specific prefixes may be protected in any proposed 442 security system in four ways: 444 o Authorization of Originating AS: For the purposes of authorization 445 of the originating AS, verifiable means that it is possible to 446 determine the authorization of the originator of a specific prefix 447 (or block of IP addresses) relative to the organization that holds 448 the prefix. 450 o Announcing AS Check: For all BGP peers, a BGP Implementation MUST 451 ensure that the first element of the AS_PATH list corresponds to 452 the locally configured AS of the peer from which the UPDATE was 453 received. 455 o AS_PATH Feasibility Check: The AS_PATH list MUST correspond to a 456 valid list of autonomous systems according to the first 457 verification category listed in the "Areas to Secure" Section 458 above. 460 o Update Transit Check: Routing information carried through BGP 461 SHOULD include information that can be used to verify the 462 readvertisement or modification by each autonomous system through 463 which the UPDATE has passed. This check is somewhat more rigorous 464 than the "verifiable list of autonomous systems" above. 466 Both checks SHOULD be made available to operators who MAY employ more 467 rigorous checks according to the needs of the deployment. 469 There are many ways in which a differential between the speed of 470 prefix/AS path attribute propagation and the information validating 471 the the prefix/AS_PATH attribute information can be exploited to 472 attack the routing system on a temporary basis. These types of 473 attacks are dominantly exploitative of the time it takes to follow 474 the withdrawal of a route via an update. As a result of this 475 potential for temporary disruption, BGP security solutions MUST 476 propagate security information at the same rate as the BGP 477 announcements and withdrawals propagate. 479 The following items are required to propagate at the same rate: 481 o the distribution of key information used by individual actors 482 within the system, including the keys used by individual 483 autonomous systems to sign certificates and other objects, 485 o the distribution of information about the AS(es) authorized to 486 advertise a given block of IP addresses (or an address space), 488 o the distribution of information about connectivity between 489 autonomous systems and about autonomous system polcies. 491 Note that in today's operational Internet, the first two pieces of 492 information, or their analogues, are not a part of the BGP routing 493 system per se (e.g. information in Routing or Address regisistries.) 494 They are consulted by operators on an inconsistent basis and do are 495 not consulted in real time by the routing system. The third piece of 496 information is explicitly carried in the routing system and 497 inconsistently expressed and consulted by operators. However, the 498 ability to change the connectivity in real time is an important 499 feature of the current Internet. 501 7. Address Allocation and Advertisement 503 As part of the regular operation of the Internet, addresses that are 504 allocated to one organization may be, and are quite commonly, 505 advertised by different organizations. Common reasons for this 506 practice include multi-homing and route reduction for the purposes of 507 resource conservation (e.g aggregation). There are two modes of 508 delegation: 510 o A BGP speaker and listener have chosen to restrict the amount of 511 received prefixes for the listener. The listener has chosen to 512 honor route announcements sent in a summary fashion by the 513 speaker. 515 o Address space that is being delegated is part of a larger 516 allocation that is owned by an autonomous system. The owner then 517 delegates the smaller block to another AS for purposes of 518 advertisement. This mode is commonly observed in multi-homing. 520 These two modes lead to a single common requirement: Any BGP Security 521 solution MUST support the ability of an address block holder to 522 declare (in a secure fashion) the AS(es) that the holder authorizes 523 to originate routes to its address block(s) or any portion thereof 524 regardless of the relationship of the entities. 526 An associated delegation criteria is the requirement to allow for 527 non-BGP IP end user implementations. As a result, all secured BGP 528 implementations MUST allow for the contemporaneous origination of a 529 route for a prefix by more than one AS. 531 8. Logging 533 In order to facilitate auditing and troubleshooting, a logging 534 capability MUST be implemented which will indicate both negative and 535 positive event behaviors. This data SHALL be for consumption of the 536 AS operating the device which is producing the logs and MAY be 537 combined with data from other ASes or devices with different 538 implmentations within the same AS for purposes of event correlation 539 and tracking. Here follow some considerations in this regard: 541 The data generated by logging may be very large depending on the 542 number of peers, the number of prefixes received, the authentication 543 model used, and routing policies. As such, efficient data structures 544 and storage mechanisms MUST be developed to allow for an effective 545 means of reproducing incidents and outages 547 Path and NLRI attributes MUST be logged using a standard format. The 548 format MUST be scalable with the amount of data logged and the 549 frequency of log generation. The frequency of log generation should 550 be controllable by the operator. The logging mechanisms for the 551 tracked information MUST be standardized across all platforms. 552 Logging ability both on and off line is considered highly desirable. 554 9. NLRI and Path Attribute Tracking 556 The ability for a receiver to know exactly who originated and 557 forwarded a routing update is a desirable trait. In order to rapidly 558 identify attack points and parties at fault for route table 559 disruption, it is important to be able to track and log prefix 560 origination information along with associated security information. 562 This capability can be afforded by implementation of the 563 aforementioned directive that any security system SHOULD provide a 564 method to allow the receiver of an update to verify that the 565 originator is actually authorized to originate the update, and that 566 the AS's listed in the AS_PATH actually forwarded the update. 568 10. Transport Layer Protection 570 Transport protection is an important aspect of BGP routing protocol 571 security. The potential to create a linked transport/NLRI/AS_PATH 572 authentication mechanism should not be overlooked and may provide for 573 the accelerated deployment of a BGP security system. Current 574 security mechanisms for BGP transport (e.g. TCP-MD5 [4] and GTSM 575 [6]) are inadequate and require significant operator interaction to 576 maintain a respectable level of security. 578 Transport protection systems SHOULD function as a component of the 579 BGP routing protocol security mechanism. This includes the use of 580 the same key generation/management systems as the rest of the 581 security system. 583 Any proposed security mechanism MUST include provisions for securing 584 both internal BGP and external BGP peering sessions. 586 11. Key Management 588 Current implementations and deployments of TCP-MD5 [4] exhibit 589 serious shortcomings with regard of key management as described in 590 RFC 3562 [5] which involve key generation, handling, and 591 distribution. 593 Key maintenance can be especially onerous to the operators. The 594 number of keys required and the maintenance of keys (update/withdraw/ 595 renew) has had an additive effect as a barrier to deployment. Thus 596 automated means of managing keys, to reduce operational burdens, MUST 597 be available throughout BGP security systems. These security systems 598 MUST be resistant to compromise of session-level or device-level 599 keys, i.e., the security implications of such compromises MUST be 600 limited. 602 12. References 604 [1] Fraser, "RFC 2196 - Site Security Handbook", September 1997. 606 [2] Rescorla, Korver, and Internet Architecture Board, "RFC 3552 - 607 Guidelines for Writing RFC Text on Security Considerations", 608 July 2003. 610 [3] Rekhter and Li, "RFC 1771 - A Border Gateway Protocol 4 611 (BGP-4)", March 1995. 613 [4] Heffernan, "RFC 2385 - Protection of BGP Sessions via the TCP 614 MD5 Signature Option", August 1998. 616 [5] Leech, "RFC 3562 - Key Management Considerations for the TCP MD5 617 Signature Option", July 2003. 619 [6] Gill, Heasley, and Meyer, "RFC 3682 - The Generalized TTL 620 Security Mechanism (GTSM)", February 2004. 622 Authors' Addresses 624 Blaine Christian (editor) 625 KMC Telecom Solutions 626 1545 U.S. Highway 206 627 Bedminster, NJ 07921 628 US 629 Tony Tauber (editor) 630 Comcast 631 27 Industrial Avenue 632 Chelmsford, MA 01824 633 US 635 Email: ttauber@1-4-5.net 637 Appendix A. Acknowledgements 639 The following individuals contributed to the development and review 640 of this draft. Steve Kent, Russ White, Sandy Murphy, Jeff Haas, Bora 641 Akyol, Susan Hares, Mike Tibodeau, Thomas Renzy, Kaarthik Sivakumar, 642 Tao Wan, Radia Perlman, and Merike Kaeo. 644 This draft was developed based on conversations with various network 645 operators including Chris Morrow, Jared Mauch, Tim Battles, and Ryan 646 McDowell. 648 Intellectual Property Statement 650 The IETF takes no position regarding the validity or scope of any 651 Intellectual Property Rights or other rights that might be claimed to 652 pertain to the implementation or use of the technology described in 653 this document or the extent to which any license under such rights 654 might or might not be available; nor does it represent that it has 655 made any independent effort to identify any such rights. Information 656 on the procedures with respect to rights in RFC documents can be 657 found in BCP 78 and BCP 79. 659 Copies of IPR disclosures made to the IETF Secretariat and any 660 assurances of licenses to be made available, or the result of an 661 attempt made to obtain a general license or permission for the use of 662 such proprietary rights by implementers or users of this 663 specification can be obtained from the IETF on-line IPR repository at 664 http://www.ietf.org/ipr. 666 The IETF invites any interested party to bring to its attention any 667 copyrights, patents or patent applications, or other proprietary 668 rights that may cover technology that may be required to implement 669 this standard. Please address the information to the IETF at 670 ietf-ipr@ietf.org. 672 Disclaimer of Validity 674 This document and the information contained herein are provided on an 675 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 676 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 677 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 678 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 679 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 680 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 682 Copyright Statement 684 Copyright (C) The Internet Society (2005). This document is subject 685 to the rights, licenses and restrictions contained in BCP 78, and 686 except as set forth therein, the authors retain all their rights. 688 Acknowledgment 690 Funding for the RFC Editor function is currently provided by the 691 Internet Society.