tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3871

 
 
 

Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure

Part 3 of 3, p. 55 to 81
Prev RFC Part

 


prevText      Top      Up      ToC       Page 55 
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.

Top      Up      ToC       Page 56 
2.12.2.  Support Authentication of Individual Users

   Requirement.

      Mechanisms used to authenticate interactive access for
      configuration and management MUST support the authentication of
      distinct, individual users.  This requirement MAY be relaxed to
      support system installation Section 2.4.5 or recovery of
      authorized access Section 2.12.15.

   Justification.

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

   Examples.

      A user may need to log in to the device to access CLI functions
      for management.  Individual user authentication could be provided
      by a centralized authentication server or a username/password
      database stored on the device.  It would be a violation of this
      rule for the device to only support a single "account" (with or
      without a username) and a single password shared by all users to
      gain administrative access.

   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 MUST support multiple simultaneous connections by
      distinct users, possibly at different authorization levels.

   Justification.

      This allows multiple people to perform authorized management
      functions simultaneously.  This also means that attempted
      connections by unauthorized users do not automatically lock out
      authorized users.

Top      Up      ToC       Page 57 
   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, etc.),

   *  privileged and unprivileged accounts.

      A local account defined as one where all information necessary for
      user authentication is stored on the device.

   Justification.

      Default accounts, well-known 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 Methods

   Requirement.

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

Top      Up      ToC       Page 58 
   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 can be satisfied through the use of DIAMETER
      [RFC3588], TACACS+ [RFC1492], RADIUS [RFC2865], or Kerberos
      [RFC1510].

      The secure management requirements (Section 2.1.1) apply to AAA.

      See [RFC3579] for a discussion security issues related to RADIUS.

   Warnings.

      None.

2.12.6.  Support Local User Authentication Method

   Requirement.

      The device SHOULD support a local authentication method.  If
      implemented, the method MUST NOT require interaction with anything
      external to the device (such as remote AAA servers),  and MUST
      work in conjunction with Section 2.3.1 (Support a 'Console'
      Interface) and Section 2.12.7 (Support Configuration of Order of
      Authentication Methods).

   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.

Top      Up      ToC       Page 59 
   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.
      Authentication SHOULD "fail closed", i.e., access should be denied
      if none of the listed authentication methods succeeds.

   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 Plaintext Passwords

   Requirement.

      The device MUST support mechanisms that do not require the
      transmission of plaintext passwords in all cases that require the
      transmission of authentication information across networks.

Top      Up      ToC       Page 60 
   Justification.

      Plaintext passwords can be easily observed using packet sniffers
      on shared networks.  See [RFC1704] and [RFC3631] for a through
      discussion.

   Examples.

      Remote login requires the transmission of authentication
      information across networks.  Telnet transmits plaintext
      passwords.  SSH does not.  Telnet fails this requirement.  SSH
      passes.

   Warnings.

      None.

2.12.9.  No Default Passwords

   Requirement.

      The initial configuration of the device MUST NOT contain any
      default passwords or other authentication tokens.

   Justification.

      Default passwords provide an easy way for attackers to gain
      unauthorized access to the device.

   Examples.

      Passwords such as the name of the vendor, device, "default", etc.
      are easily guessed.  The SNMP community strings "public" and
      "private" are well known defaults that provide read and write
      access to devices.

   Warnings.

      Lists of default passwords for various devices are readily
      available at numerous websites.

2.12.10.  Passwords Must Be Explicitly Configured Prior To Use

   Requirement.

      The device MUST require the operator to explicitly configure
      "passwords" prior to use.

Top      Up      ToC       Page 61 
   Justification.

      This requirement is intended to prevent unauthorized management
      access.  Requiring the operator to explicitly configure passwords
      will tend to have the effect of ensuring a diversity of passwords.
      It also shifts the responsibility for password selection to the
      user.

   Examples.

      Assume that a device comes with console port for management and a
      default administrative account.  This requirement together with No
      Default Passwords says that the administrative account should come
      with no password configured.  One way of meeting this requirement
      would be to have the device require the operator to choose a
      password for the administrative account as part of a dialog the
      first time the device is configured.

   Warnings.

      While this device requires operators to set passwords, it does not
      prevent them from doing things such as using scripts to configure
      hundreds of devices with the same easily guessed passwords.

