idnits 2.17.1 draft-ietf-opsec-routing-capabilities-00.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 869. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 880. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 887. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 893. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 10, 2006) is 6401 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '16' is defined on line 811, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2385 (ref. '5') (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 3682 (ref. '9') (Obsoleted by RFC 5082) == Outdated reference: A later version (-05) exists of draft-ietf-opsec-framework-03 == Outdated reference: A later version (-09) exists of draft-ietf-opsec-filter-caps-04 == Outdated reference: A later version (-17) exists of draft-ietf-idr-route-filter-16 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSEC Working Group Y. Zhao 3 Internet-Draft F. Miao 4 Intended status: Informational Huawei Technologies 5 Expires: April 13, 2007 R. Callon 6 Juniper Networks 7 October 10, 2006 9 Routing Control Plane Security Capabilities 10 draft-ietf-opsec-routing-capabilities-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 13, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 The document lists the security capabilities needed for the routing 44 control plane of an IP infrastructure to support the practices 45 defined in Operational Security Current Practices. In particular 46 this includes capabilities for route filtering and for authentication 47 of routing protocol packets. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Threat model . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. Format and Definition of Capabilities . . . . . . . . . . 3 54 1.3. Packet Filtering versus Route Filtering . . . . . . . . . 4 55 2. Route Filtering Capabilities . . . . . . . . . . . . . . . . . 5 56 2.1. General Route Filtering Capabilities . . . . . . . . . . . 5 57 2.1.1. Ability to Filter Inbound or Outbound Routes . . . . . 5 58 2.1.2. Ability to Filter Routes by Prefix . . . . . . . . . . 6 59 2.2. Route Filtering of Exterior Gateway Protocol . . . . . . . 6 60 2.2.1. Ability to Filter Routes by Route Attributes . . . . . 6 61 2.2.2. Ability to Filter Routing Update by TTL . . . . . . . 7 62 2.2.3. Ability to Limit the Number of Routes from a Peer . . 8 63 2.2.4. Ability to Limit the Length of Prefixes . . . . . . . 9 64 2.2.5. Ability to Cooperate in Outbound Route Filtering . . . 9 65 2.3. Route Filtering of Interior Gateway Protocols . . . . . . 10 66 2.3.1. Route Filtering Within an IGP Area . . . . . . . . . . 10 67 2.3.2. Route Filtering Between IGP Areas . . . . . . . . . . 10 68 2.4. Route Filtering during Redistribution . . . . . . . . . . 11 69 3. Route Authentication Capabilities . . . . . . . . . . . . . . 12 70 3.1. Ability to configure an authentication mechanism . . . . . 12 71 3.2. Ability to support authentication key chains . . . . . . . 12 72 4. Ability to Damp Route Flap . . . . . . . . . . . . . . . . . . 13 73 5. Performance and Prioritization . . . . . . . . . . . . . . . . 14 74 5.1. Ensure Resources for Management Functions . . . . . . . . 14 75 5.2. Ensure Resources for Routing Functions . . . . . . . . . . 15 76 5.3. Limit Resources used by IP Multicast . . . . . . . . . . . 16 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 83 Intellectual Property and Copyright Statements . . . . . . . . . . 20 85 1. Introduction 87 This document is defined in the context of Operation Security 88 Framework [12] and Operation Security Current Practice [13]. 90 The Framework for Operation Security Framework outlines the effort of 91 the IETF OPSEC working group. This includes producing a series of 92 drafts to codify knowledge gained through operational experience 93 about capabilities that are needed to securely deploy and operate 94 managed network elements providing transit services at the data link 95 and network layers. 97 This document lists the security capabilities needed for the routing 98 control plane of IP infrastructure to support the practices defined 99 in Operational Security Current Practices. In particular this 100 includes capabilities for route filtering and for authentication of 101 routing protocol packets. 103 Note that this document lists capabilities that can reasonably be 104 expected to be currently deployed in the context of existing 105 standards. Extensions to existing protocol standards and development 106 of new protocol standards are outside of the scope of this effort. 107 The preferred capabilities needed for securing the routing 108 infrastructure may evolve over time. 110 There will be other capabilities which are needed to fully secure a 111 router infrastructure. For example, network management of devices 112 must be secured in order to prevent unauthorized access to or denial 113 of service to the device Network Management Access Security 114 Capabilities [15]. The reader should refer to Operation Security 115 Framework for a more complete list of documents describing 116 operational capabilities for network and link layer devices 117 supporting IP Network Infrastructure. 119 Operational Security Current Practices defines the goals, motivation, 120 scope, definitions, intended audience, threat model, potential 121 attacks and give justifications for each of the practices. 123 1.1. Threat model 125 The capabilities listed in this document are intended to aid in 126 preventing or mitigating the threats outlined in Operation Security 127 Framework and Current Practices. 129 1.2. Format and Definition of Capabilities 131 Each individual capability will be defined using the four elements, 132 "Capability", "Supported Practices", "Current Implementations", and 133 "Considerations", as explained in section 1.7 of Operation Security 134 Framework. 136 1.3. Packet Filtering versus Route Filtering 138 It is useful to make a distinction between Packet Filtering versus 139 Route Filtering. 141 The term "packet filter" is used to refer to the filter that a router 142 applies to network layer packets passing through or destined to it. 143 In general packet filters are based on contents of the network (IP) 144 and transport (TCP,UDP) layers, and are mostly stateless, in the 145 sense that whether or not a filter applies to a particular packet is 146 a function of that packet (including the contents of IP and transport 147 layer headers, size of packet, incoming interface, and similar 148 characteristics), but does not depend upon the contents of other 149 packets which might be part of the same stream (and thus which may 150 also be forwarded by the same router). One common minor exception to 151 the "stateless" nature of packet filters is that packets that match a 152 particular filter may be counted and/or rate limited (the act of 153 counting therefore represents a very simple "state" associated with 154 the filter). 156 Because of the simplicity and stateless nature of packet filters, 157 they can typically be implemented with very high performance. It is 158 not unusual for them to be implemented on line cards and to perform 159 at or near full line rate. For this reason they are very useful to 160 counter very high bandwidth attacks, such as large DDoS attacks. 162 Packet filtering capabilities are outside of the scope of this 163 document. A detailed description of packet filtering capabilities 164 can be found in "Filtering Capabilities for IP Network 165 Infrastructure" [14]. 167 The Term "route filter" is used to refer to filters that routers 168 apply to the content of routing protocol packets that they are either 169 sending or receiving. Typically these therefore occur at the 170 application layer (although which route filters are applied to a 171 particular packet may be a function of network layer information, 172 such as what interface the packet is received on, or the source 173 address for the packet -- indicating the system that transmitted the 174 packet). 176 Route filters are typically implemented in some sort of processor. 177 In many cases the total bandwidth which can be received by the 178 processor is considerably less than the sum of the rate that packets 179 may be received on all interfaces to a router. Therefore in general 180 route filters cannot handle the same bandwidth as packet filters. 182 Route filters are however very useful in that they can be applied to 183 the contents of routing packets. 185 2. Route Filtering Capabilities 187 2.1. General Route Filtering Capabilities 189 2.1.1. Ability to Filter Inbound or Outbound Routes 191 Capability. 193 The device provides the ability to filter which routes may be 194 received in routing protocols (with BGP [10], and with RIP [7] and 195 other distance vector routing protocols), as well as the ability 196 to filter which routes are announced into each routing protocol. 198 Supported Practices. 200 See section 2.4.2 of Current Practices. 202 It is a beneficial practice to configure routing filters in both 203 directions, which will counter potential misconfiguration in each 204 side of peers. Also, incoming route filters will prevent a 205 deliberate attacker to inject invalid routing information. 207 Current Implementations. 209 The unicast routing protocols used with IP can be classified into 210 path vector routing protocols (such as BGP), distance vector 211 protocols (such as RIP) and link state protocols (such as OSPF [4] 212 and IS-IS [1]). Because of difference of protocol mechanism, 213 route filters will affect them in different ways. 215 Take BGP for example, an implementation may check a received route 216 against inbound filters to determine whether to install it into 217 the overall route table or not. Also, it will restrict the routes 218 which will go out to neighbors against outbound route filters. 220 However, as to link state protocols, such as OSPF, a router 221 maintains a topology database and exchanges link state information 222 with neighbors. Since route filters do not influence the link 223 state database, route filters will only affect which routes are 224 advertised into the routing protocol. That is to say, only 225 inbound route filters are effective on link state protocols. 227 Most of the routing protocols support methods to configure route 228 filters which permit or deny learning or advertising of specific 229 routes. 231 Considerations. 233 None. 235 2.1.2. Ability to Filter Routes by Prefix 237 Capability. 239 The device supports filtering routes based on prefix. 241 Supported Practices. 243 See section 2.4.2 of Current Practices. 245 Current Implementations. 247 The filter may include a list of specific prefixes to be accepted 248 or rejected. The filter may alternately include a list of 249 prefixes, such that more specific (longer) prefixes which are 250 included in the more inclusive (shorter) prefix are accepted, 251 rejected, or summarized into the shorter prefix. 253 Considerations. 255 Operators may wish to ignore advertisements for routes to 256 specially used addresses, such as private addresses, reserved 257 addresses and multicast addresses, etc. The up-to-date allocation 258 of IPv4 address space can be found in INTERNET PROTOCOL V4 ADDRESS 259 SPACE [18]. 261 2.2. Route Filtering of Exterior Gateway Protocol 263 An exterior gateway protocol is used to exchange external routing 264 information between different autonomous systems. Since BGP is the 265 actual standard, this section mainly depicts special routing filter 266 capabilities of BGP. 268 2.2.1. Ability to Filter Routes by Route Attributes 270 Capability. 272 The device supports filtering routing updates by route attributes. 274 Supported Practices. 276 See RFC3013 [8] and section 3.2 of RFC2196 [3] and section 2.4.2 277 of Current Practices. 279 Current Implementations. 281 In comparison with other routing protocol, BGP defines various 282 path attributes to describe characteristics of routes. Besides 283 filtering by specific prefixes, BGP could also use some path 284 attributes to precisely filter routes to determine whether a route 285 is accepted from or sent to a neighboring router. 287 These filters may be based upon any combination of route 288 attributes, such as: 290 * Restrictions on the Content of AS_PATH. Restrictions on the 291 contents of the AS PATH are frequently used: for example, the 292 received AS_PATH may be checked to ensure the sending AS is 293 actually contained in the received AS_PATH. 295 * Restrictions on Communities. Implementations could filter 296 received routes based on the set of communities RFC1997 [2] or 297 extended communities RFC4360 [11]. 299 Considerations. 301 None. 303 2.2.2. Ability to Filter Routing Update by TTL 305 Capability. 307 The device should provide a means to filter route packets based on 308 the value of the TTL field in the IPv4 header or the Hop-Limit 309 field in the IPv6 header. 311 Note that "Filtering Capabilities for IP Network Infrastructure" 312 Filtering Capabilities specifies: 314 Capability. 316 The filtering mechanism supports filtering based on the 317 value(s) of any portion of the protocol headers for IP, ICMP, 318 UDP and TCP. 320 The ability to filter based on TTL is therefore a packet filtering 321 capability which is already implicitly covered by the capabilities 322 listed in Filtering Capabilities. Since this capability is 323 particularly important for BGP, we felt that it is worth 324 mentioning here. 326 Supported Practices. 328 See Current Practices section 2.4.2 and RFC3682 [9]. 330 Current Implementations. 332 Most current BGP implementations support this capability to 333 protect BGP sessions. 335 Considerations. 337 There will be situations in which the distance to the neighboring 338 router is more than one hop away. This for example is common for 339 I-BGP. 341 2.2.3. Ability to Limit the Number of Routes from a Peer 343 Capability. 345 The device should provide a means to configure the maximum number 346 of routes (prefixes) to accept from a peer. 348 Supported Practices. 350 Both routing policy misconfiguration and a deliberate attack from 351 a peer may cause too many routes to be sent to a peer which may 352 exhaust memory resources of the router, introduce routing 353 instability into the overall routing table, or both. Therefore, 354 operators may want to restrict the amount of routes received from 355 a particular peer router through a maximum prefix limitation 356 approach. 358 Current Implementations. 360 Most BGP implementations support this capability. If too many 361 routes are sent, then the router may reset the BGP session or may 362 reject excess routes. In either case the device may log the 363 failure event (at a minimum), or shut down the BGP session. 365 Considerations. 367 Operators must be cognizant of the need to allow for valid swings 368 in routing announcements between themselves, and as such should 369 always set the max-prefix limit to some agreed upon number plus a 370 sane amount for overhead to allow for these necessary announcement 371 swings. Individual implementations amongst ISPs are unique, and 372 depending on equipment supplier(s) different implementation 373 options are available. Most equipment vendors offer 374 implementation options ranging from just logging excessive 375 prefixes being received to automatically shutting down the 376 session. If the option of reestablishing a session after some 377 pre-configured idle timeout has been reached is available, it 378 should be understood that automatically reestablishing the session 379 may continuously introduce instability into the overall routing 380 table if a policy misconfiguration on the adjacent neighbor is 381 causing the condition. If a serious misconfiguration on a peering 382 neighbor has occurred then automatically shutting down the session 383 and leaving it shut down until being manually cleared is perhaps 384 best and allows for operator intervention to correct as needed. 386 2.2.4. Ability to Limit the Length of Prefixes 388 Capability. 390 The device has the capability to allow filtering route updates by 391 prefix length. 393 Supported Practices. 395 Some large ISPs declare in their peer BGP policies that they will 396 not accept the announcements whose prefix length is longer than a 397 specific threshold. 399 Current Implementations. 401 Most BGP implementations support this capability. 403 Considerations. 405 None. 407 2.2.5. Ability to Cooperate in Outbound Route Filtering 409 Capability. 411 A device provides the capability to allow operators to configure 412 whether "Outbound Route Filtering"/ORF [17] are accepted from or 413 sent to other peer routers. 415 Supported Practices 417 "Outbound Route Filtering" defines a BGP mechanism to reduce the 418 number of BGP updates between BGP peers. It will conserve the 419 resource in both sides of peers, since the BGP speaker will not 420 generate updates that will be filtered and the neighbor router 421 will not process them as well. A router with limited resource may 422 need this feature to prevent overfull routes from peers. 424 Current Implementations. 426 ORF may be based on prefix, path attributes. Currently, most 427 implementations support prefix-based ORF. 429 Considerations. 431 None. 433 2.3. Route Filtering of Interior Gateway Protocols 435 This section describes route filtering as it may be applied to OSPF 436 and IS-IS when used as the interior gateway protocol (Internal 437 Gateway Protocol or "IGP") used within a routing domain. Route 438 filtering with RIP is TBD. 440 2.3.1. Route Filtering Within an IGP Area 442 A critical design principle of OSPF and IS-IS is that each router 443 within an area has the same view of the topology, thereby allowing 444 consistent routes to be computed by all routers within the area. For 445 this reason, all properly authenticated (if applicable) routing 446 topology advertisements (Link State Advertisements or LSAs in OSPF, 447 or Link State Packets or LSPs in IS-IS) are flooded unchanged 448 throughout the area. Route filtering within an OSPF or IS-IS area is 449 therefore not appropriate. 451 2.3.2. Route Filtering Between IGP Areas 453 Capability. 455 The device provides the capability to allow the network operator 456 to configure route filters which restrict which routes (ie, 457 address prefixes) are advertised into areas from outside of the 458 area (ie, from other OSPF or IS-IS areas). 460 Supported Practices. 462 See Current Practices section 2.4.2. 464 Current Implementations. 466 TBD. 468 Considerations 470 If filters are used which restrict the passing of routes between 471 IGP areas, then this may result in some addresses being 472 unreachable from some other areas within the same routing domain. 474 It is normal when passing routes into the backbone area (area 475 O.0.0.0 in OSPF, or the level 2 backbone in IS-IS) for routes to 476 be summarized, in the sense that multiple more specific (longer) 477 address prefixes that are reachable in an area may be summarized 478 into a smaller number of less specific (shorter) address prefixes. 479 This provides important scaling improvements, but is generally not 480 primarily intended to aid in security and is therefore outside of 481 the scope of this document. 483 2.4. Route Filtering during Redistribution 485 Capability. 487 The device provides a means to filter routes when distributing 488 them between routing protocols or between routing protocol 489 processes running in the single device. 491 Supported Practices. 493 Route redistribution bridges between different route domains and 494 improves the flexibility of routing system. This allows for the 495 transmission of reachable destinations learned in one protocol 496 through another protocol. However, without careful consideration 497 it may lead to looping or black holes as well. 499 Filters always needed when routes redistributing between IGP and 500 BGP. For example, it is unfeasible to inject all internet routes 501 from BGP to IGPs, since IGPs are not able to deal with such a 502 large number of routes. 504 Current Implementations. 506 Most implementations allow applying a filter based on a prefix 507 list to control redistribution. 509 Considerations 511 TBD. 513 3. Route Authentication Capabilities 515 3.1. Ability to configure an authentication mechanism 517 Capabilities. 519 The device has one or more methods to allow the routing protocol 520 to be configured an authentication mechanism (authentication keys 521 and authentication algorithms). 523 Supported Practices. 525 See Current Practices section 2.4.2. 527 Current Implementations. 529 RFC2385 [5] is deployed widely in BGP. Other routing protocols, 530 such as OSPF, adopt similar technology. 532 Consideration. 534 In most of current implementations, neither the authentication 535 mechanism nor key can be negotiated. An operator has to configure 536 it manually, which will affect scalability. 538 To the date of writing this draft, MD5 is the only cryptographic 539 hash function used in route authentication. However, recent 540 research revealed weakness of MD5, which means stronger algorithms 541 are necessary. 543 3.2. Ability to support authentication key chains 545 Capabilities. 547 The device provides a key chain mechanism to update authentication 548 keys of routing protocols. 550 Supported Practices. 552 Using a fixed authentication key is vulnerable to a compromise. A 553 key chain is a series of keys which will be used in configured 554 time intervals. A device can transit keys based on system time 555 and configured key chain. In this way, it reduces possibility of 556 leakage of an authentication key. 558 Current Implementations. 560 This mechanism could be implemented in most routing protocols. 561 Different vendors provide this feature in different routing 562 protocols, such as RIP, OSPF and BGP. 564 Consideration. 566 None. 568 4. Ability to Damp Route Flap 570 Capability. 572 The device provides the capability to damp route flaps. 574 Supported Practices. 576 The function to damp route flaps may enhance the stability of 577 routing system and minimize the influence of flapping. It is 578 useful to counter against some DoS attacks. 580 Current Implementations. 582 BGP RFD (Route Flap Damping) RFC2439 [6] defined the primary 583 mechanism in BGP to mitigate the influence caused by flapping. 584 Most of current BGP implementations support this capability. 586 Other routing protocols may be vulnerable to route flaps as well. 587 Some vendors introduce SPF (shortest path first) algorithm timers 588 in OSPF to control parameters, such as the amount of minimal time 589 between consecutive SPF calculations, which may be used to 590 mitigate excessive resource exhaustion caused by link flaps. 592 Consideration. 594 MAO [19] described a flaw of current BGP RFD standard RFC2439, 595 which shows that route flap damping could suppress relatively 596 stable routes and affect routing convergence. 598 Since none of vendors has corrected his BGP implementation, 599 RIPE378 [20] proposes that, with the current implementations of 600 BGP flap damping, the application of flap damping in ISP networks 601 is not recommended. 603 5. Performance and Prioritization 605 5.1. Ensure Resources for Management Functions 607 Capability. 609 This capability specifies that device implementations ensure that 610 at least a certain minimum sufficient level of resources are 611 available for management functions. This may include resources at 612 ingress to the device, on egress from the device, for internal 613 transmission, and processing. This may include at least protocols 614 used for configuration, monitoring, configuration backup, logging, 615 time synchronization, and authentication. 617 Supported Practices. 619 Certain attacks (and normal operation) can cause resource 620 saturation such as link congestion, memory exhaustion or CPU 621 overload. In these cases it is important that resources be 622 available for management functions in order to ensure that 623 operators have the tools needed to recover from the attack. 625 Current Implementations. 627 How this is implemented depend upon the details of the device. 628 There are a variety of ways that this may be ensured such as 629 prioritizing management functions in comparison with other 630 functions performed by the device, providing separate queues for 631 management traffic, use of operating systems or other methods that 632 partition resources between processes or functions, and so on. 634 Consideration. 636 Imagine a service provider with 1,000,000 DSL subscribers, most of 637 whom have no firewall protection. Imagine that a large portion of 638 these subscribers machines were infected with a new worm that 639 enabled them to be used in coordinated fashion as part of large 640 denial of service attack that involved flooding. It is entirely 641 possible that such an attack could in some cases cause processor 642 saturation or other internal resource saturation on routers 643 causing the routers to become unmanageable. A DoS attack against 644 hosts could therefore become a DoS attack against the network. 646 Guarantee of resources within an individual device is not a 647 panacea. Control packets may not make it across a saturated link. 648 This requirement simply says that the device should ensure 649 resources for management functions within its scope of control 650 (e.g., ingress, egress, internal transit, processing). To the 651 extent that this is done across an entire network, the overall 652 effect will be to ensure that the network remains manageable. 654 5.2. Ensure Resources for Routing Functions 656 Capability. 658 This capability specifies that a device implementation ensures at 659 least a certain minimum sufficient level of resources are 660 available for routing protocol functions. This may include 661 resources at ingress to the device, on egress from the device, for 662 internal transmission, and processing. This may include at least 663 protocols used for routing protocol operation, including resources 664 used for routing HELLO packets for BGP, IS-IS, and OSPF. 666 Supported Practices. 668 Certain attacks (and normal operation) can cause resource 669 saturation such as link congestion, memory exhaustion or CPU 670 overload. In these cases it is important that resources be 671 available for the operation of routing protocols in order to 672 ensure that the network continues to operate (for example, that 673 routes can be computed in order to allow management traffic to be 674 delivered). For many routing protocols the loss of HELLO packets 675 can cause the protocol to drop adjacencies and/or to send out 676 additional routing packets, potentially destabilizing the routing 677 protocol and/or adding to whatever congestion may be causing the 678 problem. 680 Current Implementations. 682 How this is implemented depend upon the details of the device. 683 There are a variety of ways that this may be ensured such as 684 prioritizing routing functions in comparison with other functions 685 performed by the device, providing separate queues for routing 686 traffic, use of operating systems or other methods that partition 687 resources between processes or functions, and so on. 689 Consideration. 691 If routing HELLO packets are not prioritized, then it is possible 692 during DoS attacks or during severe network congestion for routing 693 protocols to drop HELLO packets, causing routing adjacencies to be 694 lost. This in turn can cause overall failure of a network. A DoS 695 attack against hosts can therefore become a DoS attack against the 696 network. 698 Guaranteeing resources within routers is not a panacea. Routing 699 packets may not make it across a saturated link (thus for example 700 it may also be desirable to prioritize routing packets for 701 transmission across link layer devices such as Ethernet switches). 702 This requirement simply says that the device should prioritize 703 routing functions within its scope of control (e.g., ingress, 704 egress, internal transit, processing). To the extent that this is 705 done across an entire network, the overall effect will be to 706 ensure that the network continues to operate. 708 5.3. Limit Resources used by IP Multicast 710 Capability. 712 This capability specifies that some mechanism(s) is provided to 713 allow the control plane resources used by IP multicast, including 714 processing and memory, to be limited to some level which is less 715 than 100% of the total available processing and memory. In some 716 cases the maximum limit of resources used by multicast may be 717 configurable. Routers may also provide a mechanism(s) to allow 718 the amount of link bandwidth consumed by IP multicast on any 719 particular link to be limited to some level which is less than 720 100% of total available bandwidth on that link. 722 Supported Practices. 724 IP multicast has characteristics which may potentially impact the 725 availability of IP networks. In particular, IP multicast requires 726 that routers perform control plane processing and maintain state 727 in response to data plane traffic. Also, the use of multicast 728 implies that a single packet input into the network can result in 729 a large number of packets being delivered throughout the network. 730 Also, it is possible in some situations for a multicast traffic to 731 *both* enter a loop, and also be delivered to some destinations 732 (implying that many copies of the same packet could be delivered). 734 Current Implementations. 736 TBD 738 Consideration. 740 If the amount of resources used by multicast are not limited, then 741 it is possible during an attack for multicast to consume 742 potentially as much as 100% of available memory, processing, or 743 bandwidth resources, thereby causing network problems. 745 6. Security Considerations 747 Security is the subject matter of this entire document. This 748 document lists device capabilities intended to improve the ability of 749 the network to withstand security threats. Operational Security 750 Current Practices defines the threat model and practices, and lists 751 justifications for each practice. 753 7. Acknowledgements 755 The authors gratefully acknowledge the contributions of Ron Bonica, 756 Ted Seely, Pat Cain, George Jones, and Russ White etc for their 757 contributed texts, useful comments and suggestions. 759 8. References 761 8.1. Normative References 763 [1] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual 764 environments", RFC 1195, December 1990. 766 [2] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities 767 Attribute", RFC 1997, August 1996. 769 [3] Fraser, B., "Site Security Handbook", RFC 2196, September 1997. 771 [4] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 773 [5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 774 Signature Option", RFC 2385, August 1998. 776 [6] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap 777 Damping", RFC 2439, November 1998. 779 [7] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998. 781 [8] Killalea, T., "Recommended Internet Service Provider Security 782 Services and Procedures", BCP 46, RFC 3013, November 2000. 784 [9] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL 785 Security Mechanism (GTSM)", RFC 3682, February 2004. 787 [10] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 788 (BGP-4)", RFC 4271, January 2006. 790 [11] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 791 Communities Attribute", RFC 4360, February 2006. 793 8.2. Informative References 795 [12] Jones, G., "Framework for Operational Security Capabilities for 796 IP Network Infrastructure", draft-ietf-opsec-framework-03 797 (work in progress), July 2006. 799 [13] Kaeo, M., "Operational Security Current Practices", 800 draft-ietf-opsec-current-practices-07 (work in progress), 801 August 2006. 803 [14] Morrow, C., "Filtering and Rate Limiting Capabilities for IP 804 Network Infrastructure", draft-ietf-opsec-filter-caps-04 (work 805 in progress), September 2006. 807 [15] Bonica, R. and S. Ahmed, "Network Management Access Security 808 Capabilities", draft-ietf-opsec-nmasc-00 (work in progress), 809 March 2006. 811 [16] Callon, R. and G. Jones, "Miscellaneous Capabilities for IP 812 Network Infrastructure", draft-ietf-opsec-misc-cap-00 (work in 813 progress), February 2006. 815 [17] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability 816 for BGP-4", draft-ietf-idr-route-filter-16 (work in progress), 817 September 2006. 819 [18] IANA, "INTERNET PROTOCOL V4 ADDRESS SPACE", 2006. 821 [19] Mao, Z., Govindan, R., Varghese, G., and R. Katz, "Route Flap 822 Damping Exacerbates Internet Routing Convergence", 2002. 824 [20] RIPE, "Recommendations on Route-flap Damping", May 2006. 826 Authors' Addresses 828 Zhao Ye 829 Huawei Technologies 830 No. 3, Xinxi Rd 831 Shangdi Information Industry Base 832 Haidian District, Beijing 100085 833 P. R. China 835 Email: ye.zhao_ietf@hotmail.com 836 Miao Fuyou 837 Huawei Technologies 838 No. 3, Xinxi Rd 839 Shangdi Information Industry Base 840 Haidian District, Beijing 100085 841 P. R. China 843 Phone: +86 10 8288 2008 844 Email: miaofy@huawei.com 846 Ross W. Callon 847 Juniper Networks 848 10 Technology Park Drive 849 Shangdi Information Industry Base 850 Westford, MA 01886 851 USA 853 Email: rcallon@juniper.net 855 Full Copyright Statement 857 Copyright (C) The Internet Society (2006). 859 This document is subject to the rights, licenses and restrictions 860 contained in BCP 78, and except as set forth therein, the authors 861 retain all their rights. 863 This document and the information contained herein are provided on an 864 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 865 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 866 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 867 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 868 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 869 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 871 Intellectual Property 873 The IETF takes no position regarding the validity or scope of any 874 Intellectual Property Rights or other rights that might be claimed to 875 pertain to the implementation or use of the technology described in 876 this document or the extent to which any license under such rights 877 might or might not be available; nor does it represent that it has 878 made any independent effort to identify any such rights. Information 879 on the procedures with respect to rights in RFC documents can be 880 found in BCP 78 and BCP 79. 882 Copies of IPR disclosures made to the IETF Secretariat and any 883 assurances of licenses to be made available, or the result of an 884 attempt made to obtain a general license or permission for the use of 885 such proprietary rights by implementers or users of this 886 specification can be obtained from the IETF on-line IPR repository at 887 http://www.ietf.org/ipr. 889 The IETF invites any interested party to bring to its attention any 890 copyrights, patents or patent applications, or other proprietary 891 rights that may cover technology that may be required to implement 892 this standard. Please address the information to the IETF at 893 ietf-ipr@ietf.org. 895 Acknowledgment 897 Funding for the RFC Editor function is provided by the IETF 898 Administrative Support Activity (IASA).