idnits 2.17.1 draft-ietf-opsec-routing-capabilities-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 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 (June 15, 2007) is 6153 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-08 == 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: December 17, 2007 Juniper Networks 7 June 15, 2007 9 Routing Control Plane Security Capabilities 10 draft-ietf-opsec-routing-capabilities-03.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 December 17, 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 . . . . . 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 . . . . . 11 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 . . . . . . . . . . 14 77 5.3. Limit Resources used by IP Multicast . . . . . . . . . . . 16 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 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 Operational Security 90 Current Practices in Internet Service Provider Environments, 91 [RFC4778]. 93 This document lists the security capabilities needed for the routing 94 control plane of IP infrastructure to support the practices defined 95 in [RFC4778]. In particular this includes capabilities for route 96 filtering and for authentication of routing 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 [RFC4778]. 115 1.2. Format and Definition of Capabilities 117 Each individual capability will be defined using the four elements, 118 "Capability", "Supported Practices", "Current Implementations", and 119 "Considerations". The Capability section describes a feature to be 120 supported by the device. The Supported Practice section cites 121 practices described in [RFC4778] that are supported by this 122 capability. The Current Implementation section is intended to give 123 examples of implementations of the capability, citing technology and 124 standards current at the time of writing. It is expected that the 125 choice of features to implement the capabilities will change over 126 time. The Considerations section lists operational and resource 127 constraints, limitations of current implementations, and trade-offs. 129 1.3. Packet Filtering versus Route Filtering 131 It is useful to make a distinction between Packet Filtering versus 132 Route Filtering. 134 The term "packet filter" is used to refer to the filter that a router 135 applies to network layer packets passing through or destined to it. 136 In general packet filters are based on contents of the network (IP) 137 and transport (TCP, UDP) layers, and are mostly stateless, in the 138 sense that whether or not a filter applies to a particular packet is 139 a function of that packet (including the contents of IP and transport 140 layer headers, size of packet, incoming interface, and similar 141 characteristics), but does not depend upon the contents of other 142 packets which might be part of the same stream (and thus which may 143 also be forwarded by the same router). One common minor exception to 144 the "stateless" nature of packet filters is that packets that match a 145 particular filter may be counted and/or rate limited (the act of 146 counting therefore represents a very simple "state" associated with 147 the filter). 149 Because of the simplicity and stateless nature of packet filters, 150 they can typically be implemented with very high performance. It is 151 not unusual for them to be implemented on line cards and to perform 152 at or near full line rate. For this reason they are very useful to 153 counter very high bandwidth attacks, such as large DDoS attacks. 155 Packet filtering capabilities are outside of the scope of this 156 document. A detailed description of packet filtering capabilities 157 can be found in [I-D.ietf-opsec-filter-caps]. 159 The Term "route filter" is used to refer to filters that routers 160 apply to the content of routing protocol packets that they are either 161 sending or receiving. Typically these therefore occur at the 162 application layer (although which route filters are applied to a 163 particular packet may be a function of network layer information, 164 such as what interface the packet is received on, or the source 165 address for the packet -- indicating the system that transmitted the 166 packet). 168 Route filters are typically implemented in some sort of processor. 169 In many cases the total bandwidth which can be received by the 170 processor is considerably less than the sum of the rate that packets 171 may be received on all interfaces to a router. Therefore in general 172 route filters cannot handle the same bandwidth as packet filters. 173 Route filters are however very useful in that they can be applied to 174 the contents of routing packets. 176 2. Route Filtering Capabilities 178 2.1. General Route Filtering Capabilities 179 2.1.1. Ability to Filter Inbound or Outbound Routes 181 Capability. 183 The device provides the ability to filter which routes may be 184 received with [RFC4271], as well as the ability to filter which 185 routes are announced into each routing protocol. 187 Supported Practices. 189 See section 2.4.2 of [RFC4778]. 191 It is a beneficial practice to configure routing filters in both 192 directions, which will counter potential misconfiguration in 193 either peer. Also, incoming route filters will prevent a 194 deliberate attacker from injecting invalid routing information. 196 Current Implementations. 198 The unicast routing protocols used with IP can be classified into 199 path vector routing protocols (such as BGP), distance vector 200 protocols (such as [RFC2453]) and link state protocols (such as 201 [RFC2328] and [RFC1195]). Because of differences in the 202 protocols, route filters will affect them in different ways. 204 Take BGP for example, an implementation may check a received route 205 against inbound filters to determine whether to install it into 206 the overall route table or not. Also, it will restrict the routes 207 which will go out to neighbors against outbound route filters. 209 However, as to link state protocols, such as OSPF, a router 210 maintains a topology database and exchanges link state information 211 with neighbors. Since route filters do not influence the link 212 state database, route filters will only affect which routes are 213 advertised into the routing protocol. That is to say, only 214 inbound route filters are effective on link state protocols. 216 Most of the routing protocols support methods to configure route 217 filters which permit or deny learning or advertising of specific 218 routes. 220 Considerations. 222 None. 224 2.1.2. Ability to Filter Routes by Prefix 226 Capability. 228 The device supports filtering routes based on prefix. 230 Supported Practices. 232 See section 2.4.2 of [RFC4778]. 234 Current Implementations. 236 The filter may include a list of specific prefixes to be accepted 237 or rejected. The filter may alternately include a list of 238 prefixes, such that more specific (longer) prefixes, which are 239 included in the more inclusive (shorter) prefix, are accepted, 240 rejected, or summarized into the shorter prefix. 242 Considerations. 244 Operators may wish to ignore advertisements for routes to specific 245 addresses, such as private addresses, reserved addresses and 246 multicast addresses, etc. The up-to-date allocation of IPv4 247 address space can be found in [IANA]. 249 2.2. Route Filtering of Exterior Gateway Protocol 251 An exterior gateway protocol is used to exchange external routing 252 information between different autonomous systems. Since BGP is the 253 most widely used protocol, this section mainly depicts special 254 routing filter capabilities of BGP. 256 2.2.1. Ability to Filter Routes by Route Attributes 258 Capability. 260 The device supports filtering routing updates by route attributes. 262 Supported Practices. 264 See [RFC3013] , section 3.2 of[RFC2196] and section 2.4.2 of 265 [RFC4778]. 267 Current Implementations. 269 In comparison with other routing protocols, BGP defines various 270 path attributes to describe characteristics of routes. Besides 271 filtering by specific prefixes, BGP also provides capability to 272 use some path attributes to precisely filter routes to determine 273 whether a route is accepted from or sent to a neighboring router. 275 These filters may be based upon any combination of route 276 attributes, such as: 278 * Restrictions on the Content of AS_PATH. Restrictions on the 279 contents of the AS PATH are frequently used: for example, the 280 received AS_PATH may be checked to ensure the sending AS is 281 actually contained in the received AS_PATH. 283 * Restrictions on Communities. Implementations could filter 284 received routes based on the set of communities [RFC1997] or 285 extended communities [RFC4360]. 287 Considerations. 289 None. 291 2.2.2. Ability to Filter Routing Update by TTL 293 Capability. 295 The device should provide a means to filter route packets based on 296 the value of the TTL field in the IPv4 header or the Hop-Limit 297 field in the IPv6 header. 299 Note that [I-D.ietf-opsec-filter-caps] specifies: 301 Capability. 303 The filtering mechanism supports filtering based on the 304 value(s) of any portion of the protocol headers for IP, ICMP, 305 UDP and TCP. 307 The ability to filter based on TTL is therefore a packet filtering 308 capability which is already implicitly covered by the capabilities 309 listed in Filtering Capabilities. Since this capability is 310 particularly important for BGP, we felt that it is worth 311 mentioning here. 313 Supported Practices. 315 See [RFC4778] section 2.4.2 and [RFC3682]. 317 Current Implementations. 319 Most current BGP implementations support this capability to 320 protect BGP sessions. 322 Considerations. 324 There will be situations in which the distance to the neighboring 325 router is more than one hop away. This for example is common for 326 I-BGP. 328 2.2.3. Ability to Limit the Number of Routes from a Peer 330 Capability. 332 The device should provide a means to configure the maximum number 333 of routes (prefixes) to accept from a peer. 335 Supported Practices. 337 Both routing policy misconfiguration and a deliberate attack from 338 a peer may cause too many routes to be sent to a peer which may 339 exhaust the memory resources of the router, introduce routing 340 instability into the overall routing table, or both. Therefore, 341 operators may want to restrict the amount of routes received from 342 a particular peer router through a maximum prefix limitation 343 approach. 345 Current Implementations. 347 Most BGP implementations support this capability. If too many 348 routes are sent, then the router may reset the BGP session or may 349 reject excess routes. In either case the device may log the 350 failure event (at a minimum), or shut down the BGP session. 352 Considerations. 354 Operators must be cognizant of the need to allow for valid swings 355 in routing announcements between themselves, and as such should 356 always set the max-prefix limit to some agreed upon number plus a 357 sane amount for overhead to allow for these necessary announcement 358 swings. Individual implementations amongst ISPs are unique, and 359 depending on equipment supplier(s) different implementation 360 options are available. Most equipment vendors offer 361 implementation options ranging from just logging excessive 362 prefixes being received to automatically shutting down the 363 session. If the option of reestablishing a session after some 364 pre-configured idle timeout has been reached is available, it 365 should be understood that automatically reestablishing the session 366 may continuously introduce instability into the overall routing 367 table if a policy misconfiguration on the adjacent neighbor is 368 causing the condition. If a serious misconfiguration on a peering 369 neighbor has occurred then automatically shutting down the session 370 and leaving it shut down until being manually cleared is perhaps 371 best and allows for operator intervention to correct as needed. 373 2.2.4. Ability to Limit the Length of Prefixes 375 Capability. 377 The device has the capability to allow filtering of route updates 378 by prefix length. 380 Supported Practices. 382 Some large ISPs declare in their peer BGP policies that they will 383 not accept the announcements whose prefix length is longer than a 384 specific threshold. 386 Current Implementations. 388 Most BGP implementations support this capability. 390 Considerations. 392 None. 394 2.2.5. Ability to Cooperate in Outbound Route Filtering 396 Capability. 398 A device provides the capability to allow operators to configure 399 whether Outbound Route Filtering/ORF defined in 400 [I-D.ietf-idr-route-filter] are accepted from or sent to other 401 peer routers. 403 Supported Practices 405 "Outbound Route Filtering" defines a BGP mechanism to reduce the 406 number of BGP updates between BGP peers. It will conserve the 407 resource in both sides of peers, since the BGP speaker will not 408 generate updates that will be filtered and the neighbor router 409 will not process them as well. A router with limited resource may 410 need this feature to prevent overfull routes from peers. 412 Current Implementations. 414 ORF may be based on prefix, path attributes. Currently, most 415 implementations support prefix-based ORF. 417 Considerations. 419 None. 421 2.3. Route Filtering of Interior Gateway Protocols 423 This section describes route filtering as it may be applied to OSPF 424 and IS-IS when used as the interior gateway protocol (Internal 425 Gateway Protocol or IGP) used within a routing domain. 427 2.3.1. Route Filtering Within an IGP Area 429 A critical design principle of OSPF and IS-IS is that each router 430 within an area has the same view of the topology, thereby allowing 431 consistent routes to be computed by all routers within the area. For 432 this reason, all properly authenticated (if applicable) routing 433 topology advertisements (Link State Advertisements or LSAs in OSPF, 434 or Link State Packets or LSPs in IS-IS) are flooded unchanged 435 throughout the area. Route filtering within an OSPF or IS-IS area is 436 therefore not appropriate. 438 2.3.2. Route Filtering Between IGP Areas 440 Capability. 442 The device provides the capability to allow the network operator 443 to configure route filters which restrict which routes (i.e, 444 address prefixes) are advertised into areas from outside of the 445 area (i.e., from other OSPF or IS-IS areas). 447 Supported Practices. 449 See section 2.4.2 of [RFC4778]. 451 Current Implementations. 453 Some OSPF/IS-IS implementations support this capability. 455 Considerations 457 If filters are used which restrict the passing of routes between 458 IGP areas, then this may result in some addresses being 459 unreachable from some other areas within the same routing domain. 461 It is normal when passing routes into the backbone area (area 462 0.0.0.0 in OSPF, or the level 2 backbone in IS-IS) for routes to 463 be summarized, in the sense that multiple more specific (longer) 464 address prefixes that are reachable in an area may be summarized 465 into a smaller number of less specific (shorter) address prefixes. 466 This provides important scaling improvements, but is generally not 467 primarily intended to aid in security and is therefore outside of 468 the scope of this document. 470 2.4. Route Filtering during Redistribution 472 Capability. 474 The device provides a means to filter routes when distributing 475 them between routing protocols or between routing protocol 476 processes running in the single device. 478 Supported Practices. 480 Route redistribution bridges between different route domains and 481 improves the flexibility of routing system. This allows for the 482 transmission of reachable destinations learned in one protocol 483 through another protocol. However, without careful consideration 484 it may lead to looping or black holes as well. 486 Filters are always needed when routes redistributing between IGP 487 and EGP. For example, it is infeasible to inject all Internet 488 routes from EGP to IGPs, since IGPs are not able to deal with such 489 a large number of routes. 491 Current Implementations. 493 Most implementations allow applying a filter based on a prefix 494 list to control redistribution. 496 Considerations 498 None. 500 3. Route Authentication Capabilities 502 3.1. Ability to configure an authentication mechanism 504 Capabilities. 506 The device has one or more methods to allow an authentication 507 mechanism to be configured for the routing protocol. 509 Supported Practices. 511 See [RFC4778] section 2.4.2. 513 Current Implementations. 515 [RFC2385] is deployed widely in BGP. Other routing protocols, 516 such as OSPF, adopt similar technology. 518 Consideration. 520 In most of current implementations, neither the authentication 521 mechanism nor key can be negotiated. An operator has to configure 522 it manually, which will affect scalability. 524 As of this writing, MD5 is the only cryptographic hash function 525 used in route authentication. However, recent research revealed 526 weakness of MD5, which means stronger algorithms are necessary. 528 3.2. Ability to support authentication key chains 530 Capabilities. 532 The device provides a key chain mechanism to update authentication 533 keys of routing protocols. 535 Supported Practices. 537 Using a fixed authentication key is vulnerable to a compromise. A 538 key chain is a series of keys which will be used in configured 539 time intervals. A device can transit keys based on system time 540 and configured key chain. In this way, it reduces possibility of 541 leakage of an authentication key. 543 Current Implementations. 545 This mechanism is implemented in most routing protocols. 546 Different vendors provide this feature in different routing 547 protocols, such as RIP, OSPF and BGP. 549 Consideration. 551 Since the rollover of the key is based on system time on different 552 routers, it requires clock synchronization across the routers. 554 4. Ability to Damp Route Flap 556 Capability. 558 The device provides the capability to damp route flaps. 560 Supported Practices. 562 The function to damp route flaps may enhance the stability of 563 routing system and minimize the influence of flapping. It is 564 useful to counter against some DoS attacks. 566 Current Implementations. 568 BGP RFD (Route Flap Damping) of [RFC2439] defines the primary 569 mechanism in BGP to mitigate the influence caused by flapping. 570 Most of current BGP implementations support this capability. 572 Other routing protocols may be vulnerable to route flaps as well. 573 Some vendors introduce SPF (shortest path first) algorithm timers 574 in OSPF to control parameters, such as the amount of minimal time 575 between consecutive SPF computations, which may be used to 576 mitigate excessive resource exhaustion caused by link flaps. 578 Consideration. 580 [MAO] described a flaw of current BGP RFD standard RFC2439, which 581 shows that route flap damping could suppress relatively stable 582 routes and affect routing convergence. 584 Since, at the time of this writing, no vendors are known to have 585 fixed this problem, [RIPE378] proposes that, with the current 586 implementations of BGP flap damping, the application of flap 587 damping in ISP networks is not recommended. 589 5. Resource Availability for Router Control Functions 591 5.1. Ensure Resources for Management Functions 593 Capability. 595 This capability specifies that device implementations ensure that 596 at least a certain minimum sufficient level of resources are 597 available for management functions. This may include such 598 resources as memory, processor cycle, data structure and/or 599 bandwidth at ingress to the device, on egress from the device, for 600 internal transmission and processing. This may include at least 601 protocols used for configuration, monitoring, configuration 602 backup, logging, time synchronization, authentication and 603 authorization. 605 Supported Practices. 607 Certain attacks (and normal operation) can cause resource 608 saturation such as link congestion, memory exhaustion or CPU 609 overload. In these cases it is important that resources be 610 available for management functions in order to ensure that 611 operators have the tools needed to recover from the attack. 613 Current Implementations. 615 How this is implemented depend upon the details of the device. 616 There are a variety of ways that this may be ensured such as 617 prioritizing management functions in comparison with other 618 functions performed by the device, providing separate queues for 619 management traffic, use of operating systems or other methods that 620 partition resources between processes or functions, and so on. 622 Consideration. 624 Imagine a service provider with 1,000,000 DSL subscribers, most of 625 whom have no firewall protection. Imagine that a large portion of 626 these subscribers machines were infected with a new worm that 627 enabled them to be used in coordinated fashion as part of large 628 denial of service attack that involved flooding. It is entirely 629 possible that such an attack could in some cases cause processor 630 saturation or other internal resource saturation on routers 631 causing the routers to become unmanageable. A DoS attack against 632 hosts could therefore become a DoS attack against the network. 634 Guarantee of resources within an individual device is not a 635 panacea. Control packets may not make it across a saturated link. 636 This requirement simply says that the device should ensure 637 resources for management functions within its scope of control 638 (e.g., ingress, egress, internal transit, processing). To the 639 extent that this is done across an entire network, the overall 640 effect will be to ensure that the network remains manageable. 642 5.2. Ensure Resources for Routing Functions 644 Capability. 646 This capability specifies that a device implementation ensures at 647 least a certain minimum sufficient level of resources are 648 available for routing protocol functions. This may include such 649 resources as memory, processor cycle, data structure and bandwidth 650 at ingress to the device, on egress from the device, for internal 651 transmission, and processing. This may include at least protocols 652 used for routing protocol operation, including resources used for 653 routing HELLO packets for BGP, IS-IS, and OSPF. 655 Supported Practices. 657 Certain attacks (and normal operation) can cause resource 658 saturation such as link congestion, memory exhaustion or CPU 659 overload. In these cases it is important that resources be 660 available for the operation of routing protocols in order to 661 ensure that the network continues to operate (for example, that 662 routes can be computed in order to allow management traffic to be 663 delivered). For many routing protocols the loss of HELLO packets 664 can cause the protocol to drop adjacencies and/or to send out 665 additional routing packets, potentially destabilizing the routing 666 protocol and/or adding to whatever congestion may be causing the 667 problem. 669 Current Implementations. 671 How this is implemented depend upon the details of the device. 672 There are a variety of ways that this may be ensured such as 673 prioritizing routing functions in comparison with other functions 674 performed by the device, providing separate queues for routing 675 traffic, use of operating systems or other methods that partition 676 resources between processes or functions, and so on. 678 Consideration. 680 For example, if routing HELLO packets are not prioritized, then it 681 is possible during DoS attacks or during severe network congestion 682 for routing protocols to drop HELLO packets, causing routing 683 adjacencies to be lost. This in turn can cause overall failure of 684 a network. A DoS attack against hosts can therefore become a DoS 685 attack against the network. 687 Guaranteeing resources within routers is not a panacea. Routing 688 packets may not make it across a saturated link (thus for example 689 it may also be desirable to prioritize routing packets for 690 transmission across link layer devices such as Ethernet switches). 691 This requirement simply says that the device should prioritize 692 routing functions within its scope of control (e.g., ingress, 693 egress, internal transit, processing). To the extent that this is 694 done across an entire network, the overall effect will be to 695 ensure that the network continues to operate. 697 5.3. Limit Resources used by IP Multicast 699 Capability. 701 This capability specifies that some mechanism(s) is provided to 702 allow the control plane resources used by IP multicast, including 703 processing and memory, to be limited to some level which is less 704 than 100% of the total available processing and memory. In some 705 cases the maximum limit of resources used by multicast may be 706 configurable. Routers may also provide a mechanism(s) to allow 707 the amount of link bandwidth consumed by IP multicast on any 708 particular link to be limited to some level which is less than 709 100% of total available bandwidth on that link. 711 Supported Practices. 713 IP multicast has characteristics which may potentially impact the 714 availability of IP networks. In particular, IP multicast requires 715 that routers perform control plane processing and maintain state 716 in response to data plane traffic. Also, the use of multicast 717 implies that a single packet input into the network can result in 718 a large number of packets being delivered throughout the network. 719 Also, it is possible in some situations for a multicast traffic to 720 *both* enter a loop, and also be delivered to some destinations 721 (implying that many copies of the same packet could be delivered). 723 Current Implementations. 725 None. 727 Consideration. 729 If the amount of resources used by multicast are not limited, then 730 it is possible during an attack for multicast to consume 731 potentially as much as 100% of available memory, processing, or 732 bandwidth resources, thereby causing network problems. 734 6. Security Considerations 736 Security is the subject matter of this entire document. This 737 document lists device capabilities intended to improve the ability of 738 the network to withstand security threats. Operational Security 739 Current Practices defines the threat model and practices, and lists 740 justifications for each practice. 742 7. IANA Considerations 744 This document has no actions for IANA. 746 8. Acknowledgements 748 The authors gratefully acknowledge the contributions of Ron Bonica, 749 Ted Seely, Pat Cain, George Jones, and Russ White etc for their 750 contributed texts, useful comments and suggestions. 752 9. References 754 9.1. Normative References 756 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 757 dual environments", RFC 1195, December 1990. 759 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 760 Communities Attribute", RFC 1997, August 1996. 762 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 764 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 765 Signature Option", RFC 2385, August 1998. 767 [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route 768 Flap Damping", RFC 2439, November 1998. 770 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 771 November 1998. 773 [RFC3013] Killalea, T., "Recommended Internet Service Provider 774 Security Services and Procedures", BCP 46, RFC 3013, 775 November 2000. 777 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 778 Protocol 4 (BGP-4)", RFC 4271, January 2006. 780 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 781 Communities Attribute", RFC 4360, February 2006. 783 9.2. Informative References 785 [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, 786 September 1997. 788 [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL 789 Security Mechanism (GTSM)", RFC 3682, February 2004. 791 [RFC4778] Kaeo, M., "Operational Security Current Practices in 792 Internet Service Provider Environments", RFC 4778, 793 January 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-08 (work in progress), 799 June 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 826 Miao Fuyou 827 Huawei Technologies 828 No. 3, Xinxi Rd 829 Shangdi Information Industry Base 830 Haidian District, Beijing 100085 831 P. R. China 833 Phone: +86 10 8288 2008 834 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).