draft-ietf-opsec-filter-caps-03.txt   draft-ietf-opsec-filter-caps-04.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: March 5, 2007 The MITRE Corporation
V. Manral V. Manral
IP Infusion IP Infusion
September 1, 2006 September 1, 2006
Filtering and Rate Limiting Capabilities for IP Network Infrastructure Filtering and Rate Limiting Capabilities for IP Network Infrastructure
draft-ietf-opsec-filter-caps-03 draft-ietf-opsec-filter-caps-04
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 3, line 13 skipping to change at page 3, line 13
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 . . . . . . . . . . . . . . . 7 3.2. Select Traffic To the Device . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . 9 3.5. Select by Protocols . . . . . . . . . . . . . . . . . . . 10
3.6. Select by Addresses . . . . . . . . . . . . . . . . . . . 10 3.6. Select by Addresses . . . . . . . . . . . . . . . . . . . 11
3.7. Select by Protocol Header Fields . . . . . . . . . . . . . 10 3.7. Select by Protocol Header Fields . . . . . . . . . . . . . 12
4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Specify Filter Actions . . . . . . . . . . . . . . . . . . 12 4.1. Specify Filter Actions . . . . . . . . . . . . . . . . . . 14
4.2. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 13 4.2. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 14
4.3. Specify Log Actions . . . . . . . . . . . . . . . . . . . 13 4.3. Specify Log Actions . . . . . . . . . . . . . . . . . . . 15
4.4. Specify Log Granularity . . . . . . . . . . . . . . . . . 14 4.4. Specify Log Granularity . . . . . . . . . . . . . . . . . 16
4.5. Ability to Display Filter Counters . . . . . . . . . . . . 15 4.5. Ability to Display Filter Counters . . . . . . . . . . . . 17
5. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Filter Counters Displayed Per Application . . . . . . . . 16 5.1. Filter Counters Displayed Per Application . . . . . . . . 18
5.2. Ability to Reset Filter Counters . . . . . . . . . . . . . 16 5.2. Ability to Reset Filter Counters . . . . . . . . . . . . . 18
5.3. Filter Hits are Counted . . . . . . . . . . . . . . . . . 17 5.3. Filter Hits are Counted . . . . . . . . . . . . . . . . . 19
5.4. Filter Counters are Accurate . . . . . . . . . . . . . . . 18 5.4. Filter Counters are Accurate . . . . . . . . . . . . . . . 20
6. Minimal Performance Degradation . . . . . . . . . . . . . . . 19 6. Minimal Performance Degradation . . . . . . . . . . . . . . . 21
7. Additional Operational Practices . . . . . . . . . . . . . . . 21 7. Additional Operational Practices . . . . . . . . . . . . . . . 23
7.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 21 7.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 23
7.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 21 7.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 23
7.3. Limit Sources of Management . . . . . . . . . . . . . . . 21 7.3. Limit Sources of Management . . . . . . . . . . . . . . . 23
7.4. Respond to Incidents Based on Accurate Data . . . . . . . 21 7.4. Respond to Incidents Based on Accurate Data . . . . . . . 23
7.5. Implement Filters Where Necessary . . . . . . . . . . . . 22 7.5. Implement Filters Where Necessary . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. Non-normative References . . . . . . . . . . . . . . . . . . . 24 9. Non-normative References . . . . . . . . . . . . . . . . . . . 26
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 25 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Introduction 1. Introduction
This document is defined in the context of This document is defined in the context of
[I-D.ietf-opsec-current-practices]. [I-D.ietf-opsec-current-practices].
[I-D.ietf-opsec-current-practices] defines the goals, motivation, [I-D.ietf-opsec-current-practices] defines the goals, motivation,
scope, definitions, intended audience, threat model, potential scope, definitions, intended audience, threat model, potential
attacks and give justifications for each of the practices. Many of attacks and give justifications for each of the practices. Many of
the capabilities listed here refine or add to capabilities listed in the capabilities listed here refine or add to capabilities listed in
[RFC3871]. [RFC3871].
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
([I-D.ietf-opsec-current-practices], Section 2.2.2)
* Security Practices for Data Path ([I-D.ietf-opsec-current-
practices], Section 2.3.2)
* Security Practices for Software Upgrades and Configuration
Integrity/Validation ([I-D.ietf-opsec-current-practices],
Section 2.5.2)
* Data Plane Filtering ([I-D.ietf-opsec-current-practices], * Data Plane Filtering ([I-D.ietf-opsec-current-practices],
Section 2.7.1) Section 2.7.1)
* Management Plane Filtering ([I-D.ietf-opsec-current-practices], * Management Plane Filtering ([I-D.ietf-opsec-current-practices],
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)
skipping to change at page 7, line 50 skipping to change at page 8, line 15
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
([I-D.ietf-opsec-current-practices], Section 2.2.2)
* Security Practices for Software Upgrades and Configuration
Integrity/Validation ([I-D.ietf-opsec-current-practices],
Section 2.5.2)
* Management Plane Filtering ([I-D.ietf-opsec-current-practices], * Management Plane Filtering ([I-D.ietf-opsec-current-practices],
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
directed to the device itself, while dropping all other traffic directed to the device itself, while dropping all other traffic
skipping to change at page 8, line 29 skipping to change at page 8, line 50
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
([I-D.ietf-opsec-current-practices], Section 2.3.2)
* Data Plane Filtering ([I-D.ietf-opsec-current-practices], * Data Plane Filtering ([I-D.ietf-opsec-current-practices],
Section 2.7.1) 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.
skipping to change at page 9, line 14 skipping to change at page 9, line 35
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
([I-D.ietf-opsec-current-practices], Section 2.2.2)
* Security Practices for Data Path
([I-D.ietf-opsec-current-practices], Section 2.3.2)
* Security Practices for Software Upgrades and Configuration
Integrity/Validation ([I-D.ietf-opsec-current-practices],
Section 2.5.2)
* Data Plane Filtering ([I-D.ietf-opsec-current-practices], * Data Plane Filtering ([I-D.ietf-opsec-current-practices],
Section 2.7.1) Section 2.7.1)
* Management Plane Filtering ([I-D.ietf-opsec-current-practices], * Management Plane Filtering ([I-D.ietf-opsec-current-practices],
Section 2.7.2) 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 9, line 45 skipping to change at page 10, line 29
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
([I-D.ietf-opsec-current-practices], Section 2.2.2)
* Security Practices for Data Path
([I-D.ietf-opsec-current-practices], Section 2.3.2)
* Security Practices for Software Upgrades and Configuration
Integrity/Validation
([I-D.ietf-opsec-current-practices],Section 2.5.2)
* Data Plane Filtering ([I-D.ietf-opsec-current-practices], * Data Plane Filtering ([I-D.ietf-opsec-current-practices],
Section 2.7.1) Section 2.7.1)
* Management Plane Filtering ([I-D.ietf-opsec-current-practices], * Management Plane Filtering ([I-D.ietf-opsec-current-practices],
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.
Being able to filter on protocol is necessary to allow Being able to filter on protocol is necessary to allow
skipping to change at page 10, line 29 skipping to change at page 11, line 23
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
([I-D.ietf-opsec-current-practices], Section 2.2.2)
* Security Practices for Data Path
([I-D.ietf-opsec-current-practices], Section 2.3.2)
* Security Practices for Software Upgrades and Configuration
Integrity/Validation ([I-D.ietf-opsec-current-practices],
Section 2.5.2
* Data Plane Filtering ([I-D.ietf-opsec-current-practices], * Data Plane Filtering ([I-D.ietf-opsec-current-practices],
Section 2.7.1) Section 2.7.1)
* Management Plane Filtering ([I-D.ietf-opsec-current-practices], * Management Plane Filtering ([I-D.ietf-opsec-current-practices],
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]
skipping to change at page 11, line 16 skipping to change at page 12, line 19
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
([I-D.ietf-opsec-current-practices], Section 2.2.2)
* Security Practices for Data Path
([I-D.ietf-opsec-current-practices], Section 2.3.2)
* Security Practices for Software Upgrades and Configuration
Integrity/Validation ([I-D.ietf-opsec-current-practices],
Section 2.5.2)
* Data Plane Filtering ([I-D.ietf-opsec-current-practices], * Data Plane Filtering ([I-D.ietf-opsec-current-practices],
Section 2.7.1) Section 2.7.1)
* Management Plane Filtering ([I-D.ietf-opsec-current-practices], * Management Plane Filtering ([I-D.ietf-opsec-current-practices],
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
skipping to change at page 12, line 19 skipping to change at page 14, 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.
* Access Control([I-D.ietf-opsec-current-practices], Section
2.3.3)
* Data Origin Authentication ([I-D.ietf-opsec-current-practices], * Data Origin Authentication ([I-D.ietf-opsec-current-practices],
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.
skipping to change at page 24, line 9 skipping to change at page 26, line 9
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
[I-D.ietf-opsec-current-practices] that they are intended to [I-D.ietf-opsec-current-practices] that they are intended to
support. [I-D.ietf-opsec-current-practices] defines the threat support. [I-D.ietf-opsec-current-practices] defines the threat
model, 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] [I-D.ietf-opsec-current-practices]
Kaeo, M., "Operational Security Current Practices", Kaeo, M., "Operational Security Current Practices",
draft-ietf-opsec-current-practices-06 (work in progress), draft-ietf-opsec-current-practices-04 (work in progress),
July 2006. 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-02 (work Protections", draft-savola-rtgwg-backbone-attacks-01 (work
in progress), July 2006. in progress), June 2006.
[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.
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
practices
o The MITRE Corporation for supporting development of this document. o The MITRE Corporation for supporting development of this document.
NOTE: The editor's affiliation with The MITRE Corporation is NOTE: The editor's affiliation with The MITRE Corporation is
provided for identification purposes only, and is not intended to provided for identification purposes only, and is not intended to
convey or imply MITRE's concurrence with, or support for, the convey or imply MITRE's concurrence with, or support for, the
positions, opinions or viewpoints expressed by the editor. positions, opinions or viewpoints expressed by the editor.
Authors' Addresses Authors' Addresses
Christopher L. Morrow Christopher L. Morrow
UUNET Technologies UUNET Technologies
 End of changes. 17 change blocks. 
36 lines changed or deleted 96 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/