2.12.11.  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.12.  There MUST be at least three possible privilege levels.

   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 "user" which only
      allows the initiation of a PPP or telnet session, "read only",
      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

Top      Up      ToC       Page 62 
      parameters.  Note that privilege levels may be defined locally on
      the device or on centralized authentication servers.

   Warnings.

      None.

2.12.12.  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 have
      authenticated themselves to the device.  Privilege level
      determines which functions a user is allowed to execute.  Also see
      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.

      The implementation of this requirement will obviously be closely
      coupled with the authentication mechanism.  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.

   Warnings.

      None.

2.12.13.  Default Privilege Level Must Be 'None'

   Requirement.

      The default privilege level SHOULD NOT allow any access to
      management or configuration functions.  It MAY allow access to
      user-level functions (e.g., starting PPP or telnet).  It SHOULD be
      possible to assign a different privilege level as the default.
      This requirement MAY be relaxed to support system installation per
      Section 2.4.5 or recovery of authorized access per Section
      2.12.15.

Top      Up      ToC       Page 63 
   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 "user" which only
      allows the initiation of a PPP or telnet session, "read-only",
      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.

      It may be required to provide exceptions to support the
      requirements to support recovery of privileged access (Section
      2.12.15) and to support OS installation and configuration (Section
      2.4.5).  For example, if the OS and/or configuration has somehow
      become corrupt an authorized individual with physical access may
      need to have "root" level access to perform an install.

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

Top      Up      ToC       Page 64 
2.12.15.  Support Recovery Of Privileged Access

   Requirement.

      The device MUST support a mechanism to allow authorized
      individuals to recover full privileged administrative access in
      the event that access is lost.  Use of the mechanism MUST require
      physical access to the device.  There MAY be a mechanism for
      disabling the recovery feature.

   Justification.

      There are times when local administrative passwords are forgotten,
      when the only person who knows them leaves the company, or when
      hackers set or change the password.  In all these cases,
      legitimate administrative access to the device is lost.  There
      should be a way to recover access.  Requiring physical access to
      invoke the procedure makes it less likely that it will be abused.
      Some organizations may want an even higher level of security and
      be willing to risk total loss of authorized access by disabling
      the recovery feature, even for those with physical access.

   Examples.

      Some examples of ways to satisfy this requirement are to have the
      device give the user the chance to set a new administrative
      password when:

      *  The user sets a jumper on the system board to a particular
         position.

      *  The user sends a special sequence to the RS232 console port
         during the initial boot sequence.

      *  The user sets a "boot register" to a particular value.

   Warnings.

      This mechanism, by design,  provides a "back door" to complete
      administrative control of the device and may not be appropriate
      for environments where those with physical access to the device
      can not be trusted.

      Also see the warnings in Section 2.3.1 (Support a 'Console'
      Interface).

Top      Up      ToC       Page 65 
2.13.  Layer 2 Devices Must Meet Higher Layer Requirements

   Requirement.

      If a device provides layer 2 services that are dependent on layer
      3 or greater services, then the portions that operate at or above
      layer 3 MUST conform to the requirements listed in this document.

   Justification.

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

   Examples.

      Signaling protocols required for layer 2 switching may exchange
      information with other devices using layer 3 communications.  In
      such cases, the device must provide a secure layer 3 facility.
      Also, if higher layer capabilities (say, SSH or SNMP) are used to
      manage a layer 2 device, then the rest of the requirements in this
      document apply to those capabilities.

   Warnings.

      None.

2.14.  Security Features Must Not Cause Operational Problems

   Requirement.

      The use of security features specified by the requirements in this
      document SHOULD NOT cause severe operational problems.

   Justification.

      Security features which cause operational problems are not useful
      and may leave the operator with no mechanism for enforcing
      appropriate policy.

   Examples.

      Some examples of severe operational problems include:

      *  The device crashes.

      *  The device becomes unmanageable.

      *  Data is lost.

