File: rfc3871.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (4533 lines) | stat: -rw-r--r-- 191,493 bytes
parent folder | download | duplicates (2)
<pre>Network Working Group                                      G. Jones, Ed.
Request for Comments: 3871                         The MITRE Corporation
Category: Informational                                   September 2004


              <span class="h1">Operational Security Requirements for Large</span>
       <span class="h1">Internet Service Provider (ISP) IP Network Infrastructure</span>

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document defines a list of operational security requirements for
   the infrastructure of large Internet Service Provider (ISP) IP
   networks (routers and switches).  A framework is defined for
   specifying "profiles", which are collections of requirements
   applicable to certain network topology contexts (all, core-only,
   edge-only...).  The goal is to provide network operators a clear,
   concise way of communicating their security requirements to vendors.
























<span class="grey">Jones                        Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


Table of Contents

   <a href="#section-1">1</a>.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
       <a href="#section-1.1">1.1</a>.  Goals. . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
       <a href="#section-1.2">1.2</a>.  Motivation . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
       <a href="#section-1.3">1.3</a>.  Scope. . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
       <a href="#section-1.4">1.4</a>.  Definition of a Secure Network . . . . . . . . . . . . .  <a href="#page-6">6</a>
       <a href="#section-1.5">1.5</a>.  Intended Audience. . . . . . . . . . . . . . . . . . . .  <a href="#page-6">6</a>
       <a href="#section-1.6">1.6</a>.  Format . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-6">6</a>
       <a href="#section-1.7">1.7</a>.  Intended Use . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-7">7</a>
       <a href="#section-1.8">1.8</a>.  Definitions. . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-7">7</a>
   <a href="#section-2">2</a>.  Functional Requirements  . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
       <a href="#section-2.1">2.1</a>.  Device Management Requirements . . . . . . . . . . . . . <a href="#page-11">11</a>
             <a href="#section-2.1.1">2.1.1</a>.   Support Secure Channels For Management. . . . . <a href="#page-11">11</a>
       <a href="#section-2.2">2.2</a>.  In-Band Management Requirements. . . . . . . . . . . . . <a href="#page-12">12</a>
             2.2.1.   Use Cryptographic Algorithms Subject To
                      Open Review . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
             <a href="#section-2.2.2">2.2.2</a>.   Use Strong Cryptography . . . . . . . . . . . . <a href="#page-13">13</a>
             2.2.3.   Use Protocols Subject To Open Review For
                      Management. . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
             <a href="#section-2.2.4">2.2.4</a>.   Allow Selection of Cryptographic Parameters . . <a href="#page-15">15</a>
             2.2.5.   Management Functions Should Have Increased
                      Priority. . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
       <a href="#section-2.3">2.3</a>.  Out-of-Band (OoB) Management Requirements  . . . . . . . <a href="#page-16">16</a>
             <a href="#section-2.3.1">2.3.1</a>.   Support a 'Console' Interface . . . . . . . . . <a href="#page-17">17</a>
             2.3.2.   'Console' Communication Profile Must Support
                      Reset . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
             2.3.3.   'Console' Requires Minimal Functionality of
                      Attached Devices. . . . . . . . . . . . . . . . <a href="#page-19">19</a>
             <a href="#section-2.3.4">2.3.4</a>.   'Console' Supports Fall-back Authentication . . <a href="#page-20">20</a>
             2.3.5.   Support Separate Management Plane IP
                      Interfaces. . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
             2.3.6.   No Forwarding Between Management Plane And Other
                      Interfaces. . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
       <a href="#section-2.4">2.4</a>.  Configuration and Management Interface Requirements. . . <a href="#page-22">22</a>
             2.4.1.   'CLI' Provides Access to All Configuration and
                      Management Functions. . . . . . . . . . . . . . <a href="#page-22">22</a>
             <a href="#section-2.4.2">2.4.2</a>.   'CLI' Supports Scripting of Configuration . . . <a href="#page-23">23</a>
             <a href="#section-2.4.3">2.4.3</a>.   'CLI' Supports Management Over 'Slow' Links . . <a href="#page-24">24</a>
             <a href="#section-2.4.4">2.4.4</a>.   'CLI' Supports Idle Session Timeout . . . . . . <a href="#page-25">25</a>
             <a href="#section-2.4.5">2.4.5</a>.   Support Software Installation . . . . . . . . . <a href="#page-25">25</a>
             <a href="#section-2.4.6">2.4.6</a>.   Support Remote Configuration Backup . . . . . . <a href="#page-27">27</a>
             <a href="#section-2.4.7">2.4.7</a>.   Support Remote Configuration Restore. . . . . . <a href="#page-27">27</a>
             <a href="#section-2.4.8">2.4.8</a>.   Support Text Configuration Files. . . . . . . . <a href="#page-28">28</a>
       <a href="#section-2.5">2.5</a>.  IP Stack Requirements. . . . . . . . . . . . . . . . . . <a href="#page-29">29</a>
             <a href="#section-2.5.1">2.5.1</a>.   Ability to Identify All Listening Services. . . <a href="#page-29">29</a>
             <a href="#section-2.5.2">2.5.2</a>.   Ability to Disable Any and All Services . . . . <a href="#page-30">30</a>




<span class="grey">Jones                        Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


             2.5.3.   Ability to Control Service Bindings for
                      Listening Services. . . . . . . . . . . . . . . <a href="#page-30">30</a>
             <a href="#section-2.5.4">2.5.4</a>.   Ability to Control Service Source Addresses . . <a href="#page-31">31</a>
             2.5.5.   Support Automatic Anti-spoofing for
                      Single-Homed Networks . . . . . . . . . . . . . <a href="#page-32">32</a>
             2.5.6.   Support Automatic Discarding Of Bogons and
                      Martians. . . . . . . . . . . . . . . . . . . . <a href="#page-33">33</a>
             <a href="#section-2.5.7">2.5.7</a>.   Support Counters For Dropped Packets. . . . . . <a href="#page-34">34</a>
       <a href="#section-2.6">2.6</a>.  Rate Limiting Requirements . . . . . . . . . . . . . . . <a href="#page-35">35</a>
             <a href="#section-2.6.1">2.6.1</a>.   Support Rate Limiting . . . . . . . . . . . . . <a href="#page-35">35</a>
             2.6.2.   Support Directional Application Of Rate
                      Limiting Per Interface. . . . . . . . . . . . . <a href="#page-36">36</a>
             <a href="#section-2.6.3">2.6.3</a>.   Support Rate Limiting Based on State. . . . . . <a href="#page-36">36</a>
       <a href="#section-2.7">2.7</a>.  Basic Filtering Capabilities . . . . . . . . . . . . . . <a href="#page-37">37</a>
             <a href="#section-2.7.1">2.7.1</a>.   Ability to Filter Traffic . . . . . . . . . . . <a href="#page-37">37</a>
             <a href="#section-2.7.2">2.7.2</a>.   Ability to Filter Traffic TO the Device . . . . <a href="#page-37">37</a>
             <a href="#section-2.7.3">2.7.3</a>.   Ability to Filter Traffic THROUGH the Device. . <a href="#page-38">38</a>
             2.7.4.   Ability to Filter Without Significant
                      Performance Degradation . . . . . . . . . . . . <a href="#page-38">38</a>
             <a href="#section-2.7.5">2.7.5</a>.   Support Route Filtering . . . . . . . . . . . . <a href="#page-39">39</a>
             <a href="#section-2.7.6">2.7.6</a>.   Ability to Specify Filter Actions . . . . . . . <a href="#page-40">40</a>
             <a href="#section-2.7.7">2.7.7</a>.   Ability to Log Filter Actions . . . . . . . . . <a href="#page-40">40</a>
       <a href="#section-2.8">2.8</a>.  Packet Filtering Criteria. . . . . . . . . . . . . . . . <a href="#page-41">41</a>
             <a href="#section-2.8.1">2.8.1</a>.   Ability to Filter on Protocols. . . . . . . . . <a href="#page-41">41</a>
             <a href="#section-2.8.2">2.8.2</a>.   Ability to Filter on Addresses. . . . . . . . . <a href="#page-42">42</a>
             <a href="#section-2.8.3">2.8.3</a>.   Ability to Filter on Protocol Header Fields . . <a href="#page-42">42</a>
             <a href="#section-2.8.4">2.8.4</a>.   Ability to Filter Inbound and Outbound. . . . . <a href="#page-43">43</a>
       <a href="#section-2.9">2.9</a>.  Packet Filtering Counter Requirements. . . . . . . . . . <a href="#page-43">43</a>
             <a href="#section-2.9.1">2.9.1</a>.   Ability to Accurately Count Filter Hits . . . . <a href="#page-43">43</a>
             <a href="#section-2.9.2">2.9.2</a>.   Ability to Display Filter Counters. . . . . . . <a href="#page-44">44</a>
             <a href="#section-2.9.3">2.9.3</a>.   Ability to Display Filter Counters per Rule . . <a href="#page-45">45</a>
             2.9.4.   Ability to Display Filter Counters per Filter
                      Application . . . . . . . . . . . . . . . . . . <a href="#page-45">45</a>
             <a href="#section-2.9.5">2.9.5</a>.   Ability to Reset Filter Counters. . . . . . . . <a href="#page-46">46</a>
             <a href="#section-2.9.6">2.9.6</a>.   Filter Counters Must Be Accurate. . . . . . . . <a href="#page-47">47</a>
       <a href="#section-2.10">2.10</a>. Other Packet Filtering Requirements  . . . . . . . . . . <a href="#page-47">47</a>
             <a href="#section-2.10.1">2.10.1</a>.  Ability to Specify Filter Log Granularity . . . <a href="#page-47">47</a>
       <a href="#section-2.11">2.11</a>. Event Logging Requirements . . . . . . . . . . . . . . . <a href="#page-48">48</a>
             2.11.1.  Logging Facility Uses Protocols Subject To
                      Open Review . . . . . . . . . . . . . . . . . . <a href="#page-48">48</a>
             <a href="#section-2.11.2">2.11.2</a>.  Logs Sent To Remote Servers . . . . . . . . . . <a href="#page-49">49</a>
             <a href="#section-2.11.3">2.11.3</a>.  Ability to Select Reliable Delivery . . . . . . <a href="#page-49">49</a>
             <a href="#section-2.11.4">2.11.4</a>.  Ability to Log Locally. . . . . . . . . . . . . <a href="#page-50">50</a>
             <a href="#section-2.11.5">2.11.5</a>.  Ability to Maintain Accurate System Time. . . . <a href="#page-50">50</a>
             <a href="#section-2.11.6">2.11.6</a>.  Display Timezone And UTC Offset . . . . . . . . <a href="#page-51">51</a>
             <a href="#section-2.11.7">2.11.7</a>.  Default Timezone Should Be UTC. . . . . . . . . <a href="#page-52">52</a>
             <a href="#section-2.11.8">2.11.8</a>.  Logs Must Be Timestamped. . . . . . . . . . . . <a href="#page-52">52</a>
             <a href="#section-2.11.9">2.11.9</a>.  Logs Contain Untranslated IP Addresses. . . . . <a href="#page-53">53</a>



