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/ |