<pre>Network Working Group                                            M. Kaeo
Request for Comments: 4778                    Double Shot Security, Inc.
Category: Informational                                     January 2007


               <span class="h1">Current Operational Security Practices in</span>
                 <span class="h1">Internet Service Provider Environments</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 IETF Trust (2007).

Abstract

   This document is a survey of the current practices used in today's
   large ISP operational networks to secure layer 2 and layer 3
   infrastructure devices.  The information listed here is the result of
   information gathered from people directly responsible for defining
   and implementing secure infrastructures in Internet Service Provider
   environments.

























<span class="grey">Kaeo                         Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


Table of Contents

   <a href="#section-1">1</a>.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-2">2</a>
     <a href="#section-1.1">1.1</a>.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-2">2</a>
     <a href="#section-1.2">1.2</a>.  Threat Model . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-3">3</a>
     <a href="#section-1.3">1.3</a>.  Attack Sources . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-4">4</a>
     <a href="#section-1.4">1.4</a>.  Operational Security Impact from Threats . . . . . . . . .  <a href="#page-5">5</a>
     <a href="#section-1.5">1.5</a>.  Document Layout  . . . . . . . . . . . . . . . . . . . . .  <a href="#page-7">7</a>
   <a href="#section-2">2</a>.  Protected Operational Functions  . . . . . . . . . . . . . . .  <a href="#page-8">8</a>
     <a href="#section-2.1">2.1</a>.  Device Physical Access . . . . . . . . . . . . . . . . . .  <a href="#page-8">8</a>
     <a href="#section-2.2">2.2</a>.  Device Management - In-Band and Out-of-Band (OOB)  . . . . <a href="#page-10">10</a>
     <a href="#section-2.3">2.3</a>.  Data Path  . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
     <a href="#section-2.4">2.4</a>.  Routing Control Plane  . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
     2.5.  Software Upgrades and Configuration
           Integrity/Validation . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
     <a href="#section-2.6">2.6</a>.  Logging Considerations . . . . . . . . . . . . . . . . . . <a href="#page-26">26</a>
     <a href="#section-2.7">2.7</a>.  Filtering Considerations . . . . . . . . . . . . . . . . . <a href="#page-29">29</a>
     <a href="#section-2.8">2.8</a>.  Denial-of-Service Tracking/Tracing . . . . . . . . . . . . <a href="#page-30">30</a>
   <a href="#section-3">3</a>.  Security Considerations  . . . . . . . . . . . . . . . . . . . <a href="#page-32">32</a>
   <a href="#section-4">4</a>.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-32">32</a>
   <a href="#section-5">5</a>.  References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-33">33</a>
     <a href="#section-5.1">5.1</a>.  Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-33">33</a>
     <a href="#section-5.2">5.2</a>.  Informational References . . . . . . . . . . . . . . . . . <a href="#page-33">33</a>
   <a href="#appendix-A">Appendix A</a>.  Protocol Specific Attacks . . . . . . . . . . . . . . <a href="#page-34">34</a>
     <a href="#appendix-A.1">A.1</a>.  Layer 2 Attacks  . . . . . . . . . . . . . . . . . . . . . <a href="#page-34">34</a>
     <a href="#appendix-A.2">A.2</a>.  IPv4 Protocol-Based Attacks  . . . . . . . . . . . . . . . <a href="#page-34">34</a>
     <a href="#appendix-A.3">A.3</a>.  IPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-36">36</a>

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

   Security practices are well understood by the network operators who
   have, for many years, gone through the growing pains of securing
   their network infrastructures.  However, there does not exist a
   written document that enumerates these security practices.  Network
   attacks are continually increasing and although it is not necessarily
   the role of an ISP to act as the Internet police, each ISP has to
   ensure that certain security practices are followed to ensure that
   their network is operationally available for their customers.  This
   document is the result of a survey conducted to find out what current
   security practices are being deployed to secure network
   infrastructures.

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

   The scope for this survey is restricted to security practices that
   mitigate exposure to risks with the potential to adversely impact
   network availability and reliability.  Securing the actual data
   traffic is outside the scope of the conducted survey.  This document



<span class="grey">Kaeo                         Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   focuses solely on documenting currently deployed security mechanisms
   for layer 2 and layer 3 network infrastructure devices.  Although
   primarily focused on IPv4, many of the same practices can (and
   should) apply to IPv6 networks.  Both IPv4 and IPv6 network
   infrastructures are taken into account in this survey.

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

   A threat is a potential for a security violation, which exists when
   there is a circumstance, capability, action, or event that could
   breach security and cause harm [<a href="./rfc2828" title="&quot;Internet Security Glossary&quot;">RFC2828</a>].  Every operational network
   is subject to a multitude of threat actions, or attacks, i.e., an
   assault on system security that derives from an intelligent act that
   is a deliberate attempt to evade security services, and violate the
   security policy of a system [<a href="./rfc2828" title="&quot;Internet Security Glossary&quot;">RFC2828</a>].  Many of the threats to a
   network infrastructure occur from an instantiation (or combination)
   of the following:

   Reconnaissance: An attack whereby information is gathered to
   ascertain the network topology or specific device information, which
   can be further used to exploit known vulnerabilities

   Man-In-The-Middle: An attack where a malicious user impersonates
   either the sender or recipient of a communication stream while
   inserting, modifying, or dropping certain traffic.  This type of
   attack also covers phishing and session hijacks.

   Protocol Vulnerability Exploitation: An attack that takes advantage
   of known protocol vulnerabilities due to design or implementation
   flaws to cause inappropriate behavior.

   Message Insertion: This can be a valid message (it could be a reply
   attack, which is a scenario where a message is captured and resent at
   a later time).  A message can also be inserted with any of the fields
   in the message being spoofed, such as IP addresses, port numbers,
   header fields, or even packet content.  Flooding is also part of this
   threat instantiation.

   Message Diversion/Deletion: An attack where legitimate messages are
   removed before they can reach the desired recipient, or are
   re-directed to a network segment that is normally not part of the
   data path.

   Message Modification: This is a subset of a message insertion attack
   where a previous message has been captured and modified before being
   retransmitted.  The message can be captured using a man-in-the-middle
   attack or message diversion.




<span class="grey">Kaeo                         Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   Note that sometimes denial-of-service attacks are listed as separate
   categories.  A denial-of-service is a consequence of an attack and
   can be the result of too much traffic (i.e., flooding), exploiting
   protocol exploitation, or inserting/deleting/diverting/modifying
   messages.

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

   These attacks can be sourced in a variety of ways:

   Active vs Passive Attacks

      An active attack involves writing data to the network.  It is
      common practice in active attacks to disguise one's address and
      conceal the identity of the traffic sender.  A passive attack
      involves only reading information off the network.  This is
      possible if the attacker has control of a host in the
      communications path between two victim machines, or has
      compromised the routing infrastructure to specifically arrange
      that traffic pass through a compromised machine.  There are also
      situations where mirrored traffic (often used for debugging,
      performance monitoring, or accounting purposes) is diverted to a
      compromised machine, which would not necessarily subvert any
      existing topology, and could be harder to detect.  In general, the
      goal of a passive attack is to obtain information that the sender
      and receiver would prefer to remain private [<a href="./rfc3552" title="&quot;Guidelines for Writing RFC Text on Security Considerations&quot;">RFC3552</a>].

   On-path vs Off-path Attacks

      In order for a datagram to be transmitted from one host to
      another, it generally must traverse some set of intermediate links
      and routers.  Such routers are naturally able to read, modify, or
      remove any datagram transmitted along that path.  This makes it
      much easier to mount a wide variety of attacks if you are on-path.
      Off-path hosts can transmit arbitrary datagrams that appear to
      come from any host but cannot necessarily receive datagrams
      intended for other hosts.  Thus, if an attack depends on being
      able to receive data, off-path hosts must first subvert the
      topology in order to place themselves on-path.  This is by no
      means impossible, but is not necessarily trivial [<a href="./rfc3552" title="&quot;Guidelines for Writing RFC Text on Security Considerations&quot;">RFC3552</a>].  A
      more subtle attack is one where the traffic-mirroring capability
      of a device is hijacked and the traffic is diverted to a
      compromised host since the network topology may not need to be
      subverted.







<span class="grey">Kaeo                         Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   Insider vs Outsider Attacks

      An "insider attack" is initiated from inside a given security
      perimeter by an entity that is authorized to access system
      resources, but uses them in a way not approved by those who
      granted the authorization.  An "outside attack" is initiated from
      outside the perimeter by an unauthorized or illegitimate user of
      the system.

   Deliberate Attacks vs Unintentional Events

      A deliberate attack is where a miscreant intentionally performs an
      assault on system security.  However, there are also instances
      where unintentional events cause the same harm, yet are performed
      without malicious intent.  Configuration errors and software bugs
      can be as devastating to network availability as any deliberate
      attack on the network infrastructure.

   The attack source can be a combination of any of the above, all of
   which need to be considered when trying to ascertain the impact any
   attack can have on the availability and reliability of the network.
   It is nearly impossible to stop insider attacks or unintentional
   events.  However, if appropriate monitoring mechanisms are in place,
   these attacks can also be detected and mitigated as with any other
   attack source.  The amount of effort it takes to identify and trace
   an attack is, of course, dependent on the resourcefulness of the
   attacker.  Any of the specific attacks discussed further in this
   document will elaborate on malicious behavior, which are sourced by
   an "outsider" and are deliberate attacks.  Some further elaboration
   will be given to the feasibility of passive vs active and on-path vs
   off-path attacks to show the motivation behind deploying certain
   security features.

