idnits 2.17.1 draft-callon-misc-cap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 872. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 849. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 856. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 862. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages 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.) ** The abstract seems to contain references ([11], [12]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 14, 2005) is 6768 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'CurPrc' on line 160 ** Downref: Normative reference to an Informational RFC: RFC 1208 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 2196 (ref. '5') ** Obsolete normative reference: RFC 3309 (ref. '8') (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 3330 (ref. '9') (Obsoleted by RFC 5735) == Outdated reference: A later version (-05) exists of draft-ietf-opsec-framework-00 == Outdated reference: A later version (-07) exists of draft-ietf-opsec-current-practices-01 Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Callon 3 Internet-Draft Juniper Networks 4 Expires: April 17, 2006 G. Jones 5 The Mitre Corporation 6 October 14, 2005 8 Miscellaneous Capabilities for IP Network Infrastructure 9 draft-callon-misc-cap-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 17, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The Framework for Operational Security Capabilities [11] outlines the 43 proposed effort of the IETF OPSEC working group. This includes 44 producing a series of drafts to codify knowledge gained through 45 operational experience about feature sets that are needed to securely 46 deploy and operate managed network elements providing transit 47 services at the data link and IP layers. Current plans include 48 separate capabilities documents for Packet Filtering; Event Logging; 49 In-Band and Out-of-Band Management; Configuration and Management 50 Interfaces; AAA; and Documentation and Assurance. This document 51 describes some additional miscellaneous capabilities which do not fit 52 into any of these specific catagories, and whose descriptions are 53 brief enough that it does not seem appropriate to create a separate 54 document for each. 56 Operational Security Current Practices [12] lists current operator 57 practices related to securing networks. This document lists 58 miscellaneous capabilities needed to support those practices. 60 Capabilities are defined without reference to specific technologies. 61 This is done to leave room for deployment of new technologies that 62 implement the capability. Each capability cites the practices it 63 supports. Current implementations that support the capability may be 64 cited. Special considerations are discussed as appropriate listing 65 operational and resource constraints, limitations of current 66 implementations, tradeoffs, etc. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Threat model . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.2. Capabilities versus Requirements . . . . . . . . . . . . . 4 73 1.3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.4. Terms Used in this Document . . . . . . . . . . . . . . . 5 75 1.5. RFC 2119 Keywords . . . . . . . . . . . . . . . . . . . . 6 76 2. Route Filtering Capabilities . . . . . . . . . . . . . . . . . 7 77 3. IP Stack Capabilities . . . . . . . . . . . . . . . . . . . . 7 78 3.1. Ability to Identify All Listening Services . . . . . . . . 7 79 3.2. Ability to Disable Any and All Services . . . . . . . . . 8 80 3.3. Ability to Control Service Bindings for Listening 81 Services . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 3.4. Ability to Control Service Source Addresses . . . . . . . 10 83 3.5. Support Automatic Anti-Spoofing for Single-Homed 84 Networks . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 3.6. Support Automatic Discarding of Bogons and Martians . . . 11 86 3.7. Support Counters for Dropped Packets . . . . . . . . . . . 12 87 4. Performance and Prioritization . . . . . . . . . . . . . . . . 13 88 4.1. Security Features Should Have Minimal Performance 89 Impact . . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 4.2. Prioritization of Management Functions . . . . . . . . . . 14 91 4.3. Prioritization of Routing Functions . . . . . . . . . . . 14 92 4.4. Resources used by IP Multicast . . . . . . . . . . . . . . 15 93 5. Security Features Must Not Cause Operational Problems . . . . 16 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 95 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 97 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 98 8.2. Informational References . . . . . . . . . . . . . . . . . 18 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 100 Intellectual Property and Copyright Statements . . . . . . . . . . 21 102 1. Introduction 104 This document is defined in the context of [11] and [12]. 106 The Framework for Operational Security Capabilities [11] outlines the 107 proposed effort of the IETF OPSEC working group. This includes 108 producing a series of drafts to codify knowledge gained through 109 operational experience about feature sets that are needed to securely 110 deploy and operate managed network elements providing transit 111 services at the data link and IP layers. Current plans include 112 separate capabilities documents for Packet Filtering; Event Logging; 113 In-Band and Out-of-Band Management; Configuration and Management 114 Interfaces; AAA; and Documentation and Assurance. This document 115 describes some additional miscellaneous capabilities which do not fit 116 into any of these specific catagories, and whose descriptions are 117 brief enough that it does not seem appropriate to create a separate 118 document for each. 120 Operational Security Current Practices [12] defines the goals, 121 motivation, scope, definitions, intended audience, threat model, 122 potential attacks and give justifications for each of the practices. 124 Many of the capabilities listed here refine or add to capabilities 125 listed in rfc3871 [14] 127 EDITORS NOTE: This is a first draft. Additional work will be needed 128 to further refine the listed practices, to respond to comments, and 129 to try to align the supported practices with the practices listed in 130 [12]. 132 1.1. Threat model 134 The capabities listed in this document are intended to aid in 135 preventing or mitigating the threats outlined in [11] and [12]. 137 1.2. Capabilities versus Requirements 139 Capabilities may or may not be requirements. That is a local 140 determination that must be made by each operator with reference to 141 the policies that they must support. It is hoped that this document, 142 together with [12] will assist operators in identifying their 143 security capability requirements and communicating them clearly to 144 vendors. 146 1.3. Format 148 Each capability has the following subsections: 150 o Capability (what) 152 o Supported Practices (why) 154 o Current Implementations (how) 156 o Considerations (caveats, resource issues, protocol issues, etc.) 158 The Capability section describes a feature to be supported by the 159 device. The Supported Practice section cites practices described in 160 [CurPrc] that are supported by this capability. The Current 161 Implementation section is intended to give examples of 162 implementations of the capability, citing technology and standards 163 current at the time of writing. See rfc3631 [13]. It is expected 164 that the choice of features to implement the capabilities will change 165 over time. The Considerations section lists operational and resource 166 constraints, limitations of current implementations, tradeoffs, etc. 168 1.4. Terms Used in this Document 170 The following terms are used in this document. These definitions are 171 taken from rfc3871 [14]. 173 Bogon 175 A "Bogon" (plural: "bogons") is a packet with an IP source address 176 in an address block not yet allocated by IANA or the Regional 177 Internet Registries (ARIN, RIPE, APNIC...) as well as all 178 addresses reserved for private or special use by RFCs. See 179 rfc3330 [9] and rfc1918 [3]. 181 Martian 183 Per rfc1208 [1] "Martian: Humorous term applied to packets that 184 turn up unexpectedly on the wrong network because of bogus routing 185 entries. Also used as a name for a packet which has an altogether 186 bogus (non-registered or ill-formed) Internet address." For the 187 purposes of this document Martians are defined as "packets having 188 a source address that, by application of the current forwarding 189 tables, would not have its return traffic routed back to the 190 sender." "Spoofed packets" are a common source of martians. Note 191 that in some cases, the traffic may be asymmetric, and a simple 192 forwarding table check might produce false positives. See rfc3704 193 [10]. 195 Service 196 A number of requirements refer to "services". For the purposes of 197 this document a "service" is defined as "any process or protocol 198 running in the control or management planes to which non-transit 199 packets may be delivered". Examples might include an SSH server, 200 a BGP process or an NTP server. It would also include the 201 transport, network and link layer protocols since, for example, a 202 TCP packet addressed to a port on which no service is listening 203 will be "delivered" to the IP stack, and possibly result in an 204 ICMP message being sent back. 206 Single-Homed Network. 208 A "single-homed network" is defined as one for which 210 * There is only one upstream connection 212 * Routing is symmetric. 214 See rfc3704 [10] for a discussion of related issues and mechanisms 215 for multihomed networks. 217 Spoofed Packet. 219 A "spoofed packet" is defined as a packet that has a source 220 address that does not correspond to any address assigned to the 221 system which sent the packet. Spoofed packets are often "bogons" 222 or "martians". 224 1.5. RFC 2119 Keywords 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 227 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 228 document are to be interpreted as described in rfc2119 [4]. 230 The use of the RFC 2119 keywords is an attempt, by the authors, to 231 assign the correct requirement levels ("MUST", "SHOULD", "MAY"...). 232 It must be noted that different organizations, operational 233 environments, policies and legal environments will generate different 234 requirement levels. 236 NOTE: This document defines capabilities. This document does not 237 define requirements, and there is no requirement that any particular 238 capability be implemented or deployed. The use of the terms MUST, 239 SHOULD, and so on are in the context of each capability in the sense 240 that if you conform to any particular capability then you MUST or 241 SHOULD do what is specified for that capability, but there is no 242 requirement that you actually do conform to any particular 243 capability. 245 2. Route Filtering Capabilities 247 EDITOR'S NOTE: This is taken from section 2.7.5 of RFC3871. 249 Capability. 251 The device MUST provide a means to filter routing updates for all 252 protocols used to exchange external routing information. 254 Supported Practices. 256 See rfc3013 [7] and section 3.2 of rfc2196 [5]. 258 Current Implementations. 260 Typically BGP implementations allow operators to apply a variety 261 of filters to restrict which incoming updates are accepted from 262 BGP peers, as well as to limit which updates are sent out to BGP 263 peers. 265 Considerations. 267 Operators may wish to ignore advertisements for routes to 268 addresses allocated for private internets. See eBGP. 270 3. IP Stack Capabilities 272 EDITOR'S NOTE: This is taken from section 2.5 of RFC3871. 274 3.1. Ability to Identify All Listening Services 276 Capability. 278 The vendor MUST: 280 * Provide a means to display all services that are listening for 281 network traffic directed at the device from any external source. 283 * Display the addresses to which each service is bound. 285 * Display the addresses assigned to each interface. 287 * Display any and all port(s) on which the service is listing. 289 * Include both open standard and vendor proprietary services. 291 Supported Practices. 293 This information is necessary to enable a thorough assessment of 294 the security risks associated with the operation of the device 295 (e.g., "does this protocol allow complete management of the device 296 without also requiring authentication, authorization, or 297 accounting?"). The information also assists in determining what 298 steps should be taken to mitigate risk (e.g., "should I turn this 299 service off?") 301 Current Implementations. 303 tbd. 305 Considerations. 307 If the device is listening for SNMP traffic from any source 308 directed to the IP addresses of any of its local interfaces, then 309 this requirement could be met by the provision of a command which 310 displays that fact. 312 3.2. Ability to Disable Any and All Services 314 Capability. 316 The device MUST provide a means to turn off any "services" (see 317 section 1.4.1). 319 Supported Practices. 321 The ability to disable services for which there is no operational 322 need will allow administrators to reduce the overall risk posed to 323 the device. 325 Current Implementations. 327 tbd. 329 Considerations. 331 Processes that listen on TCP and UDP ports would be prime examples 332 of services that it must be possible to disable. 334 3.3. Ability to Control Service Bindings for Listening Services 336 Capability. 338 The device MUST provide a means for the user to specify the 339 bindings used for all listening services. It MUST support binding 340 to any address or net-block associated with any interface local to 341 the device. This must include addresses bound to physical or non- 342 physical (e.g., loopback) interfaces. 344 Supported Practices. 346 It is a common practice among operators to configure "loopback" 347 pseudo-interfaces to use as the source and destination of 348 management traffic. These are preferred to physical interfaces 349 because they provide a stable, routable address. Services bound 350 to the addresses of physical interface addresses might become 351 unreachable if the associated hardware goes down, is removed, etc. 353 This requirement makes it possible to restrict access to 354 management services using routing. Management services may be 355 bound only to the addresses of loopback interfaces. The loopback 356 interfaces may be addressed out of net-blocks that are only routed 357 between the managed devices and the authorized management 358 networks/hosts. This has the effect of making it impossible for 359 anyone to connect to (or attempt to DoS) management services from 360 anywhere but the authorized management networks/hosts. 362 It also greatly reduces the need for complex filters. It reduces 363 the number of ports listening, and thus the number of potential 364 avenues of attack. It ensures that only traffic arriving from 365 legitimate addresses and/or on designated interfaces can access 366 services on the device. 368 Current Implementations. 370 tbd. 372 Considerations. 374 If the device listens for inbound SSH connections, this 375 requirement means that it should be possible to specify that the 376 device will only listen to connections destined to specific 377 addresses (e.g., the address of the loopback interface) or 378 received on certain interfaces (e.g., an Ethernet interface 379 designated as the "management" interface). It should be possible 380 in this example to configure the device such that the SSH is NOT 381 listening to every address configured on the device. Similar 382 effects may be achieved with the use of global filters, sometimes 383 called "receive" or "loopback" ACLs, that filter traffic destined 384 for the device itself on all interfaces. 386 3.4. Ability to Control Service Source Addresses 388 Capability. 390 The device MUST provide a means that allows the user to specify 391 the source addresses used for all outbound connections or 392 transmissions originating from the device. It SHOULD be possible 393 to specify source addresses independently for each type of 394 outbound connection or transmission. Source addresses MUST be 395 limited to addresses that are assigned to interfaces (including 396 loopbacks) local to the device. 398 Supported Practices. 400 This allows remote devices receiving connections or transmissions 401 to use source filtering as one means of authentication. For 402 example, if SNMP traps were configured to use a known loopback 403 address as their source, the SNMP workstation receiving the traps 404 (or a firewall in front of it) could be configured to receive SNMP 405 packets only from that address. 407 Current Implementations. 409 tbd. 411 Considerations. 413 The operator may allocate a distinct block of addresses from which 414 all loopbacks are numbered. NTP and syslog can be configured to 415 use those loopback addresses as source, while SNMP and BGP may be 416 configured to use specific physical interface addresses. This 417 would facilitate filtering based on source address as one way of 418 rejecting unauthorized attempts to connect to peers/servers. 420 Care should be taken to assure that the addresses chosen are 421 routable between the sending and receiving devices, (e.g., setting 422 SSH to use a loopback address of 10.1.1.1 which is not routed 423 between a router and all intended destinations could cause 424 problems). 426 Note that some protocols, such as SCTP [8], can use more than one 427 IP address as the endpoint of a single connection. 429 Also note that rfc3631 [13] lists address-based authentication as 430 an "insecurity mechanism". Address based authentication should be 431 replaced or augmented by other mechanisms wherever possible. 433 3.5. Support Automatic Anti-Spoofing for Single-Homed Networks 435 Capability. 437 The device MUST provide a means to designate particular interfaces 438 as servicing "single-homed networks" (see Section 1.4.1) and MUST 439 provide an option to automatically drop "spoofed packets" (Section 440 1.4.1) received on such interfaces where application of the 441 current forwarding table would not route return traffic back 442 through the same interface. This option MUST work in the presence 443 of dynamic routing and dynamically assigned addresses. 445 Supported Practices. 447 See section 3 of rfc1918 [3], sections 5.3.7 and 5.3.8 of rfc1812 448 [2], and rfc2827 [6]. 450 Current Implementations. 452 This requirement could be satisfied in several ways. It could be 453 satisfied by the provision of a single command that automatically 454 generates and applies filters to an interface that implements 455 anti-spoofing. It could be satisfied by the provision of a 456 command that causes the return path for packets received to be 457 checked against the current forwarding tables and dropped if they 458 would not be forwarded back through the interface on which they 459 were received. 461 Considerations. 463 See rfc3704 [10]. 465 This requirement only holds for single-homed networks. Note that 466 a simple forwarding table check is not sufficient in the more 467 complex scenarios of multi-homed or multi-attached networks, i.e., 468 where the traffic may be asymmetric. In these cases, a more 469 extensive check such as Feasible Path RPF could be very useful. 471 3.6. Support Automatic Discarding of Bogons and Martians 473 Capability. 475 The device MUST provide a means to automatically drop all "bogons" 476 (Section 1.4.1) and "martians" (Section 1.4.1). This option MUST 477 work in the presence of dynamic routing and dynamically assigned 478 addresses. 480 Supported Practices. 482 These sorts of packets have little (no?) legitimate use and are 483 used primarily to allow individuals and organization to avoid 484 identification (and thus accountability) and appear to be most 485 often used for DoS attacks, email abuse, hacking, etc. In 486 addition, transiting these packets needlessly consumes resources 487 and may lead to capacity and performance problems for customers. 489 See section 3 of rfc1918 [3], sections 5.3.7 and 5.3.8 of rfc1812 490 [2], and rfc2827 [6]. 492 Current Implementations. 494 This requirement could be satisfied by the provision of a command 495 that causes the return path for packets received to be checked 496 against the current forwarding tables and dropped if no viable 497 return path exists. This assumes that steps are taken to assure 498 that no bogon entries are present in the forwarding tables. 500 Considerations. 502 See rfc3704 [10]. 504 This requirement only holds for single-homed networks. Note that 505 a simple forwarding table check is not sufficient in the more 506 complex scenarios of multi-homed or multi-attached networks, i.e., 507 where the traffic may be asymmetric. In these cases, a more 508 extensive check such as Feasible Path RPF could be very useful. 510 3.7. Support Counters for Dropped Packets 512 Capability. 514 The device MUST provide accurate, per-interface counts of spoofed 515 packets dropped in accordance with Section 3.5 and Section 3.6. 517 Supported Practices. 519 Counters can help in identifying the source of spoofed traffic. 521 Current Implementations. 523 tbd. 525 Considerations. 527 An edge router may have several single-homed customers attached. 528 When an attack using spoofed packets is detected, a quick check of 529 counters may be able to identify which customer is attempting to 530 send spoofed traffic. 532 4. Performance and Prioritization 534 EDITOR'S NOTE: This section is taken from section 2.15 and a slightly 535 expanded section 2.2.5 of RFC3871. 537 4.1. Security Features Should Have Minimal Performance Impact 539 Capability. 541 Security features specified by the requirements in this document 542 SHOULD be implemented with minimal impact on performance. Other 543 sections of this document or other OPSEC capabilities documents 544 may specify different performance requirements (e.g., "MUST"s). 546 Supported Practices. 548 Security features which significantly impact performance may leave 549 the operator with no mechanism for enforcing appropriate policy. 551 Current Implementations. 553 tbd. 555 Considerations. 557 If the application of filters is known to have the potential to 558 significantly reduce throughput for non-filtered traffic, there 559 will be a tendency, or in some cases a policy, not to use filters. 561 Assume, for example, that a new worm is released that scans random 562 IP addresses looking for services listening on TCP port 1433. An 563 operator might want to investigate to see if any of the hosts on 564 their networks were infected and trying to spread the worm. One 565 way to do this would be to put up non-blocking filters counting 566 and logging the number of outbound connection 1433, and then to 567 block the requests that are determined to be from infected hosts. 568 If any of these capabilities (filtering, counting, logging) have 569 the potential to impose severe performance penalties, then this 570 otherwise rational course of action might not be possible. 572 Requirements for which performance is a particular concern 573 include: filtering, rate-limiting, counters, logging and anti- 574 spoofing. 576 4.2. Prioritization of Management Functions 578 Capability. 580 Management functions SHOULD be processed at higher priority than 581 non-management traffic. This SHOULD include ingress, egress, 582 internal transmission, and processing. This SHOULD include at 583 least protocols used for configuration, monitoring, configuration 584 backup, logging, time synchronization, and authentication. 586 Supported Practices. 588 Certain attacks (and normal operation) can cause resource 589 saturation such as link congestion, memory exhaustion or CPU 590 overload. In these cases it is important that management 591 functions be prioritized to ensure that operators have the tools 592 needed to recover from the attack. 594 Current Implementations. 596 tbd. 598 Considerations. 600 Imagine a service provider with 1,000,000 DSL subscribers, most of 601 whom have no firewall protection. Imagine that a large portion of 602 these subscribers machines were infected with a new worm that 603 enabled them to be used in coordinated fashion as part of large 604 denial of service attack that involved flooding. It is entirely 605 possible that without prioritization such an attack would cause 606 processor saturation or other internal resource saturation on 607 routers causing the routers to become unmanageable. A DoS attack 608 against hosts could therefore become a DoS attack against the 609 network. 611 Prioritization is not a panacea. Control packets may not make it 612 across a saturated link. This requirement simply says that the 613 device should prioritize management functions within its scope of 614 control (e.g., ingress, egress, internal transit, processing). To 615 the extent that this is done across an entire network, the overall 616 effect will be to ensure that the network remains manageable. 618 4.3. Prioritization of Routing Functions 620 Capability. 622 Routing functions SHOULD be processed at higher priority than user 623 data traffic. This SHOULD include ingress, egress, internal 624 transmission, and processing. This SHOULD include all packets 625 necessary for routing protocol operation, and specifically MUST 626 include priority processing of routing HELLO packets for BGP, 627 IS-IS, and OSPF. 629 Supported Practices. 631 Certain attacks (and normal operation) can cause resource 632 saturation such as link congestion, memory exhaustion or CPU 633 overload. In these cases it is important that routing functions 634 be prioritized to ensure that the network continues to operate 635 (for example, that routes can be computed in order to allow 636 management traffic to be delivered). For many routing protocols 637 the loss of HELLO packets can cause the protocol to drop 638 adjacencies and/or to send out additional routing packets, 639 potentially adding to whatever congestion may be causing the 640 problem. 642 Current Implementations. 644 tbd. 646 Considerations. 648 If routing HELLO packets are not prioritized, then it is possible 649 during DoS attacks or during severe network congestion for routing 650 protocols to drop HELLO packets, causing routing adjacencies to be 651 lost. This in turn can cause overall failure of a network. A DoS 652 attack against hosts can therefore become a DoS attack against the 653 network. 655 Prioritization within routers is not a panacea. Routing update 656 packets may not make it across a saturated link (thus for example 657 it may also be desirable to prioritize routing packets for 658 transmission across link layer devices such as Ethernet switches). 659 This requirement simply says that the device should prioritize 660 routing functions within its scope of control (e.g., ingress, 661 egress, internal transit, processing). To the extent that this is 662 done across an entire network, the overall effect will be to 663 ensure that the network continues to operate. 665 4.4. Resources used by IP Multicast 667 Capability. 669 Routers SHOULD provide some mechanism(s) to allow the control 670 plane resources used by IP multicast, including processing and 671 memory, to be limited to some level which is less than 100% of the 672 total available processing and memory. The maximum limit of 673 resources used by multicast MAY be configurable. Routers SHOULD 674 also provide a mechanism(s) to allow the amount of link bandwidth 675 consumed by IP multicast on any particular link to be limited to 676 some level which is less than 100% of total available bandwidth on 677 that link. 679 Supported Practices. 681 IP multicast has characteristics which may potentially impact the 682 availability of IP networks. In particular, IP multicast requires 683 that routers perform control plane processing and maintain state 684 in response to data plane traffic. Also, the use of multicast 685 implies that a single packet input into the network can result in 686 a large number of packets being delivered throughout the network. 687 Also, it is possible in some situations for a multicast traffic to 688 *both* enter a loop, and also be delivered to some destinations 689 (implying that many copies of the same packet could be delivered). 691 Current Implementations. 693 tbd. 695 Considerations. 697 If the amount of resources used by multicast are not limited, then 698 it is possible during an attack for multicast to consume 699 potentially as much as 100% of available memory, processing, or 700 bandwidth resources, thereby causing network problems. 702 5. Security Features Must Not Cause Operational Problems 704 EDITOR'S NOTE: This is taken from section 2.14 of RFC3871. 706 Capability. 708 The use of security features specified by the requirements in this 709 document SHOULD NOT cause severe operational problems. 711 Supported Practices. 713 Security features which cause operational problems are not useful 714 and may leave the operator with no mechanism for enforcing 715 appropriate policy. 717 Current Implementations. 719 tbd. 721 Considerations. 723 Some examples of severe operational problems include: 725 * The device crashes. 727 * The device becomes unmanageable. 729 * Data is lost. 731 * Use of the security feature consumes excessive resources (CPU, 732 memory, bandwidth). 734 Determination of compliance with this requirement involves a level 735 of judgement. What is "severe"? Certainly crashing is severe, 736 but what about a %5 loss in throughput when logging is enabled? 737 It should also be noted that there may be unavoidable physical 738 limitations such as the total capacity of a link. 740 6. Security Considerations 742 General 744 Security is the subject matter of this entire document. This 745 document lists device capabilities intended to improve the ability 746 of the network to withstand security threats. Operational 747 Security Current Practices [12] defines the threat model and 748 practices, and lists justifications for each practice. 750 7. Acknowledgements 752 The authors gratefully acknowledge the contributions of: 754 o xxx, yyy, ... 756 o The MITRE Corporation for supporting development of this 757 document. NOTE: An author's affiliation with The MITRE 758 Corporation is provided for identification purposes only, and is 759 not intended to convey or imply MITRE's concurrence with, or 760 support for, the positions, opinions or viewpoints expressed by 761 the authors. 763 o This listing is intended to acknowledge contributions, not to 764 imply that the individual or organizations approve the content of 765 this document. 767 o Apologies to those who commented on/contributed to the document 768 and were not listed. 770 8. References 772 8.1. Normative References 774 [1] Jacobsen, O. and D. Lynch, "Glossary of networking terms", 775 RFC 1208, March 1991. 777 [2] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 778 June 1995. 780 [3] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. 781 Lear, "Address Allocation for Private Internets", BCP 5, 782 RFC 1918, February 1996. 784 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 785 Levels", BCP 14, RFC 2119, March 1997. 787 [5] Fraser, B., "Site Security Handbook", RFC 2196, September 1997. 789 [6] Ferguson, P. and D. Senie, "Network Ingress Filtering: 790 Defeating Denial of Service Attacks which employ IP Source 791 Address Spoofing", BCP 38, RFC 2827, May 2000. 793 [7] Killalea, T., "Recommended Internet Service Provider Security 794 Services and Procedures", BCP 46, RFC 3013, November 2000. 796 [8] Stone, J., Stewart, R., and D. Otis, "Stream Control 797 Transmission Protocol (SCTP) Checksum Change", RFC 3309, 798 September 2002. 800 [9] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. 802 [10] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 803 Networks", BCP 84, RFC 3704, March 2004. 805 8.2. Informational References 807 [11] Jones, G., "Framework for Operational Security Capabilities for 808 IP Network Infrastructure", draft-ietf-opsec-framework-00 809 (work in progress), June 2005. 811 [12] Kaeo, M., "Operational Security Current Practices", 812 draft-ietf-opsec-current-practices-01 (work in progress), 813 July 2005. 815 [13] Bellovin, S., Schiller, J., and C. Kaufman, "Security 816 Mechanisms for the Internet", RFC 3631, December 2003. 818 [14] Jones, G., "Operational Security Requirements for Large 819 Internet Service Provider (ISP) IP Network Infrastructure", 820 RFC 3871, September 2004. 822 Authors' Addresses 824 Ross W. Callon 825 Juniper Networks 826 10 Technology Park Drive 827 Westford, MA 01886 828 USA 830 Email: rcallon@juniper.net 832 George Jones 833 The Mitre Corporation 834 7515 Colshire Drive 835 McLean, Virginia, VA 22102-7508 836 USA 838 Email: gmjones@mitre.org 840 Intellectual Property Statement 842 The IETF takes no position regarding the validity or scope of any 843 Intellectual Property Rights or other rights that might be claimed to 844 pertain to the implementation or use of the technology described in 845 this document or the extent to which any license under such rights 846 might or might not be available; nor does it represent that it has 847 made any independent effort to identify any such rights. Information 848 on the procedures with respect to rights in RFC documents can be 849 found in BCP 78 and BCP 79. 851 Copies of IPR disclosures made to the IETF Secretariat and any 852 assurances of licenses to be made available, or the result of an 853 attempt made to obtain a general license or permission for the use of 854 such proprietary rights by implementers or users of this 855 specification can be obtained from the IETF on-line IPR repository at 856 http://www.ietf.org/ipr. 858 The IETF invites any interested party to bring to its attention any 859 copyrights, patents or patent applications, or other proprietary 860 rights that may cover technology that may be required to implement 861 this standard. Please address the information to the IETF at 862 ietf-ipr@ietf.org. 864 Disclaimer of Validity 866 This document and the information contained herein are provided on an 867 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 868 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 869 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 870 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 871 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 872 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 874 Copyright Statement 876 Copyright (C) The Internet Society (2005). This document is subject 877 to the rights, licenses and restrictions contained in BCP 78, and 878 except as set forth therein, the authors retain all their rights. 880 Acknowledgment 882 Funding for the RFC Editor function is currently provided by the 883 Internet Society.