idnits 2.17.1 draft-ietf-opsec-filter-caps-05.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 938. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 949. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 956. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 962. 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 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 ([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 (March 1, 2007) is 6258 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ietf-opsec-current-practices' is mentioned on line 216, but not defined -- Obsolete informational reference (is this intentional?): RFC 2828 (Obsoleted by RFC 4949) Summary: 3 errors (**), 0 flaws (~~), 2 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 Intended status: Informational G. Jones 5 Expires: September 2, 2007 6 V. Manral 7 IP Infusion 8 March 1, 2007 10 Filtering and Rate Limiting Capabilities for IP Network Infrastructure 11 draft-ietf-opsec-filter-caps-05 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 September 2, 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. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2. Packet Selection for Management and Data Plane Controls . . . 6 65 3. Packet Selection Criteria . . . . . . . . . . . . . . . . . . 7 66 3.1. Select Traffic on All Interfaces . . . . . . . . . . . . . 7 67 3.2. Select Traffic To the Device . . . . . . . . . . . . . . . 7 68 3.3. Select Transit Traffic . . . . . . . . . . . . . . . . . . 8 69 3.4. Select Inbound and/or Outbound . . . . . . . . . . . . . . 9 70 3.5. Select by Protocols . . . . . . . . . . . . . . . . . . . 10 71 3.6. Select by Addresses . . . . . . . . . . . . . . . . . . . 10 72 3.7. Select by Protocol Header Fields . . . . . . . . . . . . . 11 73 4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 4.1. Specify Filter Actions . . . . . . . . . . . . . . . . . . 13 75 4.2. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 13 76 4.3. Specify Log Actions . . . . . . . . . . . . . . . . . . . 14 77 4.4. Specify Log Granularity . . . . . . . . . . . . . . . . . 15 78 4.5. Ability to Display Filter Counters . . . . . . . . . . . . 16 79 5. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 5.1. Filter Counters Displayed Per Application . . . . . . . . 17 81 5.2. Ability to Reset Filter Counters . . . . . . . . . . . . . 17 82 5.3. Filter Hits are Counted . . . . . . . . . . . . . . . . . 18 83 5.4. Filter Counters are Accurate . . . . . . . . . . . . . . . 19 84 6. Minimal Performance Degradation . . . . . . . . . . . . . . . 20 85 7. Additional Operational Practices . . . . . . . . . . . . . . . 22 86 7.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 22 87 7.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 22 88 7.3. Limit Sources of Management . . . . . . . . . . . . . . . 22 89 7.4. Respond to Incidents Based on Accurate Data . . . . . . . 22 90 7.5. Implement Filters Where Necessary . . . . . . . . . . . . 23 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 92 9. Non-normative References . . . . . . . . . . . . . . . . . . . 25 93 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 26 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 95 Intellectual Property and Copyright Statements . . . . . . . . . . 28 97 1. Introduction 99 This document is defined in the context of [RFC4778]. [RFC4778] 100 defines the goals, motivation, scope, definitions, intended audience, 101 threat model, potential attacks and give justifications for each of 102 the practices. Many of the capabilities listed here refine or add to 103 capabilities listed in [RFC3871]. 105 Also see [I-D.lewis-infrastructure-security] for a useful description 106 of techniques for protecting infrastructure devices, including the 107 use of filtering. 109 1.1. Threat Model 111 Threats in today's networked environment range from simple packet 112 floods with overwhelming bandwidth toward a leaf network to subtle 113 attacks aimed at subverting known vulnerabilities in existing 114 applications. The attacked network or host might not be an end user, 115 it may be the networking device or links inside the provider core. 117 Networks must have the ability to place mitigation in order to limit 118 these threats. These mitigation steps could include routing updates, 119 traffic filters, and routing filters. It is possible that the 120 mitigation steps might have to affect transit traffic as well as 121 traffic destined to the device on which the mitigation steps are 122 activated. 124 The scope of the threat includes simply denying services to an 125 individual customer on one side of the scale to exploiting a newly 126 discovered protocol vulnerability which affects the entire provider 127 core. The obvious risk to the business requires mitigation 128 capabilities which can span this range of threats. 130 Threat: An indication of impending danger or harm to the network or 131 its parts. This could be formed from the projected loss of revenue 132 to the business. Additionally, it could be formed from the increased 133 cost to the business caused by the event. (more interfaces, more 134 bandwidth, more personnel to support the increased size or 135 complexity) 137 Risk: The possibility of suffering harm or loss of network services 138 due to a threat. 140 Attack: To set upon with violent force the network or its parts. 141 Typically this is a form of flood of packets to or through a network. 142 This could also be a much smaller stream of packets created with the 143 intent of exploiting a vulnerability in the infrastructure of the 144 network. 146 Asset: Either a customer, network device or network link. Any of 147 these could be assets from a business perspective. 149 These terms are more completely defined in [RFC2828] we have added 150 some scope specific information only. 152 Also see [I-D.savola-rtgwg-backbone-attacks] for a list of attacks on 153 backbone devices and counter measures. 155 1.2. Format 157 Each capability has the following subsections: 159 o Capability (what) 161 o Supported Practices (why) 163 o Current Implementations (how) 165 o Considerations (caveats, resource issues, protocol issues, etc.) 167 The Capability section describes a feature to be supported by the 168 device. The Supported Practice section cites practices described in 169 [RFC4778] that are supported by this capability. The Current 170 Implementation section is intended to give examples of 171 implementations of the capability, citing technology and standards 172 current at the time of writing. It is expected that the choice of 173 features to implement the capabilities will change over time. The 174 Considerations section lists operational and resource constraints, 175 limitations of current implementations, trade-offs, etc. 177 2. Packet Selection for Management and Data Plane Controls 179 In this document Section 3 describes a number of criteria for 180 performing packet selection. It is assumed in this document that 182 o all of these criteria can be used to select packets for both 183 filtering and rate limiting packets, 185 o management plane controls can be implemented by applying these 186 criteria to filter/rate limit traffic destined for the device 187 itself, 189 o data plane controls can be implemented by applying these criteria 190 to filter/rate limit traffic destined through the device 192 o multiple packet selection criteria can be used to select a single 193 set of packets for filtering action 195 3. Packet Selection Criteria 197 This section lists packet selection criteria that can be applied to 198 both filtering and rate limiting. 200 3.1. Select Traffic on All Interfaces 202 Capability. 204 The device provides a means to filter IP packets on any interface 205 implementing IP. 207 Supported Practices. 209 * Security Practices for Device Management ([RFC4778], Section 210 2.2.2) 212 * Security Practices for Data Path ([I-D.ietf-opsec-current- 213 practices], Section 2.3.2) 215 * Security Practices for Software Upgrades and Configuration 216 Integrity/Validation ([I-D.ietf-opsec-current-practices], 217 Section 2.5.2) 219 * Data Plane Filtering ([RFC4778], Section 2.7.1) 221 * Management Plane Filtering ([RFC4778], Section 2.7.2) 223 * Profile Current Traffic (Section 7.1) 225 * Block Malicious Packets (Section 7.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 239 Capability. 241 It is possible to apply the filtering mechanism to traffic that is 242 addressed directly to the device via any of its interfaces - 243 including loopback interfaces. 245 Supported Practices. 247 * Security Practices for Device Management ([RFC4778], Section 248 2.2.2) 250 * Security Practices for Software Upgrades and Configuration 251 Integrity/Validation ([RFC4778], Section 2.5.2) 253 * Management Plane Filtering ([RFC4778], Section 2.7.2) 255 Current Implementations. 257 Many devices currently implement access control lists or filters 258 that allow filtering based on protocol and/or source/destination 259 address and or source/destination port and allow these filters to 260 be applied to services offered by the device. 262 Examples of this might include filters that permit only BGP from 263 peers and SNMP and SSH from an authorized management segment and 264 directed to the device itself, while dropping all other traffic 265 addressed to the device. 267 Considerations. 269 None. 271 3.3. Select Transit Traffic 273 Capability. 275 It is possible to apply the filtering mechanism to traffic that 276 will transit the device via any of its interfaces. 278 Supported Practices. 280 * Security Practices for Data Path ([RFC4778], Section 2.3.2) 282 * Data Plane Filtering ([RFC4778], Section 2.7.1) 284 Current Implementations. 286 Many devices currently implement access control lists or filters 287 that allow filtering based on protocol and/or source/destination 288 address and or source/destination port and allow these filters to 289 be applied to the interfaces on the device in order to protect 290 assets attached to the network. 292 Examples of this may include filtering all traffic save SMTP 293 (tcp/25) destined to a mail server. A common use of this today 294 would also be denying all traffic to a destination which has been 295 determined to be hostile. 297 Considerations. 299 This allows the operator to apply filters that protect the 300 networks and assets surrounding the device from attacks and 301 unauthorized access. 303 3.4. Select Inbound and/or Outbound 305 Capability. 307 It is possible to filter both incoming and outgoing traffic on any 308 interface. 310 Supported Practices. 312 * Security Practices for Device Management ([RFC4778], Section 313 2.2.2) 315 * Security Practices for Data Path ([RFC4778], Section 2.3.2) 317 * Security Practices for Software Upgrades and Configuration 318 Integrity/Validation ([RFC4778], Section 2.5.2) 320 * Data Plane Filtering ([RFC4778], Section 2.7.1) 322 * Management Plane Filtering ([RFC4778], Section 2.7.2) 324 Current Implementations. 326 It might be desirable on a border router, for example, to apply an 327 egress filter outbound on the interface that connects a site to 328 its external ISP to drop outbound traffic that does not have a 329 valid internal source address. Inbound, it might be desirable to 330 apply a filter that blocks all traffic from a site that is known 331 to forward or originate large amounts of junk mail. 333 Considerations. 335 This allows flexibility in applying filters at the place that 336 makes the most sense. It allows invalid or malicious traffic to 337 be dropped as close to the source as possible with the least 338 impact on other traffic transiting the interface(s) in question. 340 3.5. Select by Protocols 342 Capability. 344 The device provides a means to filter traffic based on the value 345 of the protocol field in the IP header. 347 Supported Practices. 349 * Security Practices for Device Management ([RFC4778], Section 350 2.2.2) 352 * Security Practices for Data Path ([RFC4778], Section 2.3.2) 354 * Security Practices for Software Upgrades and Configuration 355 Integrity/Validation ([RFC4778],Section 2.5.2) 357 * Data Plane Filtering ([RFC4778], Section 2.7.1) 359 * Management Plane Filtering ([RFC4778], Section 2.7.2) 361 Current Implementations. 363 Some denial of service attacks are based on the ability to flood 364 the victim with ICMP traffic. One quick way (admittedly with some 365 negative side effects) to mitigate the effects of such attacks is 366 to drop all ICMP traffic headed toward the victim. 368 Considerations. 370 Being able to filter on protocol is necessary to allow 371 implementation of policy, secure operations and for support of 372 incident response. Filtering all traffic to a destination host is 373 not often possible, business requirements will dictate that 374 critical traffic be permitted if at all possible. 376 3.6. Select by Addresses 377 Capability. 379 The device is able to control the flow of traffic based on source 380 and/or destination IP address or blocks of addresses such as 381 Classless Inter-Domain Routing (CIDR) blocks. 383 Supported Practices. 385 * Security Practices for Device Management ([RFC4778], Section 386 2.2.2) 388 * Security Practices for Data Path ([RFC4778], Section 2.3.2) 390 * Security Practices for Software Upgrades and Configuration 391 Integrity/Validation ([RFC4778], Section 2.5.2 393 * Data Plane Filtering ([RFC4778], Section 2.7.1) 395 * Management Plane Filtering ([RFC4778], Section 2.7.2) 397 Current Implementations. 399 One example of the use of address based filtering is to implement 400 ingress filtering per [RFC2827] 402 Considerations. 404 The capability to filter on addresses and address blocks is a 405 fundamental tool for establishing boundaries between different 406 networks. 408 3.7. Select by Protocol Header Fields 410 Capability. 412 The filtering mechanism supports filtering based on the value(s) 413 of any portion of the protocol headers for IP, ICMP, UDP and TCP 414 by specifying fields by name (e.g., "protocol = ICMP") rather than 415 bit- offset/length/numeric value (e.g., 72:8 = 1). 417 It supports arbitrary header-based filtering (possibly using bit- 418 offset/length/value) of all other protocols. 420 Supported Practices. 422 * Security Practices for Device Management ([RFC4778], Section 423 2.2.2) 425 * Security Practices for Data Path ([RFC4778], Section 2.3.2) 427 * Security Practices for Software Upgrades and Configuration 428 Integrity/Validation ([RFC4778], Section 2.5.2) 430 * Data Plane Filtering ([RFC4778], Section 2.7.1) 432 * Management Plane Filtering ([RFC4778], Section 2.7.2) 434 Current Implementations. 436 This capability implies that it is possible to filter based on TCP 437 or UDP port numbers, TCP flags such as SYN, ACK and RST bits, and 438 ICMP type and code fields. One common example is to reject 439 "inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear 440 or SYN bit set+ACK,FIN and RST bits clear). Another common 441 example is the ability to control what services are allowed in/out 442 of a network. It may be desirable to only allow inbound 443 connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting 444 web servers. 446 Supporting arbitrary offset/length/value filtering allows 447 filtering of unknown (possibly new) protocols, e.g. filtering RTP 448 even when the device itself does not support RTP. 450 Considerations. 452 Being able to filter on portions of the header is necessary to 453 allow implementation of policy, secure operations, and support 454 incident response. 456 4. Actions 458 4.1. Specify Filter Actions 460 Capability. 462 The device provides a mechanism to allow the specification of the 463 action to be taken when a filter rule matches. Actions include 464 "permit" (allow the traffic), "reject" (drop with appropriate 465 notification to sender), and "drop" (drop with no notification to 466 sender). 468 Supported Practices. 470 * Data Origin Authentication ([RFC4778], Section 2.3.3) 472 Current Implementations. 474 Assume that your management devices for deployed networking 475 devices live on several subnets, use several protocols, and are 476 controlled by several different parts of your organization. There 477 might exist a reason to have disparate policies for access to the 478 devices from these parts of the organization. 480 Actions such as "permit", "reject", and "drop" are essential in 481 defining the security policy for the services offered by the 482 network devices. 484 Considerations. 486 While silently dropping traffic without sending notification may 487 be the correct action in security terms, consideration should be 488 given to operational implications. See [RFC3360] for 489 consideration of potential problems caused by sending 490 inappropriate TCP Resets. 492 Also note that it might be possible for an attacker to effect a 493 denial of service attack by causing too many rejection 494 notifications to be sent (e.g. syslog messages). For this reason 495 it might be desirable to rate-limit notifications. 497 4.2. Specify Rate Limits 499 Capability. 501 The device provides a mechanism to allow the specification of the 502 action to be taken when a rate limiting filter rule matches. The 503 actions include "transmit" (permit the traffic because it's below 504 the specified limit), "limit" (limit traffic because it exceeds 505 the specified limit). Limits should be applicable by both bits 506 per second and packets per timeframe (possible timeframes might 507 include second, minute, hour). Limits should able to be placed in 508 both inbound and outbound directions. 510 Supported Practices. 512 * Denial of Service Tracking/Tracing with Rate Limiting 513 ([RFC4778], Section 2.8.4) 515 Current Implementations. 517 Assume that your management devices for deployed networking 518 devices live on several subnets, use several protocols, and are 519 controlled by several different parts of your organization. There 520 might exist a reason to have disparate policies for access to the 521 devices from these parts of the organization with respect to 522 priority access to these services. Rate Limits may be used to 523 enforce these prioritizations. 525 Considerations. 527 This capability allows a filter to be used to rate limit a portion 528 of traffic through or to a device. It maybe desirable to limit 529 SNMP (UDP/161) traffic to a device, but not deny it completely. 530 Similarly, one might want to implement ICMP filters toward an 531 external network instead of discarding all ICMP traffic. 533 While silently dropping traffic without sending notification may 534 be the correct action in security terms, consideration should be 535 given to operational implications. See [RFC3360] for 536 consideration of potential problems caused by sending 537 inappropriate TCP Resets. 539 4.3. Specify Log Actions 541 Capability. 543 It is possible to log all filter actions. The logging capability 544 is able to capture at least the following data: 546 * permit/reject/drop status 548 * source and destination IP address 550 * source and destination ports (if applicable to the protocol) 551 * which network element received or was sending the packet 552 (interface, MAC address or other layer 2 information that 553 identifies the previous hop source of the packet). 555 Supported Practices. 557 * Logging Security Practices([RFC4778], Section 2.6.2) 559 Current Implementations. 561 Actions such as "permit", "reject", "drop" are essential in 562 defining the security policy for the services offered by the 563 network devices. Auditing the frequency, sources and destinations 564 of these attempts is essential for tracking ongoing issues today. 566 Considerations. 568 Logging can be burdensome to the network device, at no time should 569 logging cause performance degradation to the device or services 570 offered on the device. 572 Also note logging itself can be rate limited so as to not cause 573 performance degradation of the device or the network(in case of 574 syslog or other similar network logging mechanism. 576 4.4. Specify Log Granularity 578 Capability. 580 It is possible to enable/disable logging on a per rule basis. 582 Supported Practices. 584 * Logging Security Practices([RFC4778], Section 2.6.2) 586 Current Implementations. 588 If a filter is defined that has several rules, and one of the 589 rules denies telnet (tcp/23) connections, then it should be 590 possible to specify that only matches on the rule that denies 591 telnet should generate a log message. 593 Considerations. 595 The ability to tune the granularity of logging allows the operator 596 to log the information that is desired and only the information 597 that is desired. Without this capability, it is possible that 598 extra data (or none at all) would be logged, making it more 599 difficult to find relevant information. 601 4.5. Ability to Display Filter Counters 603 Capability. 605 The device provides a mechanism to display filter counters. 607 Supported Practices. 609 * Profile Current Traffic (Section 7.1) 611 * Respond to Incidents Based on Accurate Data (Section 7.4) 613 Current Implementations. 615 Assume there is a router with four interfaces. One is an up-link 616 to an ISP providing routes to the Internet. The other three 617 connect to separate internal networks. Assume that a host on one 618 of the internal networks has been compromised by a hacker and is 619 sending traffic with bogus source addresses. In such a situation, 620 it might be desirable to apply ingress filters to each of the 621 internal interfaces. Once the filters are in place, the counters 622 can be examined to determine the source (inbound interface) of the 623 bogus packets. 625 Considerations. 627 None. 629 5. Counters 631 5.1. Filter Counters Displayed Per Application 633 Capability. 635 If it is possible for a filter to be applied more than once at the 636 same time, then the device provides a mechanism to display filter 637 counters per filter application. 639 Supported Practices. 641 * Profile Current Traffic (Section 7.1) 643 * Respond to Incidents Based on Accurate Data (Section 7.4) 645 Current Implementations. 647 One way to implement this capability would be to have the counter 648 display mechanism show the interface (or other entity) to which 649 the filter has been applied, along with the name (or other 650 designator) for the filter. For example if a filter named 651 "desktop_outbound" applied two different interfaces, say, 652 "ethernet0" and "ethernet1", the display should indicate something 653 like "matches of filter 'desktop_outbound' on ethernet0 ..." and 654 "matches of filter 'desktop_outbound' on ethernet1 ..." 656 Considerations. 658 It may make sense to apply the same filter definition 659 simultaneously more than one time (to different interfaces, etc.). 660 If so, it would be much more useful to know which instance of a 661 filter is matching than to know that some instance was matching 662 somewhere. 664 5.2. Ability to Reset Filter Counters 666 Capability. 668 It is possible to reset counters to zero on a per filter basis. 670 Supported Practices. 672 * Profile Current Traffic (Section 7.1) 674 * Respond to Incidents Based on Accurate Data (Section 7.4) 676 Current Implementations. 678 For the purposes of this capability it would be acceptable for the 679 system to maintain two counters: an "absolute counter", C[now], 680 and a "reset" counter, C[reset]. The absolute counter would 681 maintain counts that increase monotonically until they wrap or 682 overflow the counter. The reset counter would receive a copy of 683 the current value of the absolute counter when the reset function 684 was issued for that counter. Functions that display or retrieve 685 the counter could then display the delta (C[now] - C[reset]). 687 Considerations. 689 Assume that filter counters are being used to detect internal 690 hosts that are infected with a new worm. Once it is believed that 691 all infected hosts have been cleaned up and the worm removed, the 692 next step would be to verify that. One way of doing so would be 693 to reset the filter counters to zero and see if traffic indicative 694 of the worm has ceased. 696 5.3. Filter Hits are Counted 698 Capability. 700 The device supplies a facility for counting all filter matches. 702 Supported Practices. 704 * Profile Current Traffic (Section 7.1) 706 * Respond to Incidents Based on Accurate Data (Section 7.4) 708 Current Implementations. 710 Assume, for example, that a ISP network implements anti-spoofing 711 egress filters (see [RFC2827]) on interfaces of its edge routers 712 that support single-homed stub networks. Counters could enable 713 the ISP to detect cases where large numbers of spoofed packets are 714 being sent. This may indicate that the customer is performing 715 potentially malicious actions (possibly in violation of the ISPs 716 Acceptable Use Policy), or that system(s) on the customers network 717 have been "owned" by hackers and are being (mis)used to launch 718 attacks. 720 Considerations. 722 None. 724 5.4. Filter Counters are Accurate 726 Capability. 728 Filter counters are accurate. They reflect the actual number of 729 matching packets since the last counter reset. Filter counters 730 are be capable of holding up to 2^32 - 1 values without 731 overflowing and should be capable of holding up to 2^64 - 1 732 values. 734 Supported Practices. 736 * Respond to Incidents Based on Accurate Data (Section 7.4) 738 Current Implementations. 740 If N packets matching a filter are sent to/through a device, then 741 the counter should show N matches. 743 Considerations. 745 None. 747 6. Minimal Performance Degradation 749 Capability. 751 The device provides a means to filter packets without significant 752 performance degradation. This specifically applies to stateless 753 packet filtering operating on layer 3 (IP) and layer 4 (TCP or 754 UDP) headers, as well as normal packet forwarding information such 755 as incoming and outgoing interfaces. 757 The device is able to apply stateless packet filters on ALL 758 interfaces (up to the total number of interfaces attached to the 759 device) simultaneously and with multiple filters per interface 760 (e.g., inbound and outbound). 762 Supported Practices. 764 * Implement Filters Where Necessary (Section 7.5) 766 Current Implementations. 768 Another way of stating the capability is that filter performance 769 should not be the limiting factor in device throughput. If a 770 device is capable of forwarding 30Mb/sec without filtering, then 771 it should be able to forward the same amount with filtering in 772 place. 774 Considerations. 776 The definition of "significant" is subjective. At one end of the 777 spectrum it might mean "the application of filters may cause the 778 box to crash". At the other end would be a throughput loss of 779 less than one percent with tens of thousands of filters applied. 780 The level of performance degradation that is acceptable will have 781 to be determined by the operator. 783 Repeatable test data showing filter performance impact would be 784 very useful in evaluating this capability. Tests should include 785 such information as packet size, packet rate, number of interfaces 786 tested (source/destination), types of interfaces, routing table 787 size, routing protocols in use, frequency of routing updates, etc. 788 This capability does not address stateful filtering, filtering 789 above layer 4 headers or other more advanced types of filtering 790 that may be important in certain operational environments. 791 Finally, if key infrastructure devices crash or experience severe 792 performance degradation when filtering under heavy load, or even 793 have the reputation of doing so, it is likely that security 794 personnel will be forbidden, by policy, from using filtering in 795 ways that would otherwise be appropriate for fear that it might 796 cause unnecessary service disruption. 798 7. Additional Operational Practices 800 This section describes practices not covered in [RFC4778]. They are 801 included here to provide justification for capabilities that 802 reference them. 804 7.1. Profile Current Traffic 806 This capability allows a network operator to monitor traffic across 807 an active interface in the network at a minimal level. This helps to 808 determine probable cause for interface or network problems. 810 The ability to separate and distinguish traffic at a layer-3 or 811 layer-4 level allows the operator to characterize beyond simple 812 interface counters the traffic in question. This is critical because 813 often the operator has no tools available for protocol analysis aside 814 from interface filters. 816 7.2. Block Malicious Packets 818 Blocking or limiting traffic deemed to be malicious is a key 819 component of application of any security policy's implementation. 820 Clearly it is critical to be able to implement a security policy on a 821 network. 823 Malicious packets could potentially be defined by any part of the 824 layer-3 or layer-4 headers of the IP packet. The ability to classify 825 or select traffic based on these criteria and take some action based 826 on that classification is critical to operations of a network. 828 7.3. Limit Sources of Management 830 Management of a network should be limited to only trusted hosts. 831 This implies that the network elements will be able to limit access 832 to management functions to these trusted hosts. 834 Currently operators will limit access to the management functions on 835 a network device to only the hosts that are trusted to perform that 836 function. This allows separation of critical functions and 837 protection of those functions on the network devices. 839 7.4. Respond to Incidents Based on Accurate Data 841 Accurate counting of filter rule matches is important because it 842 shows the frequency of attempts to violate policy. Inaccurate data 843 can not be relied on as the basis for action. Under-reported data 844 can conceal the magnitude of a problem. This enables resources to be 845 focused on areas of greatest need. 847 7.5. Implement Filters Where Necessary 849 This enables the implementation of filters on whichever services are 850 necessary. To the extent that filtering causes degradation, it may 851 not be possible to apply filters that implement the appropriate 852 policies. 854 8. Security Considerations 856 General 857 Security is the subject matter of this entire memo. The 858 capabilities listed cite practices in [RFC4778] that they are 859 intended to support. [RFC4778] defines the threat model, 860 practices and lists justifications for each practice. 862 9. Non-normative References 864 [I-D.lewis-infrastructure-security] 865 Lewis, D., "Service Provider Infrastructure Security", 866 draft-lewis-infrastructure-security-00 (work in progress), 867 June 2006. 869 [I-D.savola-rtgwg-backbone-attacks] 870 Savola, P., "Backbone Infrastructure Attacks and 871 Protections", draft-savola-rtgwg-backbone-attacks-03 (work 872 in progress), January 2007. 874 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 875 Defeating Denial of Service Attacks which employ IP Source 876 Address Spoofing", BCP 38, RFC 2827, May 2000. 878 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, 879 May 2000. 881 [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", 882 BCP 60, RFC 3360, August 2002. 884 [RFC3871] Jones, G., "Operational Security Requirements for Large 885 Internet Service Provider (ISP) IP Network 886 Infrastructure", RFC 3871, September 2004. 888 [RFC4778] Kaeo, M., "Operational Security Current Practices in 889 Internet Service Provider Environments", RFC 4778, 890 January 2007. 892 Appendix A. Acknowledgments 894 The authors gratefully acknowledge the contributions of: 896 o Merike Kaeo for help aligning these capabilities with supported 897 practices 899 Authors' Addresses 901 Christopher L. Morrow 902 UUNET Technologies 903 21830 UUNet Way 904 Ashburn, Virginia 21047 905 U.S.A. 907 Phone: +1 703 886 3823 908 Email: chris@uu.net 910 George M. Jones 912 Phone: +1 703 488 9740 913 Email: gmj3871@pobox.com 915 Vishwas Manral 916 IP Infusion 917 Ground Floor, 5th Cross Road, Off 8th Main Road 918 Bangalore, 52 919 India 921 Phone: +91-80-4113-1268 922 Email: vishwas@ipinfusion.com 924 Full Copyright Statement 926 Copyright (C) The IETF Trust (2007). 928 This document is subject to the rights, licenses and restrictions 929 contained in BCP 78, and except as set forth therein, the authors 930 retain all their rights. 932 This document and the information contained herein are provided on an 933 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 934 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 935 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 936 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 937 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 938 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 940 Intellectual Property 942 The IETF takes no position regarding the validity or scope of any 943 Intellectual Property Rights or other rights that might be claimed to 944 pertain to the implementation or use of the technology described in 945 this document or the extent to which any license under such rights 946 might or might not be available; nor does it represent that it has 947 made any independent effort to identify any such rights. Information 948 on the procedures with respect to rights in RFC documents can be 949 found in BCP 78 and BCP 79. 951 Copies of IPR disclosures made to the IETF Secretariat and any 952 assurances of licenses to be made available, or the result of an 953 attempt made to obtain a general license or permission for the use of 954 such proprietary rights by implementers or users of this 955 specification can be obtained from the IETF on-line IPR repository at 956 http://www.ietf.org/ipr. 958 The IETF invites any interested party to bring to its attention any 959 copyrights, patents or patent applications, or other proprietary 960 rights that may cover technology that may be required to implement 961 this standard. Please address the information to the IETF at 962 ietf-ipr@ietf.org. 964 Acknowledgment 966 Funding for the RFC Editor function is provided by the IETF 967 Administrative Support Activity (IASA).