<span class="h3"><a class="selflink" id="section-1.4" href="#section-1.4">1.4</a>.  Operational Security Impact from Threats</span>

   The main concern for any of the potential attack scenarios is the
   impact and harm it can cause to the network infrastructure.  The
   threat consequences are the security violations that results from a
   threat action, i.e., an attack.  These are typically classified as
   follows:

   (Unauthorized) Disclosure

      A circumstance or event whereby an entity gains access to data for
      which the entity is not authorized.






<span class="grey">Kaeo                         Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   Deception

      A circumstance or event that may result in an authorized entity
      receiving false data and believing it to be true.


   Disruption

      A circumstance or event that interrupts or prevents the correct
      operation of system services and functions.  A broad variety of
      attacks, collectively called denial of service attacks, threaten
      the availability of systems and bandwidth to legitimate users.
      Many such attacks are designed to consume machine resources,
      making it difficult or impossible to serve legitimate users.
      Other attacks cause the target machine to crash, completely
      denying service to users.


   Usurpation

      A circumstance or event that results in control of system services
      or functions by an unauthorized entity.  Most network
      infrastructure systems are only intended to be completely
      accessible to certain authorized individuals.  Should an
      unauthorized person gain access to critical layer 2/layer 3
      infrastructure devices or services, they could cause great harm to
      the reliability and availability of the network.

   A complete description of threat actions that can cause these threat
   consequences can be found in [<a href="./rfc2828" title="&quot;Internet Security Glossary&quot;">RFC2828</a>].  Typically, a number of
   different network attacks are used in combination to cause one or
   more of the above-mentioned threat consequences.  An example would be
   a malicious user who has the capability to eavesdrop on traffic.
   First, he may listen in on traffic for a while, doing reconnaissance
   work and ascertaining which IP addresses belong to specific devices,
   such as routers.  Were this miscreant to obtain information, such as
   a router password sent in cleartext, he can then proceed to
   compromise the actual router.  From there, the miscreant can launch
   various active attacks, such as sending bogus routing updates to
   redirect traffic or capture additional traffic to compromise other
   network devices.  While this document enumerates which
   countermeasures ISPs are deploying today, a useful generic analysis
   of actual backbone infrastructure attacks and the appropriate
   countermeasures can be found in [<a href="#ref-RTGWG" title="&quot;Backbone Infrastructure Attacks and Protections&quot;">RTGWG</a>].







<span class="grey">Kaeo                         Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


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

   This document is a survey of current operational practices that
   mitigate the risk of being susceptible to any threat actions.  As
   such, the main focus is on the currently deployed security practices
   used to detect and/or mitigate attacks.  The top-level categories in
   this document are based on operational functions for ISPs and
   generally relate to what is to be protected.  This is followed by a
   description of which attacks are possible and the security practices
   currently deployed.  This will provide the necessary security
   services to help mitigate these attacks.  These security services are
   classified as follows:

   o  User Authentication

   o  User Authorization

   o  Data Origin Authentication

   o  Access Control

   o  Data Integrity

   o  Data Confidentiality

   o  Auditing/Logging

   o  DoS Mitigation


   In many instances, a specific protocol currently deployed will offer
   a combination of these services.  For example, Authentication,
   Authorization, and Accounting (AAA) can offer user authentication,
   user authorization, and audit/logging services, while the Secure
   SHell (SSH) Protocol can provide data origin authentication, data
   integrity, and data confidentiality.  The services offered are more
   important than the actual protocol used.  Note that access control
   will refer basically to logical access control, i.e., filtering.
   Each section ends with an additional considerations section that
   explains why specific protocols may or may not be used, and also
   gives some information regarding capabilities, which are not possible
   today due to bugs or lack of usability.









<span class="grey">Kaeo                         Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Protected Operational Functions</span>

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

   Device physical access pertains to protecting the physical location
   and access of the layer 2 or layer 3 network infrastructure device.
   Physical security is a large field of study/practice in and of
   itself, arguably the largest, oldest, and most well-understood area
   of security.  Although it is important to have contingency plans for
   natural disasters, such as earthquakes and floods, which can cause
   damage to networking devices, this is out of the scope of this
   document.  Here, we concern ourselves with protecting access to the
   physical location and how a device can be further protected from
   unauthorized access if the physical location has been compromised,
   i.e., protecting the console access.  This is aimed largely at
   stopping an intruder with physical access from gaining operational
   control of the device(s).  Note that nothing will stop an attacker
   with physical access from effecting a denial-of-service attack, which
   can be easily accomplished by powering off the device or just
   unplugging some cables.

<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>.  Threats/Attacks</span>

   If any intruder gets physical access to a layer 2 or layer 3 device,
   the entire network infrastructure can be under the control of the
   intruder.  At a minimum, the intruder can take the compromised device
   out of service, causing network disruption, the extent of which
   depends on the network topology.  A worse scenario is where the
   intruder uses this device to crack the console password, gaining
   complete control of the device (perhaps without anyone detecting such
   a compromise, or to attach another network device onto a port and
   siphon off data with which the intruder can ascertain the network
   topology) and the entire network.

   The threat of gaining physical access can be realized in a variety of
   ways, even if critical devices are under high security.  Cases still
   occur where attackers have impersonated maintenance workers to gain
   physical access to critical devices that have caused major outages
   and privacy compromises.  Insider attacks from authorized personnel
   also pose a real threat and must be adequately recognized and
   addressed.

<span class="h4"><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a>.  Security Practices</span>

   For physical device security, equipment is kept in highly restrictive
   environments.  Only authorized users with card-key badges have access
   to any of the physical locations that contain critical network
   infrastructure devices.  These card-key systems keep track of who



<span class="grey">Kaeo                         Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   accessed which location and at what time.  Most cardkey systems have
   a fail-back "master key" in case the card system is down.  This
   "master key" usually has limited access and its use is also carefully
   logged (which should only happen if the card-key system is NOT
   online/functional).

   All console access is always password protected and the login time is
   set to time out after a specified amount of inactivity - typically
   between 3-10 minutes.  The type of privileges that you obtain from a
   console login varies between separate vendor devices.  In some cases
   you get initial basic access and need to perform a second
   authentication step to get more privileged access (i.e., enable or
   root).  In other vendors, you get the more privileged access when you
   log into the console as root, without requiring a second
   authentication step.

   How ISPs manage these logins vary greatly, although many of the
   larger ISPs employ some sort of AAA mechanism to help automate
   privilege-level authorization and utilize the automation to bypass
   the need for a second authentication step.  Also, many ISPs define
   separate classes of users to have different privileges while logged
   onto the console.  Typically, all console access is provided via an
   out-of-band (OOB) management infrastructure, which is discussed in
   <a href="#section-2.2">Section 2.2</a> of this document.

<span class="h4"><a class="selflink" id="section-2.1.3" href="#section-2.1.3">2.1.3</a>.  Security Services</span>

   The following security services are offered through the use of the
   practices described in the previous section:

   o  User Authentication - All individuals who have access to the
      physical facility are authenticated.  Console access is
      authenticated.

   o  User Authorization - An authenticated individual has implicit
      authorization to perform commands on the device.  In some cases,
      multiple authentication is required to differentiate between basic
      and more privileged access.

   o  Data Origin Authentication - Not applicable.

   o  Access Control - Not applicable.

   o  Data Integrity - Not applicable.

   o  Data Confidentiality - Not applicable.





<span class="grey">Kaeo                         Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   o  Auditing/Logging - All access to the physical locations of the
      infrastructure equipment is logged via electronic card-key
      systems.  All console access is logged (refer to <a href="#section-2.2">Section 2.2</a> of
      this document for more details).

   o  DoS Mitigation - Not applicable.

<span class="h4"><a class="selflink" id="section-2.1.4" href="#section-2.1.4">2.1.4</a>.  Additional Considerations</span>

   Physical security is relevant to operational security practices as
   described in this document, mostly from a console-access perspective.
   Most ISPs provide console access via an OOB management
   infrastructure, which is discussed in <a href="#section-2.2">Section 2.2</a> of this document.

   The physical and logical authentication and logging systems should be
   run independently of each other and should reside in different
   physical locations.  These systems need to be secured to ensure that
   they themselves will not be compromised, which could give the
   intruder valuable authentication and logging information.

   Social engineering plays a big role in many physical access
   compromises.  Most ISPs have set up training classes and awareness
   programs to educate company personnel to deny physical access to
   people who are not properly authenticated or authorized to have
   physical access to critical infrastructure devices.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Device Management - In-Band and Out-of-Band (OOB)</span>

   In-band management is generally considered to be device access, where
   the control traffic takes the same data path as the data that
   traverses the network.  Out-of-band management is generally
   considered to be device access, where the control traffic takes a
   separate path as the data that traverses the network.  In many
   environments, device management for layer 2 and layer 3
   infrastructure devices is deployed as part of an out-of-band
   management infrastructure, although there are some instances where it
   is deployed in-band as well.  Note that while many of the security
   concerns and practices are the same for OOB management and in-band
   management, most ISPs prefer an OOB management system, since access
   to the devices that make up this management network are more
   vigilantly protected and considered to be less susceptible to
   malicious activity.

   Console access is always architected via an OOB network.  Presently,
   the mechanisms used for either in-band management or OOB are via
   virtual terminal access (i.e., Telnet or SSH), Simple Network
   Management Protocol (SNMP), or HTTP.  In all large ISPs that were
   interviewed, HTTP management was never used and was explicitly



