--- 1/draft-ietf-opsec-filter-caps-06.txt 2007-05-29 22:12:13.000000000 +0200 +++ 2/draft-ietf-opsec-filter-caps-07.txt 2007-05-29 22:12:13.000000000 +0200 @@ -1,21 +1,21 @@ None. C. Morrow Internet-Draft UUNET Technologies Intended status: Informational G. Jones -Expires: September 22, 2007 +Expires: October 14, 2007 Port111 Labs V. Manral IP Infusion - March 21, 2007 + April 12, 2007 Filtering and Rate Limiting Capabilities for IP Network Infrastructure - draft-ietf-opsec-filter-caps-06 + draft-ietf-opsec-filter-caps-07 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -26,21 +26,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on September 22, 2007. + This Internet-Draft will expire on October 14, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract [RFC4778] lists operator practices related to securing networks. This document lists filtering and rate limiting capabilities needed to support those practices. Capabilities are limited to filtering @@ -53,114 +53,118 @@ implement the capability. Each capability cites the practices it supports. Current implementations that support the capability are cited. Special considerations are discussed as appropriate listing operational and resource constraints, limitations of current implementations, trade-offs, etc. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Packet Selection for Management and Data Plane Controls . . . 6 - 3. Packet Selection Criteria . . . . . . . . . . . . . . . . . . 7 - 3.1. Select Traffic on All Interfaces . . . . . . . . . . . . . 7 - 3.2. Select Traffic To the Device . . . . . . . . . . . . . . . 7 - 3.3. Select Transit Traffic . . . . . . . . . . . . . . . . . . 8 - 3.4. Select Inbound and/or Outbound . . . . . . . . . . . . . . 9 - 3.5. Select by Protocols . . . . . . . . . . . . . . . . . . . 10 - 3.6. Select by Addresses . . . . . . . . . . . . . . . . . . . 10 - 3.7. Select by Protocol Header Fields . . . . . . . . . . . . . 11 - 4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 4.1. Specify Filter Actions . . . . . . . . . . . . . . . . . . 13 - 4.2. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 13 - 4.3. Specify Log Actions . . . . . . . . . . . . . . . . . . . 14 - 4.4. Specify Log Granularity . . . . . . . . . . . . . . . . . 15 - 4.5. Ability to Display Filter Counters . . . . . . . . . . . . 16 - 5. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 5.1. Filter Counters Displayed Per Application . . . . . . . . 17 - 5.2. Ability to Reset Filter Counters . . . . . . . . . . . . . 17 - 5.3. Filter Hits are Counted . . . . . . . . . . . . . . . . . 18 - 5.4. Filter Counters are Accurate . . . . . . . . . . . . . . . 19 - 6. Minimal Performance Degradation . . . . . . . . . . . . . . . 20 - 7. Additional Operational Practices . . . . . . . . . . . . . . . 22 - 7.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 22 - 7.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 22 - 7.3. Limit Sources of Management . . . . . . . . . . . . . . . 22 - 7.4. Respond to Incidents Based on Accurate Data . . . . . . . 22 - 7.5. Implement Filters Where Necessary . . . . . . . . . . . . 23 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 - 10. Non-normative References . . . . . . . . . . . . . . . . . . . 26 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 27 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 - Intellectual Property and Copyright Statements . . . . . . . . . . 29 + 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Traffic Types, Rules and Filters . . . . . . . . . . . . . . . 6 + 3. Packet Selection Criteria . . . . . . . . . . . . . . . . . . 8 + 3.1. Select Traffic on ANY Interface . . . . . . . . . . . . . 8 + 3.2. Select Traffic on ALL Interfaces . . . . . . . . . . . . . 8 + 3.3. Select Traffic To the Device . . . . . . . . . . . . . . . 9 + 3.4. Select Transit Traffic . . . . . . . . . . . . . . . . . . 10 + 3.5. Select Inbound and/or Outbound . . . . . . . . . . . . . . 11 + 3.6. Select by Address, Protocol or Protocol Header Fields . . 12 + 4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 4.1. Specify Filter Actions . . . . . . . . . . . . . . . . . . 14 + 4.2. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 15 + 4.3. Specify Log Actions . . . . . . . . . . . . . . . . . . . 15 + 4.4. Specify Log Granularity . . . . . . . . . . . . . . . . . 16 + 4.5. Ability to Display Filter Counters . . . . . . . . . . . . 17 + 5. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 5.1. Filter Counters Displayed Per Application . . . . . . . . 18 + 5.2. Ability to Reset Filter Counters . . . . . . . . . . . . . 18 + 5.3. Filter Hits are Counted . . . . . . . . . . . . . . . . . 19 + 5.4. Filter Counters are Accurate . . . . . . . . . . . . . . . 20 + 6. Minimal Performance Degradation . . . . . . . . . . . . . . . 21 + 7. Additional Operational Practices . . . . . . . . . . . . . . . 23 + 7.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 23 + 7.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 23 + 7.3. Limit Sources of Management . . . . . . . . . . . . . . . 23 + 7.4. Respond to Incidents Based on Accurate Data . . . . . . . 23 + 7.5. Implement Filters Where Necessary . . . . . . . . . . . . 24 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 10.1. NormativeReferences . . . . . . . . . . . . . . . . . . . 27 + 10.2. Informational References . . . . . . . . . . . . . . . . . 27 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 28 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 + Intellectual Property and Copyright Statements . . . . . . . . . . 30 1. Introduction This document is defined in the context of [RFC4778]. [RFC4778] defines the goals, motivation, scope, definitions, intended audience, - threat model, potential attacks and give justifications for each of + threat model, potential attacks and gives justifications for each of the practices. Many of the capabilities listed here refine or add to capabilities listed in [RFC3871]. Also see [I-D.lewis-infrastructure-security] for a useful description of techniques for protecting infrastructure devices, including the use of filtering. 1.1. Threat Model Threats in today's networked environment range from simple packet floods with overwhelming bandwidth toward a leaf network to subtle attacks aimed at subverting known vulnerabilities in existing - applications. The attacked network or host might not be an end user, - it may be the networking device or links inside the provider core. + applications. The target of the attack may be the networking device + or links inside the provider core. - Networks must have the ability to place mitigation in order to limit + Networks must have the ability to mitigate attacks in order to limit these threats. These mitigation steps could include routing updates, traffic filters, and routing filters. It is possible that the mitigation steps might have to affect transit traffic as well as traffic destined to the device on which the mitigation steps are activated. The scope of the threat includes simply denying services to an individual customer on one side of the scale to exploiting a newly discovered protocol vulnerability which affects the entire provider core. The obvious risk to the business requires mitigation capabilities which can span this range of threats. + Also see [I-D.savola-rtgwg-backbone-attacks] for a list of attacks on + backbone devices and counter measures. + +1.2. Definitions + + Terms are used as defined in [RFC2828]. The following definitions + are intended to add clarification specific the context and threat + model of this document. + Threat: An indication of impending danger or harm to the network or its parts. This could be formed from the projected loss of revenue to the business. Additionally, it could be formed from the increased - cost to the business caused by the event. (more interfaces, more - bandwidth, more personnel to support the increased size or - complexity) + cost to the business caused by the event. The increased costs could + come from the need for more interfaces, more bandwidth, more + personnel to support the increased size or complexity, etc. Risk: The possibility of suffering harm or loss of network services due to a threat. - Attack: To set upon with violent force the network or its parts. - Typically this is a form of flood of packets to or through a network. - This could also be a much smaller stream of packets created with the - intent of exploiting a vulnerability in the infrastructure of the - network. + Attack: Typically this is a form of flood of packets to or through a + network. This could also be a much smaller stream of packets created + with the intent of exploiting a vulnerability in the infrastructure + of the network. Asset: Either a customer, network device or network link. Any of these could be assets from a business perspective. - These terms are more completely defined in [RFC2828] we have added - some scope specific information only. - - Also see [I-D.savola-rtgwg-backbone-attacks] for a list of attacks on - backbone devices and counter measures. - -1.2. Format +1.3. Format Each capability has the following subsections: o Capability (what) o Supported Practices (why) o Current Implementations (how) o Considerations (caveats, resource issues, protocol issues, etc.) @@ -168,49 +172,85 @@ The Capability section describes a feature to be supported by the device. The Supported Practice section cites practices described in [RFC4778] that are supported by this capability. The Current Implementation section is intended to give examples of implementations of the capability, citing technology and standards current at the time of writing. It is expected that the choice of features to implement the capabilities will change over time. The Considerations section lists operational and resource constraints, limitations of current implementations, trade-offs, etc. -2. Packet Selection for Management and Data Plane Controls +2. Traffic Types, Rules and Filters - In this document Section 3 describes a number of criteria for - performing packet selection. It is assumed in this document that + This document describes capabilities that enable routers to filter + transit, control and management traffic. - o all of these criteria can be used to select packets for both - filtering and rate limiting packets, + Transit traffic is traffic that passes through a router, but does not + otherwise impact the behavior of that router. Routers filter transit + traffic by applying "filters" to interfaces. For any given + interface, a filter can be applied to inbound traffic, outbound + traffic or both. - o management plane controls can be implemented by applying these - criteria to filter/rate limit traffic destined for the device - itself, + Control and management traffic either originates on the router or is + destined for the router. Routers filter control and management + traffic by applying one or more filters to all of their interfaces, + as an aggregate. Aggregation permits the router to select any + control packet, regardless of the interface upon which it arrives. + So, the router can enforce a filter like the one that follows: "The + router will accept only 1mbps of telnet traffic, regardless of the + interface(s) upon which that traffic arrives." - o data plane controls can be implemented by applying these criteria - to filter/rate limit traffic destined through the device + A "Filter" is a list of one or more rules that may be applied as a + group. - o multiple packet selection criteria can be used to select a single - set of packets for filtering action + A rule consists of the following: + + o selection criteria + + o actions + + Selection criteria identify the packets that will be impacted by this + rule. Section 3 of this document describes selection criteria in + detail. + + Actions define treatment that will be afforded to packets meeting the + selection criteria. An action can include the following: + + o forwarding treatment + + o logging treatment + + o accounting treatment + + Forwarding behaviors include the following: + + o accept + + o accept but rate limit + o reject (discard and emit ICMP message) + + o silently discard + + Section 4 describes actions in detail. Section 5 describes counter + actions in detail. 3. Packet Selection Criteria This section lists packet selection criteria that can be applied to both filtering and rate limiting. -3.1. Select Traffic on All Interfaces +3.1. Select Traffic on ANY Interface Capability. - The device provides a means to filter IP packets on any interface - implementing IP. + The device provides a means to select IP packets on any individual + interface implementing IP. Supported Practices. * Security Practices for Device Management ([RFC4778], Section 2.2.2) * Security Practices for Data Path ([RFC4778], Section 2.3.2) * Security Practices for Software Upgrades and Configuration Integrity/Validation ([RFC4778], Section 2.5.2) @@ -225,29 +265,69 @@ Current Implementations. Many devices currently implement access control lists or filters that allow filtering based on protocol and/or source/destination address and or source/destination port and allow these filters to be applied to interfaces. Considerations. - None. + This allows implementation of policies such as "Allow no more than + 1Mb/s of ingress ICMP traffic on interface FOO". -3.2. Select Traffic To the Device +3.2. Select Traffic on ALL Interfaces + Capability. + + The device provides a means to select IP packets on any interface + implementing IP. The mechanism should support a shorthand + notation representing all interfaces on the router. + + Supported Practices. + + * Security Practices for Device Management ([RFC4778], Section + 2.2.2) + + * Security Practices for Data Path ([RFC4778], Section 2.3.2) + + * Security Practices for Software Upgrades and Configuration + Integrity/Validation ([RFC4778], Section 2.5.2) + + * Data Plane Filtering ([RFC4778], Section 2.7.1) + + * Management Plane Filtering ([RFC4778], Section 2.7.2) + + * Profile Current Traffic (Section 7.1) + + * Block Malicious Packets (Section 7.2) + + Current Implementations. + + Many devices currently implement access control lists or filters + that allow filtering based on protocol and/or source/destination + address and or source/destination port and allow these filters to + be applied to all interfaces. + + Considerations. + + This allows implementation of policies such as "Allow no more than + 1Mb/s of ingress ICMP traffic combined on all interfaces on the + device". + +3.3. Select Traffic To the Device Capability. - It is possible to apply the filtering mechanism to traffic that is - addressed directly to the device via any of its interfaces - - including loopback interfaces. + It is possible to select traffic that is addressed directly to the + device via any of its interfaces - including loopback interfaces. + The mechanism should support a shorthand notation representing all + interfaces on that router. Supported Practices. * Security Practices for Device Management ([RFC4778], Section 2.2.2) * Security Practices for Software Upgrades and Configuration Integrity/Validation ([RFC4778], Section 2.5.2) * Management Plane Filtering ([RFC4778], Section 2.7.2) @@ -261,26 +341,28 @@ Examples of this might include filters that permit only BGP from peers and SNMP and SSH from an authorized management segment and directed to the device itself, while dropping all other traffic addressed to the device. Considerations. None. -3.3. Select Transit Traffic +3.4. Select Transit Traffic Capability. - It is possible to apply the filtering mechanism to traffic that - will transit the device via any of its interfaces. + It is possible to select traffic that will transit the device via + any of its interfaces. The mechanism should support a shorthand + notation representing traffic not addressed to any of the routers + interfaces. Supported Practices. * Security Practices for Data Path ([RFC4778], Section 2.3.2) * Data Plane Filtering ([RFC4778], Section 2.7.1) Current Implementations. Many devices currently implement access control lists or filters @@ -293,136 +375,84 @@ (tcp/25) destined to a mail server. A common use of this today would also be denying all traffic to a destination which has been determined to be hostile. Considerations. This allows the operator to apply filters that protect the networks and assets surrounding the device from attacks and unauthorized access. -3.4. Select Inbound and/or Outbound +3.5. Select Inbound and/or Outbound Capability. - It is possible to filter both incoming and outgoing traffic on any + It is possible to select both incoming and outgoing traffic on any interface. Supported Practices. * Security Practices for Device Management ([RFC4778], Section 2.2.2) * Security Practices for Data Path ([RFC4778], Section 2.3.2) * Security Practices for Software Upgrades and Configuration Integrity/Validation ([RFC4778], Section 2.5.2) * Data Plane Filtering ([RFC4778], Section 2.7.1) * Management Plane Filtering ([RFC4778], Section 2.7.2) Current Implementations. It might be desirable on a border router, for example, to apply an - egress filter outbound on the interface that connects a site to - its external ISP to drop outbound traffic that does not have a - valid internal source address. Inbound, it might be desirable to - apply a filter that blocks all traffic from a site that is known - to forward or originate large amounts of junk mail. + egress filter on the interface that connects a site to its + external ISP to drop outbound traffic that does not have a valid + internal source address. Inbound, it might be desirable to apply + a filter that blocks all traffic from a site that is known to + forward or originate large amounts of junk mail. Considerations. This allows flexibility in applying filters at the place that makes the most sense. It allows invalid or malicious traffic to be dropped as close to the source as possible with the least impact on other traffic transiting the interface(s) in question. -3.5. Select by Protocols - - Capability. - - The device provides a means to filter traffic based on the value - of the protocol field in the IP header. - - Supported Practices. - - * Security Practices for Device Management ([RFC4778], Section - 2.2.2) - - * Security Practices for Data Path ([RFC4778], Section 2.3.2) - - * Security Practices for Software Upgrades and Configuration - Integrity/Validation ([RFC4778],Section 2.5.2) - - * Data Plane Filtering ([RFC4778], Section 2.7.1) - - * Management Plane Filtering ([RFC4778], Section 2.7.2) - - Current Implementations. - - Some denial of service attacks are based on the ability to flood - the victim with ICMP traffic. One quick way (admittedly with some - negative side effects) to mitigate the effects of such attacks is - to drop all ICMP traffic headed toward the victim. - - Considerations. - - Being able to filter on protocol is necessary to allow - implementation of policy, secure operations and for support of - incident response. Filtering all traffic to a destination host is - not often possible, business requirements will dictate that - critical traffic be permitted if at all possible. - -3.6. Select by Addresses +3.6. Select by Address, Protocol or Protocol Header Fields Capability. - The device is able to control the flow of traffic based on source - and/or destination IP address or blocks of addresses such as - Classless Inter-Domain Routing (CIDR) blocks. - - Supported Practices. - - * Security Practices for Device Management ([RFC4778], Section - 2.2.2) - * Security Practices for Data Path ([RFC4778], Section 2.3.2) - - * Security Practices for Software Upgrades and Configuration - Integrity/Validation ([RFC4778], Section 2.5.2 - - * Data Plane Filtering ([RFC4778], Section 2.7.1) + The device supports selection based on: - * Management Plane Filtering ([RFC4778], Section 2.7.2) + * source IP address - Current Implementations. + * destination IP address - One example of the use of address based filtering is to implement - ingress filtering per [RFC2827] + * source port - Considerations. + * destination port - The capability to filter on addresses and address blocks is a - fundamental tool for establishing boundaries between different - networks. + * protocol ID -3.7. Select by Protocol Header Fields + * TCP flags (SYN, ACK, RST) - Capability. + * DiffServ Code Point (DSCP) - The filtering mechanism supports filtering based on the value(s) - of any portion of the protocol headers for IP, ICMP, UDP and TCP - by specifying fields by name (e.g., "protocol = ICMP") rather than - bit- offset/length/numeric value (e.g., 72:8 = 1). + * the value(s) of any portion of the protocol headers for IP, + ICMP, UDP and TCP by specifying fields by name (e.g., "protocol + = ICMP") rather than bit- offset/length/numeric value (e.g., + 72:8 = 1). - It supports arbitrary header-based filtering (possibly using bit- - offset/length/value) of all other protocols. + * Arbitrary header-based selection (possibly using bit-offset/ + length/value) of all other protocols. Supported Practices. * Security Practices for Device Management ([RFC4778], Section 2.2.2) * Security Practices for Data Path ([RFC4778], Section 2.3.2) * Security Practices for Software Upgrades and Configuration Integrity/Validation ([RFC4778], Section 2.5.2) @@ -435,41 +466,56 @@ This capability implies that it is possible to filter based on TCP or UDP port numbers, TCP flags such as SYN, ACK and RST bits, and ICMP type and code fields. One common example is to reject "inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear or SYN bit set+ACK,FIN and RST bits clear). Another common example is the ability to control what services are allowed in/out of a network. It may be desirable to only allow inbound connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting web servers. - Supporting arbitrary offset/length/value filtering allows + Some denial of service attacks are based on the ability to flood + the victim with ICMP traffic. One quick way (admittedly with some + negative side effects, e.g. breaking path MTU discovery) to + mitigate the effects of such attacks is to drop all ICMP traffic + headed toward the victim. + + Supporting arbitrary offset/length/value selection allows filtering of unknown (possibly new) protocols, e.g. filtering RTP even when the device itself does not support RTP. Considerations. + The capability to filter on addresses, address blocks and + protocols is a fundamental tool for establishing boundaries + between different networks. + Being able to filter on portions of the header is necessary to allow implementation of policy, secure operations, and support incident response. 4. Actions 4.1. Specify Filter Actions Capability. - The device provides a mechanism to allow the specification of the - action to be taken when a filter rule matches. Actions include - "permit" (allow the traffic), "reject" (drop with appropriate - notification to sender), and "drop" (drop with no notification to - sender). + The device provides a mechanism through which operators can + specify a forwarding action to be taken when the selection + criteria is met. Forwarding actions include the following: + + * permit (allow the datagram) + + * discard (silently discard the datagram) + + * reject (discard the datagram and send a notification to its + originator) Supported Practices. * Data Origin Authentication ([RFC4778], Section 2.3.3) Current Implementations. Assume that your management devices for deployed networking devices live on several subnets, use several protocols, and are controlled by several different parts of your organization. There @@ -491,25 +537,25 @@ Also note that it might be possible for an attacker to effect a denial of service attack by causing too many rejection notifications to be sent (e.g. syslog messages). For this reason it might be desirable to rate-limit notifications. 4.2. Specify Rate Limits Capability. The device provides a mechanism to allow the specification of the - action to be taken when a rate limiting filter rule matches. The + action to be taken when a rate limiting filter matches. The actions include "transmit" (permit the traffic because it's below the specified limit), "limit" (limit traffic because it exceeds the specified limit). Limits should be applicable by both bits - per second and packets per timeframe (possible timeframes might + per second and packets per time-frame (possible time-frames might include second, minute, hour). Limits should able to be placed in both inbound and outbound directions. Supported Practices. * Denial of Service Tracking/Tracing with Rate Limiting ([RFC4778], Section 2.8.4) Current Implementations. @@ -569,32 +615,32 @@ offered on the device. Also note logging itself can be rate limited so as to not cause performance degradation of the device or the network(in case of syslog or other similar network logging mechanism. 4.4. Specify Log Granularity Capability. - It is possible to enable/disable logging on a per rule basis. + The device provides a mechanism through which operators can + enable/disable logging on a per rule basis. Supported Practices. * Logging Security Practices([RFC4778], Section 2.6.2) - Current Implementations. If a filter is defined that has several rules, and one of the - rules denies telnet (tcp/23) connections, then it should be - possible to specify that only matches on the rule that denies - telnet should generate a log message. + rules specifies an action that denies telnet (tcp/23) connections, + then it should be possible to specify that only matches on the + rule that denies telnet should generate a log message. Considerations. The ability to tune the granularity of logging allows the operator to log the information that is desired and only the information that is desired. Without this capability, it is possible that extra data (or none at all) would be logged, making it more difficult to find relevant information. 4.5. Ability to Display Filter Counters @@ -657,21 +703,21 @@ It may make sense to apply the same filter definition simultaneously more than one time (to different interfaces, etc.). If so, it would be much more useful to know which instance of a filter is matching than to know that some instance was matching somewhere. 5.2. Ability to Reset Filter Counters Capability. - It is possible to reset counters to zero on a per filter basis. + It is possible to reset individual counters to zero. Supported Practices. * Profile Current Traffic (Section 7.1) * Respond to Incidents Based on Accurate Data (Section 7.4) Current Implementations. For the purposes of this capability it would be acceptable for the system to maintain two counters: an "absolute counter", C[now], @@ -829,64 +875,68 @@ This implies that the network elements will be able to limit access to management functions to these trusted hosts. Currently operators will limit access to the management functions on a network device to only the hosts that are trusted to perform that function. This allows separation of critical functions and protection of those functions on the network devices. 7.4. Respond to Incidents Based on Accurate Data - Accurate counting of filter rule matches is important because it - shows the frequency of attempts to violate policy. Inaccurate data - can not be relied on as the basis for action. Under-reported data - can conceal the magnitude of a problem. This enables resources to be - focused on areas of greatest need. + Accurate counting of filter matches is important because it shows the + frequency of attempts to violate policy. Inaccurate data can not be + relied on as the basis for action. Under-reported data can conceal + the magnitude of a problem. This enables resources to be focused on + areas of greatest need. 7.5. Implement Filters Where Necessary This enables the implementation of filters on whichever services are necessary. To the extent that filtering causes degradation, it may not be possible to apply filters that implement the appropriate policies. 8. Security Considerations General Security is the subject matter of this entire memo. The capabilities listed cite practices in [RFC4778] that they are intended to support. [RFC4778] defines the threat model, practices and lists justifications for each practice. 9. IANA Considerations This document has no actions for IANA. -10. Non-normative References +10. References + +10.1. NormativeReferences + + [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, + May 2000. + +10.2. Informational References [I-D.lewis-infrastructure-security] Lewis, D., "Service Provider Infrastructure Security", draft-lewis-infrastructure-security-00 (work in progress), June 2006. [I-D.savola-rtgwg-backbone-attacks] Savola, P., "Backbone Infrastructure Attacks and Protections", draft-savola-rtgwg-backbone-attacks-03 (work in progress), January 2007. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. - [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, - May 2000. - [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002. [RFC3871] Jones, G., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, September 2004. [RFC4778] Kaeo, M., "Operational Security Current Practices in Internet Service Provider Environments", RFC 4778, January 2007. @@ -903,20 +953,21 @@ Christopher L. Morrow UUNET Technologies 21830 UUNet Way Ashburn, Virginia 21047 U.S.A. Phone: +1 703 886 3823 Email: chris@uu.net George M. Jones + Port111 Labs Phone: +1 703 488 9740 Email: gmj3871@pobox.com Vishwas Manral IP Infusion Ground Floor, 5th Cross Road, Off 8th Main Road Bangalore, 52 India