Top      Up      ToC       Page 66 
      *  Use of the security feature consumes excessive resources (CPU,
         memory, bandwidth).

   Warnings.

      Determination of compliance with this requirement involves a level
      of judgement.  What is "severe"?  Certainly crashing is severe,
      but what about a %5 loss in throughput when logging is enabled?
      It should also be noted that there may be unavoidable physical
      limitations such as the total capacity of a link.

2.15.  Security Features Should Have Minimal Performance Impact

   Requirement.

      Security features specified by the requirements in this document
      SHOULD be implemented with minimal impact on performance.  Other
      sections of this document may specify different performance
      requirements (e.g., "MUST"s).

   Justification.

      Security features which significantly impact performance may leave
      the operator with no mechanism for enforcing appropriate policy.

   Examples.

      If the application of filters is known to have the potential to
      significantly reduce throughput for non-filtered traffic, there
      will be a tendency, or in some cases a policy, not to use filters.

      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.

   Warnings.

      Requirements for which performance is a particular concern
      include: filtering, rate-limiting, counters, logging and anti-
      spoofing.

Top      Up      ToC       Page 67 
3.  Documentation Requirements

   The requirements in this section are intended to list information
   that will assist operators in evaluating and securely operating a
   device.

3.1.  Identify Services That May Be Listening

   Requirement.

      The vendor MUST provide a list of all services that may be active
      on the device.  The list MUST identify the protocols and default
      ports (if applicable) on which the services listen.  It SHOULD
      provide references to complete documentation describing the
      service.

   Justification.

      This information is necessary to enable a thorough assessment of
      the potential security risks associated with the operation of each
      service.

   Examples.

      The list will likely contain network and transport protocols such
      as IP, ICMP, TCP, UDP, routing protocols such as BGP and OSPF,
      application protocols such as SSH and SNMP along with references
      to the RFCs or other documentation describing the versions of the
      protocols implemented.

      Web servers "usually" listen on port 80.  In the default
      configuration of the device, it may have a web server listening on
      port 8080.  In the context of this requirement "identify ...
      default port" would mean "port 8080".

   Warnings.

      There may be valid, non-technical reasons for not disclosing the
      specifications of proprietary protocols.  In such cases, all that
      needs to be disclosed is the existence of the service and the
      default ports (if applicable).

3.2.  Document Service Defaults

   Requirement.

      The vendor MUST provide a list of the default state of all
      services.

Top      Up      ToC       Page 68 
   Justification.

      Understanding risk requires understanding exposure.  Each service
      that is enabled presents a certain level of exposure.  Having a
      list of the services that is enabled by default makes it possible
      to perform meaningful risk analysis.

   Examples.

      The list may be no more than the output of a command that
      implements Section 2.5.1.

   Warnings.

      None.

3.3.  Document Service Activation Process

   Requirement.

      The vendor MUST concisely document which features enable and
      disable services.

   Justification.

      Once risk has been assessed, this list provides the operator a
      quick means of understanding how to disable (or enable) undesired
      (or desired) services.

   Examples.

      This may be a list of commands to enable/disable services one by
      one or a single command which enables/disables "standard" groups
      of commands.

   Warnings.

      None.

3.4.  Document Command Line Interface

   Requirement.

      The vendor MUST provide complete documentation of the command line
      interface with each software release.  The documentation SHOULD
      include highlights of changes from previous versions.  The
      documentation SHOULD list potential output for each command.

Top      Up      ToC       Page 69 
   Justification.

      Understanding of inputs and outputs is necessary to support
      scripting. See Section 2.4.2.

   Examples.

      Separate documentation should be provided for each command listing
      the syntax, parameters, options, etc. as well as expected output
      (status, tables, etc.).

   Warnings.

      None.

3.5.  'Console' Default Communication Profile Documented

   Requirement.

      The console default profile of communications parameters MUST be
      published in the system documentation.

   Justification.

      Publication in the system documentation makes the settings
      accessible.  Failure to publish them could leave the operator
      having to guess.

   Examples.

      None.

   Warnings.

      None.

4.  Assurance Requirements

   The requirements in this section are intended to

   o  identify behaviors and information that will increase confidence
      that the device will meet the security functional requirements.

   o  Provide information that will assist in the performance of
      security evaluations.

Top      Up      ToC       Page 70 
4.1.  Identify Origin of IP Stack

   Requirement.

      The vendor SHOULD 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.

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

