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


              Current Operational Security Practices in
                Internet Service Provider Environments

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.

























Kaeo                         Informational                      [Page 1]

RFC 4778                    OPSEC Practices                 January 2007


Table of Contents

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

1.  Introduction

  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.

1.1.  Scope

  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



Kaeo                         Informational                      [Page 2]

RFC 4778                    OPSEC Practices                 January 2007


  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.

1.2.  Threat Model

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




Kaeo                         Informational                      [Page 3]

RFC 4778                    OPSEC Practices                 January 2007


  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.

1.3.  Attack Sources

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

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







Kaeo                         Informational                      [Page 4]

RFC 4778                    OPSEC Practices                 January 2007


  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.

1.4.  Operational Security Impact from Threats

  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.






Kaeo                         Informational                      [Page 5]

RFC 4778                    OPSEC Practices                 January 2007


  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 [RFC2828].  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 [RTGWG].







Kaeo                         Informational                      [Page 6]

RFC 4778                    OPSEC Practices                 January 2007


1.5.  Document Layout

  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.









Kaeo                         Informational                      [Page 7]

RFC 4778                    OPSEC Practices                 January 2007


2.  Protected Operational Functions

2.1.  Device Physical Access

  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.

2.1.1.  Threats/Attacks

  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.

2.1.2.  Security Practices

  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



Kaeo                         Informational                      [Page 8]

RFC 4778                    OPSEC Practices                 January 2007


  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
  Section 2.2 of this document.

2.1.3.  Security Services

  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.





Kaeo                         Informational                      [Page 9]

RFC 4778                    OPSEC Practices                 January 2007


  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 Section 2.2 of
     this document for more details).

  o  DoS Mitigation - Not applicable.

2.1.4.  Additional Considerations

  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 Section 2.2 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.

2.2.  Device Management - In-Band and Out-of-Band (OOB)

  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



Kaeo                         Informational                     [Page 10]

RFC 4778                    OPSEC Practices                 January 2007


  disabled.  Note that file transfer protocols (TFTP, FTP, and SCP)
  will be covered in Section 2.5 of this document.

2.2.1.  Threats/Attacks

  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.

2.2.1.1.  Confidentiality Violations

  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.

2.2.1.2.  Offline Cryptographic Attacks

  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.

2.2.1.3.  Replay Attacks

  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.








Kaeo                         Informational                     [Page 11]

RFC 4778                    OPSEC Practices                 January 2007


2.2.1.4.  Message Insertion/Deletion/Modification

  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.

2.2.1.5.  Man-In-The-Middle

  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.

2.2.2.  Security Practices

  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.



Kaeo                         Informational                     [Page 12]

RFC 4778                    OPSEC Practices                 January 2007


  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



Kaeo                         Informational                     [Page 13]

RFC 4778                    OPSEC Practices                 January 2007


  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)

2.2.3.  Security Services

  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
     BCP38 [RFC2827] and BCP84 [RFC3704] guidelines (discussed in
     Section 2.5), 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.



Kaeo                         Informational                     [Page 14]

RFC 4778                    OPSEC Practices                 January 2007


2.2.4.  Additional Considerations

  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.




Kaeo                         Informational                     [Page 15]

RFC 4778                    OPSEC Practices                 January 2007


2.3.  Data Path

  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.

2.3.1.  Threats/Attacks

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

2.3.2.  Security Practices

  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 BCP38 [RFC2827] and BCP84 [RFC3704] guidelines for ingress
  filtering.  BCP38 recommends filtering ingress packets with obviously
  spoofed and/or 'reserved' source addresses to limit the effects of
  denial-of-service attacks, while BCP84 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 [RFC3882] are used to
  deter any detected malicious traffic streams.  These two techniques
  are described in more detail in Section 2.8 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



Kaeo                         Informational                     [Page 16]

RFC 4778                    OPSEC Practices                 January 2007


  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.

2.3.3.  Security Services

  o  User Authentication - Not applicable.

  o  User Authorization - Not applicable.

  o  Data Origin Authentication - When IP address filtering per BCP38,
     BCP84, 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.

2.3.4.  Additional Considerations

  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.



Kaeo                         Informational                     [Page 17]

RFC 4778                    OPSEC Practices                 January 2007


  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 BCP38
  and BCP84 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.

2.4.  Routing Control Plane

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

2.4.1.  Threats/Attacks

  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.



Kaeo                         Informational                     [Page 18]

RFC 4778                    OPSEC Practices                 January 2007


2.4.1.1.  Confidentiality Violations

  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.

2.4.1.2.  Offline Cryptographic Attacks

  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.

2.4.1.3.  Replay Attacks

  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.

2.4.1.4.  Message Insertion/Deletion/Modification

  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.

2.4.1.5.  Man-In-The-Middle

  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



Kaeo                         Informational                     [Page 19]

RFC 4778                    OPSEC Practices                 January 2007


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

