idnits 2.17.1 draft-ietf-opsec-filter-caps-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2421. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2411. ** 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 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.) ** There are 6 instances of lines with control characters in the document. ** The abstract seems to contain references ([I-D.practices]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (May 12, 2006) is 6558 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) == Missing Reference: 'RFC3360' is mentioned on line 1860, but not defined == Missing Reference: 'RFC2827' is mentioned on line 2055, but not defined == Unused Reference: 'RFC2828' is defined on line 2328, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-opsec-current-practices-00 == Outdated reference: A later version (-10) exists of draft-sanjib-private-vlan-02 -- Obsolete informational reference (is this intentional?): RFC 2828 (Obsoleted by RFC 4949) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 None. C. Morrow 3 Internet-Draft UUNET Technologies 4 Expires: October 12, 2006 G. Jones 5 The MITRE Corporation 6 V. Manral 7 IPInfusion 8 May 12, 2006 10 Filtering Capabilities for IP Network Infrastructure 11 draft-ietf-opsec-filter-caps-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on October 12, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 [I-D.practices] lists operator practices related to securing 45 networks. This document lists filtering capabilities needed to 46 support those practices. 48 Capabilities are defined without reference to specific technologies. 50 This is done to leave room for deployment of new technologies that 51 implement the capability. Each capability cites the practices it 52 supports. Current implementations that support the capability are 53 cited. Special considerations are discussed as appropriate listing 54 operational and resource constraints, limitations of current 55 implementations, tradeoffs, etc. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 1.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 6 61 1.2. Capabilities or Requirements ? . . . . . . . . . . . . . . 7 62 1.3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 64 2. Functional Capabilities - Filtering non-transit traffic 65 (management plane) . . . . . . . . . . . . . . . . . . . . . . 9 66 2.1. Filtering TO the Device . . . . . . . . . . . . . . . . . 9 67 2.1.1. Ability to Filter Traffic on All Interfaces TO the 68 Device . . . . . . . . . . . . . . . . . . . . . . . . 9 69 2.1.2. Ability to Filter Traffic To the Device . . . . . . . 10 70 2.1.3. Ability to Filter Traffic To the Device - Minimal 71 Performance Degradation . . . . . . . . . . . . . . . 10 72 2.1.4. Ability to Filter To the Device - Specify Filter 73 Actions . . . . . . . . . . . . . . . . . . . . . . . 12 74 2.1.5. Ability to Filter To the Device - Log Filter 75 Actions . . . . . . . . . . . . . . . . . . . . . . . 13 76 2.1.6. Ability to Filter To the Device - Specify Log 77 Granularity . . . . . . . . . . . . . . . . . . . . . 14 78 2.1.7. Ability to Filter To the Device - Ability to 79 Filter Protocols . . . . . . . . . . . . . . . . . . . 15 80 2.1.8. Ability to Filter To the Device - Ability to 81 Filter Addresses . . . . . . . . . . . . . . . . . . . 15 82 2.1.9. Ability to Filter To the Device - Ability to 83 Filter Protocol Header Fields . . . . . . . . . . . . 16 84 2.1.10. Ability to Filter To the Device - Ability to 85 Filter Inbound and Outbound . . . . . . . . . . . . . 17 86 2.1.11. Ability to Filter To the Device - Ability to 87 Accurately Count Filter Hits . . . . . . . . . . . . . 18 88 2.1.12. Ability to Filter To the Device - Ability to 89 Display Filter Counters . . . . . . . . . . . . . . . 19 90 2.1.13. Ability to Filter To the Device - Ability to 91 Display Filter Counters per Filter Application . . . . 20 92 2.1.14. Ability to Filter To the Device - Ability to Reset 93 Filter Counters . . . . . . . . . . . . . . . . . . . 21 94 2.1.15. Ability to Filter To the Device - Filter Counters 95 are Accurate . . . . . . . . . . . . . . . . . . . . . 22 96 2.2. Rate Limit TO the Device . . . . . . . . . . . . . . . . . 22 97 2.2.1. Ability to Rate limit Traffic on All Interfaces TO 98 the Device . . . . . . . . . . . . . . . . . . . . . . 22 99 2.2.2. Ability to Rate Limit Traffic To the Device . . . . . 23 100 2.2.3. Ability to Rate Limit Traffic To the Device - 101 Minimal Performance Degradation . . . . . . . . . . . 24 102 2.2.4. Ability to Rate Limit To the Device - Specify Rate 103 Limit Actions . . . . . . . . . . . . . . . . . . . . 26 104 2.2.5. Ability to Rate Limit To the Device - Log Rate 105 Limit Actions . . . . . . . . . . . . . . . . . . . . 27 106 2.2.6. Ability to Rate Limit To the Device - Specify Log 107 Granularity . . . . . . . . . . . . . . . . . . . . . 28 108 2.2.7. Ability to Rate Limit To the Device - Ability to 109 Rate Limit Protocols . . . . . . . . . . . . . . . . . 28 110 2.2.8. Ability to Rate Limit To the Device - Ability to 111 Rate Limit Addresses . . . . . . . . . . . . . . . . . 29 112 2.2.9. Ability to Rate Limit To the Device - Ability to 113 Rate Limit Protocol Header Fields . . . . . . . . . . 30 114 2.2.10. Ability to Rate Limit To the Device - Ability to 115 Rate Limit Inbound and Outbound . . . . . . . . . . . 31 116 2.2.11. Ability to Rate Limit To the Device - Ability to 117 Accurately Count Rate Limit Hits . . . . . . . . . . . 32 118 2.2.12. Ability to Rate Limit To the Device - Ability to 119 Display Rate Limit Counters . . . . . . . . . . . . . 33 120 2.2.13. Ability to Rate Limit To the Device - Ability to 121 Display Rate Limit Counters per Rate Limit 122 Application . . . . . . . . . . . . . . . . . . . . . 33 123 2.2.14. Ability to Rate Limit To the Device - Ability to 124 Reset Rate Limit Counters . . . . . . . . . . . . . . 34 125 2.2.15. Ability to Rate Limit To the Device - Rate Limit 126 Counters are Accurate . . . . . . . . . . . . . . . . 35 127 3. Functional Capabilities - Filtering transit traffic (data 128 plane) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 129 3.1. Filtering THROUGH the Device . . . . . . . . . . . . . . . 37 130 3.1.1. Ability to Filter Traffic on All Interfaces 131 THROUGH the Device . . . . . . . . . . . . . . . . . . 37 132 3.1.2. Ability to Filter Traffic Through the Device . . . . . 38 133 3.1.3. Ability to Filter Traffic Through the Device - 134 Minimal Performance Degradation . . . . . . . . . . . 38 135 3.1.4. Ability to Filter Through the Device - Specify 136 Filter Actions . . . . . . . . . . . . . . . . . . . . 40 137 3.1.5. Ability to Filter Through the Device - Log Filter 138 Actions . . . . . . . . . . . . . . . . . . . . . . . 41 139 3.1.6. Ability to Filter Through the Device - Specify Log 140 Granularity . . . . . . . . . . . . . . . . . . . . . 42 141 3.1.7. Ability to Filter Through the Device - Ability to 142 Filter Protocols . . . . . . . . . . . . . . . . . . . 43 143 3.1.8. Ability to Filter Through the Device - Ability to 144 Filter Addresses . . . . . . . . . . . . . . . . . . . 43 146 3.1.9. Ability to Filter Through the Device - Ability to 147 Filter Protocol Header Fields . . . . . . . . . . . . 44 148 3.1.10. Ability to Filter Through the Device - Ability to 149 Filter Inbound and Outbound . . . . . . . . . . . . . 45 150 3.1.11. Ability to Filter Through the Device - Ability to 151 Accurately Count Filter Hits . . . . . . . . . . . . . 46 152 3.1.12. Ability to Filter Through the Device - Ability to 153 Display Filter Counters . . . . . . . . . . . . . . . 47 154 3.1.13. Ability to Filter Through the Device - Ability to 155 Display Filter Counters per Filter Application . . . . 48 156 3.1.14. Ability to Filter Through the Device - Ability to 157 Reset Filter Counters . . . . . . . . . . . . . . . . 49 158 3.1.15. Ability to Filter Through the Device - Filter 159 Counters are Accurate . . . . . . . . . . . . . . . . 50 160 3.2. Rate Limit THROUGH the Device . . . . . . . . . . . . . . 50 161 3.2.1. Ability to Rate limit Traffic on All Interfaces 162 THROUGH the Device . . . . . . . . . . . . . . . . . . 51 163 3.2.2. Ability to Rate Limit Traffic Through the Device . . . 51 164 3.2.3. Ability to Rate Limit Traffic Through the Device - 165 Minimal Performance Degradation . . . . . . . . . . . 52 166 3.2.4. Ability to Rate Limit Through the Device - Specify 167 Rate Limit Actions . . . . . . . . . . . . . . . . . . 54 168 3.2.5. Ability to Rate Limit Through the Device - Log 169 Rate Limit Actions . . . . . . . . . . . . . . . . . . 55 170 3.2.6. Ability to Rate Limit Through the Device - Specify 171 Log Granularity . . . . . . . . . . . . . . . . . . . 56 172 3.2.7. Ability to Rate Limit Through the Device - Ability 173 to Rate Limit Protocols . . . . . . . . . . . . . . . 57 174 3.2.8. Ability to Rate Limit Through the Device - Ability 175 to Rate Limit Addresses . . . . . . . . . . . . . . . 57 176 3.2.9. Ability to Rate Limit Through the Device - Ability 177 to Rate Limit Protocol Header Fields . . . . . . . . . 58 178 3.2.10. Ability to Rate Limit Through the Device - Ability 179 to Rate Limit Inbound and Outbound . . . . . . . . . . 59 180 3.2.11. Ability to Rate Limit Through the Device - Ability 181 to Accurately Count Rate Limit Hits . . . . . . . . . 60 182 3.2.12. Ability to Rate Limit Through the Device - Ability 183 to Display Rate Limit Counters . . . . . . . . . . . . 61 184 3.2.13. Ability to Rate Limit Through the Device - Ability 185 to Display Rate Limit Counters per Rate Limit 186 Application . . . . . . . . . . . . . . . . . . . . . 62 187 3.2.14. Ability to Rate Limit Through the Device - Ability 188 to Reset Rate Limit Counters . . . . . . . . . . . . . 63 189 3.2.15. Ability to Rate Limit Through the Device - Rate 190 Limit Counters are Accurate . . . . . . . . . . . . . 64 191 4. Functional Capabilities - Filtering Layer 2 Attributes . . . . 65 192 4.1. Filtering Layer 2 . . . . . . . . . . . . . . . . . . . . 65 193 4.1.1. Ability to partition layer-2 network to provide 194 different levels of security . . . . . . . . . . . . . 65 195 4.1.2. Ability to restrict access to specified hardware 196 (MAC) addresses . . . . . . . . . . . . . . . . . . . 66 197 4.1.3. Ability to restrict based on layer-2 packet type 198 [etherType] field . . . . . . . . . . . . . . . . . . 67 199 5. Additional Operational Practices . . . . . . . . . . . . . . . 68 200 5.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 68 201 5.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 68 202 5.3. Limit Sources of Management . . . . . . . . . . . . . . . 68 203 6. Security Considerations . . . . . . . . . . . . . . . . . . . 69 204 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 205 7.1. Normative References . . . . . . . . . . . . . . . . . . . 70 206 7.2. Non-normative References . . . . . . . . . . . . . . . . . 70 207 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 71 208 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 72 209 Intellectual Property and Copyright Statements . . . . . . . . . . 73 211 1. Introduction 213 This document is defined in the context of [I-D.practices]. 214 [I-D.practices] defines the goals, motivation, scope, definitions, 215 intended audience,threat model, potential attacks and give 216 justifications for each of the practices. Many of the capabilities 217 listed here refine or add to capabilities listed in [RFC3871] 219 1.1. Threat Model 221 Threats in today's networked environment range from simple packet 222 floods with overwhelming bandwidth toward a leaf network to subtle 223 attacks aimed at subverting known vulnerabilities in existing 224 applications. The attacked network or host might not be an end user, 225 it may be the networking device or links inside the provider core. 227 Networks must have the ability to place mitigation in order to limit 228 these threats. These mitigation steps could include routing updates, 229 traffic filters, and routing filters. It is possible that the 230 mitigation steps might have to affect transit traffic as well as 231 traffic destined to the device on which the mitigation steps are 232 activated. 234 The scope of the threat includes simply denying services to an 235 individual customer on one side of the scale to exploiting a newly 236 discovered protocol vulnerability which affects the entire provider 237 core. The obvious risk to the business requires mitigation 238 capabilities which can span this range of threats. 240 Threat: An indication of impending danger or harm to the network or 241 its parts. This could be formed from the projected loss of revenue 242 to the business. Additionally, it could be formed from the increased 243 cost to the business caused by the event. (more interfaces, more 244 bandwidth, more personnel to support the increased size or 245 complexity) 247 Risk: The possibility of suffering harm or loss of network services 248 due to a threat. 250 Attack: To set upon with violent force the network or its parts. 251 Typically this is a form of flood of packets to or through a network. 252 This could also be a much smaller stream of packets created with the 253 intent of exploiting a vulnerability in the infrastructure of the 254 network. 256 Asset: Either a customer, network device or network link. Any of 257 these could be assets from a business perspective. 259 These terms are more completely defined in RFC2828 we have added some 260 scope specific information only. 262 1.2. Capabilities or Requirements ? 264 Capabilities may or may not be requirements. That is a local 265 determination that must be made by each operator with reference to 266 the policies that they must support. It is hoped that this document, 267 together with [I-D.practices] will assist operators in identifying 268 their security capability requirements and communicating them clearly 269 to vendors. 271 1.3. Format 273 Each capability has the following subsections: 275 o Capability (what) 277 o Supported Practices (why) 279 o Current Implementations (how) 281 o Considerations (caveats, resource issues, protocol issues, etc.) 283 The Capability section describes a feature to be supported by the 284 device. The Supported Practice section cites practices described in 285 [I-D.practices] that are supported by this capability. The Current 286 Implementation section is intended to give examples of 287 implementations of the capability, citing technology and standards 288 current at the time of writing. See [RFC3631]. It is expected that 289 the choice of features to implement the capabilities will change over 290 time. The Considerations section lists operational and resource 291 constraints, limitations of current implementations, tradeoffs, etc. 293 [EDITORS NOTE: this is a first draft. At least two editing passes 294 will be made over the capabilities listed below in future drafts: one 295 will break out compound capabilities into individual capabilities, 296 the other will try to align the supported practices with the 297 practices listed in [I-D.practices]] 299 1.4. Definitions 301 RFC 2119 Keywords 303 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 304 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 305 in this document are to be interpreted as described in [RFC2119]. 307 The use of the RFC 2119 keywords is an attempt, by the editor, to 308 assign the correct requirement levels ("MUST", "SHOULD", 309 "MAY"...). It must be noted that different organizations, 310 operational environments, policies and legal environments will 311 generate different requirement levels. 313 2. Functional Capabilities - Filtering non-transit traffic (management 314 plane) 316 The capabilities in this section are intended to list testable, 317 functional capabilities that are needed to operate devices securely. 318 Focusing on filtering non-transit packets on devices, controlling 319 access to the management plane. 321 2.1. Filtering TO the Device 323 2.1.1. Ability to Filter Traffic on All Interfaces TO the Device 325 Capability. 327 The device provides a means to filter IP packets on any interface 328 implementing IP that are non-transit packets. 330 Supported Practices. 332 * Profile Current Traffic ([I-D.practices] Section x.x.x) 334 * Block Malicious Packets (Section 5.2) 336 * Limit Sources of Management (Section 5.3) 338 Current Implementations. 340 Many devices currently implement access control lists or filters 341 that allow filtering based on protocol and/or source/destination 342 address and or source/destination port and allow these filters to 343 be applied to interfaces. 345 Considerations. 347 None. 349 2.1.2. Ability to Filter Traffic To the Device 351 Capability. 353 It is possible to apply the filtering mechanism to traffic that is 354 addressed directly to the device via any of its interfaces - 355 including loopback interfaces. 357 Supported Practices. 359 * This allows the operator to apply filters that protect the 360 device itself from attacks and unauthorized access. 362 Current Implementations. 364 Many devices currently implement access control lists or filters 365 that allow filtering based on protocol and/or source/destination 366 address and or source/destination port and allow these filters to 367 be applied to services offered by the device. 369 Examples of this might include filters that permit only BGP from 370 peers and SNMP and SSH from an authorized management segment and 371 directed to the device itself, while dropping all other traffic 372 addressed to the device. 374 Considerations. 376 None. 378 2.1.3. Ability to Filter Traffic To the Device - Minimal Performance 379 Degradation 381 Capability. 383 The device provides a means to filter packets without significant 384 performance degradation. This specifically applies to stateless 385 packet filtering operating on layer 3 (IP) and layer 4 (TCP or 386 UDP) headers, as well as normal packet forwarding information such 387 as incoming and outgoing interfaces. 389 The device is able to apply stateless packet filters on ALL 390 interfaces (up to the maximum number possible) simultaneously and 391 with multiple filters per interface (e.g., inbound and outbound). 393 The filtering of traffic destined to interfaces on the device, 394 including the loopback interface, should not degrade performance 395 significantly. 397 Supported Practices. 399 * This enables the implementation of filters on whichever 400 services necessary. To the extent that filtering causes 401 degradation, it may not be possible to apply filters that 402 implement the appropriate policies. 404 Current Implementations. 406 Another way of stating the capability is that filter performance 407 should not be the limiting factor in device throughput. If a 408 device is capable of forwarding 30Mb/sec without filtering, then 409 it should be able to forward the same amount with filtering in 410 place. 412 Considerations. 414 The definition of "significant" is subjective. At one end of the 415 spectrum it might mean "the application of filters may cause the 416 box to crash". At the other end would be a throughput loss of 417 less than one percent with tens of thousands of filters applied. 419 The level of performance degradation that is acceptable will have 420 to be determined by the operator. 422 Repeatable test data showing filter performance impact would be 423 very useful in evaluating this capability. Tests should include 424 such information as packet size, packet rate, number of interfaces 425 tested (source/destination), types of interfaces, routing table 426 size, routing protocols in use, frequency of routing updates, etc. 428 This capability does not address stateful filtering, filtering 429 above layer 4 headers or other more advanced types of filtering 430 that may be important in certain operational environments. 432 2.1.4. Ability to Filter To the Device - Specify Filter Actions 434 Capability. 436 The device provides a mechanism to allow the specification of the 437 action to be taken when a filter rule matches. Actions include 438 "permit" (allow the traffic), "reject" (drop with appropriate 439 notification to sender), and "drop" (drop with no notification to 440 sender). 442 Supported Practices. 444 * This capability is essential to the use of filters to enforce 445 policy. 447 Current Implementations. 449 Assume that your management devices for deployed networking 450 devices live on several subnets, use several protocols, and are 451 controlled by several different parts of your organization. There 452 might exist a reason to have disparate policies for access to the 453 devices from these parts of the organization. 455 Actions such as "permit", "deny", "drop" are essential in defining 456 the security policy for the services offered by the network 457 devices. 459 Considerations. 461 While silently dropping traffic without sending notification may 462 be the correct action in security terms, consideration should be 463 given to operational implications. See [RFC3360] for 464 consideration of potential problems caused by sending 465 inappropriate TCP Resets. 467 2.1.5. Ability to Filter To the Device - Log Filter Actions 469 Capability. 471 It is possible to log all filter actions. The logging capability 472 is able to capture at least the following data: 474 * permit/deny/drop status 476 * source and destination IP address 478 * source and destination ports (if applicable to the protocol) 480 * which network element received the packet (interface, MAC 481 address or other layer 2 information that identifies the 482 previous hop source of the packet). 484 Supported Practices. 486 * Logging is essential for auditing, incident response, and 487 operations 489 Current Implementations. 491 Actions such as "permit", "deny", "drop" are essential in defining 492 the security policy for the services offered by the network 493 devices. Auditing the frequency, sources and destinations of 494 these attempts is essential for tracking ongoing issues today. 496 Considerations. 498 Logging can be burdensome to the network device, at no time should 499 logging cause performance degradation to the device or services 500 offered on the device. 502 2.1.6. Ability to Filter To the Device - Specify Log Granularity 504 Capability. 506 It is possible to enable/disable logging on a per rule basis. 508 Supported Practices. 510 * The ability to tune the granularity of logging allows the 511 operator to log the information that is desired and only the 512 information that is desired. Without this capability, it is 513 possible that extra data (or none at all) would be logged, 514 making it more difficult to find relevant information. 516 Current Implementations. 518 If a filter is defined that has several rules, and one of the 519 rules denies telnet (tcp/23) connections, then it should be 520 possible to specify that only matches on the rule that denies 521 telnet should generate a log message. 523 Considerations. 525 None. 527 2.1.7. Ability to Filter To the Device - Ability to Filter Protocols 529 Capability. 531 The device provides a means to filter traffic based on the value 532 of the protocol field in the IP header. 534 Supported Practices. 536 * Being able to filter on protocol is necessary to allow 537 implementation of policy, secure operations and for support of 538 incident response. 540 Current Implementations. 542 Some denial of service attacks are based on the ability to flood 543 the victim with ICMP traffic. One quick way (admittedly with some 544 negative side effects) to mitigate the effects of such attacks is 545 to drop all ICMP traffic headed toward the victim. 547 Considerations. 549 None. 551 2.1.8. Ability to Filter To the Device - Ability to Filter Addresses 552 Capability. 554 The function is able to control the flow of traffic based on 555 source and/or destination IP address or blocks of addresses such 556 as Classless Inter-Domain Routing (CIDR) blocks. 558 Supported Practices. 560 * The capability to filter on addresses and address blocks is a 561 fundamental tool for establishing boundaries between different 562 networks. 564 Current Implementations. 566 One example of the use of address based filtering is to implement 567 ingress filtering per [RFC2827]. 569 Considerations. 571 None. 573 2.1.9. Ability to Filter To the Device - Ability to Filter Protocol 574 Header Fields 576 Capability. 578 The filtering mechanism supports filtering based on the value(s) 579 of any portion of the protocol headers for IP, ICMP, UDP and TCP. 580 It supports filtering of all other protocols supported at layer 3 581 and 4. It supports filtering based on the headers of higher level 582 protocols. It is possible to specify fields by name (e.g., 583 "protocol = ICMP") rather than bit- offset/length/numeric value 584 (e.g., 72:8 = 1). 586 Supported Practices. 588 * Being able to filter on portions of the header is necessary to 589 allow implementation of policy, secure operations, and support 590 incident response. 592 Current Implementations. 594 This capability implies that it is possible to filter based on TCP 595 or UDP port numbers, TCP flags such as SYN, ACK and RST bits, and 596 ICMP type and code fields. One common example is to reject 597 "inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear 598 or SYN bit set+ACK,FIN and RST bits clear). Another common 599 example is the ability to control what services are allowed in/out 600 of a network. It may be desirable to only allow inbound 601 connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting 602 web servers. 604 Considerations. 606 None. 608 2.1.10. Ability to Filter To the Device - Ability to Filter Inbound and 609 Outbound 611 Capability. 613 It is possible to filter both incoming and outgoing traffic on any 614 interface. 616 Supported Practices. 618 * This capability allows flexibility in applying filters at the 619 place that makes the most sense. It allows invalid or 620 malicious traffic to be dropped as close to the source as 621 possible. 623 Current Implementations. 625 It might be desirable on a border router, for example, to apply an 626 egress filter outbound on the interface that connects a site to 627 its external ISP to drop outbound traffic that does not have a 628 valid internal source address. Inbound, it might be desirable to 629 apply a filter that blocks all traffic from a site that is known 630 to forward or originate lots of junk mail. 632 Considerations. 634 None. 636 2.1.11. Ability to Filter To the Device - Ability to Accurately Count 637 Filter Hits 639 Capability. 641 The device supplies a facility for accurately counting all filter 642 matches. 644 Supported Practices. 646 * Accurate counting of filter rule matches is important because 647 it shows the frequency of attempts to violate policy. This 648 enables resources to be focused on areas of greatest need. 650 Current Implementations. 652 Assume, for example, that a ISP network implements anti-spoofing 653 egress filters (see [RFC2827]) on interfaces of its edge routers 654 that support single-homed stub networks. Counters could enable 655 the ISP to detect cases where large numbers of spoofed packets are 656 being sent. This may indicate that the customer is performing 657 potentially malicious actions (possibly in violation of the ISPs 658 Acceptable Use Policy), or that system(s) on the customers network 659 have been "owned" by hackers and are being (mis)used to launch 660 attacks. 662 Considerations. 664 None. 666 2.1.12. Ability to Filter To the Device - Ability to Display Filter 667 Counters 669 Capability. 671 The device provides a mechanism to display filter counters. 673 Supported Practices. 675 * Information that is collected is not useful unless it can be 676 displayed in a useful manner. 678 Current Implementations. 680 Assume there is a router with four interfaces. One is an up-link 681 to an ISP providing routes to the Internet. The other three 682 connect to separate internal networks. Assume that a host on one 683 of the internal networks has been compromised by a hacker and is 684 sending traffic with bogus source addresses. In such a situation, 685 it might be desirable to apply ingress filters to each of the 686 internal interfaces. Once the filters are in place, the counters 687 can be examined to determine the source (inbound interface) of the 688 bogus packets. 690 Considerations. 692 None. 694 2.1.13. Ability to Filter To the Device - Ability to Display Filter 695 Counters per Filter Application 697 Capability. 699 If it is possible for a filter to be applied more than once at the 700 same time, then the device provides a mechanism to display filter 701 counters per filter application. 703 Supported Practices. 705 * It may make sense to apply the same filter definition 706 simultaneously more than one time (to different interfaces, 707 etc.). If so, it would be much more useful to know which 708 instance of a filter is matching than to know that some 709 instance was matching somewhere. 711 Current Implementations. 713 One way to implement this capability would be to have the counter 714 display mechanism show the interface (or other entity) to which 715 the filter has been applied, along with the name (or other 716 designator) for the filter. For example if a filter named 717 "desktop_outbound" applied two different interfaces, say, 718 "ethernet0" and "ethernet1", the display should indicate something 719 like "matches of filter 'desktop_outbound' on ethernet0 ..." and 720 "matches of filter 'desktop_outbound' on ethernet1 ..." 722 Considerations. 724 None. 726 2.1.14. Ability to Filter To the Device - Ability to Reset Filter 727 Counters 729 Capability. 731 It is possible to reset counters to zero on a per filter basis. 733 For the purposes of this capability it would be acceptable for the 734 system to maintain two counters: an "absolute counter", C[now], 735 and a "reset" counter, C[reset]. The absolute counter would 736 maintain counts that increase monotonically until they wrap or 737 overflow the counter. The reset counter would receive a copy of 738 the current value of the absolute counter when the reset function 739 was issued for that counter. Functions that display or retrieve 740 the counter could then display the delta (C[now] - C[reset]). 742 Supported Practices. 744 * This allows operators to get a current picture of the traffic 745 matching particular rules/filters. 747 Current Implementations. 749 Assume that filter counters are being used to detect internal 750 hosts that are infected with a new worm. Once it is believed that 751 all infected hosts have been cleaned up and the worm removed, the 752 next step would be to verify that. One way of doing so would be 753 to reset the filter counters to zero and see if traffic indicative 754 of the worm has ceased. 756 Considerations. 758 None. 760 2.1.15. Ability to Filter To the Device - Filter Counters are Accurate 762 Capability. 764 Filter counters are accurate. They reflect the actual number of 765 matching packets since the last counter reset. Filter counters 766 are be capable of holding up to 2^32 - 1 values without 767 overflowing and should be capable of holding up to 2^64 - 1 768 values. 770 Supported Practices. 772 * Inaccurate data can not be relied on as the basis for action. 773 Underreported data can conceal the magnitude of a problem. 775 Current Implementations. 777 If N packets matching a filter are sent to/through a device, then 778 the counter should show N matches. 780 Considerations. 782 None. 784 2.2. Rate Limit TO the Device 786 2.2.1. Ability to Rate limit Traffic on All Interfaces TO the Device 787 Capability. 789 The device provides a means to rate limit IP packets on any 790 interface implementing IP that are non-transit packets. 792 Supported Practices. 794 * Profile Current Traffic ([I-D.practices] Section x.x.x) 796 * Block Malicious Packets (Section 5.2) 798 * Limit Sources of Management (Section 5.3) 800 Current Implementations. 802 Many devices currently implement rate limits that allow rate 803 limiting based on protocol and/or source/destination address and 804 or source/destination port or raw bandwidth and allow these limits 805 to be applied to interfaces. 807 Considerations. 809 None. 811 2.2.2. Ability to Rate Limit Traffic To the Device 813 Capability. 815 It is possible to apply the rate-limiting mechanism to traffic 816 that is addressed directly to the device via any of its interfaces 817 - including loopback interfaces. 819 Supported Practices. 821 * This allows the operator to apply rate-limits that protect the 822 device itself from attacks and unauthorized access. 824 Current Implementations. 826 Many devices currently implement rate-limits that allow limiting 827 based on protocol and/or source/destination address and or source/ 828 destination port and allow these limits to be applied to services 829 offered by the device. 831 Examples of this might include rate-limits that permit BGP traffic 832 rates up to 100 megabits per second from an authorized peer, while 833 dropping all other traffic addressed to the device which exceeds 834 this limit. 836 Considerations. 838 None. 840 2.2.3. Ability to Rate Limit Traffic To the Device - Minimal 841 Performance Degradation 843 Capability. 845 The device provides a means to rate-limit packets without 846 significant performance degradation. 848 The device is able to apply rate-limits on ALL interfaces (up to 849 the maximum number possible) simultaneously and with multiple 850 rate-limits per interface (e.g., inbound, outbound, differing 851 traffic classifications in either direction). 853 The rate-limiting of traffic destined to interfaces on the device, 854 including the loopback interface, should not degrade performance 855 significantly. 857 Supported Practices. 859 * This enables the implementation of rate-limits on whichever 860 services are necessary. To the extent that rate-limiting 861 causes degradation, it may not be possible to apply rate-limits 862 that implement the appropriate policies. 864 Current Implementations. 866 Another way of stating the capability is that rate-limit 867 performance should not be the limiting factor in device 868 throughput. If a device is capable of forwarding 30Mb/sec without 869 rate-limits, then it should be able to forward the same amount 870 with rate-limits in place. 872 Considerations. 874 The definition of "significant" is subjective. At one end of the 875 spectrum it might mean "the application of rate-limits may cause 876 the box to crash". At the other end would be a throughput loss of 877 less than one percent with tens of thousands of rate-limits 878 applied. The level of performance degradation that is acceptable 879 will have to be determined by the operator. 881 Repeatable test data showing rate-limiting performance impact 882 would be very useful in evaluating this capability. Tests should 883 include such information as packet size, packet rate, number of 884 interfaces tested (source/destination), types of interfaces, 885 routing table size, routing protocols in use, frequency of routing 886 updates, etc. 888 2.2.4. Ability to Rate Limit To the Device - Specify Rate Limit Actions 890 Capability. 892 The device provides a mechanism to allow the specification of the 893 action to be taken when a rate-limit rule matches. Actions 894 include "permit" (allow the traffic), "reject" (drop with 895 appropriate notification to sender), and "drop" (drop with no 896 notification to sender). 898 Supported Practices. 900 * This capability is essential to the use of rate limits to 901 enforce policy. 903 Current Implementations. 905 Assume that your management devices for deployed networking 906 devices live on several subnets, use several protocols, and are 907 controlled by several different parts of your organization. There 908 might exist a reason to have disparate policies for access to the 909 devices from these parts of the organization. Further you may 910 want to limit traffic levels for these types of traffic from these 911 known sources. 913 Actions such as "permit", "deny", "drop" are essential in defining 914 the security policy for the services offered by the network 915 devices. 917 Considerations. 919 While silently dropping traffic without sending notification may 920 be the correct action in security terms, consideration should be 921 given to operational implications. See [RFC3360] for 922 consideration of potential problems caused by sending 923 inappropriate TCP Resets. 925 2.2.5. Ability to Rate Limit To the Device - Log Rate Limit Actions 927 Capability. 929 It is possible to log rate limit actions. The logging capability 930 is able to capture at least the following data: 932 * permit/deny/drop status 934 * source and destination IP address 936 * source and destination ports (if applicable to the protocol) 938 * which network element received the packet (interface, MAC 939 address or other layer 2 information that identifies the 940 previous hop source of the packet). 942 Supported Practices. 944 * Logging is essential for auditing, incident response, and 945 operations 947 Current Implementations. 949 Actions such as "permit", "deny", "drop" are essential in defining 950 the security policy for the services offered by the network 951 devices. Auditing the frequency, sources and destinations of 952 these attempts is essential for tracking ongoing issues today. 954 Considerations. 956 Logging can be burdensome to the network device, at no time should 957 logging cause performance degradation to the device or services 958 offered on the device. 960 2.2.6. Ability to Rate Limit To the Device - Specify Log Granularity 962 Capability. 964 It is possible to enable/disable logging on a per rule basis. 966 Supported Practices. 968 * The ability to tune the granularity of logging allows the 969 operator to log the information that is desired and only the 970 information that is desired. Without this capability, it is 971 possible that extra data (or none at all) would be logged, 972 making it more difficult to find relevant information. 974 Current Implementations. 976 If a rate limit is defined that has several rules, and one of the 977 rules denies telnet (tcp/23) connections, then it should be 978 possible to specify that only matches on the rule that denies 979 telnet should generate a log message. 981 Considerations. 983 None. 985 2.2.7. Ability to Rate Limit To the Device - Ability to Rate Limit 986 Protocols 988 Capability. 990 The device provides a means to rate limit traffic based on the 991 value of the protocol field in the IP header. 993 Supported Practices. 995 * Being able to rate limit on protocol is necessary to allow 996 implementation of policy, secure operations and for support of 997 incident response. 999 Current Implementations. 1001 Some denial of service attacks are based on the ability to flood 1002 the victim with ICMP traffic. One quick way (admittedly with some 1003 negative side effects) to mitigate the effects of such attacks is 1004 to rate limit all ICMP traffic headed toward the victim. 1006 Considerations. 1008 None. 1010 2.2.8. Ability to Rate Limit To the Device - Ability to Rate Limit 1011 Addresses 1013 Capability. 1015 The function is able to control the flow of traffic based on 1016 source and/or destination IP address or blocks of addresses such 1017 as Classless Inter-Domain Routing (CIDR) blocks. 1019 Supported Practices. 1021 * The capability to rate limit on addresses and address blocks is 1022 a fundamental tool for establishing boundaries between 1023 different networks. 1025 Current Implementations. 1027 One example of the use of address based rate limits is to 1028 implement ingress filtering per [RFC2827]. 1030 Considerations. 1032 None. 1034 2.2.9. Ability to Rate Limit To the Device - Ability to Rate Limit 1035 Protocol Header Fields 1037 Capability. 1039 The rate limit mechanism supports rate limiting based on the 1040 value(s) of any portion of the protocol headers for IP, ICMP, UDP 1041 and TCP. It supports rate limiting of all other protocols 1042 supported at layer 3 and 4. It supports rate limiting based on 1043 the headers of higher level protocols. It is possible to specify 1044 fields by name (e.g., "protocol = ICMP") rather than bit- offset/ 1045 length/numeric value (e.g., 72:8 = 1). 1047 Supported Practices. 1049 * Being able to rate limit on portions of the header is necessary 1050 to allow implementation of policy, secure operations, and 1051 support incident response. 1053 Current Implementations. 1055 This capability implies that it is possible to rate limit based on 1056 TCP or UDP port numbers, TCP flags such as SYN, ACK and RST bits, 1057 and ICMP type and code fields. One common example is to reject 1058 "inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear 1059 or SYN bit set+ACK,FIN and RST bits clear). Another common 1060 example is the ability to control what services are allowed in/out 1061 of a network. It may be desirable to only allow inbound 1062 connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting 1063 web servers. 1065 Considerations. 1067 None. 1069 2.2.10. Ability to Rate Limit To the Device - Ability to Rate Limit 1070 Inbound and Outbound 1072 Capability. 1074 It is possible to rate limit both incoming and outgoing traffic on 1075 any interface. 1077 Supported Practices. 1079 * This capability allows flexibility in applying rate limits at 1080 the place that makes the most sense. It allows invalid or 1081 malicious traffic to be dropped as close to the source as 1082 possible. 1084 Current Implementations. 1086 It might be desirable on a router to apply an egress rate limit to 1087 its external connections to limit outbound traffic that does not 1088 have a high priority. Inbound, it might be desirable to apply a 1089 rate limit to all traffic of a certain classification in order to 1090 preserve limited resources on the router's management components. 1092 Considerations. 1094 None. 1096 2.2.11. Ability to Rate Limit To the Device - Ability to Accurately 1097 Count Rate Limit Hits 1099 Capability. 1101 The device supplies a facility for accurately counting all rate 1102 limit matches. 1104 Supported Practices. 1106 * Accurate counting of rate limit rule matches is important 1107 because it shows the frequency of attempts to violate policy. 1108 This enables resources to be focused on areas of greatest need. 1110 Current Implementations. 1112 Assume, for example, that a ISP network implements anti-spoofing 1113 egress rate limits (see [RFC2827]) on interfaces of its edge 1114 routers that support single-homed stub networks. Counters could 1115 enable the ISP to detect cases where large numbers of spoofed 1116 packets are being sent. This may indicate that the customer is 1117 performing potentially malicious actions (possibly in violation of 1118 the ISPs Acceptable Use Policy), or that system(s) on the 1119 customers network have been compromised by hackers and are being 1120 (mis)used to launch attacks. 1122 Considerations. 1124 None. 1126 2.2.12. Ability to Rate Limit To the Device - Ability to Display Rate 1127 Limit Counters 1129 Capability. 1131 The device provides a mechanism to display rate limit counters. 1133 Supported Practices. 1135 * Information that is collected is not useful unless it can be 1136 displayed in a useful manner. 1138 Current Implementations. 1140 Assume there is a router with four interfaces. One is an up-link 1141 to an ISP providing routes to the Internet. The other three 1142 connect to separate internal networks. Assume that a host on one 1143 of the internal networks has been compromised by a hacker and is 1144 sending traffic with bogus source addresses. In such a situation, 1145 it might be desirable to apply ingress rate limits to each of the 1146 internal interfaces. Once the rate limits are in place, the 1147 counters can be examined to determine the source (inbound 1148 interface) of the bogus packets. 1150 Considerations. 1152 None. 1154 2.2.13. Ability to Rate Limit To the Device - Ability to Display Rate 1155 Limit Counters per Rate Limit Application 1157 Capability. 1159 If it is possible for a rate limit to be applied more than once at 1160 the same time, then the device provides a mechanism to display 1161 rate limit counters per rate limit application. 1163 Supported Practices. 1165 * It may make sense to apply the same rate limit definition 1166 simultaneously more than one time (to different interfaces, 1167 etc.). If so, it would be much more useful to know which 1168 instance of a rate limit is matching than to know that some 1169 instance was matching somewhere. 1171 Current Implementations. 1173 One way to implement this capability would be to have the counter 1174 display mechanism show the interface (or other entity) to which 1175 the rate limit has been applied, along with the name (or other 1176 designator) for the rate limit. For example if a rate limit named 1177 "desktop_outbound" applied two different interfaces, say, 1178 "ethernet0" and "ethernet1", the display should indicate something 1179 like "matches of rate limit 'desktop_outbound' on ethernet0 ..." 1180 and "matches of rate limit 'desktop_outbound' on ethernet1 ..." 1182 Considerations. 1184 None. 1186 2.2.14. Ability to Rate Limit To the Device - Ability to Reset Rate 1187 Limit Counters 1189 Capability. 1191 It is possible to reset counters to zero on a per rate limit 1192 basis. 1194 For the purposes of this capability it would be acceptable for the 1195 system to maintain two counters: an "absolute counter", C[now], 1196 and a "reset" counter, C[reset]. The absolute counter would 1197 maintain counts that increase monotonically until they wrap or 1198 overflow the counter. The reset counter would receive a copy of 1199 the current value of the absolute counter when the reset function 1200 was issued for that counter. Functions that display or retrieve 1201 the counter could then display the delta (C[now] - C[reset]). 1203 Supported Practices. 1205 * This allows operators to get a current picture of the traffic 1206 matching particular rules/rate limit. 1208 Current Implementations. 1210 Assume that rate limit counters are being used to detect internal 1211 hosts that are infected with a new worm. Once it is believed that 1212 all infected hosts have been cleaned up and the worm removed, the 1213 next step would be to verify that. One way of doing so would be 1214 to reset the rate limit counters to zero and see if traffic 1215 indicative of the worm has ceased. 1217 Considerations. 1219 None. 1221 2.2.15. Ability to Rate Limit To the Device - Rate Limit Counters are 1222 Accurate 1224 Capability. 1226 Rate limit counters are accurate. They reflect the actual number 1227 of matching packets since the last counter reset. Rate limit 1228 counters are be capable of holding up to 2^32 - 1 values without 1229 overflowing and should be capable of holding up to 2^64 - 1 1230 values. 1232 Supported Practices. 1234 * Inaccurate data can not be relied on as the basis for action. 1235 Underreported data can conceal the magnitude of a problem. 1237 Current Implementations. 1239 If N packets matching a Rate limit are sent to/through a device, 1240 then the counter should show N matches. 1242 Considerations. 1244 None. 1246 3. Functional Capabilities - Filtering transit traffic (data plane) 1248 The capabilities in this section are intended to list testable, 1249 functional capabilities that are needed to operate devices securely. 1250 Focusing on filtering transit packets on devices, controlling the 1251 data plane. 1253 3.1. Filtering THROUGH the Device 1255 3.1.1. Ability to Filter Traffic on All Interfaces THROUGH the Device 1257 Capability. 1259 The device provides a means to filter IP packets on any interface 1260 implementing IP that are transit packets. 1262 Supported Practices. 1264 * Profile Current Traffic ([I-D.practices] Section x.x.x) 1266 * Block Malicious Packets (Section 5.2) 1268 * Limit Sources of Management (Section 5.3) 1270 Current Implementations. 1272 Many devices currently implement access control lists or filters 1273 that allow filtering based on protocol and/or source/destination 1274 address and or source/destination port and allow these filters to 1275 be applied to interfaces. 1277 Considerations. 1279 None. 1281 3.1.2. Ability to Filter Traffic Through the Device 1283 Capability. 1285 It is possible to apply the filtering mechanism to traffic that is 1286 flowing through the device via any of its interfaces - transit 1287 traffic. 1289 Supported Practices. 1291 * This allows the operator to apply filters that protect the 1292 networks supported by the device from attacks and unauthorized 1293 access. 1295 Current Implementations. 1297 Many devices currently implement access control lists or filters 1298 that allow filtering based on protocol and/or source/destination 1299 address and or source/destination port and allow these filters to 1300 be applied to interfaces of the device for the purposes of 1301 protecting the networks that connect to the device. 1303 Examples of this might include filters that permit only HTTP from 1304 known good sources and SMTP and SSH from a known subset of the 1305 entire network, while dropping all other traffic. 1307 Considerations. 1309 None. 1311 3.1.3. Ability to Filter Traffic Through the Device - Minimal 1312 Performance Degradation 1314 Capability. 1316 The device provides a means to filter packets without significant 1317 performance degradation. This specifically applies to stateless 1318 packet filtering operating on layer 3 (IP) and layer 4 (TCP or 1319 UDP) headers, as well as normal packet forwarding information such 1320 as incoming and outgoing interfaces. 1322 The device is able to apply stateless packet filters on ALL 1323 interfaces (up to the maximum number possible) simultaneously and 1324 with multiple filters per interface (e.g., inbound and outbound). 1326 The filtering of traffic through the device should not degrade 1327 performance significantly. 1329 Supported Practices. 1331 * This enables the implementation of filters on necessary 1332 services for the networks supported by the device. To the 1333 extent that filtering causes degradation, it may not be 1334 possible to apply filters that implement the appropriate 1335 policies. 1337 Current Implementations. 1339 Another way of stating the capability is that filter performance 1340 should not be the limiting factor in device throughput. If a 1341 device is capable of forwarding 30Mb/sec without filtering, then 1342 it should be able to forward the same amount with filtering in 1343 place. 1345 Considerations. 1347 The definition of "significant" is subjective. At one end of the 1348 spectrum it might mean "the application of filters may cause the 1349 box to crash". At the other end would be a throughput loss of 1350 less than one percent with tens of thousands of filters applied. 1352 The level of performance degradation that is acceptable will have 1353 to be determined by the operator. 1355 Repeatable test data showing filter performance impact would be 1356 very useful in evaluating this capability. Tests should include 1357 such information as packet size, packet rate, number of interfaces 1358 tested (source/destination), types of interfaces, routing table 1359 size, routing protocols in use, frequency of routing updates, etc. 1361 This capability does not address stateful filtering, filtering 1362 above layer 4 headers or other more advanced types of filtering 1363 that may be important in certain operational environments. 1365 3.1.4. Ability to Filter Through the Device - Specify Filter Actions 1367 Capability. 1369 The device provides a mechanism to allow the specification of the 1370 action to be taken when a filter rule matches. Actions include 1371 "permit" (allow the traffic), "reject" (drop with appropriate 1372 notification to sender), and "drop" (drop with no notification to 1373 sender). 1375 Supported Practices. 1377 * This capability is essential to the use of filters to enforce 1378 policy. 1380 Current Implementations. 1382 Assume that your network's services live on several subnets, use 1383 several protocols, and are controlled by several different parts 1384 of your organization. There might exist a reason to have 1385 disparate policies for access to the devices from these parts of 1386 the organization. 1388 Actions such as "permit", "deny", "drop" are essential in defining 1389 the security policy for the services offered by the network 1390 devices. 1392 Considerations. 1394 While silently dropping traffic without sending notification may 1395 be the correct action in security terms, consideration should be 1396 given to operational implications. See [RFC3360] for 1397 consideration of potential problems caused by sending 1398 inappropriate TCP Resets. 1400 3.1.5. Ability to Filter Through the Device - Log Filter Actions 1402 Capability. 1404 It is possible to log all filter actions. The logging capability 1405 is able to capture at least the following data: 1407 * permit/deny/drop status 1409 * source and destination IP address 1411 * source and destination ports (if applicable to the protocol) 1413 * which network element received the packet (interface, MAC 1414 address or other layer 2 information that identifies the 1415 previous hop source of the packet). 1417 Supported Practices. 1419 * Logging is essential for auditing, incident response, and 1420 operations 1422 Current Implementations. 1424 Actions such as "permit", "deny", "drop" are essential in defining 1425 the security policy for the services offered by the network 1426 devices. Auditing the frequency, sources and destinations of 1427 these attempts is essential for tracking ongoing issues today. 1429 Considerations. 1431 Logging can be burdensome to the network device, at no time should 1432 logging cause performance degradation to the device or services 1433 offered on the device. 1435 3.1.6. Ability to Filter Through the Device - Specify Log Granularity 1437 Capability. 1439 It is possible to enable/disable logging on a per rule basis. 1441 Supported Practices. 1443 * The ability to tune the granularity of logging allows the 1444 operator to log the information that is desired and only the 1445 information that is desired. Without this capability, it is 1446 possible that extra data (or none at all) would be logged, 1447 making it more difficult to find relevant information. 1449 Current Implementations. 1451 If a filter is defined that has several rules, and one of the 1452 rules denies telnet (tcp/23) traffic, then it should be possible 1453 to specify that only matches on the rule that denies telnet should 1454 generate a log message. 1456 Considerations. 1458 None. 1460 3.1.7. Ability to Filter Through the Device - Ability to Filter 1461 Protocols 1463 Capability. 1465 The device provides a means to filter traffic based on the value 1466 of the protocol field in the IP header. 1468 Supported Practices. 1470 * Being able to filter on protocol is necessary to allow 1471 implementation of policy, secure operations and for support of 1472 incident response. 1474 Current Implementations. 1476 Some denial of service attacks are based on the ability to flood 1477 the victim with ICMP traffic. One quick way (admittedly with some 1478 negative side effects) to mitigate the effects of such attacks is 1479 to drop all ICMP traffic headed toward the victim. 1481 Considerations. 1483 None. 1485 3.1.8. Ability to Filter Through the Device - Ability to Filter 1486 Addresses 1488 Capability. 1490 The function is able to control the flow of traffic based on 1491 source and/or destination IP address or blocks of addresses such 1492 as Classless Inter-Domain Routing (CIDR) blocks. 1494 Supported Practices. 1496 * The capability to filter on addresses and address blocks is a 1497 fundamental tool for establishing boundaries between different 1498 networks. 1500 Current Implementations. 1502 One example of the use of address based filtering is to implement 1503 ingress filtering per [RFC2827]. 1505 Considerations. 1507 None. 1509 3.1.9. Ability to Filter Through the Device - Ability to Filter 1510 Protocol Header Fields 1512 Capability. 1514 The filtering mechanism supports filtering based on the value(s) 1515 of any portion of the protocol headers for IP, ICMP, UDP and TCP. 1516 It supports filtering of all other protocols supported at layer 3 1517 and 4. It supports filtering based on the headers of higher level 1518 protocols. It is possible to specify fields by name (e.g., 1519 "protocol = ICMP") rather than bit- offset/length/numeric value 1520 (e.g., 72:8 = 1). 1522 Supported Practices. 1524 * Being able to filter on portions of the header is necessary to 1525 allow implementation of policy, secure operations, and support 1526 incident response. 1528 Current Implementations. 1530 This capability implies that it is possible to filter based on TCP 1531 or UDP port numbers, TCP flags such as SYN, ACK and RST bits, and 1532 ICMP type and code fields. One common example is to reject TCP 1533 connection attempts (TCP, SYN bit set+ACK bit clear or SYN bit 1534 set+ACK,FIN and RST bits clear). Another common example is the 1535 ability to control what services are allowed in/out of a network. 1536 It may be desirable to only allow inbound connections on port 80 1537 (HTTP) and 443 (HTTPS) to a network hosting web servers. 1539 Considerations. 1541 None. 1543 3.1.10. Ability to Filter Through the Device - Ability to Filter 1544 Inbound and Outbound 1546 Capability. 1548 It is possible to filter both incoming and outgoing traffic on any 1549 interface. 1551 Supported Practices. 1553 * This capability allows flexibility in applying filters at the 1554 place that makes the most sense. It allows invalid or 1555 malicious traffic to be dropped as close to the source as 1556 possible. 1558 Current Implementations. 1560 It might be desirable on a border router, for example, to apply an 1561 egress filter outbound on the interface that connects a site to 1562 its external ISP to drop outbound traffic that does not have a 1563 valid internal source address. Inbound, it might be desirable to 1564 apply a filter that blocks all traffic from a site that is known 1565 to forward or originate lots of junk mail. 1567 Considerations. 1569 None. 1571 3.1.11. Ability to Filter Through the Device - Ability to Accurately 1572 Count Filter Hits 1574 Capability. 1576 The device supplies a facility for accurately counting all filter 1577 matches. 1579 Supported Practices. 1581 * Accurate counting of filter rule matches is important because 1582 it shows the frequency of attempts to violate policy. This 1583 enables resources to be focused on areas of greatest need. 1585 Current Implementations. 1587 Assume, for example, that a ISP network implements anti-spoofing 1588 egress filters (see [RFC2827]) on interfaces of its edge routers 1589 that support single-homed stub networks. Counters could enable 1590 the ISP to detect cases where large numbers of spoofed packets are 1591 being sent. This may indicate that the customer is performing 1592 potentially malicious actions (possibly in violation of the ISPs 1593 Acceptable Use Policy), or that system(s) on the customers network 1594 have been "owned" by hackers and are being (mis)used to launch 1595 attacks. 1597 Considerations. 1599 None. 1601 3.1.12. Ability to Filter Through the Device - Ability to Display 1602 Filter Counters 1604 Capability. 1606 The device provides a mechanism to display filter counters. 1608 Supported Practices. 1610 * Information that is collected is not useful unless it can be 1611 displayed in a useful manner. 1613 Current Implementations. 1615 Assume there is a router with four interfaces. One is an up-link 1616 to an ISP providing routes to the Internet. The other three 1617 connect to separate internal networks. Assume that a host on one 1618 of the internal networks has been compromised by a hacker and is 1619 sending traffic with bogus source addresses. In such a situation, 1620 it might be desirable to apply ingress filters to each of the 1621 internal interfaces. Once the filters are in place, the counters 1622 can be examined to determine the source (inbound interface) of the 1623 bogus packets. 1625 Considerations. 1627 None. 1629 3.1.13. Ability to Filter Through the Device - Ability to Display 1630 Filter Counters per Filter Application 1632 Capability. 1634 If it is possible for a filter to be applied more than once at the 1635 same time, then the device provides a mechanism to display filter 1636 counters per filter application. 1638 Supported Practices. 1640 * It may make sense to apply the same filter definition 1641 simultaneously more than one time (to different interfaces, 1642 etc.). If so, it would be much more useful to know which 1643 instance of a filter is matching than to know that some 1644 instance was matching somewhere. 1646 Current Implementations. 1648 One way to implement this capability would be to have the counter 1649 display mechanism show the interface (or other entity) to which 1650 the filter has been applied, along with the name (or other 1651 designator) for the filter. For example if a filter named 1652 "desktop_outbound" applied two different interfaces, say, 1653 "ethernet0" and "ethernet1", the display should indicate something 1654 like "matches of filter 'desktop_outbound' on ethernet0 ..." and 1655 "matches of filter 'desktop_outbound' on ethernet1 ..." 1657 Considerations. 1659 None. 1661 3.1.14. Ability to Filter Through the Device - Ability to Reset Filter 1662 Counters 1664 Capability. 1666 It is possible to reset counters to zero on a per filter basis. 1668 For the purposes of this capability it would be acceptable for the 1669 system to maintain two counters: an "absolute counter", C[now], 1670 and a "reset" counter, C[reset]. The absolute counter would 1671 maintain counts that increase monotonically until they wrap or 1672 overflow the counter. The reset counter would receive a copy of 1673 the current value of the absolute counter when the reset function 1674 was issued for that counter. Functions that display or retrieve 1675 the counter could then display the delta (C[now] - C[reset]). 1677 Supported Practices. 1679 * This allows operators to get a current picture of the traffic 1680 matching particular rules/filters. 1682 Current Implementations. 1684 Assume that filter counters are being used to detect internal 1685 hosts that are infected with a new worm. Once it is believed that 1686 all infected hosts have been cleaned up and the worm removed, the 1687 next step would be to verify that. One way of doing so would be 1688 to reset the filter counters to zero and see if traffic indicative 1689 of the worm has ceased. 1691 Considerations. 1693 None. 1695 3.1.15. Ability to Filter Through the Device - Filter Counters are 1696 Accurate 1698 Capability. 1700 Filter counters are accurate. They reflect the actual number of 1701 matching packets since the last counter reset. Filter counters 1702 are be capable of holding up to 2^32 - 1 values without 1703 overflowing and should be capable of holding up to 2^64 - 1 1704 values. 1706 Supported Practices. 1708 * Inaccurate data can not be relied on as the basis for action. 1709 Underreported data can conceal the magnitude of a problem. 1711 Current Implementations. 1713 If N packets matching a filter are sent to/through a device, then 1714 the counter should show N matches. 1716 Considerations. 1718 None. 1720 3.2. Rate Limit THROUGH the Device 1721 3.2.1. Ability to Rate limit Traffic on All Interfaces THROUGH the 1722 Device 1724 Capability. 1726 The device provides a means to rate limit IP packets on any 1727 interface implementing IP that are transit packets. 1729 Supported Practices. 1731 * Profile Current Traffic ([I-D.practices] Section x.x.x) 1733 * Block Malicious Packets (Section 5.2) 1735 * Limit Sources of Management (Section 5.3) 1737 Current Implementations. 1739 Many devices currently implement rate limits that allow rate 1740 limiting based on protocol and/or source/destination address and 1741 or source/destination port or raw bandwidth and allow these limits 1742 to be applied to interfaces. 1744 Considerations. 1746 None. 1748 3.2.2. Ability to Rate Limit Traffic Through the Device 1750 Capability. 1752 It is possible to apply the rate-limiting mechanism to traffic 1753 that is transiting the device via any of its interfaces. 1755 Supported Practices. 1757 * This allows the operator to apply rate-limits that protect the 1758 networks transiting the device from attacks and unauthorized 1759 access. 1761 Current Implementations. 1763 Many devices currently implement rate-limits that allow limiting 1764 based on protocol and/or source/destination address and or source/ 1765 destination port and allow these limits to be applied to services 1766 offered by the networks which transit the device. 1768 Examples of this might include rate-limits that permit SSH traffic 1769 rates up to 100 megabits per second from an authorized peer, while 1770 dropping all other traffic addressed to the network which exceeds 1771 this limit. 1773 Considerations. 1775 None. 1777 3.2.3. Ability to Rate Limit Traffic Through the Device - Minimal 1778 Performance Degradation 1780 Capability. 1782 The device provides a means to rate-limit packets without 1783 significant performance degradation. 1785 The device is able to apply rate-limits on ALL interfaces (up to 1786 the maximum number possible) simultaneously and with multiple 1787 rate-limits per interface (e.g., inbound, outbound, differing 1788 traffic classifications in either direction). 1790 The rate-limiting of traffic destined to networks transiting the 1791 device should not degrade performance significantly. 1793 Supported Practices. 1795 * This enables the implementation of rate-limits on whichever 1796 services are necessary. To the extent that rate-limiting 1797 causes degradation, it may not be possible to apply rate-limits 1798 that implement the appropriate policies. 1800 Current Implementations. 1802 Another way of stating the capability is that rate-limit 1803 performance should not be the limiting factor in device 1804 throughput. If a device is capable of forwarding 30Mb/sec without 1805 rate-limits, then it should be able to forward the same amount 1806 with rate-limits in place. 1808 Considerations. 1810 The definition of "significant" is subjective. At one end of the 1811 spectrum it might mean "the application of rate-limits may cause 1812 the box to crash". At the other end would be a throughput loss of 1813 less than one percent with tens of thousands of rate-limits 1814 applied. The level of performance degradation that is acceptable 1815 will have to be determined by the operator. 1817 Repeatable test data showing rate-limiting performance impact 1818 would be very useful in evaluating this capability. Tests should 1819 include such information as packet size, packet rate, number of 1820 interfaces tested (source/destination), types of interfaces, 1821 routing table size, routing protocols in use, frequency of routing 1822 updates, etc. 1824 3.2.4. Ability to Rate Limit Through the Device - Specify Rate Limit 1825 Actions 1827 Capability. 1829 The device provides a mechanism to allow the specification of the 1830 action to be taken when a rate-limit rule matches. Actions 1831 include "permit" (allow the traffic), "reject" (drop with 1832 appropriate notification to sender), and "drop" (drop with no 1833 notification to sender). 1835 Supported Practices. 1837 * This capability is essential to the use of rate limits to 1838 enforce policy. 1840 Current Implementations. 1842 Assume that your management devices for deployed networking 1843 devices live on several subnets, use several protocols, and are 1844 controlled by several different parts of your organization. There 1845 might exist a reason to have disparate policies for access to the 1846 devices from these parts of the organization. Further you may 1847 want to limit traffic levels for these types of traffic from these 1848 known sources as close to the sources as possible via interface 1849 rate limits implemented on the supporting network devices for 1850 those source networks. 1852 Actions such as "permit", "deny", "drop" are essential in defining 1853 the security policy for the services offered by the network 1854 devices. 1856 Considerations. 1858 While silently dropping traffic without sending notification may 1859 be the correct action in security terms, consideration should be 1860 given to operational implications. See [RFC3360] for 1861 consideration of potential problems caused by sending 1862 inappropriate TCP Resets. 1864 3.2.5. Ability to Rate Limit Through the Device - Log Rate Limit 1865 Actions 1867 Capability. 1869 It is possible to log rate limit actions. The logging capability 1870 is able to capture at least the following data: 1872 * permit/deny/drop status 1874 * source and destination IP address 1876 * source and destination ports (if applicable to the protocol) 1878 * which network element received the packet (interface, MAC 1879 address or other layer 2 information that identifies the 1880 previous hop source of the packet). 1882 Supported Practices. 1884 * Logging is essential for auditing, incident response, and 1885 operations 1887 Current Implementations. 1889 Actions such as "permit", "deny", "drop" are essential in defining 1890 the security policy for the services offered by the network 1891 devices. Auditing the frequency, sources and destinations of 1892 these attempts is essential for tracking ongoing issues today. 1894 Considerations. 1896 Logging can be burdensome to the network device, at no time should 1897 logging cause performance degradation to the device or services 1898 offered on the device. 1900 3.2.6. Ability to Rate Limit Through the Device - Specify Log 1901 Granularity 1903 Capability. 1905 It is possible to enable/disable logging on a per rule basis. 1907 Supported Practices. 1909 * The ability to tune the granularity of logging allows the 1910 operator to log the information that is desired and only the 1911 information that is desired. Without this capability, it is 1912 possible that extra data (or none at all) would be logged, 1913 making it more difficult to find relevant information. 1915 Current Implementations. 1917 If a rate limit is defined that has several rules, and one of the 1918 rules denies telnet (tcp/23) connections, then it should be 1919 possible to specify that only matches on the rule that denies 1920 telnet should generate a log message. 1922 Considerations. 1924 None. 1926 3.2.7. Ability to Rate Limit Through the Device - Ability to Rate Limit 1927 Protocols 1929 Capability. 1931 The device provides a means to rate limit traffic based on the 1932 value of the protocol field in the IP header. 1934 Supported Practices. 1936 * Being able to rate limit on protocol is necessary to allow 1937 implementation of policy, secure operations and for support of 1938 incident response. 1940 Current Implementations. 1942 Some denial of service attacks are based on the ability to flood 1943 the victim with ICMP traffic. One quick way (admittedly with some 1944 negative side effects) to mitigate the effects of such attacks is 1945 to rate limit all ICMP traffic headed toward the victim. 1947 Considerations. 1949 None. 1951 3.2.8. Ability to Rate Limit Through the Device - Ability to Rate Limit 1952 Addresses 1954 Capability. 1956 The function is able to control the flow of traffic based on 1957 source and/or destination IP address or blocks of addresses such 1958 as Classless Inter-Domain Routing (CIDR) blocks. 1960 Supported Practices. 1962 * The capability to rate limit on addresses and address blocks is 1963 a fundamental tool for establishing boundaries between 1964 different networks. 1966 Current Implementations. 1968 One example of the use of address based rate limits is to 1969 implement ingress filtering per [RFC2827]. 1971 Considerations. 1973 None. 1975 3.2.9. Ability to Rate Limit Through the Device - Ability to Rate Limit 1976 Protocol Header Fields 1978 Capability. 1980 The rate limit mechanism supports rate limiting based on the 1981 value(s) of any portion of the protocol headers for IP, ICMP, UDP 1982 and TCP. It supports rate limiting of all other protocols 1983 supported at layer 3 and 4. It supports rate limiting based on 1984 the headers of higher level protocols. It is possible to specify 1985 fields by name (e.g., "protocol = ICMP") rather than bit- offset/ 1986 length/numeric value (e.g., 72:8 = 1). 1988 Supported Practices. 1990 * Being able to rate limit on portions of the header is necessary 1991 to allow implementation of policy, secure operations, and 1992 support incident response. 1994 Current Implementations. 1996 This capability implies that it is possible to rate limit based on 1997 TCP or UDP port numbers, TCP flags such as SYN, ACK and RST bits, 1998 and ICMP type and code fields. One common example is to reject 1999 "inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear 2000 or SYN bit set+ACK,FIN and RST bits clear). Another common 2001 example is the ability to control what services are allowed in/out 2002 of a network. It may be desirable to only allow inbound 2003 connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting 2004 web servers. 2006 Considerations. 2008 None. 2010 3.2.10. Ability to Rate Limit Through the Device - Ability to Rate 2011 Limit Inbound and Outbound 2013 Capability. 2015 It is possible to rate limit both incoming and outgoing traffic on 2016 any interface to or from any transiting network. 2018 Supported Practices. 2020 * This capability allows flexibility in applying rate limits at 2021 the place that makes the most sense. It allows invalid or 2022 malicious traffic to be dropped as close to the source as 2023 possible. 2025 Current Implementations. 2027 It might be desirable on a router to apply an egress rate limit to 2028 its external connections to limit outbound traffic that does not 2029 have a high priority. Inbound, it might be desirable to apply a 2030 rate limit to all traffic of a certain classification in order to 2031 preserve limited resources on the sported networks behind the 2032 device. 2034 Considerations. 2036 None. 2038 3.2.11. Ability to Rate Limit Through the Device - Ability to 2039 Accurately Count Rate Limit Hits 2041 Capability. 2043 The device supplies a facility for accurately counting all rate 2044 limit matches. 2046 Supported Practices. 2048 * Accurate counting of rate limit rule matches is important 2049 because it shows the frequency of attempts to violate policy. 2050 This enables resources to be focused on areas of greatest need. 2052 Current Implementations. 2054 Assume, for example, that a ISP network implements anti-spoofing 2055 egress rate limits (see [RFC2827]) on interfaces of its edge 2056 routers that support single-homed stub networks. Counters could 2057 enable the ISP to detect cases where large numbers of spoofed 2058 packets are being sent. This may indicate that the customer is 2059 performing potentially malicious actions (possibly in violation of 2060 the ISPs Acceptable Use Policy), or that system(s) on the 2061 customers network have been compromised by hackers and are being 2062 (mis)used to launch attacks. 2064 Considerations. 2066 None. 2068 3.2.12. Ability to Rate Limit Through the Device - Ability to Display 2069 Rate Limit Counters 2071 Capability. 2073 The device provides a mechanism to display rate limit counters. 2075 Supported Practices. 2077 * Information that is collected is not useful unless it can be 2078 displayed in a useful manner. 2080 Current Implementations. 2082 Assume there is a router with four interfaces. One is an up-link 2083 to an ISP providing routes to the Internet. The other three 2084 connect to separate internal networks. Assume that a host on one 2085 of the internal networks has been compromised by a hacker and is 2086 sending traffic with bogus source addresses. In such a situation, 2087 it might be desirable to apply ingress rate limits to each of the 2088 internal interfaces. Once the rate limits are in place, the 2089 counters can be examined to determine the source (inbound 2090 interface) of the bogus packets. 2092 Considerations. 2094 None. 2096 3.2.13. Ability to Rate Limit Through the Device - Ability to Display 2097 Rate Limit Counters per Rate Limit Application 2099 Capability. 2101 If it is possible for a rate limit to be applied more than once at 2102 the same time, then the device provides a mechanism to display 2103 rate limit counters per rate limit application. 2105 Supported Practices. 2107 * It may make sense to apply the same rate limit definition 2108 simultaneously more than one time (to different interfaces, 2109 etc.). If so, it would be much more useful to know which 2110 instance of a rate limit is matching than to know that some 2111 instance was matching somewhere. 2113 Current Implementations. 2115 One way to implement this capability would be to have the counter 2116 display mechanism show the interface (or other entity) to which 2117 the rate limit has been applied, along with the name (or other 2118 designator) for the rate limit. For example if a rate limit named 2119 "desktop_outbound" applied two different interfaces, say, 2120 "ethernet0" and "ethernet1", the display should indicate something 2121 like "matches of rate limit 'desktop_outbound' on ethernet0 ..." 2122 and "matches of rate limit 'desktop_outbound' on ethernet1 ..." 2124 Considerations. 2126 None. 2128 3.2.14. Ability to Rate Limit Through the Device - Ability to Reset 2129 Rate Limit Counters 2131 Capability. 2133 It is possible to reset counters to zero on a per rate limit 2134 basis. 2136 For the purposes of this capability it would be acceptable for the 2137 system to maintain two counters: an "absolute counter", C[now], 2138 and a "reset" counter, C[reset]. The absolute counter would 2139 maintain counts that increase monotonically until they wrap or 2140 overflow the counter. The reset counter would receive a copy of 2141 the current value of the absolute counter when the reset function 2142 was issued for that counter. Functions that display or retrieve 2143 the counter could then display the delta (C[now] - C[reset]). 2145 Supported Practices. 2147 * This allows operators to get a current picture of the traffic 2148 matching particular rules/rate limit. 2150 Current Implementations. 2152 Assume that rate limit counters are being used to detect internal 2153 hosts that are infected with a new worm. Once it is believed that 2154 all infected hosts have been cleaned up and the worm removed, the 2155 next step would be to verify that. One way of doing so would be 2156 to reset the rate limit counters to zero and see if traffic 2157 indicative of the worm has ceased. 2159 Considerations. 2161 None. 2163 3.2.15. Ability to Rate Limit Through the Device - Rate Limit Counters 2164 are Accurate 2166 Capability. 2168 Rate limit counters are accurate. They reflect the actual number 2169 of matching packets since the last counter reset. Rate limit 2170 counters are be capable of holding up to 2^32 - 1 values without 2171 overflowing and should be capable of holding up to 2^64 - 1 2172 values. 2174 Supported Practices. 2176 * Inaccurate data can not be relied on as the basis for action. 2177 Underreported data can conceal the magnitude of a problem. 2179 Current Implementations. 2181 If N packets matching a Rate limit are sent to/through a device, 2182 then the counter should show N matches. 2184 Considerations. 2186 None. 2188 4. Functional Capabilities - Filtering Layer 2 Attributes 2190 The capabilities in this section are intended to list testable, 2191 functional capabilities that are needed to operate devices securely. 2193 A layer-2 domain permits all devices in the domain to establish 2194 communication at layer-2. Devices thus connected have an implicit 2195 trust relationship among themselves. If there are devices in a 2196 layer-2 domain which are at different trust levels, we may want to 2197 filter traffic between such devices based on the trust levels or any 2198 other fields in the layer-2 header. The following filtering 2199 capabilities are required at layer-2. 2201 4.1. Filtering Layer 2 2203 4.1.1. Ability to partition layer-2 network to provide different levels 2204 of security 2206 Capability. 2208 The device provides a means to partition the physical layer-2 2209 domain into multiple virtual domains, thus allowing the filtering 2210 of unwarranted traffic. 2212 Supported Practices. 2214 * Being able to partition a layer-2 domain provides the same 2215 level of security within a layer-2 domain as can be guaranteed 2216 if they were different layer-2 domains. 2218 Current Implementations. 2220 Most Ethernet networks use the concept of VLAN [8021Q] to 2221 partition a layer-2 broadcast domain. Private VLAN's [PVLAN] 2222 allow further partitioning of VLANs's into smaller domains. 2224 Considerations. 2226 Not all layer-2 network technologies may lend themselves to 2227 virtual partitioning. 2229 4.1.2. Ability to restrict access to specified hardware (MAC) addresses 2231 Capability. 2233 The device provides a means to filter traffic based on the source 2234 and/ or destination hardware address. 2236 Supported Practices. 2238 * Being able to filter on hardware Address provides an ability to 2239 block frames between devices in the same layer-2 domain to 2240 communicate. 2242 Current Implementations. 2244 The ability to filter and monitor traffic in layer-2 allows for 2245 security at layer-2 itself, between devices on the same network. 2246 Allowing filtering based on hardware address allows a simple 2247 filtering interface to the administrator to apply simple policy 2248 rules. 2250 Considerations. 2252 Different Link layer technologies use different addressing 2253 mechanisms. 2255 4.1.3. Ability to restrict based on layer-2 packet type [etherType] 2256 field 2258 Capability. 2260 The device provides a means to filter packets based on the packet 2261 type field in the layer-2 header. 2263 Supported Practices. 2265 * Being able to filter on packets based on the packet type field 2266 helps in preventing packets not understandable by a particular 2267 device to be processed by it. 2269 Current Implementations. 2271 The ability to filter and monitor traffic in layer-2 allows for 2272 security at layer-2 itself. This capability can also prevent IPX 2273 packets to inadvertently be sent to an IP device and vice versa. 2275 Considerations. 2277 None. 2279 5. Additional Operational Practices 2281 This section describes practices not covered in [I-D.practices]. 2282 They are included here to provide justification for capabilities that 2283 reference them. 2285 5.1. Profile Current Traffic 2287 Discuss practice. Use same format as [I-D.practices]. 2289 5.2. Block Malicious Packets 2291 Discuss practice. Use same format as [I-D.practices]. 2293 5.3. Limit Sources of Management 2295 Discuss practice. Use same format as [I-D.practices]. 2297 6. Security Considerations 2299 General 2301 Security is the subject matter of this entire memo. The 2302 capabilities listed cite practices in [I-D.practices] that they 2303 are intended to support. [I-D.practices] defines the threat 2304 model, practices and lists justifications for each practice. 2306 7. References 2308 7.1. Normative References 2310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2311 Requirement Levels", BCP 14, RFC 2119, March 1997. 2313 7.2. Non-normative References 2315 [8021Q] "802.1Q - Virtual LANs", IEEE Standard 802.1Q - Virtual 2316 LANs, August 2001. 2318 [I-D.practices] 2319 Kaeo, M., "Operational Security Current Practices", 2320 Internet-Draft (to be published) 2321 draft-ietf-opsec-current-practices-00, February 2005. 2323 [PVLAN] HomChaudhuri, S. and M. Foschiano, "Private VLANs: 2324 Addressing VLAN scalability and security issues in a 2325 multi-client environment", Internet Draft (to be 2326 published) draft-sanjib-private-vlan-02, June 2004. 2328 [RFC2828] Shirey, R., "Internet Security Glossary", RFC rfc2828.txt, 2329 May 2000. 2331 [RFC3631] Bellovin, S. and J. Schiller, "Security Mechanisms for the 2332 Internet", RFC 3631, December 2003. 2334 [RFC3871] Jones, G., "Operational Security Requirements for Large 2335 Internet Service Provider (ISP) IP Network 2336 Infrastructure", RFC 3871, September 2004. 2338 Appendix A. Acknowledgments 2340 The editors gratefully acknowledges the contributions of: 2342 o xxx 2344 o yyy 2346 o The MITRE Corporation for supporting development of this document. 2347 NOTE: The editor's affiliation with The MITRE Corporation is 2348 provided for identification purposes only, and is not intended to 2349 convey or imply MITRE's concurrence with, or support for, the 2350 positions, opinions or viewpoints expressed by the editor. 2352 o Others who have provided significant feedback are: zzz 2354 o This listing is intended to acknowledge contributions, not to 2355 imply that the individual or organizations approve the content of 2356 this document. 2358 o Apologies to those who commented on/contributed to the document 2359 and were not listed. 2361 Authors' Addresses 2363 Christopher L. Morrow 2364 UUNET Technologies 2365 21830 UUNet Way 2366 Ashburn, Virginia 21047 2367 U.S.A. 2369 Phone: +1 703 886 3823 2370 Email: chris@uu.net 2372 George M. Jones 2373 The MITRE Corporation 2374 7515 Colshire Drive, M/S WEST 2375 McLean, Virginia 22102-7508 2376 U.S.A. 2378 Phone: +1 703 488 9740 2379 Email: gmjones@mitre.org 2381 Vishwas Manral 2382 IPInfusion, 2383 Bangalore, 2384 India 2386 Phone: +91-98456-61911 2387 Email: vishwas@ipinfusion.com 2389 Intellectual Property Statement 2391 The IETF takes no position regarding the validity or scope of any 2392 Intellectual Property Rights or other rights that might be claimed to 2393 pertain to the implementation or use of the technology described in 2394 this document or the extent to which any license under such rights 2395 might or might not be available; nor does it represent that it has 2396 made any independent effort to identify any such rights. Information 2397 on the procedures with respect to rights in RFC documents can be 2398 found in BCP 78 and BCP 79. 2400 Copies of IPR disclosures made to the IETF Secretariat and any 2401 assurances of licenses to be made available, or the result of an 2402 attempt made to obtain a general license or permission for the use of 2403 such proprietary rights by implementers or users of this 2404 specification can be obtained from the IETF on-line IPR repository at 2405 http://www.ietf.org/ipr. 2407 The IETF invites any interested party to bring to its attention any 2408 copyrights, patents or patent applications, or other proprietary 2409 rights that may cover technology that may be required to implement 2410 this standard. Please address the information to the IETF at 2411 ietf-ipr@ietf.org. 2413 Disclaimer of Validity 2415 This document and the information contained herein are provided on an 2416 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2417 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2418 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2419 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2420 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2421 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2423 Copyright Statement 2425 Copyright (C) The Internet Society (2005). This document is subject 2426 to the rights, licenses and restrictions contained in BCP 78, and 2427 except as set forth therein, the authors retain all their rights. 2429 Acknowledgment 2431 Funding for the RFC Editor function is currently provided by the 2432 Internet Society.