4.2.  Identify Origin of Operating System

   Requirement.

      The vendor SHOULD 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.

      "The operating system is based on Linux kernel 2.4.18."

   Warnings.

      None.

Top      Up      ToC       Page 71 
5.  Security Considerations

   General

      Security is the subject matter of this entire memo.  The
      justification section of each individual requirement lists the
      security implications of meeting or not meeting the requirement.

   SNMP

      SNMP versions prior to SNMPv3 did not include adequate security.
      Even if the network itself is secure (for example by using IPSec),
      even then, there is no control as to who on the secure network is
      allowed to access and GET/SET (read/change/create/delete) the
      objects in the MIB.

      It is recommended that implementors consider the security features
      as provided by the SNMPv3 framework (see [RFC3410], section 8),
      including full support for the SNMPv3 cryptographic mechanisms
      (for authentication and privacy).

      Furthermore, deployment of SNMP versions prior to SNMPv3 is NOT
      RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
      enable cryptographic security.  It is then a customer/operator
      responsibility to ensure that the SNMP entity giving access to MIB
      objects is properly configured to give access to the objects only
      to those principals (users) that have legitimate rights to indeed
      GET or SET (change/create/delete) them.

6.  References

6.1.  Normative References

   [ANSI.X9-52.1998] American National Standards Institute, "Triple Data
                     Encryption Algorithm Modes of Operation", ANSI
                     X9.52, 1998.

   [FIPS.197]        National Institute of Standards and Technology,
                     "Advanced Encryption Standard", FIPS PUB 197,
                     November 2001,
                     <http://csrc.nist.gov/publications/fips/fips197/
                     fips-197.ps>.

   [PKCS.3.1993]     RSA Laboratories, "Diffie-Hellman Key-Agreement
                     Standard, Version 1.4", PKCS 3, November 1993.

   [RFC1208]         Jacobsen, O. and D. Lynch, "Glossary of networking
                     terms", RFC 1208, March 1991.

Top      Up      ToC       Page 72 
   [RFC1321]         Rivest, R., "The MD5 Message-Digest Algorithm", RFC
                     1321, April 1992.

   [RFC1492]         Finseth, C., "An Access Control Protocol, Sometimes
                     Called TACACS", RFC 1492, July 1993.

   [RFC1510]         Kohl, J. and C. Neuman, "The Kerberos Network
                     Authentication Service (V5)", RFC 1510, September
                     1993.

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

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

   [RFC1918]         Rekhter, Y., Moskowitz, B., Karrenberg, D., de
                     Groot, G., and E. Lear, "Address Allocation for
                     Private Internets", BCP 5, RFC 1918, February 1996.

   [RFC2026]         Bradner, S., "The Internet Standards Process --
                     Revision 3", BCP 9, RFC 2026, October 1996.

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

   [RFC2196]         Fraser, B., "Site Security Handbook", FYI 8, RFC
                     2196, September 1997.

   [RFC2246]         Dierks, T. and C. Allen, "The TLS Protocol Version
                     1.0", RFC 2246, January 1999.

   [RFC2385]         Heffernan, A., "Protection of BGP Sessions via the
                     TCP MD5 Signature Option", RFC 2385, August 1998.

   [RFC2401]         Kent, S. and R. Atkinson, "Security Architecture
                     for the Internet Protocol", RFC 2401, November
                     1998.

   [RFC2631]         Rescorla, E., "Diffie-Hellman Key Agreement
                     Method", RFC 2631, June 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.