<span class="grey">Kaeo                         Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   disabled.  Note that file transfer protocols (TFTP, FTP, and SCP)
   will be covered in <a href="#section-2.5">Section 2.5</a> of this document.

<span class="h4"><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a>.  Threats/Attacks</span>

   For device management, passive attacks are possible if someone has
   the capability to intercept data between the management device and
   the managed device.  The threat is possible if a single
   infrastructure device is somehow compromised and can act as a network
   sniffer, or if it is possible to insert a new device that acts as a
   network sniffer.

   Active attacks are possible for both on-path and off-path scenarios.
   For on-path active attacks, the situation is the same as for a
   passive attack, where either a device has to already be compromised
   or a device can be inserted into the path.  For off-path active
   attacks, where a topology subversion is required to reroute traffic
   and essentially bring the attacker on-path, the attack is generally
   limited to message insertion or modification.

<span class="h5"><a class="selflink" id="section-2.2.1.1" href="#section-2.2.1.1">2.2.1.1</a>.  Confidentiality Violations</span>

   Confidentiality violations can occur when a miscreant intercepts any
   management data that has been sent in cleartext or with weak
   encryption.  This includes interception of usernames and passwords
   with which an intruder can obtain unauthorized access to network
   devices.  It can also include other information, such as logging or
   configuration information, if an administrator is remotely viewing
   local logfiles or configuration information.

<span class="h5"><a class="selflink" id="section-2.2.1.2" href="#section-2.2.1.2">2.2.1.2</a>.  Offline Cryptographic Attacks</span>

   If username/password information was encrypted but the cryptographic
   mechanism used made it easy to capture data and break the encryption
   key, the device management traffic could be compromised.  The traffic
   would need to be captured either by eavesdropping on the network or
   by being able to divert traffic to a malicious user.

<span class="h5"><a class="selflink" id="section-2.2.1.3" href="#section-2.2.1.3">2.2.1.3</a>.  Replay Attacks</span>

   For a replay attack to be successful, the management traffic would
   need to first be captured either on-path or diverted to an attacker
   to later be replayed to the intended recipient.








<span class="grey">Kaeo                         Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


<span class="h5"><a class="selflink" id="section-2.2.1.4" href="#section-2.2.1.4">2.2.1.4</a>.  Message Insertion/Deletion/Modification</span>

   Data can be manipulated by someone in control of intermediary hosts.
   Forging data is also possible with IP spoofing, where a remote host
   sends out packets that appear to come from another, trusted host.

<span class="h5"><a class="selflink" id="section-2.2.1.5" href="#section-2.2.1.5">2.2.1.5</a>.  Man-In-The-Middle</span>

   A man-in-the-middle attack attacks the identity of a communicating
   peer rather than the data stream itself.  The attacker intercepts
   traffic that is sent from a management system to the networking
   infrastructure device and traffic that is sent from the network
   infrastructure device to the management system.

<span class="h4"><a class="selflink" id="section-2.2.2" href="#section-2.2.2">2.2.2</a>.  Security Practices</span>

   OOB management is done via a terminal server at each location.  SSH
   access is used to get to the terminal server from where sessions to
   the devices are initiated.  Dial-in access is deployed as a backup if
   the network is not available.  However, it is common to use dial-
   back, encrypting modems, and/or one-time-password (OTP) modems to
   avoid the security weaknesses of plain dial-in access.

   All in-band management and OOB management access to layer 2 and layer
   3 devices is authenticated.  The user authentication and
   authorization is typically controlled by an AAA server (i.e., Remote
   Authentication Dial-in User Service (RADIUS) and/or Terminal Access
   Controller Access-Control System (TACACS+)).  Credentials used to
   determine the identity of the user vary from static username/password
   to one-time username/password schemes such as Secure-ID.  Static
   username/passwords are expired after a specified period of time,
   usually 30 days.  Every authenticated entity via AAA is an individual
   user for greater granularity of control.  Note that often the AAA
   server used for OOB management authentication is a separate physical
   device from the AAA server used for in-band management user
   authentication.  In some deployments, the AAA servers used for device
   management authentication/authorization/accounting are on separate
   networks to provide a demarcation for any other authentication
   functions.

   For backup purposes, there is often a single local database entry for
   authentication that is known to a very limited set of key personnel.
   It is usually the highest privilege-level username/password
   combination, which in most cases is the same across all devices.
   This local device password is routinely regenerated once every 2-3
   months, and is also regenerated immediately after an employee who had
   access to that password leaves the company or is no longer authorized
   to have knowledge of that password.



<span class="grey">Kaeo                         Informational                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   Each individual user in the AAA database is configured with specific
   authorization capability.  Specific commands are either individually
   denied or permitted, depending on the capability of the device to be
   accessed.  Multiple privilege levels are deployed.  Most individuals
   are authorized with basic authorization to perform a minimal set of
   commands, while a subset of individuals are authorized to perform
   more privileged commands.  Securing the AAA server is imperative and
   access to the AAA server itself is strictly controlled.  When an
   individual leaves the company, his/her AAA account is immediately
   deleted and the TACACS/RADIUS shared secret is reset for all devices.

   Some management functions are performed using command line interface
   (CLI) scripting.  In these scenarios, a dedicated user is used for
   the identity in scripts that perform CLI scripting.  Once
   authenticated, these scripts control which commands are legitimate,
   depending on authorization rights of the authenticated individual.

   SSH is always used for virtual terminal access to provide for an
   encrypted communication channel.  There are exceptions due to
   equipment limitations which are described in the additional
   considerations section.

   If SNMP is used for management, it is for read queries only and
   restricted to specific hosts.  If possible, the view is also
   restricted to only send the information that the management station
   needs, rather than expose the entire configuration file with the
   read-only SNMP community.  The community strings are carefully chosen
   to be difficult to crack and there are procedures in place to change
   these community strings between 30-90 days.  If systems support two
   SNMP community strings, the old string is replaced by first
   configuring a second, newer community string and then migrating over
   from the currently used string to the newer one.  Most large ISPs
   have multiple SNMP systems accessing their routers so it takes more
   then one maintenance period to get all the strings fixed in all the
   right systems.  SNMP RW is not used and is disabled by configuration.

   Access control is strictly enforced for infrastructure devices by
   using stringent filtering rules.  A limited set of IP addresses are
   allowed to initiate connections to the infrastructure devices and are
   specific to the services to which they are to limited (i.e., SSH and
   SNMP).

   All device management access is audited and any violations trigger
   alarms that initiate automated email, pager, and/or telephone
   notifications.  AAA servers keep track of the authenticated entity as
   well as all the commands that were carried out on a specific device.
   Additionally, the device itself logs any access control violations
   (i.e., if an SSH request comes in from an IP address that is not



<span class="grey">Kaeo                         Informational                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   explicitly permitted, that event is logged so that the offending IP
   address can be tracked down and investigations made as to why it was
   trying to access a particular infrastructure device)

<span class="h4"><a class="selflink" id="section-2.2.3" href="#section-2.2.3">2.2.3</a>.  Security Services</span>

   The security services offered for device OOB management are nearly
   identical to those of device in-band management.  Due to the critical
   nature of controlling and limiting device access, many ISPs feel that
   physically separating the management traffic from the normal customer
   data traffic will provide an added level of risk mitigation and limit
   the potential attack vectors.  The following security services are
   offered through the use of the practices described in the previous
   section:

   o  User Authentication - All individuals are authenticated via AAA
      services.

   o  User Authorization - All individuals are authorized via AAA
      services to perform specific operations once successfully
      authenticated.

   o  Data Origin Authentication - Management traffic is strictly
      filtered to allow only specific IP addresses to have access to the
      infrastructure devices.  This does not alleviate risk the from
      spoofed traffic, although when combined with edge filtering using
      <a href="https://www.rfc-editor.org/bcp/bcp38">BCP38</a> [<a href="./rfc2827" title="&quot;Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing&quot;">RFC2827</a>] and <a href="https://www.rfc-editor.org/bcp/bcp84">BCP84</a> [<a href="./rfc3704" title="&quot;Ingress Filtering for Multihomed Networks&quot;">RFC3704</a>] guidelines (discussed in
      <a href="#section-2.5">Section 2.5</a>), then the risk of spoofing is mitigated, barring a
      compromised internal system.  Also, using SSH for device access
      ensures that no one can spoof the traffic during the SSH session.

   o  Access Control - Management traffic is filtered to allow only
      specific IP addresses to have access to the infrastructure
      devices.

   o  Data Integrity - Using SSH provides data integrity and ensures
      that no one has altered the management data in transit.

   o  Data Confidentiality - Using SSH provides data confidentiality.

   o  Auditing/Logging - Using AAA provides an audit trail for who
      accessed which device and which operations were performed.

   o  DoS Mitigation - Using packet filters to allow only specific IP
      addresses to have access to the infrastructure devices.  This
      limits but does not prevent spoofed DoS attacks directed at an
      infrastructure device.  However, the risk is lowered by using a
      separate physical network for management purposes.



<span class="grey">Kaeo                         Informational                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


