idnits 2.17.1 draft-ietf-opsec-routing-capabilities-01.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, updated by RFC 4748 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. 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 IETF Trust 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 (February 25, 2007) is 6270 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '16' is defined on line 812, 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: 4 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: August 29, 2007 R. Callon 6 Juniper Networks 7 February 25, 2007 9 Routing Control Plane Security Capabilities 10 draft-ietf-opsec-routing-capabilities-01.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 August 29, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 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, for authentication of 47 routing protocol packets, and for ensuring resource availability for 48 control functions. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Threat model . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Format and Definition of Capabilities . . . . . . . . . . 3 55 1.3. Packet Filtering versus Route Filtering . . . . . . . . . 4 56 2. Route Filtering Capabilities . . . . . . . . . . . . . . . . . 5 57 2.1. General Route Filtering Capabilities . . . . . . . . . . . 5 58 2.1.1. Ability to Filter Inbound or Outbound Routes . . . . . 5 59 2.1.2. Ability to Filter Routes by Prefix . . . . . . . . . . 6 60 2.2. Route Filtering of Exterior Gateway Protocol . . . . . . . 6 61 2.2.1. Ability to Filter Routes by Route Attributes . . . . . 6 62 2.2.2. Ability to Filter Routing Update by TTL . . . . . . . 7 63 2.2.3. Ability to Limit the Number of Routes from a Peer . . 8 64 2.2.4. Ability to Limit the Length of Prefixes . . . . . . . 9 65 2.2.5. Ability to Cooperate in Outbound Route Filtering . . . 9 66 2.3. Route Filtering of Interior Gateway Protocols . . . . . . 10 67 2.3.1. Route Filtering Within an IGP Area . . . . . . . . . . 10 68 2.3.2. Route Filtering Between IGP Areas . . . . . . . . . . 10 69 2.4. Route Filtering during Redistribution . . . . . . . . . . 11 70 3. Route Authentication Capabilities . . . . . . . . . . . . . . 11 71 3.1. Ability to configure an authentication mechanism . . . . . 12 72 3.2. Ability to support authentication key chains . . . . . . . 12 73 4. Ability to Damp Route Flap . . . . . . . . . . . . . . . . . . 13 74 5. Resource Availability for Router Control Functions . . . . . . 13 75 5.1. Ensure Resources for Management Functions . . . . . . . . 13 76 5.2. Ensure Resources for Routing Functions . . . . . . . . . . 15 77 5.3. Limit Resources used by IP Multicast . . . . . . . . . . . 16 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 84 Intellectual Property and Copyright Statements . . . . . . . . . . 20 86 1. Introduction 88 This document is defined in the context of Operation Security 89 Framework [12] and Operation Security Current Practice [13]. 91 The Framework for Operation Security Framework outlines the effort of 92 the IETF OPSEC working group. This includes producing a series of 93 drafts to codify knowledge gained through operational experience 94 about capabilities that are needed to securely deploy and operate 95 managed network elements providing transit services at the data link 96 and network layers. 98 This document lists the security capabilities needed for the routing 99 control plane of IP infrastructure to support the practices defined 100 in Operational Security Current Practices. In particular this 101 includes capabilities for route filtering and for authentication of 102 routing protocol packets. 104 Note that this document lists capabilities that can reasonably be 105 expected to be currently deployed in the context of existing 106 standards. Extensions to existing protocol standards and development 107 of new protocol standards are outside of the scope of this effort. 108 The preferred capabilities needed for securing the routing 109 infrastructure may evolve over time. 111 There will be other capabilities which are needed to fully secure a 112 router infrastructure. For example, network management of devices 113 must be secured in order to prevent unauthorized access to or denial 114 of service to the device Network Management Access Security 115 Capabilities [15]. The reader should refer to Operation Security 116 Framework for a more complete list of documents describing 117 operational capabilities for network and link layer devices 118 supporting IP Network Infrastructure. 120 Operational Security Current Practices defines the goals, motivation, 121 scope, definitions, intended audience, threat model, potential 122 attacks and give justifications for each of the practices. 124 1.1. Threat model 126 The capabilities listed in this document are intended to aid in 127 preventing or mitigating the threats outlined in Operation Security 128 Framework and Current Practices. 130 1.2. Format and Definition of Capabilities 132 Each individual capability will be defined using the four elements, 133 "Capability", "Supported Practices", "Current Implementations", and 134 "Considerations", as explained in section 1.7 of Operation Security 135 Framework. 137 1.3. Packet Filtering versus Route Filtering 139 It is useful to make a distinction between Packet Filtering versus 140 Route Filtering. 142 The term "packet filter" is used to refer to the filter that a router 143 applies to network layer packets passing through or destined to it. 144 In general packet filters are based on contents of the network (IP) 145 and transport (TCP,UDP) layers, and are mostly stateless, in the 146 sense that whether or not a filter applies to a particular packet is 147 a function of that packet (including the contents of IP and transport 148 layer headers, size of packet, incoming interface, and similar 149 characteristics), but does not depend upon the contents of other 150 packets which might be part of the same stream (and thus which may 151 also be forwarded by the same router). One common minor exception to 152 the "stateless" nature of packet filters is that packets that match a 153 particular filter may be counted and/or rate limited (the act of 154 counting therefore represents a very simple "state" associated with 155 the filter). 157 Because of the simplicity and stateless nature of packet filters, 158 they can typically be implemented with very high performance. It is 159 not unusual for them to be implemented on line cards and to perform 160 at or near full line rate. For this reason they are very useful to 161 counter very high bandwidth attacks, such as large DDoS attacks. 163 Packet filtering capabilities are outside of the scope of this 164 document. A detailed description of packet filtering capabilities 165 can be found in "Filtering Capabilities for IP Network 166 Infrastructure" [14]. 168 The Term "route filter" is used to refer to filters that routers 169 apply to the content of routing protocol packets that they are either 170 sending or receiving. Typically these therefore occur at the 171 application layer (although which route filters are applied to a 172 particular packet may be a function of network layer information, 173 such as what interface the packet is received on, or the source 174 address for the packet -- indicating the system that transmitted the 175 packet). 177 Route filters are typically implemented in some sort of processor. 178 In many cases the total bandwidth which can be received by the 179 processor is considerably less than the sum of the rate that packets 180 may be received on all interfaces to a router. Therefore in general 181 route filters cannot handle the same bandwidth as packet filters. 183 Route filters are however very useful in that they can be applied to 184 the contents of routing packets. 186 2. Route Filtering Capabilities 188 2.1. General Route Filtering Capabilities 190 2.1.1. Ability to Filter Inbound or Outbound Routes 192 Capability. 194 The device provides the ability to filter which routes may be 195 received in routing protocols (with BGP [10], and with RIP [7] and 196 other distance vector routing protocols), as well as the ability 197 to filter which routes are announced into each routing protocol. 199 Supported Practices. 201 See section 2.4.2 of Current Practices. 203 It is a beneficial practice to configure routing filters in both 204 directions, which will counter potential misconfiguration in each 205 side of peers. Also, incoming route filters will prevent a 206 deliberate attacker to inject invalid routing information. 208 Current Implementations. 210 The unicast routing protocols used with IP can be classified into 211 path vector routing protocols (such as BGP), distance vector 212 protocols (such as RIP) and link state protocols (such as OSPF [4] 213 and IS-IS [1]). Because of difference of protocol mechanism, 214 route filters will affect them in different ways. 216 Take BGP for example, an implementation may check a received route 217 against inbound filters to determine whether to install it into 218 the overall route table or not. Also, it will restrict the routes 219 which will go out to neighbors against outbound route filters. 221 However, as to link state protocols, such as OSPF, a router 222 maintains a topology database and exchanges link state information 223 with neighbors. Since route filters do not influence the link 224 state database, route filters will only affect which routes are 225 advertised into the routing protocol. That is to say, only 226 inbound route filters are effective on link state protocols. 228 Most of the routing protocols support methods to configure route 229 filters which permit or deny learning or advertising of specific 230 routes. 232 Considerations. 234 None. 236 2.1.2. Ability to Filter Routes by Prefix 238 Capability. 240 The device supports filtering routes based on prefix. 242 Supported Practices. 244 See section 2.4.2 of Current Practices. 246 Current Implementations. 248 The filter may include a list of specific prefixes to be accepted 249 or rejected. The filter may alternately include a list of 250 prefixes, such that more specific (longer) prefixes which are 251 included in the more inclusive (shorter) prefix are accepted, 252 rejected, or summarized into the shorter prefix. 254 Considerations. 256 Operators may wish to ignore advertisements for routes to 257 specially used addresses, such as private addresses, reserved 258 addresses and multicast addresses, etc. The up-to-date allocation 259 of IPv4 address space can be found in INTERNET PROTOCOL V4 ADDRESS 260 SPACE [18]. 262 2.2. Route Filtering of Exterior Gateway Protocol 264 An exterior gateway protocol is used to exchange external routing 265 information between different autonomous systems. Since BGP is the 266 actual standard, this section mainly depicts special routing filter 267 capabilities of BGP. 269 2.2.1. Ability to Filter Routes by Route Attributes 271 Capability. 273 The device supports filtering routing updates by route attributes. 275 Supported Practices. 277 See RFC3013 [8] and section 3.2 of RFC2196 [3] and section 2.4.2 278 of Current Practices. 280 Current Implementations. 282 In comparison with other routing protocol, BGP defines various 283 path attributes to describe characteristics of routes. Besides 284 filtering by specific prefixes, BGP could also use some path 285 attributes to precisely filter routes to determine whether a route 286 is accepted from or sent to a neighboring router. 288 These filters may be based upon any combination of route 289 attributes, such as: 291 * Restrictions on the Content of AS_PATH. Restrictions on the 292 contents of the AS PATH are frequently used: for example, the 293 received AS_PATH may be checked to ensure the sending AS is 294 actually contained in the received AS_PATH. 296 * Restrictions on Communities. Implementations could filter 297 received routes based on the set of communities RFC1997 [2] or 298 extended communities RFC4360 [11]. 300 Considerations. 302 None. 304 2.2.2. Ability to Filter Routing Update by TTL 306 Capability. 308 The device should provide a means to filter route packets based on 309 the value of the TTL field in the IPv4 header or the Hop-Limit 310 field in the IPv6 header. 312 Note that "Filtering Capabilities for IP Network Infrastructure" 313 Filtering Capabilities specifies: 315 Capability. 317 The filtering mechanism supports filtering based on the 318 value(s) of any portion of the protocol headers for IP, ICMP, 319 UDP and TCP. 321 The ability to filter based on TTL is therefore a packet filtering 322 capability which is already implicitly covered by the capabilities 323 listed in Filtering Capabilities. Since this capability is 324 particularly important for BGP, we felt that it is worth 325 mentioning here. 327 Supported Practices. 329 See Current Practices section 2.4.2 and RFC3682 [9]. 331 Current Implementations. 333 Most current BGP implementations support this capability to 334 protect BGP sessions. 336 Considerations. 338 There will be situations in which the distance to the neighboring 339 router is more than one hop away. This for example is common for 340 I-BGP. 342 2.2.3. Ability to Limit the Number of Routes from a Peer 344 Capability. 346 The device should provide a means to configure the maximum number 347 of routes (prefixes) to accept from a peer. 349 Supported Practices. 351 Both routing policy misconfiguration and a deliberate attack from 352 a peer may cause too many routes to be sent to a peer which may 353 exhaust memory resources of the router, introduce routing 354 instability into the overall routing table, or both. Therefore, 355 operators may want to restrict the amount of routes received from 356 a particular peer router through a maximum prefix limitation 357 approach. 359 Current Implementations. 361 Most BGP implementations support this capability. If too many 362 routes are sent, then the router may reset the BGP session or may 363 reject excess routes. In either case the device may log the 364 failure event (at a minimum), or shut down the BGP session. 366 Considerations. 368 Operators must be cognizant of the need to allow for valid swings 369 in routing announcements between themselves, and as such should 370 always set the max-prefix limit to some agreed upon number plus a 371 sane amount for overhead to allow for these necessary announcement 372 swings. Individual implementations amongst ISPs are unique, and 373 depending on equipment supplier(s) different implementation 374 options are available. Most equipment vendors offer 375 implementation options ranging from just logging excessive 376 prefixes being received to automatically shutting down the 377 session. If the option of reestablishing a session after some 378 pre-configured idle timeout has been reached is available, it 379 should be understood that automatically reestablishing the session 380 may continuously introduce instability into the overall routing 381 table if a policy misconfiguration on the adjacent neighbor is 382 causing the condition. If a serious misconfiguration on a peering 383 neighbor has occurred then automatically shutting down the session 384 and leaving it shut down until being manually cleared is perhaps 385 best and allows for operator intervention to correct as needed. 387 2.2.4. Ability to Limit the Length of Prefixes 389 Capability. 391 The device has the capability to allow filtering route updates by 392 prefix length. 394 Supported Practices. 396 Some large ISPs declare in their peer BGP policies that they will 397 not accept the announcements whose prefix length is longer than a 398 specific threshold. 400 Current Implementations. 402 Most BGP implementations support this capability. 404 Considerations. 406 None. 408 2.2.5. Ability to Cooperate in Outbound Route Filtering 410 Capability. 412 A device provides the capability to allow operators to configure 413 whether "Outbound Route Filtering"/ORF [17] are accepted from or 414 sent to other peer routers. 416 Supported Practices 418 "Outbound Route Filtering" defines a BGP mechanism to reduce the 419 number of BGP updates between BGP peers. It will conserve the 420 resource in both sides of peers, since the BGP speaker will not 421 generate updates that will be filtered and the neighbor router 422 will not process them as well. A router with limited resource may 423 need this feature to prevent overfull routes from peers. 425 Current Implementations. 427 ORF may be based on prefix, path attributes. Currently, most 428 implementations support prefix-based ORF. 430 Considerations. 432 None. 434 2.3. Route Filtering of Interior Gateway Protocols 436 This section describes route filtering as it may be applied to OSPF 437 and IS-IS when used as the interior gateway protocol (Internal 438 Gateway Protocol or "IGP") used within a routing domain. 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 469 If filters are used which restrict the passing of routes between 470 IGP areas, then this may result in some addresses being 471 unreachable from some other areas within the same routing domain. 473 It is normal when passing routes into the backbone area (area 474 O.0.0.0 in OSPF, or the level 2 backbone in IS-IS) for routes to 475 be summarized, in the sense that multiple more specific (longer) 476 address prefixes that are reachable in an area may be summarized 477 into a smaller number of less specific (shorter) address prefixes. 478 This provides important scaling improvements, but is generally not 479 primarily intended to aid in security and is therefore outside of 480 the scope of this document. 482 2.4. Route Filtering during Redistribution 484 Capability. 486 The device provides a means to filter routes when distributing 487 them between routing protocols or between routing protocol 488 processes running in the single device. 490 Supported Practices. 492 Route redistribution bridges between different route domains and 493 improves the flexibility of routing system. This allows for the 494 transmission of reachable destinations learned in one protocol 495 through another protocol. However, without careful consideration 496 it may lead to looping or black holes as well. 498 Filters is always needed when routes redistributing between IGP 499 and BGP. For example, it is unfeasible to inject all internet 500 routes from BGP to IGPs, since IGPs are not able to deal with such 501 a large number of routes. 503 Current Implementations. 505 Most implementations allow applying a filter based on a prefix 506 list to control redistribution. 508 Considerations 510 TBD. 512 3. Route Authentication Capabilities 513 3.1. Ability to configure an authentication mechanism 515 Capabilities. 517 The device has one or more methods to allow the routing protocol 518 to be configured an authentication mechanism (authentication keys 519 and authentication algorithms). 521 Supported Practices. 523 See Current Practices section 2.4.2. 525 Current Implementations. 527 RFC2385 [5] is deployed widely in BGP. Other routing protocols, 528 such as OSPF, adopt similar technology. 530 Consideration. 532 In most of current implementations, neither the authentication 533 mechanism nor key can be negotiated. An operator has to configure 534 it manually, which will affect scalability. 536 To the date of writing this draft, MD5 is the only cryptographic 537 hash function used in route authentication. However, recent 538 research revealed weakness of MD5, which means stronger algorithms 539 are necessary. 541 3.2. Ability to support authentication key chains 543 Capabilities. 545 The device provides a key chain mechanism to update authentication 546 keys of routing protocols. 548 Supported Practices. 550 Using a fixed authentication key is vulnerable to a compromise. A 551 key chain is a series of keys which will be used in configured 552 time intervals. A device can transit keys based on system time 553 and configured key chain. In this way, it reduces possibility of 554 leakage of an authentication key. 556 Current Implementations. 558 This mechanism could be implemented in most routing protocols. 559 Different vendors provide this feature in different routing 560 protocols, such as RIP, OSPF and BGP. 562 Consideration. 564 None. 566 4. Ability to Damp Route Flap 568 Capability. 570 The device provides the capability to damp route flaps. 572 Supported Practices. 574 The function to damp route flaps may enhance the stability of 575 routing system and minimize the influence of flapping. It is 576 useful to counter against some DoS attacks. 578 Current Implementations. 580 BGP RFD (Route Flap Damping) RFC2439 [6] defined the primary 581 mechanism in BGP to mitigate the influence caused by flapping. 582 Most of current BGP implementations support this capability. 584 Other routing protocols may be vulnerable to route flaps as well. 585 Some vendors introduce SPF (shortest path first) algorithm timers 586 in OSPF to control parameters, such as the amount of minimal time 587 between consecutive SPF calculations, which may be used to 588 mitigate excessive resource exhaustion caused by link flaps. 590 Consideration. 592 MAO [19] described a flaw of current BGP RFD standard RFC2439, 593 which shows that route flap damping could suppress relatively 594 stable routes and affect routing convergence. 596 Since none of vendors has corrected his BGP implementation, 597 RIPE378 [20] proposes that, with the current implementations of 598 BGP flap damping, the application of flap damping in ISP networks 599 is not recommended. 601 5. Resource Availability for Router Control Functions 603 5.1. Ensure Resources for Management Functions 605 Capability. 607 This capability specifies that device implementations ensure that 608 at least a certain minimum sufficient level of resources are 609 available for management functions. This may include such 610 resources as memory, processor cycle, data structure and/or 611 bandwidth at ingress to the device, on egress from the device, for 612 internal transmission and processing. This may include at least 613 protocols used for configuration, monitoring, configuration 614 backup, logging, time synchronization, authentication and 615 authorization. 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 such 661 resources as memory, processor cycle, data structure and bandwidth 662 at ingress to the device, on egress from the device, for internal 663 transmission, and processing. This may include at least protocols 664 used for routing protocol operation, including resources used for 665 routing HELLO packets for BGP, IS-IS, and OSPF. 667 Supported Practices. 669 Certain attacks (and normal operation) can cause resource 670 saturation such as link congestion, memory exhaustion or CPU 671 overload. In these cases it is important that resources be 672 available for the operation of routing protocols in order to 673 ensure that the network continues to operate (for example, that 674 routes can be computed in order to allow management traffic to be 675 delivered). For many routing protocols the loss of HELLO packets 676 can cause the protocol to drop adjacencies and/or to send out 677 additional routing packets, potentially destabilizing the routing 678 protocol and/or adding to whatever congestion may be causing the 679 problem. 681 Current Implementations. 683 How this is implemented depend upon the details of the device. 684 There are a variety of ways that this may be ensured such as 685 prioritizing routing functions in comparison with other functions 686 performed by the device, providing separate queues for routing 687 traffic, use of operating systems or other methods that partition 688 resources between processes or functions, and so on. 690 Consideration. 692 For example, if routing HELLO packets are not prioritized, then it 693 is possible during DoS attacks or during severe network congestion 694 for routing protocols to drop HELLO packets, causing routing 695 adjacencies to be lost. This in turn can cause overall failure of 696 a network. A DoS attack against hosts can therefore become a DoS 697 attack against the network. 699 Guaranteeing resources within routers is not a panacea. Routing 700 packets may not make it across a saturated link (thus for example 701 it may also be desirable to prioritize routing packets for 702 transmission across link layer devices such as Ethernet switches). 703 This requirement simply says that the device should prioritize 704 routing functions within its scope of control (e.g., ingress, 705 egress, internal transit, processing). To the extent that this is 706 done across an entire network, the overall effect will be to 707 ensure that the network continues to operate. 709 5.3. Limit Resources used by IP Multicast 711 Capability. 713 This capability specifies that some mechanism(s) is provided to 714 allow the control plane resources used by IP multicast, including 715 processing and memory, to be limited to some level which is less 716 than 100% of the total available processing and memory. In some 717 cases the maximum limit of resources used by multicast may be 718 configurable. Routers may also provide a mechanism(s) to allow 719 the amount of link bandwidth consumed by IP multicast on any 720 particular link to be limited to some level which is less than 721 100% of total available bandwidth on that link. 723 Supported Practices. 725 IP multicast has characteristics which may potentially impact the 726 availability of IP networks. In particular, IP multicast requires 727 that routers perform control plane processing and maintain state 728 in response to data plane traffic. Also, the use of multicast 729 implies that a single packet input into the network can result in 730 a large number of packets being delivered throughout the network. 731 Also, it is possible in some situations for a multicast traffic to 732 *both* enter a loop, and also be delivered to some destinations 733 (implying that many copies of the same packet could be delivered). 735 Current Implementations. 737 TBD 739 Consideration. 741 If the amount of resources used by multicast are not limited, then 742 it is possible during an attack for multicast to consume 743 potentially as much as 100% of available memory, processing, or 744 bandwidth resources, thereby causing network problems. 746 6. Security Considerations 748 Security is the subject matter of this entire document. This 749 document lists device capabilities intended to improve the ability of 750 the network to withstand security threats. Operational Security 751 Current Practices defines the threat model and practices, and lists 752 justifications for each practice. 754 7. Acknowledgements 756 The authors gratefully acknowledge the contributions of Ron Bonica, 757 Ted Seely, Pat Cain, George Jones, and Russ White etc for their 758 contributed texts, useful comments and suggestions. 760 8. References 762 8.1. Normative References 764 [1] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual 765 environments", RFC 1195, December 1990. 767 [2] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities 768 Attribute", RFC 1997, August 1996. 770 [3] Fraser, B., "Site Security Handbook", RFC 2196, September 1997. 772 [4] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 774 [5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 775 Signature Option", RFC 2385, August 1998. 777 [6] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap 778 Damping", RFC 2439, November 1998. 780 [7] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998. 782 [8] Killalea, T., "Recommended Internet Service Provider Security 783 Services and Procedures", BCP 46, RFC 3013, November 2000. 785 [9] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL 786 Security Mechanism (GTSM)", RFC 3682, February 2004. 788 [10] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 789 (BGP-4)", RFC 4271, January 2006. 791 [11] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 792 Communities Attribute", RFC 4360, February 2006. 794 8.2. Informative References 796 [12] Jones, G., "Framework for Operational Security Capabilities for 797 IP Network Infrastructure", draft-ietf-opsec-framework-03 798 (work in progress), July 2006. 800 [13] Kaeo, M., "Operational Security Current Practices", 801 draft-ietf-opsec-current-practices-07 (work in progress), 802 August 2006. 804 [14] Morrow, C., "Filtering and Rate Limiting Capabilities for IP 805 Network Infrastructure", draft-ietf-opsec-filter-caps-04 (work 806 in progress), September 2006. 808 [15] Bonica, R. and S. Ahmed, "Network Management Access Security 809 Capabilities", draft-ietf-opsec-nmasc-00 (work in progress), 810 March 2006. 812 [16] Callon, R. and G. Jones, "Miscellaneous Capabilities for IP 813 Network Infrastructure", draft-ietf-opsec-misc-cap-00 (work in 814 progress), February 2006. 816 [17] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability 817 for BGP-4", draft-ietf-idr-route-filter-16 (work in progress), 818 September 2006. 820 [18] IANA, "INTERNET PROTOCOL V4 ADDRESS SPACE", 2006. 822 [19] Mao, Z., Govindan, R., Varghese, G., and R. Katz, "Route Flap 823 Damping Exacerbates Internet Routing Convergence", 2002. 825 [20] RIPE, "Recommendations on Route-flap Damping", May 2006. 827 Authors' Addresses 829 Zhao Ye 830 Huawei Technologies 831 No. 3, Xinxi Rd 832 Shangdi Information Industry Base 833 Haidian District, Beijing 100085 834 P. R. China 836 Email: ye.zhao_ietf@hotmail.com 837 Miao Fuyou 838 Huawei Technologies 839 No. 3, Xinxi Rd 840 Shangdi Information Industry Base 841 Haidian District, Beijing 100085 842 P. R. China 844 Phone: +86 10 8288 2008 845 Email: miaofy@huawei.com 847 Ross W. Callon 848 Juniper Networks 849 10 Technology Park Drive 850 Westford, MA 01886 851 USA 853 Email: rcallon@juniper.net 855 Full Copyright Statement 857 Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST AND 866 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 867 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 868 THE 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).