Top      Up      ToC       Page 73 
   [RFC2865]         Rigney, C., Willens, S., Rubens, A., and W.
                     Simpson, "Remote Authentication Dial In User
                     Service (RADIUS)", RFC 2865, June 2000.

   [RFC3013]         Killalea, T., "Recommended Internet Service
                     Provider Security Services and Procedures", BCP 46,
                     RFC 3013, November 2000.

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

   [RFC3174]         Eastlake, D. and P. Jones, "US Secure Hash
                     Algorithm 1 (SHA1)", RFC 3174, September 2001.

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

   [RFC3309]         Stone, J., Stewart, R. and D. Otis, "Stream Control
                     Transmission Protocol (SCTP) Checksum Change", RFC
                     3309, September 2002.

   [RFC3330]         IANA, "Special-Use IPv4 Addresses", RFC 3330,
                     September 2002.

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

   [RFC3410]         Case, J., Mundy, R., Partain, D. and B. Stewart,
                     "Introduction and Applicability Statements for
                     Internet-Standard Management Framework", RFC 3410,
                     December 2002.

   [RFC3411]         Harrington, D., Presuhn, R., and B. Wijnen, "An
                     Architecture for Describing Simple Network
                     Management Protocol (SNMP) Management Frameworks",
                     STD 62, RFC 3411, December 2002.

   [RFC3447]         Jonsson, J. and B. Kaliski, "Public-Key
                     Cryptography Standards (PKCS) #1: RSA Cryptography
                     Specifications Version 2.1", RFC 3447, February
                     2003.

   [RFC3562]         Leech, M., "Key Management Considerations for the
                     TCP MD5 Signature Option", RFC 3562, July 2003.

Top      Up      ToC       Page 74 
   [RFC3579]         Aboba, B. and P. Calhoun, "RADIUS (Remote
                     Authentication Dial In User Service) Support For
                     Extensible Authentication Protocol (EAP)", RFC
                     3579, September 2003.

   [RFC3588]         Calhoun, P., Loughney, J., Guttman, E., Zorn, G.,
                     and J. Arkko, "Diameter Base Protocol", RFC 3588,
                     September 2003.

   [RFC3631]         Bellovin, S., Schiller, J., and C. Kaufman, Eds.,
                     "Security Mechanisms for the Internet", RFC 3631,
                     December 2003.

6.2.  Informative References

   [RFC3766]         Orman, H. and P. Hoffman, "Determining Strengths
                     For Public Keys Used For Exchanging Symmetric
                     Keys", BCP 86, RFC 3766, April 2004.

   [RFC3704]         Baker, F. and P. Savola, "Ingress Filtering for
                     Multihomed Networks", BCP 84, RFC 3704, March 2004.

   [bmwg-acc-bench]  Poretsky, S., "Framework for Accelerated Stress
                     Benchmarking", Work in Progress, October 2003.

   [Schneier]        Schneier, B., "Applied Cryptography, 2nd Ed.,
                     Publisher John Wiley & Sons, Inc.", 1996.

Top      Up      ToC       Page 75 
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.

A.1.  Minimum Requirements Profile

   The functionality listed here represents a minimum set of
   requirements to which managed infrastructure of large IP networks
   should adhere.

   The minimal requirements profile addresses functionality which will
   provide reasonable capabilities to manage the devices in the event of
   attacks, simplify troubleshooting, keep track of events which affect
   system integrity, help analyze causes of attacks, as well as provide
   administrators  control over IP addresses and protocols to help
   mitigate the most common attacks and exploits.

   o  Support Secure Channels For Management

   o  Use Protocols Subject To Open Review For Management

   o  Use Cryptographic Algorithms Subject To Open Review

   o  Use Strong Cryptography

   o  Allow Selection of Cryptographic Parameters

   o  Management Functions Should Have Increased Priority

   o  Support a 'Console' Interface

   o  'Console' Communication Profile Must Support Reset

   o  'Console' Default Communication Profile Documented

   o  'Console' Requires Minimal Functionality of Attached Devices.

   o  Support Separate Management Plane IP Interfaces

   o  No Forwarding Between Management Plane And Other Interfaces

   o  'CLI' Provides Access to All Configuration and Management
      Functions

   o  'CLI' Supports Scripting of Configuration

Top      Up      ToC       Page 76 
   o  'CLI' Supports Management Over 'Slow' Links

   o  Document Command Line Interface

   o  Support Software Installation

   o  Support Remote Configuration Backup

   o  Support Remote Configuration Restore

   o  Support Text Configuration Files

   o  Ability to Identify All Listening Services

   o  Ability to Disable Any and All Services

   o  Ability to Control Service Bindings for Listening Services

   o  Ability to Control Service Source Addresses

   o  Ability to Filter Traffic

   o  Ability to Filter Traffic TO the Device

   o  Support Route Filtering

   o  Ability to Specify Filter Actions

   o  Ability to Log Filter Actions

   o  Ability to Filter Without Significant Performance Degradation

   o  Ability to Specify Filter Log Granularity

   o  Ability to Filter on Protocols

   o  Ability to Filter on Addresses

   o  Ability to Filter on Protocol Header Fields

   o  Ability to Filter Inbound and Outbound

   o  Packet Filtering Counter Requirements

   o  Ability to Display Filter Counters

   o  Ability to Display Filter Counters per Rule