<span class="h4"><a class="selflink" id="section-2.2.4" href="#section-2.2.4">2.2.4</a>.  Additional Considerations</span>

   Password selection for any device management protocol used is
   critical to ensure that the passwords are hard to guess or break
   using a brute-force attack.

   IP security (IPsec) is considered too difficult to deploy, and the
   common protocol to provide for confidential management access is SSH.
   There are exceptions for using SSH due to equipment limitations since
   SSH may not be supported on legacy equipment.  In some cases,
   changing the host name of a device requires an SSH rekey event since
   the key is based on some combination of host name, Message
   Authentication Code (MAC) address, and time.  Also, in the case where
   the SSH key is stored on a route processor card, a re-keying of SSH
   would be required whenever the route processor card needs to be
   swapped.  Some providers feel that this operational impact exceeds
   the security necessary and instead use Telnet from trusted inside
   hosts (called 'jumphosts' or 'bastion hosts') to manage those
   devices.  An individual would first SSH to the jumphost and then
   Telnet from the jumphost to the actual infrastructure device, fully
   understanding that any passwords will be sent in the clear between
   the jumphost and the device to which it is connecting.  All
   authentication and authorization is still carried out using AAA
   servers.

   In instances where Telnet access is used, the logs on the AAA servers
   are more verbose and more attention is paid to them to detect any
   abnormal behavior.  The jumphosts themselves are carefully controlled
   machines and usually have limited access.  Note that Telnet is NEVER
   allowed to an infrastructure device except from specific jumphosts;
   i.e., packet filters are used at the console server and/or
   infrastructure device to ensure that Telnet is only allowed from
   specific IP addresses.

   With thousands of devices to manage, some ISPs have created automated
   mechanisms to authenticate to devices.  As an example, Kerberos has
   been used to automate the authentication process for devices that
   have support for Kerberos.  An individual would first log in to a
   Kerberized UNIX server using SSH and generate a Kerberos 'ticket'.
   This 'ticket' is generally set to have a lifespan of 10 hours and is
   used to automatically authenticate the individual to the
   infrastructure devices.

   In instances where SNMP is used, some legacy devices only support
   SNMPv1, which then requires the provider to mandate its use across
   all infrastructure devices for operational simplicity.  SNMPv2 is
   primarily deployed since it is easier to set up than v3.




