None.                                                          C. Morrow
Internet-Draft                                        UUNET Technologies
Expires: October 12, September 25, 2006                                     G. Jones
                                                   The MITRE Corporation
                                                               V. Manral
                                                              IPInfusion
                                                            May 12,
                                                          March 24, 2006

 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

   By submitting this Internet-Draft, each author represents that any
   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
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 12, September 25, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   [I-D.practices]

   [I-D.ietf-opsec-current-practices] lists operator practices related
   to securing networks.  This document lists filtering and rate
   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.
   This is done to leave room for deployment of new technologies that
   implement the capability.  Each capability cites the practices it
   supports.  Current implementations that support the capability are
   cited.  Special considerations are discussed as appropriate listing
   operational and resource constraints, limitations of current
   implementations, tradeoffs, etc.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6  4
     1.1.  Threat Model . . . . . . . . . . . . . . . . . . . . . . .  6  4
     1.2.  Capabilities or Requirements ?  Format . . . . . . . . . . . . . .  7
     1.3.  Format . . . . . . . . . . . .  5
   2.  Packet Selction for Managemnet and Data Plane Controls . . . .  6
   3.  Packet Selection Criteria  . . . . . . . . . .  7
     1.4.  Definitions . . . . . . . .  7
     3.1.  Select Traffic on All Interfaces . . . . . . . . . . . . .  7
     3.2.  Select Traffic To the Device . .  7
   2.  Functional Capabilities	- Filtering non-transit traffic
       (management plane) . . . . . . . . . . . . .  7
     3.3.  Select Transit Traffic . . . . . . . . .  9
     2.1.  Filtering TO the Device . . . . . . . . .  8
     3.4.  Select Inbound and/or Outbound . . . . . . . .  9
       2.1.1.  Ability to Filter Traffic on All Interfaces TO the
               Device . . . . . .  8
     3.5.  Select by Protocols  . . . . . . . . . . . . . . . . . . .  9
       2.1.2.  Ability to Filter Traffic To the Device
     3.6.  Select by Addresses  . . . . . . . . . 10
       2.1.3.  Ability to Filter Traffic To the Device - Minimal
               Performance Degradation . . . . . . . . . .  9
     3.7.  Select by Protocol Header Fields . . . . . 10
       2.1.4.  Ability to Filter To the Device - Specify Filter
               Actions . . . . . . . . 10
   4.  Actions  . . . . . . . . . . . . . . . . . 12
       2.1.5.  Ability to Filter To the Device - Log Filter
               Actions . . . . . . . . . . 12
     4.1.  Specify Filter Actions . . . . . . . . . . . . . 13
       2.1.6.  Ability to Filter To the Device - Specify Log
               Granularity . . . . . 12
     4.2.  Specify Rate Limits  . . . . . . . . . . . . . . . . . 14
       2.1.7.  Ability to Filter To the Device - Ability to
               Filter Protocols . . 12
     4.3.  Specify Log Actions  . . . . . . . . . . . . . . . . . 15
       2.1.8.  Ability to Filter To the Device - Ability to
               Filter Addresses . . 13
     4.4.  Specify Log Granularity  . . . . . . . . . . . . . . . . . 15
       2.1.9.  Ability to Filter To the Device - 14
     4.5.  Ability to Display Filter Protocol Header Fields Counters . . . . . . . . . . . . 16
       2.1.10. Ability to Filter To the Device - Ability to
               Filter Inbound and Outbound 14
   5.  Counters . . . . . . . . . . . . . 17
       2.1.11. Ability to Filter To the Device - Ability to
               Accurately Count Filter Hits . . . . . . . . . . . . . 18
       2.1.12. Ability to Filter To the Device - . 16
     5.1.  Ability to Display Filter Counters per Filter
           Application  . . . . . . . . . . . . . . . 19
       2.1.13. Ability to Filter To the Device - Ability to
               Display Filter Counters per Filter Application . . . . 20
       2.1.14. Ability to Filter To the Device - . . . . 16
     5.2.  Ability to Reset Filter Counters . . . . . . . . . . . . . 16
     5.3.  Filter Hits are Accurately Counted . . . . . . 21
       2.1.15. Ability to Filter To the Device - . . . . . . 17
     5.4.  Filter Counters are Accurate . . . . . . . . . . . . . . . 17
   6.  Minimal Performance Degradation  . . . . . . 22
     2.2.  Rate Limit TO the Device . . . . . . . . . . . 19
   7.  Additional Operational Practices . . . . . . 22
       2.2.1.  Ability to Rate limit Traffic on All Interfaces TO
               the Device . . . . . . . . . 21
     7.1.  Profile Current Traffic  . . . . . . . . . . . . . 22
       2.2.2.  Ability to Rate Limit Traffic To the Device . . . . 21
     7.2.  Block Malicious Packets  . 23
       2.2.3.  Ability to Rate Limit Traffic To the Device -
               Minimal Performance Degradation . . . . . . . . . . . 24
       2.2.4.  Ability to Rate Limit To the Device - Specify Rate
               Limit Actions . . . . . 21
     7.3.  Limit Sources of Management  . . . . . . . . . . . . . . . 26
       2.2.5.  Ability to Rate Limit 21
     7.4.  Select Traffic To the Device - Log Rate
               Limit Actions  . . . . . . . . . . . . . . . . 21
     7.5.  Select Transit Traffic . . . . 27
       2.2.6.  Ability to Rate Limit To the Device - Specify Log
               Granularity . . . . . . . . . . . . . . 22
     7.6.  Select Traffic Inbound and/or Outbound . . . . . . . 28
       2.2.7.  Ability to Rate Limit To the Device - Ability to
               Rate Limit Protocols . . . 22
     7.7.  Select Traffic by Protocol . . . . . . . . . . . . . . 28
       2.2.8.  Ability to Rate Limit To the Device - Ability to
               Rate Limit Addresses . . 22
     7.8.  Select Traffic by Addresses  . . . . . . . . . . . . . . . 29
       2.2.9.  Ability to Rate Limit To the Device - Ability to
               Rate Limit 22
     7.9.  Select Traffic by Protocol Header Fields Field  . . . . . . . . . 22
     7.10. Specify Filter Actions . 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 . . . . . . 22
     7.11. Specify Rate Limit Hits Limits  . . . . . . . . . . . 32
       2.2.12. Ability to Rate Limit To the Device - Ability to
               Display Rate Limit Counters . . . . . . . . 22
     7.12. Specify Log Actions  . . . . . 33
       2.2.13. Ability to Rate Limit To the Device - Ability to
               Display Rate Limit Counters per Rate Limit
               Application . . . . . . . . . . . . . . 23
     7.13. Log Granularity  . . . . . . . 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 23
     7.14. Display Filter Counters are Accurate  . . . . . . . . . . . . . . . . 35
   3.  Functional Capabilities	- Filtering transit traffic (data
       plane) .  . . . . . . . . . . . . . . . . . 23
     7.15. Counters . . . . . . . . . . 37
     3.1.  Filtering THROUGH the Device . . . . . . . . . . . . . . . 37
       3.1.1. 23
     7.16. Ability to Reset Filter Traffic on All Interfaces
               THROUGH the Device . . . . . Counters . . . . . . . . . . . . . 37
       3.1.2.  Ability to 23
     7.17. Filter Traffic Through the Device . . . . Hits are Accurately Counted . 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 23
     7.18. Filter Actions . . . Hits are Accurate . . . . . . . . . . . . . . . . . 40
       3.1.5.  Ability to Filter Through the Device - Log Filter
               Actions 23
     7.19. Minimal Performance Degredation  . . . . . . . . . . . . . 23
   8.  Security Considerations  . . . . . . . . . . 41
       3.1.6.  Ability to Filter Through the Device - Specify Log
               Granularity . . . . . . . . . 24
   9.  Non-normative References . . . . . . . . . . . . 42
       3.1.7.  Ability to Filter Through the Device - Ability to
               Filter Protocols . . . . . . . 24
   Appendix A.  Acknowledgments . . . . . . . . . . . . 43
       3.1.8.  Ability to Filter Through the Device - Ability to
               Filter Addresses . . . . . . . 25
   Authors' 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 26
   Intellectual Property and Outbound  . . . Copyright Statements . . . . . . . . . . 45
       3.1.11. Ability to Filter Through 27

