idnits 2.17.1 draft-ietf-opsec-filter-caps-09.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 1001. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1012. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1019. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1025. 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 (July 5, 2007) is 6134 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2828' is mentioned on line 921, 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: Best Current G. Jones 5 Practice Port111 Labs 6 Expires: January 6, 2008 V. Manral 7 IP Infusion 8 July 5, 2007 10 Filtering and Rate Limiting Capabilities for IP Network Infrastructure 11 draft-ietf-opsec-filter-caps-09 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 January 6, 2008. 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 assumed in 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 traffic judged to be invalid or 419 malicious to be dropped as close to the source as possible with 420 the least impact on other traffic transiting the interface(s) in 421 question. 423 3.6. Select by Address, Protocol or Protocol Header Fields 425 Capability. 427 The device supports selection based on: 429 * source IP address 431 * destination IP address 433 * source port 435 * destination port 437 * protocol ID 439 * TCP flags (SYN, ACK, RST) 441 * DiffServ Code Point (DSCP) 443 * the value(s) of any portion of the protocol headers for IP, 444 ICMP, UDP and TCP by specifying fields by name (e.g., "protocol 445 = ICMP") rather than bit- offset/length/numeric value (e.g., 446 72:8 = 1). 448 * Arbitrary header-based selection (possibly using bit-offset/ 449 length/value) of all other protocols. 451 Supported Practices. 453 * Security Practices for Device Management ([RFC4778], Section 454 2.2.2) 456 * Security Practices for Data Path ([RFC4778], Section 2.3.2) 458 * Security Practices for Software Upgrades and Configuration 459 Integrity/Validation ([RFC4778], Section 2.5.2) 461 * Data Plane Filtering ([RFC4778], Section 2.7.1) 463 * Management Plane Filtering ([RFC4778], Section 2.7.2) 465 Current Implementations. 467 This capability implies that it is possible to filter based on TCP 468 or UDP port numbers, TCP flags such as SYN, ACK and RST bits, and 469 ICMP type and code fields. One common example is to reject 470 "inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear 471 or SYN bit set+ACK,FIN and RST bits clear). Another common 472 example is the ability to control what services are allowed in/out 473 of a network. It may be desirable to only allow inbound 474 connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting 475 web servers. 477 Some denial of service attacks are based on the ability to flood 478 the victim with ICMP traffic. One quick way to mitigate the 479 effects of such attacks is to drop all ICMP traffic headed toward 480 the victim. It should be noted ([RFC2923]) that one possibly 481 negative implication of filtering all ICMP traffic towards a 482 victim is that legitimate functions which rely upon successful 483 delivery of ICMP messages to the victim (e.g., ICMP unreachables, 484 Type-3 messages) will not be received by the victim. 486 Supporting arbitrary offset/length/value selection allows 487 filtering of unknown (possibly new) protocols, e.g. filtering RTP 488 even when the device itself does not support RTP. 490 Considerations. 492 The capability to filter on addresses, address blocks and 493 protocols is a fundamental tool for establishing boundaries 494 between different networks. 496 Being able to filter on portions of the header is necessary to 497 allow implementation of policy, secure operations, and support 498 incident response. 500 4. Actions 502 4.1. Specify Filter Actions 504 Capability. 506 The device provides a mechanism through which operators can 507 specify a forwarding action to be taken when the selection 508 criteria is met. Forwarding actions include the following: 510 * permit (allow the datagram) 512 * discard (silently discard the datagram) 514 * reject (discard the datagram and send a notification to its 515 originator) 517 Supported Practices. 519 * Data Origin Authentication ([RFC4778], Section 2.3.3) 521 Current Implementations. 523 Assume that your management devices for deployed networking 524 devices live on several subnets, use several protocols, and are 525 controlled by several different parts of your organization. There 526 might exist a reason to have disparate policies for access to the 527 devices from these parts of the organization. 529 Actions such as "permit", "reject", and "drop" are essential in 530 defining the security policy for the services offered by the 531 network devices. 533 Considerations. 535 While silently dropping traffic without sending notification may 536 be the correct action in security terms, consideration should be 537 given to operational implications. See [RFC3360] for 538 consideration of potential problems caused by sending 539 inappropriate TCP Resets, for instance. 541 Also note that it might be possible for an attacker to effect a 542 denial of service attack by causing too many rejection 543 notifications to be sent (e.g. via syslog messages). For this 544 reason it might be desirable to rate-limit notifications. 546 4.2. Specify Rate Limits 548 Capability. 550 The device provides a mechanism to allow the specification of the 551 action to be taken when a rate limiting filter matches. The 552 actions include "transmit" (permit the traffic because it's below 553 the specified limit), "limit" (limit traffic because it exceeds 554 the specified limit). Limits should be applicable by both bits 555 per second and packets per time-frame (possible time-frames might 556 include second, minute, hour). Limits should able to be placed in 557 both inbound and outbound directions. 559 Supported Practices. 561 * Denial of Service Tracking/Tracing with Rate Limiting 562 ([RFC4778], Section 2.8.4) 564 Current Implementations. 566 Assume that your management devices for deployed networking 567 devices live on several subnets, use several protocols, and are 568 controlled by several different parts of your organization. There 569 might exist a reason to have disparate policies for access to the 570 devices from these parts of the organization with respect to 571 priority access to these services. Rate Limits may be used to 572 enforce these prioritizations. 574 Considerations. 576 This capability allows a filter to be used to rate limit a portion 577 of traffic through or to a device. It maybe desirable to limit 578 SNMP (UDP/161) traffic to a device, but not deny it completely. 579 Similarly, one might want to implement ICMP filters toward an 580 external network instead of discarding all ICMP traffic. 582 While silently dropping traffic without sending notification may 583 be the correct action in security terms, consideration should be 584 given to operational implications. See [RFC3360] for 585 consideration of potential problems caused by sending 586 inappropriate TCP Resets, for instance. 588 4.3. Specify Log Actions 589 Capability. 591 It is possible to log all filter actions. The logging capability 592 is able to capture at least the following data: 594 * permit/reject/drop status 596 * source and destination IP address 598 * source and destination ports (if applicable to the protocol) 600 * which network element received or was sending the packet 601 (interface, MAC address or other layer 2 information that 602 identifies the previous hop source of the packet). 604 Supported Practices. 606 * Logging Security Practices([RFC4778], Section 2.6.2) 608 Current Implementations. 610 Actions such as "permit", "reject", "drop" are essential in 611 defining the security policy for the services offered by the 612 network devices. Auditing the frequency, sources and destinations 613 of these attempts is essential for tracking ongoing issues today. 615 Considerations. 617 Logging can be burdensome to the network device, at no time should 618 logging cause performance degradation to the device or services 619 offered on the device. 621 Also note logging itself can be rate limited so as to not cause 622 performance degradation of the device or the network(in case of 623 syslog or other similar network logging mechanism. 625 4.4. Specify Log Granularity 627 Capability. 629 The device provides a mechanism through which operators can 630 enable/disable logging on a per rule basis. 632 Supported Practices. 634 * Logging Security Practices([RFC4778], Section 2.6.2) 636 Current Implementations. 638 If a filter is defined that has several rules, and one of the 639 rules specifies an action that denies telnet (tcp/23) connections, 640 then it should be possible to specify that only matches on the 641 rule that denies telnet should generate a log message. 643 Considerations. 645 The ability to tune the granularity of logging allows the operator 646 to log the information that is desired and only the information 647 that is desired. Without this capability, it is possible that 648 extra data (or none at all) would be logged, making it more 649 difficult to find relevant information. 651 4.5. Ability to Display Filter Counters 653 Capability. 655 The device provides a mechanism to display filter counters. 657 Supported Practices. 659 * Profile Current Traffic (Section 7.1) 661 * Respond to Incidents Based on Accurate Data (Section 7.4) 663 Current Implementations. 665 Assume there is a router with four interfaces. One is an up-link 666 to an ISP providing routes to the Internet. The other three 667 connect to separate internal networks. Assume that a host on one 668 of the internal networks has been compromised by a hacker and is 669 sending traffic with bogus source addresses. In such a situation, 670 it might be desirable to apply ingress filters to each of the 671 internal interfaces. Once the filters are in place, the counters 672 can be examined to determine the source (inbound interface) of the 673 bogus packets. 675 Considerations. 677 None. 679 5. Counters 681 5.1. Filter Counters Displayed Per Application 683 Capability. 685 If it is possible for a filter to be applied more than once at the 686 same time, then the device provides a mechanism to display filter 687 counters per filter application. 689 Supported Practices. 691 * Profile Current Traffic (Section 7.1) 693 * Respond to Incidents Based on Accurate Data (Section 7.4) 695 Current Implementations. 697 One way to implement this capability would be to have the counter 698 display mechanism show the interface (or other entity) to which 699 the filter has been applied, along with the name (or other 700 designator) for the filter. For example if a filter named 701 "desktop_outbound" is applied to two different interfaces, say, 702 "ethernet0" and "ethernet1", the display should indicate something 703 like "matches of filter 'desktop_outbound' on ethernet0 ..." and 704 "matches of filter 'desktop_outbound' on ethernet1 ..." 706 Considerations. 708 It may make sense to apply the same filter definition 709 simultaneously more than one time (to different interfaces, etc.). 710 If so, it would be much more useful to know which instance of a 711 filter is matching than to know that some instance was matching 712 somewhere. 714 5.2. Ability to Reset Filter Counters 716 Capability. 718 It is possible to reset individual counters to zero. 720 Supported Practices. 722 * Profile Current Traffic (Section 7.1) 724 * Respond to Incidents Based on Accurate Data (Section 7.4) 726 Current Implementations. 728 For the purposes of this capability it would be acceptable for the 729 system to maintain two counters: an "absolute counter", C[now], 730 and a "reset" counter, C[reset]. The absolute counter would 731 maintain counts that increase monotonically until they wrap or 732 overflow the counter. The reset counter would receive a copy of 733 the current value of the absolute counter when the reset function 734 was issued for that counter. Functions that display or retrieve 735 the counter could then display the delta (C[now] - C[reset]). 737 Considerations. 739 Assume that filter counters are being used to detect internal 740 hosts that are infected with a new worm. Once it is believed that 741 all infected hosts have been cleaned up and the worm removed, the 742 next step would be to verify that. One way of doing so would be 743 to reset the filter counters to zero and see if traffic indicative 744 of the worm has ceased. 746 5.3. Filter Hits are Counted 748 Capability. 750 The device supplies a facility for counting all filter matches. 752 Supported Practices. 754 * Profile Current Traffic (Section 7.1) 756 * Respond to Incidents Based on Accurate Data (Section 7.4) 758 Current Implementations. 760 Assume, for example, that a ISP network implements anti-spoofing 761 egress filters (see [RFC2827]) on interfaces of its edge routers 762 that support single-homed stub networks. Counters could enable 763 the ISP to detect cases where large numbers of spoofed packets are 764 being sent. This may indicate that the customer is performing 765 potentially malicious actions (possibly in violation of the ISPs 766 Acceptable Use Policy), or that system(s) on the customers network 767 have been "owned" by hackers and are being (mis)used to launch 768 attacks. 770 Considerations. 772 None. 774 5.4. Filter Counters are Accurate 776 Capability. 778 Filter counters are accurate. They reflect the actual number of 779 matching packets since the last counter reset. Filter counters 780 are be capable of holding up to 2^32 - 1 values without 781 overflowing and should be capable of holding up to 2^64 - 1 782 values. 784 Supported Practices. 786 * Respond to Incidents Based on Accurate Data (Section 7.4) 788 Current Implementations. 790 If N packets matching a filter are sent to/through a device, then 791 the counter should show N matches. 793 Considerations. 795 None. 797 6. Minimal Performance Degradation 799 Capability. 801 The device provides a means to filter packets without significant 802 performance degradation. This specifically applies to stateless 803 packet filtering operating on layer 3 (IP) and layer 4 (TCP or 804 UDP) headers, as well as normal packet forwarding information such 805 as incoming and outgoing interfaces. 807 The device is able to apply stateless packet filters on ALL 808 interfaces (up to the total number of interfaces attached to the 809 device) simultaneously and with multiple filters per interface 810 (e.g., inbound and outbound). 812 Supported Practices. 814 * Implement Filters Where Necessary (Section 7.5) 816 Current Implementations. 818 Another way of stating the capability is that filter performance 819 should not be the limiting factor in device throughput. If a 820 device is capable of forwarding 30Mb/sec without filtering, then 821 it should be able to forward the same amount with filtering in 822 place. 824 Considerations. 826 The definition of "significant" is subjective. At one end of the 827 spectrum it might mean "the application of filters may cause the 828 box to crash". At the other end would be a throughput loss of 829 less than one percent with tens of thousands of filters applied. 830 The level of performance degradation that is acceptable will have 831 to be determined by the operator. 833 Repeatable test data showing filter performance impact would be 834 very useful in evaluating this capability. Tests should include 835 such information as packet size, packet rate, number of interfaces 836 tested (source/destination), types of interfaces, routing table 837 size, routing protocols in use, frequency of routing updates, etc. 838 This capability does not address stateful filtering, filtering 839 above layer 4 headers or other more advanced types of filtering 840 that may be important in certain operational environments. 841 Finally, if key infrastructure devices crash or experience severe 842 performance degradation when filtering under heavy load, or even 843 have the reputation of doing so, it is likely that security 844 personnel will be forbidden, by policy, from using filtering in 845 ways that would otherwise be appropriate for fear that it might 846 cause unnecessary service disruption. 848 7. Additional Operational Practices 850 This section describes practices not covered in [RFC4778]. They are 851 included here to provide justification for capabilities that 852 reference them. 854 7.1. Profile Current Traffic 856 This capability allows a network operator to monitor traffic across 857 an active interface in the network at a minimal level. This helps to 858 determine probable cause for interface or network problems. 860 The ability to separate and distinguish traffic at a layer-3 or 861 layer-4 level allows the operator to characterize beyond simple 862 interface counters the traffic in question. This is critical because 863 often the operator has no tools available for protocol analysis aside 864 from interface filters. 866 7.2. Block Malicious Packets 868 Blocking or limiting traffic deemed to be malicious is a key 869 component of application of any security policy's implementation. 870 Clearly it is critical to be able to implement a security policy on a 871 network. 873 Malicious packets could potentially be defined by any part of, 874 atleast, the layer-3 or layer-4 headers of the IP packet. The 875 ability to classify or select traffic based on these criteria and 876 take some action based on that classification is critical to 877 operations of a network. 879 7.3. Limit Sources of Management 881 Management of a network should be limited to only trusted hosts. 882 This implies that the network elements will be able to limit access 883 to management functions to these trusted hosts. 885 Currently operators will limit access to the management functions on 886 a network device to only the hosts that are trusted to perform that 887 function. This allows separation of critical functions and 888 protection of those functions on the network devices. 890 7.4. Respond to Incidents Based on Accurate Data 892 Accurate counting of filter matches is important because it shows the 893 frequency of attempts to violate policy. Inaccurate data can not be 894 relied on as the basis for action. Under-reported data can conceal 895 the magnitude of a problem. This enables resources to be focused on 896 areas of greatest need. 898 7.5. Implement Filters Where Necessary 900 This enables the implementation of filters on whichever services are 901 necessary. To the extent that filtering causes degradation, it may 902 not be possible to apply filters that implement the appropriate 903 policies. 905 8. Security Considerations 907 General 908 Security is the subject matter of this entire memo. The 909 capabilities listed cite practices in [RFC4778] that they are 910 intended to support. [RFC4778] defines the threat model, 911 practices and lists justifications for each practice. 913 9. IANA Considerations 915 This document has no actions for IANA. 917 10. References 919 10.1. NormativeReferences 921 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, 922 May 2000. 924 10.2. Informational References 926 [I-D.lewis-infrastructure-security] 927 Lewis, D., "Service Provider Infrastructure Security", 928 draft-lewis-infrastructure-security-00 (work in progress), 929 June 2006. 931 [I-D.savola-rtgwg-backbone-attacks] 932 Savola, P., "Backbone Infrastructure Attacks and 933 Protections", draft-savola-rtgwg-backbone-attacks-03 (work 934 in progress), January 2007. 936 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 937 Defeating Denial of Service Attacks which employ IP Source 938 Address Spoofing", BCP 38, RFC 2827, May 2000. 940 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 941 RFC 2923, September 2000. 943 [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", 944 BCP 60, RFC 3360, August 2002. 946 [RFC3871] Jones, G., "Operational Security Requirements for Large 947 Internet Service Provider (ISP) IP Network 948 Infrastructure", RFC 3871, September 2004. 950 [RFC4778] Kaeo, M., "Operational Security Current Practices in 951 Internet Service Provider Environments", RFC 4778, 952 January 2007. 954 Appendix A. Acknowledgments 956 The authors gratefully acknowledge the contributions of: 958 o Merike Kaeo for help aligning these capabilities with supported 959 practices 961 Authors' Addresses 963 Christopher L. Morrow 964 UUNET Technologies 965 21830 UUNet Way 966 Ashburn, Virginia 21047 967 U.S.A. 969 Phone: +1 703 886 3823 970 Email: chris@uu.net 972 George M. Jones 973 Port111 Labs 975 Phone: +1 703 488 9740 976 Email: gmj3871@pobox.com 978 Vishwas Manral 979 IP Infusion 980 Ground Floor, 5th Cross Road, Off 8th Main Road 981 Bangalore, 52 982 India 984 Phone: +91-80-4113-1268 985 Email: vishwas@ipinfusion.com 987 Full Copyright Statement 989 Copyright (C) The IETF Trust (2007). 991 This document is subject to the rights, licenses and restrictions 992 contained in BCP 78, and except as set forth therein, the authors 993 retain all their rights. 995 This document and the information contained herein are provided on an 996 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 997 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 998 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 999 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1000 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1001 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1003 Intellectual Property 1005 The IETF takes no position regarding the validity or scope of any 1006 Intellectual Property Rights or other rights that might be claimed to 1007 pertain to the implementation or use of the technology described in 1008 this document or the extent to which any license under such rights 1009 might or might not be available; nor does it represent that it has 1010 made any independent effort to identify any such rights. Information 1011 on the procedures with respect to rights in RFC documents can be 1012 found in BCP 78 and BCP 79. 1014 Copies of IPR disclosures made to the IETF Secretariat and any 1015 assurances of licenses to be made available, or the result of an 1016 attempt made to obtain a general license or permission for the use of 1017 such proprietary rights by implementers or users of this 1018 specification can be obtained from the IETF on-line IPR repository at 1019 http://www.ietf.org/ipr. 1021 The IETF invites any interested party to bring to its attention any 1022 copyrights, patents or patent applications, or other proprietary 1023 rights that may cover technology that may be required to implement 1024 this standard. Please address the information to the IETF at 1025 ietf-ipr@ietf.org. 1027 Acknowledgment 1029 Funding for the RFC Editor function is provided by the IETF 1030 Administrative Support Activity (IASA).