<span class="grey">Jones                        Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


             <a href="#section-2.11.10">2.11.10</a>. Logs Contain Records Of Security Events . . . . <a href="#page-54">54</a>
             <a href="#section-2.11.11">2.11.11</a>. Logs Do Not Contain Passwords . . . . . . . . . <a href="#page-55">55</a>
       2.12. Authentication, Authorization, and Accounting (AAA)
             Requirements . . . . . . . . . . . . . . . . . . . . . . <a href="#page-55">55</a>
             <a href="#section-2.12.1">2.12.1</a>.  Authenticate All User Access. . . . . . . . . . <a href="#page-55">55</a>
             <a href="#section-2.12.2">2.12.2</a>.  Support Authentication of Individual Users. . . <a href="#page-56">56</a>
             <a href="#section-2.12.3">2.12.3</a>.  Support Simultaneous Connections. . . . . . . . <a href="#page-56">56</a>
             <a href="#section-2.12.4">2.12.4</a>.  Ability to Disable All Local Accounts . . . . . <a href="#page-57">57</a>
             2.12.5.  Support Centralized User Authentication
                      Methods . . . . . . . . . . . . . . . . . . . . <a href="#page-57">57</a>
             <a href="#section-2.12.6">2.12.6</a>.  Support Local User Authentication Method. . . . <a href="#page-58">58</a>
             2.12.7.  Support Configuration of Order of
                      Authentication Methods  . . . . . . . . . . . . <a href="#page-59">59</a>
             2.12.8.  Ability To Authenticate Without Plaintext
                      Passwords . . . . . . . . . . . . . . . . . . . <a href="#page-59">59</a>
             <a href="#section-2.12.9">2.12.9</a>.  No Default Passwords. . . . . . . . . . . . . . <a href="#page-60">60</a>
             2.12.10. Passwords Must Be Explicitly Configured Prior
                      To Use. . . . . . . . . . . . . . . . . . . . . <a href="#page-60">60</a>
             <a href="#section-2.12.11">2.12.11</a>. Ability to Define Privilege Levels. . . . . . . <a href="#page-61">61</a>
             <a href="#section-2.12.12">2.12.12</a>. Ability to Assign Privilege Levels to Users . . <a href="#page-62">62</a>
             <a href="#section-2.12.13">2.12.13</a>. Default Privilege Level Must Be 'None'. . . . . <a href="#page-62">62</a>
             2.12.14. Change in Privilege Levels Requires
                      Re-Authentication . . . . . . . . . . . . . . . <a href="#page-63">63</a>
             <a href="#section-2.12.15">2.12.15</a>. Support Recovery Of Privileged Access . . . . . <a href="#page-64">64</a>
       <a href="#section-2.13">2.13</a>. Layer 2 Devices Must Meet Higher Layer Requirements. . . <a href="#page-65">65</a>
       <a href="#section-2.14">2.14</a>. Security Features Must Not Cause Operational Problems. . <a href="#page-65">65</a>
       2.15. Security Features Should Have Minimal Performance
             Impact . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-66">66</a>
   <a href="#section-3">3</a>.  Documentation Requirements . . . . . . . . . . . . . . . . . . <a href="#page-67">67</a>
       <a href="#section-3.1">3.1</a>.  Identify Services That May Be Listening. . . . . . . . . <a href="#page-67">67</a>
       <a href="#section-3.2">3.2</a>.  Document Service Defaults. . . . . . . . . . . . . . . . <a href="#page-67">67</a>
       <a href="#section-3.3">3.3</a>.  Document Service Activation Process. . . . . . . . . . . <a href="#page-68">68</a>
       <a href="#section-3.4">3.4</a>.  Document Command Line Interface. . . . . . . . . . . . . <a href="#page-68">68</a>
       <a href="#section-3.5">3.5</a>.  'Console' Default Communication Profile Documented . . . <a href="#page-69">69</a>
   <a href="#section-4">4</a>.  Assurance Requirements . . . . . . . . . . . . . . . . . . . . <a href="#page-69">69</a>
       <a href="#section-4.1">4.1</a>.  Identify Origin of IP Stack. . . . . . . . . . . . . . . <a href="#page-70">70</a>
       <a href="#section-4.2">4.2</a>.  Identify Origin of Operating System. . . . . . . . . . . <a href="#page-70">70</a>
   <a href="#section-5">5</a>.  Security Considerations . .  . . . . . . . . . . . . . . . . . <a href="#page-71">71</a>
   <a href="#section-6">6</a>.  References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-71">71</a>
       <a href="#section-6.1">6.1</a>.  Normative References . . . . . . . . . . . . . . . . . . <a href="#page-71">71</a>
       <a href="#section-6.2">6.2</a>.  Informative References . . . . . . . . . . . . . . . . . <a href="#page-74">74</a>
   Appendices
   <a href="#appendix-A">A</a>.  Requirement Profiles . . . . . . . . . . . . . . . . . . . . . <a href="#page-75">75</a>
       <a href="#appendix-A.1">A.1</a>.  Minimum Requirements Profile . . . . . . . . . . . . . . <a href="#page-75">75</a>
       <a href="#appendix-A.2">A.2</a>.  Layer 3 Network Edge Profile . . . . . . . . . . . . . . <a href="#page-78">78</a>
   <a href="#appendix-B">B</a>.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-79">79</a>
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-80">80</a>
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . <a href="#page-81">81</a>



<span class="grey">Jones                        Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Goals</span>

   This document defines a list of operational security requirements for
   the infrastructure of large IP networks (routers and switches).  The
   goal is to provide network operators a clear, concise way of
   communicating their security requirements to equipment vendors.

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  Motivation</span>

   Network operators need tools to ensure that they are able to manage
   their networks securely and to insure that they maintain the ability
   to provide service to their customers.  Some of the threats are
   outlined in <a href="./rfc2196#section-3.2">section&nbsp;3.2 of [RFC2196]</a>.  This document enumerates
   features which are required to implement many of the policies and
   procedures suggested by [<a href="./rfc2196" title="&quot;Site Security Handbook&quot;">RFC2196</a>] in the context of the
   infrastructure of large IP-based networks.  Also see [<a href="./rfc3013" title="&quot;Recommended Internet Service Provider Security Services and Procedures&quot;">RFC3013</a>].

<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>.  Scope</span>

   The scope of these requirements is intended to cover the managed
   infrastructure of large ISP IP networks (e.g., routers and switches).
   Certain groups (or "profiles", see below) apply only in specific
   situations (e.g., edge-only).

   The following are explicitly out of scope:

   o  general purpose hosts that do not transit traffic including
      infrastructure hosts such as name/time/log/AAA servers, etc.,

   o  unmanaged devices,

   o  customer managed devices (e.g., firewalls, Intrusion Detection
      System, dedicated VPN devices, etc.),

   o  SOHO (Small Office, Home Office) devices (e.g., personal
      firewalls, Wireless Access Points, Cable Modems, etc.),

   o  confidentiality of customer data,

   o  integrity of customer data,

   o  physical security.

   This means that while the requirements in the minimum profile (and
   others) may apply, additional requirements have not be added to
   account for their unique needs.



<span class="grey">Jones                        Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


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

<span class="h3"><a class="selflink" id="section-1.4" href="#section-1.4">1.4</a>.  Definition of a Secure Network</span>

   For the purposes of this document, a secure network is one in which:

   o  The network keeps passing legitimate customer traffic
      (availability).

   o  Traffic goes where it is supposed to go, and only where it is
      supposed to go (availability, confidentiality).

   o  The network elements remain manageable (availability).

   o  Only authorized users can manage network elements (authorization).

   o  There is a record of all security related events (accountability).

   o  The network operator has the necessary tools to detect and respond
      to illegitimate traffic.

<span class="h3"><a class="selflink" id="section-1.5" href="#section-1.5">1.5</a>.  Intended Audience</span>

   There are two intended audiences: the network operator who selects,
   purchases, and operates IP network equipment, and the vendors who
   create them.

<span class="h3"><a class="selflink" id="section-1.6" href="#section-1.6">1.6</a>.  Format</span>

   The individual requirements are listed in the three sections below.

   o  <a href="#section-2">Section 2</a> lists functional requirements.

   o  <a href="#section-3">Section 3</a> lists documentation requirements.

   o  <a href="#section-4">Section 4</a> lists assurance requirements.

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

   Each requirement has the following subsections:

   o  Requirement (what)

   o  Justification (why)

   o  Examples (how)



<span class="grey">Jones                        Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   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.  See
   [<a href="./rfc3631" title="&quot;Security Mechanisms for the Internet&quot;">RFC3631</a>].  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, <a href="#appendix-A">Appendix A</a> defines several
   requirement "profiles" for different types of devices.  Profiles are
   concise lists of requirements that apply to certain classes of
   devices.  The profiles in this document should be reviewed to
   determine if they are appropriate to the local environment.

<span class="h3"><a class="selflink" id="section-1.7" href="#section-1.7">1.7</a>.  Intended Use</span>

   It is anticipated that the requirements in this document will be used
   for the following purposes:

   o  as a checklist when evaluating networked products,

   o  to create profiles of different subsets of the requirements which
      describe the needs of different devices, organizations, and
      operating environments,

   o  to assist operators in clearly communicating their security
      requirements,

   o  as high level guidance for the creation of detailed test plans.

<span class="h3"><a class="selflink" id="section-1.8" href="#section-1.8">1.8</a>.  Definitions</span>

   <a href="./rfc2119">RFC 2119</a> Keywords

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
      in this document are to be interpreted as described in [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].






<span class="grey">Jones                        Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


      The use of the <a href="./rfc2119">RFC 2119</a> keywords is an attempt, by the editor, to
      assign the correct requirement levels ("MUST", "SHOULD",
      "MAY"...).  It must be noted that different organizations,
      operational environments, policies and legal environments will
      generate different requirement levels.  Operators and vendors
      should carefully consider the individual requirements listed here
      in their own context.  One size does not fit all.

   Bogon.

      A "Bogon" (plural: "bogons") is a packet with an IP source address
      in an address block not yet allocated by IANA or the Regional
      Internet Registries (ARIN, RIPE, APNIC...) as well as all
      addresses reserved for private or special use by RFCs.  See
      [<a href="./rfc3330" title="&quot;Special-Use IPv4 Addresses&quot;">RFC3330</a>] and [<a href="./rfc1918" title="&quot;Address Allocation for Private Internets&quot;">RFC1918</a>].

   CLI.

      Several requirements refer to a Command Line Interface (CLI).
      While this refers at present to a classic text oriented command
      interface, it is not intended to preclude other mechanisms which
      may meet all the requirements that reference "CLI".

   Console.

      Several requirements refer to a "Console".  The model for this is
      the classic RS232 serial port which has, for the past 30 or more
      years, provided a simple, stable, reliable, well-understood and
      nearly ubiquitous management interface to network devices.  Again,
      these requirements are intended primarily to codify the benefits
      provided by that venerable interface, not to preclude other
      mechanisms that meet all the same requirements.

   Filter.

      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 <a href="#section-2.8">Section 2.8</a>.

   In-Band management.

      "In-Band management" is defined as any management done over the
      same channels and interfaces used for user/customer data.
      Examples would include using SSH for management via customer or
      Internet facing network interfaces.






<span class="grey">Jones                        Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   High Resolution Time.

      "High resolution time" is defined in this document as "time having
      a resolution greater than one second" (e.g., milliseconds).

   IP.

      Unless otherwise indicated, "IP" refers to IPv4.

   Management.

      This document uses a broad definition of the term "management".
      In this document, "management" refers to any authorized
      interaction with the device intended to change its operational
      state or configuration.  Data/Forwarding plane functions (e.g.,
      the transit of customer traffic) are not considered management.
      Control plane functions such as routing, signaling and link
      management protocols and management plane functions such as remote
      access, configuration and authentication are considered to be
      management.

   Martian.

      Per [<a href="./rfc1208" title="&quot;Glossary of networking terms&quot;">RFC1208</a>] "Martian: Humorous term applied to packets that turn
      up unexpectedly on the wrong network because of bogus routing
      entries.  Also used as a name for a packet which has an altogether
      bogus (non-registered or ill-formed) Internet address."  For the
      purposes of this document Martians are defined as "packets having
      a source address that, by application of the current forwarding
      tables, would not have its return traffic routed back to the
      sender."  "Spoofed packets" are a common source of martians.

      Note that in some cases, the traffic may be asymmetric, and a
      simple forwarding table check might produce false positives.  See
      [<a href="./rfc3704" title="&quot;Ingress Filtering for Multihomed Networks&quot;">RFC3704</a>]

   Out-of-Band (OoB) management.

      "Out-of-Band management" is defined as any management done over
      channels and interfaces that are separate from those used for
      user/customer data.  Examples would include a serial console
      interface or a network interface connected to a dedicated
      management network that is not used to carry customer traffic.








<span class="grey">Jones                        Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Open Review.

      "Open review" refers to processes designed to generate public
      discussion and review of proposed technical solutions such as data
      communications protocols and cryptographic algorithms with the
      goals of improving and building confidence in the final solutions.

      For the purposes of this document "open review" is defined by
      [<a href="./rfc2026" title="&quot;The Internet Standards Process -- Revision 3&quot;">RFC2026</a>].  All standards track documents are considered to have
      been through an open review process.

      It should be noted that organizations may have local requirements
      that define what they view as acceptable "open review".  For
      example, they may be required to adhere to certain national or
      international standards.  Such modifications of the definition of
      the term "open review", while important, are considered local
      issues that should be discussed between the organization and the
      vendor.

      It should also be noted that <a href="./rfc2026#section-7">section&nbsp;7 of [RFC2026]</a> permits
      standards track documents to incorporate other "external standards
      and specifications".

   Service.

      A number of requirements refer to "services".  For the purposes of
      this document a "service" is defined as "any process or protocol
      running in the control or management planes to which non-transit
      packets may be delivered".  Examples might include an SSH server,
      a BGP process or an NTP server.  It would also include the
      transport, network and link layer protocols since, for example, a
      TCP packet addressed to a port on which no service is listening
      will be "delivered" to the IP stack, and possibly result in an
      ICMP message being sent back.

   Secure Channel.

      A "secure channel" is a mechanism that ensures end-to-end
      integrity and confidentiality of communications.  Examples include
      TLS [<a href="./rfc2246" title="&quot;The TLS Protocol Version 1.0&quot;">RFC2246</a>] and IPsec [<a href="./rfc2401" title="&quot;Security Architecture for the Internet Protocol&quot;">RFC2401</a>].  Connecting a terminal to a
      console port using physically secure, shielded cable would provide
      confidentiality but possibly not integrity.

   Single-Homed Network.

      A "single-homed network" is defined as one for which

         *  There is only one upstream connection



<span class="grey">Jones                        Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


         *  Routing is symmetric.

      See [<a href="./rfc3704" title="&quot;Ingress Filtering for Multihomed Networks&quot;">RFC3704</a>] for a discussion of related issues and mechanisms
      for multihomed networks.

   Spoofed Packet.

      A "spoofed packet" is defined as a packet that has a source
      address that does not correspond to any address assigned to the
      system which sent the packet.  Spoofed packets are often "bogons"
      or "martians".

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Functional Requirements</span>

   The requirements in this section are intended to list testable,
   functional requirements that are needed to operate devices securely.

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Device Management Requirements</span>

