idnits 2.17.1 draft-ietf-opsec-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 885. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 862. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 869. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 875. ** 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 (February 2, 2006) is 6652 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 == Unused Reference: '5' is defined on line 800, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 806, but no explicit reference was found in the text ** 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-01 == Outdated reference: A later version (-07) exists of draft-ietf-opsec-current-practices-02 Summary: 9 errors (**), 0 flaws (~~), 9 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: August 6, 2006 G. Jones 5 The Mitre Corporation 6 February 2, 2006 8 Miscellaneous Capabilities for IP Network Infrastructure 9 draft-ietf-opsec-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 August 6, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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. IP Stack Capabilities . . . . . . . . . . . . . . . . . . . . 7 77 2.1. Ability to Identify All Listening Services . . . . . . . . 7 78 2.2. Ability to Disable Any and All Services . . . . . . . . . 8 79 2.3. Ability to Control Service Bindings for Listening 80 Services . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 2.4. Ability to Control Service Source Addresses . . . . . . . 9 82 2.5. Support Automatic Anti-Spoofing for Single-Homed 83 Networks . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 2.6. Support Automatic Discarding of Bogons and Martians . . . 11 85 2.7. Support Counters for Dropped Packets . . . . . . . . . . . 12 86 3. Performance and Prioritization . . . . . . . . . . . . . . . . 12 87 3.1. Security Features Should Have Minimal Performance 88 Impact . . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 3.2. Prioritization of Management Functions . . . . . . . . . . 14 90 3.3. Prioritization of Routing Functions . . . . . . . . . . . 15 91 3.4. Resources used by IP Multicast . . . . . . . . . . . . . . 16 92 4. Security Features Must Not Cause Operational Problems . . . . 16 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 94 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 95 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 97 7.2. Informational References . . . . . . . . . . . . . . . . . 19 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 99 Intellectual Property and Copyright Statements . . . . . . . . . . 21 101 1. Introduction 103 This document is defined in the context of [11] and [12]. 105 The Framework for Operational Security Capabilities [11] outlines the 106 proposed effort of the IETF OPSEC working group. This includes 107 producing a series of drafts to codify knowledge gained through 108 operational experience about feature sets that are needed to securely 109 deploy and operate managed network elements providing transit 110 services at the data link and IP layers. Current plans include 111 separate capabilities documents for Packet Filtering; Event Logging; 112 In-Band and Out-of-Band Management; Configuration and Management 113 Interfaces; AAA; and Documentation and Assurance. This document 114 describes some additional miscellaneous capabilities which do not fit 115 into any of these specific catagories, and whose descriptions are 116 brief enough that it does not seem appropriate to create a separate 117 document for each. 119 Operational Security Current Practices [12] defines the goals, 120 motivation, scope, definitions, intended audience, threat model, 121 potential attacks and give justifications for each of the practices. 123 Many of the capabilities listed here refine or add to capabilities 124 listed in rfc3871 [14] 126 EDITORS NOTE: This is an early draft. Additional work will be needed 127 to further refine the listed practices, to respond to comments, and 128 to further align the supported practices with the practices listed in 129 [12]. Editor's notes listed in this document are intended to be 130 removed prior to final publication. 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 EDITOR'S NOTE: An earlier contribution towards this document 246 (draft-callon-misc-caps-00.txt) included a section on route 247 filtering. This section has been removed since it seems likely that 248 there may be a new document proposed giving significant more text 249 which includes this topic. It is intended and expected that some 250 opsec document will contain a description of route filtering 251 capabilities. details are tbd. 253 2. IP Stack Capabilities 255 EDITOR'S NOTE: This is taken from section 2.5 of RFC3871. 257 2.1. Ability to Identify All Listening Services 259 Capability. 261 The vendor MUST: 263 * Provide a means to display all services that are listening for 264 network traffic directed at the device from any external source. 266 * Display the addresses to which each service is bound. 268 * Display the addresses assigned to each interface. 270 * Display any and all port(s) on which the service is listing. 272 * Include both open standard and vendor proprietary services. 274 Supported Practices. 276 This information is necessary to enable a thorough assessment of 277 the security risks associated with the operation of the device 278 (e.g., "does this protocol allow complete management of the device 279 without also requiring authentication, authorization, or 280 accounting?"). The information also assists in determining what 281 steps should be taken to mitigate risk (e.g., "should I turn this 282 service off?") 284 Current Implementations. 286 tbd. 288 Considerations. 290 If the device is listening for SNMP traffic from any source 291 directed to the IP addresses of any of its local interfaces, then 292 this requirement could be met by the provision of a command which 293 displays that fact. 295 2.2. Ability to Disable Any and All Services 297 Capability. 299 The device MUST provide a means to turn off any "services" (see 300 section 1.4.1). 302 Supported Practices. 304 The ability to disable services for which there is no operational 305 need will allow administrators to reduce the overall risk posed to 306 the device. 308 As an example of how this is used, many service providers restrict 309 which network management protocols may be used to access the 310 device (see section 2.2 of [12]). 312 Current Implementations. 314 tbd. 316 Considerations. 318 Processes that listen on TCP and UDP ports would be prime examples 319 of services that it must be possible to disable. 321 2.3. Ability to Control Service Bindings for Listening Services 323 Capability. 325 The device MUST provide a means for the user to specify the 326 bindings used for all listening services. It MUST support binding 327 to any address or net-block associated with any interface local to 328 the device. This must include addresses bound to physical or non- 329 physical (e.g., loopback) interfaces. 331 Supported Practices. 333 It is a common practice among operators to configure "loopback" 334 pseudo-interfaces to use as the source and destination of 335 management traffic. These are preferred to physical interfaces 336 because they provide a stable, routable address. Services bound 337 to the addresses of physical interface addresses might become 338 unreachable if the associated hardware goes down, is removed, etc. 340 This requirement makes it possible to restrict access to 341 management services using routing. Management services may be 342 bound only to the addresses of loopback interfaces. The loopback 343 interfaces may be addressed out of net-blocks that are only routed 344 between the managed devices and the authorized management 345 networks/hosts. This has the effect of making it impossible for 346 anyone to connect to (or attempt to DoS) management services from 347 anywhere but the authorized management networks/hosts. 349 It also greatly reduces the need for complex filters. It reduces 350 the number of ports listening, and thus the number of potential 351 avenues of attack. It ensures that only traffic arriving from 352 legitimate addresses and/or on designated interfaces can access 353 services on the device. 355 Current Implementations. 357 tbd. 359 Considerations. 361 If the device listens for inbound SSH connections, this 362 requirement means that it should be possible to specify that the 363 device will only listen to connections destined to specific 364 addresses (e.g., the address of the loopback interface) or 365 received on certain interfaces (e.g., an Ethernet interface 366 designated as the "management" interface). It should be possible 367 in this example to configure the device such that the SSH is NOT 368 listening to every address configured on the device. Similar 369 effects may be achieved with the use of global filters, sometimes 370 called "receive" or "loopback" ACLs, that filter traffic destined 371 for the device itself on all interfaces. 373 2.4. Ability to Control Service Source Addresses 375 Capability. 377 The device MUST provide a means that allows the user to specify 378 the source addresses used for all outbound connections or 379 transmissions originating from the device. It SHOULD be possible 380 to specify source addresses independently for each type of 381 outbound connection or transmission. Source addresses MUST be 382 limited to addresses that are assigned to interfaces (including 383 loopbacks) local to the device. 385 Supported Practices. 387 This allows remote devices receiving connections or transmissions 388 to use source filtering as one means of authentication. For 389 example, if SNMP traps were configured to use a known loopback 390 address as their source, the SNMP workstation receiving the traps 391 (or a firewall in front of it) could be configured to receive SNMP 392 packets only from that address. 394 Current Implementations. 396 tbd. 398 Considerations. 400 The operator may allocate a distinct block of addresses from which 401 all loopbacks are numbered. NTP and syslog can be configured to 402 use those loopback addresses as source, while SNMP and BGP may be 403 configured to use specific physical interface addresses. This 404 would facilitate filtering based on source address as one way of 405 rejecting unauthorized attempts to connect to peers/servers. 407 Care should be taken to assure that the addresses chosen are 408 routable between the sending and receiving devices, (e.g., setting 409 SSH to use a loopback address of 10.1.1.1 which is not routed 410 between a router and all intended destinations could cause 411 problems). 413 Note that some protocols, such as SCTP [8], can use more than one 414 IP address as the endpoint of a single connection. 416 Also note that rfc3631 [13] lists address-based authentication as 417 an "insecurity mechanism". Address based authentication should be 418 replaced or augmented by other mechanisms wherever possible. 420 2.5. Support Automatic Anti-Spoofing for Single-Homed Networks 422 Capability. 424 The device MUST provide a means to designate particular interfaces 425 as servicing "single-homed networks" (see Section 1.4.1) and MUST 426 provide an option to automatically drop "spoofed packets" (Section 427 1.4.1) received on such interfaces where application of the 428 current forwarding table would not route return traffic back 429 through the same interface. This option MUST work in the presence 430 of dynamic routing and dynamically assigned addresses. 432 Supported Practices. 434 See section 3 of rfc1918 [3], sections 5.3.7 and 5.3.8 of rfc1812 435 [2], and rfc2827 [6]. 437 Current Implementations. 439 This requirement could be satisfied in several ways. It could be 440 satisfied by the provision of a single command that automatically 441 generates and applies filters to an interface that implements 442 anti-spoofing. It could be satisfied by the provision of a 443 command that causes the return path for packets received to be 444 checked against the current forwarding tables and dropped if they 445 would not be forwarded back through the interface on which they 446 were received. 448 Considerations. 450 See rfc3704 [10]. 452 This requirement only holds for single-homed networks. Note that 453 a simple forwarding table check is not sufficient in the more 454 complex scenarios of multi-homed or multi-attached networks, i.e., 455 where the traffic may be asymmetric. In these cases, a more 456 extensive check such as Feasible Path RPF could be very useful. 458 2.6. Support Automatic Discarding of Bogons and Martians 460 Capability. 462 The device MUST provide a means to automatically drop all "bogons" 463 (Section 1.4.1) and "martians" (Section 1.4.1). This option MUST 464 work in the presence of dynamic routing and dynamically assigned 465 addresses. 467 Supported Practices. 469 These sorts of packets have little (no?) legitimate use and are 470 used primarily to allow individuals and organization to avoid 471 identification (and thus accountability) and appear to be most 472 often used for DoS attacks, email abuse, hacking, etc. In 473 addition, transiting these packets needlessly consumes resources 474 and may lead to capacity and performance problems for customers. 476 See section 3 of rfc1918 [3], sections 5.3.7 and 5.3.8 of rfc1812 477 [2], and rfc2827 [6]. 479 Current Implementations. 481 This requirement could be satisfied by the provision of a command 482 that causes the return path for packets received to be checked 483 against the current forwarding tables and dropped if no viable 484 return path exists. This assumes that steps are taken to assure 485 that no bogon entries are present in the forwarding tables. 487 Considerations. 489 See rfc3704 [10]. 491 This requirement only holds for single-homed networks. Note that 492 a simple forwarding table check is not sufficient in the more 493 complex scenarios of multi-homed or multi-attached networks, i.e., 494 where the traffic may be asymmetric. In these cases, a more 495 extensive check such as Feasible Path RPF could be very useful. 497 2.7. Support Counters for Dropped Packets 499 Capability. 501 The device MUST provide accurate, per-interface counts of spoofed 502 packets dropped in accordance with Section 3.5 and Section 3.6. 504 Supported Practices. 506 Counters can help in identifying the source of spoofed traffic. 508 Current Implementations. 510 Generally the hardware that is required to drop packets includes 511 specific support for counters. Details vary greatly based on the 512 wide variety of data plane hardware implementations. 514 Considerations. 516 An edge router may have several single-homed customers attached. 517 When an attack using spoofed packets is detected, a quick check of 518 counters may be able to identify which customer is attempting to 519 send spoofed traffic. 521 3. Performance and Prioritization 523 EDITOR'S NOTE: This section is taken from section 2.15 and a slightly 524 expanded section 2.2.5 of RFC3871. 526 3.1. Security Features Should Have Minimal Performance Impact 528 Capability. 530 Security features specified by the requirements in this document 531 and related OPSEC documents SHOULD be implemented with minimal 532 impact on performance. Other sections of this document or other 533 OPSEC capabilities documents may specify different performance 534 requirements (e.g., "MUST"s). 536 Supported Practices. 538 Security features which significantly impact performance may leave 539 the operator with no mechanism for enforcing appropriate policy. 541 Current Implementations. 543 Here again how this is implemented depend upon the details of the 544 hardware. In some cases this may require using faster processors 545 than would otherwise be needed, using operating systems that allow 546 resources to be guaranteed to particular processes, or using 547 parallel hardware. There is a very wide range of possible 548 implementations that are possible in order to ensure that security 549 features can be turned on with minimal or no performance impact. 551 Considerations. 553 If the application of filters is known to have the potential to 554 significantly reduce throughput for non-filtered traffic, there 555 will be a tendency, or in some cases a policy, not to use filters. 557 Assume, for example, that a new worm is released that scans random 558 IP addresses looking for services listening on TCP port 1433. An 559 operator might want to investigate to see if any of the hosts on 560 their networks were infected and trying to spread the worm. One 561 way to do this would be to put up non-blocking filters counting 562 and logging the number of outbound connection 1433, and then to 563 block the requests that are determined to be from infected hosts. 564 If any of these capabilities (filtering, counting, logging) have 565 the potential to impose severe performance penalties, then this 566 otherwise rational course of action might not be possible. 568 Requirements for which performance is a particular concern 569 include: filtering, rate-limiting, counters, logging and anti- 570 spoofing. 572 3.2. Prioritization of Management Functions 574 Capability. 576 Management functions SHOULD be processed at higher priority than 577 non-management traffic. This SHOULD include ingress, egress, 578 internal transmission, and processing. This SHOULD include at 579 least protocols used for configuration, monitoring, configuration 580 backup, logging, time synchronization, and authentication. 582 Supported Practices. 584 Certain attacks (and normal operation) can cause resource 585 saturation such as link congestion, memory exhaustion or CPU 586 overload. In these cases it is important that management 587 functions be prioritized to ensure that operators have the tools 588 needed to recover from the attack. 590 Current Implementations. 592 Here again how this is implemented depend upon the details of the 593 hardware. There is a very wide range of possible implementations 594 that are possible in order to give priority to management 595 functions. This requirement can potentially implement any of 596 processing, memory, choice of operating system or other software 597 architecture issues, as well as internal and external data 598 transmission. 600 Considerations. 602 Imagine a service provider with 1,000,000 DSL subscribers, most of 603 whom have no firewall protection. Imagine that a large portion of 604 these subscribers machines were infected with a new worm that 605 enabled them to be used in coordinated fashion as part of large 606 denial of service attack that involved flooding. It is entirely 607 possible that without prioritization such an attack would cause 608 processor saturation or other internal resource saturation on 609 routers causing the routers to become unmanageable. A DoS attack 610 against hosts could therefore become a DoS attack against the 611 network. 613 Prioritization is not a panacea. Control packets may not make it 614 across a saturated link. This requirement simply says that the 615 device should prioritize management functions within its scope of 616 control (e.g., ingress, egress, internal transit, processing). To 617 the extent that this is done across an entire network, the overall 618 effect will be to ensure that the network remains manageable. 620 3.3. Prioritization of Routing Functions 622 Capability. 624 Routing functions SHOULD be processed at higher priority than user 625 data traffic. This SHOULD include ingress, egress, internal 626 transmission, and processing. This SHOULD include all packets 627 necessary for routing protocol operation, and specifically MUST 628 include priority processing of routing HELLO packets for BGP, 629 IS-IS, and OSPF. 631 Supported Practices. 633 Certain attacks (and normal operation) can cause resource 634 saturation such as link congestion, memory exhaustion or CPU 635 overload. In these cases it is important that routing functions 636 be prioritized to ensure that the network continues to operate 637 (for example, that routes can be computed in order to allow 638 management traffic to be delivered). For many routing protocols 639 the loss of HELLO packets can cause the protocol to drop 640 adjacencies and/or to send out additional routing packets, 641 potentially adding to whatever congestion may be causing the 642 problem. 644 Current Implementations. 646 Here again how this is implemented depend upon the details of the 647 hardware. There is a very wide range of possible implementations 648 that are possible in order to give priority to routing functions. 649 This requirement can potentially implement any of processing, 650 memory, choice of operating system or other software architecture 651 issues, as well as internal and external data transmission. 653 Considerations. 655 If routing HELLO packets are not prioritized, then it is possible 656 during DoS attacks or during severe network congestion for routing 657 protocols to drop HELLO packets, causing routing adjacencies to be 658 lost. This in turn can cause overall failure of a network. A DoS 659 attack against hosts can therefore become a DoS attack against the 660 network. 662 Prioritization within routers is not a panacea. Routing update 663 packets may not make it across a saturated link (thus for example 664 it may also be desirable to prioritize routing packets for 665 transmission across link layer devices such as Ethernet switches). 666 This requirement simply says that the device should prioritize 667 routing functions within its scope of control (e.g., ingress, 668 egress, internal transit, processing). To the extent that this is 669 done across an entire network, the overall effect will be to 670 ensure that the network continues to operate. 672 3.4. Resources used by IP Multicast 674 Capability. 676 Routers SHOULD provide some mechanism(s) to allow the control 677 plane resources used by IP multicast, including processing and 678 memory, to be limited to some level which is less than 100% of the 679 total available processing and memory. The maximum limit of 680 resources used by multicast MAY be configurable. Routers SHOULD 681 also provide a mechanism(s) to allow the amount of link bandwidth 682 consumed by IP multicast on any particular link to be limited to 683 some level which is less than 100% of total available bandwidth on 684 that link. 686 Supported Practices. 688 IP multicast has characteristics which may potentially impact the 689 availability of IP networks. In particular, IP multicast requires 690 that routers perform control plane processing and maintain state 691 in response to data plane traffic. Also, the use of multicast 692 implies that a single packet input into the network can result in 693 a large number of packets being delivered throughout the network. 694 Also, it is possible in some situations for a multicast traffic to 695 *both* enter a loop, and also be delivered to some destinations 696 (implying that many copies of the same packet could be delivered). 698 Current Implementations. 700 tbd. 702 Considerations. 704 If the amount of resources used by multicast are not limited, then 705 it is possible during an attack for multicast to consume 706 potentially as much as 100% of available memory, processing, or 707 bandwidth resources, thereby causing network problems. 709 4. Security Features Must Not Cause Operational Problems 711 EDITOR'S NOTE: This is taken from section 2.14 of RFC3871. 713 Capability. 715 The use of security features specified by the requirements in this 716 document SHOULD NOT cause severe operational problems. 718 Supported Practices. 720 Security features which cause operational problems are not useful 721 and may leave the operator with no mechanism for enforcing 722 appropriate policy. 724 Current Implementations. 726 Again this capability potentially impacts many aspects of the 727 implementation. 729 Considerations. 731 Some examples of severe operational problems include: 733 * The device crashes. 735 * The device becomes unmanageable. 737 * Data is lost. 739 * Use of the security feature consumes excessive resources (CPU, 740 memory, bandwidth). 742 Determination of compliance with this requirement involves a level 743 of judgement. What is "severe"? Certainly crashing is severe, 744 but what about a %5 loss in throughput when logging is enabled? 745 It should also be noted that there may be unavoidable physical 746 limitations such as the total capacity of a link. 748 5. Security Considerations 750 General 752 Security is the subject matter of this entire document. This 753 document lists device capabilities intended to improve the ability 754 of the network to withstand security threats. Operational 755 Security Current Practices [12] defines the threat model and 756 practices, and lists justifications for each practice. 758 6. Acknowledgements 760 The authors gratefully acknowledge the contributions of: 762 o xxx, yyy, ... 764 o The MITRE Corporation for supporting development of this 765 document. NOTE: An author's affiliation with The MITRE 766 Corporation is provided for identification purposes only, and is 767 not intended to convey or imply MITRE's concurrence with, or 768 support for, the positions, opinions or viewpoints expressed by 769 the authors. 771 o We note that there are many people from multiple network 772 operators who have contributed to the OPSEC effort, but who wish 773 to remain anonymous. We would like to thank them for their 774 considerable help. 776 o This listing is intended to acknowledge contributions, not to 777 imply that the individual or organizations approve the content of 778 this document. 780 o Apologies to those who commented on/contributed to the document 781 and were not listed. 783 7. References 785 7.1. Normative References 787 [1] Jacobsen, O. and D. Lynch, "Glossary of networking terms", 788 RFC 1208, March 1991. 790 [2] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 791 June 1995. 793 [3] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. 794 Lear, "Address Allocation for Private Internets", BCP 5, 795 RFC 1918, February 1996. 797 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 798 Levels", BCP 14, RFC 2119, March 1997. 800 [5] Fraser, B., "Site Security Handbook", RFC 2196, September 1997. 802 [6] Ferguson, P. and D. Senie, "Network Ingress Filtering: 803 Defeating Denial of Service Attacks which employ IP Source 804 Address Spoofing", BCP 38, RFC 2827, May 2000. 806 [7] Killalea, T., "Recommended Internet Service Provider Security 807 Services and Procedures", BCP 46, RFC 3013, November 2000. 809 [8] Stone, J., Stewart, R., and D. Otis, "Stream Control 810 Transmission Protocol (SCTP) Checksum Change", RFC 3309, 811 September 2002. 813 [9] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. 815 [10] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 816 Networks", BCP 84, RFC 3704, March 2004. 818 7.2. Informational References 820 [11] Jones, G., "Framework for Operational Security Capabilities for 821 IP Network Infrastructure", draft-ietf-opsec-framework-01 822 (work in progress), October 2005. 824 [12] Kaeo, M., "Operational Security Current Practices", 825 draft-ietf-opsec-current-practices-02 (work in progress), 826 October 2005. 828 [13] Bellovin, S., Schiller, J., and C. Kaufman, "Security 829 Mechanisms for the Internet", RFC 3631, December 2003. 831 [14] Jones, G., "Operational Security Requirements for Large 832 Internet Service Provider (ISP) IP Network Infrastructure", 833 RFC 3871, September 2004. 835 Authors' Addresses 837 Ross W. Callon 838 Juniper Networks 839 10 Technology Park Drive 840 Westford, MA 01886 841 USA 843 Email: rcallon@juniper.net 845 George Jones 846 The Mitre Corporation 847 7515 Colshire Drive 848 McLean, Virginia, VA 22102-7508 849 USA 851 Email: gmjones@mitre.org 853 Intellectual Property Statement 855 The IETF takes no position regarding the validity or scope of any 856 Intellectual Property Rights or other rights that might be claimed to 857 pertain to the implementation or use of the technology described in 858 this document or the extent to which any license under such rights 859 might or might not be available; nor does it represent that it has 860 made any independent effort to identify any such rights. Information 861 on the procedures with respect to rights in RFC documents can be 862 found in BCP 78 and BCP 79. 864 Copies of IPR disclosures made to the IETF Secretariat and any 865 assurances of licenses to be made available, or the result of an 866 attempt made to obtain a general license or permission for the use of 867 such proprietary rights by implementers or users of this 868 specification can be obtained from the IETF on-line IPR repository at 869 http://www.ietf.org/ipr. 871 The IETF invites any interested party to bring to its attention any 872 copyrights, patents or patent applications, or other proprietary 873 rights that may cover technology that may be required to implement 874 this standard. Please address the information to the IETF at 875 ietf-ipr@ietf.org. 877 Disclaimer of Validity 879 This document and the information contained herein are provided on an 880 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 881 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 882 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 883 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 884 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 885 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 887 Copyright Statement 889 Copyright (C) The Internet Society (2006). This document is subject 890 to the rights, licenses and restrictions contained in BCP 78, and 891 except as set forth therein, the authors retain all their rights. 893 Acknowledgment 895 Funding for the RFC Editor function is currently provided by the 896 Internet Society.