1.  Introduction

   This document is defined in 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

   This document is defined in the context of [I-D.practices].
   [I-D.practices] defines the goals, motivation, scope, definitions,
   intended audience,threat model, potential attacks and give
   justifications for each of the practices.  Many of the capabilities
   listed here refine or add to capabilities listed in [RFC3871]

1.1.  Threat Model

   Threats in today's networked environment range from simple packet
   floods with overwhelming bandwidth toward a leaf network to subtle
   attacks aimed at subverting known vulnerabilities in existing
   applications.  The attacked network or host might not be an end user,
   it may be the networking device or links inside the provider core.

   Networks must have the ability to place mitigation in order to limit
   these threats.  These mitigation steps could include routing updates,
   traffic filters, and routing filters.  It is possible that the
   mitigation steps might have to affect transit traffic as well as
   traffic destined to the device on which the mitigation steps are
   activated.

   The scope of the threat includes simply denying services to an
   individual customer on one side of the scale to exploiting a newly
   discovered protocol vulnerability which affects the entire provider
   core.  The obvious risk to the business requires mitigation
   capabilities which can span this range of threats.

   Threat: An indication of impending danger or harm to the network or
   its parts.  This could be formed from the projected loss of revenue
   to the business.  Additionally, it could be formed from the increased
   cost to the business caused by the event. (more interfaces, more
   bandwidth, more personnel to support the increased size or
   complexity)

   Risk: The possibility of suffering harm or loss of network services
   due to a threat.

   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.
   This could also be a much smaller stream of packets created with the
   intent of exploiting a vulnerability in the infrastructure of the
   network.

   Asset: Either a customer, network device or network link.  Any of
   these could be assets from a business perspective.

   These terms are more completely defined in RFC2828 we have added some
   scope specific information only.

