--- 1/draft-ietf-opsec-filter-caps-01.txt 2006-07-17 22:12:58.000000000 +0200 +++ 2/draft-ietf-opsec-filter-caps-02.txt 2006-07-17 22:12:58.000000000 +0200 @@ -1,21 +1,19 @@ None. C. Morrow Internet-Draft UUNET Technologies -Expires: October 12, 2006 G. Jones +Expires: September 25, 2006 G. Jones The MITRE Corporation - V. Manral - IPInfusion - May 12, 2006 + March 24, 2006 - Filtering Capabilities for IP Network Infrastructure - draft-ietf-opsec-filter-caps-01 + Filtering and Rate Limiting Capabilities for IP Network Infrastructure + 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 @@ -26,201 +24,108 @@ 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, 2006. + This Internet-Draft will expire on September 25, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract - [I-D.practices] lists operator practices related to securing - networks. This document lists filtering capabilities needed to - support those 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 - 1.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 6 - 1.2. Capabilities or Requirements ? . . . . . . . . . . . . . . 7 - 1.3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 - 2. Functional Capabilities - Filtering non-transit traffic - (management plane) . . . . . . . . . . . . . . . . . . . . . . 9 - 2.1. Filtering TO the Device . . . . . . . . . . . . . . . . . 9 - 2.1.1. Ability to Filter Traffic on All Interfaces TO the - Device . . . . . . . . . . . . . . . . . . . . . . . . 9 - 2.1.2. Ability to Filter Traffic To the Device . . . . . . . 10 - 2.1.3. Ability to Filter Traffic To the Device - Minimal - Performance Degradation . . . . . . . . . . . . . . . 10 - 2.1.4. Ability to Filter To the Device - Specify Filter - Actions . . . . . . . . . . . . . . . . . . . . . . . 12 - 2.1.5. Ability to Filter To the Device - Log Filter - Actions . . . . . . . . . . . . . . . . . . . . . . . 13 - 2.1.6. Ability to Filter To the Device - Specify Log - Granularity . . . . . . . . . . . . . . . . . . . . . 14 - 2.1.7. Ability to Filter To the Device - Ability to - Filter Protocols . . . . . . . . . . . . . . . . . . . 15 - 2.1.8. Ability to Filter To the Device - Ability to - Filter Addresses . . . . . . . . . . . . . . . . . . . 15 - 2.1.9. Ability to Filter To the Device - Ability to - Filter Protocol Header Fields . . . . . . . . . . . . 16 - 2.1.10. Ability to Filter To the Device - Ability to - Filter Inbound and Outbound . . . . . . . . . . . . . 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 - Ability to - Display Filter Counters . . . . . . . . . . . . . . . 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 - Ability to Reset - Filter Counters . . . . . . . . . . . . . . . . . . . 21 - 2.1.15. Ability to Filter To the Device - Filter Counters - are Accurate . . . . . . . . . . . . . . . . . . . . . 22 - 2.2. Rate Limit TO the Device . . . . . . . . . . . . . . . . . 22 - 2.2.1. Ability to Rate limit Traffic on All Interfaces TO - the Device . . . . . . . . . . . . . . . . . . . . . . 22 - 2.2.2. Ability to Rate Limit Traffic To the Device . . . . . 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 . . . . . . . . . . . . . . . . . . . . 26 - 2.2.5. Ability to Rate Limit To the Device - Log Rate - Limit Actions . . . . . . . . . . . . . . . . . . . . 27 - 2.2.6. Ability to Rate Limit To the Device - Specify Log - Granularity . . . . . . . . . . . . . . . . . . . . . 28 - 2.2.7. Ability to Rate Limit To the Device - Ability to - Rate Limit Protocols . . . . . . . . . . . . . . . . . 28 - 2.2.8. Ability to Rate Limit To the Device - Ability to - Rate Limit Addresses . . . . . . . . . . . . . . . . . 29 - 2.2.9. Ability to Rate Limit To the Device - Ability to - Rate Limit Protocol Header Fields . . . . . . . . . . 30 - 2.2.10. Ability to Rate Limit To the Device - Ability to - Rate Limit Inbound and Outbound . . . . . . . . . . . 31 - 2.2.11. Ability to Rate Limit To the Device - Ability to - Accurately Count Rate Limit Hits . . . . . . . . . . . 32 - 2.2.12. Ability to Rate Limit To the Device - Ability to - Display Rate Limit Counters . . . . . . . . . . . . . 33 - 2.2.13. Ability to Rate Limit To the Device - Ability to - Display Rate Limit Counters per Rate Limit - Application . . . . . . . . . . . . . . . . . . . . . 33 - 2.2.14. Ability to Rate Limit To the Device - Ability to - Reset Rate Limit Counters . . . . . . . . . . . . . . 34 - 2.2.15. Ability to Rate Limit To the Device - Rate Limit - Counters are Accurate . . . . . . . . . . . . . . . . 35 - 3. Functional Capabilities - Filtering transit traffic (data - plane) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 3.1. Filtering THROUGH the Device . . . . . . . . . . . . . . . 37 - 3.1.1. Ability to Filter Traffic on All Interfaces - THROUGH the Device . . . . . . . . . . . . . . . . . . 37 - 3.1.2. Ability to Filter Traffic Through the Device . . . . . 38 - 3.1.3. Ability to Filter Traffic Through the Device - - Minimal Performance Degradation . . . . . . . . . . . 38 - 3.1.4. Ability to Filter Through the Device - Specify - Filter Actions . . . . . . . . . . . . . . . . . . . . 40 - 3.1.5. Ability to Filter Through the Device - Log Filter - Actions . . . . . . . . . . . . . . . . . . . . . . . 41 - 3.1.6. Ability to Filter Through the Device - Specify Log - Granularity . . . . . . . . . . . . . . . . . . . . . 42 - 3.1.7. Ability to Filter Through the Device - Ability to - Filter Protocols . . . . . . . . . . . . . . . . . . . 43 - 3.1.8. Ability to Filter Through the Device - Ability to - Filter Addresses . . . . . . . . . . . . . . . . . . . 43 - 3.1.9. Ability to Filter Through the Device - Ability to - Filter Protocol Header Fields . . . . . . . . . . . . 44 - 3.1.10. Ability to Filter Through the Device - Ability to - Filter Inbound and Outbound . . . . . . . . . . . . . 45 - 3.1.11. Ability to Filter Through the Device - Ability to - Accurately Count Filter Hits . . . . . . . . . . . . . 46 - 3.1.12. Ability to Filter Through the Device - Ability to - Display Filter Counters . . . . . . . . . . . . . . . 47 - 3.1.13. Ability to Filter Through the Device - Ability to - Display Filter Counters per Filter Application . . . . 48 - 3.1.14. Ability to Filter Through the Device - Ability to - Reset Filter Counters . . . . . . . . . . . . . . . . 49 - 3.1.15. Ability to Filter Through the Device - Filter - Counters are Accurate . . . . . . . . . . . . . . . . 50 - 3.2. Rate Limit THROUGH the Device . . . . . . . . . . . . . . 50 - 3.2.1. Ability to Rate limit Traffic on All Interfaces - THROUGH the Device . . . . . . . . . . . . . . . . . . 51 - 3.2.2. Ability to Rate Limit Traffic Through the Device . . . 51 - 3.2.3. Ability to Rate Limit Traffic Through the Device - - Minimal Performance Degradation . . . . . . . . . . . 52 - 3.2.4. Ability to Rate Limit Through the Device - Specify - Rate Limit Actions . . . . . . . . . . . . . . . . . . 54 - 3.2.5. Ability to Rate Limit Through the Device - Log - Rate Limit Actions . . . . . . . . . . . . . . . . . . 55 - 3.2.6. Ability to Rate Limit Through the Device - Specify - Log Granularity . . . . . . . . . . . . . . . . . . . 56 - 3.2.7. Ability to Rate Limit Through the Device - Ability - to Rate Limit Protocols . . . . . . . . . . . . . . . 57 - 3.2.8. Ability to Rate Limit Through the Device - Ability - to Rate Limit Addresses . . . . . . . . . . . . . . . 57 - 3.2.9. Ability to Rate Limit Through the Device - Ability - to Rate Limit Protocol Header Fields . . . . . . . . . 58 - 3.2.10. Ability to Rate Limit Through the Device - Ability - to Rate Limit Inbound and Outbound . . . . . . . . . . 59 - 3.2.11. Ability to Rate Limit Through the Device - Ability - to Accurately Count Rate Limit Hits . . . . . . . . . 60 - 3.2.12. Ability to Rate Limit Through the Device - Ability - to Display Rate Limit Counters . . . . . . . . . . . . 61 - 3.2.13. Ability to Rate Limit Through the Device - Ability - to Display Rate Limit Counters per Rate Limit - Application . . . . . . . . . . . . . . . . . . . . . 62 - 3.2.14. Ability to Rate Limit Through the Device - Ability - to Reset Rate Limit Counters . . . . . . . . . . . . . 63 - 3.2.15. Ability to Rate Limit Through the Device - Rate - Limit Counters are Accurate . . . . . . . . . . . . . 64 - 4. Functional Capabilities - Filtering Layer 2 Attributes . . . . 65 - 4.1. Filtering Layer 2 . . . . . . . . . . . . . . . . . . . . 65 - 4.1.1. Ability to partition layer-2 network to provide - different levels of security . . . . . . . . . . . . . 65 - 4.1.2. Ability to restrict access to specified hardware - (MAC) addresses . . . . . . . . . . . . . . . . . . . 66 - 4.1.3. Ability to restrict based on layer-2 packet type - [etherType] field . . . . . . . . . . . . . . . . . . 67 - 5. Additional Operational Practices . . . . . . . . . . . . . . . 68 - 5.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 68 - 5.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 68 - 5.3. Limit Sources of Management . . . . . . . . . . . . . . . 68 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 69 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 70 - 7.2. Non-normative References . . . . . . . . . . . . . . . . . 70 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 71 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 72 - Intellectual Property and Copyright Statements . . . . . . . . . . 73 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Packet Selction for Managemnet and Data Plane Controls . . . . 6 + 3. Packet Selection Criteria . . . . . . . . . . . . . . . . . . 7 + 3.1. Select Traffic on All Interfaces . . . . . . . . . . . . . 7 + 3.2. Select Traffic To the Device . . . . . . . . . . . . . . . 7 + 3.3. Select Transit Traffic . . . . . . . . . . . . . . . . . . 8 + 3.4. Select Inbound and/or Outbound . . . . . . . . . . . . . . 8 + 3.5. Select by Protocols . . . . . . . . . . . . . . . . . . . 9 + 3.6. Select by Addresses . . . . . . . . . . . . . . . . . . . 9 + 3.7. Select by Protocol Header Fields . . . . . . . . . . . . . 10 + 4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.1. Specify Filter Actions . . . . . . . . . . . . . . . . . . 12 + 4.2. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 12 + 4.3. Specify Log Actions . . . . . . . . . . . . . . . . . . . 13 + 4.4. Specify Log Granularity . . . . . . . . . . . . . . . . . 14 + 4.5. Ability to Display Filter Counters . . . . . . . . . . . . 14 + 5. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 5.1. Ability to Display Filter Counters per Filter + Application . . . . . . . . . . . . . . . . . . . . . . . 16 + 5.2. Ability to Reset Filter Counters . . . . . . . . . . . . . 16 + 5.3. Filter Hits are Accurately Counted . . . . . . . . . . . . 17 + 5.4. Filter Counters are Accurate . . . . . . . . . . . . . . . 17 + 6. Minimal Performance Degradation . . . . . . . . . . . . . . . 19 + 7. Additional Operational Practices . . . . . . . . . . . . . . . 21 + 7.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 21 + 7.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 21 + 7.3. Limit Sources of Management . . . . . . . . . . . . . . . 21 + 7.4. Select Traffic To the Device . . . . . . . . . . . . . . . 21 + 7.5. Select Transit Traffic . . . . . . . . . . . . . . . . . . 22 + 7.6. Select Traffic Inbound and/or Outbound . . . . . . . . . . 22 + 7.7. Select Traffic by Protocol . . . . . . . . . . . . . . . . 22 + 7.8. Select Traffic by Addresses . . . . . . . . . . . . . . . 22 + 7.9. Select Traffic by Protocol Header Field . . . . . . . . . 22 + 7.10. Specify Filter Actions . . . . . . . . . . . . . . . . . . 22 + 7.11. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 22 + 7.12. Specify Log Actions . . . . . . . . . . . . . . . . . . . 23 + 7.13. Log Granularity . . . . . . . . . . . . . . . . . . . . . 23 + 7.14. Display Filter Counters . . . . . . . . . . . . . . . . . 23 + 7.15. Counters . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 7.16. Ability to Reset Filter Counters . . . . . . . . . . . . . 23 + 7.17. Filter Hits are Accurately Counted . . . . . . . . . . . . 23 + 7.18. Filter Hits are Accurate . . . . . . . . . . . . . . . . . 23 + 7.19. Minimal Performance Degredation . . . . . . . . . . . . . 23 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 9. Non-normative References . . . . . . . . . . . . . . . . . . . 24 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 + Intellectual Property and Copyright Statements . . . . . . . . . . 27 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] + This document is defined in the context of [I-D.ietf-opsec-current- + practices]. [I-D.ietf-opsec-current-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]. + + Also see [I-D.lewis-infrastructure-security] for a useful description + of techniques for protecting infrastructure devices, including the + use of filtering. 1.1. Threat Model 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 @@ -248,1090 +153,532 @@ 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 ? + These terms are more completely defined in [RFC2828] we have added + some scope specific information only. - 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. + Also see [I-D.savola-rtgwg-backbone-attacks] for a list of attacks on + backbone devices and counter measures. -1.3. Format +1.2. 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 + [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 capability, citing technology and + standards current at the time of writing. 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 +2. Packet Selction for Managemnet and Data Plane Controls - RFC 2119 Keywords + In this document section Section 3 describes a number of criteria for + performing packet selection. It is assumed in this document that - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL - NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" - in this document are to be interpreted as described in [RFC2119]. + o all of these criteria can be used to select packets for both + filtering and rate limiting packets, - 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. + o management plane controls can be implemented by applying these + criteria to filter/rate limit traffic destined for the device + itself, -2. Functional Capabilities - Filtering non-transit traffic (management - plane) + o data plane controls can be implemented by applying these criteria + to filter/rate limit traffic destined through the device - 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. +3. Packet Selection Criteria -2.1. Filtering TO the Device + This section lists packet selection criteria that can be applied to + both filtering and rate limiting. -2.1.1. Ability to Filter Traffic on All Interfaces TO the Device +3.1. Select Traffic on All Interfaces Capability. The device provides a means to filter IP packets on any interface - implementing IP that are non-transit packets. + implementing IP. Supported Practices. - * Profile Current Traffic ([I-D.practices] Section x.x.x) + * Profile Current Traffic (Section 7.1) - * Block Malicious Packets (Section 5.2) + * Block Malicious Packets (Section 7.2) - * Limit Sources of Management (Section 5.3) + * Limit Sources of Management ([I-D.ietf-opsec-current- + practices], Section 2.8.2) Current Implementations. 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 +3.2. Select 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. - + * Select Traffic To the Device (Section 7.4) 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 +3.3. Select Transit Traffic 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). + It is possible to apply the filtering mechanism to traffic that + will transit the device via any of its interfaces. Supported Practices. - * This capability is essential to the use of filters to enforce - policy. + * Select Transit Traffic (Section 7.5) 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. + 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 the interfaces on the device in order to protect + assets attached to the network. - Actions such as "permit", "deny", "drop" are essential in defining - the security policy for the services offered by the network - devices. Auditing the frequency, sources and destinations of - these attempts is essential for tracking ongoing issues today. + 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. - 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 + None. +3.4. Select Inbound and/or Outbound Capability. - It is possible to enable/disable logging on a per rule basis. + It is possible to filter both incoming and outgoing traffic on any + interface. Supported Practices. - * 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. + * Select Inbound and/or Outbound Traffic (Section 7.6) 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. + 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 large amounts of junk mail. Considerations. None. -2.1.7. Ability to Filter To the Device - Ability to Filter Protocols +3.5. Select by 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. + * Select by Protocols(Section 7.7) 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 +3.6. Select by 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. + The device 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. + * Select by Addresses(Section 7.8) Current Implementations. One example of the use of address based filtering is to implement - ingress filtering per [RFC2827]. + ingress filtering per [RFC2827] Considerations. None. -2.1.9. Ability to Filter To the Device - Ability to Filter Protocol - Header Fields +3.7. Select by 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. + * 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 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. +4. Actions -2.2.2. Ability to Rate Limit Traffic To the Device +4.1. Specify Filter Actions 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. + 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 allows the operator to apply rate-limits that protect the - device itself from attacks and unauthorized access. + * Specify Filter Actions(Section 7.10) 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. + 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. - 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. + Actions such as "permit", "deny", "drop" are essential in defining + the security policy for the services offered by the network + devices. 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. + 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.4. Ability to Rate Limit To the Device - Specify Rate Limit Actions +4.2. Specify Rate Limits 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). + 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. - * This capability is essential to the use of rate limits to - enforce policy. + * Specify Rate 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 - 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. + 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. -2.2.5. Ability to Rate Limit To the Device - Log Rate Limit Actions +4.3. Specify Log Actions Capability. - It is possible to log rate limit actions. The logging capability + It is possible to log all filter actions. The logging capability is able to capture at least the following data: * 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. -2.2.6. Ability to Rate Limit To the Device - Specify Log Granularity +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 is defined that has several rules, and one of the + If a filter is defined that has several rules, and one of the rules denies telnet (tcp/23) connections, then it should be 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 +4.5. Ability to Display Filter Counters Capability. - The device provides a mechanism to display rate limit counters. + 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. - + * Display Filter Counters (Section 7.14) 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. + 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.2.13. Ability to Rate Limit To the Device - Ability to Display Rate - Limit Counters per Rate Limit Application +5. Counters + +5.1. Ability to Display Filter Counters per Filter 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. + 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 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. + * Counters (Section 7.15) 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 + 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 rate limit 'desktop_outbound' on ethernet0 ..." - and "matches of rate limit 'desktop_outbound' on ethernet1 ..." + like "matches of filter 'desktop_outbound' on ethernet0 ..." and + "matches of filter 'desktop_outbound' on ethernet1 ..." Considerations. None. -2.2.14. Ability to Rate Limit To the Device - Ability to Reset Rate - Limit Counters +5.2. Ability to Reset Filter Counters + Capability. - It is possible to reset counters to zero on a per rate limit - basis. + 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/rate limit. - + * Reset Counters (Section 7.16) Current Implementations. - Assume that rate limit counters are being used to detect internal + Assume that filter counters are being used to detect internal hosts that are infected with a new worm. Once it is believed that 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. + to reset the filter counters to zero and see if traffic indicative + of the worm has ceased. 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 +5.3. Filter Hits are Accurately Counted Capability. - The device provides a means to filter IP packets on any interface - implementing IP that are transit packets. + The device supplies a facility for accurately counting all filter + matches. 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) + * Filter Hits are Accurately Counted (Section 7.17) 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. + Assume, for example, that a ISP network implements anti-spoofing + egress filters (see [RFC2827]) on interfaces of its edge routers + that support single-homed stub networks. Counters could enable + the ISP to detect cases where large numbers of spoofed packets are + being sent. This may indicate that the customer is performing + potentially malicious actions (possibly in violation of the ISPs + Acceptable Use Policy), or that system(s) on the customers network + have been "owned" by hackers and are being (mis)used to launch + attacks. Considerations. None. -3.1.2. Ability to Filter Traffic Through the Device +5.4. Filter Counters are Accurate Capability. - It is possible to apply the filtering mechanism to traffic that is - flowing through the device via any of its interfaces - transit - traffic. + 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. - * This allows the operator to apply filters that protect the - networks supported by the device from attacks and unauthorized - access. + * Filter Hits are Accurately (Section 7.18) 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. + If N packets matching a filter are sent to/through a device, then + the counter should show N matches. Considerations. None. -3.1.3. Ability to Filter Traffic Through the Device - Minimal - Performance Degradation +6. 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). + interfaces (up to the total number of interfaces attached to the + device) simultaneously and with multiple filters per interface + (e.g., inbound and outbound). - The filtering of traffic through the device should not degrade - performance significantly. + 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 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. + * Minimal Performance Degradation (Section 7.19) 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. @@ -1347,1042 +693,239 @@ 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 + 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 appropriate for fear that it might + cause unnecessary service disruption. - Capability. +7. Additional Operational Practices - It is possible to enable/disable logging on a per rule basis. + This section describes practices not covered in [I-D.ietf-opsec- + current-practices]. They are included here to provide justification + for capabilities that reference them. - Supported Practices. +7.1. Profile Current Traffic - * The ability to tune the granularity of logging allows the - 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. + This capability allows a network operator to monitor traffic across + an active interface in the network at a minimal level. This helps to + determine probable cause for interface or network problems. - Current Implementations. + The ability to separate and distinguish traffic at a layer-3 or + layer-4 level allows the operator to characterize beyond simple + interface counters the traffic in question. This is critical because + often the operator has no tools available for protocol analysis aside + from interface filters. - If a filter is defined that has several rules, and one of the - 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. +7.2. Block Malicious Packets - Considerations. + Blocking or limiting traffic deemed to be malicious is a key + component of application of any security policy's implementation. + Clearly it is critical to be able to implement a security policy on a + network. - None. + Malicious packets could potentially be defined by any part of the + layer-3 or layer-4 headers of the IP packet. The ability to classify + or select traffic based on these criteria and take some action based + on that classification is critical to operations of a network. -3.1.7. Ability to Filter Through the Device - Ability to Filter - Protocols +7.3. Limit Sources of Management - Capability. + Management of a network should be limited to only trusted hosts. + This implies that the network elements will be able to limit access + to management functions to these trusted hosts. - The device provides a means to filter traffic based on the value - of the protocol field in the IP header. + Currently operators will limit access to 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 + protection of those functions on the network devices. - Supported Practices. +7.4. Select Traffic To the Device - * Being able to filter on protocol is necessary to allow - implementation of policy, secure operations and for support of - incident response. + This allows the operator to apply filters that protect the device + itself from attacks and unauthorized access. - Current Implementations. +7.5. Select Transit Traffic - 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. + This allows the operator to apply filters that protect the networks + and assets surrounding the device from attacks and unauthorized + access. - Considerations. +7.6. Select Traffic Inbound and/or Outbound - None. + This allows flexibility in applying filters at the place that makes + the most sense. It allows invalid or malicious traffic to be dropped + as close to the source as possible with the least impact on other + traffic transiting the interface(s) in question. -3.1.8. Ability to Filter Through the Device - Ability to Filter - Addresses - Capability. +7.7. Select Traffic by Protocol - 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. + Being able to filter on protocol is necessary to allow implementation + of policy, secure operations and for support of incident response. + Filtering all traffic to a destination host is not often possible, + business requirements will dictate that critical traffic be permitted + if at all possible. - Supported Practices. +7.8. Select Traffic by Addresses - * The capability to filter on addresses and address blocks is a + The capability to filter on addresses and address blocks is a fundamental tool for establishing boundaries between different 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 of the protocol headers for IP, ICMP, UDP and TCP. - It supports filtering of all other protocols supported at layer 3 - and 4. It supports filtering based on the headers of higher level - protocols. It is possible to specify fields by name (e.g., - "protocol = ICMP") rather than bit- offset/length/numeric value - (e.g., 72:8 = 1). - - Supported Practices. - - * Being able to filter on portions of the header is necessary to - allow implementation of policy, secure operations, and support - incident response. - - Current Implementations. - - This capability implies that it is possible to filter based on TCP - or UDP port numbers, TCP flags such as SYN, ACK and RST bits, and - ICMP type and code fields. One common example is to reject TCP - connection attempts (TCP, SYN bit set+ACK bit clear or SYN bit - set+ACK,FIN and RST bits clear). Another common example is the - ability to control what services are allowed in/out of a network. - It may be desirable to only allow inbound connections on port 80 - (HTTP) and 443 (HTTPS) to a network hosting web servers. - - Considerations. - - None. - -3.1.10. Ability to Filter Through the Device - Ability to Filter - Inbound and Outbound - - Capability. - - It is possible to filter both incoming and outgoing traffic on any - interface. - - Supported Practices. - - * This capability allows flexibility in applying filters at the - place that makes the most sense. It allows invalid or - malicious traffic to be dropped as close to the source as - possible. - - Current Implementations. - - It might be desirable on a border router, for example, to apply an - egress filter outbound on the interface that connects a site to - its external ISP to drop outbound traffic that does not have a - valid internal source address. Inbound, it might be desirable to - apply a filter that blocks all traffic from a site that is known - to forward or originate lots of junk mail. - - Considerations. - - None. - -3.1.11. Ability to Filter Through the Device - Ability to Accurately - Count Filter Hits - - Capability. - - The device supplies a facility for accurately counting all filter - matches. - - Supported Practices. - - * Accurate counting of filter rule matches is important because - it shows the frequency of attempts to violate policy. This - enables resources to be focused on areas of greatest need. - - Current Implementations. - - Assume, for example, that a ISP network implements anti-spoofing - egress filters (see [RFC2827]) on interfaces of its edge routers - that support single-homed stub networks. Counters could enable - the ISP to detect cases where large numbers of spoofed packets are - being sent. This may indicate that the customer is performing - potentially malicious actions (possibly in violation of the ISPs - Acceptable Use Policy), or that system(s) on the customers network - have been "owned" by hackers and are being (mis)used to launch - attacks. - - Considerations. - - None. - -3.1.12. Ability to Filter Through the Device - Ability to Display - Filter Counters - - Capability. - - The device provides a mechanism to display filter counters. - - Supported Practices. - - * Information that is collected is not useful unless it can be - displayed in a useful manner. - - Current Implementations. - - Assume there is a router with four interfaces. One is an up-link - to an ISP providing routes to the Internet. The other three - connect to separate internal networks. Assume that a host on one - of the internal networks has been compromised by a hacker and is - sending traffic with bogus source addresses. In such a situation, - it might be desirable to apply ingress filters to each of the - internal interfaces. Once the filters are in place, the counters - can be examined to determine the source (inbound interface) of the - bogus packets. - - Considerations. +7.9. Select Traffic by Protocol Header Field - None. + Being able to filter on portions of the header is necessary to allow + implementation of policy, secure operations, and support incident + response. -3.1.13. Ability to Filter Through the Device - Ability to Display - Filter Counters per Filter Application +7.10. Specify Filter Actions - Capability. + This capability is essential to the use of filters to enforce policy. + With a defined filter classification of some traffic and no action + defined there is little use for the filter, actions must be included + in order to provide the requisite security. - If it is possible for a filter to be applied more than once at the - same time, then the device provides a mechanism to display filter - counters per filter application. +7.11. Specify Rate Limits - Supported Practices. + This capability allows a filter to be used to rate limit a portion of + traffic through or to a device. It maybe desirable to limit SNMP + (UDP/161) traffic to a device, but not deny it completely. + Similarly, one might want to implement ICMP filters toward an + external network instead of discarding all ICMP traffic. - * It may make sense to apply the same filter definition - 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. +7.12. Specify Log Actions - Current Implementations. + Logging is essential for auditing, incident response, and operations - 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. +7.13. Log Granularity - None. + The ability to tune the granularity of logging allows the operator to + log the information that is desired and only the information that is + desired. Without this capability, it is possible that extra data (or + none at all) would be logged, making it more difficult to find + relevant information. -3.1.14. Ability to Filter Through the Device - Ability to Reset Filter - Counters +7.14. Display Filter Counters - Capability. + Information that is collected is not useful unless it can be + displayed. - It is possible to reset counters to zero on a per filter basis. +7.15. Counters - For the purposes of this capability it would be acceptable for the - 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]). + 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. - Supported Practices. +7.16. Ability to Reset Filter Counters - * This allows operators to get a current picture of the traffic + This allows operators to get a current picture of the traffic matching particular rules/filters. - 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. - -3.1.15. Ability to Filter Through the Device - Filter Counters are - Accurate - - Capability. - - Filter counters are accurate. They reflect the actual number of - matching packets since the last counter reset. Filter counters - are be capable of holding up to 2^32 - 1 values without - overflowing and should be capable of holding up to 2^64 - 1 - values. - - Supported Practices. - - * Inaccurate data can not be relied on as the basis for action. - Underreported data can conceal the magnitude of a problem. - - Current Implementations. - - If N packets matching a filter are sent to/through a device, then - the counter should show N matches. - - Considerations. - - None. - -3.2. Rate Limit THROUGH the Device - -3.2.1. Ability to Rate limit Traffic on All Interfaces THROUGH the - Device - - Capability. - - The device provides a means to rate limit IP packets on any - interface implementing IP that are transit packets. - - Supported Practices. - - * Profile Current Traffic ([I-D.practices] Section x.x.x) - - * Block Malicious Packets (Section 5.2) - - * Limit Sources of Management (Section 5.3) - - Current Implementations. - - Many devices currently implement rate limits that allow rate - limiting based on protocol and/or source/destination address and - or source/destination port or raw bandwidth and allow these limits - to be applied to interfaces. - - Considerations. - - None. - -3.2.2. Ability to Rate Limit Traffic Through the Device - - Capability. - - It is possible to apply the rate-limiting mechanism to traffic - that is transiting the device via any of its interfaces. - - Supported Practices. - - * This allows the operator to apply rate-limits that protect the - networks transiting the device from attacks and unauthorized - access. - - Current Implementations. - - Many devices currently implement rate-limits that allow limiting - based on protocol and/or source/destination address and or source/ - destination port and allow these limits to be applied to services - offered by the networks which transit the device. - - Examples of this might include rate-limits that permit SSH traffic - rates up to 100 megabits per second from an authorized peer, while - dropping all other traffic addressed to the network which exceeds - this limit. - - Considerations. - - None. - -3.2.3. Ability to Rate Limit Traffic Through the Device - Minimal - Performance Degradation - - Capability. - - The device provides a means to rate-limit packets without - significant performance degradation. - - The device is able to apply rate-limits on ALL interfaces (up to - the maximum number possible) simultaneously and with multiple - rate-limits per interface (e.g., inbound, outbound, differing - traffic classifications in either direction). - - The rate-limiting of traffic destined to networks transiting the - device should not degrade performance significantly. - - Supported Practices. - - * This enables the implementation of rate-limits on whichever - services are necessary. To the extent that rate-limiting - causes degradation, it may not be possible to apply rate-limits - that implement the appropriate policies. - - Current Implementations. - - Another way of stating the capability is that rate-limit - performance should not be the limiting factor in device - throughput. If a device is capable of forwarding 30Mb/sec without - rate-limits, then it should be able to forward the same amount - with rate-limits in place. - - Considerations. - - The definition of "significant" is subjective. At one end of the - spectrum it might mean "the application of rate-limits may cause - the box to crash". At the other end would be a throughput loss of - less than one percent with tens of thousands of rate-limits - applied. The level of performance degradation that is acceptable - will have to be determined by the operator. - - Repeatable test data showing rate-limiting performance impact - would be very useful in evaluating this capability. Tests should - include such information as packet size, packet rate, number of - interfaces tested (source/destination), types of interfaces, - routing table size, routing protocols in use, frequency of routing - updates, etc. - -3.2.4. Ability to Rate Limit Through the Device - Specify Rate Limit - Actions - - Capability. - - The device provides a mechanism to allow the specification of the - action to be taken when a rate-limit rule matches. Actions - include "permit" (allow the traffic), "reject" (drop with - appropriate notification to sender), and "drop" (drop with no - notification to sender). - - Supported Practices. - - * This capability is essential to the use of rate limits to - enforce policy. - - Current Implementations. - - Assume that your management devices for deployed networking - devices live on several subnets, use several protocols, and are - controlled by several different parts of your organization. There - might exist a reason to have disparate policies for access to the - devices from these parts of the organization. Further you may - want to limit traffic levels for these types of traffic from these - known sources as close to the sources as possible via interface - rate limits implemented on the supporting network devices for - those source networks. - - Actions such as "permit", "deny", "drop" are essential in defining - the security policy for the services offered by the network - devices. - - Considerations. - - While silently dropping traffic without sending notification may - be the correct action in security terms, consideration should be - given to operational implications. See [RFC3360] for - consideration of potential problems caused by sending - inappropriate TCP Resets. - -3.2.5. Ability to Rate Limit Through the Device - Log Rate Limit - Actions - - Capability. - - It is possible to log rate limit actions. The logging capability - is able to capture at least the following data: - - * permit/deny/drop status - - * source and destination IP address - - * source and destination ports (if applicable to the protocol) - - * which network element received the packet (interface, MAC - address or other layer 2 information that identifies the - previous hop source of the packet). - - Supported Practices. - - * Logging is essential for auditing, incident response, and - operations - - Current Implementations. - - Actions such as "permit", "deny", "drop" are essential in defining - the security policy for the services offered by the network - devices. Auditing the frequency, sources and destinations of - these attempts is essential for tracking ongoing issues today. - - Considerations. - - Logging can be burdensome to the network device, at no time should - logging cause performance degradation to the device or services - offered on the device. - -3.2.6. Ability to Rate Limit Through the Device - Specify Log - Granularity - - Capability. - - It is possible to enable/disable logging on a per rule basis. - - Supported Practices. - - * The ability to tune the granularity of logging allows the - operator to log the information that is desired and only the - information that is desired. Without this capability, it is - possible that extra data (or none at all) would be logged, - making it more difficult to find relevant information. - - Current Implementations. - - If a rate limit is defined that has several rules, and one of the - rules denies telnet (tcp/23) connections, then it should be - possible to specify that only matches on the rule that denies - telnet should generate a log message. - - Considerations. - - None. - -3.2.7. Ability to Rate Limit Through the Device - Ability to Rate Limit - Protocols - - Capability. - - The device provides a means to rate limit traffic based on the - value of the protocol field in the IP header. - - Supported Practices. - - * Being able to rate limit on protocol is necessary to allow - implementation of policy, secure operations and for support of - incident response. - - Current Implementations. - - Some denial of service attacks are based on the ability to flood - the victim with ICMP traffic. One quick way (admittedly with some - negative side effects) to mitigate the effects of such attacks is - to rate limit all ICMP traffic headed toward the victim. - - Considerations. - - None. - -3.2.8. Ability to Rate Limit Through the Device - Ability to Rate Limit - Addresses - - Capability. - - The function is able to control the flow of traffic based on - source and/or destination IP address or blocks of addresses such - as Classless Inter-Domain Routing (CIDR) blocks. - - Supported Practices. - - * The capability to rate limit on addresses and address blocks is - a fundamental tool for establishing boundaries between - different networks. - - Current Implementations. - - One example of the use of address based rate limits is to - implement ingress filtering per [RFC2827]. - - Considerations. - - None. - -3.2.9. Ability to Rate Limit Through the Device - Ability to Rate Limit - Protocol Header Fields - - Capability. - - The rate limit mechanism supports rate limiting based on the - value(s) of any portion of the protocol headers for IP, ICMP, UDP - and TCP. It supports rate limiting of all other protocols - supported at layer 3 and 4. It supports rate limiting based on - the headers of higher level protocols. It is possible to specify - fields by name (e.g., "protocol = ICMP") rather than bit- offset/ - length/numeric value (e.g., 72:8 = 1). - - Supported Practices. - - * Being able to rate limit on portions of the header is necessary - to allow implementation of policy, secure operations, and - support incident response. - - Current Implementations. - - This capability implies that it is possible to rate limit based on - TCP or UDP port numbers, TCP flags such as SYN, ACK and RST bits, - and ICMP type and code fields. One common example is to reject - "inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear - or SYN bit set+ACK,FIN and RST bits clear). Another common - example is the ability to control what services are allowed in/out - of a network. It may be desirable to only allow inbound - connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting - web servers. - - Considerations. - - None. - -3.2.10. Ability to Rate Limit Through the Device - Ability to Rate - Limit Inbound and Outbound - - Capability. - - It is possible to rate limit both incoming and outgoing traffic on - any interface to or from any transiting network. - - Supported Practices. - - * This capability allows flexibility in applying rate limits at - the place that makes the most sense. It allows invalid or - malicious traffic to be dropped as close to the source as - possible. - - Current Implementations. - - It might be desirable on a router to apply an egress rate limit to - its external connections to limit outbound traffic that does not - have a high priority. Inbound, it might be desirable to apply a - rate limit to all traffic of a certain classification in order to - preserve limited resources on the sported networks behind the - device. - - Considerations. - - None. - -3.2.11. Ability to Rate Limit Through the Device - Ability to - Accurately Count Rate Limit Hits - - Capability. - - The device supplies a facility for accurately counting all rate - limit matches. - - Supported Practices. - - * Accurate counting of rate limit rule matches is important - because it shows the frequency of attempts to violate policy. - This enables resources to be focused on areas of greatest need. - - Current Implementations. - - Assume, for example, that a ISP network implements anti-spoofing - egress rate limits (see [RFC2827]) on interfaces of its edge - routers that support single-homed stub networks. Counters could - enable the ISP to detect cases where large numbers of spoofed - packets are being sent. This may indicate that the customer is - performing potentially malicious actions (possibly in violation of - the ISPs Acceptable Use Policy), or that system(s) on the - customers network have been compromised by hackers and are being - (mis)used to launch attacks. - - Considerations. - - None. - -3.2.12. Ability to Rate Limit Through the Device - Ability to Display - Rate Limit Counters - - Capability. - - The device provides a mechanism to display rate limit counters. - - Supported Practices. - - * Information that is collected is not useful unless it can be - displayed in a useful manner. - - Current Implementations. - - Assume there is a router with four interfaces. One is an up-link - to an ISP providing routes to the Internet. The other three - connect to separate internal networks. Assume that a host on one - of the internal networks has been compromised by a hacker and is - sending traffic with bogus source addresses. In such a situation, - it might be desirable to apply ingress rate limits to each of the - internal interfaces. Once the rate limits are in place, the - counters can be examined to determine the source (inbound - interface) of the bogus packets. - - Considerations. - - None. - -3.2.13. Ability to Rate Limit Through the Device - Ability to Display - Rate Limit Counters per Rate Limit Application - - Capability. - - If it is possible for a rate limit to be applied more than once at - the same time, then the device provides a mechanism to display - rate limit counters per rate limit application. - - Supported Practices. - - * It may make sense to apply the same rate limit definition - simultaneously more than one time (to different interfaces, - etc.). If so, it would be much more useful to know which - instance of a rate limit is matching than to know that some - instance was matching somewhere. - - Current Implementations. - - One way to implement this capability would be to have the counter - display mechanism show the interface (or other entity) to which - the rate limit has been applied, along with the name (or other - designator) for the rate limit. For example if a rate limit named - "desktop_outbound" applied two different interfaces, say, - "ethernet0" and "ethernet1", the display should indicate something - like "matches of rate limit 'desktop_outbound' on ethernet0 ..." - and "matches of rate limit 'desktop_outbound' on ethernet1 ..." - - Considerations. - - None. - -3.2.14. Ability to Rate Limit Through the Device - Ability to Reset - Rate Limit Counters - - Capability. - - It is possible to reset counters to zero on a per rate limit - basis. - - For the purposes of this capability it would be acceptable for the - system to maintain two counters: an "absolute counter", C[now], - and a "reset" counter, C[reset]. The absolute counter would - maintain counts that increase monotonically until they wrap or - overflow the counter. The reset counter would receive a copy of - the current value of the absolute counter when the reset function - was issued for that counter. Functions that display or retrieve - the counter could then display the delta (C[now] - C[reset]). - - Supported Practices. - - * This allows operators to get a current picture of the traffic - matching particular rules/rate limit. - - Current Implementations. - - Assume that rate limit counters are being used to detect internal - hosts that are infected with a new worm. Once it is believed that - all infected hosts have been cleaned up and the worm removed, the - next step would be to verify that. One way of doing so would be - to reset the rate limit counters to zero and see if traffic - indicative of the worm has ceased. - - Considerations. - - None. - -3.2.15. Ability to Rate Limit Through the Device - Rate Limit Counters - are Accurate - - Capability. - - Rate limit counters are accurate. They reflect the actual number - of matching packets since the last counter reset. Rate limit - counters are be capable of holding up to 2^32 - 1 values without - overflowing and should be capable of holding up to 2^64 - 1 - values. - - Supported Practices. - - * Inaccurate data can not be relied on as the basis for action. - Underreported data can conceal the magnitude of a problem. - - Current Implementations. - - If N packets matching a Rate limit are sent to/through a device, - then the counter should show N matches. - - Considerations. - - None. - -4. Functional Capabilities - Filtering Layer 2 Attributes - - The capabilities in this section are intended to list testable, - functional capabilities that are needed to operate devices securely. - - A layer-2 domain permits all devices in the domain to establish - communication at layer-2. Devices thus connected have an implicit - trust relationship among themselves. If there are devices in a - layer-2 domain which are at different trust levels, we may want to - filter traffic between such devices based on the trust levels or any - other fields in the layer-2 header. The following filtering - capabilities are required at layer-2. - -4.1. Filtering Layer 2 - -4.1.1. Ability to partition layer-2 network to provide different levels - of security - - Capability. - - The device provides a means to partition the physical layer-2 - domain into multiple virtual domains, thus allowing the filtering - of unwarranted traffic. - - Supported Practices. - - * Being able to partition a layer-2 domain provides the same - level of security within a layer-2 domain as can be guaranteed - if they were different layer-2 domains. - - Current Implementations. - - Most Ethernet networks use the concept of VLAN [8021Q] to - partition a layer-2 broadcast domain. Private VLAN's [PVLAN] - allow further partitioning of VLANs's into smaller domains. - - Considerations. - - Not all layer-2 network technologies may lend themselves to - virtual partitioning. - -4.1.2. Ability to restrict access to specified hardware (MAC) addresses - - Capability. - - The device provides a means to filter traffic based on the source - and/ or destination hardware address. - - Supported Practices. - - * Being able to filter on hardware Address provides an ability to - block frames between devices in the same layer-2 domain to - communicate. - - Current Implementations. - - The ability to filter and monitor traffic in layer-2 allows for - security at layer-2 itself, between devices on the same network. - Allowing filtering based on hardware address allows a simple - filtering interface to the administrator to apply simple policy - rules. - - Considerations. - - Different Link layer technologies use different addressing - mechanisms. - -4.1.3. Ability to restrict based on layer-2 packet type [etherType] - field - - Capability. - - The device provides a means to filter packets based on the packet - type field in the layer-2 header. - - Supported Practices. - - * Being able to filter on packets based on the packet type field - helps in preventing packets not understandable by a particular - device to be processed by it. - - Current Implementations. - - The ability to filter and monitor traffic in layer-2 allows for - security at layer-2 itself. This capability can also prevent IPX - packets to inadvertently be sent to an IP device and vice versa. - - Considerations. - - None. - -5. Additional Operational Practices - - This section describes practices not covered in [I-D.practices]. - They are included here to provide justification for capabilities that - reference them. - -5.1. Profile Current Traffic +7.17. Filter Hits are Accurately Counted - Discuss practice. Use same format as [I-D.practices]. + Accurate counting of filter rule matches is important because it + shows the frequency of attempts to violate policy. This enables + resources to be focused on areas of greatest need. -5.2. Block Malicious Packets +7.18. Filter Hits are Accurate - Discuss practice. Use same format as [I-D.practices]. + Inaccurate data can not be relied on as the basis for action. Under- + reported data can conceal the magnitude of a problem. -5.3. Limit Sources of Management +7.19. Minimal Performance Degredation - Discuss practice. Use same format as [I-D.practices]. + This enables the implementation of filters on whichever services are + necessary. To the extent that filtering causes degradation, it may + not be possible to apply filters that implement the appropriate + policies. -6. Security Considerations +8. Security Considerations General Security is the subject matter of this entire memo. The - capabilities listed cite practices in [I-D.practices] that they - are intended to support. [I-D.practices] defines the threat - model, practices and lists justifications for each practice. - -7. References - -7.1. Normative References + capabilities listed cite practices in [I-D.ietf-opsec-current- + practices] that they are intended to support. [I-D.ietf-opsec- + current-practices] defines the threat model, practices and lists + justifications for each practice. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. +9. Non-normative References -7.2. Non-normative References + [I-D.ietf-opsec-current-practices] + Kaeo, M., "Operational Security Current Practices", + draft-ietf-opsec-current-practices-04 (work in progress), + June 2006. - [8021Q] "802.1Q - Virtual LANs", IEEE Standard 802.1Q - Virtual - LANs, August 2001. + [I-D.lewis-infrastructure-security] + Lewis, D., "Service Provider Infrastructure Security", + draft-lewis-infrastructure-security-00 (work in progress), + June 2006. - [I-D.practices] - Kaeo, M., "Operational Security Current Practices", - Internet-Draft (to be published) - draft-ietf-opsec-current-practices-00, February 2005. + [I-D.savola-rtgwg-backbone-attacks] + Savola, P., "Backbone Infrastructure Attacks and + Protections", draft-savola-rtgwg-backbone-attacks-01 (work + in progress), June 2006. - [PVLAN] HomChaudhuri, S. and M. Foschiano, "Private VLANs: - Addressing VLAN scalability and security issues in a - multi-client environment", Internet Draft (to be - published) draft-sanjib-private-vlan-02, June 2004. + [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, + [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000. - [RFC3631] Bellovin, S. and J. Schiller, "Security Mechanisms for the - Internet", RFC 3631, December 2003. + [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", + BCP 60, RFC 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. @@ -2405,18 +948,18 @@ 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). This document is subject + Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and 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.