--- 1/draft-ietf-opsec-filter-caps-08.txt 2007-07-13 20:12:10.000000000 +0200 +++ 2/draft-ietf-opsec-filter-caps-09.txt 2007-07-13 20:12:10.000000000 +0200 @@ -1,21 +1,21 @@ None. C. Morrow Internet-Draft UUNET Technologies Intended status: Best Current G. Jones Practice Port111 Labs -Expires: October 14, 2007 V. Manral +Expires: January 6, 2008 V. Manral IP Infusion - April 12, 2007 + July 5, 2007 Filtering and Rate Limiting Capabilities for IP Network Infrastructure - draft-ietf-opsec-filter-caps-08 + draft-ietf-opsec-filter-caps-09 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 October 14, 2007. + This Internet-Draft will expire on January 6, 2008. 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 @@ -130,21 +130,21 @@ 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. + model assumed in 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. 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. @@ -260,21 +260,21 @@ * 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 + address and/or source/destination port and allow these filters to be applied to interfaces. Considerations. This allows implementation of policies such as "Allow no more than 1Mb/s of ingress ICMP traffic on interface FOO". 3.2. Select Traffic on ALL Interfaces Capability. @@ -297,21 +297,21 @@ * 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 + 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 @@ -329,21 +329,21 @@ * Security Practices for Software Upgrades and Configuration Integrity/Validation ([RFC4778], Section 2.5.2) * Management Plane Filtering ([RFC4778], Section 2.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 + address and/or source/destination port and allow these filters to be applied to services offered by the device. 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. @@ -360,21 +360,21 @@ 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 that allow filtering based on protocol and/or source/destination - address and or source/destination port and allow these filters to + address and/or source/destination port and allow these filters to be applied to the interfaces on the device in order to protect assets attached to the network. Examples of this may include filtering all traffic save SMTP (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. @@ -408,23 +408,24 @@ It might be desirable on a border router, for example, to apply an 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. + makes the most sense. It allows traffic judged to be invalid or + malicious to be dropped as close to the source as possible with + the least impact on other traffic transiting the interface(s) in + question. 3.6. Select by Address, Protocol or Protocol Header Fields Capability. The device supports selection based on: * source IP address * destination IP address @@ -467,24 +468,27 @@ 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. 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. + the victim with ICMP traffic. One quick way to mitigate the + effects of such attacks is to drop all ICMP traffic headed toward + the victim. It should be noted ([RFC2923]) that one possibly + negative implication of filtering all ICMP traffic towards a + victim is that legitimate functions which rely upon successful + delivery of ICMP messages to the victim (e.g., ICMP unreachables, + Type-3 messages) will not be received by 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. @@ -525,26 +529,26 @@ Actions such as "permit", "reject", and "drop" are essential in defining the security policy for the services offered by the network devices. Considerations. While silently dropping traffic without sending notification may be the correct action in security terms, consideration should be given to operational implications. See [RFC3360] for consideration of potential problems caused by sending - inappropriate TCP Resets. + inappropriate TCP Resets, for instance. 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. + notifications to be sent (e.g. via 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 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 @@ -572,21 +576,21 @@ This capability allows a filter to be used to rate limit a portion of traffic through or to a device. It maybe desirable to limit SNMP (UDP/161) traffic to a device, but not deny it completely. Similarly, one might want to implement ICMP filters toward an external network instead of discarding all ICMP traffic. While silently dropping traffic without sending notification may be the correct action in security terms, consideration should be given to operational implications. See [RFC3360] for consideration of potential problems caused by sending - inappropriate TCP Resets. + inappropriate TCP Resets, for instance. 4.3. Specify Log Actions Capability. It is possible to log all filter actions. The logging capability is able to capture at least the following data: * permit/reject/drop status * source and destination IP address @@ -686,21 +690,21 @@ * Profile Current Traffic (Section 7.1) * Respond to Incidents Based on Accurate Data (Section 7.4) Current Implementations. One way to implement this capability would be to have the counter display mechanism show the interface (or other entity) to which the filter has been applied, along with the name (or other designator) for the filter. For example if a filter named - "desktop_outbound" applied two different interfaces, say, + "desktop_outbound" is applied to two different interfaces, say, "ethernet0" and "ethernet1", the display should indicate something like "matches of filter 'desktop_outbound' on ethernet0 ..." and "matches of filter 'desktop_outbound' on ethernet1 ..." Considerations. 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 @@ -857,24 +861,25 @@ often the operator has no tools available for protocol analysis aside from interface filters. 7.2. Block Malicious Packets Blocking or limiting traffic deemed to be malicious is a key component of application of any security policy's implementation. Clearly it is critical to be able to implement a security policy on a network. - Malicious packets could potentially be defined by any part of the - layer-3 or layer-4 headers of the IP packet. The ability to classify - or select traffic based on these criteria and take some action based - on that classification is critical to operations of a network. + Malicious packets could potentially be defined by any part of, + atleast, the layer-3 or layer-4 headers of the IP packet. The + ability to classify or select traffic based on these criteria and + take some action based on that classification is critical to + operations of a network. 7.3. Limit Sources of Management Management of a network should be limited to only trusted hosts. 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 @@ -923,20 +928,23 @@ [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. + [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", + RFC 2923, September 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.