<span class="grey">Kaeo                         Informational                     [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Data Path</span>

   This section refers to how traffic is handled that traverses the
   network infrastructure device.  The primary goal of ISPs is to
   forward customer traffic.  However, due to the large amount of
   malicious traffic that can cause DoS attacks and render the network
   unavailable, specific measures are sometimes deployed to ensure the
   availability to forward legitimate customer traffic.

<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a>.  Threats/Attacks</span>

   Any data traffic can potentially be attack traffic and the challenge
   is to detect and potentially stop forwarding any of the malicious
   traffic.  The deliberately sourced attack traffic can consist of
   packets with spoofed source and/or destination addresses or any other
   malformed packet that mangle any portion of a header field to cause
   protocol-related security issues (such as resetting connections,
   causing unwelcome ICMP redirects, creating unwelcome IP options, or
   packet fragmentations).

<span class="h4"><a class="selflink" id="section-2.3.2" href="#section-2.3.2">2.3.2</a>.  Security Practices</span>

   Filtering and rate limiting are the primary mechanism to provide risk
   mitigation of malicious traffic rendering the ISP services
   unavailable.  However, filtering and rate limiting of data path
   traffic is deployed in a variety of ways, depending on how automated
   the process is and what the capabilities and performance limitations
   of the existing deployed hardware are.

   The ISPs that do not have performance issues with their equipment
   follow <a href="https://www.rfc-editor.org/bcp/bcp38">BCP38</a> [<a href="./rfc2827" title="&quot;Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing&quot;">RFC2827</a>] and <a href="https://www.rfc-editor.org/bcp/bcp84">BCP84</a> [<a href="./rfc3704" title="&quot;Ingress Filtering for Multihomed Networks&quot;">RFC3704</a>] guidelines for ingress
   filtering.  <a href="https://www.rfc-editor.org/bcp/bcp38">BCP38</a> recommends filtering ingress packets with obviously
   spoofed and/or 'reserved' source addresses to limit the effects of
   denial-of-service attacks, while <a href="https://www.rfc-editor.org/bcp/bcp84">BCP84</a> extends the recommendation for
   multi-homed environments.  Filters are also used to help alleviate
   issues between service providers.  Without any filtering, an
   inter-exchange peer could steal transit just by using static routes,
   and essentially redirect data traffic.  Therefore, some ISPs have
   implemented ingress/egress filters that block unexpected source and
   destination addresses not defined in the above-mentioned documents.
   Null routes and black-hole triggered routing [<a href="./rfc3882" title="&quot;Configuring BGP to Block Denial-of-Service Attacks&quot;">RFC3882</a>] are used to
   deter any detected malicious traffic streams.  These two techniques
   are described in more detail in <a href="#section-2.8">Section 2.8</a> below.

   Most ISPs consider layer 4 filtering useful, but it is only
   implemented if performance limitations allow for it.  Since it poses
   a large administrative overhead and ISPs are very much opposed to
   acting as the Internet firewall, Layer 4 filtering is typically



<span class="grey">Kaeo                         Informational                     [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   implemented as a last option.  Netflow is used for tracking traffic
   flows, but there is some concern whether sampling is good enough to
   detect malicious behavior.

   Unicast Reverse Path Forwarding (RPF) is not consistently
   implemented.  Some ISPs are in the process of doing so, while other
   ISPs think that the perceived benefit of knowing that spoofed traffic
   comes from legitimate addresses are not worth the operational
   complexity.  Some providers have a policy of implementing uRPF at
   link speeds of Digital Signal 3 (DS3) and below, which was due to the
   fact that all hardware in the network supported uRPF for DS3 speeds
   and below.  At higher-speed links, the uRPF support was inconsistent
   and it was easier for operational people to implement a consistent
   solution.

<span class="h4"><a class="selflink" id="section-2.3.3" href="#section-2.3.3">2.3.3</a>.  Security Services</span>

   o  User Authentication - Not applicable.

   o  User Authorization - Not applicable.

   o  Data Origin Authentication - When IP address filtering per <a href="https://www.rfc-editor.org/bcp/bcp38">BCP38</a>,
      <a href="https://www.rfc-editor.org/bcp/bcp84">BCP84</a>, and uRPF are deployed at network edges it can ensure that
      any spoofed traffic comes from at least a legitimate IP address
      and can be tracked.

   o  Access Control - IP address filtering and layer 4 filtering is
      used to deny forbidden protocols and limit traffic destined for
      infrastructure device itself.  Filters are also used to block
      unexpected source/destination addresses.

   o  Data Integrity - Not applicable.

   o  Data Confidentiality - Not applicable.

   o  Auditing/Logging - Filtering exceptions are logged for potential
      attack traffic.

   o  DoS Mitigation - Black-hole triggered filtering and rate-limiting
      are used to limit the risk of DoS attacks.

<span class="h4"><a class="selflink" id="section-2.3.4" href="#section-2.3.4">2.3.4</a>.  Additional Considerations</span>

   For layer 2 devices, MAC address filtering and authentication is not
   used in large-scale deployments.  This is due to the problems it can
   cause when troubleshooting networking issues.  Port security becomes
   unmanageable at a large scale where thousands of switches are
   deployed.



<span class="grey">Kaeo                         Informational                     [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   Rate limiting is used by some ISPs, although other ISPs believe it is
   not really useful, since attackers are not well-behaved and it
   doesn't provide any operational benefit over the complexity.  Some
   ISPs feel that rate limiting can also make an attacker's job easier
   by requiring the attacker to send less traffic to starve legitimate
   traffic that is part of a rate limiting scheme.  Rate limiting may be
   improved by developing flow-based rate-limiting capabilities with
   filtering hooks.  This would improve the performance as well as the
   granularity over current capabilities.

   Lack of consistency regarding the ability to filter, especially with
   respect to performance issues, cause some ISPs not to implement <a href="https://www.rfc-editor.org/bcp/bcp38">BCP38</a>
   and <a href="https://www.rfc-editor.org/bcp/bcp84">BCP84</a> guidelines for ingress filtering.  One such example is at
   edge boxes, where up to 1000 T1s connecting into a router with an
   OC-12 (Optical Carrier) uplink.  Some deployed devices experience a
   large performance impact with filtering, which is unacceptable for
   passing customer traffic through, though ingress filtering (uRPF)
   might be applicable at the devices that are connecting these
   aggregation routers.  Where performance is not an issue, the ISPs
   make a tradeoff between management versus risk.

<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>.  Routing Control Plane</span>

   The routing control plane deals with all the traffic that is part of
   establishing and maintaining routing protocol information.

<span class="h4"><a class="selflink" id="section-2.4.1" href="#section-2.4.1">2.4.1</a>.  Threats/Attacks</span>

   Attacks on the routing control plane can be from both passive or
   active sources.  Passive attacks are possible if someone has the
   capability to intercept data between the communicating routing peers.
   This can be accomplished if a single routing peer is somehow
   compromised and can act as a network sniffer, or if it is possible to
   insert a new device that acts as a network sniffer.

   Active attacks are possible for both on-path and off-path scenarios.
   For on-path active attacks, the situation is the same as for a
   passive attack, where either a device has to already be compromised
   or a device can be inserted into the path.  This may lead to an
   attacker impersonating a legitimate routing peer and exchanging
   routing information.  Unintentional active attacks are more common
   due to configuration errors, which cause legitimate routing peers to
   feed invalid routing information to other neighboring peers.

   For off-path active attacks, the attacks are generally limited to
   message insertion or modification, which can divert traffic to
   illegitimate destinations, causing traffic to never reach its
   intended destination.



<span class="grey">Kaeo                         Informational                     [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


<span class="h5"><a class="selflink" id="section-2.4.1.1" href="#section-2.4.1.1">2.4.1.1</a>.  Confidentiality Violations</span>

   Confidentiality violations can occur when a miscreant intercepts any
   of the routing update traffic.  This is becoming more of a concern
   because many ISPs are classifying addressing schemes and network
   topologies as private and proprietary information.  It is also a
   concern because the routing protocol packets contain information that
   may show ways in which routing sessions could be spoofed or hijacked.
   This in turn could lead into a man-in-the-middle attack, where the
   miscreants can insert themselves into the traffic path or divert the
   traffic path and violate the confidentiality of user data.

<span class="h5"><a class="selflink" id="section-2.4.1.2" href="#section-2.4.1.2">2.4.1.2</a>.  Offline Cryptographic Attacks</span>

   If any cryptographic mechanism was used to provide for data integrity
   and confidentiality, an offline cryptographic attack could
   potentially compromise the data.  The traffic would need to be
   captured either by eavesdropping on the network or by being able to
   divert traffic to a malicious user.  Note that by using
   cryptographically protected routing information, the latter would
   require the cryptographic key to already be compromised anyway, so
   this attack is only feasible if a device was able to eavesdrop and
   capture the cryptographically protected routing information.

<span class="h5"><a class="selflink" id="section-2.4.1.3" href="#section-2.4.1.3">2.4.1.3</a>.  Replay Attacks</span>

   For a replay attack to be successful, the routing control plane
   traffic would need to first be captured either on-path or diverted to
   an attacker to later be replayed to the intended recipient.
   Additionally, since many of these protocols include replay protection
   mechanisms, these would also need to be subverted, if applicable.

<span class="h5"><a class="selflink" id="section-2.4.1.4" href="#section-2.4.1.4">2.4.1.4</a>.  Message Insertion/Deletion/Modification</span>

   Routing control plane traffic can be manipulated by someone in
   control of intermediate hosts.  In addition, traffic can be injected
   by forging IP addresses, where a remote router sends out packets that
   appear to come from another, trusted router.  If enough traffic is
   injected to be processed by limited memory routers, it can cause a
   DoS attack.

<span class="h5"><a class="selflink" id="section-2.4.1.5" href="#section-2.4.1.5">2.4.1.5</a>.  Man-In-The-Middle</span>

   A man-in-the-middle attack attacks the identity of a communicating
   peer rather than the data stream itself.  The attacker intercepts
   traffic that is sent from one routing peer to the other and
   communicates on behalf of one of the peers.  This can lead to a
   diversion of the user traffic to either an unauthorized receiving



<span class="grey">Kaeo                         Informational                     [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   party or cause legitimate traffic to never reach its intended
   destination.

<span class="h4"><a class="selflink" id="section-2.4.2" href="#section-2.4.2">2.4.2</a>.  Security Practices</span>

   Securing the routing control plane takes many features, which are
   generally deployed as a system.  Message Digest 5 (MD5)
   authentication is used by some ISPs to validate the sending peer and
   to ensure that the data in transit has not been altered.  Some ISPs
   only deploy MD5 authentication at the customers' request.  Additional
   sanity checks to ensure with reasonable certainty that the received
   routing update was originated by a valid routing peer include route
   filters and the Generalized TTL Security Mechanism (GTSM) feature
   [<a href="./rfc3682" title="&quot;The Generalized TTL Security Mechanism (GTSM)&quot;">RFC3682</a>] (sometimes also referred to as the TTL-Hack).  The GTSM
   feature is used for protocols such as the Border Gateway Protocol
   (BGP), and makes use of a packet's Time To Live (TTL) field (IPv4) or
   Hop Limit (IPv6) to protect communicating peers.  If GTSM is used, it
   is typically deployed only in limited scenarios between internal BGP
   peers due to lack of consistent support between vendor products and
   operating system versions.

   Packet filters are used to limit which systems can appear as a valid
   peer, while route filters are used to limit which routes are believed
   to be from a valid peer.  In the case of BGP routing, a variety of
   policies are deployed to limit the propagation of invalid routing
   information.  These include: incoming and outgoing prefix filters for
   BGP customers, incoming and outgoing prefix filters for peers and
   upstream neighbors, incoming AS-PATH filter for BGP customers,
   outgoing AS-PATH filter towards peers and upstream neighbors, route
   dampening and rejecting selected attributes and communities.
   Consistency between these policies varies greatly and there is a
   definite distinction whether the other end is an end-site vs an
   internal peer vs another big ISP or customer.  Mostly ISPs do
   prefix-filter their end-site customers, but due to the operational
   constraints of maintaining large prefix filter lists, many ISPs are
   starting to depend on BGP AS-PATH filters to/from their peers and
   upstream neighbors.

   In cases where prefix lists are not used, operators often define a
   maximum prefix limit per peer to prevent misconfiguration (e.g.,
   unintentional de-aggregation or neighbor routing policy
   mis-configuration) or overload attacks.  ISPs need to coordinate with
   each other what the expected prefix exchange is, and increase this
   number by some sane amount.  It is important for ISPs to pad the
   max-prefix number enough to allow for valid swings in routing
   announcements, preventing an unintentional shut down of the BGP
   session.  Individual implementation amongst ISPs are unique, and
   depending on equipment supplier(s), different implementation options



<span class="grey">Kaeo                         Informational                     [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   are available.  Most equipment vendors offer implementation options
   ranging from just logging excessive prefixes being received, to
   automatically shutting down the session.  If the option of
   reestablishing a session after some pre-configured idle timeout has
   been reached is available, it should be understood that automatically
   reestablishing the session may potentially introduce instability
   continuously into the overall routing table if a policy
   mis-configuration on the adjacent neighbor is causing the condition.
   If a serious mis-configuration on a peering neighbor has occurred,
   then automatically shutting down the session and leaving it shut down
   until being manually cleared, is sometimes best and allows for
   operator intervention to correct as needed.

   Some large ISPs require that routes be registered in an Internet
   Routing Registry (IRR), which can then be part of the Routing Assets
   Database (RADb) - a public registry of routing information for
   networks in the Internet that can be used to generate filter lists.
   Some ISPs, especially in Europe, require registered routes before
   agreeing to become an eBGP peer with someone.

   Many ISPs also do not propagate interface IP addresses to further
   reduce attack vectors on routers and connected customers.

<span class="h4"><a class="selflink" id="section-2.4.3" href="#section-2.4.3">2.4.3</a>.  Security Services</span>

   o  User Authentication - Not applicable.

   o  User Authorization - Not applicable.

   o  Data Origin Authentication - By using MD5 authentication and/or
      the TTL-hack, a routing peer can be reasonably certain that
      traffic originated from a valid peer.

   o  Access Control - Route filters, AS-PATH filters, and prefix limits
      are used to control access to specific parts of the network.

   o  Data Integrity - By using MD5 authentication, a peer can be
      reasonably certain that the data has not been modified in transit,
      but there is no mechanism to prove the validity of the routing
      information itself.

   o  Data Confidentiality - Not implemented.

   o  Auditing / Logging - Filter exceptions are logged.







<span class="grey">Kaeo                         Informational                     [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   o  DoS Mitigation - Many DoS attacks are mitigated using a
      combination of techniques including: MD5 authentication, the GTSM
      feature, filtering routing advertisements to bogons, and filtering
      routing advertisements to one's own network.

<span class="h4"><a class="selflink" id="section-2.4.4" href="#section-2.4.4">2.4.4</a>.  Additional Considerations</span>

   So far the primary concern to secure the routing control plane has
   been to validate the sending peer and to ensure that the data in
   transit has not been altered.  Although MD5 routing protocol
   extensions have been implemented, which can provide both services,
   they are not consistently deployed amongst ISPs.  Two major
   deployment concerns have been implementation issues, where both
   software bugs and the lack of graceful re-keying options have caused
   significant network down times.  Also, some ISPs express concern that
   deploying MD5 authentication will itself be a worse DoS attack victim
   and prefer to use a combination of other risk mitigation mechanisms
   such as GTSM (for BGP) and route filters.  An issue with GTSM is that
   it is not supported on all devices across different vendors'
   products.

   IPsec is not deployed since the operational management aspects of
   ensuring interoperability and reliable configurations is too complex
   and time consuming to be operationally viable.  There is also limited
   concern to the confidentiality of the routing information.  The
   integrity and validity of the updates are of much greater concern.

   There is concern for manual or automated actions, which introduce new
   routes and can affect the entire routing domain.

<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>.  Software Upgrades and Configuration Integrity/Validation</span>

   Software upgrades and configuration changes are usually performed as
   part of either in-band or OOB management functions.  However, there
   are additional considerations to be taken into account, which are
   enumerated in this section.

<span class="h4"><a class="selflink" id="section-2.5.1" href="#section-2.5.1">2.5.1</a>.  Threats/Attacks</span>

   Attacks performed on system software and configurations can be both
   from passive or active sources.  Passive attacks are possible if
   someone has the capability to intercept data between the network
   infrastructure device and the system which is downloading or
   uploading the software or configuration information.  This can be
   accomplished if a single infrastructure device is somehow compromised
   and can act as a network sniffer, or if it is possible to insert a
   new device that acts as a network sniffer.




<span class="grey">Kaeo                         Informational                     [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   Active attacks are possible for both on-path and off-path scenarios.
   For on-path active attacks, the situation is the same as for a
   passive attack, where either a device has to already be compromised
   or a device can be inserted into the path.  For off-path active
   attacks, the attacks are generally limited to message insertion or
   modification where the attacker may wish to load illegal software or
   configuration files to an infrastructure device.

   Note that similar issues are relevant when software updates are
   downloaded from a vendor site to an ISPs network management system
   that is responsible for software updates and/or configuration
   information.

<span class="h5"><a class="selflink" id="section-2.5.1.1" href="#section-2.5.1.1">2.5.1.1</a>.  Confidentiality Violations</span>

   Confidentiality violations can occur when a miscreant intercepts any
   of the software image or configuration information.  The software
   image may give an indication of exploits which the device is
   vulnerable to while the configuration information can inadvertently
   lead attackers to identify critical infrastructure IP addresses and
   passwords.

<span class="h5"><a class="selflink" id="section-2.5.1.2" href="#section-2.5.1.2">2.5.1.2</a>.  Offline Cryptographic Attacks</span>

   If any cryptographic mechanism was used to provide for data integrity
   and confidentiality, an offline cryptographic attack could
   potentially compromise the data.  The traffic would need to be
   captured either by eavesdropping on the communication path or by
   being able to divert traffic to a malicious user.

<span class="h5"><a class="selflink" id="section-2.5.1.3" href="#section-2.5.1.3">2.5.1.3</a>.  Replay Attacks</span>

   For a replay attack to be successful, the software image or
   configuration file would need to first be captured either on-path or
   diverted to an attacker to later be replayed to the intended
   recipient.  Additionally, since many protocols do have replay
   protection capabilities, these would have to be subverted as well in
   applicable situations.

<span class="h5"><a class="selflink" id="section-2.5.1.4" href="#section-2.5.1.4">2.5.1.4</a>.  Message Insertion/Deletion/Modification</span>

   Software images and configuration files can be manipulated by someone
   in control of intermediate hosts.  By forging an IP address and
   impersonating a valid host which can download software images or
   configuration files, invalid files can be downloaded to an
   infrastructure device.  This can also be the case from trusted
   vendors who may unbeknownst to them have compromised trusted hosts.
   An invalid software image or configuration file can cause a device to



<span class="grey">Kaeo                         Informational                     [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   hang and become inoperable.  Spoofed configuration files can be hard
   to detect, especially when the only added command is to allow a
   miscreant access to that device by entering a filter allowing a
   specific host access and configuring a local username/password
   database entry for authentication to that device.

<span class="h5"><a class="selflink" id="section-2.5.1.5" href="#section-2.5.1.5">2.5.1.5</a>.  Man-In-The-Middle</span>

   A man-in-the-middle attack attacks the identity of a communicating
   peer rather than the data stream itself.  The attacker intercepts
   traffic that is sent between the infrastructure device and the host
   used to upload/download the system image or configuration file.
   He/she can then act on behalf of one or both of these systems.

   If an attacker obtained a copy of the software image being deployed,
   he could potentially exploit a known vulnerability and gain access to
   the system.  From a captured configuration file, he could obtain
   confidential network topology information, or even more damaging
   information, if any of the passwords in the configuration file were
   not encrypted.

<span class="h4"><a class="selflink" id="section-2.5.2" href="#section-2.5.2">2.5.2</a>.  Security Practices</span>

   Images and configurations are stored on specific hosts that have
   limited access.  All access and activity relating to these hosts are
   authenticated and logged via AAA services.  When uploaded/downloading
   any system software or configuration files, either TFTP, FTP, or SCP
   can be used.  Where possible, SCP is used to secure the data transfer
   and FTP is generally never used.  All SCP access is username/password
   authenticated but since this requires an interactive shell, most ISPs
   will use shared key authentication to avoid the interactive shell.
   While TFTP access does not have any security measures, it is still
   widely used, especially in OOB management scenarios.  Some ISPs
   implement IP-based restriction on the TFTP server, while some custom
   written TFTP servers will support MAC-based authentication.  The
   MAC-based authentication is more common when using TFTP to bootstrap
   routers remotely.

   In most environments, scripts are used for maintaining the images and
   configurations of a large number of routers.  To ensure the integrity
   of the configurations, every hour the configuration files are polled
   and compared to the previously polled version to find discrepancies.
   In at least one environment these, tools are Kerberized to take
   advantage of automated authentication (not confidentiality).
   'Rancid' is one popular publicly available tool for detecting
   configuration and system changes.





<span class="grey">Kaeo                         Informational                     [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   Filters are used to limit access to uploading/downloading
   configuration files and system images to specific IP addresses and
   protocols.

   The software images perform Cyclic Redundancy Checks (CRC) and the
   system binaries use the MD5 algorithm to validate integrity.  Many
   ISPs expressed interest in having software image integrity validation
   based on the MD5 algorithm for enhanced security.

   In all configuration files, most passwords are stored in an encrypted
   format.  Note that the encryption techniques used in varying products
   can vary and that some weaker encryption schemes may be subject to
   off-line dictionary attacks.  This includes passwords for user
   authentication, MD5-authentication shared secrets, AAA server shared
   secrets, NTP shared secrets, etc.  For older software that may not
   support this functionality, configuration files may contain some
   passwords in readable format.  Most ISPs mitigate any risk of
   password compromise by either storing these configuration files
   without the password lines or by requiring authenticated and
   authorized access to the configuration files that are stored on
   protected OOB management devices.

   Automated security validation is performed on infrastructure devices
   using Network Mapping (Nmap) and Nessus to ensure valid configuration
   against many of the well-known attacks.

<span class="h4"><a class="selflink" id="section-2.5.3" href="#section-2.5.3">2.5.3</a>.  Security Services</span>

   o  User Authentication - All users are authenticated before being
      able to download/upload any system images or configuration files.

   o  User Authorization - All authenticated users are granted specific
      privileges to download or upload system images and/or
      configuration files.

   o  Data Origin Authentication - Filters are used to limit access to
      uploading/downloading configuration files and system images to
      specific IP addresses.

   o  Access Control - Filters are used to limit access to uploading/
      downloading configuration files and system images to specific IP
      addresses and protocols.

   o  Data Integrity - All systems use either a CRC-check or MD5
      authentication to ensure data integrity.  Also, tools such as
      rancid are used to automatically detect configuration changes.





<span class="grey">Kaeo                         Informational                     [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   o  Data Confidentiality - If the SCP protocol is used then there is
      confidentiality of the downloaded/uploaded configuration files and
      system images.

   o  Auditing/Logging - All access and activity relating to
      downloading/uploading system images and configuration files are
      logged via AAA services and filter exception rules.

   o  DoS Mitigation - A combination of filtering and CRC-check/
      MD5-based integrity checks are used to mitigate the risks of DoS
      attacks.  If the software updates and configuration changes are
      performed via an OOB management system, this is also added
      protection.

<span class="h4"><a class="selflink" id="section-2.5.4" href="#section-2.5.4">2.5.4</a>.  Additional Considerations</span>

   Where the MD5 algorithm is not used to perform data-integrity
   checking of software images and configuration files, ISPs have
   expressed an interest in having this functionality.  IPsec is
   considered too cumbersome and operationally difficult to use for data
   integrity and confidentiality.

<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>.  Logging Considerations</span>

   Although logging is part of all the previous sections, it is
   important enough to be covered as a separate item.  The main issues
   revolve around what gets logged, how long are logs kept, and what
   mechanisms are used to secure the logged information while it is in
   transit and while it is stored.

<span class="h4"><a class="selflink" id="section-2.6.1" href="#section-2.6.1">2.6.1</a>.  Threats/Attacks</span>

   Attacks on the logged data can be both from passive or active
   sources.  Passive attacks are possible if someone has the capability
   to intercept data between the recipient logging server and the device
   from which the logged data originated.  This can be accomplished if a
   single infrastructure device is somehow compromised and can act as a
   network sniffer, or if it is possible to insert a new device that
   acts as a network sniffer.

   Active attacks are possible for both on-path and off-path scenarios.
   For on-path active attacks, the situation is the same as for a
   passive attack, where either a device has to already be compromised,
   or a device can be inserted into the path.  For off-path active
   attacks, the attacks are generally limited to message insertion or
   modification that can alter the logged data to keep any compromise
   from being detected, or to destroy any evidence that could be used
   for criminal prosecution.



<span class="grey">Kaeo                         Informational                     [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


<span class="h5"><a class="selflink" id="section-2.6.1.1" href="#section-2.6.1.1">2.6.1.1</a>.  Confidentiality Violations</span>

   Confidentiality violations can occur when a miscreant intercepts any
   of the logging data that is in transit on the network.  This could
   lead to privacy violations if some of the logged data has not been
   sanitized to disallow any data that could be a violation of privacy
   to be included in the logged data.

<span class="h5"><a class="selflink" id="section-2.6.1.2" href="#section-2.6.1.2">2.6.1.2</a>.  Offline Cryptographic Attacks</span>

   If any cryptographic mechanism was used to provide for data integrity
   and confidentiality, an offline cryptographic attack could
   potentially compromise the data.  The traffic would need to be
   captured either by eavesdropping on the network or by being able to
   divert traffic to a malicious user.

<span class="h5"><a class="selflink" id="section-2.6.1.3" href="#section-2.6.1.3">2.6.1.3</a>.  Replay Attacks</span>

   For a replay attack to be successful, the logging data would need to
   first be captured either on-path or diverted to an attacker and later
   replayed to the recipient.

<span class="h5"><a class="selflink" id="section-2.6.1.4" href="#section-2.6.1.4">2.6.1.4</a>.  Message Insertion/Deletion/Modification</span>

   Logging data could be injected, deleted, or modified by someone in
   control of intermediate hosts.  Logging data can also be injected by
   forging packets from either legitimate or illegitimate IP addresses.

<span class="h5"><a class="selflink" id="section-2.6.1.5" href="#section-2.6.1.5">2.6.1.5</a>.  Man-In-The-Middle</span>

   A man-in-the-middle attack attacks the identity of a communicating
   peer rather than the data stream itself.  The attacker intercepts
   traffic that is sent between the infrastructure device and the
   logging server or traffic sent between the logging server and the
   database that is used to archive the logged data.  Any unauthorized
   access to logging information could lead to the knowledge of private
   and proprietary network topology information, which could be used to
   compromise portions of the network.  An additional concern is having
   access to logging information, which could be deleted or modified so
   as to cover any traces of a security breach.

<span class="h4"><a class="selflink" id="section-2.6.2" href="#section-2.6.2">2.6.2</a>.  Security Practices</span>

   When it comes to filtering, logging is mostly performed on an
   exception auditing basis (i.e., traffic that is NOT allowed is
   logged).  This is to assure that the logging servers are not
   overwhelmed with data, which would render most logs unusable.
   Typically the data logged will contain the source and destination IP



<span class="grey">Kaeo                         Informational                     [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   addresses and layer 4 port numbers as well as a timestamp.  The
   syslog protocol is used to transfer the logged data between the
   infrastructure device to the syslog server.  Many ISPs use the OOB
   management network to transfer syslog data since there is virtually
   no security performed between the syslog server and the device.  All
   ISPs have multiple syslog servers - some ISPs choose to use separate
   syslog servers for varying infrastructure devices (i.e., one syslog
   server for backbone routers, one syslog server for customer edge
   routers, etc.)

   The timestamp is derived from NTP, which is generally configured as a
   flat hierarchy at stratum1 and stratum2 to have less configuration
   and less maintenance.  Consistency of configuration and redundancy is
   the primary goal.  Each router is configured with several stratum1
   server sources, which are chosen to ensure that proper NTP time is
   available, even in the event of varying network outages.

   In addition to logging filtering exceptions, the following is
   typically logged: routing protocol state changes, all device access
   (regardless of authentication success or failure), all commands
   issued to a device, all configuration changes, and all router events
   (boot-up/flaps).

   The main function of any of these log messages is to see what the
   device is doing as well as to try and ascertain what certain
   malicious attackers are trying to do.  Since syslog is an unreliable
   protocol, when routers boot or lose adjacencies, not all messages
   will get delivered to the remote syslog server.  Some vendors may
   implement syslog buffering (e.g., buffer the messages until you have
   a route to the syslog destination), but this is not standard.
   Therefore, operators often have to look at local syslog information
   on a device (which typically has very little memory allocated to it)
   to make up for the fact that the server-based syslog files can be
   incomplete.  Some ISPs also put in passive devices to see routing
   updates and withdrawals and do not rely solely on the device for log
   files.  This provides a backup mechanism to see what is going on in
   the network in the event that a device may 'forget' to do syslog if
   the CPU is busy.

   The logs from the various syslog server devices are generally
   transferred into databases at a set interval that can be anywhere
   from every 10 minutes to every hour.  One ISP uses Rsync to push the
   data into a database, and then the information is sorted manually by
   someone SSH'ing to that database.







<span class="grey">Kaeo                         Informational                     [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


<span class="h4"><a class="selflink" id="section-2.6.3" href="#section-2.6.3">2.6.3</a>.  Security Services</span>

   o  User Authentication - Not applicable.

   o  User Authorization - Not applicable.

   o  Data Origin Authentication - Not implemented.

   o  Access Control - Filtering on logging host and server IP address
      to ensure that syslog information only goes to specific syslog
      hosts.

   o  Data Integrity - Not implemented.

   o  Data Confidentiality - Not implemented.

   o  Auditing/Logging - This entire section deals with logging.

   o  DoS Mitigation - An OOB management system is used and sometimes
      different syslog servers are used for logging information from
      varying equipment.  Exception logging tries to keep information to
      a minimum.

<span class="h4"><a class="selflink" id="section-2.6.4" href="#section-2.6.4">2.6.4</a>.  Additional Considerations</span>

   There is no security with syslog and ISPs are fully cognizant of
   this.  IPsec is considered too operationally expensive and cumbersome
   to deploy.  Syslog-ng and stunnel are being looked at for providing
   better authenticated and integrity-protected solutions.  Mechanisms
   to prevent unauthorized personnel from tampering with logs is
   constrained to auditing who has access to the logging servers and
   files.

   ISPs expressed requirements for more than just UDP syslog.
   Additionally, they would like more granular and flexible facilities
   and priorities, i.e., specific logs to specific servers.  Also, a
   common format for reporting standard events so that modifying parsers
   after each upgrade of a vendor device or software is not necessary.

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

   Although filtering has been covered under many of the previous
   sections, this section will provide some more insights to the
   filtering considerations that are currently being taken into account.
   Filtering is now being categorized into three specific areas: data
   plane, management plane, and routing control plane.





<span class="grey">Kaeo                         Informational                     [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


<span class="h4"><a class="selflink" id="section-2.7.1" href="#section-2.7.1">2.7.1</a>.  Data Plane Filtering</span>

   Data plane filters control the traffic that traverses through a
   device and affects transit traffic.  Most ISPs deploy these kinds of
   filters at customer facing edge devices to mitigate spoofing attacks
   using <a href="https://www.rfc-editor.org/bcp/bcp38">BCP38</a> and <a href="https://www.rfc-editor.org/bcp/bcp84">BCP84</a> guidelines.

<span class="h4"><a class="selflink" id="section-2.7.2" href="#section-2.7.2">2.7.2</a>.  Management Plane Filtering</span>

   Management filters control the traffic to and from a device.  All of
   the protocols that are used for device management fall under this
   category and include: SSH, Telnet, SNMP, NTP, HTTP, DNS, TFTP, FTP,
   SCP, and Syslog.  This type of traffic is often filtered per
   interface and is based on any combination of protocol, source and
   destination IP address, and source and destination port number.  Some
   devices support functionality to apply management filters to the
   device rather than to the specific interfaces (e.g., receive ACL or
   loopback interface ACL), which is gaining wider acceptance.  Note
   that logging the filtering rules can today place a burden on many
   systems and more granularity is often required to more specifically
   log the required exceptions.

   Any services that are not specifically used are turned off.

   IPv6 networks require the use of specific ICMP messages for proper
   protocol operation.  Therefore, ICMP cannot be completely filtered to
   and from a device.  Instead, granular ICMPv6 filtering is always
   deployed to allow for specific ICMPv6 types to be sourced or destined
   to a network device.  A good guideline for IPv6 filtering is in the
   Recommendations for Filtering ICMPv6 Messages in Firewalls [<a href="#ref-ICMPv6" title="&quot;Recommendations for Filtering ICMPv6 Messages in Firewalls&quot;">ICMPv6</a>].

<span class="h4"><a class="selflink" id="section-2.7.3" href="#section-2.7.3">2.7.3</a>.  Routing Control Plane Filtering</span>

   Routing filters are used to control the flow of routing information.
   In IPv6 networks, some providers are liberal in accepting /48s due to
   the still unresolved multihoming issues, while others filter at
   allocation boundaries, which are typically at /32.  Any announcement
   received that is longer than a /48 for IPv6 routing and a /24 for
   IPv4 routing is filtered out of eBGP.  Note that this is for
   non-customer traffic.  Most ISPs will accept any agreed upon prefix
   length from its customer(s).

<span class="h3"><a class="selflink" id="section-2.8" href="#section-2.8">2.8</a>.  Denial-of-Service Tracking/Tracing</span>

   Denial-of-Service attacks are an ever-increasing problem and require
   vast amounts of resources to combat effectively.  Some large ISPs do
   not concern themselves with attack streams that are less than 1G in
   bandwidth - this is on the larger pipes where 1G is essentially less



<span class="grey">Kaeo                         Informational                     [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   than 5% of an offered load.  This is largely due to the large amounts
   of DoS traffic, which continually requires investigation and
   mitigation.  At last count, the number of hosts making up large
   distributed DoS botnets exceeded 1 million hosts.

   New techniques are continually evolving to automate the process of
   detecting DoS sources and mitigating any adverse effects as quickly
   as possible.  At this time, ISPs are using a variety of mitigation
   techniques including: sinkhole routing, black hole triggered routing,
   uRPF, rate limiting, and specific control plane traffic enhancements.
   Each of these techniques will be detailed below.

<span class="h4"><a class="selflink" id="section-2.8.1" href="#section-2.8.1">2.8.1</a>.  Sinkhole Routing</span>

   Sinkhole routing refers to injecting a more specific route for any
   known attack traffic, which will ensure that the malicious traffic is
   redirected to a valid device or specific system where it can be
   analyzed.

<span class="h4"><a class="selflink" id="section-2.8.2" href="#section-2.8.2">2.8.2</a>.  Black Hole Triggered Routing</span>

   Black hole triggered routing (also referred to as Remote Triggered
   Black Hole Filtering) is a technique where the BGP routing protocol
   is used to propagate routes which in turn redirects attack traffic to
   the null interface where it is effectively dropped.  This technique
   is often used in large routing infrastructures since BGP can
   propagate the information in a fast, effective manner, as opposed to
   using any packet-based filtering techniques on hundreds or thousands
   of routers (refer to the following NANOG presentation for a more
   complete description <a href="http://www.nanog.org/mtg-0402/pdf/morrow.pdf">http://www.nanog.org/mtg-0402/pdf/morrow.pdf</a>).

   Note that this black-holing technique may actually fulfill the goal
   of the attacker if the goal was to instigate black-holing traffic
   that appeared to come from a certain site.  On the other hand, this
   black hole technique can decrease the collateral damage caused by an
   overly large attack aimed at something other than critical services.

<span class="h4"><a class="selflink" id="section-2.8.3" href="#section-2.8.3">2.8.3</a>.  Unicast Reverse Path Forwarding</span>

   Unicast Reverse Path Forwarding (uRPF) is a mechanism for validating
   whether or not an incoming packet has a legitimate source address.
   It has two modes: strict mode and loose mode.  In strict mode, uRPF
   checks whether the incoming packet has a source address that matches
   a prefix in the routing table, and whether the interface expects to
   receive a packet with this source address prefix.  If the incoming
   packet fails the unicast RPF check, the packet is not accepted on the





<span class="grey">Kaeo                         Informational                     [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


   incoming interface.  Loose mode uRPF is not as specific and the
   incoming packet is accepted if there is any route in the routing
   table for the source address.

   While <a href="https://www.rfc-editor.org/bcp/bcp84">BCP84</a> [<a href="./rfc3704" title="&quot;Ingress Filtering for Multihomed Networks&quot;">RFC3704</a>] and a study on uRPF experiences [<a href="#ref-BCP84-URPF" title="&quot;Experiences from Using Unicast RPF&quot;">BCP84-URPF</a>]
   detail how asymmetry, i.e., multiple routes to the source of a
   packet, does not preclude applying feasible paths strict uRPF, it is
   generally not used on interfaces that are likely to have routing
   asymmetry.  Usually for the larger ISPs, uRPF is placed at the
   customer edge of a network.

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

   Rate limiting refers to allocating a specific amount of bandwidth or
   packets per second to specific traffic types.  This technique is
   widely used to mitigate well-known protocol attacks such as the
   TCP-SYN attack, where a large number of resources get allocated for
   spoofed TCP traffic.  Although this technique does not stop an
   attack, it can sometimes lessen the damage and impact on a specific
   service.  However, it can also make the impact of a DoS attack much
   worse if the rate limiting is impacting (i.e., discarding) more
   legitimate traffic.

<span class="h4"><a class="selflink" id="section-2.8.5" href="#section-2.8.5">2.8.5</a>.  Specific Control Plane Traffic Enhancements</span>

   Some ISPs are starting to use capabilities that are available from
   some vendors to simplify the filtering and rate limiting of control
   traffic.  Control traffic here refers to the routing control plane
   and management plane traffic that requires CPU cycles.  A DoS attack
   against any control plane traffic can therefore be much more damaging
   to a critical device than other types of traffic.  No consistent
   deployment of this capability was found at the time of this writing.

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

   This entire document deals with current security practices in large
   ISP environments.  It lists specific practices used in today's
   environments and as such, does not in itself pose any security risk.

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

   The editor gratefully acknowledges the contributions of: George
   Jones, who has been instrumental in providing guidance and direction
   for this document, and the insightful comments from Ross Callon, Ron
   Bonica, Ryan Mcdowell, Gaurab Upadhaya, Warren Kumari, Pekka Savola,
   Fernando Gont, Chris Morrow, Ted Seely, Donald Smith, and the
   numerous ISP operators who supplied the information that is depicted
   in this document.



<span class="grey">Kaeo                         Informational                     [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


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

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

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

   [<a id="ref-RFC2828">RFC2828</a>]     Shirey, R., "Internet Security Glossary", <a href="./rfc2828">RFC 2828</a>,
                 May 2000.

   [<a id="ref-RFC3552">RFC3552</a>]     Rescorla, E. and B. Korver, "Guidelines for Writing RFC
                 Text on Security Considerations", <a href="https://www.rfc-editor.org/bcp/bcp72">BCP 72</a>, <a href="./rfc3552">RFC 3552</a>,
                 July 2003.

   [<a id="ref-RFC3682">RFC3682</a>]     Gill, V., Heasley, J., and D. Meyer, "The Generalized
                 TTL Security Mechanism (GTSM)", <a href="./rfc3682">RFC 3682</a>,
                 February 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-RFC3882">RFC3882</a>]     Turk, D., "Configuring BGP to Block Denial-of-Service
                 Attacks", <a href="./rfc3882">RFC 3882</a>, September 2004.

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

   [<a id="ref-BCP84-URPF">BCP84-URPF</a>]  Savola, P., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22Experiences+from+Using+Unicast+RPF%22'>"Experiences from Using Unicast RPF"</a>, Work
                 in Progress, November 2006.

   [<a id="ref-ICMPv6">ICMPv6</a>]      Davies, E. and J. Mohacsi, "Recommendations for
                 Filtering ICMPv6 Messages in Firewalls", Work
                 in Progress, July 2006.

   [<a id="ref-RTGWG">RTGWG</a>]       Savola, P., "Backbone Infrastructure Attacks and
                 Protections", Work in Progress, July 2006.















<span class="grey">Kaeo                         Informational                     [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Protocol Specific Attacks</span>

   This section will list many of the traditional protocol-based attacks
   that have been observed over the years to cause malformed packets
   and/or exploit protocol deficiencies.  Note that they all exploit
   vulnerabilities in the actual protocol itself and often, additional
   authentication and auditing mechanisms are now used to detect and
   mitigate the impact of these attacks.  The list is not exhaustive,
   but is a fraction of the representation of what types of attacks are
   possible for varying protocols.

<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>.  Layer 2 Attacks</span>

   o  ARP Flooding

<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>.  IPv4 Protocol-Based Attacks</span>

   o  IP Addresses, either source or destination, can be spoofed which
      in turn can circumvent established filtering rules.

   o  IP Source Route Option can allows attackers to establish stealth
      TCP connections.

   o  IP Record Route Option can disclose information about the topology
      of the network.

   o  IP header that is too long or too short can cause DoS attacks to
      devices.

   o  IP Timestamp Option can leak information that can be used to
      discern network behavior.

   o  Fragmentation attacks which can vary widely - more detailed
      information can be found at <a href="http://www-src.lip6.fr/homepages/Fabrice.Legond-Aubry/www.ouah.org/fragma.html">http://www-src.lip6.fr/homepages/</a>
      <a href="http://www-src.lip6.fr/homepages/Fabrice.Legond-Aubry/www.ouah.org/fragma.html">Fabrice.Legond-Aubry/www.ouah.org/fragma.html</a>.

   o  IP ToS field (or the Differentiated Services (DSCP) field) can be
      used to reroute or reclassify traffic based on specified
      precedence.

   o  IP checksum field has been used for scanning purposes, for example
      when some firewalls did not check the checksum and allowed an
      attacker to differentiate when the response came from an end-
      system, and when from a firewall.

   o  IP TTL field can be used to bypass certain network-based intrusion
      detection systems and to map network behavior.




<span class="grey">Kaeo                         Informational                     [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


<span class="h4"><a class="selflink" id="appendix-A.2.1" href="#appendix-A.2.1">A.2.1</a>.  Higher Layer Protocol Attacks</span>

   The following lists additional attacks, but does not explicitly
   numerate them in detail.  It is for informational purposes only.

   o  IGMP oversized packet

   o  ICMP Source Quench

   o  ICMP Mask Request

   o  ICMP Large Packet (&gt; 1472)

   o  ICMP Oversized packet (&gt;65536)

   o  ICMP Flood

   o  ICMP Broadcast w/ Spoofed Source (Smurf Attack)

   o  ICMP Error Packet Flood

   o  ICMP Spoofed Unreachable

   o  TCP Packet without Flag

   o  TCP Oversized Packet

   o  TCP FIN bit with no ACK bit

   o  TCP Packet with URG/OOB flag (Nuke Attack)

   o  SYN Fragments

   o  SYN Flood

   o  SYN with IP Spoofing (Land Attack)

   o  SYN and FIN bits set

   o  TCP port scan attack

   o  UDP spoofed broadcast echo (Fraggle Attack)

   o  UDP attack on diagnostic ports (Pepsi Attack)







<span class="grey">Kaeo                         Informational                     [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


<span class="h3"><a class="selflink" id="appendix-A.3" href="#appendix-A.3">A.3</a>.  IPv6 Attacks</span>

   Any of the above-mentioned IPv4 attacks could be used in IPv6
   networks with the exception of any fragmentation and broadcast
   traffic, which operate differently in IPv6.  Note that all of these
   attacks are based on either spoofing or misusing any part of the
   protocol field(s).

   Today, IPv6-enabled hosts are starting to be used to create IPv6
   tunnels, which can effectively hide botnet and other malicious
   traffic if firewalls and network flow collection tools are not
   capable of detecting this traffic.  The security measures used for
   protecting IPv6 infrastructures should be the same as in IPv4
   networks, but with additional considerations for IPv6 network
   operations, which may be different from IPv4.

Author's Address

   Merike Kaeo
   Double Shot Security, Inc.
   3518 Fremont Avenue North #363
   Seattle, WA  98103
   U.S.A.

   Phone: +1 310 866 0165
   EMail: merike@doubleshotsecurity.com

























<span class="grey">Kaeo                         Informational                     [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc4778">RFC 4778</a>                    OPSEC Practices                 January 2007</span>


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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.







Kaeo                         Informational                     [Page 37]
</pre>