[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 3871

None.                                                   G. Jones, Editor
Internet-Draft                                     The MITRE Corporation
Expires: December 8, 2003                                   June 9, 2003


    Network Security Requirements for Devices Implementing Internet
                                Protocol
                          draft-jones-opsec-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 except that the right to
   produce derivative works is not granted.

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

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

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

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

   This Internet-Draft will expire on December 8, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   This document defines a list of security requirements for devices
   that implement the Internet Protocol (IP).  These requirements apply
   to devices that makeup the network core infrastructure (such as
   routers and switches) as well other devices that implement IP (e.g.,
   cable modems, personal firewalls,hosts). A framework is defined for
   specifying "profiles", which are collections of devices applicable to
   certain classes of devices. The goal is to provide consumers of
   network equipment a clear, concise way of communicating their
   security requirements to vendors of such equipment. Please send any
   COMMENTS TO: "opsec-comment@ops.ietf.org".  ALSO SEE "http://
   www.port111.com/opsec/opsec-meta.txt".



Jones, Editor           Expires December 8, 2003                [Page 1]

Internet-Draft       Network Security Requirements             June 2003


Table of Contents

   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  5
   1.1     Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   1.2     Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   1.3     Context  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   1.4     Intended Audience  . . . . . . . . . . . . . . . . . . . .  5
   1.5     Format . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   1.6     Intended Use . . . . . . . . . . . . . . . . . . . . . . .  6
   1.7     Definitions  . . . . . . . . . . . . . . . . . . . . . . .  7
   2.      Best Current Practice  . . . . . . . . . . . . . . . . . .  8
   2.1     Device Management Requirements . . . . . . . . . . . . . .  8
   2.1.1   Support Out-of-Band Management (OoB) Interfaces  . . . . .  8
   2.1.2   Enforce Separation of Data and Control Channels  . . . . .  8
   2.1.3   Separation Not Achieved by Filtering . . . . . . . . . . .  9
   2.1.4   No Forwarding Between Management and Data Planes . . . . .  9
   2.1.5   Device Remains Manageable at All Times . . . . . . . . . .  9
   2.1.6   Support Remote Configuration Backup  . . . . . . . . . . . 10
   2.1.7   Support Management Over Slow Links . . . . . . . . . . . . 11
   2.2     User Interface Requirements  . . . . . . . . . . . . . . . 11
   2.2.1   Support Human-Readable Configuration File  . . . . . . . . 11
   2.2.2   Display of 'Sanitized' Configuration . . . . . . . . . . . 11
   2.3     IP Stack Requirements  . . . . . . . . . . . . . . . . . . 12
   2.3.1   Comply With Relevant IETF RFCs on All Protocols
           Implemented  . . . . . . . . . . . . . . . . . . . . . . . 12
   2.3.2   Provide a List of All Protocols Implemented  . . . . . . . 14
   2.3.3   Provide Documentation for All Protocols Implemented  . . . 14
   2.3.4   Ability to Identify All Listening Services . . . . . . . . 14
   2.3.5   Ability to Disable Any and All Services  . . . . . . . . . 15
   2.3.6   Ability to Control Service Bindings for Listening
           Services . . . . . . . . . . . . . . . . . . . . . . . . . 15
   2.3.7   Ability to Control Service Source Address  . . . . . . . . 16
   2.3.8   Ability to Withstand Well-Known Attacks and Exploits . . . 16
   2.3.9   Maintain Primary Function at All Times . . . . . . . . . . 17
   2.3.10  Support Automatic Anti-spoofing for Single-Homed
           Networks . . . . . . . . . . . . . . . . . . . . . . . . . 18
   2.3.11  Ability to Disable Processing of Packets Utilizing IP
           Options  . . . . . . . . . . . . . . . . . . . . . . . . . 19
   2.3.12  Ability to Disable Directed Broadcasts . . . . . . . . . . 19
   2.3.13  Identify Origin of IP Stack  . . . . . . . . . . . . . . . 20
   2.3.14  Identify Origin of Operating System  . . . . . . . . . . . 20
   2.4     Rate Limiting Requirements . . . . . . . . . . . . . . . . 20
   2.4.1   Support Rate Limiting  . . . . . . . . . . . . . . . . . . 21
   2.4.2   Support Rate Limiting Based on State . . . . . . . . . . . 21
   2.5     Ability to Filter Traffic  . . . . . . . . . . . . . . . . 22
   2.6     Packet Filtering Criteria  . . . . . . . . . . . . . . . . 22
   2.6.1   Ability to Filter on Protocols . . . . . . . . . . . . . . 22
   2.6.2   Ability to Filter on Addresses . . . . . . . . . . . . . . 22



Jones, Editor           Expires December 8, 2003                [Page 2]

Internet-Draft       Network Security Requirements             June 2003


   2.6.3   Ability to Filter on Any Protocol Header Fields  . . . . . 23
   2.6.4   Ability to Filter Inbound and Outbound . . . . . . . . . . 23
   2.6.5   Ability to Filter on Layer 2 MAC Addresses . . . . . . . . 24
   2.7     Packet Filtering Application Targets . . . . . . . . . . . 24
   2.7.1   Ability to Filter Traffic Through the Device . . . . . . . 24
   2.7.2   Ability to Filter Traffic to the Device  . . . . . . . . . 24
   2.7.3   Ability to Filter Updates  . . . . . . . . . . . . . . . . 25
   2.8     Packet Filtering Actions . . . . . . . . . . . . . . . . . 25
   2.8.1   Ability to Specify Filter Actions  . . . . . . . . . . . . 25
   2.9     Packet Filtering Counter Requirements  . . . . . . . . . . 26
   2.9.1   Ability to Accurately Count Filter Hits  . . . . . . . . . 26
   2.9.2   Ability to Display Filter Counters . . . . . . . . . . . . 26
   2.9.3   Ability to Display Filter Counters per Rule  . . . . . . . 27
   2.9.4   Ability to Display Filter Counters per Filter
           Application  . . . . . . . . . . . . . . . . . . . . . . . 27
   2.9.5   Ability to Reset Filter Counters . . . . . . . . . . . . . 28
   2.9.6   Filter Counters Must Be Accurate . . . . . . . . . . . . . 28
   2.10    Other Packet Filtering Requirements  . . . . . . . . . . . 28
   2.10.1  Ability to Log Filter Actions  . . . . . . . . . . . . . . 29
   2.10.2  Ability to Specify Filter Log Granularity  . . . . . . . . 29
   2.10.3  Ability to Filter Without Performance Degradation  . . . . 29
   2.10.4  Filter, Counters, and Filter Log Performance Must Be
           Usable . . . . . . . . . . . . . . . . . . . . . . . . . . 30
   2.11    Event Logging Requirements . . . . . . . . . . . . . . . . 31
   2.11.1  Ability to Log All Events That Affect System Integrity . . 31
   2.11.2  Logging Facility Conforms to Open Standards  . . . . . . . 32
   2.11.3  Catalog of Log Messages Available  . . . . . . . . . . . . 32
   2.11.4  Ability to Log to Remote Server  . . . . . . . . . . . . . 32
   2.11.5  Ability to Select Reliable Delivery  . . . . . . . . . . . 33
   2.11.6  Ability to Configure Security of Log Messages  . . . . . . 33
   2.11.7  Ability to Log Locally . . . . . . . . . . . . . . . . . . 33
   2.11.8  Ability to Specify Logservers by Event Classification  . . 34
   2.11.9  Ability to Classify Events . . . . . . . . . . . . . . . . 34
   2.11.10 Ability to Maintain Accurate System Time . . . . . . . . . 35
   2.11.11 Logs Must Be Timestamped . . . . . . . . . . . . . . . . . 35
   2.11.12 Logs Contain Untranslated Addresses  . . . . . . . . . . . 36
   2.11.13 Logs Do Not Contain DNS Names by Default . . . . . . . . . 36
   2.12    Authentication, Authorization, and Accounting (AAA)
           Requirements . . . . . . . . . . . . . . . . . . . . . . . 37
   2.12.1  Authenticate All User Access . . . . . . . . . . . . . . . 37
   2.12.2  Support Authentication of Individual Users . . . . . . . . 37
   2.12.3  Support Simultaneous Connections . . . . . . . . . . . . . 37
   2.12.4  Ability to Disable All Local Accounts  . . . . . . . . . . 38
   2.12.5  Support Centralized User Authentication  . . . . . . . . . 38
   2.12.6  Support Local User Authentication  . . . . . . . . . . . . 39
   2.12.7  Support Configuration of Order of Authentication
           Methods  . . . . . . . . . . . . . . . . . . . . . . . . . 39
   2.12.8  Ability to Authenticate Without Reusable Plaintext



Jones, Editor           Expires December 8, 2003                [Page 3]

Internet-Draft       Network Security Requirements             June 2003


           Passwords  . . . . . . . . . . . . . . . . . . . . . . . . 39
   2.12.9  Support Device-to-Device Authentication  . . . . . . . . . 40
   2.12.10 Ability to Define Privilege Levels . . . . . . . . . . . . 41
   2.12.11 Ability to Assign Privilege Levels to Users  . . . . . . . 41
   2.12.12 Default Privilege Level Must Be Read Only  . . . . . . . . 42
   2.12.13 Change in Privilege Levels Requires Re-Authentication  . . 42
   2.12.14 Accounting Records . . . . . . . . . . . . . . . . . . . . 42
   2.13    Layer 2 Requirements . . . . . . . . . . . . . . . . . . . 43
   2.13.1  Filtering MPLS LSRs  . . . . . . . . . . . . . . . . . . . 43
   2.13.2  VLAN Isolation . . . . . . . . . . . . . . . . . . . . . . 44
   2.13.3  Layer 2 Denial-of-Service  . . . . . . . . . . . . . . . . 44
   2.13.4  Layer 3 Dependencies . . . . . . . . . . . . . . . . . . . 45
   2.14    Vendor Behavior  . . . . . . . . . . . . . . . . . . . . . 45
   2.14.1  Vendor Responsiveness  . . . . . . . . . . . . . . . . . . 45
   3.      Non-Standard Requirements  . . . . . . . . . . . . . . . . 47
   3.1     Device Management Requirements . . . . . . . . . . . . . . 47
   3.1.1   Support Secure Management Channels . . . . . . . . . . . . 47
   3.1.2   Use Non-Proprietary Encryption . . . . . . . . . . . . . . 48
   3.1.3   Use Strong Encryption  . . . . . . . . . . . . . . . . . . 48
   3.1.4   Key Management Must Be Scalable  . . . . . . . . . . . . . 49
   3.1.5   Support Scripting of Management Functions  . . . . . . . . 49
   3.2     User Interface Requirements  . . . . . . . . . . . . . . . 50
   3.2.1   Display All Configuration Settings . . . . . . . . . . . . 50
   3.3     IP Stack Requirements  . . . . . . . . . . . . . . . . . . 50
   3.3.1   Support Denial-Of-Service (DoS) Tracking . . . . . . . . . 50
   3.3.2   Traffic Monitoring . . . . . . . . . . . . . . . . . . . . 51
   3.3.3   Traffic Sampling . . . . . . . . . . . . . . . . . . . . . 52
   4.      Advanced Requirements  . . . . . . . . . . . . . . . . . . 54
   4.1     IP Stack Requirements  . . . . . . . . . . . . . . . . . . 54
   4.1.1   Ability To Stealth Device  . . . . . . . . . . . . . . . . 54
   5.      Security Considerations  . . . . . . . . . . . . . . . . . 56
           References . . . . . . . . . . . . . . . . . . . . . . . . 57
           Author's Address . . . . . . . . . . . . . . . . . . . . . 59
   A.      Requirement Profiles . . . . . . . . . . . . . . . . . . . 60
   A.1     Minimum Requirements Profile . . . . . . . . . . . . . . . 60
   A.2     Layer 3 Network Core Profile . . . . . . . . . . . . . . . 61
   A.3     Layer 3 Network Edge Profile . . . . . . . . . . . . . . . 61
   A.4     Layer 2 Network Core Profile . . . . . . . . . . . . . . . 62
   A.5     Layer 2 Edge Profile . . . . . . . . . . . . . . . . . . . 62
   B.      Acknowledgments  . . . . . . . . . . . . . . . . . . . . . 63
           Intellectual Property and Copyright Statements . . . . . . 64










Jones, Editor           Expires December 8, 2003                [Page 4]

Internet-Draft       Network Security Requirements             June 2003


1. Introduction

1.1 Goals

   The goal of this document is to define a list of security
   requirements for devices that implement Internet Protocol (IP).  The
   intent of the list is to provide consumers of IP devices a clear,
   concise way of communicating their security requirements to equipment
   vendors.

1.2 Scope

   These requirements apply to devices that make up the network core
   infrastructure (such as routers and switches) as well other devices
   that implement IP (e.g., cable modems, personal firewalls,hosts).

   While, the examples given are written with IPv4 in mind, most of the
   requirements are general enough to apply to IPv6.

1.3 Context

   Devices are expected to conform to protocol specifications as defined
   by the Internet Engineering Task Force (IETF) Request for Comment
   (RFC) series for all protocols which they implement unless otherwise
   noted.

1.4 Intended Audience

   There are two intended audiences: the end user (consumer) who
   selects, purchases, and operates IP network equipment, and the
   vendors who create them.

1.5 Format

   The individual requirements are listed in one of three sections
   below.

   o  Section 2 lists requirements that are based on approved standards
      and/or codify existing best practices.  Requirements in this
      category are mature.

   o  Section 3 lists requirements for security features or practices
      that are desirable, but for which there are not yet approved
      standards or widely accepted best practices. Requirements in this
      category are generally the subject of active work.
      Work-in-progress documents such as vendor documents, Internet
      drafts or documents describing a practice may be cited as
      examples.



Jones, Editor           Expires December 8, 2003                [Page 5]

Internet-Draft       Network Security Requirements             June 2003


   o  Section 4 lists requirements for security features or practices
      that are desirable that have not been standardized and that may
      present significant challenges in terms of implementation,
      support, cost, or other issues.

   Within these areas, requirements are grouped in major functional
   areas (e.g., logging, authentication, filtering, etc.

   Each requirement has the following subsections:

   o  The Requirement (What)

   o  The Justification (Why)

   o  Examples (How)

   o  Warnings (if applicable)

   The requirement describes a policy to be supported by the device. The
   justification tells why and in what context the requirement is
   important. The examples section is intended to give examples of
   implementations that may meet the requirement.  Examples cite
   technology and standards current at the time of this writing.  It is
   expected that the choice of implementations to meet the requirements
   will change over time. The warnings list operational concerns,
   deviation from standards, caveats, etc.

   Security requirements will vary across different device types and
   different organizations, depending on policy and other factors. A
   desired feature in one environment may be a requirement in another.
   Classifications must be made according to local need.

   In order to assist in classification, the Appendix Appendix A defines
   several requirement "profiles" for different types of devices.
   Profiles are simply collections of requirements.  They provide a
   concise list of the requirements that apply to certain classes of
   devices.  The profiles in this document are suggestions only and
   should be reviewed to determine if they are appropriate the local
   environment.

1.6 Intended Use

   It is anticipated that this document will be used in the following
   manners:

   Security Capability Checklist The requirements in this document may
      be used as a checklist when evaluating networked products.




Jones, Editor           Expires December 8, 2003                [Page 6]

Internet-Draft       Network Security Requirements             June 2003


   Composing Profiles Different subsets of these requirements may be
      compiled to describe the needs of different devices,
      organizations, and operating environments.

   Communicating Requirements This document may be referenced, along
      with profiles, to clearly communicate security requirements.

   Basis For Testing and Certification This document may form the basis
      for testing and certification of security features of networked
      products.


1.7 Definitions

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

   Unless otherwise indicated, "IP" refers to IPv4
































Jones, Editor           Expires December 8, 2003                [Page 7]

Internet-Draft       Network Security Requirements             June 2003


2. Best Current Practice

   This section is intended to list security features that comprise best
   practice at the time of writing.   They are known to be implemented
   and useful for improving security.

2.1 Device Management Requirements

2.1.1 Support Out-of-Band Management (OoB) Interfaces

   Requirement. The device MUST provide an OoB interface for management
      access.

   Justification. This is important because it allows all management of
      the device to be done via separate control channels and reduces
      the risk that unauthorized individuals will observe management
      traffic and/or compromise the device.

      It applies in situations where a separate OoB management network
      exists or other OoB access mechanisms (e.g., modems) are used to
      provide secure remote management.

   Examples. This requirement MAY be satisfied with a serial console
      port or a separate network interface, such as an Ethernet port.

   Warnings. OoB management may not be required or feasible in all
      situations: for instance; if remote management is not a
      requirement.


2.1.2 Enforce Separation of Data and Control Channels

   Requirement. The device MUST support separation of data and control
      channels. It MUST support complete physical and logical separation
      of management and non-management traffic.

   Justification. Separation of control and data channels enables the
      application of separate and appropriate controls to each channel,
      and reduces the possibility that a vulnerability in one area/
      environment (data forwarding) could have an adverse impact on
      another area (control/management). For example, imagine that a
      "killer packet" or buffer overrun is discovered that allows
      arbitrary users of a public network to crash the data forwarding
      elements of a router.  If data forwarding and control elements are
      separated, it is likely that the control elements will continue to
      function, allowing the network operator to evaluate and respond to
      the problem.  If they are not separated (e.g., they both use the
      same interfaces and share an operating system and IP stack), then



Jones, Editor           Expires December 8, 2003                [Page 8]

Internet-Draft       Network Security Requirements             June 2003


      it is likely that the entire device will crash or become
      unmanageable.

   Examples. This requirement may be satisfied by supporting OoB
      management interfaces per Section 2.1.1 and supporting the ability
      to disable all protocols that support management functions (e.g.,
      telnet, FTP, TFTP, SSH, SNMP, HTTP, etc.) on all non-management
      ports.

      See [I-D.ietf-forces-requirements] for related requirements.

   Warnings. None.


2.1.3 Separation Not Achieved by Filtering

   Requirement. The requirements to enforce separation of of data and
      control channels  SHALL NOT be satisfied using a filtering
      mechanism alone.

   Justification. Filters do not guarantee internal separation of
      traffic.

   Examples. None.

   Warnings. None.


2.1.4 No Forwarding Between Management and Data Planes

   Requirement. It MUST NOT be possible to forward data between data
      plane and management plane.

   Justification. This is to ensure that it is impossible to route
      packets to the management interface through the publicly
      accessible ports on the device.

   Examples. One way of meeting this requirement would be to have
      completely separate IP stacks and forwarding tables for management
      and non-management interfaces and to prohibit propagation of
      routing information between the two forwarding tables.

   Warnings. None.


2.1.5 Device Remains Manageable at All Times





Jones, Editor           Expires December 8, 2003                [Page 9]

Internet-Draft       Network Security Requirements             June 2003


   Requirement. The device MUST remain manageable at all times, even in
      the presence of attacks directed to or through the device.

   Justification. This requirement is particularly important for
      management ports. If a malicious user is able to effectively
      disable the management port, then it may be impossible for
      authorized users to access the device to respond to incidents and
      maintain normal operation.

   Examples. Assume that an attacker is able to flood the management
      port, launch a large number of well known attacks (See Section
      2.3.8) directly against the management port, or to use a group of
      compromised hosts to saturate all links connected to the device.
      It is precisely under these conditions that it is critical to
      preserve ability to connect to the device to perform management
      functions.  The issuance of such management commands may be the
      primary tool for mitigating the effects of the attacks. Also see
      Section 2.5.

   Warnings. There is a never-ending arms race between the discovery/
      exploitation of new vulnerabilities and the full deployment of
      code and configurations necessary to remove the vulnerabilities.
      This requirement is therefore something of an ideal.  It will
      require constant attention on the part of both vendors and
      operators to achieve the best approximation of meeting the
      requirement at any given time.   Also see the warning on Section
      2.3.9


2.1.6 Support Remote Configuration Backup

   Requirement. The device MUST provide a means to store and retrieve
      the system configuration to/from a remote server.  The stored
      configuration must have sufficient information to restore the
      device to its operational state at the time the configuration is
      saved.

   Justification. Archived configurations are essential to enable
      auditing and recovery.

   Examples. Possible implementations include SCP or FTP over a secure
      channel. See Section 3.1.1 for requirements related to secure
      communication channels for management protocols and data.

   Warnings. The security of the remote server is assumed, with
      appropriate measures being outside the scope of this document.





Jones, Editor           Expires December 8, 2003               [Page 10]

Internet-Draft       Network Security Requirements             June 2003


2.1.7 Support Management Over Slow Links

   Requirement. The device MUST provide a management interface that
      enables management over low bandwidth links (e.g., modem or serial
      port)

   Justification. This is important because it is often necessary to
      manage remote devices for which high bandwidth access is not
      available.

   Examples. A consistent command line interface is one possible
      implementation of this requirement.  An open, well-defined,
      scriptable management protocol is another.

   Warnings. None.


2.2 User Interface Requirements

2.2.1 Support Human-Readable Configuration File

   Requirement. The device MUST provide a means to remotely save a copy
      of the system configuration file(s) in a human-readable form.  It
      MUST NOT be necessary to use a proprietary program to view the
      configuration. The configuration MUST also be viewable in human
      readable form on the device itself.

   Justification. Having configurations in human-readable format is
      necessary to enable off-line audits of the system configuration.
      Having them in simple, non-proprietary formats also facilitates
      automation of configuration checking.

   Examples. A simple text-based configuration file would satisfy this
      requirement.

   Warnings. Offline copies of configurations should be well protected
      as they often contain sensitive information such as SNMP community
      strings, passwords, network blocks, customer information, etc.


2.2.2 Display of 'Sanitized' Configuration

   Requirement. The device MUST support the display of a "sanitized"
      configuration in which all sensitive information that appears in
      the system configuration must be replaced with innocuous data.






Jones, Editor           Expires December 8, 2003               [Page 11]

Internet-Draft       Network Security Requirements             June 2003


   Justification. This is necessary to allow safe distribution and
      analysis of configurations.

   Examples. Some examples of "sensitive information" include:

      *  system passwords

      *  usernames and passwords

      *  shared secrets (RADIUS, TACACS, IKE, VPN, SNMP, NTP, routing
         protocols, etc.)

      *  Private keys

      *  All IP addresses and blocks.

      *  System names

      *  Domain names

      *  Comments

      *  Banners

      *  User defined data (filter names, SNMP profile names, etc.)

      *  Contact information (snmp server, contact, location info, etc.)

      One simple way of obscuring the information would be to replace it
      with "***"s or similar characters in the display of the device
      configuration.

   Warnings. Some information may be "sensitive" in some situations, but
      not in others.  Passwords are clearly sensitive.  Other
      information in configurations that may be considered sensitive
      could include: IP addresses on particular interfaces (one way of
      obscuring these might be to replace the first octet with "10." in
      all cases), the name of the device, comments, banners, addresses
      of peers/upstream devices, addresses of logging devices, AAA
      servers, NTP servers, etc.


2.3 IP Stack Requirements

2.3.1 Comply With Relevant IETF RFCs on All Protocols Implemented






Jones, Editor           Expires December 8, 2003               [Page 12]

Internet-Draft       Network Security Requirements             June 2003


   Requirement. The device MUST fully comply with IETF RFCs for all
      protocols implemented.

   Justification. This is important because it ensures interoperability
      of products from multiple vendors.

   Examples. Some of the relevant RFCs include:

      ICMP.

         [RFC0792] INTERNET CONTROL MESSAGE PROTOCOL

         [RFC1812] Requirements for IP Version 4 Routers

      IP.

         [RFC0791] INTERNET PROTOCOL

         [RFC0922] BROADCASTING INTERNET DATAGRAMS IN THE PRESENCE OF
         SUBNETS

         [RFC1812] Requirements for IP Version 4 Routers

         [RFC1858] Security Considerations for IP Fragment Filtering

         [RFC2644] Changing the Default for Directed Broadcasts in
         Routers

         [RFC2827] Network Ingress Filtering

      TCP.

         [RFC0793] TRANSMISSION CONTROL PROTOCOL

         [RFC1858] Security Considerations for IP Fragment Filtering

         [RFC1948] Defending Against Sequence Number Attacks

      UDP.

         [RFC0768] User Datagram Protocol

         [RFC1122] Requirements for Internet Hosts -- Communication
         Layers

         [RFC1812] Requirements for IP Version 4 Routers





Jones, Editor           Expires December 8, 2003               [Page 13]

Internet-Draft       Network Security Requirements             June 2003


   Warnings. None.


2.3.2 Provide a List of All Protocols Implemented

   Requirement. The vendor SHOULD provide a concise list all protocols
      implemented by the device.

   Justification. This facilitates thorough and appropriately targeted
      testing.

   Examples. None.

   Warnings. None.


2.3.3 Provide Documentation for All Protocols Implemented

   Requirement. The vendor SHOULD provide  references to publicly
      available specifications for all protocols implemented.

   Justification. Security thorough obscurity is bad policy. Closed,
      undocumented protocols that have not undergone through public
      review may contain undiscovered (by the vendor) vulnerabilities
      that can easily be exploited.  Open, documented protocols
      facilitate thorough and appropriately targeted testing.

   Examples. None.

   Warnings. It is acknowledged that there may be valid business or
      other non-technical reasons for not releasing documentation for
      protocols, This requirement should be evaluated on a case-by-case
      basis.


2.3.4 Ability to Identify All Listening Services

   Requirement. The vendor MUST:

      *  Provide a means to display all services that are listening for
         network traffic directed at the device from any external
         source. The mechanism should also display the interfaces on
         which each service is listening.

      *  Provide a documented explanation for all network services that
         may be active on the system.

      *  Concisely document which features enable listening ports on the



Jones, Editor           Expires December 8, 2003               [Page 14]

Internet-Draft       Network Security Requirements             June 2003


         device.

      *  List which services are on by default.

      This information MUST be provided in a single, contiguous section
      of the documentation.  This list MUST include both open standard
      and vendor proprietary services.

   Justification. This information is necessary to enable a thorough
      assessment of the security risks associated with the operation of
      the device (e.g., "does this protocol allow complete management of
      the device without also requiring authentication, authorization,
      or accounting"?).  The information also assists in determining
      what steps should be taken to mitigate risk (e.g., "should I turn
      this service off "?)

   Examples. This documentation SHOULD include at least a list of all
      possible network services that could be activated to listen on any
      TCP and/or UDP port, or any vendor-proprietary port/protocol.

   Warnings. None.


2.3.5 Ability to Disable Any and All Services

   Requirement. The device MUST provide a means to turn off any external
      services.

   Justification. The ability to disable services for which there is no
      operational need will allow administrators to reduce the overall
      risk posed to the device.

   Examples. It SHOULD be possible to enable/disable each service
      independently if it is not needed.

   Warnings. None.


2.3.6 Ability to Control Service Bindings for Listening Services

   Requirement. The device MUST provide a means for the user to specify
      the bindings used for all listening services.  It MUST support
      binding to a list of addresses and netblocks and SHOULD support
      configuration of binding services to particular interfaces,
      including loopback addresses.






Jones, Editor           Expires December 8, 2003               [Page 15]

Internet-Draft       Network Security Requirements             June 2003


   Justification. This greatly reduces the need for complex filters.  It
      reduces the number of ports listening, and thus the number of
      potential avenues of attack.  It ensures that only traffic
      arriving from legitimate addresses and/or on designated interfaces
      can access services on the device.

   Examples. The default configuration as displayed by Section 3.2.1
      should list all interfaces and all potential services along with
      the ports they listen to, the addresses they listen to, and the
      interfaces they bind to.  These should all be made configurable.

   Warnings. None.


2.3.7 Ability to Control Service Source Address

   Requirement. The device MUST provide a means that allows the user to
      specify the source address used for all outbound connections or
      transmissions originating from the device.  It MUST be possible to
      specify source addresses independently for each type of outbound
      connection or transmission.  Source addresses MUST be limited to
      addresses that are assigned to interfaces (including loopbacks)
      local to the device.

   Justification. This allows remote devices receiving connections or
      transmissions to use source filtering as one means of
      authentication.  For example, if SNMP traps were configured to use
      a known loopback address as their source, the SNMP workstation
      receiving the traps (or a firewall in front of it) could be
      configured to receive SNMP packets only from that address.

   Examples. None.

   Warnings. None.


2.3.8 Ability to Withstand Well-Known Attacks and Exploits

   Requirement. The device MUST have an IP stack and operating system
      that is robust enough to withstand well-known attacks and
      exploits. For the purpose of this document, well-known attacks and
      exploits are defined as those that have been published by the
      following:

      *  Computer Emergency Response Team Coordination Center [CERT/CC]
         Advisories

      *  Common Vulnerabilities and Exposures [CVE] entries



Jones, Editor           Expires December 8, 2003               [Page 16]

Internet-Draft       Network Security Requirements             June 2003


      *  Bugtraq [Bugtraq] postings

      *  Standard Nessus [Nessus] Plugins

      *  Vendor security bulletins for the device in question.

   Justification. Product vulnerabilities and tools to exploit
      vulnerabilities are all constantly evolving.  A configuration that
      is secure one day may be insecure the next due to the discovery of
      a new vulnerability or the release of a new exploit script.
      Devices that are vulnerable to known exploits may be easily
      compromised or disabled.  This can affect confidentiality,
      availability, and data integrity.

   Examples. Take for example the SNMP vulnerabilities described in
      [CERT.2002-03].  These vulnerabilities were discovered and a
      toolkit for exploiting them was publicly released.  What this
      requirement is saying is that known vulnerabilities such as this
      should be fixed.

      It is up to the customer/operator to verify to their satisfaction
      that the system is "bug free" and free of known exploits.  Some
      possible methods of doing this include

      *  Taking the vendors word

      *  Testing for themselves

      *  Relying on 3rd party testing/certification

   Warnings. It is acknowledged that the number of known vulnerabilities
      is constantly expanding and that it is not possible to prove that
      any system is completely bug and vulnerability free (with
      apologies to any computer science researchers who may think
      otherwise).  Any test or "certification" of a device to show
      compliance with this requirement will be an approximation at a
      point in time.  The most that can be shown is that a given list of
      exploits failed.


2.3.9 Maintain Primary Function at All Times

   Requirement. The device MUST maintain its primary function at all
      times, even in the presence of attacks directed to or through the
      device.






Jones, Editor           Expires December 8, 2003               [Page 17]

Internet-Draft       Network Security Requirements             June 2003


   Justification. One of the primary goals of security is to preserve
      availability of resources (such as routers, switches or hosts) for
      authorized use.  That is the goal of this requirement.

   Examples. Assume that several attacks (See Section 2.3.8 were
      directed at the management port or that a flood attack was
      directed through the device.  In both these cases, the device
      should continue to perform its routing/switching functions.  Also
      see Section 2.5.

   Warnings. There is a never ending arms race between those who would
      discover and exploit vulnerabilities and those who would defend
      against them.  New vulnerabilities are discovered continually, and
      there is a window of opportunity for harm between the time of
      discovery  and the time that the patch or configuration changes is
      applied. The vendor must be made aware of the problem, analyze it,
      implement fixes, and make updated code/images available. The
      operator must acquire and install the patched code and/or perform
      the necessary configuration to defend against the new
      vulnerability.  In this context, this requirement is admittedly an
      idealized goal.


2.3.10 Support Automatic Anti-spoofing for Single-Homed Networks

   Requirement. The device MUST provide a means to designate particular
      interfaces as servicing single-homed networks and MUST provide an
      option to automatically apply anti-spoofing to such interfaces.
      This option MUST work in the presence of dynamic routing and
      dynamically assigned addresses.  It MUST NOT negatively impact
      performance.  It MUST provide accurate counts of spoofed packets
      that were dropped with logging options. It SHOULD be possible to
      apply the option to an interface with a single command.  For the
      purposes of this requirement a "single-homed network" is defined
      as one for which

      *  There is only one (logical) upstream connection

      *  Routing is symmetric

      A "spoofed packet" is defined as a "packet having a source address
      that, by application of the current forwarding tables, would not
      have its return traffic routed back through the interface on which
      it was received."

   Justification. See [RFC2867] Network Ingress Filtering.





Jones, Editor           Expires December 8, 2003               [Page 18]

Internet-Draft       Network Security Requirements             June 2003


   Examples. This requirement could be satisfied in several ways.  It
      could be satisfied by the provision of a single command that
      automatically generates and applies filters to an interface that
      implements anti-spoofing.   It could be satisfied by the provision
      of a command that causes the return path for packets received to
      be checked against the current routing tables and dropped if they
      would not be forwarded back through the interface on which they
      were received.

   Warnings. None.


2.3.11 Ability to Disable Processing of Packets Utilizing IP Options

   Requirement. The device MUST provide a means to disable processing of
      all packets utilizing IP Options.  This option MUST be available
      on a per-interface basis.  It MUST be possible to individually
      configure which options are processed.  Source routing SHOULD be
      disabled by default.

   Justification. Options can be used to alter normal traffic flows and
      thus circumvent network-based access control mechanisms (such as
      firewalls).  They can also be used to provide information (such as
      routes taken) that could be useful to an attacker mapping a
      network.

   Examples. None.

   Warnings. RFC791 says "The Options provide for control functions
      needed or useful in some situations but unnecessary for the most
      common communications...  [options] must be implemented by all IP
      modules (host and gateways).  What is optional is their
      transmission in any particular datagram, not their implementation"


2.3.12 Ability to Disable Directed Broadcasts

   Requirement. The device MUST provide a configuration mechanism so
      that:

      *  It will not respond to any directed broadcasts to any broadcast
         domains of which it is a member.

      *  It will not propagate any directed broadcasts to any broadcast
         domains to which it is directly connected.






Jones, Editor           Expires December 8, 2003               [Page 19]

Internet-Draft       Network Security Requirements             June 2003


      These SHOULD be the default settings.

   Justification. Directed broadcasts have few legitimate uses in modern
      networks and are easily abused to amplify denial of service
      attacks (e.g., SMURF attacks). [RFC2664] recommends the same
      change in default settings as a Best Current Practice.

   Examples. None.

   Warnings. None.


2.3.13 Identify Origin of IP Stack

   Requirement. The vendor MUST disclose the origin or basis of the IP
      stack used on the system.

   Justification. This information is required to better understand the
      possible security vulnerabilities that may be inherent in the IP
      stack.

   Examples. For example, "The IP stack was derived from BSD 4.4," or
      "The IP stack was implemented from scratch."

   Warnings. Many IP stacks make simplifying assumptions about how an IP
      packet should be formed. A malformed packet can cause unexpected
      behavior in the device, such as a system crash or buffer overflow
      which could result in  unauthorized access to the system.


2.3.14 Identify Origin of Operating System

   Requirement. The vendor MUST disclose the origin or basis of the
      operating system (OS).

   Justification. This information is required to better understand the
      security vulnerabilities that may be inherent to the OS based on
      its origin.

   Examples. For example, "The operating system is based on Linux kernel
      2.4.18."

   Warnings. None.


2.4 Rate Limiting Requirements





Jones, Editor           Expires December 8, 2003               [Page 20]

Internet-Draft       Network Security Requirements             June 2003


2.4.1 Support Rate Limiting

   Requirement. The device MUST provide the capability to limit the rate
      at which it will pass traffic based on protocol, port, and
      interface: and to rate-limit input and/or output separately on
      each interface.  It SHOULD allow filtering on any protocol and
      MUST allow filtering on at least IP, ICMP, UDP, and TCP. This
      feature SHOULD be implemented with minimal impact to system
      performance.

   Justification. This requirement provides a means of reducing or
      eliminating the impact of certain types of attacks.

   Examples. Assume that a web hosting company provides space in its
      data-center to a company that becomes unpopular with a certain
      element of network users, who then decide to flood the web server
      with inbound ICMP traffic. It would be useful in such a situation
      to be able to rate-filter inbound ICMP traffic at the
      data-center's border routers.   On the other side, assume that a
      new worm is released that infects vulnerable database servers such
      that they then start spewing traffic on TCP port 1433 aimed at
      random destination addresses as fast as the system and network
      interface of the infected  server is capable. Further assume that
      a data center has many vulnerable servers that are infected and
      simultaneously sending large amounts of traffic with the result
      that all outbound links are saturated. Implementation of this
      requirement, would allow the network operator to rate limit
      inbound and/or outbound TCP 1433 traffic (possibly to a rate of 0
      packets/bytes per second) to respond to the attack and maintain
      service levels for other legitimate customers/traffic.

   Warnings. None.


2.4.2 Support Rate Limiting Based on State

   Requirement. For stateful protocols it SHOULD be possible to rate
      limit traffic based on session state.

   Justification. This allows appropriate response to certain classes of
      attack.

   Examples. For example, for TCP sessions, it should be possible to
      rate limit based on the SYN, SYN-ACK, RST, or other bit state.

   Warnings. None.





Jones, Editor           Expires December 8, 2003               [Page 21]

Internet-Draft       Network Security Requirements             June 2003


2.5 Ability to Filter Traffic

   Requirement. The device MUST provide a means to filter IP packets on
      any interface implementing IP.

      In this document a "filter" is defined as a group of one or more
      rules where each rule specifies one or more match criteria as
      specified in Section 2.6.

      Also see the specific filtering requirements that follow this one.

   Justification. Packet filtering is important because it provides a
      basic means of implementing policies that specify which traffic is
      allowed and which is not.  It also provides a basic tool for
      responding to malicious traffic.

   Examples. Access control lists that allow filtering based on protocol
      and/or source/destination address and or source/destination port
      would be one example.

   Warnings. None.


2.6 Packet Filtering Criteria

2.6.1 Ability to Filter on Protocols

   Requirement. The device MUST provide a means to filter traffic based
      on protocol.

   Justification. Being able to filter on protocol is necessary to allow
      implementation of policy, secure operations and for support of
      incident response.

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

   Warnings. None.


2.6.2 Ability to Filter on Addresses

   Requirement. The function MUST be 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.




Jones, Editor           Expires December 8, 2003               [Page 22]

Internet-Draft       Network Security Requirements             June 2003


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

   Examples. One example of the use of address based filtering is to
      implement ingress filtering per [RFC2827].

   Warnings. None.


2.6.3 Ability to Filter on Any Protocol Header Fields

   Requirement. The filtering mechanism MUST support filtering based on
      the value(s) of any portion of the protocol headers.

   Justification. Being able to filter on portions of the header is
      necessary to allow implementation of policy, secure operations,
      and support incident response.

   Examples. For example, this requirement 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).   Another common example is the ability to control what
      services are allowed in/out of a network.  For example, it may be
      desirable to only allow inbound connections on port 80 (HTTP) and
      443 (HTTPS) to a network hosting web servers.

   Warnings. None.


2.6.4 Ability to Filter Inbound and Outbound

   Requirement. It MUST be possible to filter both incoming and outgoing
      traffic on any interface.

   Justification. This requirement 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.

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




Jones, Editor           Expires December 8, 2003               [Page 23]

Internet-Draft       Network Security Requirements             June 2003


   Warnings. None.


2.6.5 Ability to Filter on Layer 2 MAC Addresses

   Requirement. Filters in layer 2 devices MUST be able to filter based
      on Media Access Control (MAC) addresses.

   Justification. This provides a level of control that may be needed to
      enforce policy and respond to malicious activity.

   Examples. Policy may require, for example, that personal systems not
      be allowed to connect to the internal desktop network. Restricting
      the MAC addresses on a port is one way of enforcing this.

   Warnings. None.


2.7 Packet Filtering Application Targets

2.7.1 Ability to Filter Traffic Through the Device

   Requirement. It MUST be possible to apply the filtering mechanism to
      traffic that is being routed (switched) through the device.

   Justification. This is important because it permits implementation of
      basic policies on devices that carry transit traffic (routers,
      switches, firewalls, etc.).

   Examples. Ingress filtering as described in [RFC2827] is one example
      of filtering traffic intended to pass through the device.

   Warnings. None.


2.7.2 Ability to Filter Traffic to the Device

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

   Justification. This is important because it allows filters to be
      applied that protect the device itself from attacks and
      unauthorized access.

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



Jones, Editor           Expires December 8, 2003               [Page 24]

Internet-Draft       Network Security Requirements             June 2003


      addressed to the device.

   Warnings. None.


2.7.3 Ability to Filter Updates

   Requirement. The device MUST provide a means to filter updates for
      all protocols that could be used to update operational
      characteristics of the device. Note that it MUST be possible to
      specify a filter that disables all updates.

      This requirement MAY be satisfied through the use of filters as
      described in Section 2.5 and/or with mechanisms specific to each
      protocol.  Also note that update filtering is required in addition
      to secure channels (Section 3.1.1) and authentication (Section
      2.12)

   Justification. Without the ability to filter protocols used for
      management and operational updates, unauthorized users might be
      able to change operational parameters (e.g., routing tables,
      passwords, etc.) and/or completely disable the device.

   Examples. This should include the ability to:

      *  Filter routing protocol updates

      *  Disable SNMP writing completely

      *  Filter addresses permitted to manage the device regardless of
         protocol (SNMP,SSH,TELNET,HTTP,TFTP,SNMP...)

   Warnings. None.


2.8 Packet Filtering Actions

2.8.1 Ability to Specify Filter Actions

   Requirement. The device MUST provide a mechanism to allow the
      specification of the action to be taken when a filter rule
      matches.   Actions must include "permit" (allow the traffic),
      "reject" (drop with appropriate notification to sender), and
      "drop" (drop with no notification to sender). Also see Section
      2.10.1 and Section 2.9






Jones, Editor           Expires December 8, 2003               [Page 25]

Internet-Draft       Network Security Requirements             June 2003


   Justification. This capability is essential to the use of filters to
      enforce policy.

   Examples. Assume that you have a small DMZ network connected to the
      Internet. You want to allow management using SSH coming from your
      corporate office.  In this case, you might "permit" all traffic to
      port 22 in the DMZ from your corporate network, "rejecting" all
      others. Port 22 traffic from the corporate network is allowed
      through. Port 22 traffic from all other addresses results in an
      ICMP message to the sender.  For those who are slightly more
      paranoid, you might choose to "drop" instead of "reject" traffic
      from unauthorized addresses, with the result being that *nothing*
      is sent back to the source.

   Warnings. [Ed. Does "drop" with no ICMP unreachable violate any RFCs
      ?]


2.9 Packet Filtering Counter Requirements

2.9.1 Ability to Accurately Count Filter Hits

   Requirement. The device MUST supply a facility for accurately
      counting all filter hits.

   Justification. Accurate counting of filter rule matches is important
      because it shows the magnitude/frequency of attempts to violate
      policy. This enables resources to be focused on areas of greatest
      need.

   Examples. 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 IPS's Acceptable Use Policy), or that system(s)
      on the customers network have been "owned" by hackers and are
      being (mis)used to launch attacks.

   Warnings. None.


2.9.2 Ability to Display Filter Counters

   Requirement. The device MUST provide a mechanism to display filter
      counters.




Jones, Editor           Expires December 8, 2003               [Page 26]

Internet-Draft       Network Security Requirements             June 2003


   Justification. Information that is collected is not useful unless it
      can be displayed in a useful manner.

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

   Warnings. None.


2.9.3 Ability to Display Filter Counters per Rule

   Requirement. The device MUST provide a mechanism to display filter
      counters per rule.

   Justification. This makes it possible to see which rules are matching
      and how frequently.

   Examples. Assume that a filter has been defined that has two rules,
      one permitting all SSH traffic (tcp/22) and the second dropping
      all remaining traffic.  If three packets are directed toward/
      through the point at which the filter is applied, one to port 22,
      the others to different ports, then the counter display should
      show 1 packet matching the permit tcp/22 rule and 2 packets
      matching the deny all others rule.

   Warnings. None.


2.9.4 Ability to Display Filter Counters per Filter Application

   Requirement. If it is possible for a filter to be applied more than
      once at the same time, then the device MUST provide a mechanism to
      display filter counters per filter application.

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





Jones, Editor           Expires December 8, 2003               [Page 27]

Internet-Draft       Network Security Requirements             June 2003


   Examples. One way to implement this requirement 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 ..."

   Warnings. None.


2.9.5 Ability to Reset Filter Counters

   Requirement. It MUST be possible to reset counters to zero on a per
      filter basis.

   Justification. This allows operators to get a current picture of the
      traffic matching particular rules/filters.

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

   Warnings. None.


2.9.6 Filter Counters Must Be Accurate

   Requirement. Filter counters MUST be accurate.   They MUST reflect
      the actual number of matching packets since the last counter
      reset.

   Justification. Inaccurate data can not be relied on as the basis for
      action. Underreported data can conceal the magnitude of a problem.

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

   Warnings. None.


2.10 Other Packet Filtering Requirements





Jones, Editor           Expires December 8, 2003               [Page 28]

Internet-Draft       Network Security Requirements             June 2003


2.10.1 Ability to Log Filter Actions

   Requirement.

      It MUST be possible to log all filter actions. The logging
      capability MUST be able to capture at least the following data:
      permit/deny/drop status, source and destination ports, source and
      destination IP address, which network element forwarded the packet
      (interface, MAC address or other layer 2 information that
      identifies the previous hop source of the packet), and time-stamp
      to millisecond accuracy.

      Logging of filter actions is subject to the requirements of
      Section 2.11.

   Justification. Logging is essential for auditing, incident response,
      and operations.

   Examples. A desktop network may not provide any services that should
      be accessible from "outside."  In such cases, all inbound
      connection attempts should be logged as possible intrusion
      attempts.

   Warnings. None.


2.10.2 Ability to Specify Filter Log Granularity

   Requirement. It MUST be possible to enable/disable logging on a per
      rule basis.

   Justification. The ability to tune the granularity of logging allows
      the operator to log only the information that is desired. Without
      this capability, it is possible that extra data (or none at all)
      wold be logged, making it more difficult to find relevant
      information.

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

   Warnings. None.


2.10.3 Ability to Filter Without Performance Degradation





Jones, Editor           Expires December 8, 2003               [Page 29]

Internet-Draft       Network Security Requirements             June 2003


   Requirement. The device MUST provide a means to filter packets
      without performance degradation. The device MUST be able to filter
      on ALL interfaces (up to the maximum number possible)
      simultaneously and with multiple filters per interface (e.g.,
      inbound and outbound).

   Justification. This is important because it enables the
      implementation of filtering wherever and whenever needed.  To the
      extent that filtering causes degradation, it may not be possible
      to apply filters that implement the appropriate policies.

   Examples. Another way of stating the requirement is that filter
      performance should not be the limiting factor in device
      throughput.  If a device is capable of forwarding, say, 30Mb/sec
      without filtering, then it should be able to forward the same
      amount with filtering in place. This requirement most likely
      implies a hardware-based solution (ASIC).

   Warnings. Without hardware based filtering, it may be possible for
      the implementation of filters to degrade the performance of the
      device or to cause it to cease functioning.


2.10.4 Filter, Counters, and Filter Log Performance Must Be Usable

   Requirement. Filtering, logging, and counting functionality MUST be
      implemented such that they are usable, from a performance
      standpoint, in situations where they are the logical solution.

   Justification. The possibility of severe performance degradation in
      the use of filtering, logging, or counting would reduce their
      utility. Fear of adverse operational consequences might cause
      operators to limit or discard their use completely in situations
      where they are needed.

   Examples.

      Assume, for example, that a new worm is released that scans random
      IP addresses looking for services listening on TCP port 1433.  An
      operator might want to investigate to see if any of the hosts on
      their networks were infected and trying to spread the worm.  One
      way to do this would be to put up non-blocking filters counting
      and logging the number of outbound connection 1433, and then to
      block the requests that are determined to be from infected hosts.
      If any of these capabilities (filtering, counting, logging) have
      the potential to impose severe performance penalties, then this
      otherwise rational course of action might not be possible.




Jones, Editor           Expires December 8, 2003               [Page 30]

Internet-Draft       Network Security Requirements             June 2003


      Some examples of things that would make the logging features
      unusable might include situations where their use:

      *  crashes the device

      *  consumes excessive resources (CPU, memory, bandwidth)

      *  makes the device unmanageable

      *  causes the loss of data

   Warnings.

      While there are some objective measures that indicate clearly when
      a feature is unusable (its use crashes the device), "usability" is
      largely a subjective term.  Lab tests may be constructed to
      determine how well the device behaves under certain loads, but the
      ultimate test of usability for filtering, counting and logging
      will come under live, quite possibly heavy, loads.


2.11 Event Logging Requirements

2.11.1 Ability to Log All Events That Affect System Integrity

   Requirement. The logging facility MUST be capable of logging any
      event that affects system integrity.

   Justification. Having the device log all events that might impact
      system integrity promotes accountability and enables
      audit-ability.

   Examples.

      The list of items that must be logged includes, but is not limited
      to, the following events:

      *  Filter matches, described in Section 2.10.1

      *  Authentication failures (e.g., bad login attempts)

      *  Authentication successes (e.g., user logins)

      *  Authorization changes (e.g., User privilege level changes)

      *  Configuration changes (e.g., command accounting)

      *  Device status changes (interface up/down, etc.)



Jones, Editor           Expires December 8, 2003               [Page 31]

Internet-Draft       Network Security Requirements             June 2003


   Warnings. None.


2.11.2 Logging Facility Conforms to Open Standards

   Requirement. The device MUST provide a logging facility that conforms
      to open standards. Custom/Proprietary log protocols MAY be
      implemented provided the same information is made available via
      logging facilities that conform to open standards.

   Justification. The use of open standards logging is important because
      it permits the customer to perform archival and analysis of logs
      without relying on vendor-supplied software and servers.

   Examples. [RFC3195] meets this requirement. The use of SNMP traps may
      also satisfy this requirement.

   Warnings. While [RFC3164] and SNMP may satisfy this requirement, they
      both fail to satisfy several other logging requirements.


2.11.3 Catalog of Log Messages Available

   Requirement. The vendor MUST specify a catalog of all messages that a
      device can emit.  This MUST be included with every release of
      software for the device.

   Justification. A complete catalog of all possible messages permits
      the customer to automate response to possible events.

   Examples. None.

   Warnings. None.


2.11.4 Ability to Log to Remote Server

   Requirement. The device MUST be capale of logging to a remote server.
      It SHOULD be able to log to multiple servers.

   Justification. External logging allows the storage of large,
      persistent logs that may not be possible with local (on the
      device) logging.

   Examples. One example of a remote log server would be a host running
      a syslog server.  See [RFC3164].





Jones, Editor           Expires December 8, 2003               [Page 32]

Internet-Draft       Network Security Requirements             June 2003


   Warnings. High volumes of logging may generate excessive network
      traffic and/or compete for scarce memory and CPU resources on the
      device.


2.11.5 Ability to Select Reliable Delivery

   Requirement. It MUST be possible to select reliable, sequenced
      delivery of log messages between device sending the message and
      server receiving the message.

   Justification. Reliable delivery is important to the extent that log
      data is depended upon to make operational decisions and forensic
      analysis.  Without reliable delivery, log data becomes a
      collection of hints.

   Examples. One example of reliable syslog delivery is defined in
      [RFC3195]. Syslog-ng provides another example, although the
      protocol has not been standardized.

   Warnings. None.


2.11.6 Ability to Configure Security of Log Messages

   Requirement. It MUST be possible to configure the logging mechanism
      such that there is independent control of the authenticity,
      integrity, confidentiality, and replay prevention of log messages.

   Justification. See section 5 of [RFC3195], and section 6 of
      [RFC3164].

   Examples. [RFC3195] defines one way of meeting these requirements.

   Warnings. None.


2.11.7 Ability to Log Locally

   Requirement.

      It SHOULD be possible to log locally on the device itself.

   Justification. Local logging is important for viewing information
      when connected to the device.  It provides some backup of log data
      in case remote logging fails.  It provides a way to view logs
      relevant to one device without having to sort through a possibly
      large set of logs from other devices.



Jones, Editor           Expires December 8, 2003               [Page 33]

Internet-Draft       Network Security Requirements             June 2003


   Examples. One example of local logging would be a memory buffer that
      receives copies of messages sent to the remote log server.
      Another example might be a local syslog server (assuming the
      device is capable of running syslog and has some local storage).

   Warnings. Storage on the device may be limited.  High volumes of
      logging may quickly fill available storage, in which case there
      are two options: new logs overwrite old logs (possibly via the use
      of a circular memory buffer or log file rotation), or logging
      stops.


2.11.8 Ability to Specify Logservers by Event Classification

   Requirement. The device MUST allow the remote log server to be
      specified by the event classification.  For example,
      security-related messages would go to one log server, while
      operational messages would go to another.

   Justification. This is important because it allows (in concert with
      requirement Section 2.11.9 ) messages of certain types to be sent
      to different servers for processing.  This is important in
      environments with large numbers of devices, large numbers of log
      messages, and/or where responsibilities for certain classes of
      messages are divided.

   Examples. This requirement MAY be satisfied by providing
      configuration commands that allow the user to assign syslog
      facilities to each message or class of messages.  For example, it
      should be possible to specify that all security-related events be
      assigned syslog facility local4 and that messages classified as
      local4 should be sent to syslog server 10.9.8.7.

   Warnings. None.


2.11.9 Ability to Classify Events

   Requirement. The device SHOULD provide a mechanism for assigning
      classifications to all messages.  At a minimum, it MUST provide
      the ability to assign a chosen classification to all security
      related messages, and different classification(s) to all other
      messages.

   Justification. This is important because it allows (in concert with
      requirement Section 2.11.8 ) messages of certain types to be sent
      to different servers for processing.  This is important in
      environments with large numbers of devices, large numbers of log



Jones, Editor           Expires December 8, 2003               [Page 34]

Internet-Draft       Network Security Requirements             June 2003


      messages, and/or where responsibilities for certain classes of
      messages are divided.

   Examples. This requirement MAY be satisfied by providing a mechanism
      to assign specific syslog facility codes to specific messages or
      groups of messages. For example, all security events could be
      assigned to one facility code, all network routing issues to
      another, and all physical (power, line card) to another.

   Warnings. None.


2.11.10 Ability to Maintain Accurate System Time

   Requirement. The device MUST maintain accurate, high resolution
      system time. All displays of system time MUST include a timezone.
      The default timezone SHOULD be UTC or GMT. The device SHOULD
      support a mechanism to allow the operator to specify the timezone
      for local system time.

   Justification. This is important because the system clock is used for
      time-stamping log messages.

   Examples. This requirement MAY be satisfied by supporting Network
      Time Protocol (NTP). See Section 3.1.1 for requirements related to
      secure communication channels for management protocols and data.

   Warnings. System clock chips are inaccurate to varying degrees.
      System time should not be relied upon unless it is regularly
      checked and synchronized with a known, accurate external time
      source (such as an NTP stratum-1 server).


2.11.11 Logs Must Be Timestamped

   Requirement. The device MUST time-stamp all log messages.  The
      time-stamp MUST be accurate to within a second or less.  The
      time-stamp MUST include a timezone.

   Justification. This is important because accurate timestamps are
      necessary for correlating events, particularly across multiple
      devices or with other organizations. This applies when it is
      necessary to analyze logs.

   Examples. This requirement MAY be satisfied by writing timestamps
      into syslog messages.





Jones, Editor           Expires December 8, 2003               [Page 35]

Internet-Draft       Network Security Requirements             June 2003


   Warnings. It is difficult to correlate logs from different time
      zones. Security events on the Internet often involve machines and
      logs from a variety of physical locations.  For that reason, UTC
      is preferred, all other things being equal.


2.11.12 Logs Contain Untranslated Addresses

   Requirement. Log messages MUST contain relevant IP addresses.

   Justification. It is important to include IP address of access list
      violation logs, authentication attempts.  This enables a level of
      individual and organizational accountability and is necessary to
      enable analysis of network events, incidents, policy violations,
      etc.

   Examples. None.

   Warnings.

      *  Source addresses may be spoofed.  Network-based attacks often
         use spoofed source addresses.  Source addresses should not be
         completely trusted unless verified by means.

      *  Addresses may be reassigned to different individual, for
         example, in a desktop environment using DHCP. In such cases the
         individual accountability afforded by this requirement is weak.

      *  Network topologies may change. Even in the absence of dynamic
         address assignment, network topologies and address block
         assignments do change. Logs of an attack one month ago may not
         give an accurate indication of which host, network or
         organization owned the system(s) in question at the time.


2.11.13 Logs Do Not Contain DNS Names by Default

   Requirement. By default, log messages MUST NOT contain DNS names
      resolved at the time the message was generated.  The device MAY
      provide a facility to incorporate translated DNS names in addition
      to the IP address.

   Justification. This is important because IP to DNS mappings change
      over time and mappings done at one point in time may not be valid
      later.  Also, the use of the resources (memory, processor, time,
      bandwidth) required to do the translation could result in *no*
      data being sent/logged, and, in the extreme case could lead to
      degraded performance and/or resource exhaustion.



Jones, Editor           Expires December 8, 2003               [Page 36]

Internet-Draft       Network Security Requirements             June 2003


   Examples. None.

   Warnings. DNS name translation can impose significant performance
      delays.


2.12 Authentication, Authorization, and Accounting (AAA) Requirements

2.12.1 Authenticate All User Access

   Requirement. The device MUST provide a facility to perform
      authentication of all user access to the system.

   Justification. This functionality is required so that access to the
      system can be restricted to authorized personnel.

   Examples. This requirement MAY be satisfied by implementing a
      centralized authentication system.  See Section 2.12.5. It MAY
      also be satisfied using local authentication. See Section 2.12.6

   Warnings. None.


2.12.2 Support Authentication of Individual Users

   Requirement. Each authentication mechanism supported by the device
      MUST support the authentication of distinct, individual users.

   Justification. The use of individual accounts, in conjunction with
      logging, promotes accountability.   The use of group or default
      accounts undermines individual accountability.

   Examples. The implementation depends on the types of authentication
      supported by the device.  Local usernames and passwords are one
      possibility. Centralized authentication servers using usernames
      and onetime passwords is another.

   Warnings. This simply requires that the mechanism to support
      individual users be present.  Policy (e.g., forbidding shared
      group accounts) and enforcement are also needed but beyond the
      scope of this document.


2.12.3 Support Simultaneous Connections

   Requirement. The device SHOULD support multiple simultaneous
      connections by distinct users, possibly at different authorization
      levels.



Jones, Editor           Expires December 8, 2003               [Page 37]

Internet-Draft       Network Security Requirements             June 2003


   Justification. This allows multiple people to perform authorized
      management functions simultaneously.

   Examples. None.

   Warnings. None.


2.12.4 Ability to Disable All Local Accounts

   Requirement. The device MUST provide a means of disabling all local
      accounts including:

      *  Local users

      *  Default accounts (vendor, maintenance, guest...)

      *  Privileged and unprivileged accounts

   Justification. Default accounts, well know accounts, and old accounts
      provide easy targets for someone attempting to gain access to a
      device. It must be possible to disable them to reduce the
      potential vulnerability.

   Examples. The implementation depends on the types of authentication
      supported by the device.

   Warnings. None.


2.12.5 Support Centralized User Authentication

   Requirement. The device MUST support centralized authentication of
      all user access via standard authentication protocols.

   Justification. Support for centralized authentication is particularly
      important in large environments where the network devices are
      widely distributed and where many people have access to them. This
      reduces the effort needed to effectively restrict and track access
      to the system by authorized personnel.

   Examples. This requirement MAY be satisfied by implementing Terminal
      Access Controller Access Control System Plus (TACACS+), Remote
      Authentication Dial-In User Service (RADIUS), or Kerberos 5. See
      Section 3.1.1 for requirements related to secure communication
      channels for management protocols and data.





Jones, Editor           Expires December 8, 2003               [Page 38]

Internet-Draft       Network Security Requirements             June 2003


   Warnings. None.


2.12.6 Support Local User Authentication

   Requirement. The device MAY support local authentication.

   Justification. Support for local authentication may be required in
      smaller environments where there may be only a few devices and a
      limited number of people with access.  The overhead of maintaining
      centralized authentication servers may not be justified.

   Examples. The use of local, per-device usernames and passwords
      provides one way to implement this requirement.

   Warnings. Authentication information must be protected wherever it
      resides.  Having, for instance, local usernames and passwords
      stored on 100 network devices means that there are 100 potential
      points of failure where the information could be compromised vs.
      storing authentication data centralized server(s), which would
      reduce the potential points of failure to the number of servers
      and allow protection efforts (system hardening, audits, etc.) to
      be focused on, at most, a few servers.


2.12.7 Support Configuration of Order of Authentication Methods

   Requirement. The device MUST support the ability to configure the
      order in which supported authentication methods are attempted.

   Justification. This allows the operator flexibility in implementing
      appropriate security policies that balance operational and
      security needs.

   Examples. If, for example, a device supports RADIUS authentication
      and local usernames and passwords, it should be possible to
      specify that RADIUS authentication should be attempted if the
      servers are available, and that local usernames and passwords
      should be used for authentication only if the RADIUS servers are
      not available. Similarly, it should be possible to specify that
      only RADIUS or only local authentication be used.

   Warnings. None.


2.12.8 Ability to Authenticate Without Reusable Plaintext Passwords





Jones, Editor           Expires December 8, 2003               [Page 39]

Internet-Draft       Network Security Requirements             June 2003


   Requirement. The device MUST perform authentication without the
      transmission of reusable plain-text passwords across a network.
      The implementation:

      *  MUST NOT cause significant performance degradation

      *  MUST NOT require additional devices (e.g., encryption cards,
         etc.)

      *  MUST scale well/be supportable on large numbers of devices
         (e.g., the number of keys and configuration settings that need
         to be managed should increase at most linearly as the number of
         devices).

      This requirement MAY be satisfied by tunneling protocols that use
      plain-text passwords over secure channels per Section 3.1.1.

   Justification. Reusable plain-text passwords can easily be observed
      using packet sniffers on shared networks. Mechanisms that impose
      too high of an overhead or are not manageable will not be used.
      This requirement specifically precludes the use of reusable
      passwords with standard telnet without being carried over a secure
      channel (see Section 3.1.1) for device management.  It does allow
      the use of standard telnet with one time passwords. Note that this
      does not preclude the use of extra hardware; it simply says that
      additional hardware (smart cards, encryption cards, etc.) must not
      be required to support authentication without the use of clear
      text passwords. See [RFC1704] for a through discussion of the
      issues.

   Examples. None.

   Warnings. None.


2.12.9 Support Device-to-Device Authentication

   Requirement. The device MUST support device-to-device authentication
      for all non-interactive management protocols.  Also see Section
      2.12.8 and Section 3.1.1

   Justification. This is required to allow automated management
      functions to operate with a reasonable level assurance that
      updates and sharing of management information is occurring only
      with authorized devices.






Jones, Editor           Expires December 8, 2003               [Page 40]

Internet-Draft       Network Security Requirements             June 2003


   Examples. Examples of protocols that implement device to device
      authentication are: SNMP (community strings), NTP and BGP (shared
      keys).

   Warnings. None.


2.12.10 Ability to Define Privilege Levels

   Requirement. It MUST be possible to define arbitrary subsets of all
      management and configuration functions and assign them to groups
      or "privilege levels," which can be assigned to users per Section
      2.12.11

   Justification. This requirement supports the implementation of the
      principal of "least privilege", which states that an individual
      should only have the privileges necessary to execute the
      operations he/she is required to perform.

   Examples. Examples of privilege levels might include "default," which
      allows read-only access to device configuration and operational
      statistics, "root/superuser/administrator" which allows update
      access to all configurable parameters, and "operator" which allows
      updates to a limited, user defined set of parameters. Note that
      privilege levels may be defined locally on the device or on
      centralized authentication servers.

   Warnings. None.


2.12.11 Ability to Assign Privilege Levels to Users

   Requirement. The device MUST be able to assign a defined set of
      authorized functions, or "privilege level," to each user once they
      are authenticated the device.  Privilege level determines which
      functions a user is allowed to execute.   Also see See Section
      2.12.10.

   Justification. This requirement supports the implementation of the
      principal of "least privilege," which states that an individual
      should only have the privileges necessary to execute the
      operations he/she is required to perform.

   Examples. The implementation of this requirement will obviously be
      closely coupled with the authentication mechanism.  So for
      example, if RADIUS is used, an attribute could be set in the
      user's RADIUS profile that can be used to map the ID to a certain
      privilege level.



Jones, Editor           Expires December 8, 2003               [Page 41]

Internet-Draft       Network Security Requirements             June 2003


   Warnings. None.


2.12.12 Default Privilege Level Must Be Read Only

   Requirement. The default privilege level MUST only allow read access
      to device settings and operational parameters.

   Justification. This requirement supports the implementation of the
      principal of "least privilege," which states that an individual
      should only have the privileges necessary to execute the
      operations he/she is required to perform.

   Examples. None.

   Warnings. None.


2.12.13 Change in Privilege Levels Requires Re-Authentication

   Requirement. The device MUST re-authenticate a user prior to granting
      any change in user authorizations.

   Justification. This requirement insures that users are able to
      perform only authorized actions.

   Examples. This requirement might be implemented by assigning base
      privilege levels to all users and allowing the user to request
      additional privileges, with the requests validated by the AAA
      server.

   Warnings. None.


2.12.14 Accounting Records

   Requirement. The device MUST be able to store a record of at least
      the following events:

      *  Failed logins

      *  Successful logins

      *  All Commands executed by the user during their session,
         including via the management/serial port and interactions with
         an underlying OS (e.g., Unix "shell" commands)

      *  Change in privilege level



Jones, Editor           Expires December 8, 2003               [Page 42]

Internet-Draft       Network Security Requirements             June 2003


      *  All logouts

      The device MUST support transmission of accounting records to one
      or more remote devices.  There MUST be configuration settings on
      the device that allow selection of servers.

   Justification. This is important because it supports individual
      accountability by providing a record of changes that were made and
      who made them. It is important to store them on a separate server
      to preserve them in case of failure or compromise of the managed
      device.

   Examples. This requirement MAY be satisfied by the use of
      RADIUS,TACACS+, or syslog. See Section 3.1.1 for requirements
      related to secure communication channels for management protocols
      and data.

   Warnings. Syslog is known to be unreliable/lossy during network
      transmission (due to use of UDP).  It has also been observed that
      some devices lose a significant number of UDP packets before they
      are ever transmitted, due (apparently) to low prioritization of
      the internal processing of UDP packets.  Similar problems have
      been observed in various syslog servers (syslogd on UNIX systems).
      Bottom line: be aware that syslog data may be lost at one of
      several points.


2.13 Layer 2 Requirements

2.13.1 Filtering MPLS LSRs

   Requirement. The device MUST provide a method to filter packets based
      on layer 3 and 4 criteria on Label Switch Routers (LSRs)
      regardless of whether they are encapsulated using Multi Protocol
      Label Switching (MPLS). The MPLS encapsulated packets MUST NOT be
      allowed to bypass IP filters. Logging facilities that MUST provide
      previous-hop information when information so the previous hop for
      a logged packet can be determined. Packets tagged with MPLS labels
      MUST be treated as IP packets when crossing an interface on which
      a filter is applied. Encapsulation/decapsulation MAY take place
      before or after the filter as long as it does not cause the
      filters to be ignored. When logging the input interface
      information for hits on outgoing filter list rules, any MPLS label
      that was present when the packet was received MUST be logged with
      the input interface. This functionality is equivalent to the
      requirement that all layer 2 source information must be logged
      when the input interface is logged. Also, the addition of any
      filtering and logging MUST be implemented with no significant



Jones, Editor           Expires December 8, 2003               [Page 43]

Internet-Draft       Network Security Requirements             June 2003


      performance degradation to the normal system operations.

   Justification. This is important because it may be necessary to
      filter traffic encapsulated in a LSP.  This applies primarily to
      backbone and large core networks.

   Examples. None.

   Warnings. None.


2.13.2 VLAN Isolation

   Requirement. The device MUST NOT allow VLAN Hopping. This applies to
      the insertion of falsified VLAN IDs or 802.1Q (or equivalent) tags
      into frames in an attempt to hop from one VLAN to another while
      traversing the switch. Many VLAN implementations allow hopping if
      the native VLAN (usually VLAN 1) is set up as the trunk port. If
      this is the case then the default configuration on the switch MUST
      NOT allow the trunk port to be set as the native VLAN. Also the
      switch MUST NOT broadcast ARP requests across VLANs.

   Justification. This requirement is intended to ensure that layer 2
      traffic remains isolated to designated VLANs.  It applies in
      situations where data on different VLAN segments have different
      sensitivity classification.

   Examples. None.

   Warnings. None.


2.13.3 Layer 2 Denial-of-Service

   Requirement. It MUST NOT be possible for users connected to a switch
      port to perform an action which results in denial of service to
      other users connected to the switch. Examples of denial of service
      would include:

      *  Causing the switch to crash

      *  Causing long delays (e.g., by forcing spanning tree
         recalculations)

      *  Redirecting/stealing traffic






Jones, Editor           Expires December 8, 2003               [Page 44]

Internet-Draft       Network Security Requirements             June 2003


   Justification. This requirement is needed to ensure the
      confidentiality and availability of data transmitted via the
      switch.

   Examples. None.

   Warnings. None.


2.13.4 Layer 3 Dependencies

   Requirement. If a device provides layer 2 services that are dependent
      on layer 3 or greater services, then the portions that operate at
      layer 3 MUST conform to the layer 3 security requirements listed
      in this document where appropriate.  For example, signaling
      protocols required for layer 2 switching may exchange information
      with other devices using layer 3 communications. The device must
      provide a secure layer 3 facility.

   Justification. All layer 3 devices have similar security needs and
      should be subject to similar requirements.

   Examples. None.

   Warnings. None.


2.14 Vendor Behavior

2.14.1 Vendor Responsiveness

   Requirement. The vendor MUST be responsive to current and future
      security requirements as specified by the customer. When new
      security exploits are discovered, either by the customer or the
      public, the vendor MUST provide patches or workarounds in a timely
      fashion to mitigate the threat from any existing vulnerability in
      the system. The vendor MUST ensure that it remains actively aware
      of security threats.

   Justification. This is important because new vulnerabilities are
      regularly discovered.  Slow vendor response to vulnerabilities
      increase the level of risk/window of opportunity for exploit. This
      requirement applies to ALL devices.

   Examples. This is a non-technical requirement. The implementation
      involves process, customer support, engineering, etc.





Jones, Editor           Expires December 8, 2003               [Page 45]

Internet-Draft       Network Security Requirements             June 2003


   Warnings. This "requirement" has a large element of subjectivity.
      When evaluating vendor responsiveness, objective data (such as
      mean time to releasing patches for new exploits) should be
      evaluated.















































Jones, Editor           Expires December 8, 2003               [Page 46]

Internet-Draft       Network Security Requirements             June 2003


3. Non-Standard Requirements

   This section is intended to list security features that may not be
   implemented at the time of this writing, would be useful for
   improving security, and are not thought to present significant
   challenges in terms of technology required, support costs,
   performance impact, etc.

3.1 Device Management Requirements

3.1.1 Support Secure Management Channels

   Requirement. The device MUST provide a secure end-to-end channel for
      all network traffic and protocols used to support management
      functions.  This MUST include at least protocols used for
      configuration, monitoring, configuration backup, logging, time
      synchronization, authentication, and routing. This requirement MAY
      be satisfied by using protocols that support secure channels
      directly or by layering insecure protocols over secure transport
      protocols.

   Justification. Secure channels ensure confidentiality and integrity
      of management traffic.

   Examples. Secure channels are most commonly implemented using
      encryption...one can imagine other secure channels, such as
      shielded cable run in tamper-evident conduit monitored by armed
      guards... but in most cases "secure channel" will mean encryption.
      See [ANSI.T1.276-200x] for a discussion of appropriate algorithms.

      The following table shows examples of the security requirements
      for different classes of protocols.  The rows list different
      classes of protocols.  The columns show the required security
      attributes.  The attributes are: Confidentiality (Conf.),
      Integrity (Integ.), User-to-Device Authentication (Auth. U2D), and
      Device-to-Device Authentication (Auth D2D).:

           +---------------+-------+-------+-------+-------+
           | Type          | Conf. | Integ.| Auth. | Auth. |
           |   Protocol(s) |       |       | U2D   | D2D   |
           +---------------+-------+-------+-------+-------+
           | Management    |   X   |   X   |  X    |       |
           |   telnet, HTTP|       |       |       |       |
           |   FTP,        |       |       |       |       |
           +---------------+-------+-------+-------+-------+
           | Management    |   X   |   X   |       |   X   |
           |   TFTP,SNMP   |       |       |       |       |
           +---------------+-------+-------+-------+-------+



Jones, Editor           Expires December 8, 2003               [Page 47]

Internet-Draft       Network Security Requirements             June 2003


           | Logging       |   X   |   X   |       |   X   |
           |   Syslog      |       |       |       |       |
           |               |       |       |       |       |
           +---------------+-------+-------+-------+-------+
           | Time          |       |       |       |       |
           |   NTP         |       |   X   |       |   X   |
           |               |       |       |       |       |
           +---------------+-------+-------+-------+-------+
           | AAA           |       |       |       |       |
           |   TACACS,     |       |       |       |       |
           |   RADIUS,     |   X   |   X   |   X   |   X   |
           |   DIAMETER,   |       |       |       |       |
           |   Kerberos,   |       |       |       |       |
           +---------------+-------+-------+-------+-------+
           | Routing       |       |       |       |       |
           |   BGP,OSPF,   |       |   X   |       |   X   |
           |   RIP         |       |       |       |       |
           +---------------+-------+-------+-------+-------+


   Warnings. None.


3.1.2 Use Non-Proprietary Encryption

   Requirement. If encryption is used to satisfy the Section 3.1.1
      requirements, then the encryption algorithms used MUST be
      non-proprietary. See [ANSI.T1.276-200x]

   Justification. Proprietary encryption algorithms and protocols that
      have not been subjected to public/peer review are more likely to
      have undiscovered weaknesses or flaws than open standards and
      publicly reviewed algorithms.

   Examples. None.

   Warnings. None.


3.1.3 Use Strong Encryption

   Requirement. If encryption is used to satisfy the Section 3.1.1
      requirements, then the key lengths and algorithms MUST be "strong"
      by current definitions.

   Justification. Short keys and weak algorithms threaten the
      confidentiality and integrity of communications.




Jones, Editor           Expires December 8, 2003               [Page 48]

Internet-Draft       Network Security Requirements             June 2003


   Examples. [ANSI.T1.276-200x] provides a list of acceptable key
      lengths for various types of encryption algorithms at the time of
      this writing.

   Warnings. "Strong" is a relative term.  Long keys and strong
      algorithms are intended to increase the work factor required to
      compromise the security of the data protected.  Over time, as
      processing power increases, the security provided by a given
      algorithm and key length will degrade.  The definition of "Strong"
      must be constantly reevaluated. There may be legal issues
      governing the use of encryption and the strength of encryption
      used.


3.1.4 Key Management Must Be Scalable

   Requirement. The number of keys and passwords that must be managed to
      support other requirements in this document MUST scale well.
      Specifically, The number of keys and passwords managed MUST
      increase, at most, linearly as the number of devices and users.

   Justification. In large networks, or in networks with large number of
      users, the key/password space could quickly grow to unmanageable
      size, inhibiting proper management and making audits difficult if
      not impossible.

   Examples. [Ed. insert verbiage about PKIs, etc.  Contributions to
      this space solicited.] See Section 3.1.1.

   Warnings. [Ed. insert verbiage about PKIs, etc.  Contributions to
      this space solicited]


3.1.5 Support Scripting of Management Functions

   Requirement. The device MUST provide a management interface that:

      *  Supports external scripting

      *  Has a simple, regular syntax

      *  Allows complete access to all management functions

      *  Works consistently on both in-band and out-of-band interfaces

      The interface MUST NOT be a text-based menu, windowing system, or
      GUI. The implementation should support scripts running on external
      systems using Perl, Expect, or some other common scripting



Jones, Editor           Expires December 8, 2003               [Page 49]

Internet-Draft       Network Security Requirements             June 2003


      languages.  This requirement explicitly does not anticipate
      support for scripting languages on the device itself.

   Justification. Scripting support is important for configuration
      fetching, auditing, attack tracking, automated administration,
      etc.

   Examples. A consistent command line interface is one possible
      implementation of this requirement.  An open, well-defined,
      scriptable management protocol is another.  An example of this
      would be the work currently being done in the IETF on xmlconf. See
      [I-D.enns-xmlconf-spec].

   Warnings. None.


3.2 User Interface Requirements

3.2.1 Display All Configuration Settings

   Requirement. The device MUST provide a mechanism to display a
      complete listing of all possible configuration settings and their
      current values.  This MUST include values for any "hidden"
      commands.  It MUST be possible to display all values, even those
      that are disabled, "off," or set to default values.

   Justification. It is not possible to perform thorough audits without
      a complete listing of all possible configuration settings and
      their current values.

   Examples. None.

   Warnings. It has been stated that it may be unreasonable to expect
      vendors to expose all settings, as this would lead to confusion
      due to customers changing settings that did not apply to their
      situation, and could drive up support costs.


3.3 IP Stack Requirements

3.3.1 Support Denial-Of-Service (DoS) Tracking

   Requirement. The device MUST include native "spoofed" packet
      tracking. This feature:

      *  MUST be able to capture data to a tracking table that shows how
         many packets match a configurable layer 3/4 header pattern or
         list of patterns from each previous hop router.



Jones, Editor           Expires December 8, 2003               [Page 50]

Internet-Draft       Network Security Requirements             June 2003


      *  MUST display the interface on which a matching packet arrived.

      *  MUST display the layer-2 header information. arrived.

      *  MUST implement "unknown source" as an optional part of the
         header pattern where "unknown" is the set of all addresses that
         are unreachable by the router (i.e., not in the forwarding
         table).

      *  MUST be able to display the tracking table showing the pattern
         that is being tracked and how many matches were received from
         each previous hop.

      This feature MUST be implemented with minimal impact to system
      performance.

   Justification. This applies in situations where DoS attacks, possibly
      utilizing spoofed source addresses, must be tracked across one or
      more routers. Without the capability to track DoS packets, it is
      possible that an attacker could adversely impact the availability
      of resources (hosts, routers, network links, etc.) leaving network
      administrators little to no capability to track and stop the
      attack. Layer 2 header information is particularly useful for
      identifying spoofed sources coming in over an Ethernet interface
      at a peering point and you want to track the source back to a
      particular ISP so you can ask them to trace the source.

   Examples.

      These features must allow the customer to quickly and easily ask
      the router which packets matching a given profile came into the
      router, from where, and how many from each source.

      Note that this requirement MAY be satisfied by implementing the
      requirements listed in Section 2.5

   Warnings. None.


3.3.2 Traffic Monitoring

   Requirement. The device MUST provide a means to monitor selected
      traffic through the system. It MUST provide the ability to select
      specific traffic patterns for monitoring based on arbitrary IP
      header patterns and layer 4 (TCP and UDP) header patterns. This
      includes: source and destination IP address, IP header flags,
      layer 4 source and destination ports (TCP, UDP), ICMP type and
      code fields, and other IP protocol types (e.g., 50 - ESP, 47 -



Jones, Editor           Expires December 8, 2003               [Page 51]

Internet-Draft       Network Security Requirements             June 2003


      GRE, etc.). It MUST provide the ability to monitor the full
      contents of the packets.  This feature MUST be implemented with
      minimal impact on system performance. In addition, the device MUST
      provide a means to remotely capture the data being monitored.

   Justification. This requirement applies in contexts where traffic
      headers and content must be monitored.  This enables
      characterization of malicious (and non-malicious) traffic, which
      may be essential to enable effective response and maintain normal
      operations.

   Examples.

      The addition of any traffic monitoring facility must be
      implemented with minimal impact on system performance. See Section
      3.1.1 for requirements related to secure communication channels
      for management protocols and data.

      Remote capture of header data could be implemented by sending it
      via syslog or SNMP. For the full packet capture, the device may
      send this information over the network for small data streams, or
      provide a "port mirroring" capability for large data streams where
      the data would be duplicated out a second configurable port.

   Warnings. Monitoring data can add significant network traffic,
      processor, and memory use.


3.3.3 Traffic Sampling

   NOTE: there is a proposed IETF working group active in this area. See
   the mailing list archives at https://ops.ietf.org/lists/psamp/. It is
   possible this section may just reference the product of that working
   group.

   Requirement. The device MUST provide a means to sample traffic
      through the system and summarize data from the layer 3 and 4
      headers.

      It MUST be possible to dump the cache at specified intervals to a
      collection host.  It MUST be possible to specify device behavior
      when the cache is full.  Options SHOULD include: dumping the cache
      to the specified collection host(s), clearing the cache,
      overwriting the cache, and disabling further sampling.  The cache
      SHOULD be implemented as a circular buffer such that older entries
      are overwritten first.  The device SHOULD provide options to
      manually dump or clear the cache.




Jones, Editor           Expires December 8, 2003               [Page 52]

Internet-Draft       Network Security Requirements             June 2003


      The device SHOULD provide a means of summarizing sampled data.
      The following IP layer header information SHOULD be summarized
      appropriately: type of service (or DS field), total length,
      protocol, source, and destination. The following TCP/UDP header
      information SHOULD be summarized appropriately: source port,
      destination port, UDP packet length, TCP header length, and TCP
      flag bits.

      The device MUST provide the ability to select the traffic-sampling
      rate. For instance, there MUST be a way to sample every nth
      packet, where n is a number determined by an authorized user and
      entered into the system configuration file. This feature must be
      implemented with minimal impact on system performance.

   Justification. This requirement enables accurate characterization of
      data transiting the device.  This supports identification of and
      response to malicious traffic.

   Examples. This requirement MAY be satisfied by allowing the user to
      specify that 1 in every N packets should be sampled. See Section
      3.1.1 for requirements related to secure communication channels
      for management protocols and data.

   Warnings. Traffic sampling can add significant network traffic,
      processor, and memory use.


























Jones, Editor           Expires December 8, 2003               [Page 53]

Internet-Draft       Network Security Requirements             June 2003


4. Advanced Requirements

   This section is intended to list security features that may not be
   implemented at the time of this writing, would be useful for
   improving security, but which may present significant challenges in
   terms of technology required, support costs, performance impact, etc.

4.1 IP Stack Requirements

4.1.1 Ability To Stealth Device

   Requirement. The device MUST provide a mechanism to allow it to
      become a "black box" as seen from public interfaces.  Specifically
      this means:

      *  The device SHOULD provide no information about itself (e.g.,
         system type, HW configuration, operating system type/revision,
         etc.) beyond the edge of the network (except for what's
         required to route traffic).

      *  Edge interfaces SHOULD be visible beyond the network.

      *  Internal interfaces SHOULD NOT be visible beyond the network
         (but would be visible within the network).

      *  It MUST be possible to not only disable all listening ports,
         but also to prevent them from initiating any traffic (such as
         ICMP error messages) in response to user activity.

      While the default configuration of the device SHOULD be fully RFC
      compliant (including the sending of ICMP messages), it MUST be
      possible to alter the default configuration such that the device
      is "stealthed" (i.e., does not send ICMP messages or otherwise
      respond directly to packets directed to it on non-management
      interfaces).

   Justification. This applies primarily in the context of core network
      infrastructure. A stealthed infrastructure which can not be
      addressed is less susceptible to direct attack.  Stealthing the
      core network infrastructure would eliminate the possibility of
      large classes of attacks and thus increase reliability and
      availability.

   Examples. Some specific capabilities important to stealthing include:

      *  Ability to filter/deny/ignore pings (ICMP echo requests)

      *  Ability to filter on individual protocol header bits



Jones, Editor           Expires December 8, 2003               [Page 54]

Internet-Draft       Network Security Requirements             June 2003


      *  Ability to control the generation of ICMP messages, including
         port unreachable and timeouts

      It MUST be possible to configure each of these settings
      individually.

   Warnings. Although some STEALTHING MECHANISMS MAY BE IN VIOLATION OF
      SOME RFCs, they are desirable/necessary in certain circumstances
      for security and operational reasons.










































Jones, Editor           Expires December 8, 2003               [Page 55]

Internet-Draft       Network Security Requirements             June 2003


5. Security Considerations

   Security is the subject matter of this entire memo. It might be more
   appropriate to list operational considerations. Operational issues
   are mentioned as needed in the examples and warnings sections of each
   requirement.













































Jones, Editor           Expires December 8, 2003               [Page 56]

Internet-Draft       Network Security Requirements             June 2003


References

   [ANSI.T1.276-200x]
              American National Standards Institute (ANSI),
              "T1.276-200x: Draft proposed American National Standard
              for Telecommunications Operations, Administration,
              Maintenance, and Provisioning Security Requirements for
              the Public Telecommunications Network: A Baseline of
              Security Requirements for the Management Plane", April
              2003.

   [Bugtraq]  SecurityFocus/Symantec, "Bugtraq mailing list", 2003,
              <http://www.securityfocus.com/archive/1>.

   [CERT.2002-03]
              CERT/CC, "Multiple Vulnerabilities in Many Implementations
              of the Simple Network Management Protocol (SNMP)", 2002,
              <http://www.cert.org/advisories/CA-2002-03.html>.

   [CERT/CC]  CERT/CC, "CERT/CC Advisories", 2003, <http://www.cert.org/
              advisories/>.

   [CVE]      The MITRE Corporation, "MITRE Common Vulnerabilities and
              Exposures", 2003, <http://www.cve.mitre.org>.

   [I-D.enns-xmlconf-spec]
              Enns, R., "XMLCONF Configuration Protocol",
              draft-enns-xmlconf-spec-00 (work in progress), February
              2003.

   [I-D.ietf-forces-requirements]
              Khosravi, H. and T. Anderson, "Requirements for Separation
              of IP Control and Forwarding",
              draft-ietf-forces-requirements-09 (work in progress), May
              2003.

   [Nessus]   Deraison, R., "Nessus Security Scanner", 2003, <http://
              www.nessus.org>.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.




Jones, Editor           Expires December 8, 2003               [Page 57]

Internet-Draft       Network Security Requirements             June 2003


   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

   [RFC0922]  Mogul, J., "Broadcasting Internet datagrams in the
              presence of subnets", STD 5, RFC 922, October 1984.

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC1704]  Haller, N. and R. Atkinson, "On Internet Authentication",
              RFC 1704, October 1994.

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers", RFC
              1812, June 1995.

   [RFC1858]  Ziemba, G., Reed, D. and P. Traina, "Security
              Considerations for IP Fragment Filtering", RFC 1858,
              October 1995.

   [RFC1948]  Bellovin, S., "Defending Against Sequence Number Attacks",
              RFC 1948, May 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2644]  Senie, D., "Changing the Default for Directed Broadcasts
              in Routers", BCP 34, RFC 2644, August 1999.

   [RFC2664]  Plzak, R., Wells, A. and E. Krol, "FYI on Questions and
              Answers - Answers to Commonly Asked "New Internet User"
              Questions", RFC 2664, August 1999.

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

   [RFC2867]  Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
              Modifications for Tunnel Protocol Support", RFC 2867, June
              2000.

   [RFC3164]  Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August
              2001.

   [RFC3195]  New, D. and M. Rose, "Reliable Delivery for syslog", RFC
              3195, November 2001.






Jones, Editor           Expires December 8, 2003               [Page 58]

Internet-Draft       Network Security Requirements             June 2003


Author's Address

   George M. Jones, Editor
   The MITRE Corporation
   7525 Colshire Dr., WEST
   McLean, VA  22102
   U.S.A.

   Phone: +1 703 488 9740
   EMail: gmjones@mitre.org
   URI:   http://www.port111.com/opsec/








































Jones, Editor           Expires December 8, 2003               [Page 59]

Internet-Draft       Network Security Requirements             June 2003


Appendix A. Requirement Profiles

   This Appendix lists different profiles.  A profile is a list of list
   of requirements that apply to a particular class of devices.  The
   minimum requirements profile applies to all devices.

   [Ed. there have been major changes to the individual requirements
   since these profiles were created.  They will be updated in -01].

A.1 Minimum Requirements Profile

   o  Section 2.3.1

   o  Section 2.1.1

   o  Section 3.1.1

   o  Section 2.1.6

   o  Section 2.12.1

   o  Section 2.12.2

   o  Section 2.12.3

   o  Section 2.12.4

   o  Section 2.12.5

   o  Section 2.12.6

   o  Section 2.12.7

   o  Section 2.12.8

   o  Section 2.12.10

   o  Section 2.12.11

   o  Section 2.12.12

   o  Section 2.12.13

   o  Section 2.12.14

   o  Section 2.3.8

   o  Section 2.3.4



Jones, Editor           Expires December 8, 2003               [Page 60]

Internet-Draft       Network Security Requirements             June 2003


   o  Section 2.3.5

   o  Section 2.3.6

   o  Section 2.11.1

   o  Section 2.2.1

   o  Section 3.1.5

   o  Section 2.1.7

   o  Section 2.14.1


A.2 Layer 3 Network Core Profile

   A core device is defined as a device that makes up the network
   infrastructure but does not connect directly to customers or peers.
   This would include backbone core routers.  This section lists layer
   requirements specific to core devices.

   o  Section 3.3.3

   o  Section 3.3.2

   o  Section 3.3.1

   o  Section 4.1.1


A.3 Layer 3 Network Edge Profile

   An edge device is defined as a device that makes up the network
   infrastructure and connects directly to customers or peers. This
   would include routers connected to peering points, switches
   connecting customer hosts, etc.  This section lists layer
   requirements specific to edge devices. In general, edge device
   requirements are a superset of those for core devices.

   o  Section 2.4.1

   o  Section 2.4.2

   o  Section 2.5

   o  Section 2.6.3




Jones, Editor           Expires December 8, 2003               [Page 61]

Internet-Draft       Network Security Requirements             June 2003


   o  Section 2.6.2

   o  Section 2.11.1

   o  Section 2.11.7

   o  Section 2.11.4

   o  Section 2.9.1

   o  Section 2.7.1

   o  Section 2.7.2

   o  Section 2.10.3

   o  Section 3.3.3

   o  Section 3.3.2

   o  Section 3.3.1


A.4 Layer 2 Network Core Profile

   This section lists layer two requirements specific to core devices.

   o  Section 2.13.2

   o  Section 2.13.3

   o  Section 2.13.4


A.5 Layer 2 Edge Profile

   This section lists layer two requirements specific to edge devices.

   o  Section 2.13.1

   o  Section 2.6.5

   o  Section 2.13.2

   o  Section 2.13.3

   o  Section 2.13.4




Jones, Editor           Expires December 8, 2003               [Page 62]

Internet-Draft       Network Security Requirements             June 2003


Appendix B. Acknowledgments

   This document grew out of an internal security requirements document
   used by UUNET for testing devices that were being proposed for
   connection to the backbone.

   The editor gratefully acknowledges the contributions of:

   o  Greg Sayadian, author of a predecessor of this document.

   o  Eric Brandwine, a major source of ideas/critiques.

   o  The MITRE Corporation for supporting continued 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  UUNET's entire network security team (past and present): Jared
      Allison, Eric Brandwine, Clarissa Cook, Dave Garn, Tae Kim, Kent
      King, Neil Kirr, Mark Krause, Michael Lamoureux, Maureen Lee, Todd
      MacDermid, Chris Morrow, Alan Pitts, Greg Sayadian, Bruce Snow,
      Robert Stone, Anne Williams, Pete White.

   o  Others who have provided significant feedback at various stages of
      the life of this document are: Ran Atkinson, Fred Baker, Steve
      Bellovin, Michael H. Behringer, Matt Bishop, Scott Blake, Randy
      Bush, Sean Donelan, Robert Elmore, Barry Greene, Dan Hollis,
      Merike Kaeo, John Kristoff, Chris Liljenstolpe, James W.
      Laferriere, Alan Paller, Rob Pickering, Gregg Schudel, Rodney
      Thayer, David Walters, Anthony Williams, Neal Ziring

   o  Madge B. Harrison, technical writing review.

   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...contact the editor to be credited in future
      versions

   Version: $Id: draft-jones-opsec-00.cpp,v 1.9 2003/06/09 10:59:03
   george Exp $






Jones, Editor           Expires December 8, 2003               [Page 63]

Internet-Draft       Network Security Requirements             June 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Jones, Editor           Expires December 8, 2003               [Page 64]

Internet-Draft       Network Security Requirements             June 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

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











































Jones, Editor           Expires December 8, 2003               [Page 65]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/