<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>.  Support Secure Channels For Management</span>

   Requirement.

      The device MUST provide mechanisms to ensure end-to-end integrity
      and confidentiality for all network traffic and protocols used to
      support management functions.  This MUST include at least
      protocols used for configuration, monitoring, configuration backup
      and restore, logging, time synchronization, authentication, and
      routing.

   Justification.

      Integrity protection is required to ensure that unauthorized users
      cannot manage the device or alter log data or the results of
      management commands.  Confidentiality is required so that
      unauthorized users cannot view sensitive information, such as
      keys, passwords, or the identity of users.

   Examples.

      See [<a href="./rfc3631" title="&quot;Security Mechanisms for the Internet&quot;">RFC3631</a>] for a current list of mechanisms that can be used to
      support secure management.

      Later sections list requirements for supporting in-band management
      (<a href="#section-2.2">Section 2.2</a>)  and out-of-band management (<a href="#section-2.3">Section 2.3</a>) as well as
      trade-offs that must be weighed in considering which is
      appropriate to a given situation.




<span class="grey">Jones                        Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Warnings.

      None.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  In-Band Management Requirements</span>

   This section lists security requirements that support secure in-band
   management.  In-band  management has the advantage of lower cost (no
   extra interfaces or lines), but has significant security
   disadvantages:

   o  Saturation of customer lines or interfaces can make the device
      unmanageable unless out-of-band management resources have been
      reserved.

   o  Since public interfaces/channels are used, it is possible for
      attackers to directly address and reach the device and to attempt
      management functions.

   o  In-band management traffic on public interfaces may be
      intercepted, however this would typically require a significant
      compromise in the routing system.

   o  Public interfaces used for in-band management may become
      unavailable due to bugs (e.g., buffer overflows being exploited)
      while out-of-band interfaces (such as a serial console device)
      remain available.

   There are many situations where in-band management makes sense, is
   used, and/or is the only option.  The following requirements are
   meant to provide means of securing in-band management traffic.

<span class="h4"><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a>.  Use Cryptographic Algorithms Subject To Open Review</span>

   Requirement.

      If cryptography is used to provide secure management functions,
      then there MUST be an option to use algorithms that are subject to
      "open review" as defined in <a href="#section-1.8">Section 1.8</a> to provide these
      functions.  These SHOULD be used by default.  The device MAY
      optionally support algorithms that are not open to review.

   Justification.

      Cryptographic algorithms that have not been subjected to
      widespread, extended public/peer review are more likely to have
      undiscovered weaknesses or flaws than open standards and publicly
      reviewed algorithms.  Network operators may have need or desire to



<span class="grey">Jones                        Informational                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


      use non-open cryptographic algorithms.  They should be allowed to
      evaluate the trade-offs and make an informed choice between open
      and non-open cryptography.  See [<a href="#ref-Schneier" title="&quot;Applied Cryptography, 2nd Ed., Publisher John Wiley &amp; Sons, Inc.&quot;">Schneier</a>] for further discussion.

   Examples.

      The following are some algorithms that satisfy the requirement at
      the time of writing: AES [<a href="#ref-FIPS.197" title="&quot;Advanced Encryption Standard&quot;">FIPS.197</a>], and 3DES [<a href="#ref-ANSI.X9-52.1998" title="&quot;Triple Data Encryption Algorithm Modes of Operation&quot;">ANSI.X9-52.1998</a>]
      for applications requiring symmetric encryption; RSA [<a href="./rfc3447" title="&quot;Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1&quot;">RFC3447</a>] and
      Diffie-Hellman [<a href="#ref-PKCS.3.1993" title="&quot;Diffie-Hellman Key-Agreement Standard, Version 1.4&quot;">PKCS.3.1993</a>], [<a href="./rfc2631" title="&quot;Diffie-Hellman Key Agreement Method&quot;">RFC2631</a>] for applications requiring
      key exchange; HMAC [<a href="./rfc2401" title="&quot;Security Architecture for the Internet Protocol&quot;">RFC2401</a>] with SHA-1 [<a href="./rfc3174" title="&quot;US Secure Hash Algorithm 1 (SHA1)&quot;">RFC3174</a>] for applications
      requiring message verification.

   Warnings.

      This list is not exhaustive.  Other strong, well-reviewed
      algorithms may meet the requirement.  The dynamic nature of the
      field means that what is good enough today may not be in the
      future.

      Open review is necessary but not sufficient.  The strength of the
      algorithm and key length must also be considered.  For example,
      56-bit DES meets the open review requirement, but is today
      considered too weak and is therefore not recommended.

<span class="h4"><a class="selflink" id="section-2.2.2" href="#section-2.2.2">2.2.2</a>.  Use Strong Cryptography</span>

   Requirement.

      If cryptography is used to meet the secure management channel
      requirements, then the key lengths and algorithms SHOULD be
      "strong".

   Justification.

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

   Examples.

      The following algorithms satisfy the requirement at the time of
      writing: AES [<a href="#ref-FIPS.197" title="&quot;Advanced Encryption Standard&quot;">FIPS.197</a>], and 3DES [<a href="#ref-ANSI.X9-52.1998" title="&quot;Triple Data Encryption Algorithm Modes of Operation&quot;">ANSI.X9-52.1998</a>] for
      applications requiring symmetric encryption; RSA [<a href="./rfc3447" title="&quot;Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1&quot;">RFC3447</a>] and
      Diffie-Hellman [<a href="#ref-PKCS.3.1993" title="&quot;Diffie-Hellman Key-Agreement Standard, Version 1.4&quot;">PKCS.3.1993</a>], [<a href="./rfc2631" title="&quot;Diffie-Hellman Key Agreement Method&quot;">RFC2631</a>] for applications requiring
      key exchange; HMAC [<a href="./rfc2401" title="&quot;Security Architecture for the Internet Protocol&quot;">RFC2401</a>] with SHA-1 [<a href="./rfc3174" title="&quot;US Secure Hash Algorithm 1 (SHA1)&quot;">RFC3174</a>] for applications
      requiring message verification.





<span class="grey">Jones                        Informational                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


      Note that for *new protocols* [<a href="./rfc3631" title="&quot;Security Mechanisms for the Internet&quot;">RFC3631</a>]  says the following:
      "Simple keyed hashes based on MD5 [<a href="./rfc1321" title="&quot;The MD5 Message-Digest Algorithm&quot;">RFC1321</a>], such as that used in
      the BGP session security mechanism [<a href="./rfc2385" title="&quot;Protection of BGP Sessions via the TCP MD5 Signature Option&quot;">RFC2385</a>], are especially to be
      avoided in new protocols, given the hints of weakness in MD5."
      While use of such hashes in deployed products and protocols is
      preferable to a complete lack of integrity and authentication
      checks, this document concurs with the recommendation that new
      products and protocols strongly consider alternatives.

   Warnings.

      This list is not exhaustive.  Other strong, well-reviewed
      algorithms may meet the requirement.  The dynamic nature of the
      field means that what is good enough today may not be in the
      future.

      Strength is relative.  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 cryptography and
      the strength of cryptography used.

      This document explicitly does not attempt to make any
      authoritative statement about what key lengths constitute "strong"
      cryptography.  See  [<a href="./rfc3562" title="&quot;Key Management Considerations for the TCP MD5 Signature Option&quot;">RFC3562</a>] and [<a href="./rfc3766" title="&quot;Determining Strengths For Public Keys Used For Exchanging Symmetric Keys&quot;">RFC3766</a>] for help in
      determining appropriate key lengths.  Also see [<a href="#ref-Schneier" title="&quot;Applied Cryptography, 2nd Ed., Publisher John Wiley &amp; Sons, Inc.&quot;">Schneier</a>] chapter
      7 for a discussion of key lengths.

<span class="h4"><a class="selflink" id="section-2.2.3" href="#section-2.2.3">2.2.3</a>.  Use Protocols Subject To Open Review For Management</span>

   Requirement.

      If cryptography is used to provide secure management channels,
      then its use MUST be supported in protocols that are subject to
      "open review" as defined in <a href="#section-1.8">Section 1.8</a>.  These SHOULD be used by
      default.  The device MAY optionally support the use of
      cryptography in protocols that are not open to review.










<span class="grey">Jones                        Informational                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Justification.

      Protocols that have not been subjected to widespread, extended
      public/peer review are more likely to have undiscovered weaknesses
      or flaws than open standards and publicly reviewed protocols
      Network operators may have need or desire to use non-open
      protocols They should be allowed to evaluate the trade-offs and
      make an informed choice between open and non-open protocols.

   Examples.

      See TLS [<a href="./rfc2246" title="&quot;The TLS Protocol Version 1.0&quot;">RFC2246</a>] and IPsec [<a href="./rfc2401" title="&quot;Security Architecture for the Internet Protocol&quot;">RFC2401</a>].

   Warnings.

      Note that open review is necessary but may not be sufficient.  It
      is perfectly possible for an openly reviewed protocol to misuse
      (or not use) cryptography.

<span class="h4"><a class="selflink" id="section-2.2.4" href="#section-2.2.4">2.2.4</a>.  Allow Selection of Cryptographic Parameters</span>

   Requirement.

      The device SHOULD allow the operator to select cryptographic
      parameters.  This SHOULD include key lengths and algorithms.

   Justification.

      Cryptography using certain algorithms and key lengths may be
      considered "strong" at one point in time, but "weak" at another.
      The constant increase in compute power continually reduces the
      time needed to break cryptography of a certain strength.
      Weaknesses may be discovered in algorithms.  The ability to select
      a different algorithm is a useful tool for maintaining security in
      the face of such discoveries.

   Examples.

      56-bit DES was once considered secure.  In 1998 it was cracked by
      custom built machine in under 3 days.  The ability to select
      algorithms and key lengths would give the operator options
      (different algorithms, longer keys) in the face of such
      developments.

   Warnings.

      None.




