draft-ietf-opsec-filter-caps-08.txt   draft-ietf-opsec-filter-caps-09.txt 
None. C. Morrow None. C. Morrow
Internet-Draft UUNET Technologies Internet-Draft UUNET Technologies
Intended status: Best Current G. Jones Intended status: Best Current G. Jones
Practice Port111 Labs Practice Port111 Labs
Expires: October 14, 2007 V. Manral Expires: January 6, 2008 V. Manral
IP Infusion IP Infusion
April 12, 2007 July 5, 2007
Filtering and Rate Limiting Capabilities for IP Network Infrastructure 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 Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
[RFC4778] lists operator practices related to securing networks. [RFC4778] lists operator practices related to securing networks.
This document lists filtering and rate limiting capabilities needed This document lists filtering and rate limiting capabilities needed
to support those practices. Capabilities are limited to filtering to support those practices. Capabilities are limited to filtering
skipping to change at page 4, line 45 skipping to change at page 4, line 45
core. The obvious risk to the business requires mitigation core. The obvious risk to the business requires mitigation
capabilities which can span this range of threats. capabilities which can span this range of threats.
Also see [I-D.savola-rtgwg-backbone-attacks] for a list of attacks on Also see [I-D.savola-rtgwg-backbone-attacks] for a list of attacks on
backbone devices and counter measures. backbone devices and counter measures.
1.2. Definitions 1.2. Definitions
Terms are used as defined in [RFC2828]. The following definitions Terms are used as defined in [RFC2828]. The following definitions
are intended to add clarification specific the context and threat 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 Threat: An indication of impending danger or harm to the network or
its parts. This could be formed from the projected loss of revenue its parts. This could be formed from the projected loss of revenue
to the business. Additionally, it could be formed from the increased to the business. Additionally, it could be formed from the increased
cost to the business caused by the event. The increased costs could cost to the business caused by the event. The increased costs could
come from the need for more interfaces, more bandwidth, more come from the need for more interfaces, more bandwidth, more
personnel to support the increased size or complexity, etc. personnel to support the increased size or complexity, etc.
Risk: The possibility of suffering harm or loss of network services Risk: The possibility of suffering harm or loss of network services
due to a threat. due to a threat.
skipping to change at page 8, line 39 skipping to change at page 8, line 39
* Management Plane Filtering ([RFC4778], Section 2.7.2) * Management Plane Filtering ([RFC4778], Section 2.7.2)
* Profile Current Traffic (Section 7.1) * Profile Current Traffic (Section 7.1)
* Block Malicious Packets (Section 7.2) * Block Malicious Packets (Section 7.2)
Current Implementations. Current Implementations.
Many devices currently implement access control lists or filters Many devices currently implement access control lists or filters
that allow filtering based on protocol and/or source/destination 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. be applied to interfaces.
Considerations. Considerations.
This allows implementation of policies such as "Allow no more than This allows implementation of policies such as "Allow no more than
1Mb/s of ingress ICMP traffic on interface FOO". 1Mb/s of ingress ICMP traffic on interface FOO".
3.2. Select Traffic on ALL Interfaces 3.2. Select Traffic on ALL Interfaces
Capability. Capability.
skipping to change at page 9, line 32 skipping to change at page 9, line 32
* Management Plane Filtering ([RFC4778], Section 2.7.2) * Management Plane Filtering ([RFC4778], Section 2.7.2)
* Profile Current Traffic (Section 7.1) * Profile Current Traffic (Section 7.1)
* Block Malicious Packets (Section 7.2) * Block Malicious Packets (Section 7.2)
Current Implementations. Current Implementations.
Many devices currently implement access control lists or filters Many devices currently implement access control lists or filters
that allow filtering based on protocol and/or source/destination 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. be applied to all interfaces.
Considerations. Considerations.
This allows implementation of policies such as "Allow no more than This allows implementation of policies such as "Allow no more than
1Mb/s of ingress ICMP traffic combined on all interfaces on the 1Mb/s of ingress ICMP traffic combined on all interfaces on the
device". device".
3.3. Select Traffic To the Device 3.3. Select Traffic To the Device
skipping to change at page 10, line 19 skipping to change at page 10, line 19
* Security Practices for Software Upgrades and Configuration * Security Practices for Software Upgrades and Configuration
Integrity/Validation ([RFC4778], Section 2.5.2) Integrity/Validation ([RFC4778], Section 2.5.2)
* Management Plane Filtering ([RFC4778], Section 2.7.2) * Management Plane Filtering ([RFC4778], Section 2.7.2)
Current Implementations. Current Implementations.
Many devices currently implement access control lists or filters Many devices currently implement access control lists or filters
that allow filtering based on protocol and/or source/destination 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. be applied to services offered by the device.
Examples of this might include filters that permit only BGP from Examples of this might include filters that permit only BGP from
peers and SNMP and SSH from an authorized management segment and peers and SNMP and SSH from an authorized management segment and
directed to the device itself, while dropping all other traffic directed to the device itself, while dropping all other traffic
addressed to the device. addressed to the device.
Considerations. Considerations.
None. None.
skipping to change at page 10, line 50 skipping to change at page 10, line 50
Supported Practices. Supported Practices.
* Security Practices for Data Path ([RFC4778], Section 2.3.2) * Security Practices for Data Path ([RFC4778], Section 2.3.2)
* Data Plane Filtering ([RFC4778], Section 2.7.1) * Data Plane Filtering ([RFC4778], Section 2.7.1)
Current Implementations. Current Implementations.
Many devices currently implement access control lists or filters Many devices currently implement access control lists or filters
that allow filtering based on protocol and/or source/destination 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 be applied to the interfaces on the device in order to protect
assets attached to the network. assets attached to the network.
Examples of this may include filtering all traffic save SMTP Examples of this may include filtering all traffic save SMTP
(tcp/25) destined to a mail server. A common use of this today (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 would also be denying all traffic to a destination which has been
determined to be hostile. determined to be hostile.
Considerations. Considerations.
skipping to change at page 11, line 49 skipping to change at page 11, line 49
It might be desirable on a border router, for example, to apply an It might be desirable on a border router, for example, to apply an
egress filter on the interface that connects a site to its egress filter on the interface that connects a site to its
external ISP to drop outbound traffic that does not have a valid external ISP to drop outbound traffic that does not have a valid
internal source address. Inbound, it might be desirable to apply internal source address. Inbound, it might be desirable to apply
a filter that blocks all traffic from a site that is known to a filter that blocks all traffic from a site that is known to
forward or originate large amounts of junk mail. forward or originate large amounts of junk mail.
Considerations. Considerations.
This allows flexibility in applying filters at the place that This allows flexibility in applying filters at the place that
makes the most sense. It allows invalid or malicious traffic to makes the most sense. It allows traffic judged to be invalid or
be dropped as close to the source as possible with the least malicious to be dropped as close to the source as possible with
impact on other traffic transiting the interface(s) in question. the least impact on other traffic transiting the interface(s) in
question.
3.6. Select by Address, Protocol or Protocol Header Fields 3.6. Select by Address, Protocol or Protocol Header Fields
Capability. Capability.
The device supports selection based on: The device supports selection based on:
* source IP address * source IP address
* destination IP address * destination IP address
skipping to change at page 13, line 11 skipping to change at page 13, line 11
or UDP port numbers, TCP flags such as SYN, ACK and RST bits, and 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 ICMP type and code fields. One common example is to reject
"inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear "inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear
or SYN bit set+ACK,FIN and RST bits clear). Another common or SYN bit set+ACK,FIN and RST bits clear). Another common
example is the ability to control what services are allowed in/out example is the ability to control what services are allowed in/out
of a network. It may be desirable to only allow inbound of a network. It may be desirable to only allow inbound
connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting
web servers. web servers.
Some denial of service attacks are based on the ability to flood Some denial of service attacks are based on the ability to flood
the victim with ICMP traffic. One quick way (admittedly with some the victim with ICMP traffic. One quick way to mitigate the
negative side effects, e.g. breaking path MTU discovery) to effects of such attacks is to drop all ICMP traffic headed toward
mitigate the effects of such attacks is to drop all ICMP traffic the victim. It should be noted ([RFC2923]) that one possibly
headed toward the victim. 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 Supporting arbitrary offset/length/value selection allows
filtering of unknown (possibly new) protocols, e.g. filtering RTP filtering of unknown (possibly new) protocols, e.g. filtering RTP
even when the device itself does not support RTP. even when the device itself does not support RTP.
Considerations. Considerations.
The capability to filter on addresses, address blocks and The capability to filter on addresses, address blocks and
protocols is a fundamental tool for establishing boundaries protocols is a fundamental tool for establishing boundaries
between different networks. between different networks.
skipping to change at page 14, line 44 skipping to change at page 14, line 44
Actions such as "permit", "reject", and "drop" are essential in Actions such as "permit", "reject", and "drop" are essential in
defining the security policy for the services offered by the defining the security policy for the services offered by the
network devices. network devices.
Considerations. Considerations.
While silently dropping traffic without sending notification may While silently dropping traffic without sending notification may
be the correct action in security terms, consideration should be be the correct action in security terms, consideration should be
given to operational implications. See [RFC3360] for given to operational implications. See [RFC3360] for
consideration of potential problems caused by sending 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 Also note that it might be possible for an attacker to effect a
denial of service attack by causing too many rejection denial of service attack by causing too many rejection
notifications to be sent (e.g. syslog messages). For this reason notifications to be sent (e.g. via syslog messages). For this
it might be desirable to rate-limit notifications. reason it might be desirable to rate-limit notifications.
4.2. Specify Rate Limits 4.2. Specify Rate Limits
Capability. Capability.
The device provides a mechanism to allow the specification of the The device provides a mechanism to allow the specification of the
action to be taken when a rate limiting filter matches. The action to be taken when a rate limiting filter matches. The
actions include "transmit" (permit the traffic because it's below actions include "transmit" (permit the traffic because it's below
the specified limit), "limit" (limit traffic because it exceeds the specified limit), "limit" (limit traffic because it exceeds
the specified limit). Limits should be applicable by both bits the specified limit). Limits should be applicable by both bits
skipping to change at page 15, line 45 skipping to change at page 15, line 45
This capability allows a filter to be used to rate limit a portion 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 of traffic through or to a device. It maybe desirable to limit
SNMP (UDP/161) traffic to a device, but not deny it completely. SNMP (UDP/161) traffic to a device, but not deny it completely.
Similarly, one might want to implement ICMP filters toward an Similarly, one might want to implement ICMP filters toward an
external network instead of discarding all ICMP traffic. external network instead of discarding all ICMP traffic.
While silently dropping traffic without sending notification may While silently dropping traffic without sending notification may
be the correct action in security terms, consideration should be be the correct action in security terms, consideration should be
given to operational implications. See [RFC3360] for given to operational implications. See [RFC3360] for
consideration of potential problems caused by sending consideration of potential problems caused by sending
inappropriate TCP Resets. inappropriate TCP Resets, for instance.
4.3. Specify Log Actions 4.3. Specify Log Actions
Capability. Capability.
It is possible to log all filter actions. The logging capability It is possible to log all filter actions. The logging capability
is able to capture at least the following data: is able to capture at least the following data:
* permit/reject/drop status * permit/reject/drop status
* source and destination IP address * source and destination IP address
skipping to change at page 18, line 27 skipping to change at page 18, line 27
* Profile Current Traffic (Section 7.1) * Profile Current Traffic (Section 7.1)
* Respond to Incidents Based on Accurate Data (Section 7.4) * Respond to Incidents Based on Accurate Data (Section 7.4)
Current Implementations. Current Implementations.
One way to implement this capability would be to have the counter One way to implement this capability would be to have the counter
display mechanism show the interface (or other entity) to which display mechanism show the interface (or other entity) to which
the filter has been applied, along with the name (or other the filter has been applied, along with the name (or other
designator) for the filter. For example if a filter named 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 "ethernet0" and "ethernet1", the display should indicate something
like "matches of filter 'desktop_outbound' on ethernet0 ..." and like "matches of filter 'desktop_outbound' on ethernet0 ..." and
"matches of filter 'desktop_outbound' on ethernet1 ..." "matches of filter 'desktop_outbound' on ethernet1 ..."
Considerations. Considerations.
It may make sense to apply the same filter definition It may make sense to apply the same filter definition
simultaneously more than one time (to different interfaces, etc.). simultaneously more than one time (to different interfaces, etc.).
If so, it would be much more useful to know which instance of a 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 filter is matching than to know that some instance was matching
skipping to change at page 23, line 30 skipping to change at page 23, line 30
often the operator has no tools available for protocol analysis aside often the operator has no tools available for protocol analysis aside
from interface filters. from interface filters.
7.2. Block Malicious Packets 7.2. Block Malicious Packets
Blocking or limiting traffic deemed to be malicious is a key Blocking or limiting traffic deemed to be malicious is a key
component of application of any security policy's implementation. component of application of any security policy's implementation.
Clearly it is critical to be able to implement a security policy on a Clearly it is critical to be able to implement a security policy on a
network. network.
Malicious packets could potentially be defined by any part of the Malicious packets could potentially be defined by any part of,
layer-3 or layer-4 headers of the IP packet. The ability to classify atleast, the layer-3 or layer-4 headers of the IP packet. The
or select traffic based on these criteria and take some action based ability to classify or select traffic based on these criteria and
on that classification is critical to operations of a network. take some action based on that classification is critical to
operations of a network.
7.3. Limit Sources of Management 7.3. Limit Sources of Management
Management of a network should be limited to only trusted hosts. Management of a network should be limited to only trusted hosts.
This implies that the network elements will be able to limit access This implies that the network elements will be able to limit access
to management functions to these trusted hosts. to management functions to these trusted hosts.
Currently operators will limit access to the management functions on Currently operators will limit access to the management functions on
a network device to only the hosts that are trusted to perform that a network device to only the hosts that are trusted to perform that
function. This allows separation of critical functions and function. This allows separation of critical functions and
skipping to change at page 27, line 28 skipping to change at page 27, line 28
[I-D.savola-rtgwg-backbone-attacks] [I-D.savola-rtgwg-backbone-attacks]
Savola, P., "Backbone Infrastructure Attacks and Savola, P., "Backbone Infrastructure Attacks and
Protections", draft-savola-rtgwg-backbone-attacks-03 (work Protections", draft-savola-rtgwg-backbone-attacks-03 (work
in progress), January 2007. in progress), January 2007.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. 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", [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful",
BCP 60, RFC 3360, August 2002. BCP 60, RFC 3360, August 2002.
[RFC3871] Jones, G., "Operational Security Requirements for Large [RFC3871] Jones, G., "Operational Security Requirements for Large
Internet Service Provider (ISP) IP Network Internet Service Provider (ISP) IP Network
Infrastructure", RFC 3871, September 2004. Infrastructure", RFC 3871, September 2004.
[RFC4778] Kaeo, M., "Operational Security Current Practices in [RFC4778] Kaeo, M., "Operational Security Current Practices in
Internet Service Provider Environments", RFC 4778, Internet Service Provider Environments", RFC 4778,
January 2007. January 2007.
 End of changes. 17 change blocks. 
25 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/