2.4.2.  Security Practices

  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
  [RFC3682] (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



Kaeo                         Informational                     [Page 20]

RFC 4778                    OPSEC Practices                 January 2007


  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.

2.4.3.  Security Services

  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.







Kaeo                         Informational                     [Page 21]

RFC 4778                    OPSEC Practices                 January 2007


  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.

2.4.4.  Additional Considerations

  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.

2.5.  Software Upgrades and Configuration Integrity/Validation

  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.

2.5.1.  Threats/Attacks

  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.




Kaeo                         Informational                     [Page 22]

RFC 4778                    OPSEC Practices                 January 2007


  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.

2.5.1.1.  Confidentiality Violations

  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.

2.5.1.2.  Offline Cryptographic Attacks

  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.

2.5.1.3.  Replay Attacks

  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.

2.5.1.4.  Message Insertion/Deletion/Modification

  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



Kaeo                         Informational                     [Page 23]

RFC 4778                    OPSEC Practices                 January 2007


  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.

2.5.1.5.  Man-In-The-Middle

  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.

2.5.2.  Security Practices

  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.





Kaeo                         Informational                     [Page 24]

RFC 4778                    OPSEC Practices                 January 2007


  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.

2.5.3.  Security Services

  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.





Kaeo                         Informational                     [Page 25]

RFC 4778                    OPSEC Practices                 January 2007


  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.

2.5.4.  Additional Considerations

  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.

2.6.  Logging Considerations

  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.

2.6.1.  Threats/Attacks

  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.



Kaeo                         Informational                     [Page 26]

RFC 4778                    OPSEC Practices                 January 2007


2.6.1.1.  Confidentiality Violations

  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.

2.6.1.2.  Offline Cryptographic Attacks

  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.

2.6.1.3.  Replay Attacks

  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.

2.6.1.4.  Message Insertion/Deletion/Modification

  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.

2.6.1.5.  Man-In-The-Middle

  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.

2.6.2.  Security Practices

  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



Kaeo                         Informational                     [Page 27]

RFC 4778                    OPSEC Practices                 January 2007


  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.







Kaeo                         Informational                     [Page 28]

RFC 4778                    OPSEC Practices                 January 2007


2.6.3.  Security Services

  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.

2.6.4.  Additional Considerations

  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.

2.7.  Filtering Considerations

  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.





Kaeo                         Informational                     [Page 29]

RFC 4778                    OPSEC Practices                 January 2007


2.7.1.  Data Plane Filtering

  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 BCP38 and BCP84 guidelines.

2.7.2.  Management Plane Filtering

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

2.7.3.  Routing Control Plane Filtering

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

2.8.  Denial-of-Service Tracking/Tracing

  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



Kaeo                         Informational                     [Page 30]

RFC 4778                    OPSEC Practices                 January 2007


  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.

2.8.1.  Sinkhole Routing

  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.

2.8.2.  Black Hole Triggered Routing

  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 http://www.nanog.org/mtg-0402/pdf/morrow.pdf).

  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.

2.8.3.  Unicast Reverse Path Forwarding

  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





Kaeo                         Informational                     [Page 31]

RFC 4778                    OPSEC Practices                 January 2007


  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 BCP84 [RFC3704] and a study on uRPF experiences [BCP84-URPF]
  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.

2.8.4.  Rate Limiting

  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.

2.8.5.  Specific Control Plane Traffic Enhancements

  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.

3.  Security Considerations

  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.

4.  Acknowledgments

  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.



Kaeo                         Informational                     [Page 32]

RFC 4778                    OPSEC Practices                 January 2007


5.  References

5.1.  Normative References

  [RFC2827]     Ferguson, P. and D. Senie, "Network Ingress Filtering:
                Defeating Denial of Service Attacks which employ IP
                Source Address Spoofing", BCP 38, RFC 2827, May 2000.

  [RFC2828]     Shirey, R., "Internet Security Glossary", RFC 2828,
                May 2000.

  [RFC3552]     Rescorla, E. and B. Korver, "Guidelines for Writing RFC
                Text on Security Considerations", BCP 72, RFC 3552,
                July 2003.

  [RFC3682]     Gill, V., Heasley, J., and D. Meyer, "The Generalized
                TTL Security Mechanism (GTSM)", RFC 3682,
                February 2004.

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

  [RFC3882]     Turk, D., "Configuring BGP to Block Denial-of-Service
                Attacks", RFC 3882, September 2004.

5.2.  Informational References

  [BCP84-URPF]  Savola, P., "Experiences from Using Unicast RPF", Work
                in Progress, November 2006.

  [ICMPv6]      Davies, E. and J. Mohacsi, "Recommendations for
                Filtering ICMPv6 Messages in Firewalls", Work
                in Progress, July 2006.

  [RTGWG]       Savola, P., "Backbone Infrastructure Attacks and
                Protections", Work in Progress, July 2006.















Kaeo                         Informational                     [Page 33]

RFC 4778                    OPSEC Practices                 January 2007


Appendix A.  Protocol Specific Attacks

  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.

A.1.  Layer 2 Attacks

  o  ARP Flooding

A.2.  IPv4 Protocol-Based Attacks

  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 http://www-src.lip6.fr/homepages/
     Fabrice.Legond-Aubry/www.ouah.org/fragma.html.

  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.




Kaeo                         Informational                     [Page 34]

RFC 4778                    OPSEC Practices                 January 2007


A.2.1.  Higher Layer Protocol Attacks

  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 (> 1472)

  o  ICMP Oversized packet (>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)







Kaeo                         Informational                     [Page 35]

RFC 4778                    OPSEC Practices                 January 2007


A.3.  IPv6 Attacks

  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: [email protected]

























Kaeo                         Informational                     [Page 36]

RFC 4778                    OPSEC Practices                 January 2007


Full Copyright Statement

  Copyright (C) The IETF Trust (2007).

  This document is subject to the rights, licenses and restrictions
  contained in BCP 78, and except as set forth therein, the authors
  retain all their rights.

  This document and the information contained herein are provided on an
  "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
  OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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 BCP 78 and BCP 79.

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

  The IETF invites any interested party to bring to its attention any
  copyrights, patents or patent applications, or other proprietary
  rights that may cover technology that may be required to implement
  this standard.  Please address the information to the IETF at
  [email protected].

Acknowledgement

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







Kaeo                         Informational                     [Page 37]


You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.