1.2.  Capabilities or Requirements ?

   Capabilities may or may not be requirements.  That is a local
   determination that must be made by each operator with reference to
   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

   Each capability has the following subsections:

   o  Capability (what)

   o  Supported Practices (why)

   o  Current Implementations (how)

   o  Considerations (caveats, resource issues, protocol issues, etc.)

   The Capability section describes a feature to be supported by the
   device.  The Supported Practice section cites practices described in
   [I-D.practices] that are supported by this capability.  The Current
   Implementation section is intended to give examples of
   implementations of the capability, citing technology and standards
   current at the time of writing.  See [RFC3631].  It is expected that
   the choice of features to implement the capabilities will change over
   time.  The Considerations section lists operational and resource
   constraints, limitations of current implementations, tradeoffs, etc.

   [EDITORS NOTE: this is a first draft.  At least two editing passes
   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

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
      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
      assign the correct requirement levels ("MUST", "SHOULD",
      "MAY"...).  It must be noted that different organizations,
      operational environments, policies and legal environments will
      generate different requirement levels.

2.  Functional Capabilities	- Filtering non-transit traffic (management
    plane)

   The capabilities in this section are intended to list testable,
   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

2.1.1.  Ability to Filter Traffic on All Interfaces TO the Device

   Capability.

      The device provides a means to filter 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 access control lists or filters
      that allow filtering based on protocol and/or source/destination
      address and or source/destination port and allow these filters to
      be applied to interfaces.

   Considerations.

      None.

2.1.2.  Ability to Filter Traffic To the Device

   Capability.

      It is possible to apply the filtering mechanism to traffic that is
      addressed directly to the device via any of its interfaces -
      including loopback interfaces.

   Supported Practices.

      *  This allows the operator to apply filters that protect the
         device itself from attacks and unauthorized access.

   Current Implementations.

      Many devices currently implement access control lists or filters
      that allow filtering based on protocol and/or source/destination
      address and or source/destination port and allow these filters to
      be applied to services offered by the device.

      Examples of this might include filters that permit only BGP from
      peers and SNMP and SSH from an authorized management segment and
      directed to the device itself, while dropping all other traffic
      addressed to the device.

   Considerations.

      None.

2.1.3.  Ability to Filter Traffic To the Device - Minimal Performance
        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.

      The device provides a mechanism to allow the specification of the
      action to be taken when a filter 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 filters 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.

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

2.1.6.  Ability to Filter To 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 filter 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.

2.1.7.  Ability to Filter To the Device - Ability to Filter Protocols

   Capability.

      The device provides a means to filter traffic based on the value
      of the protocol field in the IP header.

   Supported Practices.

      *  Being able to filter 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 drop all ICMP traffic headed toward the victim.

   Considerations.

      None.

2.1.8.  Ability to Filter To the Device - Ability to Filter 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 filter 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 filtering is to implement
      ingress filtering per [RFC2827].

   Considerations.

      None.

2.1.9.  Ability to Filter To 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
      "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.1.10.  Ability to Filter To 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.

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

   Capability.

      It is possible to apply the rate-limiting mechanism to traffic
      that is addressed directly to the device via any of its interfaces
      - including loopback interfaces.

   Supported Practices.

      *  This allows the operator to apply rate-limits that protect the
         device itself 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 device.

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

2.2.4.  Ability to Rate Limit To 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.

      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.2.5.  Ability to Rate Limit To 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.

2.2.6.  Ability to Rate Limit To 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.

2.2.7.  Ability to Rate Limit To 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.

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.

      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.

2.2.13.  Ability to Rate Limit To 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.

2.2.14.  Ability to Rate Limit To 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.

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.

      None.

3.  Functional Capabilities	- Filtering transit traffic (data plane)

   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.

      The device provides a means to filter 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 access control lists or filters
      that allow filtering based on protocol and/or source/destination
      address and or source/destination port and allow these filters to
      be applied to interfaces.

   Considerations.

      None.

3.1.2.  Ability to Filter Traffic Through the Device

   Capability.

      It is possible to apply the filtering mechanism to traffic that is
      flowing through the device via any of its interfaces - transit
      traffic.

   Supported Practices.

      *  This allows the operator to apply filters that protect the
         networks supported by the device from attacks and unauthorized
         access.

   Current Implementations.

      Many devices currently implement access control lists or filters
      that allow filtering based on protocol and/or source/destination
      address and or source/destination port and allow these filters to
      be applied to 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.

      None.

3.1.3.  Ability to Filter Traffic Through the Device - Minimal
        Performance 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 through the device should not degrade
      performance significantly.

   Supported Practices.

      *  This enables the implementation of filters on necessary
         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.

      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.

3.1.4.  Ability to Filter Through the Device - Specify Filter Actions

   Capability.

      The device provides a mechanism to allow the specification of the
      action to be taken when a filter 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 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.

      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 filter is defined that has several rules, and one of the
      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.

      None.

3.1.7.  Ability to Filter Through the Device - Ability to Filter
        Protocols

   Capability.

      The device provides a means to filter traffic based on the value
      of the protocol field in the IP header.

   Supported Practices.

      *  Being able to filter 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 drop all ICMP traffic headed toward the victim.

   Considerations.

      None.

3.1.8.  Ability to Filter Through the Device - Ability to Filter
        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 filter 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 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 context of [I-D.ietf-opsec-current-
   practices].  [I-D.ietf-opsec-current-practices] defines the protocol headers for IP, ICMP, UDP and TCP.
      It supports filtering of all other protocols supported at layer 3 goals,
   motivation, scope, definitions, intended audience,threat model,
   potential attacks 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 give justifications for each 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 practices.
   Many 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 capabilities listed here refine or
         malicious traffic to be dropped as close add to the source as
         possible.

   Current Implementations.

      It might be desirable on capabilities
   listed in [RFC3871].

   Also see [I-D.lewis-infrastructure-security] for a border router, useful description
   of techniques for example, to apply an
      egress filter outbound on protecting infrastructure devices, including the interface that connects
   use of filtering.

1.1.  Threat Model

   Threats in today's networked environment range from simple packet
   floods with overwhelming bandwidth toward a site to
      its external ISP leaf network to drop outbound traffic that does subtle
   attacks aimed at subverting known vulnerabilities in existing
   applications.  The attacked network or host might not have a
      valid internal source address.  Inbound, be an end user,
   it might may 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 networking device supplies a facility for accurately counting all filter
      matches.

   Supported Practices.

      *  Accurate counting of filter rule matches is important because
         it shows or links inside the frequency of attempts provider core.

   Networks must have the ability to violate policy.  This
         enables resources place mitigation in order 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 limit
   these threats.  These mitigation steps could enable
      the ISP to detect cases where large numbers of spoofed packets are
      being sent.  This may indicate that the customer include routing updates,
   traffic filters, and routing filters.  It is performing
      potentially malicious actions (possibly in violation of the ISPs
      Acceptable Use Policy), or possible that system(s) on the customers network
   mitigation steps might have been "owned" by hackers and are being (mis)used to launch
      attacks.

   Considerations.

      None.

3.1.12.  Ability affect transit traffic as well as
   traffic destined 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 on which the Internet. mitigation steps are
   activated.

   The other three
      connect scope of the threat includes simply denying services to separate internal networks.  Assume that a host an
   individual customer on one side 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 scale to apply ingress filters exploiting a newly
   discovered protocol vulnerability which affects the entire provider
   core.  The obvious risk to each the business requires mitigation
   capabilities which can span this range of threats.

   Threat: An indication of impending danger or harm to the
      internal interfaces.  Once network or
   its parts.  This could be formed from the filters are in place, projected loss of revenue
   to the counters
      can business.  Additionally, it could be examined formed from the increased
   cost to determine the source (inbound interface) of business caused by the
      bogus packets.

   Considerations.

      None.

3.1.13.  Ability event. (more interfaces, more
   bandwidth, more personnel to support the increased size or
   complexity)

   Risk: The possibility of suffering harm or loss of network services
   due to Filter Through a threat.

   Attack: To set upon with violent force the Device - Ability to Display
         Filter Counters per Filter Application

   Capability.

      If it network or its parts.
   Typically this is possible for a filter form of flood of packets to or through a network.
   This could also be applied more than once at the
      same time, then a much smaller stream of packets created with the device provides
   intent of exploiting a mechanism to display filter
      counters per filter application.

   Supported Practices.

      *  It may make sense to apply vulnerability in 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 infrastructure of the
   network.

   Asset: Either a filter is matching than to know that some
         instance was matching somewhere.

   Current Implementations.

      One way to implement this capability would customer, network device or network link.  Any of
   these could be to assets from a business perspective.

   These terms are more completely defined in [RFC2828] we have the added
   some scope specific information only.

   Also see [I-D.savola-rtgwg-backbone-attacks] for a list of attacks on
   backbone devices and counter
      display mechanism show measures.

1.2.  Format

   Each capability has the interface (or other entity) following subsections:

   o  Capability (what)

   o  Supported Practices (why)

   o  Current Implementations (how)

   o  Considerations (caveats, resource issues, protocol issues, etc.)

   The Capability section describes a feature to which
      the filter has been applied, along with be supported by the name (or other
      designator) for
   device.  The Supported Practice section cites practices described in
   [I-D.ietf-opsec-current-practices] that are supported by this
   capability.  The Current Implementation section is intended to give
   examples of implementations of the filter.  For example if a filter named
      "desktop_outbound" applied two different interfaces, say,
      "ethernet0" capability, citing technology and "ethernet1",
   standards current at the display should indicate something
      like "matches of filter 'desktop_outbound' on ethernet0 ..." and
      "matches time of filter 'desktop_outbound' on ethernet1 ..."
   Considerations.

      None.

3.1.14.  Ability to Filter Through the Device - Ability to Reset Filter
         Counters

   Capability. writing.  It is possible to reset counters to zero on a per filter basis.

      For expected that the purposes
   choice of this capability it would be acceptable for the
      system features 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 implement the counter. capabilities will change over
   time.  The reset counter would receive a copy Considerations section lists operational and resource
   constraints, limitations of
      the current value implementations, tradeoffs, etc.

2.  Packet Selction for Managemnet and Data Plane Controls

   In this document section Section 3 describes a number of the absolute counter when the reset function
      was issued criteria for
   performing packet selection.  It is assumed in this document that counter.  Functions that display or retrieve

   o  all of these criteria can be used to select packets for both
      filtering and rate limiting packets,

   o  management plane controls can be implemented by applying these
      criteria to filter/rate limit traffic destined for the counter could then display device
      itself,

   o  data plane controls can be implemented by applying these criteria
      to filter/rate limit traffic destined through the delta (C[now] - C[reset]). device

3.  Packet Selection Criteria

   This section lists packet selection criteria that can be applied to
   both filtering and rate limiting.

3.1.  Select Traffic on All Interfaces

   Capability.

      The device provides a means to filter IP packets on any interface
      implementing IP.

   Supported Practices.

      *  This allows operators to get a current picture  Profile Current Traffic (Section 7.1)

      *  Block Malicious Packets (Section 7.2)

      *  Limit Sources of the traffic
         matching particular rules/filters. Management ([I-D.ietf-opsec-current-
         practices], Section 2.8.2)

   Current Implementations.

      Assume that filter counters are being used to detect internal
      hosts that are infected with a new worm.  Once it is believed

      Many devices currently implement access control lists or filters
      that
      all infected hosts have been cleaned up allow filtering based on protocol and/or source/destination
      address and the worm removed, the
      next step would be or source/destination port and allow these filters to verify that.  One way of doing so would
      be applied to reset the filter counters to zero and see if traffic indicative
      of the worm has ceased. interfaces.

   Considerations.

      None.

3.1.15.  Ability to Filter Through

3.2.  Select Traffic To the Device - Filter Counters are
         Accurate

   Capability.

      Filter counters are accurate.  They reflect the actual number of
      matching packets since

      It is possible to apply the last counter reset.  Filter counters
      are be capable of holding up filtering mechanism to 2^32 - 1 values without
      overflowing and should be capable of holding up traffic that is
      addressed directly to 2^64 the device via any of its interfaces - 1
      values.
      including loopback interfaces.

   Supported Practices.

      *  Inaccurate data can not be relied  Select Traffic To the Device (Section 7.4)
   Current Implementations.

      Many devices currently implement access control lists or filters
      that allow filtering based on as protocol and/or source/destination
      address and or source/destination port and allow these filters to
      be applied to services offered by the basis for action.
         Underreported data can conceal device.

      Examples of this might include filters that permit only BGP from
      peers and SNMP and SSH from an authorized management segment and
      directed to the magnitude of a problem.

   Current Implementations.

      If N packets matching a filter are sent to/through a device, then device itself, while dropping all other traffic
      addressed to the counter should show N matches. device.

   Considerations.

      None.

3.2.  Rate Limit THROUGH the Device

3.2.1.  Ability to Rate limit

3.3.  Select Transit Traffic on All Interfaces THROUGH the
        Device

   Capability.

      The device provides a means

      It is possible to rate limit IP packets on any
      interface implementing IP apply the filtering mechanism to traffic that are
      will transit packets. the device via any of its interfaces.

   Supported Practices.

      *  Profile Current  Select Transit Traffic ([I-D.practices] Section x.x.x)

      *  Block Malicious Packets (Section 5.2)

      *  Limit Sources of Management (Section 5.3) 7.5)

   Current Implementations.

      Many devices currently implement rate limits access control lists or filters
      that allow rate
      limiting filtering based on protocol and/or source/destination
      address and or source/destination port or raw bandwidth and allow these limits filters to
      be applied to interfaces. the interfaces on the device in order to protect
      assets attached to the network.

      Examples of this may include filtering all traffic save SMTP
      (tcp/25) destined to a mail server.  A common use of this today
      would also be denying all traffic to a destination which has been
      determined to be hostile.

   Considerations.

      None.

