draft-ietf-opsec-filter-caps-06.txt   draft-ietf-opsec-filter-caps-07.txt 
None. C. Morrow None. C. Morrow
Internet-Draft UUNET Technologies Internet-Draft UUNET Technologies
Intended status: Informational G. Jones Intended status: Informational G. Jones
Expires: September 22, 2007 Expires: October 14, 2007 Port111 Labs
V. Manral V. Manral
IP Infusion IP Infusion
March 21, 2007 April 12, 2007
Filtering and Rate Limiting Capabilities for IP Network Infrastructure 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 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 September 22, 2007. This Internet-Draft will expire on October 14, 2007.
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 3, line 9 skipping to change at page 3, line 9
implement the capability. Each capability cites the practices it implement the capability. Each capability cites the practices it
supports. Current implementations that support the capability are supports. Current implementations that support the capability are
cited. Special considerations are discussed as appropriate listing cited. Special considerations are discussed as appropriate listing
operational and resource constraints, limitations of current operational and resource constraints, limitations of current
implementations, trade-offs, etc. implementations, trade-offs, etc.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Packet Selection for Management and Data Plane Controls . . . 6 1.3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Packet Selection Criteria . . . . . . . . . . . . . . . . . . 7 2. Traffic Types, Rules and Filters . . . . . . . . . . . . . . . 6
3.1. Select Traffic on All Interfaces . . . . . . . . . . . . . 7 3. Packet Selection Criteria . . . . . . . . . . . . . . . . . . 8
3.2. Select Traffic To the Device . . . . . . . . . . . . . . . 7 3.1. Select Traffic on ANY Interface . . . . . . . . . . . . . 8
3.3. Select Transit Traffic . . . . . . . . . . . . . . . . . . 8 3.2. Select Traffic on ALL Interfaces . . . . . . . . . . . . . 8
3.4. Select Inbound and/or Outbound . . . . . . . . . . . . . . 9 3.3. Select Traffic To the Device . . . . . . . . . . . . . . . 9
3.5. Select by Protocols . . . . . . . . . . . . . . . . . . . 10 3.4. Select Transit Traffic . . . . . . . . . . . . . . . . . . 10
3.6. Select by Addresses . . . . . . . . . . . . . . . . . . . 10 3.5. Select Inbound and/or Outbound . . . . . . . . . . . . . . 11
3.7. Select by Protocol Header Fields . . . . . . . . . . . . . 11 3.6. Select by Address, Protocol or Protocol Header Fields . . 12
4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Specify Filter Actions . . . . . . . . . . . . . . . . . . 13 4.1. Specify Filter Actions . . . . . . . . . . . . . . . . . . 14
4.2. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 13 4.2. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 15
4.3. Specify Log Actions . . . . . . . . . . . . . . . . . . . 14 4.3. Specify Log Actions . . . . . . . . . . . . . . . . . . . 15
4.4. Specify Log Granularity . . . . . . . . . . . . . . . . . 15 4.4. Specify Log Granularity . . . . . . . . . . . . . . . . . 16
4.5. Ability to Display Filter Counters . . . . . . . . . . . . 16 4.5. Ability to Display Filter Counters . . . . . . . . . . . . 17
5. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Filter Counters Displayed Per Application . . . . . . . . 17 5.1. Filter Counters Displayed Per Application . . . . . . . . 18
5.2. Ability to Reset Filter Counters . . . . . . . . . . . . . 17 5.2. Ability to Reset Filter Counters . . . . . . . . . . . . . 18
5.3. Filter Hits are Counted . . . . . . . . . . . . . . . . . 18 5.3. Filter Hits are Counted . . . . . . . . . . . . . . . . . 19
5.4. Filter Counters are Accurate . . . . . . . . . . . . . . . 19 5.4. Filter Counters are Accurate . . . . . . . . . . . . . . . 20
6. Minimal Performance Degradation . . . . . . . . . . . . . . . 20 6. Minimal Performance Degradation . . . . . . . . . . . . . . . 21
7. Additional Operational Practices . . . . . . . . . . . . . . . 22 7. Additional Operational Practices . . . . . . . . . . . . . . . 23
7.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 22 7.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 23
7.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 22 7.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 23
7.3. Limit Sources of Management . . . . . . . . . . . . . . . 22 7.3. Limit Sources of Management . . . . . . . . . . . . . . . 23
7.4. Respond to Incidents Based on Accurate Data . . . . . . . 22 7.4. Respond to Incidents Based on Accurate Data . . . . . . . 23
7.5. Implement Filters Where Necessary . . . . . . . . . . . . 23 7.5. Implement Filters Where Necessary . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10. Non-normative References . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 27 10.1. NormativeReferences . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 10.2. Informational References . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 29 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 30
1. Introduction 1. Introduction
This document is defined in the context of [RFC4778]. [RFC4778] This document is defined in the context of [RFC4778]. [RFC4778]
defines the goals, motivation, scope, definitions, intended audience, 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 the practices. Many of the capabilities listed here refine or add to
capabilities listed in [RFC3871]. capabilities listed in [RFC3871].
Also see [I-D.lewis-infrastructure-security] for a useful description Also see [I-D.lewis-infrastructure-security] for a useful description
of techniques for protecting infrastructure devices, including the of techniques for protecting infrastructure devices, including the
use of filtering. use of filtering.
1.1. Threat Model 1.1. Threat Model
Threats in today's networked environment range from simple packet Threats in today's networked environment range from simple packet
floods with overwhelming bandwidth toward a leaf network to subtle floods with overwhelming bandwidth toward a leaf network to subtle
attacks aimed at subverting known vulnerabilities in existing attacks aimed at subverting known vulnerabilities in existing
applications. The attacked network or host might not be an end user, applications. The target of the attack may be the networking device
it may be the networking device or links inside the provider core. 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, these threats. These mitigation steps could include routing updates,
traffic filters, and routing filters. It is possible that the traffic filters, and routing filters. It is possible that the
mitigation steps might have to affect transit traffic as well as mitigation steps might have to affect transit traffic as well as
traffic destined to the device on which the mitigation steps are traffic destined to the device on which the mitigation steps are
activated. activated.
The scope of the threat includes simply denying services to an The scope of the threat includes simply denying services to an
individual customer on one side of the scale to exploiting a newly individual customer on one side of the scale to exploiting a newly
discovered protocol vulnerability which affects the entire provider discovered protocol vulnerability which affects the entire provider
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
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 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. (more interfaces, more cost to the business caused by the event. The increased costs could
bandwidth, more personnel to support the increased size or come from the need for more interfaces, more bandwidth, more
complexity) 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.
Attack: To set upon with violent force the network or its parts. Attack: Typically this is a form of flood of packets to or through a
Typically this is a form of flood of packets to or through a network. network. This could also be a much smaller stream of packets created
This could also be a much smaller stream of packets created with the with the intent of exploiting a vulnerability in the infrastructure
intent of exploiting a vulnerability in the infrastructure of the of the network.
network.
Asset: Either a customer, network device or network link. Any of Asset: Either a customer, network device or network link. Any of
these could be assets from a business perspective. these could be assets from a business perspective.
These terms are more completely defined in [RFC2828] we have added 1.3. Format
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
Each capability has the following subsections: Each capability has the following subsections:
o Capability (what) o Capability (what)
o Supported Practices (why) o Supported Practices (why)
o Current Implementations (how) o Current Implementations (how)
o Considerations (caveats, resource issues, protocol issues, etc.) o Considerations (caveats, resource issues, protocol issues, etc.)
skipping to change at page 6, line 5 skipping to change at page 6, line 5
The Capability section describes a feature to be supported by the The Capability section describes a feature to be supported by the
device. The Supported Practice section cites practices described in device. The Supported Practice section cites practices described in
[RFC4778] that are supported by this capability. The Current [RFC4778] that are supported by this capability. The Current
Implementation section is intended to give examples of Implementation section is intended to give examples of
implementations of the capability, citing technology and standards implementations of the capability, citing technology and standards
current at the time of writing. It is expected that the choice of current at the time of writing. It is expected that the choice of
features to implement the capabilities will change over time. The features to implement the capabilities will change over time. The
Considerations section lists operational and resource constraints, Considerations section lists operational and resource constraints,
limitations of current implementations, trade-offs, etc. 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 This document describes capabilities that enable routers to filter
performing packet selection. It is assumed in this document that transit, control and management traffic.
o all of these criteria can be used to select packets for both Transit traffic is traffic that passes through a router, but does not
filtering and rate limiting packets, 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 Control and management traffic either originates on the router or is
criteria to filter/rate limit traffic destined for the device destined for the router. Routers filter control and management
itself, 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 A "Filter" is a list of one or more rules that may be applied as a
to filter/rate limit traffic destined through the device group.
o multiple packet selection criteria can be used to select a single A rule consists of the following:
set of packets for filtering action
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 3. Packet Selection Criteria
This section lists packet selection criteria that can be applied to This section lists packet selection criteria that can be applied to
both filtering and rate limiting. both filtering and rate limiting.
3.1. Select Traffic on All Interfaces 3.1. Select Traffic on ANY Interface
Capability. Capability.
The device provides a means to filter IP packets on any interface The device provides a means to select IP packets on any individual
implementing IP. interface implementing IP.
Supported Practices. Supported Practices.
* Security Practices for Device Management ([RFC4778], Section * Security Practices for Device Management ([RFC4778], Section
2.2.2) 2.2.2)
* Security Practices for Data Path ([RFC4778], Section 2.3.2) * Security Practices for Data Path ([RFC4778], Section 2.3.2)
* 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)
skipping to change at page 7, line 44 skipping to change at page 8, line 44
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.
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. Capability.
It is possible to apply the filtering mechanism to traffic that is It is possible to select traffic that is addressed directly to the
addressed directly to the device via any of its interfaces - device via any of its interfaces - including loopback interfaces.
including loopback interfaces. The mechanism should support a shorthand notation representing all
interfaces on that router.
Supported Practices. Supported Practices.
* Security Practices for Device Management ([RFC4778], Section * Security Practices for Device Management ([RFC4778], Section
2.2.2) 2.2.2)
* 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)
skipping to change at page 8, line 31 skipping to change at page 10, line 31
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.
3.3. Select Transit Traffic 3.4. Select Transit Traffic
Capability. Capability.
It is possible to apply the filtering mechanism to traffic that It is possible to select traffic that will transit the device via
will transit the device via any of its interfaces. any of its interfaces. The mechanism should support a shorthand
notation representing traffic not addressed to any of the routers
interfaces.
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
skipping to change at page 9, line 14 skipping to change at page 11, line 16
(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.
This allows the operator to apply filters that protect the This allows the operator to apply filters that protect the
networks and assets surrounding the device from attacks and networks and assets surrounding the device from attacks and
unauthorized access. unauthorized access.
3.4. Select Inbound and/or Outbound 3.5. Select Inbound and/or Outbound
Capability. 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. interface.
Supported Practices. Supported Practices.
* Security Practices for Device Management ([RFC4778], Section * Security Practices for Device Management ([RFC4778], Section
2.2.2) 2.2.2)
* Security Practices for Data Path ([RFC4778], Section 2.3.2) * Security Practices for Data Path ([RFC4778], Section 2.3.2)
* 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)
* Data Plane Filtering ([RFC4778], Section 2.7.1) * Data Plane Filtering ([RFC4778], Section 2.7.1)
* Management Plane Filtering ([RFC4778], Section 2.7.2) * Management Plane Filtering ([RFC4778], Section 2.7.2)
Current Implementations. Current Implementations.
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 outbound on the interface that connects a site to egress filter on the interface that connects a site to its
its external ISP to drop outbound traffic that does not have a external ISP to drop outbound traffic that does not have a valid
valid internal source address. Inbound, it might be desirable to internal source address. Inbound, it might be desirable to apply
apply a filter that blocks all traffic from a site that is known a filter that blocks all traffic from a site that is known to
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 invalid or malicious traffic to
be dropped as close to the source as possible with the least be dropped as close to the source as possible with the least
impact on other traffic transiting the interface(s) in question. impact on other traffic transiting the interface(s) in question.
3.5. Select by Protocols 3.6. Select by Address, Protocol or Protocol Header Fields
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
Capability. Capability.
The device is able to control the flow of traffic based on source The device supports selection based on:
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)
* 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 * source port
ingress filtering per [RFC2827]
Considerations. * destination port
The capability to filter on addresses and address blocks is a * protocol ID
fundamental tool for establishing boundaries between different
networks.
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) * the value(s) of any portion of the protocol headers for IP,
of any portion of the protocol headers for IP, ICMP, UDP and TCP ICMP, UDP and TCP by specifying fields by name (e.g., "protocol
by specifying fields by name (e.g., "protocol = ICMP") rather than = ICMP") rather than bit- offset/length/numeric value (e.g.,
bit- offset/length/numeric value (e.g., 72:8 = 1). 72:8 = 1).
It supports arbitrary header-based filtering (possibly using bit- * Arbitrary header-based selection (possibly using bit-offset/
offset/length/value) of all other protocols. length/value) of all other protocols.
Supported Practices. Supported Practices.
* Security Practices for Device Management ([RFC4778], Section * Security Practices for Device Management ([RFC4778], Section
2.2.2) 2.2.2)
* Security Practices for Data Path ([RFC4778], Section 2.3.2) * Security Practices for Data Path ([RFC4778], Section 2.3.2)
* 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)
skipping to change at page 12, line 16 skipping to change at page 13, line 10
This capability implies that it is possible to filter based on TCP 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 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.
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 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
protocols is a fundamental tool for establishing boundaries
between different networks.
Being able to filter on portions of the header is necessary to Being able to filter on portions of the header is necessary to
allow implementation of policy, secure operations, and support allow implementation of policy, secure operations, and support
incident response. incident response.
4. Actions 4. Actions
4.1. Specify Filter Actions 4.1. Specify Filter Actions
Capability. Capability.
The device provides a mechanism to allow the specification of the The device provides a mechanism through which operators can
action to be taken when a filter rule matches. Actions include specify a forwarding action to be taken when the selection
"permit" (allow the traffic), "reject" (drop with appropriate criteria is met. Forwarding actions include the following:
notification to sender), and "drop" (drop with no notification to
sender). * permit (allow the datagram)
* discard (silently discard the datagram)
* reject (discard the datagram and send a notification to its
originator)
Supported Practices. Supported Practices.
* Data Origin Authentication ([RFC4778], Section 2.3.3) * Data Origin Authentication ([RFC4778], Section 2.3.3)
Current Implementations. Current Implementations.
Assume that your management devices for deployed networking Assume that your management devices for deployed networking
devices live on several subnets, use several protocols, and are devices live on several subnets, use several protocols, and are
controlled by several different parts of your organization. There controlled by several different parts of your organization. There
skipping to change at page 13, line 51 skipping to change at page 15, line 10
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. syslog messages). For this reason
it might be desirable to rate-limit notifications. 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 rule 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
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 include second, minute, hour). Limits should able to be placed in
both inbound and outbound directions. both inbound and outbound directions.
Supported Practices. Supported Practices.
* Denial of Service Tracking/Tracing with Rate Limiting * Denial of Service Tracking/Tracing with Rate Limiting
([RFC4778], Section 2.8.4) ([RFC4778], Section 2.8.4)
Current Implementations. Current Implementations.
skipping to change at page 15, line 33 skipping to change at page 16, line 44
offered on the device. offered on the device.
Also note logging itself can be rate limited so as to not cause Also note logging itself can be rate limited so as to not cause
performance degradation of the device or the network(in case of performance degradation of the device or the network(in case of
syslog or other similar network logging mechanism. syslog or other similar network logging mechanism.
4.4. Specify Log Granularity 4.4. Specify Log Granularity
Capability. 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. Supported Practices.
* Logging Security Practices([RFC4778], Section 2.6.2) * Logging Security Practices([RFC4778], Section 2.6.2)
Current Implementations. Current Implementations.
If a filter is defined that has several rules, and one of the If a filter is defined that has several rules, and one of the
rules denies telnet (tcp/23) connections, then it should be rules specifies an action that denies telnet (tcp/23) connections,
possible to specify that only matches on the rule that denies then it should be possible to specify that only matches on the
telnet should generate a log message. rule that denies telnet should generate a log message.
Considerations. Considerations.
The ability to tune the granularity of logging allows the operator The ability to tune the granularity of logging allows the operator
to log the information that is desired and only the information to log the information that is desired and only the information
that is desired. Without this capability, it is possible that that is desired. Without this capability, it is possible that
extra data (or none at all) would be logged, making it more extra data (or none at all) would be logged, making it more
difficult to find relevant information. difficult to find relevant information.
4.5. Ability to Display Filter Counters 4.5. Ability to Display Filter Counters
skipping to change at page 17, line 44 skipping to change at page 18, line 44
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
somewhere. somewhere.
5.2. Ability to Reset Filter Counters 5.2. Ability to Reset Filter Counters
Capability. 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. Supported Practices.
* 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.
For the purposes of this capability it would be acceptable for the For the purposes of this capability it would be acceptable for the
system to maintain two counters: an "absolute counter", C[now], system to maintain two counters: an "absolute counter", C[now],
skipping to change at page 22, line 48 skipping to change at page 23, line 48
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
protection of those functions on the network devices. protection of those functions on the network devices.
7.4. Respond to Incidents Based on Accurate Data 7.4. Respond to Incidents Based on Accurate Data
Accurate counting of filter rule matches is important because it Accurate counting of filter matches is important because it shows the
shows the frequency of attempts to violate policy. Inaccurate data frequency of attempts to violate policy. Inaccurate data can not be
can not be relied on as the basis for action. Under-reported data relied on as the basis for action. Under-reported data can conceal
can conceal the magnitude of a problem. This enables resources to be the magnitude of a problem. This enables resources to be focused on
focused on areas of greatest need. areas of greatest need.
7.5. Implement Filters Where Necessary 7.5. Implement Filters Where Necessary
This enables the implementation of filters on whichever services are This enables the implementation of filters on whichever services are
necessary. To the extent that filtering causes degradation, it may necessary. To the extent that filtering causes degradation, it may
not be possible to apply filters that implement the appropriate not be possible to apply filters that implement the appropriate
policies. policies.
8. Security Considerations 8. Security Considerations
General General
Security is the subject matter of this entire memo. The Security is the subject matter of this entire memo. The
capabilities listed cite practices in [RFC4778] that they are capabilities listed cite practices in [RFC4778] that they are
intended to support. [RFC4778] defines the threat model, intended to support. [RFC4778] defines the threat model,
practices and lists justifications for each practice. practices and lists justifications for each practice.
9. IANA Considerations 9. IANA Considerations
This document has no actions for IANA. 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] [I-D.lewis-infrastructure-security]
Lewis, D., "Service Provider Infrastructure Security", Lewis, D., "Service Provider Infrastructure Security",
draft-lewis-infrastructure-security-00 (work in progress), draft-lewis-infrastructure-security-00 (work in progress),
June 2006. June 2006.
[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.
[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828,
May 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.
skipping to change at page 28, line 17 skipping to change at page 29, line 17
Christopher L. Morrow Christopher L. Morrow
UUNET Technologies UUNET Technologies
21830 UUNet Way 21830 UUNet Way
Ashburn, Virginia 21047 Ashburn, Virginia 21047
U.S.A. U.S.A.
Phone: +1 703 886 3823 Phone: +1 703 886 3823
Email: chris@uu.net Email: chris@uu.net
George M. Jones George M. Jones
Port111 Labs
Phone: +1 703 488 9740 Phone: +1 703 488 9740
Email: gmj3871@pobox.com Email: gmj3871@pobox.com
Vishwas Manral Vishwas Manral
IP Infusion IP Infusion
Ground Floor, 5th Cross Road, Off 8th Main Road Ground Floor, 5th Cross Road, Off 8th Main Road
Bangalore, 52 Bangalore, 52
India India
 End of changes. 52 change blocks. 
177 lines changed or deleted 227 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/