idnits 2.17.1 draft-ietf-opsec-filter-caps-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 958. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 935. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 942. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 948. ** 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.) ** The abstract seems to contain references ([I-D.ietf-opsec-current-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 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 (March 24, 2006) is 6607 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) == Outdated reference: A later version (-07) exists of draft-ietf-opsec-current-practices-04 == Outdated reference: A later version (-03) exists of draft-savola-rtgwg-backbone-attacks-01 -- Obsolete informational reference (is this intentional?): RFC 2828 (Obsoleted by RFC 4949) Summary: 5 errors (**), 0 flaws (~~), 4 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: September 25, 2006 G. Jones 5 The MITRE Corporation 6 March 24, 2006 8 Filtering and Rate Limiting Capabilities for IP Network Infrastructure 9 draft-ietf-opsec-filter-caps-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 25, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 [I-D.ietf-opsec-current-practices] lists operator practices related 43 to securing networks. This document lists filtering and rate 44 limiting capabilities needed to support those practices. 45 Capabilities are limited to filtering and rate limiting packets as 46 they enter or leave the device. Route filters and service specific 47 filters (e.g. SNMP, telnet) are not addressed. 49 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2. Packet Selction for Managemnet and Data Plane Controls . . . . 6 63 3. Packet Selection Criteria . . . . . . . . . . . . . . . . . . 7 64 3.1. Select Traffic on All Interfaces . . . . . . . . . . . . . 7 65 3.2. Select Traffic To the Device . . . . . . . . . . . . . . . 7 66 3.3. Select Transit Traffic . . . . . . . . . . . . . . . . . . 8 67 3.4. Select Inbound and/or Outbound . . . . . . . . . . . . . . 8 68 3.5. Select by Protocols . . . . . . . . . . . . . . . . . . . 9 69 3.6. Select by Addresses . . . . . . . . . . . . . . . . . . . 9 70 3.7. Select by Protocol Header Fields . . . . . . . . . . . . . 10 71 4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 4.1. Specify Filter Actions . . . . . . . . . . . . . . . . . . 12 73 4.2. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 12 74 4.3. Specify Log Actions . . . . . . . . . . . . . . . . . . . 13 75 4.4. Specify Log Granularity . . . . . . . . . . . . . . . . . 14 76 4.5. Ability to Display Filter Counters . . . . . . . . . . . . 14 77 5. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 5.1. Ability to Display Filter Counters per Filter 79 Application . . . . . . . . . . . . . . . . . . . . . . . 16 80 5.2. Ability to Reset Filter Counters . . . . . . . . . . . . . 16 81 5.3. Filter Hits are Accurately Counted . . . . . . . . . . . . 17 82 5.4. Filter Counters are Accurate . . . . . . . . . . . . . . . 17 83 6. Minimal Performance Degradation . . . . . . . . . . . . . . . 19 84 7. Additional Operational Practices . . . . . . . . . . . . . . . 21 85 7.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 21 86 7.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 21 87 7.3. Limit Sources of Management . . . . . . . . . . . . . . . 21 88 7.4. Select Traffic To the Device . . . . . . . . . . . . . . . 21 89 7.5. Select Transit Traffic . . . . . . . . . . . . . . . . . . 22 90 7.6. Select Traffic Inbound and/or Outbound . . . . . . . . . . 22 91 7.7. Select Traffic by Protocol . . . . . . . . . . . . . . . . 22 92 7.8. Select Traffic by Addresses . . . . . . . . . . . . . . . 22 93 7.9. Select Traffic by Protocol Header Field . . . . . . . . . 22 94 7.10. Specify Filter Actions . . . . . . . . . . . . . . . . . . 22 95 7.11. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 22 96 7.12. Specify Log Actions . . . . . . . . . . . . . . . . . . . 23 97 7.13. Log Granularity . . . . . . . . . . . . . . . . . . . . . 23 98 7.14. Display Filter Counters . . . . . . . . . . . . . . . . . 23 99 7.15. Counters . . . . . . . . . . . . . . . . . . . . . . . . . 23 100 7.16. Ability to Reset Filter Counters . . . . . . . . . . . . . 23 101 7.17. Filter Hits are Accurately Counted . . . . . . . . . . . . 23 102 7.18. Filter Hits are Accurate . . . . . . . . . . . . . . . . . 23 103 7.19. Minimal Performance Degredation . . . . . . . . . . . . . 23 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 105 9. Non-normative References . . . . . . . . . . . . . . . . . . . 24 106 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 25 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 108 Intellectual Property and Copyright Statements . . . . . . . . . . 27 110 1. Introduction 112 This document is defined in the context of [I-D.ietf-opsec-current- 113 practices]. [I-D.ietf-opsec-current-practices] defines the goals, 114 motivation, scope, definitions, intended audience,threat model, 115 potential attacks and give justifications for each of the practices. 116 Many of the capabilities listed here refine or add to capabilities 117 listed in [RFC3871]. 119 Also see [I-D.lewis-infrastructure-security] for a useful description 120 of techniques for protecting infrastructure devices, including the 121 use of filtering. 123 1.1. Threat Model 125 Threats in today's networked environment range from simple packet 126 floods with overwhelming bandwidth toward a leaf network to subtle 127 attacks aimed at subverting known vulnerabilities in existing 128 applications. The attacked network or host might not be an end user, 129 it may be the networking device or links inside the provider core. 131 Networks must have the ability to place mitigation in order to limit 132 these threats. These mitigation steps could include routing updates, 133 traffic filters, and routing filters. It is possible that the 134 mitigation steps might have to affect transit traffic as well as 135 traffic destined to the device on which the mitigation steps are 136 activated. 138 The scope of the threat includes simply denying services to an 139 individual customer on one side of the scale to exploiting a newly 140 discovered protocol vulnerability which affects the entire provider 141 core. The obvious risk to the business requires mitigation 142 capabilities which can span this range of threats. 144 Threat: An indication of impending danger or harm to the network or 145 its parts. This could be formed from the projected loss of revenue 146 to the business. Additionally, it could be formed from the increased 147 cost to the business caused by the event. (more interfaces, more 148 bandwidth, more personnel to support the increased size or 149 complexity) 151 Risk: The possibility of suffering harm or loss of network services 152 due to a threat. 154 Attack: To set upon with violent force the network or its parts. 155 Typically this is a form of flood of packets to or through a network. 156 This could also be a much smaller stream of packets created with the 157 intent of exploiting a vulnerability in the infrastructure of the 158 network. 160 Asset: Either a customer, network device or network link. Any of 161 these could be assets from a business perspective. 163 These terms are more completely defined in [RFC2828] we have added 164 some scope specific information only. 166 Also see [I-D.savola-rtgwg-backbone-attacks] for a list of attacks on 167 backbone devices and counter measures. 169 1.2. Format 171 Each capability has the following subsections: 173 o Capability (what) 175 o Supported Practices (why) 177 o Current Implementations (how) 179 o Considerations (caveats, resource issues, protocol issues, etc.) 181 The Capability section describes a feature to be supported by the 182 device. The Supported Practice section cites practices described in 183 [I-D.ietf-opsec-current-practices] that are supported by this 184 capability. The Current Implementation section is intended to give 185 examples of implementations of the capability, citing technology and 186 standards current at the time of writing. It is expected that the 187 choice of features to implement the capabilities will change over 188 time. The Considerations section lists operational and resource 189 constraints, limitations of current implementations, tradeoffs, etc. 191 2. Packet Selction for Managemnet and Data Plane Controls 193 In this document section Section 3 describes a number of criteria for 194 performing packet selection. It is assumed in this document that 196 o all of these criteria can be used to select packets for both 197 filtering and rate limiting packets, 199 o management plane controls can be implemented by applying these 200 criteria to filter/rate limit traffic destined for the device 201 itself, 203 o data plane controls can be implemented by applying these criteria 204 to filter/rate limit traffic destined through the device 206 3. Packet Selection Criteria 208 This section lists packet selection criteria that can be applied to 209 both filtering and rate limiting. 211 3.1. Select Traffic on All Interfaces 213 Capability. 215 The device provides a means to filter IP packets on any interface 216 implementing IP. 218 Supported Practices. 220 * Profile Current Traffic (Section 7.1) 222 * Block Malicious Packets (Section 7.2) 224 * Limit Sources of Management ([I-D.ietf-opsec-current- 225 practices], Section 2.8.2) 227 Current Implementations. 229 Many devices currently implement access control lists or filters 230 that allow filtering based on protocol and/or source/destination 231 address and or source/destination port and allow these filters to 232 be applied to interfaces. 234 Considerations. 236 None. 238 3.2. Select Traffic To the Device 240 Capability. 242 It is possible to apply the filtering mechanism to traffic that is 243 addressed directly to the device via any of its interfaces - 244 including loopback interfaces. 246 Supported Practices. 248 * Select Traffic To the Device (Section 7.4) 250 Current Implementations. 252 Many devices currently implement access control lists or filters 253 that allow filtering based on protocol and/or source/destination 254 address and or source/destination port and allow these filters to 255 be applied to services offered by the device. 257 Examples of this might include filters that permit only BGP from 258 peers and SNMP and SSH from an authorized management segment and 259 directed to the device itself, while dropping all other traffic 260 addressed to the device. 262 Considerations. 264 None. 266 3.3. Select Transit Traffic 268 Capability. 270 It is possible to apply the filtering mechanism to traffic that 271 will transit the device via any of its interfaces. 273 Supported Practices. 275 * Select Transit Traffic (Section 7.5) 277 Current Implementations. 279 Many devices currently implement access control lists or filters 280 that allow filtering based on protocol and/or source/destination 281 address and or source/destination port and allow these filters to 282 be applied to the interfaces on the device in order to protect 283 assets attached to the network. 285 Examples of this may include filtering all traffic save SMTP 286 (tcp/25) destined to a mail server. A common use of this today 287 would also be denying all traffic to a destination which has been 288 determined to be hostile. 290 Considerations. 292 None. 294 3.4. Select Inbound and/or Outbound 295 Capability. 297 It is possible to filter both incoming and outgoing traffic on any 298 interface. 300 Supported Practices. 302 * Select Inbound and/or Outbound Traffic (Section 7.6) 304 Current Implementations. 306 It might be desirable on a border router, for example, to apply an 307 egress filter outbound on the interface that connects a site to 308 its external ISP to drop outbound traffic that does not have a 309 valid internal source address. Inbound, it might be desirable to 310 apply a filter that blocks all traffic from a site that is known 311 to forward or originate large amounts of junk mail. 313 Considerations. 315 None. 317 3.5. Select by Protocols 319 Capability. 321 The device provides a means to filter traffic based on the value 322 of the protocol field in the IP header. 324 Supported Practices. 326 * Select by Protocols(Section 7.7) 328 Current Implementations. 330 Some denial of service attacks are based on the ability to flood 331 the victim with ICMP traffic. One quick way (admittedly with some 332 negative side effects) to mitigate the effects of such attacks is 333 to drop all ICMP traffic headed toward the victim. 335 Considerations. 337 None. 339 3.6. Select by Addresses 340 Capability. 342 The device is able to control the flow of traffic based on source 343 and/or destination IP address or blocks of addresses such as 344 Classless Inter-Domain Routing (CIDR) blocks. 346 Supported Practices. 348 * Select by Addresses(Section 7.8) 350 Current Implementations. 352 One example of the use of address based filtering is to implement 353 ingress filtering per [RFC2827] 355 Considerations. 357 None. 359 3.7. Select by Protocol Header Fields 361 Capability. 363 The filtering mechanism supports filtering based on the value(s) 364 of any portion of the protocol headers for IP, ICMP, UDP and TCP. 365 It supports filtering of all other protocols supported at layer 3 366 and 4. It supports filtering based on the headers of higher level 367 protocols. It is possible to specify fields by name (e.g., 368 "protocol = ICMP") rather than bit- offset/length/numeric value 369 (e.g., 72:8 = 1). 371 Supported Practices. 373 * Select by Protocol Header Field(Section 7.9) 375 Current Implementations. 377 This capability implies that it is possible to filter based on TCP 378 or UDP port numbers, TCP flags such as SYN, ACK and RST bits, and 379 ICMP type and code fields. One common example is to reject 380 "inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear 381 or SYN bit set+ACK,FIN and RST bits clear). Another common 382 example is the ability to control what services are allowed in/out 383 of a network. It may be desirable to only allow inbound 384 connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting 385 web servers. 387 Considerations. 389 None. 391 4. Actions 393 4.1. Specify Filter Actions 395 Capability. 397 The device provides a mechanism to allow the specification of the 398 action to be taken when a filter rule matches. Actions include 399 "permit" (allow the traffic), "reject" (drop with appropriate 400 notification to sender), and "drop" (drop with no notification to 401 sender). 403 Supported Practices. 405 * Specify Filter Actions(Section 7.10) 407 Current Implementations. 409 Assume that your management devices for deployed networking 410 devices live on several subnets, use several protocols, and are 411 controlled by several different parts of your organization. There 412 might exist a reason to have disparate policies for access to the 413 devices from these parts of the organization. 415 Actions such as "permit", "deny", "drop" are essential in defining 416 the security policy for the services offered by the network 417 devices. 419 Considerations. 421 While silently dropping traffic without sending notification may 422 be the correct action in security terms, consideration should be 423 given to operational implications. See [RFC3360] for 424 consideration of potential problems caused by sending 425 inappropriate TCP Resets. 427 4.2. Specify Rate Limits 429 Capability. 431 The device provides a mechanism to allow the specification of the 432 action to be taken when a rate limiting filter rule matches. The 433 actions include "transmit" (permit the traffic because it's below 434 the specified limit), "limit" (limit traffic because it exceeds 435 the specified limit). Limits should be applicable by both bits 436 per second and packets per timeframe (possible timeframes might 437 include second, minute, hour). Limits should able to be placed in 438 both inbound and outbound directions. 440 Supported Practices. 442 * Specify Rate Limits (Section 7.11) 444 Current Implementations. 446 Assume that your management devices for deployed networking 447 devices live on several subnets, use several protocols, and are 448 controlled by several different parts of your organization. There 449 might exist a reason to have disparate policies for access to the 450 devices from these parts of the organization with respect to 451 priority access to these services. Rate Limits may be used to 452 enforce these prioritizations. 454 Considerations. 456 While silently dropping traffic without sending notification may 457 be the correct action in security terms, consideration should be 458 given to operational implications. See [RFC3360] for 459 consideration of potential problems caused by sending 460 inappropriate TCP Resets. 462 4.3. Specify Log Actions 464 Capability. 466 It is possible to log all filter actions. The logging capability 467 is able to capture at least the following data: 469 * permit/deny/drop status 471 * source and destination IP address 473 * source and destination ports (if applicable to the protocol) 475 * which network element received the packet (interface, MAC 476 address or other layer 2 information that identifies the 477 previous hop source of the packet). 479 Supported Practices. 481 * Log exceptions ([I-D.ietf-opsec-current-practices], Section 482 2.7.2) 484 * Log Actions (Section 7.12) 486 Current Implementations. 488 Actions such as "permit", "deny", "drop" are essential in defining 489 the security policy for the services offered by the network 490 devices. Auditing the frequency, sources and destinations of 491 these attempts is essential for tracking ongoing issues today. 493 Considerations. 495 Logging can be burdensome to the network device, at no time should 496 logging cause performance degradation to the device or services 497 offered on the device. 499 4.4. Specify Log Granularity 501 Capability. 503 It is possible to enable/disable logging on a per rule basis. 505 Supported Practices. 507 * Log Granularity (Section 7.13) 509 Current Implementations. 511 If a filter is defined that has several rules, and one of the 512 rules denies telnet (tcp/23) connections, then it should be 513 possible to specify that only matches on the rule that denies 514 telnet should generate a log message. 516 Considerations. 518 None. 520 4.5. Ability to Display Filter Counters 522 Capability. 524 The device provides a mechanism to display filter counters. 526 Supported Practices. 528 * Display Filter Counters (Section 7.14) 530 Current Implementations. 532 Assume there is a router with four interfaces. One is an up-link 533 to an ISP providing routes to the Internet. The other three 534 connect to separate internal networks. Assume that a host on one 535 of the internal networks has been compromised by a hacker and is 536 sending traffic with bogus source addresses. In such a situation, 537 it might be desirable to apply ingress filters to each of the 538 internal interfaces. Once the filters are in place, the counters 539 can be examined to determine the source (inbound interface) of the 540 bogus packets. 542 Considerations. 544 None. 546 5. Counters 548 5.1. Ability to Display Filter Counters per Filter Application 550 Capability. 552 If it is possible for a filter to be applied more than once at the 553 same time, then the device provides a mechanism to display filter 554 counters per filter application. 556 Supported Practices. 558 * Counters (Section 7.15) 560 Current Implementations. 562 One way to implement this capability would be to have the counter 563 display mechanism show the interface (or other entity) to which 564 the filter has been applied, along with the name (or other 565 designator) for the filter. For example if a filter named 566 "desktop_outbound" applied two different interfaces, say, 567 "ethernet0" and "ethernet1", the display should indicate something 568 like "matches of filter 'desktop_outbound' on ethernet0 ..." and 569 "matches of filter 'desktop_outbound' on ethernet1 ..." 571 Considerations. 573 None. 575 5.2. Ability to Reset Filter Counters 577 Capability. 579 It is possible to reset counters to zero on a per filter basis. 581 For the purposes of this capability it would be acceptable for the 582 system to maintain two counters: an "absolute counter", C[now], 583 and a "reset" counter, C[reset]. The absolute counter would 584 maintain counts that increase monotonically until they wrap or 585 overflow the counter. The reset counter would receive a copy of 586 the current value of the absolute counter when the reset function 587 was issued for that counter. Functions that display or retrieve 588 the counter could then display the delta (C[now] - C[reset]). 590 Supported Practices. 592 * Reset Counters (Section 7.16) 594 Current Implementations. 596 Assume that filter counters are being used to detect internal 597 hosts that are infected with a new worm. Once it is believed that 598 all infected hosts have been cleaned up and the worm removed, the 599 next step would be to verify that. One way of doing so would be 600 to reset the filter counters to zero and see if traffic indicative 601 of the worm has ceased. 603 Considerations. 605 None. 607 5.3. Filter Hits are Accurately Counted 609 Capability. 611 The device supplies a facility for accurately counting all filter 612 matches. 614 Supported Practices. 616 * Filter Hits are Accurately Counted (Section 7.17) 618 Current Implementations. 620 Assume, for example, that a ISP network implements anti-spoofing 621 egress filters (see [RFC2827]) on interfaces of its edge routers 622 that support single-homed stub networks. Counters could enable 623 the ISP to detect cases where large numbers of spoofed packets are 624 being sent. This may indicate that the customer is performing 625 potentially malicious actions (possibly in violation of the ISPs 626 Acceptable Use Policy), or that system(s) on the customers network 627 have been "owned" by hackers and are being (mis)used to launch 628 attacks. 630 Considerations. 632 None. 634 5.4. Filter Counters are Accurate 636 Capability. 638 Filter counters are accurate. They reflect the actual number of 639 matching packets since the last counter reset. Filter counters 640 are be capable of holding up to 2^32 - 1 values without 641 overflowing and should be capable of holding up to 2^64 - 1 642 values. 644 Supported Practices. 646 * Filter Hits are Accurately (Section 7.18) 648 Current Implementations. 650 If N packets matching a filter are sent to/through a device, then 651 the counter should show N matches. 653 Considerations. 655 None. 657 6. Minimal Performance Degradation 659 Capability. 661 The device provides a means to filter packets without significant 662 performance degradation. This specifically applies to stateless 663 packet filtering operating on layer 3 (IP) and layer 4 (TCP or 664 UDP) headers, as well as normal packet forwarding information such 665 as incoming and outgoing interfaces. 667 The device is able to apply stateless packet filters on ALL 668 interfaces (up to the total number of interfaces attached to the 669 device) simultaneously and with multiple filters per interface 670 (e.g., inbound and outbound). 672 The filtering of traffic destined to interfaces on the device, 673 including the loopback interface, should not degrade performance 674 significantly. 676 Supported Practices. 678 * Minimal Performance Degradation (Section 7.19) 680 Current Implementations. 682 Another way of stating the capability is that filter performance 683 should not be the limiting factor in device throughput. If a 684 device is capable of forwarding 30Mb/sec without filtering, then 685 it should be able to forward the same amount with filtering in 686 place. 688 Considerations. 690 The definition of "significant" is subjective. At one end of the 691 spectrum it might mean "the application of filters may cause the 692 box to crash". At the other end would be a throughput loss of 693 less than one percent with tens of thousands of filters applied. 694 The level of performance degradation that is acceptable will have 695 to be determined by the operator. 697 Repeatable test data showing filter performance impact would be 698 very useful in evaluating this capability. Tests should include 699 such information as packet size, packet rate, number of interfaces 700 tested (source/destination), types of interfaces, routing table 701 size, routing protocols in use, frequency of routing updates, etc. 703 This capability does not address stateful filtering, filtering 704 above layer 4 headers or other more advanced types of filtering 705 that may be important in certain operational environments. 707 Finally, if key infrastructure devices crash or experience severe 708 performance degradation when filtering under heavy load, or even 709 have the reputation of doing so, it is likely that security 710 personnel will be forbidden, by policy, from using filtering in 711 ways that would otherwise be appropriate for fear that it might 712 cause unnecessary service disruption. 714 7. Additional Operational Practices 716 This section describes practices not covered in [I-D.ietf-opsec- 717 current-practices]. They are included here to provide justification 718 for capabilities that reference them. 720 7.1. Profile Current Traffic 722 This capability allows a network operator to monitor traffic across 723 an active interface in the network at a minimal level. This helps to 724 determine probable cause for interface or network problems. 726 The ability to separate and distinguish traffic at a layer-3 or 727 layer-4 level allows the operator to characterize beyond simple 728 interface counters the traffic in question. This is critical because 729 often the operator has no tools available for protocol analysis aside 730 from interface filters. 732 7.2. Block Malicious Packets 734 Blocking or limiting traffic deemed to be malicious is a key 735 component of application of any security policy's implementation. 736 Clearly it is critical to be able to implement a security policy on a 737 network. 739 Malicious packets could potentially be defined by any part of the 740 layer-3 or layer-4 headers of the IP packet. The ability to classify 741 or select traffic based on these criteria and take some action based 742 on that classification is critical to operations of a network. 744 7.3. Limit Sources of Management 746 Management of a network should be limited to only trusted hosts. 747 This implies that the network elements will be able to limit access 748 to management functions to these trusted hosts. 750 Currently operators will limit access to the management functions on 751 a network device to only the hosts that are trusted to perform that 752 function. This allows separation of critical functions and 753 protection of those functions on the network devices. 755 7.4. Select Traffic To the Device 757 This allows the operator to apply filters that protect the device 758 itself from attacks and unauthorized access. 760 7.5. Select Transit Traffic 762 This allows the operator to apply filters that protect the networks 763 and assets surrounding the device from attacks and unauthorized 764 access. 766 7.6. Select Traffic Inbound and/or Outbound 768 This allows flexibility in applying filters at the place that makes 769 the most sense. It allows invalid or malicious traffic to be dropped 770 as close to the source as possible with the least impact on other 771 traffic transiting the interface(s) in question. 773 7.7. Select Traffic by Protocol 775 Being able to filter on protocol is necessary to allow implementation 776 of policy, secure operations and for support of incident response. 777 Filtering all traffic to a destination host is not often possible, 778 business requirements will dictate that critical traffic be permitted 779 if at all possible. 781 7.8. Select Traffic by Addresses 783 The capability to filter on addresses and address blocks is a 784 fundamental tool for establishing boundaries between different 785 networks. 787 7.9. Select Traffic by Protocol Header Field 789 Being able to filter on portions of the header is necessary to allow 790 implementation of policy, secure operations, and support incident 791 response. 793 7.10. Specify Filter Actions 795 This capability is essential to the use of filters to enforce policy. 796 With a defined filter classification of some traffic and no action 797 defined there is little use for the filter, actions must be included 798 in order to provide the requisite security. 800 7.11. Specify Rate Limits 802 This capability allows a filter to be used to rate limit a portion of 803 traffic through or to a device. It maybe desirable to limit SNMP 804 (UDP/161) traffic to a device, but not deny it completely. 805 Similarly, one might want to implement ICMP filters toward an 806 external network instead of discarding all ICMP traffic. 808 7.12. Specify Log Actions 810 Logging is essential for auditing, incident response, and operations 812 7.13. Log Granularity 814 The ability to tune the granularity of logging allows the operator to 815 log the information that is desired and only the information that is 816 desired. Without this capability, it is possible that extra data (or 817 none at all) would be logged, making it more difficult to find 818 relevant information. 820 7.14. Display Filter Counters 822 Information that is collected is not useful unless it can be 823 displayed. 825 7.15. Counters 827 It may make sense to apply the same filter definition simultaneously 828 more than one time (to different interfaces, etc.). If so, it would 829 be much more useful to know which instance of a filter is matching 830 than to know that some instance was matching somewhere. 832 7.16. Ability to Reset Filter Counters 834 This allows operators to get a current picture of the traffic 835 matching particular rules/filters. 837 7.17. Filter Hits are Accurately Counted 839 Accurate counting of filter rule matches is important because it 840 shows the frequency of attempts to violate policy. This enables 841 resources to be focused on areas of greatest need. 843 7.18. Filter Hits are Accurate 845 Inaccurate data can not be relied on as the basis for action. Under- 846 reported data can conceal the magnitude of a problem. 848 7.19. Minimal Performance Degredation 850 This enables the implementation of filters on whichever services are 851 necessary. To the extent that filtering causes degradation, it may 852 not be possible to apply filters that implement the appropriate 853 policies. 855 8. Security Considerations 857 General 859 Security is the subject matter of this entire memo. The 860 capabilities listed cite practices in [I-D.ietf-opsec-current- 861 practices] that they are intended to support. [I-D.ietf-opsec- 862 current-practices] defines the threat model, practices and lists 863 justifications for each practice. 865 9. Non-normative References 867 [I-D.ietf-opsec-current-practices] 868 Kaeo, M., "Operational Security Current Practices", 869 draft-ietf-opsec-current-practices-04 (work in progress), 870 June 2006. 872 [I-D.lewis-infrastructure-security] 873 Lewis, D., "Service Provider Infrastructure Security", 874 draft-lewis-infrastructure-security-00 (work in progress), 875 June 2006. 877 [I-D.savola-rtgwg-backbone-attacks] 878 Savola, P., "Backbone Infrastructure Attacks and 879 Protections", draft-savola-rtgwg-backbone-attacks-01 (work 880 in progress), June 2006. 882 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 883 Defeating Denial of Service Attacks which employ IP Source 884 Address Spoofing", BCP 38, RFC 2827, May 2000. 886 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, 887 May 2000. 889 [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", 890 BCP 60, RFC 3360, August 2002. 892 [RFC3871] Jones, G., "Operational Security Requirements for Large 893 Internet Service Provider (ISP) IP Network 894 Infrastructure", RFC 3871, September 2004. 896 Appendix A. Acknowledgments 898 The editors gratefully acknowledges the contributions of: 900 o The MITRE Corporation for supporting development of this document. 901 NOTE: The editor's affiliation with The MITRE Corporation is 902 provided for identification purposes only, and is not intended to 903 convey or imply MITRE's concurrence with, or support for, the 904 positions, opinions or viewpoints expressed by the editor. 906 Authors' Addresses 908 Christopher L. Morrow 909 UUNET Technologies 910 21830 UUNet Way 911 Ashburn, Virginia 21047 912 U.S.A. 914 Phone: +1 703 886 3823 915 Email: chris@uu.net 917 George M. Jones 918 The MITRE Corporation 919 7515 Colshire Drive, M/S WEST 920 McLean, Virginia 22102-7508 921 U.S.A. 923 Phone: +1 703 488 9740 924 Email: gmjones@mitre.org 926 Intellectual Property Statement 928 The IETF takes no position regarding the validity or scope of any 929 Intellectual Property Rights or other rights that might be claimed to 930 pertain to the implementation or use of the technology described in 931 this document or the extent to which any license under such rights 932 might or might not be available; nor does it represent that it has 933 made any independent effort to identify any such rights. Information 934 on the procedures with respect to rights in RFC documents can be 935 found in BCP 78 and BCP 79. 937 Copies of IPR disclosures made to the IETF Secretariat and any 938 assurances of licenses to be made available, or the result of an 939 attempt made to obtain a general license or permission for the use of 940 such proprietary rights by implementers or users of this 941 specification can be obtained from the IETF on-line IPR repository at 942 http://www.ietf.org/ipr. 944 The IETF invites any interested party to bring to its attention any 945 copyrights, patents or patent applications, or other proprietary 946 rights that may cover technology that may be required to implement 947 this standard. Please address the information to the IETF at 948 ietf-ipr@ietf.org. 950 Disclaimer of Validity 952 This document and the information contained herein are provided on an 953 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 954 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 955 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 956 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 957 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 958 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 960 Copyright Statement 962 Copyright (C) The Internet Society (2006). This document is subject 963 to the rights, licenses and restrictions contained in BCP 78, and 964 except as set forth therein, the authors retain all their rights. 966 Acknowledgment 968 Funding for the RFC Editor function is currently provided by the 969 Internet Society.