3.2.2.  Ability

3.4.  Select Inbound and/or Outbound
   Capability.

      It is possible to Rate Limit filter both incoming and outgoing traffic on any
      interface.

   Supported Practices.

      *  Select Inbound and/or Outbound Traffic Through (Section 7.6)

   Current Implementations.

      It might be desirable on a border router, for example, to apply an
      egress filter outbound on the Device 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 large amounts of junk mail.

   Considerations.

      None.

3.5.  Select by Protocols

   Capability.

      It is possible to apply the rate-limiting mechanism

      The device provides a means to filter traffic
      that is transiting based on the device via any value
      of its interfaces. the protocol field in the IP header.

   Supported Practices.

      *  This allows the operator to apply rate-limits that protect the
         networks transiting the device from attacks and unauthorized
         access.  Select by Protocols(Section 7.7)

   Current Implementations.

      Many devices currently implement rate-limits that allow limiting

      Some denial of service attacks are based on protocol and/or source/destination address and or source/
      destination port and allow these limits to be applied the ability to services
      offered by flood
      the networks which transit victim with ICMP traffic.  One quick way (admittedly with some
      negative side effects) to mitigate the device.

      Examples effects of this might include rate-limits that permit SSH traffic
      rates up such attacks is
      to 100 megabits per second from an authorized peer, while
      dropping drop all other ICMP traffic addressed to headed toward the network which exceeds
      this limit. victim.

   Considerations.

      None.

