idnits 2.17.1 draft-ietf-opsec-filter-caps-07.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, updated by RFC 4748 on line 993. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1004. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1011. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1017. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4778]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 12, 2007) is 6218 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2828' is mentioned on line 916, but not defined ** Obsolete undefined reference: RFC 2828 (Obsoleted by RFC 4949) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 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 Intended status: Informational G. Jones 5 Expires: October 14, 2007 Port111 Labs 6 V. Manral 7 IP Infusion 8 April 12, 2007 10 Filtering and Rate Limiting Capabilities for IP Network Infrastructure 11 draft-ietf-opsec-filter-caps-07 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 14, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 [RFC4778] lists operator practices related to securing networks. 45 This document lists filtering and rate limiting capabilities needed 46 to support those practices. Capabilities are limited to filtering 47 and rate limiting packets as they enter or leave the device. Route 48 filters and service specific filters (e.g. SNMP, telnet) are not 49 addressed. 51 Capabilities are defined without reference to specific technologies. 52 This is done to leave room for deployment of new technologies that 53 implement the capability. Each capability cites the practices it 54 supports. Current implementations that support the capability are 55 cited. Special considerations are discussed as appropriate listing 56 operational and resource constraints, limitations of current 57 implementations, trade-offs, etc. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2. Traffic Types, Rules and Filters . . . . . . . . . . . . . . . 6 66 3. Packet Selection Criteria . . . . . . . . . . . . . . . . . . 8 67 3.1. Select Traffic on ANY Interface . . . . . . . . . . . . . 8 68 3.2. Select Traffic on ALL Interfaces . . . . . . . . . . . . . 8 69 3.3. Select Traffic To the Device . . . . . . . . . . . . . . . 9 70 3.4. Select Transit Traffic . . . . . . . . . . . . . . . . . . 10 71 3.5. Select Inbound and/or Outbound . . . . . . . . . . . . . . 11 72 3.6. Select by Address, Protocol or Protocol Header Fields . . 12 73 4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 4.1. Specify Filter Actions . . . . . . . . . . . . . . . . . . 14 75 4.2. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 15 76 4.3. Specify Log Actions . . . . . . . . . . . . . . . . . . . 15 77 4.4. Specify Log Granularity . . . . . . . . . . . . . . . . . 16 78 4.5. Ability to Display Filter Counters . . . . . . . . . . . . 17 79 5. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 5.1. Filter Counters Displayed Per Application . . . . . . . . 18 81 5.2. Ability to Reset Filter Counters . . . . . . . . . . . . . 18 82 5.3. Filter Hits are Counted . . . . . . . . . . . . . . . . . 19 83 5.4. Filter Counters are Accurate . . . . . . . . . . . . . . . 20 84 6. Minimal Performance Degradation . . . . . . . . . . . . . . . 21 85 7. Additional Operational Practices . . . . . . . . . . . . . . . 23 86 7.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 23 87 7.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 23 88 7.3. Limit Sources of Management . . . . . . . . . . . . . . . 23 89 7.4. Respond to Incidents Based on Accurate Data . . . . . . . 23 90 7.5. Implement Filters Where Necessary . . . . . . . . . . . . 24 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 94 10.1. NormativeReferences . . . . . . . . . . . . . . . . . . . 27 95 10.2. Informational References . . . . . . . . . . . . . . . . . 27 96 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 28 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 98 Intellectual Property and Copyright Statements . . . . . . . . . . 30 100 1. Introduction 102 This document is defined in the context of [RFC4778]. [RFC4778] 103 defines the goals, motivation, scope, definitions, intended audience, 104 threat model, potential attacks and gives justifications for each of 105 the practices. Many of the capabilities listed here refine or add to 106 capabilities listed in [RFC3871]. 108 Also see [I-D.lewis-infrastructure-security] for a useful description 109 of techniques for protecting infrastructure devices, including the 110 use of filtering. 112 1.1. Threat Model 114 Threats in today's networked environment range from simple packet 115 floods with overwhelming bandwidth toward a leaf network to subtle 116 attacks aimed at subverting known vulnerabilities in existing 117 applications. The target of the attack may be the networking device 118 or links inside the provider core. 120 Networks must have the ability to mitigate attacks in order to limit 121 these threats. These mitigation steps could include routing updates, 122 traffic filters, and routing filters. It is possible that the 123 mitigation steps might have to affect transit traffic as well as 124 traffic destined to the device on which the mitigation steps are 125 activated. 127 The scope of the threat includes simply denying services to an 128 individual customer on one side of the scale to exploiting a newly 129 discovered protocol vulnerability which affects the entire provider 130 core. The obvious risk to the business requires mitigation 131 capabilities which can span this range of threats. 133 Also see [I-D.savola-rtgwg-backbone-attacks] for a list of attacks on 134 backbone devices and counter measures. 136 1.2. Definitions 138 Terms are used as defined in [RFC2828]. The following definitions 139 are intended to add clarification specific the context and threat 140 model of this document. 142 Threat: An indication of impending danger or harm to the network or 143 its parts. This could be formed from the projected loss of revenue 144 to the business. Additionally, it could be formed from the increased 145 cost to the business caused by the event. The increased costs could 146 come from the need for more interfaces, more bandwidth, more 147 personnel to support the increased size or complexity, etc. 149 Risk: The possibility of suffering harm or loss of network services 150 due to a threat. 152 Attack: Typically this is a form of flood of packets to or through a 153 network. This could also be a much smaller stream of packets created 154 with the intent of exploiting a vulnerability in the infrastructure 155 of the network. 157 Asset: Either a customer, network device or network link. Any of 158 these could be assets from a business perspective. 160 1.3. Format 162 Each capability has the following subsections: 164 o Capability (what) 166 o Supported Practices (why) 168 o Current Implementations (how) 170 o Considerations (caveats, resource issues, protocol issues, etc.) 172 The Capability section describes a feature to be supported by the 173 device. The Supported Practice section cites practices described in 174 [RFC4778] that are supported by this capability. The Current 175 Implementation section is intended to give examples of 176 implementations of the capability, citing technology and standards 177 current at the time of writing. It is expected that the choice of 178 features to implement the capabilities will change over time. The 179 Considerations section lists operational and resource constraints, 180 limitations of current implementations, trade-offs, etc. 182 2. Traffic Types, Rules and Filters 184 This document describes capabilities that enable routers to filter 185 transit, control and management traffic. 187 Transit traffic is traffic that passes through a router, but does not 188 otherwise impact the behavior of that router. Routers filter transit 189 traffic by applying "filters" to interfaces. For any given 190 interface, a filter can be applied to inbound traffic, outbound 191 traffic or both. 193 Control and management traffic either originates on the router or is 194 destined for the router. Routers filter control and management 195 traffic by applying one or more filters to all of their interfaces, 196 as an aggregate. Aggregation permits the router to select any 197 control packet, regardless of the interface upon which it arrives. 198 So, the router can enforce a filter like the one that follows: "The 199 router will accept only 1mbps of telnet traffic, regardless of the 200 interface(s) upon which that traffic arrives." 202 A "Filter" is a list of one or more rules that may be applied as a 203 group. 205 A rule consists of the following: 207 o selection criteria 209 o actions 211 Selection criteria identify the packets that will be impacted by this 212 rule. Section 3 of this document describes selection criteria in 213 detail. 215 Actions define treatment that will be afforded to packets meeting the 216 selection criteria. An action can include the following: 218 o forwarding treatment 220 o logging treatment 222 o accounting treatment 224 Forwarding behaviors include the following: 226 o accept 228 o accept but rate limit 229 o reject (discard and emit ICMP message) 231 o silently discard 233 Section 4 describes actions in detail. Section 5 describes counter 234 actions in detail. 236 3. Packet Selection Criteria 238 This section lists packet selection criteria that can be applied to 239 both filtering and rate limiting. 241 3.1. Select Traffic on ANY Interface 243 Capability. 245 The device provides a means to select IP packets on any individual 246 interface implementing IP. 248 Supported Practices. 250 * Security Practices for Device Management ([RFC4778], Section 251 2.2.2) 253 * Security Practices for Data Path ([RFC4778], Section 2.3.2) 255 * Security Practices for Software Upgrades and Configuration 256 Integrity/Validation ([RFC4778], Section 2.5.2) 258 * Data Plane Filtering ([RFC4778], Section 2.7.1) 260 * Management Plane Filtering ([RFC4778], Section 2.7.2) 262 * Profile Current Traffic (Section 7.1) 264 * Block Malicious Packets (Section 7.2) 266 Current Implementations. 268 Many devices currently implement access control lists or filters 269 that allow filtering based on protocol and/or source/destination 270 address and or source/destination port and allow these filters to 271 be applied to interfaces. 273 Considerations. 275 This allows implementation of policies such as "Allow no more than 276 1Mb/s of ingress ICMP traffic on interface FOO". 278 3.2. Select Traffic on ALL Interfaces 279 Capability. 281 The device provides a means to select IP packets on any interface 282 implementing IP. The mechanism should support a shorthand 283 notation representing all interfaces on the router. 285 Supported Practices. 287 * Security Practices for Device Management ([RFC4778], Section 288 2.2.2) 290 * Security Practices for Data Path ([RFC4778], Section 2.3.2) 292 * Security Practices for Software Upgrades and Configuration 293 Integrity/Validation ([RFC4778], Section 2.5.2) 295 * Data Plane Filtering ([RFC4778], Section 2.7.1) 297 * Management Plane Filtering ([RFC4778], Section 2.7.2) 299 * Profile Current Traffic (Section 7.1) 301 * Block Malicious Packets (Section 7.2) 303 Current Implementations. 305 Many devices currently implement access control lists or filters 306 that allow filtering based on protocol and/or source/destination 307 address and or source/destination port and allow these filters to 308 be applied to all interfaces. 310 Considerations. 312 This allows implementation of policies such as "Allow no more than 313 1Mb/s of ingress ICMP traffic combined on all interfaces on the 314 device". 316 3.3. Select Traffic To the Device 318 Capability. 320 It is possible to select traffic that is addressed directly to the 321 device via any of its interfaces - including loopback interfaces. 322 The mechanism should support a shorthand notation representing all 323 interfaces on that router. 325 Supported Practices. 327 * Security Practices for Device Management ([RFC4778], Section 328 2.2.2) 330 * Security Practices for Software Upgrades and Configuration 331 Integrity/Validation ([RFC4778], Section 2.5.2) 333 * Management Plane Filtering ([RFC4778], Section 2.7.2) 335 Current Implementations. 337 Many devices currently implement access control lists or filters 338 that allow filtering based on protocol and/or source/destination 339 address and or source/destination port and allow these filters to 340 be applied to services offered by the device. 342 Examples of this might include filters that permit only BGP from 343 peers and SNMP and SSH from an authorized management segment and 344 directed to the device itself, while dropping all other traffic 345 addressed to the device. 347 Considerations. 349 None. 351 3.4. Select Transit Traffic 353 Capability. 355 It is possible to select traffic that will transit the device via 356 any of its interfaces. The mechanism should support a shorthand 357 notation representing traffic not addressed to any of the routers 358 interfaces. 360 Supported Practices. 362 * Security Practices for Data Path ([RFC4778], Section 2.3.2) 364 * Data Plane Filtering ([RFC4778], Section 2.7.1) 366 Current Implementations. 368 Many devices currently implement access control lists or filters 369 that allow filtering based on protocol and/or source/destination 370 address and or source/destination port and allow these filters to 371 be applied to the interfaces on the device in order to protect 372 assets attached to the network. 374 Examples of this may include filtering all traffic save SMTP 375 (tcp/25) destined to a mail server. A common use of this today 376 would also be denying all traffic to a destination which has been 377 determined to be hostile. 379 Considerations. 381 This allows the operator to apply filters that protect the 382 networks and assets surrounding the device from attacks and 383 unauthorized access. 385 3.5. Select Inbound and/or Outbound 387 Capability. 389 It is possible to select both incoming and outgoing traffic on any 390 interface. 392 Supported Practices. 394 * Security Practices for Device Management ([RFC4778], Section 395 2.2.2) 397 * Security Practices for Data Path ([RFC4778], Section 2.3.2) 399 * Security Practices for Software Upgrades and Configuration 400 Integrity/Validation ([RFC4778], Section 2.5.2) 402 * Data Plane Filtering ([RFC4778], Section 2.7.1) 404 * Management Plane Filtering ([RFC4778], Section 2.7.2) 406 Current Implementations. 408 It might be desirable on a border router, for example, to apply an 409 egress filter on the interface that connects a site to its 410 external ISP to drop outbound traffic that does not have a valid 411 internal source address. Inbound, it might be desirable to apply 412 a filter that blocks all traffic from a site that is known to 413 forward or originate large amounts of junk mail. 415 Considerations. 417 This allows flexibility in applying filters at the place that 418 makes the most sense. It allows invalid or malicious traffic to 419 be dropped as close to the source as possible with the least 420 impact on other traffic transiting the interface(s) in question. 422 3.6. Select by Address, Protocol or Protocol Header Fields 424 Capability. 426 The device supports selection based on: 428 * source IP address 430 * destination IP address 432 * source port 434 * destination port 436 * protocol ID 438 * TCP flags (SYN, ACK, RST) 440 * DiffServ Code Point (DSCP) 442 * the value(s) of any portion of the protocol headers for IP, 443 ICMP, UDP and TCP by specifying fields by name (e.g., "protocol 444 = ICMP") rather than bit- offset/length/numeric value (e.g., 445 72:8 = 1). 447 * Arbitrary header-based selection (possibly using bit-offset/ 448 length/value) of all other protocols. 450 Supported Practices. 452 * Security Practices for Device Management ([RFC4778], Section 453 2.2.2) 455 * Security Practices for Data Path ([RFC4778], Section 2.3.2) 457 * Security Practices for Software Upgrades and Configuration 458 Integrity/Validation ([RFC4778], Section 2.5.2) 460 * Data Plane Filtering ([RFC4778], Section 2.7.1) 462 * Management Plane Filtering ([RFC4778], Section 2.7.2) 464 Current Implementations. 466 This capability implies that it is possible to filter based on TCP 467 or UDP port numbers, TCP flags such as SYN, ACK and RST bits, and 468 ICMP type and code fields. One common example is to reject 469 "inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear 470 or SYN bit set+ACK,FIN and RST bits clear). Another common 471 example is the ability to control what services are allowed in/out 472 of a network. It may be desirable to only allow inbound 473 connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting 474 web servers. 476 Some denial of service attacks are based on the ability to flood 477 the victim with ICMP traffic. One quick way (admittedly with some 478 negative side effects, e.g. breaking path MTU discovery) to 479 mitigate the effects of such attacks is to drop all ICMP traffic 480 headed toward the victim. 482 Supporting arbitrary offset/length/value selection allows 483 filtering of unknown (possibly new) protocols, e.g. filtering RTP 484 even when the device itself does not support RTP. 486 Considerations. 488 The capability to filter on addresses, address blocks and 489 protocols is a fundamental tool for establishing boundaries 490 between different networks. 492 Being able to filter on portions of the header is necessary to 493 allow implementation of policy, secure operations, and support 494 incident response. 496 4. Actions 498 4.1. Specify Filter Actions 500 Capability. 502 The device provides a mechanism through which operators can 503 specify a forwarding action to be taken when the selection 504 criteria is met. Forwarding actions include the following: 506 * permit (allow the datagram) 508 * discard (silently discard the datagram) 510 * reject (discard the datagram and send a notification to its 511 originator) 513 Supported Practices. 515 * Data Origin Authentication ([RFC4778], Section 2.3.3) 517 Current Implementations. 519 Assume that your management devices for deployed networking 520 devices live on several subnets, use several protocols, and are 521 controlled by several different parts of your organization. There 522 might exist a reason to have disparate policies for access to the 523 devices from these parts of the organization. 525 Actions such as "permit", "reject", and "drop" are essential in 526 defining the security policy for the services offered by the 527 network devices. 529 Considerations. 531 While silently dropping traffic without sending notification may 532 be the correct action in security terms, consideration should be 533 given to operational implications. See [RFC3360] for 534 consideration of potential problems caused by sending 535 inappropriate TCP Resets. 537 Also note that it might be possible for an attacker to effect a 538 denial of service attack by causing too many rejection 539 notifications to be sent (e.g. syslog messages). For this reason 540 it might be desirable to rate-limit notifications. 542 4.2. Specify Rate Limits 544 Capability. 546 The device provides a mechanism to allow the specification of the 547 action to be taken when a rate limiting filter matches. The 548 actions include "transmit" (permit the traffic because it's below 549 the specified limit), "limit" (limit traffic because it exceeds 550 the specified limit). Limits should be applicable by both bits 551 per second and packets per time-frame (possible time-frames might 552 include second, minute, hour). Limits should able to be placed in 553 both inbound and outbound directions. 555 Supported Practices. 557 * Denial of Service Tracking/Tracing with Rate Limiting 558 ([RFC4778], Section 2.8.4) 560 Current Implementations. 562 Assume that your management devices for deployed networking 563 devices live on several subnets, use several protocols, and are 564 controlled by several different parts of your organization. There 565 might exist a reason to have disparate policies for access to the 566 devices from these parts of the organization with respect to 567 priority access to these services. Rate Limits may be used to 568 enforce these prioritizations. 570 Considerations. 572 This capability allows a filter to be used to rate limit a portion 573 of traffic through or to a device. It maybe desirable to limit 574 SNMP (UDP/161) traffic to a device, but not deny it completely. 575 Similarly, one might want to implement ICMP filters toward an 576 external network instead of discarding all ICMP traffic. 578 While silently dropping traffic without sending notification may 579 be the correct action in security terms, consideration should be 580 given to operational implications. See [RFC3360] for 581 consideration of potential problems caused by sending 582 inappropriate TCP Resets. 584 4.3. Specify Log Actions 585 Capability. 587 It is possible to log all filter actions. The logging capability 588 is able to capture at least the following data: 590 * permit/reject/drop status 592 * source and destination IP address 594 * source and destination ports (if applicable to the protocol) 596 * which network element received or was sending the packet 597 (interface, MAC address or other layer 2 information that 598 identifies the previous hop source of the packet). 600 Supported Practices. 602 * Logging Security Practices([RFC4778], Section 2.6.2) 604 Current Implementations. 606 Actions such as "permit", "reject", "drop" are essential in 607 defining the security policy for the services offered by the 608 network devices. Auditing the frequency, sources and destinations 609 of these attempts is essential for tracking ongoing issues today. 611 Considerations. 613 Logging can be burdensome to the network device, at no time should 614 logging cause performance degradation to the device or services 615 offered on the device. 617 Also note logging itself can be rate limited so as to not cause 618 performance degradation of the device or the network(in case of 619 syslog or other similar network logging mechanism. 621 4.4. Specify Log Granularity 623 Capability. 625 The device provides a mechanism through which operators can 626 enable/disable logging on a per rule basis. 628 Supported Practices. 630 * Logging Security Practices([RFC4778], Section 2.6.2) 632 Current Implementations. 634 If a filter is defined that has several rules, and one of the 635 rules specifies an action that denies telnet (tcp/23) connections, 636 then it should be possible to specify that only matches on the 637 rule that denies telnet should generate a log message. 639 Considerations. 641 The ability to tune the granularity of logging allows the operator 642 to log the information that is desired and only the information 643 that is desired. Without this capability, it is possible that 644 extra data (or none at all) would be logged, making it more 645 difficult to find relevant information. 647 4.5. Ability to Display Filter Counters 649 Capability. 651 The device provides a mechanism to display filter counters. 653 Supported Practices. 655 * Profile Current Traffic (Section 7.1) 657 * Respond to Incidents Based on Accurate Data (Section 7.4) 659 Current Implementations. 661 Assume there is a router with four interfaces. One is an up-link 662 to an ISP providing routes to the Internet. The other three 663 connect to separate internal networks. Assume that a host on one 664 of the internal networks has been compromised by a hacker and is 665 sending traffic with bogus source addresses. In such a situation, 666 it might be desirable to apply ingress filters to each of the 667 internal interfaces. Once the filters are in place, the counters 668 can be examined to determine the source (inbound interface) of the 669 bogus packets. 671 Considerations. 673 None. 675 5. Counters 677 5.1. Filter Counters Displayed Per Application 679 Capability. 681 If it is possible for a filter to be applied more than once at the 682 same time, then the device provides a mechanism to display filter 683 counters per filter application. 685 Supported Practices. 687 * Profile Current Traffic (Section 7.1) 689 * Respond to Incidents Based on Accurate Data (Section 7.4) 691 Current Implementations. 693 One way to implement this capability would be to have the counter 694 display mechanism show the interface (or other entity) to which 695 the filter has been applied, along with the name (or other 696 designator) for the filter. For example if a filter named 697 "desktop_outbound" applied two different interfaces, say, 698 "ethernet0" and "ethernet1", the display should indicate something 699 like "matches of filter 'desktop_outbound' on ethernet0 ..." and 700 "matches of filter 'desktop_outbound' on ethernet1 ..." 702 Considerations. 704 It may make sense to apply the same filter definition 705 simultaneously more than one time (to different interfaces, etc.). 706 If so, it would be much more useful to know which instance of a 707 filter is matching than to know that some instance was matching 708 somewhere. 710 5.2. Ability to Reset Filter Counters 712 Capability. 714 It is possible to reset individual counters to zero. 716 Supported Practices. 718 * Profile Current Traffic (Section 7.1) 720 * Respond to Incidents Based on Accurate Data (Section 7.4) 722 Current Implementations. 724 For the purposes of this capability it would be acceptable for the 725 system to maintain two counters: an "absolute counter", C[now], 726 and a "reset" counter, C[reset]. The absolute counter would 727 maintain counts that increase monotonically until they wrap or 728 overflow the counter. The reset counter would receive a copy of 729 the current value of the absolute counter when the reset function 730 was issued for that counter. Functions that display or retrieve 731 the counter could then display the delta (C[now] - C[reset]). 733 Considerations. 735 Assume that filter counters are being used to detect internal 736 hosts that are infected with a new worm. Once it is believed that 737 all infected hosts have been cleaned up and the worm removed, the 738 next step would be to verify that. One way of doing so would be 739 to reset the filter counters to zero and see if traffic indicative 740 of the worm has ceased. 742 5.3. Filter Hits are Counted 744 Capability. 746 The device supplies a facility for counting all filter matches. 748 Supported Practices. 750 * Profile Current Traffic (Section 7.1) 752 * Respond to Incidents Based on Accurate Data (Section 7.4) 754 Current Implementations. 756 Assume, for example, that a ISP network implements anti-spoofing 757 egress filters (see [RFC2827]) on interfaces of its edge routers 758 that support single-homed stub networks. Counters could enable 759 the ISP to detect cases where large numbers of spoofed packets are 760 being sent. This may indicate that the customer is performing 761 potentially malicious actions (possibly in violation of the ISPs 762 Acceptable Use Policy), or that system(s) on the customers network 763 have been "owned" by hackers and are being (mis)used to launch 764 attacks. 766 Considerations. 768 None. 770 5.4. Filter Counters are Accurate 772 Capability. 774 Filter counters are accurate. They reflect the actual number of 775 matching packets since the last counter reset. Filter counters 776 are be capable of holding up to 2^32 - 1 values without 777 overflowing and should be capable of holding up to 2^64 - 1 778 values. 780 Supported Practices. 782 * Respond to Incidents Based on Accurate Data (Section 7.4) 784 Current Implementations. 786 If N packets matching a filter are sent to/through a device, then 787 the counter should show N matches. 789 Considerations. 791 None. 793 6. Minimal Performance Degradation 795 Capability. 797 The device provides a means to filter packets without significant 798 performance degradation. This specifically applies to stateless 799 packet filtering operating on layer 3 (IP) and layer 4 (TCP or 800 UDP) headers, as well as normal packet forwarding information such 801 as incoming and outgoing interfaces. 803 The device is able to apply stateless packet filters on ALL 804 interfaces (up to the total number of interfaces attached to the 805 device) simultaneously and with multiple filters per interface 806 (e.g., inbound and outbound). 808 Supported Practices. 810 * Implement Filters Where Necessary (Section 7.5) 812 Current Implementations. 814 Another way of stating the capability is that filter performance 815 should not be the limiting factor in device throughput. If a 816 device is capable of forwarding 30Mb/sec without filtering, then 817 it should be able to forward the same amount with filtering in 818 place. 820 Considerations. 822 The definition of "significant" is subjective. At one end of the 823 spectrum it might mean "the application of filters may cause the 824 box to crash". At the other end would be a throughput loss of 825 less than one percent with tens of thousands of filters applied. 826 The level of performance degradation that is acceptable will have 827 to be determined by the operator. 829 Repeatable test data showing filter performance impact would be 830 very useful in evaluating this capability. Tests should include 831 such information as packet size, packet rate, number of interfaces 832 tested (source/destination), types of interfaces, routing table 833 size, routing protocols in use, frequency of routing updates, etc. 834 This capability does not address stateful filtering, filtering 835 above layer 4 headers or other more advanced types of filtering 836 that may be important in certain operational environments. 837 Finally, if key infrastructure devices crash or experience severe 838 performance degradation when filtering under heavy load, or even 839 have the reputation of doing so, it is likely that security 840 personnel will be forbidden, by policy, from using filtering in 841 ways that would otherwise be appropriate for fear that it might 842 cause unnecessary service disruption. 844 7. Additional Operational Practices 846 This section describes practices not covered in [RFC4778]. They are 847 included here to provide justification for capabilities that 848 reference them. 850 7.1. Profile Current Traffic 852 This capability allows a network operator to monitor traffic across 853 an active interface in the network at a minimal level. This helps to 854 determine probable cause for interface or network problems. 856 The ability to separate and distinguish traffic at a layer-3 or 857 layer-4 level allows the operator to characterize beyond simple 858 interface counters the traffic in question. This is critical because 859 often the operator has no tools available for protocol analysis aside 860 from interface filters. 862 7.2. Block Malicious Packets 864 Blocking or limiting traffic deemed to be malicious is a key 865 component of application of any security policy's implementation. 866 Clearly it is critical to be able to implement a security policy on a 867 network. 869 Malicious packets could potentially be defined by any part of the 870 layer-3 or layer-4 headers of the IP packet. The ability to classify 871 or select traffic based on these criteria and take some action based 872 on that classification is critical to operations of a network. 874 7.3. Limit Sources of Management 876 Management of a network should be limited to only trusted hosts. 877 This implies that the network elements will be able to limit access 878 to management functions to these trusted hosts. 880 Currently operators will limit access to the management functions on 881 a network device to only the hosts that are trusted to perform that 882 function. This allows separation of critical functions and 883 protection of those functions on the network devices. 885 7.4. Respond to Incidents Based on Accurate Data 887 Accurate counting of filter matches is important because it shows the 888 frequency of attempts to violate policy. Inaccurate data can not be 889 relied on as the basis for action. Under-reported data can conceal 890 the magnitude of a problem. This enables resources to be focused on 891 areas of greatest need. 893 7.5. Implement Filters Where Necessary 895 This enables the implementation of filters on whichever services are 896 necessary. To the extent that filtering causes degradation, it may 897 not be possible to apply filters that implement the appropriate 898 policies. 900 8. Security Considerations 902 General 903 Security is the subject matter of this entire memo. The 904 capabilities listed cite practices in [RFC4778] that they are 905 intended to support. [RFC4778] defines the threat model, 906 practices and lists justifications for each practice. 908 9. IANA Considerations 910 This document has no actions for IANA. 912 10. References 914 10.1. NormativeReferences 916 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, 917 May 2000. 919 10.2. Informational References 921 [I-D.lewis-infrastructure-security] 922 Lewis, D., "Service Provider Infrastructure Security", 923 draft-lewis-infrastructure-security-00 (work in progress), 924 June 2006. 926 [I-D.savola-rtgwg-backbone-attacks] 927 Savola, P., "Backbone Infrastructure Attacks and 928 Protections", draft-savola-rtgwg-backbone-attacks-03 (work 929 in progress), January 2007. 931 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 932 Defeating Denial of Service Attacks which employ IP Source 933 Address Spoofing", BCP 38, RFC 2827, May 2000. 935 [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", 936 BCP 60, RFC 3360, August 2002. 938 [RFC3871] Jones, G., "Operational Security Requirements for Large 939 Internet Service Provider (ISP) IP Network 940 Infrastructure", RFC 3871, September 2004. 942 [RFC4778] Kaeo, M., "Operational Security Current Practices in 943 Internet Service Provider Environments", RFC 4778, 944 January 2007. 946 Appendix A. Acknowledgments 948 The authors gratefully acknowledge the contributions of: 950 o Merike Kaeo for help aligning these capabilities with supported 951 practices 953 Authors' Addresses 955 Christopher L. Morrow 956 UUNET Technologies 957 21830 UUNet Way 958 Ashburn, Virginia 21047 959 U.S.A. 961 Phone: +1 703 886 3823 962 Email: chris@uu.net 964 George M. Jones 965 Port111 Labs 967 Phone: +1 703 488 9740 968 Email: gmj3871@pobox.com 970 Vishwas Manral 971 IP Infusion 972 Ground Floor, 5th Cross Road, Off 8th Main Road 973 Bangalore, 52 974 India 976 Phone: +91-80-4113-1268 977 Email: vishwas@ipinfusion.com 979 Full Copyright Statement 981 Copyright (C) The IETF Trust (2007). 983 This document is subject to the rights, licenses and restrictions 984 contained in BCP 78, and except as set forth therein, the authors 985 retain all their rights. 987 This document and the information contained herein are provided on an 988 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 989 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 990 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 991 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 992 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 993 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 995 Intellectual Property 997 The IETF takes no position regarding the validity or scope of any 998 Intellectual Property Rights or other rights that might be claimed to 999 pertain to the implementation or use of the technology described in 1000 this document or the extent to which any license under such rights 1001 might or might not be available; nor does it represent that it has 1002 made any independent effort to identify any such rights. Information 1003 on the procedures with respect to rights in RFC documents can be 1004 found in BCP 78 and BCP 79. 1006 Copies of IPR disclosures made to the IETF Secretariat and any 1007 assurances of licenses to be made available, or the result of an 1008 attempt made to obtain a general license or permission for the use of 1009 such proprietary rights by implementers or users of this 1010 specification can be obtained from the IETF on-line IPR repository at 1011 http://www.ietf.org/ipr. 1013 The IETF invites any interested party to bring to its attention any 1014 copyrights, patents or patent applications, or other proprietary 1015 rights that may cover technology that may be required to implement 1016 this standard. Please address the information to the IETF at 1017 ietf-ipr@ietf.org. 1019 Acknowledgment 1021 Funding for the RFC Editor function is provided by the IETF 1022 Administrative Support Activity (IASA).