idnits 2.17.1 draft-ietf-opsec-routing-capabilities-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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 858. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 869. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 876. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 882. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (April 5, 2007) is 6231 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 3682 (Obsoleted by RFC 5082) == Outdated reference: A later version (-09) exists of draft-ietf-opsec-filter-caps-06 == Outdated reference: A later version (-17) exists of draft-ietf-idr-route-filter-16 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 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: Best Current Huawei Technologies 5 Practice R. Callon 6 Expires: October 7, 2007 Juniper Networks 7 April 5, 2007 9 Routing Control Plane Security Capabilities 10 draft-ietf-opsec-routing-capabilities-02.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 October 7, 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 . . . . . . . . . 3 56 2. Route Filtering Capabilities . . . . . . . . . . . . . . . . . 4 57 2.1. General Route Filtering Capabilities . . . . . . . . . . . 4 58 2.1.1. Ability to Filter Inbound or Outbound Routes . . . . . 4 59 2.1.2. Ability to Filter Routes by Prefix . . . . . . . . . . 5 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 . . . . . 11 72 3.2. Ability to support authentication key chains . . . . . . . 12 73 4. Ability to Damp Route Flap . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . 14 77 5.3. Limit Resources used by IP Multicast . . . . . . . . . . . 15 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 85 Intellectual Property and Copyright Statements . . . . . . . . . . 20 87 1. Introduction 89 This document is defined in the context of [I-D.ietf-opsec-framework] 90 and [RFC4778]. 92 This document lists the security capabilities needed for the routing 93 control plane of IP infrastructure to support the practices defined 94 in [I-D.ietf-opsec-framework]. In particular this includes 95 capabilities for route filtering and for authentication of routing 96 protocol packets. 98 Note that this document lists capabilities that can reasonably be 99 expected to be currently deployed in the context of existing 100 standards. Extensions to existing protocol standards and development 101 of new protocol standards are outside of the scope of this effort. 102 The preferred capabilities needed for securing the routing 103 infrastructure may evolve over time. 105 There will be other capabilities which are needed to fully secure a 106 router infrastructure. [RFC4778] defines the goals, motivation, 107 scope, definitions, intended audience, threat model, potential 108 attacks and give justifications for each of the practices. 110 1.1. Threat model 112 The capabilities listed in this document are intended to aid in 113 preventing or mitigating the threats outlined in 114 [I-D.ietf-opsec-framework]. 116 1.2. Format and Definition of Capabilities 118 Each individual capability will be defined using the four elements, 119 "Capability", "Supported Practices", "Current Implementations", and 120 "Considerations", as explained in section 1.7 of 121 [I-D.ietf-opsec-framework]. 123 1.3. Packet Filtering versus Route Filtering 125 It is useful to make a distinction between Packet Filtering versus 126 Route Filtering. 128 The term "packet filter" is used to refer to the filter that a router 129 applies to network layer packets passing through or destined to it. 130 In general packet filters are based on contents of the network (IP) 131 and transport (TCP, UDP) layers, and are mostly stateless, in the 132 sense that whether or not a filter applies to a particular packet is 133 a function of that packet (including the contents of IP and transport 134 layer headers, size of packet, incoming interface, and similar 135 characteristics), but does not depend upon the contents of other 136 packets which might be part of the same stream (and thus which may 137 also be forwarded by the same router). One common minor exception to 138 the "stateless" nature of packet filters is that packets that match a 139 particular filter may be counted and/or rate limited (the act of 140 counting therefore represents a very simple "state" associated with 141 the filter). 143 Because of the simplicity and stateless nature of packet filters, 144 they can typically be implemented with very high performance. It is 145 not unusual for them to be implemented on line cards and to perform 146 at or near full line rate. For this reason they are very useful to 147 counter very high bandwidth attacks, such as large DDoS attacks. 149 Packet filtering capabilities are outside of the scope of this 150 document. A detailed description of packet filtering capabilities 151 can be found in [I-D.ietf-opsec-filter-caps]. 153 The Term "route filter" is used to refer to filters that routers 154 apply to the content of routing protocol packets that they are either 155 sending or receiving. Typically these therefore occur at the 156 application layer (although which route filters are applied to a 157 particular packet may be a function of network layer information, 158 such as what interface the packet is received on, or the source 159 address for the packet -- indicating the system that transmitted the 160 packet). 162 Route filters are typically implemented in some sort of processor. 163 In many cases the total bandwidth which can be received by the 164 processor is considerably less than the sum of the rate that packets 165 may be received on all interfaces to a router. Therefore in general 166 route filters cannot handle the same bandwidth as packet filters. 167 Route filters are however very useful in that they can be applied to 168 the contents of routing packets. 170 2. Route Filtering Capabilities 172 2.1. General Route Filtering Capabilities 174 2.1.1. Ability to Filter Inbound or Outbound Routes 176 Capability. 178 The device provides the ability to filter which routes may be 179 received with [RFC4271], as well as the ability to filter which 180 routes are announced into each routing protocol. 182 Supported Practices. 184 See section 2.4.2 of [RFC4778]. 186 It is a beneficial practice to configure routing filters in both 187 directions, which will counter potential misconfiguration in 188 either peer. Also, incoming route filters will prevent a 189 deliberate attacker from injecting invalid routing information. 191 Current Implementations. 193 The unicast routing protocols used with IP can be classified into 194 path vector routing protocols (such as BGP), distance vector 195 protocols (such as [RFC2453]) and link state protocols (such as 196 [RFC2328] and [RFC1195]). Because of differences in the 197 protocols, route filters will affect them in different ways. 199 Take BGP for example, an implementation may check a received route 200 against inbound filters to determine whether to install it into 201 the overall route table or not. Also, it will restrict the routes 202 which will go out to neighbors against outbound route filters. 204 However, as to link state protocols, such as OSPF, a router 205 maintains a topology database and exchanges link state information 206 with neighbors. Since route filters do not influence the link 207 state database, route filters will only affect which routes are 208 advertised into the routing protocol. That is to say, only 209 inbound route filters are effective on link state protocols. 211 Most of the routing protocols support methods to configure route 212 filters which permit or deny learning or advertising of specific 213 routes. 215 Considerations. 217 None. 219 2.1.2. Ability to Filter Routes by Prefix 221 Capability. 223 The device supports filtering routes based on prefix. 225 Supported Practices. 227 See section 2.4.2 of [RFC4778]. 229 Current Implementations. 231 The filter may include a list of specific prefixes to be accepted 232 or rejected. The filter may alternately include a list of 233 prefixes, such that more specific (longer) prefixes, which are 234 included in the more inclusive (shorter) prefix, are accepted, 235 rejected, or summarized into the shorter prefix. 237 Considerations. 239 Operators may wish to ignore advertisements for routes to specific 240 addresses, such as private addresses, reserved addresses and 241 multicast addresses, etc. The up-to-date allocation of IPv4 242 address space can be found in [IANA]. 244 2.2. Route Filtering of Exterior Gateway Protocol 246 An exterior gateway protocol is used to exchange external routing 247 information between different autonomous systems. Since BGP is the 248 most widely used protocol, this section mainly depicts special 249 routing filter capabilities of BGP. 251 2.2.1. Ability to Filter Routes by Route Attributes 253 Capability. 255 The device supports filtering routing updates by route attributes. 257 Supported Practices. 259 See [RFC3013] , section 3.2 of[RFC2196] and section 2.4.2 of 260 [RFC4778]. 262 Current Implementations. 264 In comparison with other routing protocols, BGP defines various 265 path attributes to describe characteristics of routes. Besides 266 filtering by specific prefixes, BGP also provides capability to 267 use some path attributes to precisely filter routes to determine 268 whether a route is accepted from or sent to a neighboring router. 270 These filters may be based upon any combination of route 271 attributes, such as: 273 * Restrictions on the Content of AS_PATH. Restrictions on the 274 contents of the AS PATH are frequently used: for example, the 275 received AS_PATH may be checked to ensure the sending AS is 276 actually contained in the received AS_PATH. 278 * Restrictions on Communities. Implementations could filter 279 received routes based on the set of communities [RFC1997] or 280 extended communities [RFC4360]. 282 Considerations. 284 None. 286 2.2.2. Ability to Filter Routing Update by TTL 288 Capability. 290 The device should provide a means to filter route packets based on 291 the value of the TTL field in the IPv4 header or the Hop-Limit 292 field in the IPv6 header. 294 Note that [I-D.ietf-opsec-filter-caps] specifies: 296 Capability. 298 The filtering mechanism supports filtering based on the 299 value(s) of any portion of the protocol headers for IP, ICMP, 300 UDP and TCP. 302 The ability to filter based on TTL is therefore a packet filtering 303 capability which is already implicitly covered by the capabilities 304 listed in Filtering Capabilities. Since this capability is 305 particularly important for BGP, we felt that it is worth 306 mentioning here. 308 Supported Practices. 310 See [RFC4778] section 2.4.2 and [RFC3682]. 312 Current Implementations. 314 Most current BGP implementations support this capability to 315 protect BGP sessions. 317 Considerations. 319 There will be situations in which the distance to the neighboring 320 router is more than one hop away. This for example is common for 321 I-BGP. 323 2.2.3. Ability to Limit the Number of Routes from a Peer 325 Capability. 327 The device should provide a means to configure the maximum number 328 of routes (prefixes) to accept from a peer. 330 Supported Practices. 332 Both routing policy misconfiguration and a deliberate attack from 333 a peer may cause too many routes to be sent to a peer which may 334 exhaust the memory resources of the router, introduce routing 335 instability into the overall routing table, or both. Therefore, 336 operators may want to restrict the amount of routes received from 337 a particular peer router through a maximum prefix limitation 338 approach. 340 Current Implementations. 342 Most BGP implementations support this capability. If too many 343 routes are sent, then the router may reset the BGP session or may 344 reject excess routes. In either case the device may log the 345 failure event (at a minimum), or shut down the BGP session. 347 Considerations. 349 Operators must be cognizant of the need to allow for valid swings 350 in routing announcements between themselves, and as such should 351 always set the max-prefix limit to some agreed upon number plus a 352 sane amount for overhead to allow for these necessary announcement 353 swings. Individual implementations amongst ISPs are unique, and 354 depending on equipment supplier(s) different implementation 355 options are available. Most equipment vendors offer 356 implementation options ranging from just logging excessive 357 prefixes being received to automatically shutting down the 358 session. If the option of reestablishing a session after some 359 pre-configured idle timeout has been reached is available, it 360 should be understood that automatically reestablishing the session 361 may continuously introduce instability into the overall routing 362 table if a policy misconfiguration on the adjacent neighbor is 363 causing the condition. If a serious misconfiguration on a peering 364 neighbor has occurred then automatically shutting down the session 365 and leaving it shut down until being manually cleared is perhaps 366 best and allows for operator intervention to correct as needed. 368 2.2.4. Ability to Limit the Length of Prefixes 370 Capability. 372 The device has the capability to allow filtering of route updates 373 by prefix length. 375 Supported Practices. 377 Some large ISPs declare in their peer BGP policies that they will 378 not accept the announcements whose prefix length is longer than a 379 specific threshold. 381 Current Implementations. 383 Most BGP implementations support this capability. 385 Considerations. 387 None. 389 2.2.5. Ability to Cooperate in Outbound Route Filtering 391 Capability. 393 A device provides the capability to allow operators to configure 394 whether Outbound Route Filtering/ORF defined in 395 [I-D.ietf-idr-route-filter] are accepted from or sent to other 396 peer routers. 398 Supported Practices 400 "Outbound Route Filtering" defines a BGP mechanism to reduce the 401 number of BGP updates between BGP peers. It will conserve the 402 resource in both sides of peers, since the BGP speaker will not 403 generate updates that will be filtered and the neighbor router 404 will not process them as well. A router with limited resource may 405 need this feature to prevent overfull routes from peers. 407 Current Implementations. 409 ORF may be based on prefix, path attributes. Currently, most 410 implementations support prefix-based ORF. 412 Considerations. 414 None. 416 2.3. Route Filtering of Interior Gateway Protocols 418 This section describes route filtering as it may be applied to OSPF 419 and IS-IS when used as the interior gateway protocol (Internal 420 Gateway Protocol or IGP) used within a routing domain. 422 2.3.1. Route Filtering Within an IGP Area 424 A critical design principle of OSPF and IS-IS is that each router 425 within an area has the same view of the topology, thereby allowing 426 consistent routes to be computed by all routers within the area. For 427 this reason, all properly authenticated (if applicable) routing 428 topology advertisements (Link State Advertisements or LSAs in OSPF, 429 or Link State Packets or LSPs in IS-IS) are flooded unchanged 430 throughout the area. Route filtering within an OSPF or IS-IS area is 431 therefore not appropriate. 433 2.3.2. Route Filtering Between IGP Areas 435 Capability. 437 The device provides the capability to allow the network operator 438 to configure route filters which restrict which routes (i.e, 439 address prefixes) are advertised into areas from outside of the 440 area (i.e., from other OSPF or IS-IS areas). 442 Supported Practices. 444 See section 2.4.2 of [RFC4778]. 446 Current Implementations. 448 Some OSPF/IS-IS implementations support this capability. 450 Considerations 452 If filters are used which restrict the passing of routes between 453 IGP areas, then this may result in some addresses being 454 unreachable from some other areas within the same routing domain. 456 It is normal when passing routes into the backbone area (area 457 0.0.0.0 in OSPF, or the level 2 backbone in IS-IS) for routes to 458 be summarized, in the sense that multiple more specific (longer) 459 address prefixes that are reachable in an area may be summarized 460 into a smaller number of less specific (shorter) address prefixes. 461 This provides important scaling improvements, but is generally not 462 primarily intended to aid in security and is therefore outside of 463 the scope of this document. 465 2.4. Route Filtering during Redistribution 467 Capability. 469 The device provides a means to filter routes when distributing 470 them between routing protocols or between routing protocol 471 processes running in the single device. 473 Supported Practices. 475 Route redistribution bridges between different route domains and 476 improves the flexibility of routing system. This allows for the 477 transmission of reachable destinations learned in one protocol 478 through another protocol. However, without careful consideration 479 it may lead to looping or black holes as well. 481 Filters are always needed when routes redistributing between IGP 482 and EGP. For example, it is infeasible to inject all Internet 483 routes from EGP to IGPs, since IGPs are not able to deal with such 484 a large number of routes. 486 Current Implementations. 488 Most implementations allow applying a filter based on a prefix 489 list to control redistribution. 491 Considerations 493 None. 495 3. Route Authentication Capabilities 497 3.1. Ability to configure an authentication mechanism 499 Capabilities. 501 The device has one or more methods to allow an authentication 502 mechanism to be configured for the routing protocol. 504 Supported Practices. 506 See [RFC4778] section 2.4.2. 508 Current Implementations. 510 [RFC2385] is deployed widely in BGP. Other routing protocols, 511 such as OSPF, adopt similar technology. 513 Consideration. 515 In most of current implementations, neither the authentication 516 mechanism nor key can be negotiated. An operator has to configure 517 it manually, which will affect scalability. 519 As of this writing, MD5 is the only cryptographic hash function 520 used in route authentication. However, recent research revealed 521 weakness of MD5, which means stronger algorithms are necessary. 523 3.2. Ability to support authentication key chains 525 Capabilities. 527 The device provides a key chain mechanism to update authentication 528 keys of routing protocols. 530 Supported Practices. 532 Using a fixed authentication key is vulnerable to a compromise. A 533 key chain is a series of keys which will be used in configured 534 time intervals. A device can transit keys based on system time 535 and configured key chain. In this way, it reduces possibility of 536 leakage of an authentication key. 538 Current Implementations. 540 This mechanism is implemented in most routing protocols. 541 Different vendors provide this feature in different routing 542 protocols, such as RIP, OSPF and BGP. 544 Consideration. 546 Since the rollover of the key is based on system time on different 547 routers, it requires clock synchronization across the routers. 549 4. Ability to Damp Route Flap 551 Capability. 553 The device provides the capability to damp route flaps. 555 Supported Practices. 557 The function to damp route flaps may enhance the stability of 558 routing system and minimize the influence of flapping. It is 559 useful to counter against some DoS attacks. 561 Current Implementations. 563 BGP RFD (Route Flap Damping) of [RFC2439] defines the primary 564 mechanism in BGP to mitigate the influence caused by flapping. 565 Most of current BGP implementations support this capability. 567 Other routing protocols may be vulnerable to route flaps as well. 568 Some vendors introduce SPF (shortest path first) algorithm timers 569 in OSPF to control parameters, such as the amount of minimal time 570 between consecutive SPF computations, which may be used to 571 mitigate excessive resource exhaustion caused by link flaps. 573 Consideration. 575 [MAO] described a flaw of current BGP RFD standard RFC2439, which 576 shows that route flap damping could suppress relatively stable 577 routes and affect routing convergence. 579 Since, at the time of this writing, no vendors are known to have 580 fixed this problem, [RIPE378] proposes that, with the current 581 implementations of BGP flap damping, the application of flap 582 damping in ISP networks is not recommended. 584 5. Resource Availability for Router Control Functions 586 5.1. Ensure Resources for Management Functions 588 Capability. 590 This capability specifies that device implementations ensure that 591 at least a certain minimum sufficient level of resources are 592 available for management functions. This may include such 593 resources as memory, processor cycle, data structure and/or 594 bandwidth at ingress to the device, on egress from the device, for 595 internal transmission and processing. This may include at least 596 protocols used for configuration, monitoring, configuration 597 backup, logging, time synchronization, authentication and 598 authorization. 600 Supported Practices. 602 Certain attacks (and normal operation) can cause resource 603 saturation such as link congestion, memory exhaustion or CPU 604 overload. In these cases it is important that resources be 605 available for management functions in order to ensure that 606 operators have the tools needed to recover from the attack. 608 Current Implementations. 610 How this is implemented depend upon the details of the device. 611 There are a variety of ways that this may be ensured such as 612 prioritizing management functions in comparison with other 613 functions performed by the device, providing separate queues for 614 management traffic, use of operating systems or other methods that 615 partition resources between processes or functions, and so on. 617 Consideration. 619 Imagine a service provider with 1,000,000 DSL subscribers, most of 620 whom have no firewall protection. Imagine that a large portion of 621 these subscribers machines were infected with a new worm that 622 enabled them to be used in coordinated fashion as part of large 623 denial of service attack that involved flooding. It is entirely 624 possible that such an attack could in some cases cause processor 625 saturation or other internal resource saturation on routers 626 causing the routers to become unmanageable. A DoS attack against 627 hosts could therefore become a DoS attack against the network. 629 Guarantee of resources within an individual device is not a 630 panacea. Control packets may not make it across a saturated link. 631 This requirement simply says that the device should ensure 632 resources for management functions within its scope of control 633 (e.g., ingress, egress, internal transit, processing). To the 634 extent that this is done across an entire network, the overall 635 effect will be to ensure that the network remains manageable. 637 5.2. Ensure Resources for Routing Functions 639 Capability. 641 This capability specifies that a device implementation ensures at 642 least a certain minimum sufficient level of resources are 643 available for routing protocol functions. This may include such 644 resources as memory, processor cycle, data structure and bandwidth 645 at ingress to the device, on egress from the device, for internal 646 transmission, and processing. This may include at least protocols 647 used for routing protocol operation, including resources used for 648 routing HELLO packets for BGP, IS-IS, and OSPF. 650 Supported Practices. 652 Certain attacks (and normal operation) can cause resource 653 saturation such as link congestion, memory exhaustion or CPU 654 overload. In these cases it is important that resources be 655 available for the operation of routing protocols in order to 656 ensure that the network continues to operate (for example, that 657 routes can be computed in order to allow management traffic to be 658 delivered). For many routing protocols the loss of HELLO packets 659 can cause the protocol to drop adjacencies and/or to send out 660 additional routing packets, potentially destabilizing the routing 661 protocol and/or adding to whatever congestion may be causing the 662 problem. 664 Current Implementations. 666 How this is implemented depend upon the details of the device. 667 There are a variety of ways that this may be ensured such as 668 prioritizing routing functions in comparison with other functions 669 performed by the device, providing separate queues for routing 670 traffic, use of operating systems or other methods that partition 671 resources between processes or functions, and so on. 673 Consideration. 675 For example, if routing HELLO packets are not prioritized, then it 676 is possible during DoS attacks or during severe network congestion 677 for routing protocols to drop HELLO packets, causing routing 678 adjacencies to be lost. This in turn can cause overall failure of 679 a network. A DoS attack against hosts can therefore become a DoS 680 attack against the network. 682 Guaranteeing resources within routers is not a panacea. Routing 683 packets may not make it across a saturated link (thus for example 684 it may also be desirable to prioritize routing packets for 685 transmission across link layer devices such as Ethernet switches). 686 This requirement simply says that the device should prioritize 687 routing functions within its scope of control (e.g., ingress, 688 egress, internal transit, processing). To the extent that this is 689 done across an entire network, the overall effect will be to 690 ensure that the network continues to operate. 692 5.3. Limit Resources used by IP Multicast 694 Capability. 696 This capability specifies that some mechanism(s) is provided to 697 allow the control plane resources used by IP multicast, including 698 processing and memory, to be limited to some level which is less 699 than 100% of the total available processing and memory. In some 700 cases the maximum limit of resources used by multicast may be 701 configurable. Routers may also provide a mechanism(s) to allow 702 the amount of link bandwidth consumed by IP multicast on any 703 particular link to be limited to some level which is less than 704 100% of total available bandwidth on that link. 706 Supported Practices. 708 IP multicast has characteristics which may potentially impact the 709 availability of IP networks. In particular, IP multicast requires 710 that routers perform control plane processing and maintain state 711 in response to data plane traffic. Also, the use of multicast 712 implies that a single packet input into the network can result in 713 a large number of packets being delivered throughout the network. 714 Also, it is possible in some situations for a multicast traffic to 715 *both* enter a loop, and also be delivered to some destinations 716 (implying that many copies of the same packet could be delivered). 718 Current Implementations. 720 None. 722 Consideration. 724 If the amount of resources used by multicast are not limited, then 725 it is possible during an attack for multicast to consume 726 potentially as much as 100% of available memory, processing, or 727 bandwidth resources, thereby causing network problems. 729 6. Security Considerations 731 Security is the subject matter of this entire document. This 732 document lists device capabilities intended to improve the ability of 733 the network to withstand security threats. Operational Security 734 Current Practices defines the threat model and practices, and lists 735 justifications for each practice. 737 7. IANA Considerations 739 This document has no actions for IANA. 741 8. Acknowledgements 743 The authors gratefully acknowledge the contributions of Ron Bonica, 744 Ted Seely, Pat Cain, George Jones, and Russ White etc for their 745 contributed texts, useful comments and suggestions. 747 9. References 748 9.1. Normative References 750 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 751 dual environments", RFC 1195, December 1990. 753 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 754 Communities Attribute", RFC 1997, August 1996. 756 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 758 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 759 Signature Option", RFC 2385, August 1998. 761 [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route 762 Flap Damping", RFC 2439, November 1998. 764 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 765 November 1998. 767 [RFC3013] Killalea, T., "Recommended Internet Service Provider 768 Security Services and Procedures", BCP 46, RFC 3013, 769 November 2000. 771 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 772 Protocol 4 (BGP-4)", RFC 4271, January 2006. 774 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 775 Communities Attribute", RFC 4360, February 2006. 777 9.2. Informative References 779 [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, 780 September 1997. 782 [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL 783 Security Mechanism (GTSM)", RFC 3682, February 2004. 785 [RFC4778] Kaeo, M., "Operational Security Current Practices in 786 Internet Service Provider Environments", RFC 4778, 787 January 2007. 789 [I-D.ietf-opsec-framework] 790 Jones, G., "Framework for Operational Security 791 Capabilities for IP Network Infrastructure", 792 draft-ietf-opsec-framework-05 (work in progress), 793 April 2007. 795 [I-D.ietf-opsec-filter-caps] 796 Morrow, C., "Filtering and Rate Limiting Capabilities for 797 IP Network Infrastructure", 798 draft-ietf-opsec-filter-caps-06 (work in progress), 799 April 2007. 801 [I-D.ietf-idr-route-filter] 802 Chen, E. and Y. Rekhter, "Outbound Route Filtering 803 Capability for BGP-4", draft-ietf-idr-route-filter-16 804 (work in progress), September 2006. 806 [IANA] IANA, "INTERNET PROTOCOL V4 ADDRESS SPACE", 807 http://www.iana.org/assignments/ipv4-address-space , 2007. 809 [MAO] Mao, Z., Govindan, R., Varghese, G., and R. Katz, "Route 810 Flap Damping Exacerbates Internet Routing Convergence", 811 Sigcomm , 2002. 813 [RIPE378] RIPE, "Recommendations on Route-flap Damping", RIPE , 814 May 2006. 816 Authors' Addresses 818 Zhao Ye 819 Huawei Technologies 820 No. 3, Xinxi Rd 821 Shangdi Information Industry Base 822 Haidian District, Beijing 100085 823 P. R. China 825 Email: ye.zhao_ietf@hotmail.com 827 Miao Fuyou 828 Huawei Technologies 829 No. 3, Xinxi Rd 830 Shangdi Information Industry Base 831 Haidian District, Beijing 100085 832 P. R. China 834 Phone: +86 10 8288 2008 835 Email: miaofy@huawei.com 836 Ross W. Callon 837 Juniper Networks 838 10 Technology Park Drive 839 Westford, MA 01886 840 USA 842 Email: rcallon@juniper.net 844 Full Copyright Statement 846 Copyright (C) The IETF Trust (2007). 848 This document is subject to the rights, licenses and restrictions 849 contained in BCP 78, and except as set forth therein, the authors 850 retain all their rights. 852 This document and the information contained herein are provided on an 853 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 854 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 855 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 856 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 857 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 858 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 860 Intellectual Property 862 The IETF takes no position regarding the validity or scope of any 863 Intellectual Property Rights or other rights that might be claimed to 864 pertain to the implementation or use of the technology described in 865 this document or the extent to which any license under such rights 866 might or might not be available; nor does it represent that it has 867 made any independent effort to identify any such rights. Information 868 on the procedures with respect to rights in RFC documents can be 869 found in BCP 78 and BCP 79. 871 Copies of IPR disclosures made to the IETF Secretariat and any 872 assurances of licenses to be made available, or the result of an 873 attempt made to obtain a general license or permission for the use of 874 such proprietary rights by implementers or users of this 875 specification can be obtained from the IETF on-line IPR repository at 876 http://www.ietf.org/ipr. 878 The IETF invites any interested party to bring to its attention any 879 copyrights, patents or patent applications, or other proprietary 880 rights that may cover technology that may be required to implement 881 this standard. Please address the information to the IETF at 882 ietf-ipr@ietf.org. 884 Acknowledgment 886 Funding for the RFC Editor function is provided by the IETF 887 Administrative Support Activity (IASA).