3.2.3.  Ability to Rate Limit Traffic Through the Device - Minimal
        Performance Degradation

3.6.  Select by Addresses
   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 control 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 flow of traffic destined to networks transiting the
      device should not degrade performance significantly. based on source
      and/or destination IP address or blocks of addresses such as
      Classless Inter-Domain Routing (CIDR) blocks.

   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.  Select by Addresses(Section 7.8)

   Current Implementations.

      Another way

      One example of stating the capability is that rate-limit
      performance should not be the limiting factor in device
      throughput.  If a device is capable use of forwarding 30Mb/sec without
      rate-limits, then it should be able address based filtering is to forward the same amount
      with rate-limits in place. implement
      ingress filtering per [RFC2827]

   Considerations.

      None.

3.7.  Select by Protocol Header Fields

   Capability.

      The definition filtering mechanism supports filtering based on the value(s)
      of "significant" is subjective.  At one end any portion of the
      spectrum it might mean "the application protocol headers for IP, ICMP, UDP and TCP.
      It supports filtering of rate-limits may cause
      the box to crash".  At the all other end would be a throughput loss of
      less than one percent with tens of thousands protocols supported at layer 3
      and 4.  It supports filtering based on the headers of rate-limits
      applied.  The higher level of performance degradation that
      protocols.  It is acceptable
      will have possible to be determined specify fields by the operator.

      Repeatable test data showing rate-limiting performance impact
      would be very useful in evaluating this capability.  Tests should
      include name (e.g.,
      "protocol = ICMP") rather than bit- offset/length/numeric value
      (e.g., 72:8 = 1).

   Supported Practices.

      *  Select by Protocol Header Field(Section 7.9)

   Current Implementations.

      This capability implies that it is possible to filter based on TCP
      or UDP port numbers, TCP flags such information as packet size, packet rate, number of
      interfaces tested (source/destination), types of interfaces,
      routing table size, routing protocols in use, frequency 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 routing
      updates, etc.

3.2.4.  Ability a network.  It may be desirable to Rate Limit Through the Device - only allow inbound
      connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting
      web servers.

   Considerations.

      None.

4.  Actions

4.1.  Specify Rate Limit Filter Actions

   Capability.

      The device provides a mechanism to allow the specification of the
      action to be taken when a rate-limit filter 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.  Specify Filter Actions(Section 7.10)

   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

