draft-ietf-opsec-filter-caps-01.txt   draft-ietf-opsec-filter-caps-02.txt 
None. C. Morrow None. C. Morrow
Internet-Draft UUNET Technologies Internet-Draft UUNET Technologies
Expires: October 12, 2006 G. Jones Expires: September 25, 2006 G. Jones
The MITRE Corporation The MITRE Corporation
V. Manral March 24, 2006
IPInfusion
May 12, 2006
Filtering Capabilities for IP Network Infrastructure Filtering and Rate Limiting Capabilities for IP Network Infrastructure
draft-ietf-opsec-filter-caps-01 draft-ietf-opsec-filter-caps-02
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 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 12, 2006. This Internet-Draft will expire on September 25, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
[I-D.practices] lists operator practices related to securing [I-D.ietf-opsec-current-practices] lists operator practices related
networks. This document lists filtering capabilities needed to to securing networks. This document lists filtering and rate
support those practices. limiting capabilities needed to support those practices.
Capabilities are limited to filtering and rate limiting packets as
they enter or leave the device. Route filters and service specific
filters (e.g. SNMP, telnet) are not 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, tradeoffs, etc. implementations, tradeoffs, etc.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Capabilities or Requirements ? . . . . . . . . . . . . . . 7 1.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Packet Selction for Managemnet and Data Plane Controls . . . . 6
1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 3. Packet Selection Criteria . . . . . . . . . . . . . . . . . . 7
2. Functional Capabilities - Filtering non-transit traffic 3.1. Select Traffic on All Interfaces . . . . . . . . . . . . . 7
(management plane) . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Select Traffic To the Device . . . . . . . . . . . . . . . 7
2.1. Filtering TO the Device . . . . . . . . . . . . . . . . . 9 3.3. Select Transit Traffic . . . . . . . . . . . . . . . . . . 8
2.1.1. Ability to Filter Traffic on All Interfaces TO the 3.4. Select Inbound and/or Outbound . . . . . . . . . . . . . . 8
Device . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Select by Protocols . . . . . . . . . . . . . . . . . . . 9
2.1.2. Ability to Filter Traffic To the Device . . . . . . . 10 3.6. Select by Addresses . . . . . . . . . . . . . . . . . . . 9
2.1.3. Ability to Filter Traffic To the Device - Minimal 3.7. Select by Protocol Header Fields . . . . . . . . . . . . . 10
Performance Degradation . . . . . . . . . . . . . . . 10 4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.4. Ability to Filter To the Device - Specify Filter 4.1. Specify Filter Actions . . . . . . . . . . . . . . . . . . 12
Actions . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 12
2.1.5. Ability to Filter To the Device - Log Filter 4.3. Specify Log Actions . . . . . . . . . . . . . . . . . . . 13
Actions . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Specify Log Granularity . . . . . . . . . . . . . . . . . 14
2.1.6. Ability to Filter To the Device - Specify Log 4.5. Ability to Display Filter Counters . . . . . . . . . . . . 14
Granularity . . . . . . . . . . . . . . . . . . . . . 14 5. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.7. Ability to Filter To the Device - Ability to 5.1. Ability to Display Filter Counters per Filter
Filter Protocols . . . . . . . . . . . . . . . . . . . 15 Application . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.8. Ability to Filter To the Device - Ability to 5.2. Ability to Reset Filter Counters . . . . . . . . . . . . . 16
Filter Addresses . . . . . . . . . . . . . . . . . . . 15 5.3. Filter Hits are Accurately Counted . . . . . . . . . . . . 17
2.1.9. Ability to Filter To the Device - Ability to 5.4. Filter Counters are Accurate . . . . . . . . . . . . . . . 17
Filter Protocol Header Fields . . . . . . . . . . . . 16 6. Minimal Performance Degradation . . . . . . . . . . . . . . . 19
2.1.10. Ability to Filter To the Device - Ability to 7. Additional Operational Practices . . . . . . . . . . . . . . . 21
Filter Inbound and Outbound . . . . . . . . . . . . . 17 7.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 21
2.1.11. Ability to Filter To the Device - Ability to 7.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 21
Accurately Count Filter Hits . . . . . . . . . . . . . 18 7.3. Limit Sources of Management . . . . . . . . . . . . . . . 21
2.1.12. Ability to Filter To the Device - Ability to 7.4. Select Traffic To the Device . . . . . . . . . . . . . . . 21
Display Filter Counters . . . . . . . . . . . . . . . 19 7.5. Select Transit Traffic . . . . . . . . . . . . . . . . . . 22
2.1.13. Ability to Filter To the Device - Ability to 7.6. Select Traffic Inbound and/or Outbound . . . . . . . . . . 22
Display Filter Counters per Filter Application . . . . 20 7.7. Select Traffic by Protocol . . . . . . . . . . . . . . . . 22
2.1.14. Ability to Filter To the Device - Ability to Reset 7.8. Select Traffic by Addresses . . . . . . . . . . . . . . . 22
Filter Counters . . . . . . . . . . . . . . . . . . . 21 7.9. Select Traffic by Protocol Header Field . . . . . . . . . 22
2.1.15. Ability to Filter To the Device - Filter Counters 7.10. Specify Filter Actions . . . . . . . . . . . . . . . . . . 22
are Accurate . . . . . . . . . . . . . . . . . . . . . 22 7.11. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 22
2.2. Rate Limit TO the Device . . . . . . . . . . . . . . . . . 22 7.12. Specify Log Actions . . . . . . . . . . . . . . . . . . . 23
2.2.1. Ability to Rate limit Traffic on All Interfaces TO 7.13. Log Granularity . . . . . . . . . . . . . . . . . . . . . 23
the Device . . . . . . . . . . . . . . . . . . . . . . 22 7.14. Display Filter Counters . . . . . . . . . . . . . . . . . 23
2.2.2. Ability to Rate Limit Traffic To the Device . . . . . 23 7.15. Counters . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.3. Ability to Rate Limit Traffic To the Device - 7.16. Ability to Reset Filter Counters . . . . . . . . . . . . . 23
Minimal Performance Degradation . . . . . . . . . . . 24 7.17. Filter Hits are Accurately Counted . . . . . . . . . . . . 23
2.2.4. Ability to Rate Limit To the Device - Specify Rate 7.18. Filter Hits are Accurate . . . . . . . . . . . . . . . . . 23
Limit Actions . . . . . . . . . . . . . . . . . . . . 26 7.19. Minimal Performance Degredation . . . . . . . . . . . . . 23
2.2.5. Ability to Rate Limit To the Device - Log Rate 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
Limit Actions . . . . . . . . . . . . . . . . . . . . 27 9. Non-normative References . . . . . . . . . . . . . . . . . . . 24
2.2.6. Ability to Rate Limit To the Device - Specify Log Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 25
Granularity . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.7. Ability to Rate Limit To the Device - Ability to Intellectual Property and Copyright Statements . . . . . . . . . . 27
Rate Limit Protocols . . . . . . . . . . . . . . . . . 28
2.2.8. Ability to Rate Limit To the Device - Ability to
Rate Limit Addresses . . . . . . . . . . . . . . . . . 29
2.2.9. Ability to Rate Limit To the Device - Ability to
Rate Limit Protocol Header Fields . . . . . . . . . . 30
2.2.10. Ability to Rate Limit To the Device - Ability to
Rate Limit Inbound and Outbound . . . . . . . . . . . 31
2.2.11. Ability to Rate Limit To the Device - Ability to
Accurately Count Rate Limit Hits . . . . . . . . . . . 32
2.2.12. Ability to Rate Limit To the Device - Ability to
Display Rate Limit Counters . . . . . . . . . . . . . 33
2.2.13. Ability to Rate Limit To the Device - Ability to
Display Rate Limit Counters per Rate Limit
Application . . . . . . . . . . . . . . . . . . . . . 33
2.2.14. Ability to Rate Limit To the Device - Ability to
Reset Rate Limit Counters . . . . . . . . . . . . . . 34
2.2.15. Ability to Rate Limit To the Device - Rate Limit
Counters are Accurate . . . . . . . . . . . . . . . . 35
3. Functional Capabilities - Filtering transit traffic (data
plane) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1. Filtering THROUGH the Device . . . . . . . . . . . . . . . 37
3.1.1. Ability to Filter Traffic on All Interfaces
THROUGH the Device . . . . . . . . . . . . . . . . . . 37
3.1.2. Ability to Filter Traffic Through the Device . . . . . 38
3.1.3. Ability to Filter Traffic Through the Device -
Minimal Performance Degradation . . . . . . . . . . . 38
3.1.4. Ability to Filter Through the Device - Specify
Filter Actions . . . . . . . . . . . . . . . . . . . . 40
3.1.5. Ability to Filter Through the Device - Log Filter
Actions . . . . . . . . . . . . . . . . . . . . . . . 41
3.1.6. Ability to Filter Through the Device - Specify Log
Granularity . . . . . . . . . . . . . . . . . . . . . 42
3.1.7. Ability to Filter Through the Device - Ability to
Filter Protocols . . . . . . . . . . . . . . . . . . . 43
3.1.8. Ability to Filter Through the Device - Ability to
Filter Addresses . . . . . . . . . . . . . . . . . . . 43
3.1.9. Ability to Filter Through the Device - Ability to
Filter Protocol Header Fields . . . . . . . . . . . . 44
3.1.10. Ability to Filter Through the Device - Ability to
Filter Inbound and Outbound . . . . . . . . . . . . . 45
3.1.11. Ability to Filter Through the Device - Ability to
Accurately Count Filter Hits . . . . . . . . . . . . . 46
3.1.12. Ability to Filter Through the Device - Ability to
Display Filter Counters . . . . . . . . . . . . . . . 47
3.1.13. Ability to Filter Through the Device - Ability to
Display Filter Counters per Filter Application . . . . 48
3.1.14. Ability to Filter Through the Device - Ability to
Reset Filter Counters . . . . . . . . . . . . . . . . 49
3.1.15. Ability to Filter Through the Device - Filter
Counters are Accurate . . . . . . . . . . . . . . . . 50
3.2. Rate Limit THROUGH the Device . . . . . . . . . . . . . . 50
3.2.1. Ability to Rate limit Traffic on All Interfaces
THROUGH the Device . . . . . . . . . . . . . . . . . . 51
3.2.2. Ability to Rate Limit Traffic Through the Device . . . 51
3.2.3. Ability to Rate Limit Traffic Through the Device -
Minimal Performance Degradation . . . . . . . . . . . 52
3.2.4. Ability to Rate Limit Through the Device - Specify
Rate Limit Actions . . . . . . . . . . . . . . . . . . 54
3.2.5. Ability to Rate Limit Through the Device - Log
Rate Limit Actions . . . . . . . . . . . . . . . . . . 55
3.2.6. Ability to Rate Limit Through the Device - Specify
Log Granularity . . . . . . . . . . . . . . . . . . . 56
3.2.7. Ability to Rate Limit Through the Device - Ability
to Rate Limit Protocols . . . . . . . . . . . . . . . 57
3.2.8. Ability to Rate Limit Through the Device - Ability
to Rate Limit Addresses . . . . . . . . . . . . . . . 57
3.2.9. Ability to Rate Limit Through the Device - Ability
to Rate Limit Protocol Header Fields . . . . . . . . . 58
3.2.10. Ability to Rate Limit Through the Device - Ability
to Rate Limit Inbound and Outbound . . . . . . . . . . 59
3.2.11. Ability to Rate Limit Through the Device - Ability
to Accurately Count Rate Limit Hits . . . . . . . . . 60
3.2.12. Ability to Rate Limit Through the Device - Ability
to Display Rate Limit Counters . . . . . . . . . . . . 61
3.2.13. Ability to Rate Limit Through the Device - Ability
to Display Rate Limit Counters per Rate Limit
Application . . . . . . . . . . . . . . . . . . . . . 62
3.2.14. Ability to Rate Limit Through the Device - Ability
to Reset Rate Limit Counters . . . . . . . . . . . . . 63
3.2.15. Ability to Rate Limit Through the Device - Rate
Limit Counters are Accurate . . . . . . . . . . . . . 64
4. Functional Capabilities - Filtering Layer 2 Attributes . . . . 65
4.1. Filtering Layer 2 . . . . . . . . . . . . . . . . . . . . 65
4.1.1. Ability to partition layer-2 network to provide
different levels of security . . . . . . . . . . . . . 65
4.1.2. Ability to restrict access to specified hardware
(MAC) addresses . . . . . . . . . . . . . . . . . . . 66
4.1.3. Ability to restrict based on layer-2 packet type
[etherType] field . . . . . . . . . . . . . . . . . . 67
5. Additional Operational Practices . . . . . . . . . . . . . . . 68
5.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 68
5.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 68
5.3. Limit Sources of Management . . . . . . . . . . . . . . . 68
6. Security Considerations . . . . . . . . . . . . . . . . . . . 69
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.1. Normative References . . . . . . . . . . . . . . . . . . . 70
7.2. Non-normative References . . . . . . . . . . . . . . . . . 70
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 72
Intellectual Property and Copyright Statements . . . . . . . . . . 73
1. Introduction 1. Introduction
This document is defined in the context of [I-D.practices]. This document is defined in the context of [I-D.ietf-opsec-current-
[I-D.practices] defines the goals, motivation, scope, definitions, practices]. [I-D.ietf-opsec-current-practices] defines the goals,
intended audience,threat model, potential attacks and give motivation, scope, definitions, intended audience,threat model,
justifications for each of the practices. Many of the capabilities potential attacks and give justifications for each of the practices.
listed here refine or add to capabilities listed in [RFC3871] Many of the capabilities listed here refine or add to capabilities
listed in [RFC3871].
Also see [I-D.lewis-infrastructure-security] for a useful description
of techniques for protecting infrastructure devices, including the
use of filtering.
1.1. Threat Model 1.1. Threat Model
Threats in today's networked environment range from simple packet Threats in today's networked environment range from simple packet
floods with overwhelming bandwidth toward a leaf network to subtle floods with overwhelming bandwidth toward a leaf network to subtle
attacks aimed at subverting known vulnerabilities in existing attacks aimed at subverting known vulnerabilities in existing
applications. The attacked network or host might not be an end user, applications. The attacked network or host might not be an end user,
it may be the networking device or links inside the provider core. it may be the networking device or links inside the provider core.
Networks must have the ability to place mitigation in order to limit Networks must have the ability to place mitigation in order to limit
skipping to change at page 7, line 5 skipping to change at page 5, line 9
Attack: To set upon with violent force the network or its parts. Attack: To set upon with violent force the network or its parts.
Typically this is a form of flood of packets to or through a network. Typically this is a form of flood of packets to or through a network.
This could also be a much smaller stream of packets created with the This could also be a much smaller stream of packets created with the
intent of exploiting a vulnerability in the infrastructure of the intent of exploiting a vulnerability in the infrastructure of the
network. network.
Asset: Either a customer, network device or network link. Any of Asset: Either a customer, network device or network link. Any of
these could be assets from a business perspective. these could be assets from a business perspective.
These terms are more completely defined in RFC2828 we have added some These terms are more completely defined in [RFC2828] we have added
scope specific information only. some scope specific information only.
1.2. Capabilities or Requirements ?
Capabilities may or may not be requirements. That is a local Also see [I-D.savola-rtgwg-backbone-attacks] for a list of attacks on
determination that must be made by each operator with reference to backbone devices and counter measures.
the policies that they must support. It is hoped that this document,
together with [I-D.practices] will assist operators in identifying
their security capability requirements and communicating them clearly
to vendors.
1.3. Format 1.2. Format
Each capability has the following subsections: Each capability has the following subsections:
o Capability (what) o Capability (what)
o Supported Practices (why) o Supported Practices (why)
o Current Implementations (how) o Current Implementations (how)
o Considerations (caveats, resource issues, protocol issues, etc.) o Considerations (caveats, resource issues, protocol issues, etc.)
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.practices] that are supported by this capability. The Current [I-D.ietf-opsec-current-practices] that are supported by this
Implementation section is intended to give examples of capability. The Current Implementation section is intended to give
implementations of the capability, citing technology and standards examples of implementations of the capability, citing technology and
current at the time of writing. See [RFC3631]. It is expected that standards current at the time of writing. It is expected that the
the choice of features to implement the capabilities will change over choice of features to implement the capabilities will change over
time. The Considerations section lists operational and resource time. The Considerations section lists operational and resource
constraints, limitations of current implementations, tradeoffs, etc. constraints, limitations of current implementations, tradeoffs, etc.
[EDITORS NOTE: this is a first draft. At least two editing passes 2. Packet Selction for Managemnet and Data Plane Controls
will be made over the capabilities listed below in future drafts: one
will break out compound capabilities into individual capabilities,
the other will try to align the supported practices with the
practices listed in [I-D.practices]]
1.4. Definitions
RFC 2119 Keywords In this document section Section 3 describes a number of criteria for
performing packet selection. It is assumed in this document that
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL o all of these criteria can be used to select packets for both
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" filtering and rate limiting packets,
in this document are to be interpreted as described in [RFC2119].
The use of the RFC 2119 keywords is an attempt, by the editor, to o management plane controls can be implemented by applying these
assign the correct requirement levels ("MUST", "SHOULD", criteria to filter/rate limit traffic destined for the device
"MAY"...). It must be noted that different organizations, itself,
operational environments, policies and legal environments will
generate different requirement levels.
2. Functional Capabilities - Filtering non-transit traffic (management o data plane controls can be implemented by applying these criteria
plane) to filter/rate limit traffic destined through the device
The capabilities in this section are intended to list testable, 3. Packet Selection Criteria
functional capabilities that are needed to operate devices securely.
Focusing on filtering non-transit packets on devices, controlling
access to the management plane.
2.1. Filtering TO the Device This section lists packet selection criteria that can be applied to
both filtering and rate limiting.
2.1.1. Ability to Filter Traffic on All Interfaces TO the Device 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 that are non-transit packets. implementing IP.
Supported Practices. Supported Practices.
* Profile Current Traffic ([I-D.practices] Section x.x.x) * Profile Current Traffic (Section 7.1)
* Block Malicious Packets (Section 5.2) * Block Malicious Packets (Section 7.2)
* Limit Sources of Management (Section 5.3) * Limit Sources of Management ([I-D.ietf-opsec-current-
practices], Section 2.8.2)
Current Implementations. Current Implementations.
Many devices currently implement access control lists or filters Many devices currently implement access control lists or filters
that allow filtering based on protocol and/or source/destination that allow filtering based on protocol and/or source/destination
address and or source/destination port and allow these filters to address and or source/destination port and allow these filters to
be applied to interfaces. be applied to interfaces.
Considerations. Considerations.
None. None.
2.1.2. Ability to Filter 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.
* This allows the operator to apply filters that protect the * Select Traffic To the Device (Section 7.4)
device itself from attacks and unauthorized access.
Current Implementations. Current Implementations.
Many devices currently implement access control lists or filters Many devices currently implement access control lists or filters
that allow filtering based on protocol and/or source/destination that allow filtering based on protocol and/or source/destination
address and or source/destination port and allow these filters to address and or source/destination port and allow these filters to
be applied to services offered by the device. be applied to services offered by the device.
Examples of this might include filters that permit only BGP from Examples of this might include filters that permit only BGP from
peers and SNMP and SSH from an authorized management segment and peers and SNMP and SSH from an authorized management segment and
directed to the device itself, while dropping all other traffic directed to the device itself, while dropping all other traffic
addressed to the device. addressed to the device.
Considerations. Considerations.
None. None.
2.1.3. Ability to Filter Traffic To the Device - Minimal Performance 3.3. Select Transit Traffic
Degradation
Capability.
The device provides a means to filter packets without significant
performance degradation. This specifically applies to stateless
packet filtering operating on layer 3 (IP) and layer 4 (TCP or
UDP) headers, as well as normal packet forwarding information such
as incoming and outgoing interfaces.
The device is able to apply stateless packet filters on ALL
interfaces (up to the maximum number possible) simultaneously and
with multiple filters per interface (e.g., inbound and outbound).
The filtering of traffic destined to interfaces on the device,
including the loopback interface, should not degrade performance
significantly.
Supported Practices.
* This enables the implementation of filters on whichever
services necessary. To the extent that filtering causes
degradation, it may not be possible to apply filters that
implement the appropriate policies.
Current Implementations.
Another way of stating the capability is that filter performance
should not be the limiting factor in device throughput. If a
device is capable of forwarding 30Mb/sec without filtering, then
it should be able to forward the same amount with filtering in
place.
Considerations.
The definition of "significant" is subjective. At one end of the
spectrum it might mean "the application of filters may cause the
box to crash". At the other end would be a throughput loss of
less than one percent with tens of thousands of filters applied.
The level of performance degradation that is acceptable will have
to be determined by the operator.
Repeatable test data showing filter performance impact would be
very useful in evaluating this capability. Tests should include
such information as packet size, packet rate, number of interfaces
tested (source/destination), types of interfaces, routing table
size, routing protocols in use, frequency of routing updates, etc.
This capability does not address stateful filtering, filtering
above layer 4 headers or other more advanced types of filtering
that may be important in certain operational environments.
2.1.4. Ability to Filter To the Device - Specify Filter Actions
Capability. Capability.
The device provides a mechanism to allow the specification of the It is possible to apply the filtering mechanism to traffic that
action to be taken when a filter rule matches. Actions include will transit the device via any of its interfaces.
"permit" (allow the traffic), "reject" (drop with appropriate
notification to sender), and "drop" (drop with no notification to
sender).
Supported Practices. Supported Practices.
* This capability is essential to the use of filters to enforce * Select Transit Traffic (Section 7.5)
policy.
Current Implementations. Current Implementations.
Assume that your management devices for deployed networking Many devices currently implement access control lists or filters
devices live on several subnets, use several protocols, and are that allow filtering based on protocol and/or source/destination
controlled by several different parts of your organization. There address and or source/destination port and allow these filters to
might exist a reason to have disparate policies for access to the be applied to the interfaces on the device in order to protect
devices from these parts of the organization. assets attached to the network.
Actions such as "permit", "deny", "drop" are essential in defining
the security policy for the services offered by the network
devices.
Considerations.
While silently dropping traffic without sending notification may
be the correct action in security terms, consideration should be
given to operational implications. See [RFC3360] for
consideration of potential problems caused by sending
inappropriate TCP Resets.
2.1.5. Ability to Filter To the Device - Log Filter Actions
Capability.
It is possible to log all filter actions. The logging capability
is able to capture at least the following data:
* permit/deny/drop status
* source and destination IP address
* source and destination ports (if applicable to the protocol)
* which network element received the packet (interface, MAC
address or other layer 2 information that identifies the
previous hop source of the packet).
Supported Practices.
* Logging is essential for auditing, incident response, and
operations
Current Implementations.
Actions such as "permit", "deny", "drop" are essential in defining Examples of this may include filtering all traffic save SMTP
the security policy for the services offered by the network (tcp/25) destined to a mail server. A common use of this today
devices. Auditing the frequency, sources and destinations of would also be denying all traffic to a destination which has been
these attempts is essential for tracking ongoing issues today. determined to be hostile.
Considerations. Considerations.
Logging can be burdensome to the network device, at no time should None.
logging cause performance degradation to the device or services
offered on the device.
2.1.6. Ability to Filter To the Device - Specify Log Granularity
3.4. Select Inbound and/or Outbound
Capability. Capability.
It is possible to enable/disable logging on a per rule basis. It is possible to filter both incoming and outgoing traffic on any
interface.
Supported Practices. Supported Practices.
* The ability to tune the granularity of logging allows the * Select Inbound and/or Outbound Traffic (Section 7.6)
operator to log the information that is desired and only the
information that is desired. Without this capability, it is
possible that extra data (or none at all) would be logged,
making it more difficult to find relevant information.
Current Implementations. Current Implementations.
If a filter is defined that has several rules, and one of the It might be desirable on a border router, for example, to apply an
rules denies telnet (tcp/23) connections, then it should be egress filter outbound on the interface that connects a site to
possible to specify that only matches on the rule that denies its external ISP to drop outbound traffic that does not have a
telnet should generate a log message. valid internal source address. Inbound, it might be desirable to
apply a filter that blocks all traffic from a site that is known
to forward or originate large amounts of junk mail.
Considerations. Considerations.
None. None.
2.1.7. Ability to Filter To the Device - Ability to Filter 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.
* Being able to filter on protocol is necessary to allow * Select by Protocols(Section 7.7)
implementation of policy, secure operations and for support of
incident response.
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.
None. None.
2.1.8. Ability to Filter To the Device - Ability to Filter Addresses 3.6. Select by Addresses
Capability. Capability.
The function is able to control the flow of traffic based on The device is able to control the flow of traffic based on source
source and/or destination IP address or blocks of addresses such and/or destination IP address or blocks of addresses such as
as Classless Inter-Domain Routing (CIDR) blocks. Classless Inter-Domain Routing (CIDR) blocks.
Supported Practices. Supported Practices.
* The capability to filter on addresses and address blocks is a * Select by Addresses(Section 7.8)
fundamental tool for establishing boundaries between different
networks.
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.
None. None.
2.1.9. Ability to Filter To the Device - Ability to Filter Protocol 3.7. Select by Protocol Header Fields
Header Fields
Capability. Capability.
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.
It supports filtering of all other protocols supported at layer 3 It supports filtering of all other protocols supported at layer 3
and 4. It supports filtering based on the headers of higher level and 4. It supports filtering based on the headers of higher level
protocols. It is possible to specify fields by name (e.g., protocols. It is possible to specify fields by name (e.g.,
"protocol = ICMP") rather than bit- offset/length/numeric value "protocol = ICMP") rather than bit- offset/length/numeric value
(e.g., 72:8 = 1). (e.g., 72:8 = 1).
Supported Practices. Supported Practices.
* Being able to filter on portions of the header is necessary to * Select by Protocol Header Field(Section 7.9)
allow implementation of policy, secure operations, and support
incident response.
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
connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting
web servers. web servers.
Considerations. Considerations.
None. None.
2.1.10. Ability to Filter To the Device - Ability to Filter Inbound and 4. Actions
Outbound
Capability.
It is possible to filter both incoming and outgoing traffic on any
interface.
Supported Practices.
* This capability allows flexibility in applying filters at the
place that makes the most sense. It allows invalid or
malicious traffic to be dropped as close to the source as
possible.
Current Implementations.
It might be desirable on a border router, for example, to apply an
egress filter outbound on the interface that connects a site to
its external ISP to drop outbound traffic that does not have a
valid internal source address. Inbound, it might be desirable to
apply a filter that blocks all traffic from a site that is known
to forward or originate lots of junk mail.
Considerations.
None.
2.1.11. Ability to Filter To the Device - Ability to Accurately Count
Filter Hits
Capability.
The device supplies a facility for accurately counting all filter
matches.
Supported Practices.
* Accurate counting of filter rule matches is important because
it shows the frequency of attempts to violate policy. This
enables resources to be focused on areas of greatest need.
Current Implementations.
Assume, for example, that a ISP network implements anti-spoofing
egress filters (see [RFC2827]) on interfaces of its edge routers
that support single-homed stub networks. Counters could enable
the ISP to detect cases where large numbers of spoofed packets are
being sent. This may indicate that the customer is performing
potentially malicious actions (possibly in violation of the ISPs
Acceptable Use Policy), or that system(s) on the customers network
have been "owned" by hackers and are being (mis)used to launch
attacks.
Considerations.
None.
2.1.12. Ability to Filter To the Device - Ability to Display Filter
Counters
Capability.
The device provides a mechanism to display filter counters.
Supported Practices.
* Information that is collected is not useful unless it can be
displayed in a useful manner.
Current Implementations.
Assume there is a router with four interfaces. One is an up-link
to an ISP providing routes to the Internet. The other three
connect to separate internal networks. Assume that a host on one
of the internal networks has been compromised by a hacker and is
sending traffic with bogus source addresses. In such a situation,
it might be desirable to apply ingress filters to each of the
internal interfaces. Once the filters are in place, the counters
can be examined to determine the source (inbound interface) of the
bogus packets.
Considerations.
None.
2.1.13. Ability to Filter To the Device - Ability to Display Filter
Counters per Filter Application
Capability.
If it is possible for a filter to be applied more than once at the
same time, then the device provides a mechanism to display filter
counters per filter application.
Supported Practices.
* It may make sense to apply the same filter definition
simultaneously more than one time (to different interfaces,
etc.). If so, it would be much more useful to know which
instance of a filter is matching than to know that some
instance was matching somewhere.
Current Implementations.
One way to implement this capability would be to have the counter
display mechanism show the interface (or other entity) to which
the filter has been applied, along with the name (or other
designator) for the filter. For example if a filter named
"desktop_outbound" applied two different interfaces, say,
"ethernet0" and "ethernet1", the display should indicate something
like "matches of filter 'desktop_outbound' on ethernet0 ..." and
"matches of filter 'desktop_outbound' on ethernet1 ..."
Considerations.
None.
2.1.14. Ability to Filter To the Device - Ability to Reset Filter
Counters
Capability.
It is possible to reset counters to zero on a per filter basis.
For the purposes of this capability it would be acceptable for the
system to maintain two counters: an "absolute counter", C[now],
and a "reset" counter, C[reset]. The absolute counter would
maintain counts that increase monotonically until they wrap or
overflow the counter. The reset counter would receive a copy of
the current value of the absolute counter when the reset function
was issued for that counter. Functions that display or retrieve
the counter could then display the delta (C[now] - C[reset]).
Supported Practices.
* This allows operators to get a current picture of the traffic
matching particular rules/filters.
Current Implementations.
Assume that filter counters are being used to detect internal
hosts that are infected with a new worm. Once it is believed that
all infected hosts have been cleaned up and the worm removed, the
next step would be to verify that. One way of doing so would be
to reset the filter counters to zero and see if traffic indicative
of the worm has ceased.
Considerations.
None.
2.1.15. Ability to Filter To the Device - Filter Counters are Accurate
Capability.
Filter counters are accurate. They reflect the actual number of
matching packets since the last counter reset. Filter counters
are be capable of holding up to 2^32 - 1 values without
overflowing and should be capable of holding up to 2^64 - 1
values.
Supported Practices.
* Inaccurate data can not be relied on as the basis for action.
Underreported data can conceal the magnitude of a problem.
Current Implementations.
If N packets matching a filter are sent to/through a device, then
the counter should show N matches.
Considerations.
None.
2.2. Rate Limit TO the Device
2.2.1. Ability to Rate limit Traffic on All Interfaces TO the Device
Capability.
The device provides a means to rate limit IP packets on any
interface implementing IP that are non-transit packets.
Supported Practices.
* Profile Current Traffic ([I-D.practices] Section x.x.x)
* Block Malicious Packets (Section 5.2)
* Limit Sources of Management (Section 5.3)
Current Implementations.
Many devices currently implement rate limits that allow rate
limiting based on protocol and/or source/destination address and
or source/destination port or raw bandwidth and allow these limits
to be applied to interfaces.
Considerations.
None.
2.2.2. Ability to Rate Limit Traffic To the Device 4.1. Specify Filter Actions
Capability. Capability.
It is possible to apply the rate-limiting mechanism to traffic The device provides a mechanism to allow the specification of the
that is addressed directly to the device via any of its interfaces action to be taken when a filter rule matches. Actions include
- including loopback interfaces. "permit" (allow the traffic), "reject" (drop with appropriate
notification to sender), and "drop" (drop with no notification to
sender).
Supported Practices. Supported Practices.
* This allows the operator to apply rate-limits that protect the * Specify Filter Actions(Section 7.10)
device itself from attacks and unauthorized access.
Current Implementations. Current Implementations.
Many devices currently implement rate-limits that allow limiting Assume that your management devices for deployed networking
based on protocol and/or source/destination address and or source/ devices live on several subnets, use several protocols, and are
destination port and allow these limits to be applied to services controlled by several different parts of your organization. There
offered by the device. might exist a reason to have disparate policies for access to the
devices from these parts of the organization.
Examples of this might include rate-limits that permit BGP traffic
rates up to 100 megabits per second from an authorized peer, while
dropping all other traffic addressed to the device which exceeds
this limit.
Considerations.
None.
2.2.3. Ability to Rate Limit Traffic To the Device - Minimal
Performance Degradation
Capability.
The device provides a means to rate-limit packets without
significant performance degradation.
The device is able to apply rate-limits on ALL interfaces (up to
the maximum number possible) simultaneously and with multiple
rate-limits per interface (e.g., inbound, outbound, differing
traffic classifications in either direction).
The rate-limiting of traffic destined to interfaces on the device,
including the loopback interface, should not degrade performance
significantly.
Supported Practices.
* This enables the implementation of rate-limits on whichever
services are necessary. To the extent that rate-limiting
causes degradation, it may not be possible to apply rate-limits
that implement the appropriate policies.
Current Implementations.
Another way of stating the capability is that rate-limit Actions such as "permit", "deny", "drop" are essential in defining
performance should not be the limiting factor in device the security policy for the services offered by the network
throughput. If a device is capable of forwarding 30Mb/sec without devices.
rate-limits, then it should be able to forward the same amount
with rate-limits in place.
Considerations. Considerations.
The definition of "significant" is subjective. At one end of the While silently dropping traffic without sending notification may
spectrum it might mean "the application of rate-limits may cause be the correct action in security terms, consideration should be
the box to crash". At the other end would be a throughput loss of given to operational implications. See [RFC3360] for
less than one percent with tens of thousands of rate-limits consideration of potential problems caused by sending
applied. The level of performance degradation that is acceptable inappropriate TCP Resets.
will have to be determined by the operator.
Repeatable test data showing rate-limiting performance impact
would be very useful in evaluating this capability. Tests should
include such information as packet size, packet rate, number of
interfaces tested (source/destination), types of interfaces,
routing table size, routing protocols in use, frequency of routing
updates, etc.
2.2.4. Ability to Rate Limit To the Device - Specify Rate Limit Actions 4.2. Specify Rate Limits
Capability. Capability.
The device provides a mechanism to allow the specification of the The device provides a mechanism to allow the specification of the
action to be taken when a rate-limit rule matches. Actions action to be taken when a rate limiting filter rule matches. The
include "permit" (allow the traffic), "reject" (drop with actions include "transmit" (permit the traffic because it's below
appropriate notification to sender), and "drop" (drop with no the specified limit), "limit" (limit traffic because it exceeds
notification to sender). the specified limit). Limits should be applicable by both bits
per second and packets per timeframe (possible timeframes might
include second, minute, hour). Limits should able to be placed in
both inbound and outbound directions.
Supported Practices. Supported Practices.
* This capability is essential to the use of rate limits to * Specify Rate Limits (Section 7.11)
enforce policy.
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. Further you may devices from these parts of the organization with respect to
want to limit traffic levels for these types of traffic from these priority access to these services. Rate Limits may be used to
known sources. enforce these prioritizations.
Actions such as "permit", "deny", "drop" are essential in defining
the security policy for the services offered by the network
devices.
Considerations. Considerations.
While silently dropping traffic without sending notification may While silently dropping traffic without sending notification may
be the correct action in security terms, consideration should be be the correct action in security terms, consideration should be
given to operational implications. See [RFC3360] for given to operational implications. See [RFC3360] for
consideration of potential problems caused by sending consideration of potential problems caused by sending
inappropriate TCP Resets. inappropriate TCP Resets.
2.2.5. Ability to Rate Limit To the Device - Log Rate Limit Actions 4.3. Specify Log Actions
Capability. Capability.
It is possible to log rate limit 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/deny/drop status * permit/deny/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 the packet (interface, MAC * which network element received the packet (interface, MAC
address or other layer 2 information that identifies the address or other layer 2 information that identifies the
previous hop source of the packet). previous hop source of the packet).
Supported Practices. Supported Practices.
* Logging is essential for auditing, incident response, and * Log exceptions ([I-D.ietf-opsec-current-practices], Section
operations 2.7.2)
* Log Actions (Section 7.12)
Current Implementations. Current Implementations.
Actions such as "permit", "deny", "drop" are essential in defining Actions such as "permit", "deny", "drop" are essential in defining
the security policy for the services offered by the network the security policy for the services offered by the network
devices. Auditing the frequency, sources and destinations of devices. Auditing the frequency, sources and destinations of
these attempts is essential for tracking ongoing issues today. these attempts is essential for tracking ongoing issues today.
Considerations. Considerations.
Logging can be burdensome to the network device, at no time should Logging can be burdensome to the network device, at no time should
logging cause performance degradation to the device or services logging cause performance degradation to the device or services
offered on the device. offered on the device.
2.2.6. Ability to Rate Limit To the Device - 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.
* The ability to tune the granularity of logging allows the * Log Granularity (Section 7.13)
operator to log the information that is desired and only the
information that is desired. Without this capability, it is
possible that extra data (or none at all) would be logged,
making it more difficult to find relevant information.
Current Implementations. Current Implementations.
If a rate limit 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.
None. None.
2.2.7. Ability to Rate Limit To the Device - Ability to Rate Limit 4.5. Ability to Display Filter Counters
Protocols
Capability.
The device provides a means to rate limit traffic based on the
value of the protocol field in the IP header.
Supported Practices.
* Being able to rate limit on protocol is necessary to allow
implementation of policy, secure operations and for support of
incident response.
Current Implementations.
Some denial of service attacks are based on the ability to flood
the victim with ICMP traffic. One quick way (admittedly with some
negative side effects) to mitigate the effects of such attacks is
to rate limit all ICMP traffic headed toward the victim.
Considerations.
None.
2.2.8. Ability to Rate Limit To the Device - Ability to Rate Limit
Addresses
Capability.
The function is able to control the flow of traffic based on
source and/or destination IP address or blocks of addresses such
as Classless Inter-Domain Routing (CIDR) blocks.
Supported Practices.
* The capability to rate limit on addresses and address blocks is
a fundamental tool for establishing boundaries between
different networks.
Current Implementations.
One example of the use of address based rate limits is to
implement ingress filtering per [RFC2827].
Considerations.
None.
2.2.9. Ability to Rate Limit To the Device - Ability to Rate Limit
Protocol Header Fields
Capability.
The rate limit mechanism supports rate limiting based on the
value(s) of any portion of the protocol headers for IP, ICMP, UDP
and TCP. It supports rate limiting of all other protocols
supported at layer 3 and 4. It supports rate limiting based on
the headers of higher level protocols. It is possible to specify
fields by name (e.g., "protocol = ICMP") rather than bit- offset/
length/numeric value (e.g., 72:8 = 1).
Supported Practices.
* Being able to rate limit on portions of the header is necessary
to allow implementation of policy, secure operations, and
support incident response.
Current Implementations.
This capability implies that it is possible to rate limit based on
TCP 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
"inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear
or SYN bit set+ACK,FIN and RST bits clear). Another common
example is the ability to control what services are allowed in/out
of a network. It may be desirable to only allow inbound
connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting
web servers.
Considerations.
None.
2.2.10. Ability to Rate Limit To the Device - Ability to Rate Limit
Inbound and Outbound
Capability.
It is possible to rate limit both incoming and outgoing traffic on
any interface.
Supported Practices.
* This capability allows flexibility in applying rate limits at
the place that makes the most sense. It allows invalid or
malicious traffic to be dropped as close to the source as
possible.
Current Implementations.
It might be desirable on a router to apply an egress rate limit to
its external connections to limit outbound traffic that does not
have a high priority. Inbound, it might be desirable to apply a
rate limit to all traffic of a certain classification in order to
preserve limited resources on the router's management components.
Considerations.
None.
2.2.11. Ability to Rate Limit To the Device - Ability to Accurately
Count Rate Limit Hits
Capability.
The device supplies a facility for accurately counting all rate
limit matches.
Supported Practices.
* Accurate counting of rate limit rule matches is important
because it shows the frequency of attempts to violate policy.
This enables resources to be focused on areas of greatest need.
Current Implementations.
Assume, for example, that a ISP network implements anti-spoofing
egress rate limits (see [RFC2827]) on interfaces of its edge
routers that support single-homed stub networks. Counters could
enable the ISP to detect cases where large numbers of spoofed
packets are being sent. This may indicate that the customer is
performing potentially malicious actions (possibly in violation of
the ISPs Acceptable Use Policy), or that system(s) on the
customers network have been compromised by hackers and are being
(mis)used to launch attacks.
Considerations.
None.
2.2.12. Ability to Rate Limit To the Device - Ability to Display Rate
Limit Counters
Capability. Capability.
The device provides a mechanism to display rate limit counters. The device provides a mechanism to display filter counters.
Supported Practices. Supported Practices.
* Information that is collected is not useful unless it can be * Display Filter Counters (Section 7.14)
displayed in a useful manner.
Current Implementations. Current Implementations.
Assume there is a router with four interfaces. One is an up-link Assume there is a router with four interfaces. One is an up-link
to an ISP providing routes to the Internet. The other three to an ISP providing routes to the Internet. The other three
connect to separate internal networks. Assume that a host on one connect to separate internal networks. Assume that a host on one
of the internal networks has been compromised by a hacker and is of the internal networks has been compromised by a hacker and is
sending traffic with bogus source addresses. In such a situation, sending traffic with bogus source addresses. In such a situation,
it might be desirable to apply ingress rate limits to each of the it might be desirable to apply ingress filters to each of the
internal interfaces. Once the rate limits are in place, the internal interfaces. Once the filters are in place, the counters
counters can be examined to determine the source (inbound can be examined to determine the source (inbound interface) of the
interface) of the bogus packets. bogus packets.
Considerations. Considerations.
None. None.
2.2.13. Ability to Rate Limit To the Device - Ability to Display Rate 5. Counters
Limit Counters per Rate Limit Application
5.1. Ability to Display Filter Counters per Filter Application
Capability. Capability.
If it is possible for a rate limit to be applied more than once at If it is possible for a filter to be applied more than once at the
the same time, then the device provides a mechanism to display same time, then the device provides a mechanism to display filter
rate limit counters per rate limit application. counters per filter application.
Supported Practices. Supported Practices.
* It may make sense to apply the same rate limit definition * Counters (Section 7.15)
simultaneously more than one time (to different interfaces,
etc.). If so, it would be much more useful to know which
instance of a rate limit is matching than to know that some
instance was matching somewhere.
Current Implementations. Current Implementations.
One way to implement this capability would be to have the counter One way to implement this capability would be to have the counter
display mechanism show the interface (or other entity) to which display mechanism show the interface (or other entity) to which
the rate limit has been applied, along with the name (or other the filter has been applied, along with the name (or other
designator) for the rate limit. For example if a rate limit named designator) for the filter. For example if a filter named
"desktop_outbound" applied two different interfaces, say, "desktop_outbound" applied two different interfaces, say,
"ethernet0" and "ethernet1", the display should indicate something "ethernet0" and "ethernet1", the display should indicate something
like "matches of rate limit 'desktop_outbound' on ethernet0 ..." like "matches of filter 'desktop_outbound' on ethernet0 ..." and
and "matches of rate limit 'desktop_outbound' on ethernet1 ..." "matches of filter 'desktop_outbound' on ethernet1 ..."
Considerations. Considerations.
None. None.
2.2.14. Ability to Rate Limit To the Device - Ability to Reset Rate 5.2. Ability to Reset Filter Counters
Limit Counters
Capability. Capability.
It is possible to reset counters to zero on a per rate limit It is possible to reset counters to zero on a per filter basis.
basis.
For the purposes of this capability it would be acceptable for the For the purposes of this capability it would be acceptable for the
system to maintain two counters: an "absolute counter", C[now], system to maintain two counters: an "absolute counter", C[now],
and a "reset" counter, C[reset]. The absolute counter would and a "reset" counter, C[reset]. The absolute counter would
maintain counts that increase monotonically until they wrap or maintain counts that increase monotonically until they wrap or
overflow the counter. The reset counter would receive a copy of overflow the counter. The reset counter would receive a copy of
the current value of the absolute counter when the reset function the current value of the absolute counter when the reset function
was issued for that counter. Functions that display or retrieve was issued for that counter. Functions that display or retrieve
the counter could then display the delta (C[now] - C[reset]). the counter could then display the delta (C[now] - C[reset]).
Supported Practices. Supported Practices.
* This allows operators to get a current picture of the traffic * Reset Counters (Section 7.16)
matching particular rules/rate limit.
Current Implementations. Current Implementations.
Assume that rate limit counters are being used to detect internal Assume that filter counters are being used to detect internal
hosts that are infected with a new worm. Once it is believed that hosts that are infected with a new worm. Once it is believed that
all infected hosts have been cleaned up and the worm removed, the all infected hosts have been cleaned up and the worm removed, the
next step would be to verify that. One way of doing so would be next step would be to verify that. One way of doing so would be
to reset the rate limit counters to zero and see if traffic to reset the filter counters to zero and see if traffic indicative
indicative of the worm has ceased. of the worm has ceased.
Considerations.
None.
2.2.15. Ability to Rate Limit To the Device - Rate Limit Counters are
Accurate
Capability.
Rate limit counters are accurate. They reflect the actual number
of matching packets since the last counter reset. Rate limit
counters are be capable of holding up to 2^32 - 1 values without
overflowing and should be capable of holding up to 2^64 - 1
values.
Supported Practices.
* Inaccurate data can not be relied on as the basis for action.
Underreported data can conceal the magnitude of a problem.
Current Implementations.
If N packets matching a Rate limit are sent to/through a device,
then the counter should show N matches.
Considerations. Considerations.
None. None.
3. Functional Capabilities - Filtering transit traffic (data plane) 5.3. Filter Hits are Accurately Counted
The capabilities in this section are intended to list testable,
functional capabilities that are needed to operate devices securely.
Focusing on filtering transit packets on devices, controlling the
data plane.
3.1. Filtering THROUGH the Device
3.1.1. Ability to Filter Traffic on All Interfaces THROUGH the Device
Capability. Capability.
The device provides a means to filter IP packets on any interface The device supplies a facility for accurately counting all filter
implementing IP that are transit packets. matches.
Supported Practices. Supported Practices.
* Profile Current Traffic ([I-D.practices] Section x.x.x) * Filter Hits are Accurately Counted (Section 7.17)
* Block Malicious Packets (Section 5.2)
* Limit Sources of Management (Section 5.3)
Current Implementations. Current Implementations.
Many devices currently implement access control lists or filters Assume, for example, that a ISP network implements anti-spoofing
that allow filtering based on protocol and/or source/destination egress filters (see [RFC2827]) on interfaces of its edge routers
address and or source/destination port and allow these filters to that support single-homed stub networks. Counters could enable
be applied to interfaces. the ISP to detect cases where large numbers of spoofed packets are
being sent. This may indicate that the customer is performing
potentially malicious actions (possibly in violation of the ISPs
Acceptable Use Policy), or that system(s) on the customers network
have been "owned" by hackers and are being (mis)used to launch
attacks.
Considerations. Considerations.
None. None.
3.1.2. Ability to Filter Traffic Through the Device 5.4. Filter Counters are Accurate
Capability. Capability.
It is possible to apply the filtering mechanism to traffic that is Filter counters are accurate. They reflect the actual number of
flowing through the device via any of its interfaces - transit matching packets since the last counter reset. Filter counters
traffic. are be capable of holding up to 2^32 - 1 values without
overflowing and should be capable of holding up to 2^64 - 1
values.
Supported Practices. Supported Practices.
* This allows the operator to apply filters that protect the * Filter Hits are Accurately (Section 7.18)
networks supported by the device from attacks and unauthorized
access.
Current Implementations. Current Implementations.
Many devices currently implement access control lists or filters If N packets matching a filter are sent to/through a device, then
that allow filtering based on protocol and/or source/destination the counter should show N matches.
address and or source/destination port and allow these filters to
be applied to interfaces of the device for the purposes of
protecting the networks that connect to the device.
Examples of this might include filters that permit only HTTP from
known good sources and SMTP and SSH from a known subset of the
entire network, while dropping all other traffic.
Considerations. Considerations.
None. None.
3.1.3. Ability to Filter Traffic Through the Device - Minimal 6. Minimal Performance Degradation
Performance Degradation
Capability. Capability.
The device provides a means to filter packets without significant The device provides a means to filter packets without significant
performance degradation. This specifically applies to stateless performance degradation. This specifically applies to stateless
packet filtering operating on layer 3 (IP) and layer 4 (TCP or packet filtering operating on layer 3 (IP) and layer 4 (TCP or
UDP) headers, as well as normal packet forwarding information such UDP) headers, as well as normal packet forwarding information such
as incoming and outgoing interfaces. as incoming and outgoing interfaces.
The device is able to apply stateless packet filters on ALL The device is able to apply stateless packet filters on ALL
interfaces (up to the maximum number possible) simultaneously and interfaces (up to the total number of interfaces attached to the
with multiple filters per interface (e.g., inbound and outbound). device) simultaneously and with multiple filters per interface
(e.g., inbound and outbound).
The filtering of traffic through the device should not degrade The filtering of traffic destined to interfaces on the device,
performance significantly. including the loopback interface, should not degrade performance
significantly.
Supported Practices. Supported Practices.
* This enables the implementation of filters on necessary * Minimal Performance Degradation (Section 7.19)
services for the networks supported by the device. To the
extent that filtering causes degradation, it may not be
possible to apply filters that implement the appropriate
policies.
Current Implementations. Current Implementations.
Another way of stating the capability is that filter performance Another way of stating the capability is that filter performance
should not be the limiting factor in device throughput. If a should not be the limiting factor in device throughput. If a
device is capable of forwarding 30Mb/sec without filtering, then device is capable of forwarding 30Mb/sec without filtering, then
it should be able to forward the same amount with filtering in it should be able to forward the same amount with filtering in
place. place.
Considerations. Considerations.
skipping to change at page 40, line 18 skipping to change at page 20, line 9
Repeatable test data showing filter performance impact would be Repeatable test data showing filter performance impact would be
very useful in evaluating this capability. Tests should include very useful in evaluating this capability. Tests should include
such information as packet size, packet rate, number of interfaces such information as packet size, packet rate, number of interfaces
tested (source/destination), types of interfaces, routing table tested (source/destination), types of interfaces, routing table
size, routing protocols in use, frequency of routing updates, etc. size, routing protocols in use, frequency of routing updates, etc.
This capability does not address stateful filtering, filtering This capability does not address stateful filtering, filtering
above layer 4 headers or other more advanced types of filtering above layer 4 headers or other more advanced types of filtering
that may be important in certain operational environments. that may be important in certain operational environments.
3.1.4. Ability to Filter Through the Device - Specify Filter Actions Finally, if key infrastructure devices crash or experience severe
performance degradation when filtering under heavy load, or even
Capability. have the reputation of doing so, it is likely that security
personnel will be forbidden, by policy, from using filtering in
The device provides a mechanism to allow the specification of the ways that would otherwise be appropriate for fear that it might
action to be taken when a filter rule matches. Actions include cause unnecessary service disruption.
"permit" (allow the traffic), "reject" (drop with appropriate
notification to sender), and "drop" (drop with no notification to
sender).
Supported Practices.
* This capability is essential to the use of filters to enforce
policy.
Current Implementations.
Assume that your network's services live on several subnets, use
several protocols, and are controlled by several different parts
of your organization. There might exist a reason to have
disparate policies for access to the devices from these parts of
the organization.
Actions such as "permit", "deny", "drop" are essential in defining
the security policy for the services offered by the network
devices.
Considerations.
While silently dropping traffic without sending notification may
be the correct action in security terms, consideration should be
given to operational implications. See [RFC3360] for
consideration of potential problems caused by sending
inappropriate TCP Resets.
3.1.5. Ability to Filter Through the Device - Log Filter Actions
Capability.
It is possible to log all filter actions. The logging capability
is able to capture at least the following data:
* permit/deny/drop status
* source and destination IP address
* source and destination ports (if applicable to the protocol)
* which network element received the packet (interface, MAC
address or other layer 2 information that identifies the
previous hop source of the packet).
Supported Practices.
* Logging is essential for auditing, incident response, and
operations
Current Implementations.
Actions such as "permit", "deny", "drop" are essential in defining
the security policy for the services offered by the network
devices. Auditing the frequency, sources and destinations of
these attempts is essential for tracking ongoing issues today.
Considerations.
Logging can be burdensome to the network device, at no time should
logging cause performance degradation to the device or services
offered on the device.
3.1.6. Ability to Filter Through the Device - Specify Log Granularity
Capability. 7. Additional Operational Practices
It is possible to enable/disable logging on a per rule basis. This section describes practices not covered in [I-D.ietf-opsec-
current-practices]. They are included here to provide justification
for capabilities that reference them.
Supported Practices. 7.1. Profile Current Traffic
* The ability to tune the granularity of logging allows the This capability allows a network operator to monitor traffic across
operator to log the information that is desired and only the an active interface in the network at a minimal level. This helps to
information that is desired. Without this capability, it is determine probable cause for interface or network problems.
possible that extra data (or none at all) would be logged,
making it more difficult to find relevant information.
Current Implementations. The ability to separate and distinguish traffic at a layer-3 or
layer-4 level allows the operator to characterize beyond simple
interface counters the traffic in question. This is critical because
often the operator has no tools available for protocol analysis aside
from interface filters.
If a filter is defined that has several rules, and one of the 7.2. Block Malicious Packets
rules denies telnet (tcp/23) traffic, then it should be possible
to specify that only matches on the rule that denies telnet should
generate a log message.
Considerations. Blocking or limiting traffic deemed to be malicious is a key
component of application of any security policy's implementation.
Clearly it is critical to be able to implement a security policy on a
network.
None. Malicious packets could potentially be defined by any part of the
layer-3 or layer-4 headers of the IP packet. The ability to classify
or select traffic based on these criteria and take some action based
on that classification is critical to operations of a network.
3.1.7. Ability to Filter Through the Device - Ability to Filter 7.3. Limit Sources of Management
Protocols
Capability. Management of a network should be limited to only trusted hosts.
This implies that the network elements will be able to limit access
to management functions to these trusted hosts.
The device provides a means to filter traffic based on the value Currently operators will limit access to the management functions on
of the protocol field in the IP header. a network device to only the hosts that are trusted to perform that
function. This allows separation of critical functions and
protection of those functions on the network devices.
Supported Practices. 7.4. Select Traffic To the Device
* Being able to filter on protocol is necessary to allow This allows the operator to apply filters that protect the device
implementation of policy, secure operations and for support of itself from attacks and unauthorized access.
incident response.
Current Implementations. 7.5. Select Transit Traffic
Some denial of service attacks are based on the ability to flood This allows the operator to apply filters that protect the networks
the victim with ICMP traffic. One quick way (admittedly with some and assets surrounding the device from attacks and unauthorized
negative side effects) to mitigate the effects of such attacks is access.
to drop all ICMP traffic headed toward the victim.
Considerations. 7.6. Select Traffic Inbound and/or Outbound
None. This allows flexibility in applying filters at the place that makes
the most sense. It allows invalid or malicious traffic to be dropped
as close to the source as possible with the least impact on other
traffic transiting the interface(s) in question.
3.1.8. Ability to Filter Through the Device - Ability to Filter 7.7. Select Traffic by Protocol
Addresses
Capability.
The function is able to control the flow of traffic based on Being able to filter on protocol is necessary to allow implementation
source and/or destination IP address or blocks of addresses such of policy, secure operations and for support of incident response.
as Classless Inter-Domain Routing (CIDR) blocks. Filtering all traffic to a destination host is not often possible,
business requirements will dictate that critical traffic be permitted
if at all possible.
Supported Practices. 7.8. Select Traffic by Addresses
* 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
networks. networks.
Current Implementations. 7.9. Select Traffic by Protocol Header Field
One example of the use of address based filtering is to implement
ingress filtering per [RFC2827].
Considerations.
None.
3.1.9. Ability to Filter Through the Device - Ability to Filter
Protocol Header Fields
Capability.
The filtering mechanism supports filtering based on the value(s)
of any portion of the protocol headers for IP, ICMP, UDP and TCP.
It supports filtering of all other protocols supported at layer 3
and 4. It supports filtering based on the headers of higher level
protocols. It is possible to specify fields by name (e.g.,
"protocol = ICMP") rather than bit- offset/length/numeric value
(e.g., 72:8 = 1).
Supported Practices.
* Being able to filter on portions of the header is necessary to
allow implementation of policy, secure operations, and support
incident response.
Current Implementations.
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
ICMP type and code fields. One common example is to reject TCP
connection attempts (TCP, SYN bit set+ACK bit clear or SYN bit
set+ACK,FIN and RST bits clear). Another common example is the
ability to control what services are allowed in/out of a network.
It may be desirable to only allow inbound connections on port 80
(HTTP) and 443 (HTTPS) to a network hosting web servers.
Considerations.
None.
3.1.10. Ability to Filter Through the Device - Ability to Filter
Inbound and Outbound
Capability.
It is possible to filter both incoming and outgoing traffic on any
interface.
Supported Practices.
* This capability allows flexibility in applying filters at the
place that makes the most sense. It allows invalid or
malicious traffic to be dropped as close to the source as
possible.
Current Implementations.
It might be desirable on a border router, for example, to apply an
egress filter outbound on the interface that connects a site to
its external ISP to drop outbound traffic that does not have a
valid internal source address. Inbound, it might be desirable to
apply a filter that blocks all traffic from a site that is known
to forward or originate lots of junk mail.
Considerations.
None.
3.1.11. Ability to Filter Through the Device - Ability to Accurately
Count Filter Hits
Capability.
The device supplies a facility for accurately counting all filter
matches.
Supported Practices.
* Accurate counting of filter rule matches is important because
it shows the frequency of attempts to violate policy. This
enables resources to be focused on areas of greatest need.
Current Implementations.
Assume, for example, that a ISP network implements anti-spoofing
egress filters (see [RFC2827]) on interfaces of its edge routers
that support single-homed stub networks. Counters could enable
the ISP to detect cases where large numbers of spoofed packets are
being sent. This may indicate that the customer is performing
potentially malicious actions (possibly in violation of the ISPs
Acceptable Use Policy), or that system(s) on the customers network
have been "owned" by hackers and are being (mis)used to launch
attacks.
Considerations.
None.
3.1.12. Ability to Filter Through the Device - Ability to Display
Filter Counters
Capability.
The device provides a mechanism to display filter counters.
Supported Practices.
* Information that is collected is not useful unless it can be
displayed in a useful manner.
Current Implementations.
Assume there is a router with four interfaces. One is an up-link
to an ISP providing routes to the Internet. The other three
connect to separate internal networks. Assume that a host on one
of the internal networks has been compromised by a hacker and is
sending traffic with bogus source addresses. In such a situation,
it might be desirable to apply ingress filters to each of the
internal interfaces. Once the filters are in place, the counters
can be examined to determine the source (inbound interface) of the
bogus packets.
Considerations.
None. Being able to filter on portions of the header is necessary to allow
implementation of policy, secure operations, and support incident
response.
3.1.13. Ability to Filter Through the Device - Ability to Display 7.10. Specify Filter Actions
Filter Counters per Filter Application
Capability. This capability is essential to the use of filters to enforce policy.
With a defined filter classification of some traffic and no action
defined there is little use for the filter, actions must be included
in order to provide the requisite security.
If it is possible for a filter to be applied more than once at the 7.11. Specify Rate Limits
same time, then the device provides a mechanism to display filter
counters per filter application.
Supported Practices. This capability allows a filter to be used to rate limit a portion of
traffic through or to a device. It maybe desirable to limit SNMP
(UDP/161) traffic to a device, but not deny it completely.
Similarly, one might want to implement ICMP filters toward an
external network instead of discarding all ICMP traffic.
* It may make sense to apply the same filter definition 7.12. Specify Log Actions
simultaneously more than one time (to different interfaces,
etc.). If so, it would be much more useful to know which
instance of a filter is matching than to know that some
instance was matching somewhere.
Current Implementations. Logging is essential for auditing, incident response, and operations
One way to implement this capability would be to have the counter 7.13. Log Granularity
display mechanism show the interface (or other entity) to which
the filter has been applied, along with the name (or other
designator) for the filter. For example if a filter named
"desktop_outbound" applied two different interfaces, say,
"ethernet0" and "ethernet1", the display should indicate something
like "matches of filter 'desktop_outbound' on ethernet0 ..." and
"matches of filter 'desktop_outbound' on ethernet1 ..."
Considerations.
None. The ability to tune the granularity of logging allows the operator to
log the information that is desired and only the information that is
desired. Without this capability, it is possible that extra data (or
none at all) would be logged, making it more difficult to find
relevant information.
3.1.14. Ability to Filter Through the Device - Ability to Reset Filter 7.14. Display Filter Counters
Counters
Capability. Information that is collected is not useful unless it can be
displayed.
It is possible to reset counters to zero on a per filter basis. 7.15. Counters
For the purposes of this capability it would be acceptable for the It may make sense to apply the same filter definition simultaneously
system to maintain two counters: an "absolute counter", C[now], more than one time (to different interfaces, etc.). If so, it would
and a "reset" counter, C[reset]. The absolute counter would be much more useful to know which instance of a filter is matching
maintain counts that increase monotonically until they wrap or than to know that some instance was matching somewhere.
overflow the counter. The reset counter would receive a copy of
the current value of the absolute counter when the reset function
was issued for that counter. Functions that display or retrieve
the counter could then display the delta (C[now] - C[reset]).
Supported Practices. 7.16. Ability to Reset Filter Counters
* This allows operators to get a current picture of the traffic This allows operators to get a current picture of the traffic
matching particular rules/filters. matching particular rules/filters.
Current Implementations. 7.17. Filter Hits are Accurately Counted
Assume that filter counters are being used to detect internal
hosts that are infected with a new worm. Once it is believed that
all infected hosts have been cleaned up and the worm removed, the
next step would be to verify that. One way of doing so would be
to reset the filter counters to zero and see if traffic indicative
of the worm has ceased.
Considerations.
None.
3.1.15. Ability to Filter Through the Device - Filter Counters are
Accurate
Capability.
Filter counters are accurate. They reflect the actual number of
matching packets since the last counter reset. Filter counters
are be capable of holding up to 2^32 - 1 values without
overflowing and should be capable of holding up to 2^64 - 1
values.
Supported Practices.
* Inaccurate data can not be relied on as the basis for action.
Underreported data can conceal the magnitude of a problem.
Current Implementations.
If N packets matching a filter are sent to/through a device, then
the counter should show N matches.
Considerations.
None.
3.2. Rate Limit THROUGH the Device
3.2.1. Ability to Rate limit Traffic on All Interfaces THROUGH the
Device
Capability.
The device provides a means to rate limit IP packets on any
interface implementing IP that are transit packets.
Supported Practices.
* Profile Current Traffic ([I-D.practices] Section x.x.x)
* Block Malicious Packets (Section 5.2)
* Limit Sources of Management (Section 5.3)
Current Implementations.
Many devices currently implement rate limits that allow rate
limiting based on protocol and/or source/destination address and
or source/destination port or raw bandwidth and allow these limits
to be applied to interfaces.
Considerations.
None.
3.2.2. Ability to Rate Limit Traffic Through the Device
Capability.
It is possible to apply the rate-limiting mechanism to traffic
that is transiting the device via any of its interfaces.
Supported Practices.
* This allows the operator to apply rate-limits that protect the
networks transiting the device from attacks and unauthorized
access.
Current Implementations.
Many devices currently implement rate-limits that allow limiting
based on protocol and/or source/destination address and or source/
destination port and allow these limits to be applied to services
offered by the networks which transit the device.
Examples of this might include rate-limits that permit SSH traffic
rates up to 100 megabits per second from an authorized peer, while
dropping all other traffic addressed to the network which exceeds
this limit.
Considerations.
None.
3.2.3. Ability to Rate Limit Traffic Through the Device - Minimal
Performance Degradation
Capability.
The device provides a means to rate-limit packets without
significant performance degradation.
The device is able to apply rate-limits on ALL interfaces (up to
the maximum number possible) simultaneously and with multiple
rate-limits per interface (e.g., inbound, outbound, differing
traffic classifications in either direction).
The rate-limiting of traffic destined to networks transiting the
device should not degrade performance significantly.
Supported Practices.
* This enables the implementation of rate-limits on whichever
services are necessary. To the extent that rate-limiting
causes degradation, it may not be possible to apply rate-limits
that implement the appropriate policies.
Current Implementations.
Another way of stating the capability is that rate-limit
performance should not be the limiting factor in device
throughput. If a device is capable of forwarding 30Mb/sec without
rate-limits, then it should be able to forward the same amount
with rate-limits in place.
Considerations.
The definition of "significant" is subjective. At one end of the
spectrum it might mean "the application of rate-limits may cause
the box to crash". At the other end would be a throughput loss of
less than one percent with tens of thousands of rate-limits
applied. The level of performance degradation that is acceptable
will have to be determined by the operator.
Repeatable test data showing rate-limiting performance impact
would be very useful in evaluating this capability. Tests should
include such information as packet size, packet rate, number of
interfaces tested (source/destination), types of interfaces,
routing table size, routing protocols in use, frequency of routing
updates, etc.
3.2.4. Ability to Rate Limit Through the Device - Specify Rate Limit
Actions
Capability.
The device provides a mechanism to allow the specification of the
action to be taken when a rate-limit rule matches. Actions
include "permit" (allow the traffic), "reject" (drop with
appropriate notification to sender), and "drop" (drop with no
notification to sender).
Supported Practices.
* This capability is essential to the use of rate limits to
enforce policy.
Current Implementations.
Assume that your management devices for deployed networking
devices live on several subnets, use several protocols, and are
controlled by several different parts of your organization. There
might exist a reason to have disparate policies for access to the
devices from these parts of the organization. Further you may
want to limit traffic levels for these types of traffic from these
known sources as close to the sources as possible via interface
rate limits implemented on the supporting network devices for
those source networks.
Actions such as "permit", "deny", "drop" are essential in defining
the security policy for the services offered by the network
devices.
Considerations.
While silently dropping traffic without sending notification may
be the correct action in security terms, consideration should be
given to operational implications. See [RFC3360] for
consideration of potential problems caused by sending
inappropriate TCP Resets.
3.2.5. Ability to Rate Limit Through the Device - Log Rate Limit
Actions
Capability.
It is possible to log rate limit actions. The logging capability
is able to capture at least the following data:
* permit/deny/drop status
* source and destination IP address
* source and destination ports (if applicable to the protocol)
* which network element received the packet (interface, MAC
address or other layer 2 information that identifies the
previous hop source of the packet).
Supported Practices.
* Logging is essential for auditing, incident response, and
operations
Current Implementations.
Actions such as "permit", "deny", "drop" are essential in defining
the security policy for the services offered by the network
devices. Auditing the frequency, sources and destinations of
these attempts is essential for tracking ongoing issues today.
Considerations.
Logging can be burdensome to the network device, at no time should
logging cause performance degradation to the device or services
offered on the device.
3.2.6. Ability to Rate Limit Through the Device - Specify Log
Granularity
Capability.
It is possible to enable/disable logging on a per rule basis.
Supported Practices.
* The ability to tune the granularity of logging allows the
operator to log the information that is desired and only the
information that is desired. Without this capability, it is
possible that extra data (or none at all) would be logged,
making it more difficult to find relevant information.
Current Implementations.
If a rate limit is defined that has several rules, and one of the
rules denies telnet (tcp/23) connections, then it should be
possible to specify that only matches on the rule that denies
telnet should generate a log message.
Considerations.
None.
3.2.7. Ability to Rate Limit Through the Device - Ability to Rate Limit
Protocols
Capability.
The device provides a means to rate limit traffic based on the
value of the protocol field in the IP header.
Supported Practices.
* Being able to rate limit on protocol is necessary to allow
implementation of policy, secure operations and for support of
incident response.
Current Implementations.
Some denial of service attacks are based on the ability to flood
the victim with ICMP traffic. One quick way (admittedly with some
negative side effects) to mitigate the effects of such attacks is
to rate limit all ICMP traffic headed toward the victim.
Considerations.
None.
3.2.8. Ability to Rate Limit Through the Device - Ability to Rate Limit
Addresses
Capability.
The function is able to control the flow of traffic based on
source and/or destination IP address or blocks of addresses such
as Classless Inter-Domain Routing (CIDR) blocks.
Supported Practices.
* The capability to rate limit on addresses and address blocks is
a fundamental tool for establishing boundaries between
different networks.
Current Implementations.
One example of the use of address based rate limits is to
implement ingress filtering per [RFC2827].
Considerations.
None.
3.2.9. Ability to Rate Limit Through the Device - Ability to Rate Limit
Protocol Header Fields
Capability.
The rate limit mechanism supports rate limiting based on the
value(s) of any portion of the protocol headers for IP, ICMP, UDP
and TCP. It supports rate limiting of all other protocols
supported at layer 3 and 4. It supports rate limiting based on
the headers of higher level protocols. It is possible to specify
fields by name (e.g., "protocol = ICMP") rather than bit- offset/
length/numeric value (e.g., 72:8 = 1).
Supported Practices.
* Being able to rate limit on portions of the header is necessary
to allow implementation of policy, secure operations, and
support incident response.
Current Implementations.
This capability implies that it is possible to rate limit based on
TCP 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
"inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear
or SYN bit set+ACK,FIN and RST bits clear). Another common
example is the ability to control what services are allowed in/out
of a network. It may be desirable to only allow inbound
connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting
web servers.
Considerations.
None.
3.2.10. Ability to Rate Limit Through the Device - Ability to Rate
Limit Inbound and Outbound
Capability.
It is possible to rate limit both incoming and outgoing traffic on
any interface to or from any transiting network.
Supported Practices.
* This capability allows flexibility in applying rate limits at
the place that makes the most sense. It allows invalid or
malicious traffic to be dropped as close to the source as
possible.
Current Implementations.
It might be desirable on a router to apply an egress rate limit to
its external connections to limit outbound traffic that does not
have a high priority. Inbound, it might be desirable to apply a
rate limit to all traffic of a certain classification in order to
preserve limited resources on the sported networks behind the
device.
Considerations.
None.
3.2.11. Ability to Rate Limit Through the Device - Ability to
Accurately Count Rate Limit Hits
Capability.
The device supplies a facility for accurately counting all rate
limit matches.
Supported Practices.
* Accurate counting of rate limit rule matches is important
because it shows the frequency of attempts to violate policy.
This enables resources to be focused on areas of greatest need.
Current Implementations.
Assume, for example, that a ISP network implements anti-spoofing
egress rate limits (see [RFC2827]) on interfaces of its edge
routers that support single-homed stub networks. Counters could
enable the ISP to detect cases where large numbers of spoofed
packets are being sent. This may indicate that the customer is
performing potentially malicious actions (possibly in violation of
the ISPs Acceptable Use Policy), or that system(s) on the
customers network have been compromised by hackers and are being
(mis)used to launch attacks.
Considerations.
None.
3.2.12. Ability to Rate Limit Through the Device - Ability to Display
Rate Limit Counters
Capability.
The device provides a mechanism to display rate limit counters.
Supported Practices.
* Information that is collected is not useful unless it can be
displayed in a useful manner.
Current Implementations.
Assume there is a router with four interfaces. One is an up-link
to an ISP providing routes to the Internet. The other three
connect to separate internal networks. Assume that a host on one
of the internal networks has been compromised by a hacker and is
sending traffic with bogus source addresses. In such a situation,
it might be desirable to apply ingress rate limits to each of the
internal interfaces. Once the rate limits are in place, the
counters can be examined to determine the source (inbound
interface) of the bogus packets.
Considerations.
None.
3.2.13. Ability to Rate Limit Through the Device - Ability to Display
Rate Limit Counters per Rate Limit Application
Capability.
If it is possible for a rate limit to be applied more than once at
the same time, then the device provides a mechanism to display
rate limit counters per rate limit application.
Supported Practices.
* It may make sense to apply the same rate limit definition
simultaneously more than one time (to different interfaces,
etc.). If so, it would be much more useful to know which
instance of a rate limit is matching than to know that some
instance was matching somewhere.
Current Implementations.
One way to implement this capability would be to have the counter
display mechanism show the interface (or other entity) to which
the rate limit has been applied, along with the name (or other
designator) for the rate limit. For example if a rate limit named
"desktop_outbound" applied two different interfaces, say,
"ethernet0" and "ethernet1", the display should indicate something
like "matches of rate limit 'desktop_outbound' on ethernet0 ..."
and "matches of rate limit 'desktop_outbound' on ethernet1 ..."
Considerations.
None.
3.2.14. Ability to Rate Limit Through the Device - Ability to Reset
Rate Limit Counters
Capability.
It is possible to reset counters to zero on a per rate limit
basis.
For the purposes of this capability it would be acceptable for the
system to maintain two counters: an "absolute counter", C[now],
and a "reset" counter, C[reset]. The absolute counter would
maintain counts that increase monotonically until they wrap or
overflow the counter. The reset counter would receive a copy of
the current value of the absolute counter when the reset function
was issued for that counter. Functions that display or retrieve
the counter could then display the delta (C[now] - C[reset]).
Supported Practices.
* This allows operators to get a current picture of the traffic
matching particular rules/rate limit.
Current Implementations.
Assume that rate limit counters are being used to detect internal
hosts that are infected with a new worm. Once it is believed that
all infected hosts have been cleaned up and the worm removed, the
next step would be to verify that. One way of doing so would be
to reset the rate limit counters to zero and see if traffic
indicative of the worm has ceased.
Considerations.
None.
3.2.15. Ability to Rate Limit Through the Device - Rate Limit Counters
are Accurate
Capability.
Rate limit counters are accurate. They reflect the actual number
of matching packets since the last counter reset. Rate limit
counters are be capable of holding up to 2^32 - 1 values without
overflowing and should be capable of holding up to 2^64 - 1
values.
Supported Practices.
* Inaccurate data can not be relied on as the basis for action.
Underreported data can conceal the magnitude of a problem.
Current Implementations.
If N packets matching a Rate limit are sent to/through a device,
then the counter should show N matches.
Considerations.
None.
4. Functional Capabilities - Filtering Layer 2 Attributes
The capabilities in this section are intended to list testable,
functional capabilities that are needed to operate devices securely.
A layer-2 domain permits all devices in the domain to establish
communication at layer-2. Devices thus connected have an implicit
trust relationship among themselves. If there are devices in a
layer-2 domain which are at different trust levels, we may want to
filter traffic between such devices based on the trust levels or any
other fields in the layer-2 header. The following filtering
capabilities are required at layer-2.
4.1. Filtering Layer 2
4.1.1. Ability to partition layer-2 network to provide different levels
of security
Capability.
The device provides a means to partition the physical layer-2
domain into multiple virtual domains, thus allowing the filtering
of unwarranted traffic.
Supported Practices.
* Being able to partition a layer-2 domain provides the same
level of security within a layer-2 domain as can be guaranteed
if they were different layer-2 domains.
Current Implementations.
Most Ethernet networks use the concept of VLAN [8021Q] to
partition a layer-2 broadcast domain. Private VLAN's [PVLAN]
allow further partitioning of VLANs's into smaller domains.
Considerations.
Not all layer-2 network technologies may lend themselves to
virtual partitioning.
4.1.2. Ability to restrict access to specified hardware (MAC) addresses
Capability.
The device provides a means to filter traffic based on the source
and/ or destination hardware address.
Supported Practices.
* Being able to filter on hardware Address provides an ability to
block frames between devices in the same layer-2 domain to
communicate.
Current Implementations.
The ability to filter and monitor traffic in layer-2 allows for
security at layer-2 itself, between devices on the same network.
Allowing filtering based on hardware address allows a simple
filtering interface to the administrator to apply simple policy
rules.
Considerations.
Different Link layer technologies use different addressing
mechanisms.
4.1.3. Ability to restrict based on layer-2 packet type [etherType]
field
Capability.
The device provides a means to filter packets based on the packet
type field in the layer-2 header.
Supported Practices.
* Being able to filter on packets based on the packet type field
helps in preventing packets not understandable by a particular
device to be processed by it.
Current Implementations.
The ability to filter and monitor traffic in layer-2 allows for
security at layer-2 itself. This capability can also prevent IPX
packets to inadvertently be sent to an IP device and vice versa.
Considerations.
None.
5. Additional Operational Practices
This section describes practices not covered in [I-D.practices].
They are included here to provide justification for capabilities that
reference them.
5.1. Profile Current Traffic
Discuss practice. Use same format as [I-D.practices]. Accurate counting of filter rule matches is important because it
shows the frequency of attempts to violate policy. This enables
resources to be focused on areas of greatest need.
5.2. Block Malicious Packets 7.18. Filter Hits are Accurate
Discuss practice. Use same format as [I-D.practices]. Inaccurate data can not be relied on as the basis for action. Under-
reported data can conceal the magnitude of a problem.
5.3. Limit Sources of Management 7.19. Minimal Performance Degredation
Discuss practice. Use same format as [I-D.practices]. This enables the implementation of filters on whichever services are
necessary. To the extent that filtering causes degradation, it may
not be possible to apply filters that implement the appropriate
policies.
6. 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 [I-D.practices] that they capabilities listed cite practices in [I-D.ietf-opsec-current-
are intended to support. [I-D.practices] defines the threat practices] that they are intended to support. [I-D.ietf-opsec-
model, practices and lists justifications for each practice. current-practices] defines the threat model, practices and lists
justifications for each practice.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 9. Non-normative References
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. 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.
[8021Q] "802.1Q - Virtual LANs", IEEE Standard 802.1Q - Virtual [I-D.lewis-infrastructure-security]
LANs, August 2001. Lewis, D., "Service Provider Infrastructure Security",
draft-lewis-infrastructure-security-00 (work in progress),
June 2006.
[I-D.practices] [I-D.savola-rtgwg-backbone-attacks]
Kaeo, M., "Operational Security Current Practices", Savola, P., "Backbone Infrastructure Attacks and
Internet-Draft (to be published) Protections", draft-savola-rtgwg-backbone-attacks-01 (work
draft-ietf-opsec-current-practices-00, February 2005. in progress), June 2006.
[PVLAN] HomChaudhuri, S. and M. Foschiano, "Private VLANs: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Addressing VLAN scalability and security issues in a Defeating Denial of Service Attacks which employ IP Source
multi-client environment", Internet Draft (to be Address Spoofing", BCP 38, RFC 2827, May 2000.
published) draft-sanjib-private-vlan-02, June 2004.
[RFC2828] Shirey, R., "Internet Security Glossary", RFC rfc2828.txt, [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828,
May 2000. May 2000.
[RFC3631] Bellovin, S. and J. Schiller, "Security Mechanisms for the [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful",
Internet", RFC 3631, December 2003. 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 editors gratefully acknowledges the contributions of: The editors gratefully acknowledges the contributions of:
o xxx
o yyy
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.
o Others who have provided significant feedback are: zzz
o This listing is intended to acknowledge contributions, not to
imply that the individual or organizations approve the content of
this document.
o Apologies to those who commented on/contributed to the document
and were not listed.
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 The MITRE Corporation
7515 Colshire Drive, M/S WEST 7515 Colshire Drive, M/S WEST
McLean, Virginia 22102-7508 McLean, Virginia 22102-7508
U.S.A. U.S.A.
Phone: +1 703 488 9740 Phone: +1 703 488 9740
Email: gmjones@mitre.org Email: gmjones@mitre.org
Vishwas Manral
IPInfusion,
Bangalore,
India
Phone: +91-98456-61911
Email: vishwas@ipinfusion.com
Intellectual Property Statement Intellectual Property Statement
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
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 73, line 41 skipping to change at page 27, line 41
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 AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 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.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 145 change blocks. 
1816 lines changed or deleted 360 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/