<span class="grey">Jones                        Informational                     [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h4"><a class="selflink" id="section-2.2.5" href="#section-2.2.5">2.2.5</a>.  Management Functions Should Have Increased Priority</span>

   Requirement.

      Management functions SHOULD be processed at higher priority than
      non-management traffic.  This SHOULD include ingress, egress,
      internal transmission, and processing.  This SHOULD include at
      least protocols used for configuration, monitoring, configuration
      backup, logging, time synchronization, authentication, and
      routing.

   Justification.

      Certain attacks (and normal operation) can cause resource
      saturation such as link congestion, memory exhaustion or CPU
      overload.  In these cases it is important that management
      functions be prioritized to ensure that operators have the tools
      needed to recover from the attack.

   Examples.

      Imagine a service provider with 1,000,000 DSL subscribers, most of
      whom have no firewall protection.  Imagine that a large portion of
      these subscribers machines were infected with a new worm that
      enabled them to be used in coordinated fashion as part of large
      denial of service attack that involved flooding.  It is entirely
      possible that without prioritization such an attack would cause
      link congestion resulting in routing adjacencies being lost.  A
      DoS attack against hosts has just become a DoS attack against the
      network.

   Warnings.

      Prioritization is not a panacea.  Routing update packets may not
      make it across a saturated link.  This requirement simply says
      that the device should prioritize management functions within its
      scope of control (e.g., ingress, egress, internal transit,
      processing).  To the extent that this is done across an entire
      network, the overall effect will be to ensure that the network
      remains manageable.

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Out-of-Band (OoB) Management Requirements</span>

   See <a href="#section-2.2">Section 2.2</a> for a discussion of the advantages and disadvantages
   of In-band vs. Out-of-Band management.






<span class="grey">Jones                        Informational                     [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   These requirements assume two different possible Out-of-Band
   topologies:

   o  serial line (or equivalent) console connections using a CLI,

   o  network interfaces connected to a separate network dedicated to
      management.

   The following assumptions are made about out-of-band management:

   o  The out-of-band management network is secure.

   o  Communications beyond the management interface (e.g., console
      port, management network interface) is secure.

   o  There is no need for encryption of communication on out-of-band
      management interfaces, (e.g., on a serial connection between a
      terminal server and a device's console port).

   o  Security measures are in place to prevent unauthorized physical
      access.

   Even if these assumptions hold it would be wise, as an application of
   defense-in-depth, to apply the in-band requirements (e.g.,
   encryption) to out-of-band interfaces.

<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a>.  Support a 'Console' Interface</span>

   Requirement.

      The device MUST support complete configuration and management via
      a 'console' interface that functions independently from the
      forwarding and IP control planes.

   Justification.

      There are times when it is operationally necessary to be able to
      immediately and easily access a device for management or
      configuration, even when the network is unavailable, routing and
      network interfaces are incorrectly configured, the IP stack and/or
      operating system may not be working (or may be vulnerable to
      recently discovered exploits that make their use impossible/
      inadvisable), or when high bandwidth paths to the device are
      unavailable.  In such situations, a console interface can provide
      a way to manage and configure the device.






<span class="grey">Jones                        Informational                     [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Examples.

      An RS232 (EIA232) interface that provides the capability to load
      new versions of the system software and to perform configuration
      via a command line interface.  RS232 interfaces are ubiquitous and
      well understood.

      A simple embedded device that provides management and
      configuration access via an Ethernet or USB interface.

      As of this writing, RS232 is still strongly recommended as it
      provides the following benefits:

      *  Simplicity.  RS232 is far simpler than the alternatives.  It is
         simply a hardware specification.  By contrast an Ethernet based
         solution might require an ethernet interface, an operating
         system, an IP stack and an HTTP server all to be functioning
         and properly configured.

      *  Proven.  RS232 has more than 30 years of use.

      *  Well-Understood.  Operators have a great deal of experience
         with RS232.

      *  Availability.  It works even in the presence of network
         failure.

      *  Ubiquity.  It is very widely deployed in mid to high end
         network infrastructure.

      *  Low-Cost.  The cost of adding a RS232 port to a device is
         small.

      *  CLI-Friendly.  An RS232 interface and a CLI are sufficient in
         most cases to manage a device.  No additional software is
         required.

      *  Integrated.  Operators have many solutions (terminal servers,
         etc.) currently deployed to support management via RS232.

         While other interfaces may be supplied, the properties listed
         above should be considered.  Interfaces not having these
         properties may present challenges in terms of ease of use,
         integration or adoption.  Problems in any of these areas could
         have negative security impacts, particularly in situations
         where the console must be used to quickly respond to incidents.





<span class="grey">Jones                        Informational                     [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Warnings.

      It is common practice is to connect RS232 ports to terminal
      servers that permit networked access for convenience.  This
      increases the potential security exposure of mechanisms available
      only via RS232 ports.  For example, a password recovery mechanism
      that is available only via RS232 might give a remote hacker to
      completely reconfigure a router.  While operational procedures are
      beyond the scope of this document, it is important to note here
      that strong attention should be given to policies, procedures,
      access mechanisms and physical security governing access to
      console ports.

<span class="h4"><a class="selflink" id="section-2.3.2" href="#section-2.3.2">2.3.2</a>.  'Console' Communication Profile Must Support Reset</span>

   Requirement.

      There MUST be a method defined and published for returning the
      console communication parameters to their default settings.  This
      method must not require the current settings to be known.

   Justification.

      Having to guess at communications settings can waste time.  In a
      crisis situation, the operator may need to get on the console of a
      device quickly.

   Examples.

      One method might be to send a break on a serial line.

   Warnings.

      None.

<span class="h4"><a class="selflink" id="section-2.3.3" href="#section-2.3.3">2.3.3</a>.  'Console' Requires Minimal Functionality of Attached Devices</span>

   Requirement.

      The use of the 'console' interface MUST NOT require proprietary
      devices, protocol extensions or specific client software.










<span class="grey">Jones                        Informational                     [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Justification.

      The purpose of having the console interface is to have a
      management interface that can be made to work quickly at all
      times.  Requiring complex or nonstandard behavior on the part of
      attached devices reduces the likelihood that the console will work
      without hassles.

   Examples.

      If the console is supplied via an RS232 interface, then it should
      function with an attached device that only implements a "dumb"
      terminal.  Support of "advanced" terminal features/types should be
      optional.

   Warnings.

      None.

<span class="h4"><a class="selflink" id="section-2.3.4" href="#section-2.3.4">2.3.4</a>.  'Console' Supports Fall-back Authentication</span>

   Requirement.

      The 'console' SHOULD support an authentication mechanism which
      does not require functional IP or depend on external services.
      This authentication mechanism MAY be disabled until a failure of
      other preferred mechanisms is detected.

   Justification.

      It does little good to have a console interface on a device if you
      cannot get into the device with it when the network is not
      working.

   Examples.

      Some devices which use TACACS or RADIUS for authentication will
      fall back to a local account if the TACACS or RADIUS server does
      not reply to an authentication request.

   Warnings.

      This requirement represents a trade-off between being able to
      manage the device (functionality) and security.  There are many
      ways to implement this which would provide reduced security for
      the device, (e.g., a back door for unauthorized access).  Local
      policy should be consulted to determine if "fail open" or "fail




<span class="grey">Jones                        Informational                     [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


      closed" is the correct stance.  The implications of "fail closed"
      (e.g., not being able to manage a device) should be fully
      considered.

      If the fall-back mechanism is disabled, it is important that the
      failure of IP based authentication mechanism be reliably detected
      and the fall-back mechanism automatically enabled...otherwise the
      operator may be left with no means to authenticate.

<span class="h4"><a class="selflink" id="section-2.3.5" href="#section-2.3.5">2.3.5</a>.  Support Separate Management Plane IP Interfaces</span>

   Requirement.

      The device MAY provide designated network interface(s) that are
      used for management plane traffic.

   Justification.

      A separate management plane interface allows management traffic to
      be segregated from other traffic (data/forwarding plane, control
      plane).  This reduces the risk that unauthorized individuals will
      be able to observe management traffic and/or compromise the
      device.

      This requirement applies in situations where a separate OoB
      management network exists.

   Examples.

      Ethernet port dedicated to management and isolated from customer
      traffic satisfies this requirement.

   Warnings.

      The use of this type of interface depends on proper functioning of
      both the operating system and the IP stack, as well as good, known
      configuration at least on the portions of the device dedicated to
      management.

<span class="h4"><a class="selflink" id="section-2.3.6" href="#section-2.3.6">2.3.6</a>.  No Forwarding Between Management Plane And Other Interfaces</span>

   Requirement.

      If the device implements separate network interface(s) for the
      management plane per <a href="#section-2.3.5">Section 2.3.5</a> then the device MUST NOT
      forward traffic between the management plane and non-management
      plane interfaces.




<span class="grey">Jones                        Informational                     [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Justification.

      This prevents the flow, intentional or unintentional, of
      management traffic to/from places that it should not be
      originating/terminating (e.g., anything beyond the customer-facing
      interfaces).

   Examples.

      Implementing separate forwarding tables for management plane and
      non-management plane interfaces that do not propagate routes to
      each other satisfies this requirement.

   Warnings.

      None.

<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>.  Configuration and Management Interface Requirements</span>

   This section lists requirements that support secure device
   configuration and management methods.  In most cases, this currently
   involves some sort of command line interface (CLI) and configuration
   files.  It may be possible to meet these requirements with other
   mechanisms, for instance SNMP or a script-able HTML interface that
   provides full access to management and configuration functions.  In
   the future, there may be others (e.g., XML based configuration).

<span class="h4"><a class="selflink" id="section-2.4.1" href="#section-2.4.1">2.4.1</a>.  'CLI' Provides Access to All Configuration and Management</span>
<span class="h4">         Functions</span>

   Requirement.

      The Command Line Interface (CLI) or equivalent MUST allow complete
      access to all configuration and management functions.  The CLI
      MUST be supported on the console (see <a href="#section-2.3.1">Section 2.3.1</a>) and SHOULD be
      supported on all other interfaces used for management.

   Justification.

      The CLI (or equivalent) is needed to provide the ability to do
      reliable, fast, direct, local management and monitoring of a
      device.  It is particularly useful in situations where it is not
      possible to manage and monitor the device in-band via "normal"
      means (e.g., SSH or SNMP [<a href="./rfc3410" title="&quot;Introduction and Applicability Statements for Internet-Standard Management Framework&quot;">RFC3410</a>], [<a href="./rfc3411" title="&quot;An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks&quot;">RFC3411</a>]) that depend on
      functional networking.  Such situations often occur during
      security incidents such as bandwidth-based denial of service
      attacks.




<span class="grey">Jones                        Informational                     [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Examples.

      Examples of configuration include setting interface addresses,
      defining and applying filters, configuring logging and
      authentication, etc.  Examples of management functions include
      displaying dynamic state information such as CPU load, memory
      utilization, packet processing statistics, etc.

   Warnings.

      None.

<span class="h4"><a class="selflink" id="section-2.4.2" href="#section-2.4.2">2.4.2</a>.  'CLI' Supports Scripting of Configuration</span>

   Requirement.

      The CLI or equivalent MUST support external scripting of
      configuration functions.  This CLI SHOULD support the same command
      set and syntax as that in <a href="#section-2.4.1">Section 2.4.1</a>.

   Justification.

      During the handling of security incidents, it is often necessary
      to quickly make configuration changes on large numbers of devices.
      Doing so manually is error prone and slow.  Vendor supplied
      management solutions do not always foresee or address the type or
      scale of solutions that are required.  The ability to script
      provides a solution to these problems.

   Examples.

      Example uses of scripting include: tracking an attack across a
      large network, updating authentication parameters, updating
      logging parameters, updating filters, configuration fetching/
      auditing, etc.  Some languages that are currently used for
      scripting include expect, Perl and TCL.

   Warnings.

      Some properties of the command language that enhance the ability
      to script are: simplicity, regularity and consistency.  Some
      implementations that would make scripting difficult or impossible
      include: "text menu" style interfaces (e.g., "curses" on UNIX) or
      a hard-coded GUI interfaces (e.g., a native Windows or Macintosh
      GUI application) that communicate using a proprietary or
      undocumented protocol not based on a CLI.





<span class="grey">Jones                        Informational                     [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h4"><a class="selflink" id="section-2.4.3" href="#section-2.4.3">2.4.3</a>.  'CLI' Supports Management Over 'Slow' Links</span>

   Requirement.

      The device MUST support a command line interface (CLI) or
      equivalent mechanism that works over low bandwidth connections.

   Justification.

   There are situations where high bandwidth for management is not
   available, for example when in-band connections are overloaded during
   an attack or when low-bandwidth, out-of-band connections such as
   modems must be used.  It is often under these conditions that it is
   most crucial to be able to perform management and configuration
   functions.

   Examples.

      The network is down.  The network engineer just disabled routing
      by mistake on the sole gateway router in a remote unmanned data
      center.  The only access to the device is over a modem connected
      to a console port.  The data center customers are starting to call
      the support line.  The GUI management interface is redrawing the
      screen multiple times...slowly... at 9600bps.

      One mechanism that supports operation over slow links is the
      ability to apply filters to the output of CLI commands which have
      potentially large output.  This may be implemented with something
      similar to the UNIX pipe facility and "grep" command.

      For example,

         cat largefile.txt | grep interesting-string

      Another is the ability to "page" through large command output,
      e.g., the UNIX "more" command:

      For example,

         cat largefile.txt | more

   Warnings.

      One consequence of this requirement may be that requiring a GUI
      interface for management is unacceptable unless it can be shown to
      work acceptably over slow links.





<span class="grey">Jones                        Informational                     [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h4"><a class="selflink" id="section-2.4.4" href="#section-2.4.4">2.4.4</a>.  'CLI' Supports Idle Session Timeout</span>

   Requirement.

      The command line interface (CLI) or equivalent mechanism MUST
      support a configurable idle timeout value.

   Justification.

      Network administrators go to lunch.  They leave themselves logged
      in with administrative privileges.  They forget to use screen-
      savers with password protection.  They do this while at
      conferences and in other public places.  This behavior presents
      opportunity for unauthorized access.  Idle timeouts reduce the
      window of exposure.

   Examples.

      The CLI may provide a configuration command that allows an idle
      timeout to be set.  If the operator does not enter commands for
      that amount of time, the login session will be automatically
      terminated.

   Warnings.

      None.

<span class="h4"><a class="selflink" id="section-2.4.5" href="#section-2.4.5">2.4.5</a>.  Support Software Installation</span>

   Requirement.

      The device MUST provide a means to install new software versions.
      It MUST be possible to install new software while the device is
      disconnected from all public IP networks.  This MUST NOT rely on
      previous installation and/or configuration.  While new software
      MAY be loaded from writable media (disk, flash, etc.), the
      capability to load new software MUST depend only on non-writable
      media (ROM, etc.).  The installation procedures SHOULD support
      mechanisms to ensure reliability and integrity of data transfers.

   Justification.

   *  Vulnerabilities are often discovered in the base software
      (operating systems, etc.) shipped by vendors.  Often mitigation of
      the risk presented by these vulnerabilities can only be
      accomplished by updates to the vendor supplied software (e.g., bug





<span class="grey">Jones                        Informational                     [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


      fixes, new versions of code, etc.).  Without a mechanism to load
      new vendor supplied code, it may not be possible to mitigate the
      risk posed by these vulnerabilities.

   *  It is also conceivable that malicious behavior on the part of
      hackers or unintentional behaviors on the part of operators could
      cause software on devices to be corrupted or erased.  In these
      situations, it is necessary to have a means to (re)load software
      onto the device to restore correct functioning.

   *  It is important to be able to load new software while disconnected
      from all public IP networks because the device may be vulnerable
      to old attacks before the update is complete.

   *  One has to assume that hackers, operators, etc. may erase or
      corrupt all writable media (disks, flash, etc.).  In such
      situations, it is necessary to be able to recover starting with
      only non-writable media (e.g., CD-ROM, a true ROM-based monitor).

   *  System images may be corrupted in transit (from vendor to
      customer, or during the loading process) or in storage (bit rot,
      defective media, etc.).  Failure to reliably load a new image, for
      example after a hacker deletes or corrupts the installed image,
      could result in extended loss of availability.

   Examples.

      The device could support booting into a simple ROM-based monitor
      that supported a set of commands sufficient to load new operating
      system code and configuration data from other devices.  The
      operating system and configuration might be loaded from:

   RS232. The device could support uploading new code via an RS232
      console port.

   CD-ROM. The device could support installing new code from a
      locally attached CD-ROM drive.

   NETWORK. The device could support installing new code via a
      network interface, assuming that (a) it is disconnected from all
      public networks and (b) the device can boot an OS and IP stack
      from some read-only media with sufficient capabilities to load new
      code  from the network.








<span class="grey">Jones                        Informational                     [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   FLASH. The device could support booting from flash memory cards.

      Simple mechanisms currently in use to protect the integrity of
      system images and data transfer include image checksums and simple
      serial file transfer protocols such as XMODEM and Kermit.

   Warnings.

      None.

<span class="h4"><a class="selflink" id="section-2.4.6" href="#section-2.4.6">2.4.6</a>.  Support Remote Configuration Backup</span>

   Requirement.

      The device MUST provide a means to store the system configuration
      to 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.  Stored versions of the
      configuration MAY be compressed using an algorithm which is
      subject to open review, as long as the fact is clearly identified
      and the compression can be disabled.  Sensitive information such
      as passwords that could be used to compromise the security of the
      device MAY be excluded from the saved configuration.

   Justification.

      Archived configurations are essential to enable auditing and
      recovery.

   Examples.

      Possible implementations include SCP, SFTP or FTP over a secure
      channel.  See <a href="#section-2.1.1">Section 2.1.1</a> 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.

<span class="h4"><a class="selflink" id="section-2.4.7" href="#section-2.4.7">2.4.7</a>.  Support Remote Configuration Restore</span>

   Requirement.

      The device MUST provide a means to restore a configuration that
      was saved as described in <a href="#section-2.4.6">Section 2.4.6</a>.  The system MUST be
      restored to its operational state at the time the configuration
      was saved.



<span class="grey">Jones                        Informational                     [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Justification.

      Restoration of archived configurations allows quick restoration of
      service following an outage (security related as well as from
      other causes).

   Examples.

      Configurations may be restored using SCP, SFTP or FTP over a
      secure channel.  See <a href="#section-2.1.1">Section 2.1.1</a> 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.

      Note that if passwords or other sensitive information are excluded
      from the saved copy of the configuration, as allowed by <a href="#section-2.4.6">Section</a>
      <a href="#section-2.4.6">2.4.6</a>, then the restore may not be complete.  The operator may
      have to set new passwords or supply other information that was not
      saved.

<span class="h4"><a class="selflink" id="section-2.4.8" href="#section-2.4.8">2.4.8</a>.  Support Text Configuration Files</span>

   Requirement.

      The device MUST support display, backup and restore of system
      configuration in a simple well defined textual format.  The
      configuration MUST also be viewable as text on the device itself.
      It MUST NOT be necessary to use a proprietary program to view the
      configuration.

   Justification.

      Simple, well-defined textual configurations facilitate human
      understanding of the operational state of the device, enable off-
      line audits, and facilitate automation.  Requiring the use of a
      proprietary program to access the configuration inhibits these
      goals.

   Examples.

      A 7-bit ASCII configuration file that shows the current settings
      of the various configuration options would satisfy the
      requirement, as would a Unicode configuration or any other
      "textual" representation.  A structured binary format intended
      only for consumption by programs would not be acceptable.



<span class="grey">Jones                        Informational                     [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   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.

      "Well defined" and "textual" are open to interpretation.  Clearly
      an ASCII configuration file with a regular, documented command
      oriented-syntax would meet the definition.  These are currently in
      wide use.  Future options, such as XML based configuration may
      meet the requirement.  Determining this will require evaluation
      against the justifications listed above.

<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>.  IP Stack Requirements</span>

<span class="h4"><a class="selflink" id="section-2.5.1" href="#section-2.5.1">2.5.1</a>.  Ability to Identify All Listening Services</span>

   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.

      *  Display the addresses to which each service is bound.

      *  Display the addresses assigned to each interface.

      *  Display any and all port(s) on which the service is listing.

      *  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 ?")









<span class="grey">Jones                        Informational                     [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Examples.

      If the device is listening for SNMP traffic from any source
      directed to the IP addresses of any of its local interfaces, then
      this requirement could be met by the provision of a command which
      displays that fact.

   Warnings.

      None.

<span class="h4"><a class="selflink" id="section-2.5.2" href="#section-2.5.2">2.5.2</a>.  Ability to Disable Any and All Services</span>

   Requirement.

      The device MUST provide a means to turn off any "services" (see
      <a href="#section-1.8">Section 1.8</a>).

   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.

      Processes that listen on TCP and UDP ports would be prime examples
      of services that it must be possible to disable.

   Warnings.

      None.

<span class="h4"><a class="selflink" id="section-2.5.3" href="#section-2.5.3">2.5.3</a>.  Ability to Control Service Bindings for Listening Services</span>

   Requirement.

      The device MUST provide a means for the user to specify the
      bindings used for all listening services.  It MUST support binding
      to any address or net-block associated with any interface local to
      the device.  This must include addresses bound to physical or
      non-physical (e.g., loopback) interfaces.

   Justification.

      It is a common practice among operators to configure "loopback"
      pseudo-interfaces to use as the source and destination of
      management traffic.  These are preferred to physical interfaces



<span class="grey">Jones                        Informational                     [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


      because they provide a stable, routable address.  Services bound
      to the addresses of physical interface addresses might become
      unreachable if the associated hardware goes down, is removed, etc.

      This requirement makes it possible to restrict access to
      management services using routing.  Management services may be
      bound only to the addresses of loopback interfaces.  The loopback
      interfaces may be addressed out of net-blocks that are only routed
      between the managed devices and the authorized management
      networks/hosts.  This has the effect of making it impossible for
      anyone to connect to (or attempt to DoS) management services from
      anywhere but the authorized management networks/hosts.

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

      If the device listens for inbound SSH connections, this
      requirement means that it should be possible to specify that the
      device will only listen to connections destined to specific
      addresses (e.g., the address of the loopback interface) or
      received on certain interfaces (e.g., an Ethernet interface
      designated as the "management" interface).  It should be possible
      in this example to configure the device such that the SSH is NOT
      listening to every address configured on the device.  Similar
      effects may be achieved with the use of global filters, sometimes
      called "receive" or "loopback" ACLs, that filter traffic destined
      for the device itself on all interfaces.

   Warnings.

      None.

<span class="h4"><a class="selflink" id="section-2.5.4" href="#section-2.5.4">2.5.4</a>.  Ability to Control Service Source Addresses</span>

   Requirement.

      The device MUST provide a means that allows the user to specify
      the source addresses used for all outbound connections or
      transmissions originating from the device.  It SHOULD 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.



<span class="grey">Jones                        Informational                     [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   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.

      The operator may allocate a distinct block of addresses from which
      all loopbacks are numbered.   NTP and syslog can be configured to
      use those loopback addresses as source, while SNMP and BGP may be
      configured to use specific physical interface addresses.  This
      would facilitate filtering based on source address as one way of
      rejecting unauthorized attempts to connect to peers/servers.

   Warnings.

      Care should be taken to assure that the addresses chosen are
      routable between the sending and receiving devices, (e.g., setting
      SSH to use a loopback address of 10.1.1.1 which is not routed
      between a router and all intended destinations could cause
      problems).

      Note that some protocols, such as SCTP [<a href="./rfc3309" title="&quot;Stream Control Transmission Protocol (SCTP) Checksum Change&quot;">RFC3309</a>], can use more
      than one IP address as the endpoint of a single connection.

      Also note that [<a href="./rfc3631" title="&quot;Security Mechanisms for the Internet&quot;">RFC3631</a>] lists address-based authentication as an
      "insecurity mechanism".  Address based authentication should be
      replaced or augmented by other mechanisms wherever possible.

<span class="h4"><a class="selflink" id="section-2.5.5" href="#section-2.5.5">2.5.5</a>.  Support Automatic Anti-spoofing for Single-Homed Networks</span>

   Requirement.

      The device MUST provide a means to designate particular interfaces
      as servicing "single-homed networks" (see <a href="#section-1.8">Section 1.8</a>) and MUST
      provide an option to automatically drop "spoofed packets" (<a href="#section-1.8">Section</a>
      <a href="#section-1.8">1.8</a>) received on such interfaces where application of the current
      forwarding table would not route return traffic back through the
      same interface.  This option MUST work in the presence of dynamic
      routing and dynamically assigned addresses.







<span class="grey">Jones                        Informational                     [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Justification.

      See sections <a href="#section-3">3</a> of [<a href="./rfc1918" title="&quot;Address Allocation for Private Internets&quot;">RFC1918</a>], sections <a href="#section-5.3.7">5.3.7</a> and <a href="#section-5.3.8">5.3.8</a> of
      [<a href="./rfc1812" title="&quot;Requirements for IP Version 4 Routers&quot;">RFC1812</a>], and [<a href="./rfc2827" title="&quot;Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing&quot;">RFC2827</a>].

   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 forwarding tables and dropped if they
      would not be forwarded back through the interface on which they
      were received.

      See [<a href="./rfc3704" title="&quot;Ingress Filtering for Multihomed Networks&quot;">RFC3704</a>].

   Warnings.

      This requirement only holds for single-homed networks.  Note that
      a simple forwarding table check is not sufficient in the more
      complex scenarios of multi-homed or multi-attached networks, i.e.,
      where the traffic may be asymmetric.  In these cases, a more
      extensive check such as Feasible Path RPF could be very useful.

<span class="h4"><a class="selflink" id="section-2.5.6" href="#section-2.5.6">2.5.6</a>.  Support Automatic Discarding Of Bogons and Martians</span>

   Requirement.

      The device MUST provide a means to automatically drop all "bogons"
      (<a href="#section-1.8">Section 1.8</a>) and "martians" (<a href="#section-1.8">Section 1.8</a>).  This option MUST work
      in the presence of dynamic routing and dynamically assigned
      addresses.

   Justification.

      These sorts of packets have little (no?) legitimate use and are
      used primarily to allow individuals and organization to avoid
      identification (and thus accountability) and appear to be most
      often used for DoS attacks, email abuse, hacking, etc.  In
      addition, transiting these packets needlessly consumes resources
      and may lead to capacity and performance problems for customers.

      See sections <a href="#section-3">3</a> of [<a href="./rfc1918" title="&quot;Address Allocation for Private Internets&quot;">RFC1918</a>], sections <a href="#section-5.3.7">5.3.7</a> and <a href="#section-5.3.8">5.3.8</a> of
      [<a href="./rfc1812" title="&quot;Requirements for IP Version 4 Routers&quot;">RFC1812</a>], and [<a href="./rfc2827" title="&quot;Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing&quot;">RFC2827</a>].





<span class="grey">Jones                        Informational                     [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Examples.

      This requirement could be satisfied by the provision of a command
      that causes the return path for packets received to be checked
      against the current forwarding tables and dropped if no viable
      return path exists.  This assumes that steps are taken to assure
      that no bogon entries are present in the forwarding tables (for
      example filtering routing updates per <a href="#section-2.7.5">Section 2.7.5</a> to reject
      advertisements of unassigned addresses).

      See [<a href="./rfc3704" title="&quot;Ingress Filtering for Multihomed Networks&quot;">RFC3704</a>].

   Warnings.

      This requirement only holds for single-homed networks.  Note that
      a simple forwarding table check is not sufficient in the more
      complex scenarios of multi-homed or multi-attached networks, i.e.,
      where the traffic may be asymmetric.  In these cases, a more
      extensive check such as Feasible Path RPF could be very useful.

<span class="h4"><a class="selflink" id="section-2.5.7" href="#section-2.5.7">2.5.7</a>.  Support Counters For Dropped Packets</span>

   Requirement.

      The device MUST provide accurate, per-interface counts of spoofed
      packets dropped in accordance with <a href="#section-2.5.5">Section 2.5.5</a> and <a href="#section-2.5.6">Section</a>
      <a href="#section-2.5.6">2.5.6</a>.

   Justification.

      Counters can help in identifying the source of spoofed traffic.

   Examples.

      An edge router may have several single-homed customers attached.
      When an attack using spoofed packets is detected, a quick check of
      counters may be able to identify which customer is attempting to
      send spoofed traffic.

   Warnings.

      None.









<span class="grey">Jones                        Informational                     [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>.  Rate Limiting Requirements</span>

<span class="h4"><a class="selflink" id="section-2.6.1" href="#section-2.6.1">2.6.1</a>.  Support Rate Limiting</span>

   Requirement.

      The device MUST provide the capability to limit the rate at which
      it will pass traffic based on protocol, source and destination IP
      address or CIDR block, source and destination port, and interface.
      Protocols MUST include at least IP, ICMP, UDP, and TCP and SHOULD
      include any protocol.

   Justification.

      This requirement provides a means of reducing or eliminating the
      impact of certain types of attacks.  Also, rate limiting has the
      advantage that in some cases it can be turned on a priori, thereby
      offering some ability to mitigate the effect of future attacks
      prior to any explicit operator reaction to the 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.








<span class="grey">Jones                        Informational                     [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h4"><a class="selflink" id="section-2.6.2" href="#section-2.6.2">2.6.2</a>.  Support Directional Application Of Rate Limiting Per Interface</span>

   Requirement.

      The device MUST provide support to rate-limit input and/or output
      separately on each interface.

   Justification.

      This level of granular control allows appropriately targeted
      controls that minimize the impact on third parties.

   Examples.

      If an ICMP flood is directed a single customer on an edge router,
      it may be appropriate to rate-limit outbound ICMP only on that
      customers interface.

   Warnings.

      None.

<span class="h4"><a class="selflink" id="section-2.6.3" href="#section-2.6.3">2.6.3</a>.  Support Rate Limiting Based on State</span>

   Requirement.

      The device MUST be able to rate limit based on all TCP control
      flag bits.  The device SHOULD support rate limiting of other
      stateful protocols where the normal processing of the protocol
      gives the device access to protocol 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.








<span class="grey">Jones                        Informational                     [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h3"><a class="selflink" id="section-2.7" href="#section-2.7">2.7</a>.  Basic Filtering Capabilities</span>

<span class="h4"><a class="selflink" id="section-2.7.1" href="#section-2.7.1">2.7.1</a>.  Ability to Filter Traffic</span>

   Requirement.

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

   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.

<span class="h4"><a class="selflink" id="section-2.7.2" href="#section-2.7.2">2.7.2</a>.  Ability to Filter Traffic TO the Device</span>

   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 allows the operator to apply filters  that protect the device
      itself from attacks and unauthorized access.

   Examples.

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






<span class="grey">Jones                        Informational                     [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Warnings.

      None.

<span class="h4"><a class="selflink" id="section-2.7.3" href="#section-2.7.3">2.7.3</a>.  Ability to Filter Traffic THROUGH the Device</span>

   Requirement.

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

   Justification.

      This permits implementation of basic policies on devices that
      carry transit traffic (routers, switches, etc.).

   Examples.

      One simple and common way to meet this requirement is to provide
      the ability to filter traffic inbound to each interface and/or
      outbound from each interface.  Ingress filtering as described in
      [<a href="./rfc2827" title="&quot;Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing&quot;">RFC2827</a>] provides one example of the use of this capability.

   Warnings.

      None.

<span class="h4"><a class="selflink" id="section-2.7.4" href="#section-2.7.4">2.7.4</a>.  Ability to Filter Without Significant Performance Degradation</span>

   Requirement.

      The device MUST provide a means to filter packets without
      significant performance degradation.  This specifically applies to
      stateless packet filtering operating on layer 3 (IP) and layer 4
      (TCP or UDP) headers, as well as normal packet forwarding
      information such as incoming and outgoing interfaces.

      The device MUST be able to apply stateless packet filters on ALL
      interfaces (up to the maximum number possible) simultaneously and
      with multiple filters per interface (e.g., inbound and outbound).

   Justification.

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




<span class="grey">Jones                        Informational                     [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   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 30Mb/sec without filtering, then
      it should be able to forward the same amount with filtering in
      place.

   Warnings.

      The definition of "significant" is subjective.  At one end of the
      spectrum it might mean "the application of filters may cause the
      box to crash".  At the other end would be a throughput loss of
      less than one percent with tens of thousands of filters applied.
      The level of performance degradation that is acceptable will have
      to be determined by the operator.

      Repeatable test data showing filter performance impact would be
      very useful in evaluating conformance with this requirement.
      Tests should include such information as packet size, packet rate,
      number of interfaces tested (source/destination), types of
      interfaces, routing table size, routing protocols in use,
      frequency of routing updates, etc.  See [<a href="#ref-bmwg-acc-bench" title="&quot;Framework for Accelerated Stress Benchmarking&quot;">bmwg-acc-bench</a>].

      This requirement does not address stateful filtering, filtering
      above layer 4 headers or other more advanced types of filtering
      that may be important in certain operational environments.

<span class="h4"><a class="selflink" id="section-2.7.5" href="#section-2.7.5">2.7.5</a>.  Support Route Filtering</span>

   Requirement.

      The device MUST provide a means to filter routing updates for all
      protocols used to exchange external routing information.

   Justification.

      See [<a href="./rfc3013" title="&quot;Recommended Internet Service Provider Security Services and Procedures&quot;">RFC3013</a>] and <a href="./rfc2196#section-3.2">section&nbsp;3.2 of [RFC2196]</a>.

   Examples.

      Operators may wish to ignore advertisements for routes to
      addresses allocated for private internets.  See eBGP.

   Warnings.

      None.




<span class="grey">Jones                        Informational                     [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h4"><a class="selflink" id="section-2.7.6" href="#section-2.7.6">2.7.6</a>.  Ability to Specify Filter Actions</span>

   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 <a href="#section-2.7.7">Section 2.7.7</a> and <a href="#section-2.9">Section 2.9</a>

   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.

      While silently dropping traffic without sending notification may
      be the correct action in security terms, consideration should be
      given to operational implications.  See [<a href="./rfc3360" title="&quot;Inappropriate TCP Resets Considered Harmful&quot;">RFC3360</a>] for
      consideration of potential problems caused by sending
      inappropriate TCP Resets.

<span class="h4"><a class="selflink" id="section-2.7.7" href="#section-2.7.7">2.7.7</a>.  Ability to Log Filter Actions</span>

   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 IP address,

      *  source and destination ports (if applicable to the protocol),



<span class="grey">Jones                        Informational                     [Page 40]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


      *  which network element received the packet (interface, MAC
         address or other layer 2 information that identifies the
         previous hop source of the packet).

         Logging of filter actions is subject to the requirements of
         <a href="#section-2.11">Section 2.11</a>.

   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.

<span class="h3"><a class="selflink" id="section-2.8" href="#section-2.8">2.8</a>.  Packet Filtering Criteria</span>

<span class="h4"><a class="selflink" id="section-2.8.1" href="#section-2.8.1">2.8.1</a>.  Ability to Filter on Protocols</span>

   Requirement.

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

   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.





<span class="grey">Jones                        Informational                     [Page 41]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-42" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h4"><a class="selflink" id="section-2.8.2" href="#section-2.8.2">2.8.2</a>.  Ability to Filter on Addresses</span>

   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.

   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 [<a href="./rfc2827" title="&quot;Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing&quot;">RFC2827</a>].

   Warnings.

      None.

<span class="h4"><a class="selflink" id="section-2.8.3" href="#section-2.8.3">2.8.3</a>.  Ability to Filter on Protocol Header Fields</span>

   Requirement.

      The filtering mechanism MUST support filtering based on the
      value(s) of any portion of the protocol headers for IP, ICMP, UDP
      and TCP.  It SHOULD support filtering of all other protocols
      supported at layer 3 and 4.  It MAY support filtering based on the
      headers of higher level protocols.  It SHOULD be possible to
      specify fields by name (e.g., "protocol = ICMP") rather than bit-
      offset/length/numeric value (e.g., 72:8 = 1).

   Justification.

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

   Examples.

      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+ACK bit clear
      or SYN bit set+ACK,FIN and RST bits clear).  Another common



<span class="grey">Jones                        Informational                     [Page 42]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-43" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


      example is the ability to control what services are allowed in/out
      of a network.  It may be desirable to only allow inbound
      connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting
      web servers.

   Warnings.

      None.

<span class="h4"><a class="selflink" id="section-2.8.4" href="#section-2.8.4">2.8.4</a>.  Ability to Filter Inbound and Outbound</span>

   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.

   Warnings.

      None.

<span class="h3"><a class="selflink" id="section-2.9" href="#section-2.9">2.9</a>.  Packet Filtering Counter Requirements</span>

<span class="h4"><a class="selflink" id="section-2.9.1" href="#section-2.9.1">2.9.1</a>.  Ability to Accurately Count Filter Hits</span>

   Requirement.

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








<span class="grey">Jones                        Informational                     [Page 43]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-44" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Justification.

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

   Examples.

      Assume, for example, that a ISP network implements anti-spoofing
      egress filters (see [<a href="./rfc2827" title="&quot;Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing&quot;">RFC2827</a>]) on interfaces of its edge routers
      that support single-homed stub networks.  Counters could enable
      the ISP to detect cases where large numbers of spoofed packets are
      being sent.  This may indicate that the customer is performing
      potentially malicious actions (possibly in violation of the ISPs
      Acceptable Use Policy), or that system(s) on the customers network
      have been "owned" by hackers and are being (mis)used to launch
      attacks.

   Warnings.

      None.

<span class="h4"><a class="selflink" id="section-2.9.2" href="#section-2.9.2">2.9.2</a>.  Ability to Display Filter Counters</span>

   Requirement.

      The device MUST provide a mechanism to display filter counters.

   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 separate internal networks.  Assume that a host on one
      of the internal networks has been compromised by a hacker and is
      sending traffic with bogus source addresses.  In such a situation,
      it might be desirable to apply ingress filters to each of the
      internal interfaces.  Once the filters are in place, the counters
      can be examined to determine the source (inbound interface) of the
      bogus packets.

   Warnings.

      None.



<span class="grey">Jones                        Informational                     [Page 44]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-45" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h4"><a class="selflink" id="section-2.9.3" href="#section-2.9.3">2.9.3</a>.  Ability to Display Filter Counters per Rule</span>

   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.

<span class="h4"><a class="selflink" id="section-2.9.4" href="#section-2.9.4">2.9.4</a>.  Ability to Display Filter Counters per Filter Application</span>

   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.

   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



<span class="grey">Jones                        Informational                     [Page 45]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-46" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


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

<span class="h4"><a class="selflink" id="section-2.9.5" href="#section-2.9.5">2.9.5</a>.  Ability to Reset Filter Counters</span>

   Requirement.

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

      For the purposes of this requirement it would be acceptable for
      the system to maintain two counters: an "absolute counter",
      C[now], and a "reset" counter, C[reset].  The absolute counter
      would maintain counts that increase monotonically until they wrap
      or overflow the counter.  The reset counter would receive a copy
      of the current value of the absolute counter when the reset
      function was issued for that counter.  Functions that display or
      retrieve the counter could then display the delta (C[now] -
      C[reset]).

   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.








<span class="grey">Jones                        Informational                     [Page 46]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-47" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h4"><a class="selflink" id="section-2.9.6" href="#section-2.9.6">2.9.6</a>.  Filter Counters Must Be Accurate</span>

   Requirement.

      Filter counters MUST be accurate.  They MUST reflect the actual
      number of matching packets since the last counter reset.  Filter
      counters MUST be capable of holding up to 2^32 - 1 values without
      overflowing and SHOULD be capable of holding up to 2^64 - 1
      values.

   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.

<span class="h3"><a class="selflink" id="section-2.10" href="#section-2.10">2.10</a>.  Other Packet Filtering Requirements</span>

<span class="h4"><a class="selflink" id="section-2.10.1" href="#section-2.10.1">2.10.1</a>.  Ability to Specify Filter Log Granularity</span>

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






<span class="grey">Jones                        Informational                     [Page 47]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-48" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Warnings.

      None.

<span class="h3"><a class="selflink" id="section-2.11" href="#section-2.11">2.11</a>.  Event Logging Requirements</span>

<span class="h4"><a class="selflink" id="section-2.11.1" href="#section-2.11.1">2.11.1</a>.  Logging Facility Uses Protocols Subject To Open Review</span>

   Requirement.

      The device MUST provide a logging facility that is based on
      protocols subject to open review.  See <a href="#section-1.8">Section 1.8</a>.  Custom or
      proprietary logging protocols MAY be implemented provided the same
      information is made available.

   Justification.

      The use of logging based on protocols subject to open review
      permits the operator to perform archival and analysis of logs
      without relying on vendor-supplied software and servers.

   Examples.

      This requirement may be satisfied by the use of one or more of
      syslog [<a href="./rfc3164" title="&quot;The BSD Syslog Protocol&quot;">RFC3164</a>], syslog with reliable delivery [<a href="./rfc3195" title="&quot;Reliable Delivery for syslog&quot;">RFC3195</a>], TACACS+
      [<a href="./rfc1492" title="&quot;An Access Control Protocol, Sometimes Called TACACS&quot;">RFC1492</a>] or RADIUS [<a href="./rfc2865" title="&quot;Remote Authentication Dial In User Service (RADIUS)&quot;">RFC2865</a>].

   Warnings.

      While [<a href="./rfc3164" title="&quot;The BSD Syslog Protocol&quot;">RFC3164</a>] meets this requirement, it has many security
      issues and by itself does not meet the requirements of <a href="#section-2.1.1">Section</a>
      <a href="#section-2.1.1">2.1.1</a>.  See the security considerations section  of [<a href="./rfc3164" title="&quot;The BSD Syslog Protocol&quot;">RFC3164</a>] for
      a list of issues.  [<a href="./rfc3195" title="&quot;Reliable Delivery for syslog&quot;">RFC3195</a>] provides solutions to most/all of
      these issues....however at the time of this writing there are few
      implementations.  Other possible solutions might be to tunnel
      syslog over a secure transport...but this often raises difficult
      key management and scalability issues.

      The current best solution seems to be the following:

      *  Implement [<a href="./rfc3164" title="&quot;The BSD Syslog Protocol&quot;">RFC3164</a>].

      *  Consider implementing [<a href="./rfc3195" title="&quot;Reliable Delivery for syslog&quot;">RFC3195</a>].








<span class="grey">Jones                        Informational                     [Page 48]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-49" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h4"><a class="selflink" id="section-2.11.2" href="#section-2.11.2">2.11.2</a>.  Logs Sent To Remote Servers</span>

   Requirement.

      The device MUST support transmission of records of security
      related events 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.
      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 one or more of:
      syslog [<a href="./rfc3164" title="&quot;The BSD Syslog Protocol&quot;">RFC3164</a>], syslog with reliable delivery [<a href="./rfc3195" title="&quot;Reliable Delivery for syslog&quot;">RFC3195</a>], TACACS+
      [<a href="./rfc1492" title="&quot;An Access Control Protocol, Sometimes Called TACACS&quot;">RFC1492</a>] or RADIUS [<a href="./rfc2865" title="&quot;Remote Authentication Dial In User Service (RADIUS)&quot;">RFC2865</a>].

   Warnings.

      Note that there may be privacy or legal considerations when
      logging/monitoring user activity.

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

<span class="h4"><a class="selflink" id="section-2.11.3" href="#section-2.11.3">2.11.3</a>.  Ability to Select Reliable Delivery</span>

   Requirement.

      It SHOULD be possible to select reliable delivery of log messages.

   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 [<a href="./rfc3195" title="&quot;Reliable Delivery for syslog&quot;">RFC3195</a>].
      Syslog-ng provides another example, although the protocol has not
      been standardized.





<span class="grey">Jones                        Informational                     [Page 49]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-50" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Warnings.

      None.

<span class="h4"><a class="selflink" id="section-2.11.4" href="#section-2.11.4">2.11.4</a>.  Ability to Log Locally</span>

   Requirement.

      It SHOULD be possible to log locally on the device itself.  Local
      logging SHOULD be written to non-volatile storage.

   Justification.

      Local logging of failed authentication attempts to non-volatile
      storage is critical.  It provides a means of detecting attacks
      where the device is isolated from its authentication interfaces
      and attacked at the console.

      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.

   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.

<span class="h4"><a class="selflink" id="section-2.11.5" href="#section-2.11.5">2.11.5</a>.  Ability to Maintain Accurate System Time</span>

   Requirement.

      The device MUST maintain accurate, "high resolution" (see
      definition in <a href="#section-1.8">Section 1.8</a>) system time.







<span class="grey">Jones                        Informational                     [Page 50]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-51" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Justification.

      Accurate time is important to the generation of reliable log data.
      Accurate time is also important to the correct operation of some
      authentication mechanisms.

   Examples.

      This requirement may be satisfied by supporting Network Time
      Protocol (NTP), Simple Network Time Protocol (SNTP), or via direct
      connection to an accurate time source.

   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).  Also note that if network time
      synchronization is used, an attacker may be able to manipulate the
      clock unless cryptographic authentication is used.

<span class="h4"><a class="selflink" id="section-2.11.6" href="#section-2.11.6">2.11.6</a>.  Display Timezone And UTC Offset</span>

   Requirement.

      All displays and logs of system time MUST include a timezone or
      offset from UTC.

   Justification.

      Knowing the timezone or UTC offset makes correlation of data and
      coordination with data in other timezones possible.

   Examples.

      Bob is in Newfoundland, Canada which is UTC -3:30.  Alice is
      somewhere in Indiana, USA.  Some parts of Indiana switch to
      daylight savings time while others do not.  A user on Bob's
      network attacks a user on Alice's network.  Both are using logs
      with local timezones and no indication of UTC offset.  Correlating
      these logs will be difficult and error prone.  Including timezone,
      or better, UTC offset, eliminates these difficulties.

   Warnings.

      None.





<span class="grey">Jones                        Informational                     [Page 51]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-52" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h4"><a class="selflink" id="section-2.11.7" href="#section-2.11.7">2.11.7</a>.  Default Timezone Should Be UTC</span>

   Requirement.

      The default timezone for display and logging SHOULD be UTC.  The
      device MAY support a mechanism to allow the operator to specify
      the display and logging of times in a timezone other than UTC.

   Justification.

      Knowing the timezone or UTC offset makes correlation of data and
      coordination with data in other timezones possible.

   Examples.

      Bob in Newfoundland (UTC -3:30) and Alice in Indiana (UTC -5 or
      UTC -6 depending on the time of year and exact county in Indiana)
      are working an incident together using their logs.  Both left the
      default settings, which was UTC, so there was no translation of
      time necessary to correlate the logs.

   Warnings.

      None.

<span class="h4"><a class="selflink" id="section-2.11.8" href="#section-2.11.8">2.11.8</a>.  Logs Must Be Timestamped</span>

   Requirement.

      By default, the device MUST timestamp all log messages.  The
      timestamp MUST be accurate to within a second or less.  The
      timestamp MUST include a timezone.  There MAY be a mechanism to
      disable the generation of timestamps.

   Justification.

      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.







<span class="grey">Jones                        Informational                     [Page 52]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-53" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   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.

<span class="h4"><a class="selflink" id="section-2.11.9" href="#section-2.11.9">2.11.9</a>.  Logs Contain Untranslated IP Addresses</span>

   Requirement.

      Log messages MUST NOT list translated addresses (DNS names)
      associated with the address without listing the untranslated IP
      address where the IP address is available to the device generating
      the log message.

   Justification.

      Including IP address of access list violations authentication
      attempts, address lease assignments and similar events in logs
      enables a level of individual and organizational accountability
      and is necessary to enable analysis of network events, incidents,
      policy violations, etc.

      DNS entries tend to change more quickly than IP block assignments.
      This makes the address more reliable for data forensics.

      DNS lookups can be slow and consume resources.

   Examples.

      A failed network login should generate a record with the source
      address of the login attempt.

   Warnings.

      *  Source addresses may be spoofed.  Network-based attacks often
         use spoofed source addresses.  Source addresses should not be
         completely trusted unless verified by other 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.  Having accurate time in the logs increases the chances
         that the use of an address can be correlated to an individual.






<span class="grey">Jones                        Informational                     [Page 53]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-54" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


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

<span class="h4"><a class="selflink" id="section-2.11.10" href="#section-2.11.10">2.11.10</a>.  Logs Contain Records Of Security Events</span>

   Requirement.

      The device MUST be able to send a record of at least the following
      events:

      *  authentication successes,

      *  authentication failures,

      *  session Termination,

      *  authorization changes,

      *  configuration changes,

      *  device status changes.

      The device SHOULD be able to send a record of all other security
      related events.

   Justification.

      This is important because it supports individual accountability.
      See <a href="./rfc2196#section-4.5.4.4">section&nbsp;4.5.4.4 of [RFC2196]</a>.

   Examples.

      Examples of events for which there must be a record include: user
      logins, bad login attempts, logouts, user privilege level changes,
      individual configuration commands issued by users and system
      startup/shutdown events.

   Warnings.

      This list is far from complete.

      Note that there may be privacy or legal considerations when
      logging/monitoring user activity.





<span class="grey">Jones                        Informational                     [Page 54]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-55" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h4"><a class="selflink" id="section-2.11.11" href="#section-2.11.11">2.11.11</a>.  Logs Do Not Contain Passwords</span>

   Requirement.

      Passwords SHOULD be excluded from all audit records, including
      records of successful or failed authentication attempts.

   Justification.

      Access control and authorization requirements differ for
      accounting records (logs) and authorization databases (passwords).
      Logging passwords may grant unauthorized access to individuals
      with access to the logs.  Logging failed passwords may give hints
      about actual passwords.  See <a href="./rfc2196#section-4.5.4.4">section&nbsp;4.5.4.4 of [RFC2196]</a>.

   Examples.

      A user may make small mistakes in entering a password such as
      using incorrect capitalization ("my password" vs. "My Password").

   Warnings.

      There may be situations where it is appropriate/required to log
      passwords.

<span class="h3"><a class="selflink" id="section-2.12" href="#section-2.12">2.12</a>.  Authentication, Authorization, and Accounting (AAA) Requirements</span>

<span class="h4"><a class="selflink" id="section-2.12.1" href="#section-2.12.1">2.12.1</a>.  Authenticate All User Access</span>

   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 <a href="#section-2.12.5">Section 2.12.5</a>.  It MAY also be
      satisfied using local authentication.  See <a href="#section-2.12.6">Section 2.12.6</a>.

   Warnings.

      None.



<span class="grey">Jones                        Informational                     [Page 55]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-56" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h4"><a class="selflink" id="section-2.12.2" href="#section-2.12.2">2.12.2</a>.  Support Authentication of Individual Users</span>

   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 <a href="#section-2.4.5">Section 2.4.5</a> or recovery of
      authorized access <a href="#section-2.12.15">Section 2.12.15</a>.

   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.

<span class="h4"><a class="selflink" id="section-2.12.3" href="#section-2.12.3">2.12.3</a>.  Support Simultaneous Connections</span>

   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.





<span class="grey">Jones                        Informational                     [Page 56]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-57" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Examples.

      None.

   Warnings.

      None.

<span class="h4"><a class="selflink" id="section-2.12.4" href="#section-2.12.4">2.12.4</a>.  Ability to Disable All Local Accounts</span>

   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.

<span class="h4"><a class="selflink" id="section-2.12.5" href="#section-2.12.5">2.12.5</a>.  Support Centralized User Authentication Methods</span>

   Requirement.

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





<span class="grey">Jones                        Informational                     [Page 57]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-58" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   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
      [<a href="./rfc3588" title="&quot;Diameter Base Protocol&quot;">RFC3588</a>], TACACS+ [<a href="./rfc1492" title="&quot;An Access Control Protocol, Sometimes Called TACACS&quot;">RFC1492</a>], RADIUS [<a href="./rfc2865" title="&quot;Remote Authentication Dial In User Service (RADIUS)&quot;">RFC2865</a>], or Kerberos
      [<a href="./rfc1510" title="&quot;The Kerberos Network Authentication Service (V5)&quot;">RFC1510</a>].

      The secure management requirements (<a href="#section-2.1.1">Section 2.1.1</a>) apply to AAA.

      See [<a href="./rfc3579" title="&quot;RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)&quot;">RFC3579</a>] for a discussion security issues related to RADIUS.

   Warnings.

      None.

<span class="h4"><a class="selflink" id="section-2.12.6" href="#section-2.12.6">2.12.6</a>.  Support Local User Authentication Method</span>

   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 <a href="#section-2.3.1">Section 2.3.1</a> (Support a 'Console'
      Interface) and <a href="#section-2.12.7">Section 2.12.7</a> (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.







<span class="grey">Jones                        Informational                     [Page 58]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-59" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   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.

<span class="h4"><a class="selflink" id="section-2.12.7" href="#section-2.12.7">2.12.7</a>.  Support Configuration of Order of Authentication Methods</span>

   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.

<span class="h4"><a class="selflink" id="section-2.12.8" href="#section-2.12.8">2.12.8</a>.  Ability To Authenticate Without Plaintext Passwords</span>

   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.





<span class="grey">Jones                        Informational                     [Page 59]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-60" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Justification.

      Plaintext passwords can be easily observed using packet sniffers
      on shared networks.  See [<a href="./rfc1704" title="&quot;On Internet Authentication&quot;">RFC1704</a>] and [<a href="./rfc3631" title="&quot;Security Mechanisms for the Internet&quot;">RFC3631</a>] 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.

<span class="h4"><a class="selflink" id="section-2.12.9" href="#section-2.12.9">2.12.9</a>.  No Default Passwords</span>

   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.

<span class="h4"><a class="selflink" id="section-2.12.10" href="#section-2.12.10">2.12.10</a>.  Passwords Must Be Explicitly Configured Prior To Use</span>

   Requirement.

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




<span class="grey">Jones                        Informational                     [Page 60]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-61" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   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.

<span class="h4"><a class="selflink" id="section-2.12.11" href="#section-2.12.11">2.12.11</a>.  Ability to Define Privilege Levels</span>

   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 <a href="#section-2.12.12">Section</a>
      <a href="#section-2.12.12">2.12.12</a>.  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



<span class="grey">Jones                        Informational                     [Page 61]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-62" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


      parameters.  Note that privilege levels may be defined locally on
      the device or on centralized authentication servers.

   Warnings.

      None.

<span class="h4"><a class="selflink" id="section-2.12.12" href="#section-2.12.12">2.12.12</a>.  Ability to Assign Privilege Levels to Users</span>

   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
      <a href="#section-2.12.11">Section 2.12.11</a>.

   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.

<span class="h4"><a class="selflink" id="section-2.12.13" href="#section-2.12.13">2.12.13</a>.  Default Privilege Level Must Be 'None'</span>

   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
      <a href="#section-2.4.5">Section 2.4.5</a> or recovery of authorized access per <a href="#section-2.12.15">Section</a>
      <a href="#section-2.12.15">2.12.15</a>.





<span class="grey">Jones                        Informational                     [Page 62]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-63" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   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 (<a href="#section-2.12.15">Section</a>
      <a href="#section-2.12.15">2.12.15</a>) and to support OS installation and configuration (<a href="#section-2.4.5">Section</a>
      <a href="#section-2.4.5">2.4.5</a>).  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.

<span class="h4"><a class="selflink" id="section-2.12.14" href="#section-2.12.14">2.12.14</a>.  Change in Privilege Levels Requires Re-Authentication</span>

   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.



<span class="grey">Jones                        Informational                     [Page 63]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-64" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h4"><a class="selflink" id="section-2.12.15" href="#section-2.12.15">2.12.15</a>.  Support Recovery Of Privileged Access</span>

   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 <a href="#section-2.3.1">Section 2.3.1</a> (Support a 'Console'
      Interface).






<span class="grey">Jones                        Informational                     [Page 64]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-65" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h3"><a class="selflink" id="section-2.13" href="#section-2.13">2.13</a>.  Layer 2 Devices Must Meet Higher Layer Requirements</span>

   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.

<span class="h3"><a class="selflink" id="section-2.14" href="#section-2.14">2.14</a>.  Security Features Must Not Cause Operational Problems</span>

   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.



<span class="grey">Jones                        Informational                     [Page 65]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-66" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


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

<span class="h3"><a class="selflink" id="section-2.15" href="#section-2.15">2.15</a>.  Security Features Should Have Minimal Performance Impact</span>

   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.




<span class="grey">Jones                        Informational                     [Page 66]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-67" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Documentation Requirements</span>

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

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Identify Services That May Be Listening</span>

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

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Document Service Defaults</span>

   Requirement.

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



<span class="grey">Jones                        Informational                     [Page 67]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-68" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   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 <a href="#section-2.5.1">Section 2.5.1</a>.

   Warnings.

      None.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Document Service Activation Process</span>

   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.

<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  Document Command Line Interface</span>

   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.




<span class="grey">Jones                        Informational                     [Page 68]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-69" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   Justification.

      Understanding of inputs and outputs is necessary to support
      scripting. See <a href="#section-2.4.2">Section 2.4.2</a>.

   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.

<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>.  'Console' Default Communication Profile Documented</span>

   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.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Assurance Requirements</span>

   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.






<span class="grey">Jones                        Informational                     [Page 69]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-70" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Identify Origin of IP Stack</span>

   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.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Identify Origin of Operating System</span>

   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.







<span class="grey">Jones                        Informational                     [Page 70]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-71" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Security Considerations</span>

   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 <a href="./rfc3410#section-8">[RFC3410], section&nbsp;8</a>),
      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.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  References</span>

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Normative References</span>

   [<a id="ref-ANSI.X9-52.1998">ANSI.X9-52.1998</a>] American National Standards Institute, "Triple Data
                     Encryption Algorithm Modes of Operation", ANSI
                     X9.52, 1998.

   [<a id="ref-FIPS.197">FIPS.197</a>]        National Institute of Standards and Technology,
                     "Advanced Encryption Standard", FIPS PUB 197,
                     November 2001,
                     &lt;<a href="http://csrc.nist.gov/publications/fips/fips197/fips-197.ps">http://csrc.nist.gov/publications/fips/fips197/</a>
                     <a href="http://csrc.nist.gov/publications/fips/fips197/fips-197.ps">fips-197.ps</a>&gt;.

   [<a id="ref-PKCS.3.1993">PKCS.3.1993</a>]     RSA Laboratories, "Diffie-Hellman Key-Agreement
                     Standard, Version 1.4", PKCS 3, November 1993.

   [<a id="ref-RFC1208">RFC1208</a>]         Jacobsen, O. and D. Lynch, "Glossary of networking
                     terms", <a href="./rfc1208">RFC 1208</a>, March 1991.



<span class="grey">Jones                        Informational                     [Page 71]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-72" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   [<a id="ref-RFC1321">RFC1321</a>]         Rivest, R., "The MD5 Message-Digest Algorithm", <a href="./rfc1321">RFC</a>
                     <a href="./rfc1321">1321</a>, April 1992.

   [<a id="ref-RFC1492">RFC1492</a>]         Finseth, C., "An Access Control Protocol, Sometimes
                     Called TACACS", <a href="./rfc1492">RFC 1492</a>, July 1993.

   [<a id="ref-RFC1510">RFC1510</a>]         Kohl, J. and C. Neuman, "The Kerberos Network
                     Authentication Service (V5)", <a href="./rfc1510">RFC 1510</a>, September
                     1993.

   [<a id="ref-RFC1704">RFC1704</a>]         Haller, N. and R. Atkinson, "On Internet
                     Authentication", <a href="./rfc1704">RFC 1704</a>, October 1994.

   [<a id="ref-RFC1812">RFC1812</a>]         Baker, F., Ed., "Requirements for IP Version 4
                     Routers", <a href="./rfc1812">RFC 1812</a>, June 1995.

   [<a id="ref-RFC1918">RFC1918</a>]         Rekhter, Y., Moskowitz, B., Karrenberg, D., de
                     Groot, G., and E. Lear, "Address Allocation for
                     Private Internets", <a href="https://www.rfc-editor.org/bcp/bcp5">BCP 5</a>, <a href="./rfc1918">RFC 1918</a>, February 1996.

   [<a id="ref-RFC2026">RFC2026</a>]         Bradner, S., "The Internet Standards Process --
                     Revision 3", <a href="https://www.rfc-editor.org/bcp/bcp9">BCP 9</a>, <a href="./rfc2026">RFC 2026</a>, October 1996.

   [<a id="ref-RFC2119">RFC2119</a>]         Bradner, S., "Key words for use in RFCs to Indicate
                     Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC2196">RFC2196</a>]         Fraser, B., "Site Security Handbook", FYI 8, <a href="./rfc2196">RFC</a>
                     <a href="./rfc2196">2196</a>, September 1997.

   [<a id="ref-RFC2246">RFC2246</a>]         Dierks, T. and C. Allen, "The TLS Protocol Version
                     1.0", <a href="./rfc2246">RFC 2246</a>, January 1999.

   [<a id="ref-RFC2385">RFC2385</a>]         Heffernan, A., "Protection of BGP Sessions via the
                     TCP MD5 Signature Option", <a href="./rfc2385">RFC 2385</a>, August 1998.

   [<a id="ref-RFC2401">RFC2401</a>]         Kent, S. and R. Atkinson, "Security Architecture
                     for the Internet Protocol", <a href="./rfc2401">RFC 2401</a>, November
                     1998.

   [<a id="ref-RFC2631">RFC2631</a>]         Rescorla, E., "Diffie-Hellman Key Agreement
                     Method", <a href="./rfc2631">RFC 2631</a>, June 1999.

   [<a id="ref-RFC2827">RFC2827</a>]         Ferguson, P. and D. Senie, "Network Ingress
                     Filtering: Defeating Denial of Service Attacks
                     which employ IP Source Address Spoofing", <a href="https://www.rfc-editor.org/bcp/bcp38">BCP 38</a>,
                     <a href="./rfc2827">RFC 2827</a>, May 2000.





<span class="grey">Jones                        Informational                     [Page 72]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-73" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   [<a id="ref-RFC2865">RFC2865</a>]         Rigney, C., Willens, S., Rubens, A., and W.
                     Simpson, "Remote Authentication Dial In User
                     Service (RADIUS)", <a href="./rfc2865">RFC 2865</a>, June 2000.

   [<a id="ref-RFC3013">RFC3013</a>]         Killalea, T., "Recommended Internet Service
                     Provider Security Services and Procedures", <a href="https://www.rfc-editor.org/bcp/bcp46">BCP 46</a>,
                     <a href="./rfc3013">RFC 3013</a>, November 2000.

   [<a id="ref-RFC3164">RFC3164</a>]         Lonvick, C., "The BSD Syslog Protocol", <a href="./rfc3164">RFC 3164</a>,
                     August 2001.

   [<a id="ref-RFC3174">RFC3174</a>]         Eastlake, D. and P. Jones, "US Secure Hash
                     Algorithm 1 (SHA1)", <a href="./rfc3174">RFC 3174</a>, September 2001.

   [<a id="ref-RFC3195">RFC3195</a>]         New, D. and M. Rose, "Reliable Delivery for
                     syslog", <a href="./rfc3195">RFC 3195</a>, November 2001.

   [<a id="ref-RFC3309">RFC3309</a>]         Stone, J., Stewart, R. and D. Otis, "Stream Control
                     Transmission Protocol (SCTP) Checksum Change", <a href="./rfc3309">RFC</a>
                     <a href="./rfc3309">3309</a>, September 2002.

   [<a id="ref-RFC3330">RFC3330</a>]         IANA, "Special-Use IPv4 Addresses", <a href="./rfc3330">RFC 3330</a>,
                     September 2002.

   [<a id="ref-RFC3360">RFC3360</a>]         Floyd, S., "Inappropriate TCP Resets Considered
                     Harmful", <a href="https://www.rfc-editor.org/bcp/bcp60">BCP 60</a>, <a href="./rfc3360">RFC 3360</a>, August 2002.

   [<a id="ref-RFC3410">RFC3410</a>]         Case, J., Mundy, R., Partain, D. and B. Stewart,
                     "Introduction and Applicability Statements for
                     Internet-Standard Management Framework", <a href="./rfc3410">RFC 3410</a>,
                     December 2002.

   [<a id="ref-RFC3411">RFC3411</a>]         Harrington, D., Presuhn, R., and B. Wijnen, "An
                     Architecture for Describing Simple Network
                     Management Protocol (SNMP) Management Frameworks",
                     STD 62, <a href="./rfc3411">RFC 3411</a>, December 2002.

   [<a id="ref-RFC3447">RFC3447</a>]         Jonsson, J. and B. Kaliski, "Public-Key
                     Cryptography Standards (PKCS) #1: RSA Cryptography
                     Specifications Version 2.1", <a href="./rfc3447">RFC 3447</a>, February
                     2003.

   [<a id="ref-RFC3562">RFC3562</a>]         Leech, M., "Key Management Considerations for the
                     TCP MD5 Signature Option", <a href="./rfc3562">RFC 3562</a>, July 2003.







<span class="grey">Jones                        Informational                     [Page 73]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-74" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   [<a id="ref-RFC3579">RFC3579</a>]         Aboba, B. and P. Calhoun, "RADIUS (Remote
                     Authentication Dial In User Service) Support For
                     Extensible Authentication Protocol (EAP)", <a href="./rfc3579">RFC</a>
                     <a href="./rfc3579">3579</a>, September 2003.

   [<a id="ref-RFC3588">RFC3588</a>]         Calhoun, P., Loughney, J., Guttman, E., Zorn, G.,
                     and J. Arkko, "Diameter Base Protocol", <a href="./rfc3588">RFC 3588</a>,
                     September 2003.

   [<a id="ref-RFC3631">RFC3631</a>]         Bellovin, S., Schiller, J., and C. Kaufman, Eds.,
                     "Security Mechanisms for the Internet", <a href="./rfc3631">RFC 3631</a>,
                     December 2003.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Informative References</span>

   [<a id="ref-RFC3766">RFC3766</a>]         Orman, H. and P. Hoffman, "Determining Strengths
                     For Public Keys Used For Exchanging Symmetric
                     Keys", <a href="https://www.rfc-editor.org/bcp/bcp86">BCP 86</a>, <a href="./rfc3766">RFC 3766</a>, April 2004.

   [<a id="ref-RFC3704">RFC3704</a>]         Baker, F. and P. Savola, "Ingress Filtering for
                     Multihomed Networks", <a href="https://www.rfc-editor.org/bcp/bcp84">BCP 84</a>, <a href="./rfc3704">RFC 3704</a>, March 2004.

   [<a id="ref-bmwg-acc-bench">bmwg-acc-bench</a>]  Poretsky, S., "Framework for Accelerated Stress
                     Benchmarking", Work in Progress, October 2003.

   [<a id="ref-Schneier">Schneier</a>]        Schneier, B., "Applied Cryptography, 2nd Ed.,
                     Publisher John Wiley &amp; Sons, Inc.", 1996.
























<span class="grey">Jones                        Informational                     [Page 74]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-75" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Requirement Profiles</span>

   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.

<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>.  Minimum Requirements Profile</span>

   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




<span class="grey">Jones                        Informational                     [Page 75]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-76" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   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




<span class="grey">Jones                        Informational                     [Page 76]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-77" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   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




<span class="grey">Jones                        Informational                     [Page 77]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-78" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   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

<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>.  Layer 3 Network Edge Profile</span>

   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



<span class="grey">Jones                        Informational                     [Page 78]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-79" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   o  Support Directional Application Of Rate Limiting Per Interface

   o  Support Rate Limiting Based on State

   o  Ability to Filter Traffic THROUGH the Device

<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>.  Acknowledgments</span>

   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.



<span class="grey">Jones                        Informational                     [Page 79]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-80" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


   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






































<span class="grey">Jones                        Informational                     [Page 80]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-81" ></span>
<span class="grey"><a href="./rfc3871">RFC 3871</a>           Operational Security Requirements      September 2004</span>


Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, 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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   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
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   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.









Jones                        Informational                     [Page 81]
</pre>