4.2.  Specify Rate Limits

   Capability.

      The device provides a mechanism to allow the specification of the
      action to be taken when a rate limiting filter rule matches.  The
      actions include "transmit" (permit the traffic because it's below
      the specified limit), "limit" (limit traffic because it exceeds
      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.

      *  Specify Rate Limit Through Limits (Section 7.11)

   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 Device -
      devices from these parts of the organization with respect to
      priority access to these services.  Rate Limits may be used to
      enforce these prioritizations.

   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.

4.3.  Specify Log Rate Limit Actions

   Capability.

      It is possible to log rate limit 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  Log exceptions ([I-D.ietf-opsec-current-practices], Section
         2.7.2)

      *  Log Actions (Section 7.12)
   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 -

4.4.  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.  Log Granularity (Section 7.13)

   Current Implementations.

      If a rate limit filter 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 -

4.5.  Ability to Rate Limit
        Protocols Display Filter Counters

   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 mechanism 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. display filter counters.

   Supported Practices.

      *  The capability to rate limit on addresses and address blocks is
         a fundamental tool for establishing boundaries between
         different networks.  Display Filter Counters (Section 7.14)
   Current Implementations.

      Assume there is a router with four interfaces.  One example of the use of address based rate limits is an up-link
      to
      implement ingress filtering per [RFC2827].

   Considerations.

      None.

3.2.9.  Ability an ISP providing routes to Rate Limit Through the Device - Ability to Rate Limit
        Protocol Header Fields

   Capability. Internet.  The rate limit mechanism supports rate limiting based other three
      connect to separate internal networks.  Assume that a host on the
      value(s) of any portion one
      of the protocol headers for IP, ICMP, UDP
      and TCP.  It supports rate limiting of all other protocols
      supported at layer 3 internal networks has been compromised by a hacker and 4.  It supports rate limiting based on
      the headers of higher level protocols.  It is possible
      sending traffic with bogus source addresses.  In such a situation,
      it might be desirable 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 apply ingress filters to rate limit on portions each of the header is necessary
      internal interfaces.  Once the filters are in place, the counters
      can be examined to allow implementation determine the source (inbound interface) 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 the
      bogus packets.

   Considerations.

      None.

5.  Counters

5.1.  Ability 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 Display Filter Counters per Filter Application

   Capability.

      If it is the ability possible for a filter to control what services are allowed in/out
      of be applied more than once at the
      same time, then the device provides a network.  It may mechanism to display filter
      counters per filter application.

   Supported Practices.

      *  Counters (Section 7.15)

   Current Implementations.

      One way to implement this capability would be desirable to only allow inbound
      connections on port 80 (HTTP) and 443 (HTTPS) 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 network hosting
      web servers. 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.

3.2.10.  Ability to Rate Limit Through the Device -

5.2.  Ability to Rate
         Limit Inbound and Outbound Reset Filter Counters

   Capability.

      It is possible to rate limit both incoming and outgoing traffic on
      any interface reset counters to or from any transiting network.

   Supported Practices.

      *  This zero on a per filter basis.

      For the purposes of this capability allows flexibility in applying rate limits at it would be acceptable for the place
      system to maintain two counters: an "absolute counter", C[now],
      and a "reset" counter, C[reset].  The absolute counter would
      maintain counts that makes the most sense.  It allows invalid increase monotonically until they wrap or
         malicious traffic to be dropped as close to
      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 source as
         possible. counter could then display the delta (C[now] - C[reset]).

   Supported Practices.

      *  Reset Counters (Section 7.16)
   Current Implementations.

      It might be desirable on a router to apply an egress rate limit to
      its external connections

      Assume that filter counters are being used to limit outbound traffic detect internal
      hosts that does not
      have are infected with a high priority.  Inbound, new worm.  Once it might is believed that
      all infected hosts have been cleaned up and the worm removed, the
      next step would be desirable to apply a
      rate limit to all traffic verify that.  One way of a certain classification in order doing so would be
      to
      preserve limited resources on reset the sported networks behind filter counters to zero and see if traffic indicative
      of the
      device. worm has ceased.

   Considerations.

      None.

3.2.11.  Ability to Rate Limit Through the Device - Ability to
         Accurately Count Rate Limit

5.3.  Filter Hits are Accurately Counted

   Capability.

      The device supplies a facility for accurately counting all rate
      limit filter
      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.  Filter Hits are Accurately Counted (Section 7.17)

   Current Implementations.

      Assume, for example, that a ISP network implements anti-spoofing
      egress rate limits 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 compromised "owned" 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

5.4.  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.

      *  Filter Hits are Accurately (Section 7.18)

   Current Implementations.

      If N packets matching a filter are sent to/through a device, then
      the counter should show N matches.

   Considerations.

      None.

6.  Minimal Performance Degradation

   Capability.

      The device provides a mechanism means 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 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.  One

      The device is an up-link able to an ISP providing routes apply stateless packet filters on ALL
      interfaces (up to the Internet.  The other three
      connect to separate internal networks.  Assume that a host on one total number of interfaces attached to the internal networks has been compromised by a hacker
      device) simultaneously and is
      sending traffic with bogus source addresses.  In such a situation,
      it might be desirable to apply ingress rate limits to each multiple filters per interface
      (e.g., inbound and outbound).

      The filtering of the
      internal interfaces.  Once the rate limits are in place, the
      counters can be examined traffic destined to determine interfaces on the source (inbound
      interface) of device,
      including the bogus packets.

   Considerations.

      None.

3.2.13.  Ability to Rate Limit Through loopback interface, should not degrade performance
      significantly.

   Supported Practices.

      *  Minimal Performance Degradation (Section 7.19)

   Current Implementations.

      Another way of stating the Device - Ability to Display
         Rate Limit Counters per Rate Limit Application

   Capability.

      If it capability is possible for a rate limit to be applied more than once at
      the same time, then that filter performance
      should not be the limiting factor in device provides throughput.  If a mechanism to display
      rate limit counters per rate limit application.

   Supported Practices.

      *  It may make sense
      device is capable of forwarding 30Mb/sec without filtering, then
      it should be able to apply forward the same rate limit amount with filtering in
      place.

   Considerations.

      The 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 "significant" is matching than to know that some
         instance was matching somewhere.

   Current Implementations.

      One way to implement this capability would be to have subjective.  At one end of the counter
      display mechanism show
      spectrum it might mean "the application of filters may cause the interface (or other entity)
      box to which
      the rate limit has been applied, along with crash".  At the name (or other
      designator) for the rate limit.  For example if end would be a rate limit named
      "desktop_outbound" applied two different interfaces, say,
      "ethernet0" and "ethernet1", the display should indicate something
      like "matches throughput loss of rate limit 'desktop_outbound' on ethernet0 ..."
      and "matches
      less than one percent with tens 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 thousands of filters applied.
      The level of performance degradation that is possible to reset counters acceptable will have
      to zero on a per rate limit
      basis.

      For be determined by the purposes 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 this 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.

      Finally, if key infrastructure devices crash or experience severe
      performance degradation when filtering under heavy load, or even
      have the reputation of doing so, it is likely that security
      personnel will be forbidden, by policy, from using filtering in
      ways that would otherwise be acceptable appropriate for the
      system fear that it might
      cause unnecessary service disruption.