Top      Up      ToC       Page 77 
   o  Ability to Display Filter Counters per Filter Application

   o  Ability to Reset Filter Counters

   o  Filter Counters Must Be Accurate

   o  Logging Facility Uses Protocols Subject To Open Review

   o  Logs Sent To Remote Servers

   o  Ability to Log Locally

   o  Ability to Maintain Accurate System Time

   o  Display Timezone And UTC Offset

   o  Default Timezone Should Be UTC

   o  Logs Must Be Timestamped

   o  Logs Contain Untranslated IP Addresses

   o  Logs Contain Records Of Security Events

   o  Authenticate All User Access

   o  Support Authentication of Individual Users

   o  Support Simultaneous Connections

   o  Ability to Disable All Local Accounts

   o  Support Centralized User Authentication Methods

   o  Support Local User Authentication Method

   o  Support Configuration of Order of Authentication Methods

   o  Ability To Authenticate Without Plaintext Passwords

   o  Passwords Must Be Explicitly Configured Prior To Use

   o  No Default Passwords

   o  Ability to Define Privilege Levels

   o  Ability to Assign Privilege Levels to Users

Top      Up      ToC       Page 78 
   o  Default Privilege Level Must Be 'None'

   o  Change in Privilege Levels Requires Re-Authentication

   o  Support Recovery Of Privileged Access

   o  Logs Do Not Contain Passwords

   o  Security Features Must Not Cause Operational Problems

   o  Security Features Should Have Minimal Performance Impact

   o  Identify Services That May Be Listening

   o  Document Service Defaults

   o  Document Service Activation Process

   o  Identify Origin of IP Stack

   o  Identify Origin of Operating System

   o  Identify Origin of IP Stack

   o  Identify Origin of Operating System

   o  Layer 2 Devices Must Meet Higher Layer Requirements

A.2.  Layer 3 Network Edge Profile

   This section builds on the minimal requirements listed in A.1 and
   adds more stringent security functionality specific to layer 3
   devices which are part of the network edge.  The network edge is
   typically where much of the filtering and traffic control policies
   are implemented.

   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.

   o  Support Automatic Anti-spoofing for Single-Homed Networks

   o  Support Automatic Discarding Of Bogons and Martians

   o  Support Counters For Dropped Packets

   o  Support Rate Limiting

Top      Up      ToC       Page 79 
   o  Support Directional Application Of Rate Limiting Per Interface

   o  Support Rate Limiting Based on State

   o  Ability to Filter Traffic THROUGH the Device

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  The former UUNET network security team: 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, David L. Black, Michael H. Behringer, Matt Bishop, Scott
      Blake, Randy Bush, Pat Cain, Ross Callon, Steven Christey, Owen
      Delong, Sean Donelan, Robert Elmore, Barbara Fraser, Barry Greene,
      Jeffrey Haas, David Harrington, Dan Hollis, Jeffrey Hutzelman,
      Merike Kaeo, James Ko, John Kristoff, Chris Lonvick, Chris
      Liljenstolpe, James W. Laferriere, Jared Mauch, Perry E. Metzger,
      Mike O'Connor, Alan Paller, Rob Pickering, Pekka Savola, Gregg
      Schudel, Juergen Schoenwaelder, Don Smith, Rodney Thayer, David
      Walters, Joel N. Weber II, Russ White, Anthony Williams, Neal
      Ziring.

   o  Madge B. Harrison and Patricia L. Jones, 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.

Top      Up      ToC       Page 80 
   o  Apologies to those who commented on/contributed to the document
      and were not listed.

Author's Address

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

   Phone: +1 703 488 9740
   EMail: gmj3871@pobox.com

Top      Up      ToC       Page 81 
Full Copyright Statement

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

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

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

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

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

Acknowledgement

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