draft-ietf-opsec-filter-caps-04.txt   draft-ietf-opsec-filter-caps-05.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: March 5, 2007 The MITRE Corporation Expires: September 2, 2007
V. Manral V. Manral
IP Infusion IP Infusion
September 1, 2006 March 1, 2007
Filtering and Rate Limiting Capabilities for IP Network Infrastructure Filtering and Rate Limiting Capabilities for IP Network Infrastructure
draft-ietf-opsec-filter-caps-04 draft-ietf-opsec-filter-caps-05
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 March 5, 2007. This Internet-Draft will expire on September 2, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
[I-D.ietf-opsec-current-practices] lists operator practices related [RFC4778] lists operator practices related to securing networks.
to securing networks. This document lists filtering and rate This document lists filtering and rate limiting capabilities needed
limiting capabilities needed to support those practices. to support those practices. Capabilities are limited to filtering
Capabilities are limited to filtering and rate limiting packets as and rate limiting packets as they enter or leave the device. Route
they enter or leave the device. Route filters and service specific filters and service specific filters (e.g. SNMP, telnet) are not
filters (e.g. SNMP, telnet) are not addressed. addressed.
Capabilities are defined without reference to specific technologies. Capabilities are defined without reference to specific technologies.
This is done to leave room for deployment of new technologies that This is done to leave room for deployment of new technologies that
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. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Packet Selection for Management and Data Plane Controls . . . 6 2. Packet Selection for Management and Data Plane Controls . . . 6
3. Packet Selection Criteria . . . . . . . . . . . . . . . . . . 7 3. Packet Selection Criteria . . . . . . . . . . . . . . . . . . 7
3.1. Select Traffic on All Interfaces . . . . . . . . . . . . . 7 3.1. Select Traffic on All Interfaces . . . . . . . . . . . . . 7
3.2. Select Traffic To the Device . . . . . . . . . . . . . . . 8 3.2. Select Traffic To the Device . . . . . . . . . . . . . . . 7
3.3. Select Transit Traffic . . . . . . . . . . . . . . . . . . 8 3.3. Select Transit Traffic . . . . . . . . . . . . . . . . . . 8
3.4. Select Inbound and/or Outbound . . . . . . . . . . . . . . 9 3.4. Select Inbound and/or Outbound . . . . . . . . . . . . . . 9
3.5. Select by Protocols . . . . . . . . . . . . . . . . . . . 10 3.5. Select by Protocols . . . . . . . . . . . . . . . . . . . 10
3.6. Select by Addresses . . . . . . . . . . . . . . . . . . . 11 3.6. Select by Addresses . . . . . . . . . . . . . . . . . . . 10
3.7. Select by Protocol Header Fields . . . . . . . . . . . . . 12 3.7. Select by Protocol Header Fields . . . . . . . . . . . . . 11
4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Specify Filter Actions . . . . . . . . . . . . . . . . . . 14 4.1. Specify Filter Actions . . . . . . . . . . . . . . . . . . 13
4.2. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 14 4.2. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 13
4.3. Specify Log Actions . . . . . . . . . . . . . . . . . . . 15 4.3. Specify Log Actions . . . . . . . . . . . . . . . . . . . 14
4.4. Specify Log Granularity . . . . . . . . . . . . . . . . . 16 4.4. Specify Log Granularity . . . . . . . . . . . . . . . . . 15
4.5. Ability to Display Filter Counters . . . . . . . . . . . . 17 4.5. Ability to Display Filter Counters . . . . . . . . . . . . 16
5. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Filter Counters Displayed Per Application . . . . . . . . 18 5.1. Filter Counters Displayed Per Application . . . . . . . . 17
5.2. Ability to Reset Filter Counters . . . . . . . . . . . . . 18 5.2. Ability to Reset Filter Counters . . . . . . . . . . . . . 17
5.3. Filter Hits are Counted . . . . . . . . . . . . . . . . . 19 5.3. Filter Hits are Counted . . . . . . . . . . . . . . . . . 18
5.4. Filter Counters are Accurate . . . . . . . . . . . . . . . 20 5.4. Filter Counters are Accurate . . . . . . . . . . . . . . . 19
6. Minimal Performance Degradation . . . . . . . . . . . . . . . 21 6. Minimal Performance Degradation . . . . . . . . . . . . . . . 20
7. Additional Operational Practices . . . . . . . . . . . . . . . 23 7. Additional Operational Practices . . . . . . . . . . . . . . . 22
7.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 23 7.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 22
7.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 23 7.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 22
7.3. Limit Sources of Management . . . . . . . . . . . . . . . 23 7.3. Limit Sources of Management . . . . . . . . . . . . . . . 22
7.4. Respond to Incidents Based on Accurate Data . . . . . . . 23 7.4. Respond to Incidents Based on Accurate Data . . . . . . . 22
7.5. Implement Filters Where Necessary . . . . . . . . . . . . 24 7.5. Implement Filters Where Necessary . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. Non-normative References . . . . . . . . . . . . . . . . . . . 26 9. Non-normative References . . . . . . . . . . . . . . . . . . . 25
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 27 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 28
1. Introduction 1. Introduction
This document is defined in the context of This document is defined in the context of [RFC4778]. [RFC4778]
[I-D.ietf-opsec-current-practices]. defines the goals, motivation, scope, definitions, intended audience,
[I-D.ietf-opsec-current-practices] defines the goals, motivation, threat model, potential attacks and give justifications for each of
scope, definitions, intended audience, threat model, potential the practices. Many of the capabilities listed here refine or add to
attacks and give justifications for each of the practices. Many of capabilities listed in [RFC3871].
the capabilities listed here refine or add to 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
skipping to change at page 5, line 30 skipping to change at page 5, line 28
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.)
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
[I-D.ietf-opsec-current-practices] that are supported by this [RFC4778] that are supported by this capability. The Current
capability. The Current Implementation section is intended to give Implementation section is intended to give examples of
examples of implementations of the capability, citing technology and implementations of the capability, citing technology and standards
standards current at the time of writing. It is expected that the current at the time of writing. It is expected that the choice of
choice of features to implement the capabilities will change over features to implement the capabilities will change over time. The
time. The Considerations section lists operational and resource Considerations section lists operational and resource constraints,
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. Packet Selection for Management and Data Plane Controls
In this document Section 3 describes a number of criteria for In this document Section 3 describes a number of criteria for
performing packet selection. It is assumed in this document that performing packet selection. It is assumed in this document that
o all of these criteria can be used to select packets for both o all of these criteria can be used to select packets for both
filtering and rate limiting packets, filtering and rate limiting packets,
o management plane controls can be implemented by applying these o management plane controls can be implemented by applying these
skipping to change at page 7, line 19 skipping to change at page 7, line 19
3.1. Select Traffic on All Interfaces 3.1. Select Traffic on All Interfaces
Capability. Capability.
The device provides a means to filter IP packets on any interface The device provides a means to filter IP packets on any interface
implementing IP. implementing IP.
Supported Practices. Supported Practices.
* Security Practices for Device Management * Security Practices for Device Management ([RFC4778], Section
([I-D.ietf-opsec-current-practices], Section 2.2.2) 2.2.2)
* Security Practices for Data Path ([I-D.ietf-opsec-current- * Security Practices for Data Path ([I-D.ietf-opsec-current-
practices], Section 2.3.2) practices], Section 2.3.2)
* Security Practices for Software Upgrades and Configuration * Security Practices for Software Upgrades and Configuration
Integrity/Validation ([I-D.ietf-opsec-current-practices], Integrity/Validation ([I-D.ietf-opsec-current-practices],
Section 2.5.2) Section 2.5.2)
* Data Plane Filtering ([I-D.ietf-opsec-current-practices], * Data Plane Filtering ([RFC4778], Section 2.7.1)
Section 2.7.1)
* Management Plane Filtering ([I-D.ietf-opsec-current-practices], * Management Plane Filtering ([RFC4778], Section 2.7.2)
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
skipping to change at page 8, line 6 skipping to change at page 8, line 4
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. None.
3.2. Select Traffic To the Device 3.2. Select Traffic To the Device
Capability. Capability.
It is possible to apply the filtering mechanism to traffic that is It is possible to apply the filtering mechanism to traffic that is
addressed directly to the device via any of its interfaces - addressed directly to the device via any of its interfaces -
including loopback interfaces. including loopback interfaces.
Supported Practices. Supported Practices.
* Security Practices for Device Management * Security Practices for Device Management ([RFC4778], Section
([I-D.ietf-opsec-current-practices], Section 2.2.2) 2.2.2)
* Security Practices for Software Upgrades and Configuration * Security Practices for Software Upgrades and Configuration
Integrity/Validation ([I-D.ietf-opsec-current-practices], Integrity/Validation ([RFC4778], Section 2.5.2)
Section 2.5.2)
* Management Plane Filtering ([I-D.ietf-opsec-current-practices], * Management Plane Filtering ([RFC4778], Section 2.7.2)
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
skipping to change at page 8, line 50 skipping to change at page 8, line 45
3.3. Select Transit Traffic 3.3. Select Transit Traffic
Capability. Capability.
It is possible to apply the filtering mechanism to traffic that It is possible to apply the filtering mechanism to traffic that
will transit the device via any of its interfaces. will transit the device via any of its interfaces.
Supported Practices. Supported Practices.
* Security Practices for Data Path * Security Practices for Data Path ([RFC4778], Section 2.3.2)
([I-D.ietf-opsec-current-practices], Section 2.3.2)
* Data Plane Filtering ([I-D.ietf-opsec-current-practices],
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
skipping to change at page 9, line 35 skipping to change at page 9, line 32
3.4. Select Inbound and/or Outbound 3.4. Select Inbound and/or Outbound
Capability. Capability.
It is possible to filter both incoming and outgoing traffic on any It is possible to filter both incoming and outgoing traffic on any
interface. interface.
Supported Practices. Supported Practices.
* Security Practices for Device Management * Security Practices for Device Management ([RFC4778], Section
([I-D.ietf-opsec-current-practices], Section 2.2.2) 2.2.2)
* Security Practices for Data Path * Security Practices for Data Path ([RFC4778], Section 2.3.2)
([I-D.ietf-opsec-current-practices], Section 2.3.2)
* Security Practices for Software Upgrades and Configuration * Security Practices for Software Upgrades and Configuration
Integrity/Validation ([I-D.ietf-opsec-current-practices], Integrity/Validation ([RFC4778], Section 2.5.2)
Section 2.5.2)
* Data Plane Filtering ([I-D.ietf-opsec-current-practices], * Data Plane Filtering ([RFC4778], Section 2.7.1)
Section 2.7.1)
* Management Plane Filtering ([RFC4778], Section 2.7.2)
* Management Plane Filtering ([I-D.ietf-opsec-current-practices],
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 outbound on the interface that connects a site to
its external ISP to drop outbound traffic that does not have a its external ISP to drop outbound traffic that does not have a
valid internal source address. Inbound, it might be desirable to valid internal source address. Inbound, it might be desirable to
apply a filter that blocks all traffic from a site that is known apply a filter that blocks all traffic from a site that is known
to forward or originate large amounts of junk mail. to forward or originate large amounts of junk mail.
Considerations. Considerations.
skipping to change at page 10, line 29 skipping to change at page 10, line 21
3.5. Select by Protocols 3.5. Select by Protocols
Capability. Capability.
The device provides a means to filter traffic based on the value The device provides a means to filter traffic based on the value
of the protocol field in the IP header. of the protocol field in the IP header.
Supported Practices. Supported Practices.
* Security Practices for Device Management * Security Practices for Device Management ([RFC4778], Section
([I-D.ietf-opsec-current-practices], Section 2.2.2) 2.2.2)
* Security Practices for Data Path * Security Practices for Data Path ([RFC4778], Section 2.3.2)
([I-D.ietf-opsec-current-practices], Section 2.3.2)
* Security Practices for Software Upgrades and Configuration * Security Practices for Software Upgrades and Configuration
Integrity/Validation Integrity/Validation ([RFC4778],Section 2.5.2)
([I-D.ietf-opsec-current-practices],Section 2.5.2)
* Data Plane Filtering ([I-D.ietf-opsec-current-practices], * Data Plane Filtering ([RFC4778], Section 2.7.1)
Section 2.7.1)
* Management Plane Filtering ([I-D.ietf-opsec-current-practices], * Management Plane Filtering ([RFC4778], Section 2.7.2)
Section 2.7.2)
Current Implementations. Current Implementations.
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 (admittedly with some
negative side effects) to mitigate the effects of such attacks is negative side effects) to mitigate the effects of such attacks is
to drop all ICMP traffic headed toward the victim. to drop all ICMP traffic headed toward the victim.
Considerations. Considerations.
skipping to change at page 11, line 14 skipping to change at page 11, line 4
Considerations. Considerations.
Being able to filter on protocol is necessary to allow Being able to filter on protocol is necessary to allow
implementation of policy, secure operations and for support of implementation of policy, secure operations and for support of
incident response. Filtering all traffic to a destination host is incident response. Filtering all traffic to a destination host is
not often possible, business requirements will dictate that not often possible, business requirements will dictate that
critical traffic be permitted if at all possible. critical traffic be permitted if at all possible.
3.6. Select by Addresses 3.6. Select by Addresses
Capability. Capability.
The device is able to control the flow of traffic based on source The device is able to control the flow of traffic based on source
and/or destination IP address or blocks of addresses such as and/or destination IP address or blocks of addresses such as
Classless Inter-Domain Routing (CIDR) blocks. Classless Inter-Domain Routing (CIDR) blocks.
Supported Practices. Supported Practices.
* Security Practices for Device Management * Security Practices for Device Management ([RFC4778], Section
([I-D.ietf-opsec-current-practices], Section 2.2.2) 2.2.2)
* Security Practices for Data Path * Security Practices for Data Path ([RFC4778], Section 2.3.2)
([I-D.ietf-opsec-current-practices], Section 2.3.2)
* Security Practices for Software Upgrades and Configuration * Security Practices for Software Upgrades and Configuration
Integrity/Validation ([I-D.ietf-opsec-current-practices], Integrity/Validation ([RFC4778], Section 2.5.2
Section 2.5.2
* Data Plane Filtering ([I-D.ietf-opsec-current-practices], * Data Plane Filtering ([RFC4778], Section 2.7.1)
Section 2.7.1)
* Management Plane Filtering ([I-D.ietf-opsec-current-practices], * Management Plane Filtering ([RFC4778], Section 2.7.2)
Section 2.7.2)
Current Implementations. Current Implementations.
One example of the use of address based filtering is to implement One example of the use of address based filtering is to implement
ingress filtering per [RFC2827] ingress filtering per [RFC2827]
Considerations. Considerations.
The capability to filter on addresses and address blocks is a The capability to filter on addresses and address blocks is a
fundamental tool for establishing boundaries between different fundamental tool for establishing boundaries between different
skipping to change at page 12, line 19 skipping to change at page 11, line 49
The filtering mechanism supports filtering based on the value(s) The filtering mechanism supports filtering based on the value(s)
of any portion of the protocol headers for IP, ICMP, UDP and TCP of any portion of the protocol headers for IP, ICMP, UDP and TCP
by specifying fields by name (e.g., "protocol = ICMP") rather than by specifying fields by name (e.g., "protocol = ICMP") rather than
bit- offset/length/numeric value (e.g., 72:8 = 1). bit- offset/length/numeric value (e.g., 72:8 = 1).
It supports arbitrary header-based filtering (possibly using bit- It supports arbitrary header-based filtering (possibly using bit-
offset/length/value) of all other protocols. offset/length/value) of all other protocols.
Supported Practices. Supported Practices.
* Security Practices for Device Management * Security Practices for Device Management ([RFC4778], Section
([I-D.ietf-opsec-current-practices], Section 2.2.2) 2.2.2)
* Security Practices for Data Path ([RFC4778], Section 2.3.2)
* Security Practices for Data Path
([I-D.ietf-opsec-current-practices], Section 2.3.2)
* Security Practices for Software Upgrades and Configuration * Security Practices for Software Upgrades and Configuration
Integrity/Validation ([I-D.ietf-opsec-current-practices], Integrity/Validation ([RFC4778], Section 2.5.2)
Section 2.5.2)
* Data Plane Filtering ([I-D.ietf-opsec-current-practices], * Data Plane Filtering ([RFC4778], Section 2.7.1)
Section 2.7.1)
* Management Plane Filtering ([I-D.ietf-opsec-current-practices], * Management Plane Filtering ([RFC4778], Section 2.7.2)
Section 2.7.2)
Current Implementations. Current Implementations.
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
skipping to change at page 14, line 19 skipping to change at page 13, line 19
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 filter rule matches. Actions include action to be taken when a filter rule matches. Actions include
"permit" (allow the traffic), "reject" (drop with appropriate "permit" (allow the traffic), "reject" (drop with appropriate
notification to sender), and "drop" (drop with no notification to notification to sender), and "drop" (drop with no notification to
sender). sender).
Supported Practices. Supported Practices.
* Data Origin Authentication ([I-D.ietf-opsec-current-practices], * Data Origin Authentication ([RFC4778], Section 2.3.3)
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
might exist a reason to have disparate policies for access to the might exist a reason to have disparate policies for access to the
devices from these parts of the organization. devices from these parts of the organization.
Actions such as "permit", "reject", and "drop" are essential in Actions such as "permit", "reject", and "drop" are essential in
skipping to change at page 15, line 18 skipping to change at page 14, line 13
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 timeframe (possible timeframes 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
([I-D.ietf-opsec-current-practices], Section 2.8.4) ([RFC4778], Section 2.8.4)
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
might exist a reason to have disparate policies for access to the might exist a reason to have disparate policies for access to the
devices from these parts of the organization with respect to devices from these parts of the organization with respect to
priority access to these services. Rate Limits may be used to priority access to these services. Rate Limits may be used to
enforce these prioritizations. enforce these prioritizations.
skipping to change at page 16, line 10 skipping to change at page 15, line 4
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
* source and destination ports (if applicable to the protocol) * source and destination ports (if applicable to the protocol)
* which network element received or was sending the packet * which network element received or was sending the packet
(interface, MAC address or other layer 2 information that (interface, MAC address or other layer 2 information that
identifies the previous hop source of the packet). identifies the previous hop source of the packet).
Supported Practices. Supported Practices.
* Logging Security Practices([I-D.ietf-opsec-current-practices], * Logging Security Practices([RFC4778], Section 2.6.2)
Section 2.6.2)
Current Implementations. Current Implementations.
Actions such as "permit", "reject", "drop" are essential in Actions such as "permit", "reject", "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. Auditing the frequency, sources and destinations network devices. Auditing the frequency, sources and destinations
of these attempts is essential for tracking ongoing issues today. of these attempts is essential for tracking ongoing issues today.
Considerations. Considerations.
skipping to change at page 16, line 45 skipping to change at page 15, line 37
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. It is possible to enable/disable logging on a per rule basis.
Supported Practices. Supported Practices.
* Logging Security Practices([I-D.ietf-opsec-current-practices], * Logging Security Practices([RFC4778], Section 2.6.2)
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 denies telnet (tcp/23) connections, then it should be
possible to specify that only matches on the rule that denies possible to specify that only matches on the rule that denies
telnet should generate a log message. telnet should generate a log message.
Considerations. Considerations.
skipping to change at page 23, line 7 skipping to change at page 22, line 7
that may be important in certain operational environments. that may be important in certain operational environments.
Finally, if key infrastructure devices crash or experience severe Finally, if key infrastructure devices crash or experience severe
performance degradation when filtering under heavy load, or even performance degradation when filtering under heavy load, or even
have the reputation of doing so, it is likely that security have the reputation of doing so, it is likely that security
personnel will be forbidden, by policy, from using filtering in personnel will be forbidden, by policy, from using filtering in
ways that would otherwise be appropriate for fear that it might ways that would otherwise be appropriate for fear that it might
cause unnecessary service disruption. cause unnecessary service disruption.
7. Additional Operational Practices 7. Additional Operational Practices
This section describes practices not covered in This section describes practices not covered in [RFC4778]. They are
[I-D.ietf-opsec-current-practices]. They are included here to included here to provide justification for capabilities that
provide justification for capabilities that reference them. reference them.
7.1. Profile Current Traffic 7.1. Profile Current Traffic
This capability allows a network operator to monitor traffic across This capability allows a network operator to monitor traffic across
an active interface in the network at a minimal level. This helps to an active interface in the network at a minimal level. This helps to
determine probable cause for interface or network problems. determine probable cause for interface or network problems.
The ability to separate and distinguish traffic at a layer-3 or The ability to separate and distinguish traffic at a layer-3 or
layer-4 level allows the operator to characterize beyond simple layer-4 level allows the operator to characterize beyond simple
interface counters the traffic in question. This is critical because interface counters the traffic in question. This is critical because
skipping to change at page 25, line 9 skipping to change at page 24, line 9
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 capabilities listed cite practices in [RFC4778] that they are
[I-D.ietf-opsec-current-practices] that they are intended to intended to support. [RFC4778] defines the threat model,
support. [I-D.ietf-opsec-current-practices] defines the threat practices and lists justifications for each practice.
model, practices and lists justifications for each practice.
9. Non-normative References 9. Non-normative References
[I-D.ietf-opsec-current-practices]
Kaeo, M., "Operational Security Current Practices",
draft-ietf-opsec-current-practices-04 (work in progress),
June 2006.
[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-01 (work Protections", draft-savola-rtgwg-backbone-attacks-03 (work
in progress), June 2006. 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, [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828,
May 2000. 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
Internet Service Provider Environments", RFC 4778,
January 2007.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors gratefully acknowledge the contributions of: The authors gratefully acknowledge the contributions of:
o Merike Kaeo for help aligning these capabilities with supported o Merike Kaeo for help aligning these capabilities with supported
practices practices
o The MITRE Corporation for supporting development of this document.
NOTE: The editor's affiliation with The MITRE Corporation is
provided for identification purposes only, and is not intended to
convey or imply MITRE's concurrence with, or support for, the
positions, opinions or viewpoints expressed by the editor.
Authors' Addresses Authors' Addresses
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
The MITRE Corporation
7515 Colshire Drive, M/S WEST
McLean, Virginia 22102-7508
U.S.A.
Phone: +1 703 488 9740 Phone: +1 703 488 9740
Email: gmjones@mitre.org 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
Phone: +91-80-4113-1268 Phone: +91-80-4113-1268
Email: vishwas@ipinfusion.com Email: vishwas@ipinfusion.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 54 change blocks. 
148 lines changed or deleted 106 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/