7.  Additional Operational Practices

   This section describes practices not covered in [I-D.ietf-opsec-
   current-practices].  They are included here to maintain two counters: provide justification
   for capabilities that reference them.

7.1.  Profile Current Traffic

   This capability allows a network operator to monitor traffic across
   an "absolute counter", C[now],
      and active interface in the network at a "reset" counter, C[reset].  The absolute counter would
      maintain counts that increase monotonically until they wrap minimal level.  This helps to
   determine probable cause for interface or
      overflow the counter. network problems.

   The reset counter would receive ability to separate and distinguish traffic at a copy of layer-3 or
   layer-4 level allows the current value of operator to characterize beyond simple
   interface counters the absolute counter when traffic in question.  This is critical because
   often the reset function
      was issued operator has no tools available for that counter.  Functions that display protocol analysis aside
   from interface filters.

7.2.  Block Malicious Packets

   Blocking or retrieve
      the counter could then display the delta (C[now] - C[reset]).

   Supported Practices.

      *  This allows operators limiting traffic deemed to get be malicious is a current picture 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.

   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
         matching particular rules/rate limit.

   Current Implementations.

      Assume based on these criteria and take some action based
   on that rate limit counters are being used classification is critical to detect internal
      hosts that are infected with operations of a new worm.  Once it is believed network.

7.3.  Limit Sources of Management

   Management of a network should be limited to only trusted hosts.
   This implies that
      all infected hosts have been cleaned up and the worm removed, the
      next step would network elements will be able to verify that.  One way of doing so would be limit access
   to reset the rate management functions to these trusted hosts.

   Currently operators will limit counters access to zero the management functions on
   a network device to only the hosts that are trusted to perform that
   function.  This allows separation of critical functions and see if traffic
      indicative
   protection of those functions on the worm has ceased.

   Considerations.

      None.

3.2.15.  Ability to Rate Limit Through network devices.

7.4.  Select Traffic To the Device - Rate Limit Counters
         are Accurate

   Capability.

      Rate limit counters are accurate.  They reflect

   This allows the actual number
      of matching packets since operator to apply filters that protect the last counter reset.  Rate limit
      counters are be capable of holding up device
   itself from attacks and unauthorized access.

7.5.  Select Transit Traffic

   This allows the operator to 2^32 - 1 values without
      overflowing apply filters that protect the networks
   and should be capable of holding up assets surrounding the device from attacks and unauthorized
   access.

7.6.  Select Traffic Inbound and/or Outbound

   This allows flexibility in applying filters at the place that makes
   the most sense.  It allows invalid or malicious traffic to 2^64 - 1
      values.

   Supported Practices.

      *  Inaccurate data can not be relied on dropped
   as close to the basis for action.
         Underreported data can conceal source as possible with the magnitude of a problem.

   Current Implementations.

      If N packets matching a Rate limit are sent to/through a device,
      then least impact on other
   traffic transiting the counter should show N matches.

   Considerations.

      None.

4.  Functional Capabilities	- Filtering Layer 2 Attributes

   The capabilities interface(s) in this section are intended question.

7.7.  Select Traffic by Protocol

   Being able to list testable,
   functional capabilities that are needed filter on protocol is necessary to operate devices securely.

   A layer-2 domain permits allow implementation
   of policy, secure operations and for support of incident response.
   Filtering all devices in the domain traffic 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 destination host is not often possible,
   business requirements will dictate that critical traffic be permitted
   if at different trust levels, we may want all possible.

7.8.  Select Traffic by Addresses

   The capability to filter traffic on addresses and address blocks is a
   fundamental tool for establishing boundaries between such devices based different
   networks.

7.9.  Select Traffic by Protocol Header Field

   Being able to filter on portions of 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 header is necessary to provide different levels allow
   implementation of security

   Capability.

      The device provides a means policy, secure operations, and support incident
   response.

7.10.  Specify Filter Actions

   This capability is essential to partition the physical layer-2
      domain into multiple virtual domains, thus allowing the filtering use of unwarranted traffic.

   Supported Practices.

      *  Being able filters to partition enforce policy.
   With a layer-2 domain provides the same
         level defined filter classification of security within a layer-2 domain as can be guaranteed
         if they were different layer-2 domains.

   Current Implementations.

      Most Ethernet networks some traffic and no action
   defined there is little use for 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 filter, actions must be included
   in order to
      virtual partitioning.

4.1.2.  Ability provide the requisite security.

