idnits 2.17.1 draft-ietf-opsec-filter-caps-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 979. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 990. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 997. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1003. ** 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 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 ([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 (September 1, 2006) is 6446 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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 (~~), 3 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: March 5, 2007 The MITRE Corporation 6 V. Manral 7 IP Infusion 8 September 1, 2006 10 Filtering and Rate Limiting Capabilities for IP Network Infrastructure 11 draft-ietf-opsec-filter-caps-04 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 March 5, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 [I-D.ietf-opsec-current-practices] lists operator practices related 45 to securing networks. This document lists filtering and rate 46 limiting capabilities needed to support those practices. 47 Capabilities are limited to filtering and rate limiting packets as 48 they enter or leave the device. Route filters and service specific 49 filters (e.g. SNMP, telnet) are not 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 . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . 11 72 3.7. Select by Protocol Header Fields . . . . . . . . . . . . . 12 73 4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 4.1. Specify Filter Actions . . . . . . . . . . . . . . . . . . 14 75 4.2. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 14 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. Non-normative References . . . . . . . . . . . . . . . . . . . 26 93 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 27 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 95 Intellectual Property and Copyright Statements . . . . . . . . . . 29 97 1. Introduction 99 This document is defined in the context of 100 [I-D.ietf-opsec-current-practices]. 101 [I-D.ietf-opsec-current-practices] defines the goals, motivation, 102 scope, definitions, intended audience, threat model, potential 103 attacks and give justifications for each of the practices. Many of 104 the capabilities listed here refine or add to capabilities listed in 105 [RFC3871]. 107 Also see [I-D.lewis-infrastructure-security] for a useful description 108 of techniques for protecting infrastructure devices, including the 109 use of filtering. 111 1.1. Threat Model 113 Threats in today's networked environment range from simple packet 114 floods with overwhelming bandwidth toward a leaf network to subtle 115 attacks aimed at subverting known vulnerabilities in existing 116 applications. The attacked network or host might not be an end user, 117 it may be the networking device or links inside the provider core. 119 Networks must have the ability to place mitigation in order to limit 120 these threats. These mitigation steps could include routing updates, 121 traffic filters, and routing filters. It is possible that the 122 mitigation steps might have to affect transit traffic as well as 123 traffic destined to the device on which the mitigation steps are 124 activated. 126 The scope of the threat includes simply denying services to an 127 individual customer on one side of the scale to exploiting a newly 128 discovered protocol vulnerability which affects the entire provider 129 core. The obvious risk to the business requires mitigation 130 capabilities which can span this range of threats. 132 Threat: An indication of impending danger or harm to the network or 133 its parts. This could be formed from the projected loss of revenue 134 to the business. Additionally, it could be formed from the increased 135 cost to the business caused by the event. (more interfaces, more 136 bandwidth, more personnel to support the increased size or 137 complexity) 139 Risk: The possibility of suffering harm or loss of network services 140 due to a threat. 142 Attack: To set upon with violent force the network or its parts. 143 Typically this is a form of flood of packets to or through a network. 144 This could also be a much smaller stream of packets created with the 145 intent of exploiting a vulnerability in the infrastructure of the 146 network. 148 Asset: Either a customer, network device or network link. Any of 149 these could be assets from a business perspective. 151 These terms are more completely defined in [RFC2828] we have added 152 some scope specific information only. 154 Also see [I-D.savola-rtgwg-backbone-attacks] for a list of attacks on 155 backbone devices and counter measures. 157 1.2. Format 159 Each capability has the following subsections: 161 o Capability (what) 163 o Supported Practices (why) 165 o Current Implementations (how) 167 o Considerations (caveats, resource issues, protocol issues, etc.) 169 The Capability section describes a feature to be supported by the 170 device. The Supported Practice section cites practices described in 171 [I-D.ietf-opsec-current-practices] that are supported by this 172 capability. The Current Implementation section is intended to give 173 examples of implementations of the capability, citing technology and 174 standards current at the time of writing. It is expected that the 175 choice of features to implement the capabilities will change over 176 time. The Considerations section lists operational and resource 177 constraints, limitations of current implementations, trade-offs, etc. 179 2. Packet Selection for Management and Data Plane Controls 181 In this document Section 3 describes a number of criteria for 182 performing packet selection. It is assumed in this document that 184 o all of these criteria can be used to select packets for both 185 filtering and rate limiting packets, 187 o management plane controls can be implemented by applying these 188 criteria to filter/rate limit traffic destined for the device 189 itself, 191 o data plane controls can be implemented by applying these criteria 192 to filter/rate limit traffic destined through the device 194 o multiple packet selection criteria can be used to select a single 195 set of packets for filtering action 197 3. Packet Selection Criteria 199 This section lists packet selection criteria that can be applied to 200 both filtering and rate limiting. 202 3.1. Select Traffic on All Interfaces 204 Capability. 206 The device provides a means to filter IP packets on any interface 207 implementing IP. 209 Supported Practices. 211 * Security Practices for Device Management 212 ([I-D.ietf-opsec-current-practices], Section 2.2.2) 214 * Security Practices for Data Path ([I-D.ietf-opsec-current- 215 practices], Section 2.3.2) 217 * Security Practices for Software Upgrades and Configuration 218 Integrity/Validation ([I-D.ietf-opsec-current-practices], 219 Section 2.5.2) 221 * Data Plane Filtering ([I-D.ietf-opsec-current-practices], 222 Section 2.7.1) 224 * Management Plane Filtering ([I-D.ietf-opsec-current-practices], 225 Section 2.7.2) 227 * Profile Current Traffic (Section 7.1) 229 * Block Malicious Packets (Section 7.2) 231 Current Implementations. 233 Many devices currently implement access control lists or filters 234 that allow filtering based on protocol and/or source/destination 235 address and or source/destination port and allow these filters to 236 be applied to interfaces. 238 Considerations. 240 None. 242 3.2. Select Traffic To the Device 244 Capability. 246 It is possible to apply the filtering mechanism to traffic that is 247 addressed directly to the device via any of its interfaces - 248 including loopback interfaces. 250 Supported Practices. 252 * Security Practices for Device Management 253 ([I-D.ietf-opsec-current-practices], Section 2.2.2) 255 * Security Practices for Software Upgrades and Configuration 256 Integrity/Validation ([I-D.ietf-opsec-current-practices], 257 Section 2.5.2) 259 * Management Plane Filtering ([I-D.ietf-opsec-current-practices], 260 Section 2.7.2) 262 Current Implementations. 264 Many devices currently implement access control lists or filters 265 that allow filtering based on protocol and/or source/destination 266 address and or source/destination port and allow these filters to 267 be applied to services offered by the device. 269 Examples of this might include filters that permit only BGP from 270 peers and SNMP and SSH from an authorized management segment and 271 directed to the device itself, while dropping all other traffic 272 addressed to the device. 274 Considerations. 276 None. 278 3.3. Select Transit Traffic 280 Capability. 282 It is possible to apply the filtering mechanism to traffic that 283 will transit the device via any of its interfaces. 285 Supported Practices. 287 * Security Practices for Data Path 288 ([I-D.ietf-opsec-current-practices], Section 2.3.2) 290 * Data Plane Filtering ([I-D.ietf-opsec-current-practices], 291 Section 2.7.1) 293 Current Implementations. 295 Many devices currently implement access control lists or filters 296 that allow filtering based on protocol and/or source/destination 297 address and or source/destination port and allow these filters to 298 be applied to the interfaces on the device in order to protect 299 assets attached to the network. 301 Examples of this may include filtering all traffic save SMTP 302 (tcp/25) destined to a mail server. A common use of this today 303 would also be denying all traffic to a destination which has been 304 determined to be hostile. 306 Considerations. 308 This allows the operator to apply filters that protect the 309 networks and assets surrounding the device from attacks and 310 unauthorized access. 312 3.4. Select Inbound and/or Outbound 314 Capability. 316 It is possible to filter both incoming and outgoing traffic on any 317 interface. 319 Supported Practices. 321 * Security Practices for Device Management 322 ([I-D.ietf-opsec-current-practices], Section 2.2.2) 324 * Security Practices for Data Path 325 ([I-D.ietf-opsec-current-practices], Section 2.3.2) 327 * Security Practices for Software Upgrades and Configuration 328 Integrity/Validation ([I-D.ietf-opsec-current-practices], 329 Section 2.5.2) 331 * Data Plane Filtering ([I-D.ietf-opsec-current-practices], 332 Section 2.7.1) 334 * Management Plane Filtering ([I-D.ietf-opsec-current-practices], 335 Section 2.7.2) 337 Current Implementations. 339 It might be desirable on a border router, for example, to apply an 340 egress filter outbound on the interface that connects a site to 341 its external ISP to drop outbound traffic that does not have a 342 valid internal source address. Inbound, it might be desirable to 343 apply a filter that blocks all traffic from a site that is known 344 to forward or originate large amounts of junk mail. 346 Considerations. 348 This allows flexibility in applying filters at the place that 349 makes the most sense. It allows invalid or malicious traffic to 350 be dropped as close to the source as possible with the least 351 impact on other traffic transiting the interface(s) in question. 353 3.5. Select by Protocols 355 Capability. 357 The device provides a means to filter traffic based on the value 358 of the protocol field in the IP header. 360 Supported Practices. 362 * Security Practices for Device Management 363 ([I-D.ietf-opsec-current-practices], Section 2.2.2) 365 * Security Practices for Data Path 366 ([I-D.ietf-opsec-current-practices], Section 2.3.2) 368 * Security Practices for Software Upgrades and Configuration 369 Integrity/Validation 370 ([I-D.ietf-opsec-current-practices],Section 2.5.2) 372 * Data Plane Filtering ([I-D.ietf-opsec-current-practices], 373 Section 2.7.1) 375 * Management Plane Filtering ([I-D.ietf-opsec-current-practices], 376 Section 2.7.2) 378 Current Implementations. 380 Some denial of service attacks are based on the ability to flood 381 the victim with ICMP traffic. One quick way (admittedly with some 382 negative side effects) to mitigate the effects of such attacks is 383 to drop all ICMP traffic headed toward the victim. 385 Considerations. 387 Being able to filter on protocol is necessary to allow 388 implementation of policy, secure operations and for support of 389 incident response. Filtering all traffic to a destination host is 390 not often possible, business requirements will dictate that 391 critical traffic be permitted if at all possible. 393 3.6. Select by Addresses 395 Capability. 397 The device is able to control the flow of traffic based on source 398 and/or destination IP address or blocks of addresses such as 399 Classless Inter-Domain Routing (CIDR) blocks. 401 Supported Practices. 403 * Security Practices for Device Management 404 ([I-D.ietf-opsec-current-practices], Section 2.2.2) 406 * Security Practices for Data Path 407 ([I-D.ietf-opsec-current-practices], Section 2.3.2) 409 * Security Practices for Software Upgrades and Configuration 410 Integrity/Validation ([I-D.ietf-opsec-current-practices], 411 Section 2.5.2 413 * Data Plane Filtering ([I-D.ietf-opsec-current-practices], 414 Section 2.7.1) 416 * Management Plane Filtering ([I-D.ietf-opsec-current-practices], 417 Section 2.7.2) 419 Current Implementations. 421 One example of the use of address based filtering is to implement 422 ingress filtering per [RFC2827] 424 Considerations. 426 The capability to filter on addresses and address blocks is a 427 fundamental tool for establishing boundaries between different 428 networks. 430 3.7. Select by Protocol Header Fields 432 Capability. 434 The filtering mechanism supports filtering based on the value(s) 435 of any portion of the protocol headers for IP, ICMP, UDP and TCP 436 by specifying fields by name (e.g., "protocol = ICMP") rather than 437 bit- offset/length/numeric value (e.g., 72:8 = 1). 439 It supports arbitrary header-based filtering (possibly using bit- 440 offset/length/value) of all other protocols. 442 Supported Practices. 444 * Security Practices for Device Management 445 ([I-D.ietf-opsec-current-practices], Section 2.2.2) 447 * Security Practices for Data Path 448 ([I-D.ietf-opsec-current-practices], Section 2.3.2) 450 * Security Practices for Software Upgrades and Configuration 451 Integrity/Validation ([I-D.ietf-opsec-current-practices], 452 Section 2.5.2) 454 * Data Plane Filtering ([I-D.ietf-opsec-current-practices], 455 Section 2.7.1) 457 * Management Plane Filtering ([I-D.ietf-opsec-current-practices], 458 Section 2.7.2) 460 Current Implementations. 462 This capability implies that it is possible to filter based on TCP 463 or UDP port numbers, TCP flags such as SYN, ACK and RST bits, and 464 ICMP type and code fields. One common example is to reject 465 "inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear 466 or SYN bit set+ACK,FIN and RST bits clear). Another common 467 example is the ability to control what services are allowed in/out 468 of a network. It may be desirable to only allow inbound 469 connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting 470 web servers. 472 Supporting arbitrary offset/length/value filtering allows 473 filtering of unknown (possibly new) protocols, e.g. filtering RTP 474 even when the device itself does not support RTP. 476 Considerations. 478 Being able to filter on portions of the header is necessary to 479 allow implementation of policy, secure operations, and support 480 incident response. 482 4. Actions 484 4.1. Specify Filter Actions 486 Capability. 488 The device provides a mechanism to allow the specification of the 489 action to be taken when a filter rule matches. Actions include 490 "permit" (allow the traffic), "reject" (drop with appropriate 491 notification to sender), and "drop" (drop with no notification to 492 sender). 494 Supported Practices. 496 * Data Origin Authentication ([I-D.ietf-opsec-current-practices], 497 Section 2.3.3) 499 Current Implementations. 501 Assume that your management devices for deployed networking 502 devices live on several subnets, use several protocols, and are 503 controlled by several different parts of your organization. There 504 might exist a reason to have disparate policies for access to the 505 devices from these parts of the organization. 507 Actions such as "permit", "reject", and "drop" are essential in 508 defining the security policy for the services offered by the 509 network devices. 511 Considerations. 513 While silently dropping traffic without sending notification may 514 be the correct action in security terms, consideration should be 515 given to operational implications. See [RFC3360] for 516 consideration of potential problems caused by sending 517 inappropriate TCP Resets. 519 Also note that it might be possible for an attacker to effect a 520 denial of service attack by causing too many rejection 521 notifications to be sent (e.g. syslog messages). For this reason 522 it might be desirable to rate-limit notifications. 524 4.2. Specify Rate Limits 525 Capability. 527 The device provides a mechanism to allow the specification of the 528 action to be taken when a rate limiting filter rule matches. The 529 actions include "transmit" (permit the traffic because it's below 530 the specified limit), "limit" (limit traffic because it exceeds 531 the specified limit). Limits should be applicable by both bits 532 per second and packets per timeframe (possible timeframes might 533 include second, minute, hour). Limits should able to be placed in 534 both inbound and outbound directions. 536 Supported Practices. 538 * Denial of Service Tracking/Tracing with Rate Limiting 539 ([I-D.ietf-opsec-current-practices], Section 2.8.4) 541 Current Implementations. 543 Assume that your management devices for deployed networking 544 devices live on several subnets, use several protocols, and are 545 controlled by several different parts of your organization. There 546 might exist a reason to have disparate policies for access to the 547 devices from these parts of the organization with respect to 548 priority access to these services. Rate Limits may be used to 549 enforce these prioritizations. 551 Considerations. 553 This capability allows a filter to be used to rate limit a portion 554 of traffic through or to a device. It maybe desirable to limit 555 SNMP (UDP/161) traffic to a device, but not deny it completely. 556 Similarly, one might want to implement ICMP filters toward an 557 external network instead of discarding all ICMP traffic. 559 While silently dropping traffic without sending notification may 560 be the correct action in security terms, consideration should be 561 given to operational implications. See [RFC3360] for 562 consideration of potential problems caused by sending 563 inappropriate TCP Resets. 565 4.3. Specify Log Actions 567 Capability. 569 It is possible to log all filter actions. The logging capability 570 is able to capture at least the following data: 572 * permit/reject/drop status 574 * source and destination IP address 576 * source and destination ports (if applicable to the protocol) 578 * which network element received or was sending the packet 579 (interface, MAC address or other layer 2 information that 580 identifies the previous hop source of the packet). 582 Supported Practices. 584 * Logging Security Practices([I-D.ietf-opsec-current-practices], 585 Section 2.6.2) 587 Current Implementations. 589 Actions such as "permit", "reject", "drop" are essential in 590 defining the security policy for the services offered by the 591 network devices. Auditing the frequency, sources and destinations 592 of these attempts is essential for tracking ongoing issues today. 594 Considerations. 596 Logging can be burdensome to the network device, at no time should 597 logging cause performance degradation to the device or services 598 offered on the device. 600 Also note logging itself can be rate limited so as to not cause 601 performance degradation of the device or the network(in case of 602 syslog or other similar network logging mechanism. 604 4.4. Specify Log Granularity 606 Capability. 608 It is possible to enable/disable logging on a per rule basis. 610 Supported Practices. 612 * Logging Security Practices([I-D.ietf-opsec-current-practices], 613 Section 2.6.2) 615 Current Implementations. 617 If a filter is defined that has several rules, and one of the 618 rules denies telnet (tcp/23) connections, then it should be 619 possible to specify that only matches on the rule that denies 620 telnet should generate a log message. 622 Considerations. 624 The ability to tune the granularity of logging allows the operator 625 to log the information that is desired and only the information 626 that is desired. Without this capability, it is possible that 627 extra data (or none at all) would be logged, making it more 628 difficult to find relevant information. 630 4.5. Ability to Display Filter Counters 632 Capability. 634 The device provides a mechanism to display filter counters. 636 Supported Practices. 638 * Profile Current Traffic (Section 7.1) 640 * Respond to Incidents Based on Accurate Data (Section 7.4) 642 Current Implementations. 644 Assume there is a router with four interfaces. One is an up-link 645 to an ISP providing routes to the Internet. The other three 646 connect to separate internal networks. Assume that a host on one 647 of the internal networks has been compromised by a hacker and is 648 sending traffic with bogus source addresses. In such a situation, 649 it might be desirable to apply ingress filters to each of the 650 internal interfaces. Once the filters are in place, the counters 651 can be examined to determine the source (inbound interface) of the 652 bogus packets. 654 Considerations. 656 None. 658 5. Counters 660 5.1. Filter Counters Displayed Per Application 662 Capability. 664 If it is possible for a filter to be applied more than once at the 665 same time, then the device provides a mechanism to display filter 666 counters per filter application. 668 Supported Practices. 670 * Profile Current Traffic (Section 7.1) 672 * Respond to Incidents Based on Accurate Data (Section 7.4) 674 Current Implementations. 676 One way to implement this capability would be to have the counter 677 display mechanism show the interface (or other entity) to which 678 the filter has been applied, along with the name (or other 679 designator) for the filter. For example if a filter named 680 "desktop_outbound" applied two different interfaces, say, 681 "ethernet0" and "ethernet1", the display should indicate something 682 like "matches of filter 'desktop_outbound' on ethernet0 ..." and 683 "matches of filter 'desktop_outbound' on ethernet1 ..." 685 Considerations. 687 It may make sense to apply the same filter definition 688 simultaneously more than one time (to different interfaces, etc.). 689 If so, it would be much more useful to know which instance of a 690 filter is matching than to know that some instance was matching 691 somewhere. 693 5.2. Ability to Reset Filter Counters 695 Capability. 697 It is possible to reset counters to zero on a per filter basis. 699 Supported Practices. 701 * Profile Current Traffic (Section 7.1) 703 * Respond to Incidents Based on Accurate Data (Section 7.4) 705 Current Implementations. 707 For the purposes of this capability it would be acceptable for the 708 system to maintain two counters: an "absolute counter", C[now], 709 and a "reset" counter, C[reset]. The absolute counter would 710 maintain counts that increase monotonically until they wrap or 711 overflow the counter. The reset counter would receive a copy of 712 the current value of the absolute counter when the reset function 713 was issued for that counter. Functions that display or retrieve 714 the counter could then display the delta (C[now] - C[reset]). 716 Considerations. 718 Assume that filter counters are being used to detect internal 719 hosts that are infected with a new worm. Once it is believed that 720 all infected hosts have been cleaned up and the worm removed, the 721 next step would be to verify that. One way of doing so would be 722 to reset the filter counters to zero and see if traffic indicative 723 of the worm has ceased. 725 5.3. Filter Hits are Counted 727 Capability. 729 The device supplies a facility for counting all filter matches. 731 Supported Practices. 733 * Profile Current Traffic (Section 7.1) 735 * Respond to Incidents Based on Accurate Data (Section 7.4) 737 Current Implementations. 739 Assume, for example, that a ISP network implements anti-spoofing 740 egress filters (see [RFC2827]) on interfaces of its edge routers 741 that support single-homed stub networks. Counters could enable 742 the ISP to detect cases where large numbers of spoofed packets are 743 being sent. This may indicate that the customer is performing 744 potentially malicious actions (possibly in violation of the ISPs 745 Acceptable Use Policy), or that system(s) on the customers network 746 have been "owned" by hackers and are being (mis)used to launch 747 attacks. 749 Considerations. 751 None. 753 5.4. Filter Counters are Accurate 755 Capability. 757 Filter counters are accurate. They reflect the actual number of 758 matching packets since the last counter reset. Filter counters 759 are be capable of holding up to 2^32 - 1 values without 760 overflowing and should be capable of holding up to 2^64 - 1 761 values. 763 Supported Practices. 765 * Respond to Incidents Based on Accurate Data (Section 7.4) 767 Current Implementations. 769 If N packets matching a filter are sent to/through a device, then 770 the counter should show N matches. 772 Considerations. 774 None. 776 6. Minimal Performance Degradation 778 Capability. 780 The device provides a means to filter packets without significant 781 performance degradation. This specifically applies to stateless 782 packet filtering operating on layer 3 (IP) and layer 4 (TCP or 783 UDP) headers, as well as normal packet forwarding information such 784 as incoming and outgoing interfaces. 786 The device is able to apply stateless packet filters on ALL 787 interfaces (up to the total number of interfaces attached to the 788 device) simultaneously and with multiple filters per interface 789 (e.g., inbound and outbound). 791 Supported Practices. 793 * Implement Filters Where Necessary (Section 7.5) 795 Current Implementations. 797 Another way of stating the capability is that filter performance 798 should not be the limiting factor in device throughput. If a 799 device is capable of forwarding 30Mb/sec without filtering, then 800 it should be able to forward the same amount with filtering in 801 place. 803 Considerations. 805 The definition of "significant" is subjective. At one end of the 806 spectrum it might mean "the application of filters may cause the 807 box to crash". At the other end would be a throughput loss of 808 less than one percent with tens of thousands of filters applied. 809 The level of performance degradation that is acceptable will have 810 to be determined by the operator. 812 Repeatable test data showing filter performance impact would be 813 very useful in evaluating this capability. Tests should include 814 such information as packet size, packet rate, number of interfaces 815 tested (source/destination), types of interfaces, routing table 816 size, routing protocols in use, frequency of routing updates, etc. 817 This capability does not address stateful filtering, filtering 818 above layer 4 headers or other more advanced types of filtering 819 that may be important in certain operational environments. 820 Finally, if key infrastructure devices crash or experience severe 821 performance degradation when filtering under heavy load, or even 822 have the reputation of doing so, it is likely that security 823 personnel will be forbidden, by policy, from using filtering in 824 ways that would otherwise be appropriate for fear that it might 825 cause unnecessary service disruption. 827 7. Additional Operational Practices 829 This section describes practices not covered in 830 [I-D.ietf-opsec-current-practices]. They are included here to 831 provide justification for capabilities that reference them. 833 7.1. Profile Current Traffic 835 This capability allows a network operator to monitor traffic across 836 an active interface in the network at a minimal level. This helps to 837 determine probable cause for interface or network problems. 839 The ability to separate and distinguish traffic at a layer-3 or 840 layer-4 level allows the operator to characterize beyond simple 841 interface counters the traffic in question. This is critical because 842 often the operator has no tools available for protocol analysis aside 843 from interface filters. 845 7.2. Block Malicious Packets 847 Blocking or limiting traffic deemed to be malicious is a key 848 component of application of any security policy's implementation. 849 Clearly it is critical to be able to implement a security policy on a 850 network. 852 Malicious packets could potentially be defined by any part of the 853 layer-3 or layer-4 headers of the IP packet. The ability to classify 854 or select traffic based on these criteria and take some action based 855 on that classification is critical to operations of a network. 857 7.3. Limit Sources of Management 859 Management of a network should be limited to only trusted hosts. 860 This implies that the network elements will be able to limit access 861 to management functions to these trusted hosts. 863 Currently operators will limit access to the management functions on 864 a network device to only the hosts that are trusted to perform that 865 function. This allows separation of critical functions and 866 protection of those functions on the network devices. 868 7.4. Respond to Incidents Based on Accurate Data 870 Accurate counting of filter rule matches is important because it 871 shows the frequency of attempts to violate policy. Inaccurate data 872 can not be relied on as the basis for action. Under-reported data 873 can conceal the magnitude of a problem. This enables resources to be 874 focused on areas of greatest need. 876 7.5. Implement Filters Where Necessary 878 This enables the implementation of filters on whichever services are 879 necessary. To the extent that filtering causes degradation, it may 880 not be possible to apply filters that implement the appropriate 881 policies. 883 8. Security Considerations 885 General 886 Security is the subject matter of this entire memo. The 887 capabilities listed cite practices in 888 [I-D.ietf-opsec-current-practices] that they are intended to 889 support. [I-D.ietf-opsec-current-practices] defines the threat 890 model, practices and lists justifications for each practice. 892 9. Non-normative References 894 [I-D.ietf-opsec-current-practices] 895 Kaeo, M., "Operational Security Current Practices", 896 draft-ietf-opsec-current-practices-04 (work in progress), 897 June 2006. 899 [I-D.lewis-infrastructure-security] 900 Lewis, D., "Service Provider Infrastructure Security", 901 draft-lewis-infrastructure-security-00 (work in progress), 902 June 2006. 904 [I-D.savola-rtgwg-backbone-attacks] 905 Savola, P., "Backbone Infrastructure Attacks and 906 Protections", draft-savola-rtgwg-backbone-attacks-01 (work 907 in progress), June 2006. 909 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 910 Defeating Denial of Service Attacks which employ IP Source 911 Address Spoofing", BCP 38, RFC 2827, May 2000. 913 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, 914 May 2000. 916 [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", 917 BCP 60, RFC 3360, August 2002. 919 [RFC3871] Jones, G., "Operational Security Requirements for Large 920 Internet Service Provider (ISP) IP Network 921 Infrastructure", RFC 3871, September 2004. 923 Appendix A. Acknowledgments 925 The authors gratefully acknowledge the contributions of: 927 o Merike Kaeo for help aligning these capabilities with supported 928 practices 930 o The MITRE Corporation for supporting development of this document. 931 NOTE: The editor's affiliation with The MITRE Corporation is 932 provided for identification purposes only, and is not intended to 933 convey or imply MITRE's concurrence with, or support for, the 934 positions, opinions or viewpoints expressed by the editor. 936 Authors' Addresses 938 Christopher L. Morrow 939 UUNET Technologies 940 21830 UUNet Way 941 Ashburn, Virginia 21047 942 U.S.A. 944 Phone: +1 703 886 3823 945 Email: chris@uu.net 947 George M. Jones 948 The MITRE Corporation 949 7515 Colshire Drive, M/S WEST 950 McLean, Virginia 22102-7508 951 U.S.A. 953 Phone: +1 703 488 9740 954 Email: gmjones@mitre.org 956 Vishwas Manral 957 IP Infusion 958 Ground Floor, 5th Cross Road, Off 8th Main Road 959 Bangalore, 52 960 India 962 Phone: +91-80-4113-1268 963 Email: vishwas@ipinfusion.com 965 Full Copyright Statement 967 Copyright (C) The Internet Society (2006). 969 This document is subject to the rights, licenses and restrictions 970 contained in BCP 78, and except as set forth therein, the authors 971 retain all their rights. 973 This document and the information contained herein are provided on an 974 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 975 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 976 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 977 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 978 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 979 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 981 Intellectual Property 983 The IETF takes no position regarding the validity or scope of any 984 Intellectual Property Rights or other rights that might be claimed to 985 pertain to the implementation or use of the technology described in 986 this document or the extent to which any license under such rights 987 might or might not be available; nor does it represent that it has 988 made any independent effort to identify any such rights. Information 989 on the procedures with respect to rights in RFC documents can be 990 found in BCP 78 and BCP 79. 992 Copies of IPR disclosures made to the IETF Secretariat and any 993 assurances of licenses to be made available, or the result of an 994 attempt made to obtain a general license or permission for the use of 995 such proprietary rights by implementers or users of this 996 specification can be obtained from the IETF on-line IPR repository at 997 http://www.ietf.org/ipr. 999 The IETF invites any interested party to bring to its attention any 1000 copyrights, patents or patent applications, or other proprietary 1001 rights that may cover technology that may be required to implement 1002 this standard. Please address the information to the IETF at 1003 ietf-ipr@ietf.org. 1005 Acknowledgment 1007 Funding for the RFC Editor function is provided by the IETF 1008 Administrative Support Activity (IASA).