7.11.  Specify Rate Limits

   This capability allows a filter to restrict access be used to specified hardware (MAC) addresses

   Capability.

      The device provides rate limit a means to filter portion of
   traffic based on the source
      and/ through or destination hardware address.

   Supported Practices.

      *  Being able to filter on hardware Address provides an ability a device.  It maybe desirable to
         block frames between devices in the same layer-2 domain limit SNMP
   (UDP/161) traffic to
         communicate.

   Current Implementations. 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.

7.12.  Specify Log Actions

   Logging is essential for auditing, incident response, and operations

7.13.  Log Granularity

   The ability to filter and monitor traffic in layer-2 allows for
      security at layer-2 itself, between devices on tune the same network.
      Allowing filtering based on hardware address granularity of logging allows a simple
      filtering interface the operator to
   log the information that is desired and only the administrator 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.

7.14.  Display Filter Counters

   Information that is collected is not useful unless it can be
   displayed.

7.15.  Counters

   It may make sense to apply simple policy
      rules.

   Considerations.

      Different Link layer technologies use the same filter definition simultaneously
   more than one time (to different addressing
      mechanisms.

4.1.3.  Ability interfaces, etc.).  If so, it would
   be much more useful to restrict based on layer-2 packet type [etherType]
        field

   Capability.

      The device provides know which instance of a means to filter packets based on is matching
   than to know that some instance was matching somewhere.

7.16.  Ability to Reset Filter Counters

   This allows operators to get a current picture of the packet
      type field in traffic
   matching particular rules/filters.

7.17.  Filter Hits are Accurately Counted

   Accurate counting of filter rule matches is important because it
   shows the layer-2 header.

   Supported Practices.

      *  Being able frequency of attempts to filter on packets based violate policy.  This enables
   resources to be focused on the packet type field
         helps in preventing packets areas of greatest need.

7.18.  Filter Hits are Accurate

   Inaccurate data can not understandable by a particular
         device to be processed by it.

   Current Implementations.

      The ability to filter and monitor traffic in layer-2 allows relied on as the basis for
      security at layer-2 itself.  This capability action.  Under-
   reported data can also prevent IPX
      packets to inadvertently be sent to an IP device and vice versa.

   Considerations.

      None.

5.  Additional Operational Practices conceal the magnitude of a problem.

7.19.  Minimal Performance Degredation

   This section describes practices not covered in [I-D.practices].
   They enables the implementation of filters on whichever services are included here
   necessary.  To the extent that filtering causes degradation, it may
   not be possible to provide justification for capabilities apply filters that
   reference them.

5.1.  Profile Current Traffic

   Discuss practice.  Use same format as [I-D.practices].

5.2.  Block Malicious Packets

   Discuss practice.  Use same format as [I-D.practices].

5.3.  Limit Sources of Management

   Discuss practice.  Use same format as [I-D.practices].

6. implement the appropriate
   policies.

8.  Security Considerations

   General

      Security is the subject matter of this entire memo.  The
      capabilities listed cite practices in [I-D.practices] [I-D.ietf-opsec-current-
      practices] that they are intended to support.  [I-D.practices]  [I-D.ietf-opsec-
      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
              Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2.

9.  Non-normative References

   [8021Q]    "802.1Q - Virtual LANs", IEEE Standard 802.1Q - Virtual
              LANs, August 2001.

   [I-D.practices]

   [I-D.ietf-opsec-current-practices]
              Kaeo, M., "Operational Security Current Practices",
              Internet-Draft (to be published)
              draft-ietf-opsec-current-practices-00, February 2005.

   [PVLAN]    HomChaudhuri, S. and M. Foschiano, "Private VLANs:
              Addressing VLAN scalability
              draft-ietf-opsec-current-practices-04 (work in progress),
              June 2006.

   [I-D.lewis-infrastructure-security]
              Lewis, D., "Service Provider Infrastructure Security",
              draft-lewis-infrastructure-security-00 (work in progress),
              June 2006.

   [I-D.savola-rtgwg-backbone-attacks]
              Savola, P., "Backbone Infrastructure Attacks and security issues
              Protections", draft-savola-rtgwg-backbone-attacks-01 (work
              in a
              multi-client environment", Internet Draft (to be
              published) draft-sanjib-private-vlan-02, progress), June 2004. 2006.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.

   [RFC2828]  Shirey, R., "Internet Security Glossary", RFC rfc2828.txt, 2828,
              May 2000.

   [RFC3631]  Bellovin, S. and J. Schiller, "Security Mechanisms for the
              Internet",

   [RFC3360]  Floyd, S., "Inappropriate TCP Resets Considered Harmful",
              BCP 60, RFC 3631, December 2003. 3360, August 2002.

   [RFC3871]  Jones, G., "Operational Security Requirements for Large
              Internet Service Provider (ISP) IP Network
              Infrastructure", RFC 3871, September 2004.

Appendix A.  Acknowledgments

   The editors gratefully acknowledges the contributions of:

   o  xxx

   o  yyy

   o  The MITRE Corporation for supporting development of this document.
      NOTE: The editor's affiliation with The MITRE Corporation is
      provided for identification purposes only, and is not intended to
      convey or imply MITRE's concurrence with, or support for, the
      positions, opinions or viewpoints expressed by the editor.

   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

   Christopher L. Morrow
   UUNET Technologies
   21830 UUNet Way
   Ashburn, Virginia  21047
   U.S.A.

   Phone: +1 703 886 3823
   Email: chris@uu.net

   George M. Jones
   The MITRE Corporation
   7515 Colshire Drive, M/S WEST
   McLean, Virginia  22102-7508
   U.S.A.

   Phone: +1 703 488 9740
   Email: gmjones@mitre.org

   Vishwas Manral
   IPInfusion,
   Bangalore,
   India

   Phone: +91-98456-61911
   Email: vishwas@ipinfusion.com

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   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
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005). (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.