< draft-ietf-opsec-current-practices-05.txt   draft-ietf-opsec-current-practices-06.txt >
OPSEC M. Kaeo OPSEC M. Kaeo
Internet-Draft Double Shot Security, Inc. Internet-Draft Double Shot Security, Inc.
Expires: January 6, 2007 July 5, 2006 Expires: January 21, 2007 July 20, 2006
Operational Security Current Practices Operational Security Current Practices
draft-ietf-opsec-current-practices-05 draft-ietf-opsec-current-practices-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 6, 2007. This Internet-Draft will expire on January 21, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document is a survey of the current practices used in today's This document is a survey of the current practices used in today's
large ISP operational networks to secure layer 2 and layer 3 large ISP operational networks to secure layer 2 and layer 3
infrastructure devices. The information listed here is the result of infrastructure devices. The information listed here is the result of
information gathered from people directly responsible for defining information gathered from people directly responsible for defining
and implementing secure infrastructures in Internet Service Provider and implementing secure infrastructures in Internet Service Provider
environments. environments.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Attack Sources . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Attack Sources . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Operational Security Impact from Threats . . . . . . . . . 5 1.4. Operational Security Impact from Threats . . . . . . . . . 6
1.5. Document Layout . . . . . . . . . . . . . . . . . . . . . 7 1.5. Document Layout . . . . . . . . . . . . . . . . . . . . . 7
1.6. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8
2. Protected Operational Functions . . . . . . . . . . . . . . . 9 2. Protected Operational Functions . . . . . . . . . . . . . . . 9
2.1. Device Physical Access . . . . . . . . . . . . . . . . . . 9 2.1. Device Physical Access . . . . . . . . . . . . . . . . . . 9
2.2. Device In-Band Management . . . . . . . . . . . . . . . . 11 2.2. Device Management - In-Band and Out-of-Band (OOB) . . . . 11
2.3. Device Out-of-Band Management . . . . . . . . . . . . . . 15 2.3. Data Path . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4. Data Path . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4. Routing Control Plane . . . . . . . . . . . . . . . . . . 19
2.5. Routing Control Plane . . . . . . . . . . . . . . . . . . 22 2.5. Software Upgrades and Configuration Integrity /
2.6. Software Upgrades and Configuration Integrity / Validation . . . . . . . . . . . . . . . . . . . . . . . . 23
Validation . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6. Logging Considerations . . . . . . . . . . . . . . . . . . 26
2.7. Logging Considerations . . . . . . . . . . . . . . . . . . 29 2.7. Filtering Considerations . . . . . . . . . . . . . . . . . 30
2.8. Filtering Considerations . . . . . . . . . . . . . . . . . 32 2.8. Denial of Service Tracking / Tracing . . . . . . . . . . . 31
2.9. Denial of Service Tracking / Tracing . . . . . . . . . . . 33 3. Security Considerations . . . . . . . . . . . . . . . . . . . 33
3. Security Considerations . . . . . . . . . . . . . . . . . . . 35 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.1. Normative References . . . . . . . . . . . . . . . . . . . 34
4.1. Normative References . . . . . . . . . . . . . . . . . . . 36 4.2. Informational References . . . . . . . . . . . . . . . . . 34
4.2. Informational References . . . . . . . . . . . . . . . . . 36 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 35
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 37 Appendix B. Protocol Specific Attacks . . . . . . . . . . . . . . 36
Appendix B. Protocol Specific Attacks . . . . . . . . . . . . . . 38 B.1. Layer 2 Attacks . . . . . . . . . . . . . . . . . . . . . 36
B.1. Layer 2 Attacks . . . . . . . . . . . . . . . . . . . . . 38 B.2. IPv4 Protocol Based Attacks . . . . . . . . . . . . . . . 36
B.2. IPv4 Attacks . . . . . . . . . . . . . . . . . . . . . . . 38 B.3. IPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . . 38
B.3. IPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . . 39 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . . . 42
1. Introduction 1. Introduction
Security practices are well understood by the network operators who Security practices are well understood by the network operators who
have for many years gone through the growing pains of securing their have for many years gone through the growing pains of securing their
network infrastructures. However, there does not exist a written network infrastructures. However, there does not exist a written
document that enumerates these security practices. Network attacks document that enumerates these security practices. Network attacks
are continually increasing and although it is not necessarily the 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 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 that certain security practices are followed to ensure that their
skipping to change at page 3, line 35 skipping to change at page 3, line 35
focuses solely on documenting currently deployed security mechanisms focuses solely on documenting currently deployed security mechanisms
for layer 2 and layer 3 network infrastructure devices. Although for layer 2 and layer 3 network infrastructure devices. Although
primarily focused on IPv4, many of the same practices can (and primarily focused on IPv4, many of the same practices can (and
should) apply to IPv6 networks. Both IPv4 and IPv6 network should) apply to IPv6 networks. Both IPv4 and IPv6 network
infrastructures are taken into account in this survey. infrastructures are taken into account in this survey.
1.2. Threat Model 1.2. Threat Model
A threat is a potential for a security violation, which exists when A threat is a potential for a security violation, which exists when
there is a circumstance, capability, action, or event that could there is a circumstance, capability, action, or event that could
breach security and cause harm [RFC2828].Every operational network is breach security and cause harm [RFC2828]. Every operational network
subject to a multitude of threat actions, or attacks, i.e. an assault is subject to a multitude of threat actions, or attacks, i.e. an
on system security that derives from an intelligent act that is a assault on system security that derives from an intelligent act that
deliberate attempt to evade security services and violate the is a deliberate attempt to evade security services and violate the
security policy of a system [RFC2828]. All of the threats in any security policy of a system [RFC2828]. All of the threats in any
network infrastructure is an instantiation or combination of the network infrastructure is an instantiation or combination of the
following: following:
Reconnaissance: An attack whereby information is gathered to Reconnaissance: An attack whereby information is gathered to
ascertain the network topology or specific device information which ascertain the network topology or specific device information which
can be further used to exploit known vulnerabilities can be further used to exploit known vulnerabilities
Man-In-The-Middle: An attack where a malicious user impersonates Man-In-The-Middle: An attack where a malicious user impersonates
either the sender or recipient of a communication stream while either the sender or recipient of a communication stream while
inserting, modifying or dropping certain traffic. This type of inserting, modifying or dropping certain traffic. This type of
attack also covers phishing and session hijacks. attack also covers phishing and session hijacks.
Protocol Vulnerability Exploitation: An attack which takes advantage Protocol Vulnerability Exploitation: An attack which takes advantage
of known protocol deficiencies to cause inappropriate behavior. of known protocol vulnerabilities due to design or implementation
flaws to cause inappropriate behavior.
Message Insertion: This can be a valid message (which could be a Message Insertion: This can be a valid message (which could be a
reply attack, which is a scenario where a message is captured and reply attack, which is a scenario where a message is captured and
resent at later time). A message can also be inserted with any of resent at later time). A message can also be inserted with any of
the fields in the message being OspoofedO, such as IP addresses, port the fields in the message being OspoofedO, such as IP addresses, port
numbers, header fields or even packet content. Flooding is also part numbers, header fields or even packet content. Flooding is also part
of this threat instantiation. of this threat instantiation.
Message Diversion/Deletion: An attack where legitimate messages are Message Diversion/Deletion: An attack where legitimate messages are
removed before they can reach the desired recipient or are re- removed before they can reach the desired recipient or are re-
skipping to change at page 5, line 39 skipping to change at page 5, line 42
instances where unintentional events cause the same harm yet are instances where unintentional events cause the same harm yet are
performed without malice in mind. Configuration errors and performed without malice in mind. Configuration errors and
software bugs can be as devastating to network availability as any software bugs can be as devastating to network availability as any
deliberate attack on the network infrastructure. deliberate attack on the network infrastructure.
The attack source can be a combination of any of the above, all of The attack source can be a combination of any of the above, all of
which need to be considered when trying to ascertain what impact any which need to be considered when trying to ascertain what impact any
attack can have on the availability and reliability of the network. attack can have on the availability and reliability of the network.
It is nearly impossible to stop insider attacks or unintentional It is nearly impossible to stop insider attacks or unintentional
events. However, if appropriate monitoring mechanisms are in place, events. However, if appropriate monitoring mechanisms are in place,
these attacks can be as easily detected and mitigated as with any these attacks can also be detected and mitigated as with any other
other attack source. Any of the specific attacks discussed further attack source. The amount of effort it takes to identify and trace
in this document will elaborate on attacks which are sourced by an 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 "outsider" and are deliberate attacks. Some further elaboration will
be given to the feasibility of passive vs active and on-path vs off- be given to the feasibility of passive vs active and on-path vs off-
path attacks to show the motivation behind deploying certain security path attacks to show the motivation behind deploying certain security
features. features.
1.4. Operational Security Impact from Threats 1.4. Operational Security Impact from Threats
The main concern for any of the potential attack scenarios is the The main concern for any of the potential attack scenarios is the
impact and harm it can cause to the network infrastructure. The impact and harm it can cause to the network infrastructure. The
threat consequences are the security violations which results from a threat consequences are the security violations which results from a
skipping to change at page 7, line 44 skipping to change at page 7, line 48
o Auditing / Logging o Auditing / Logging
o DoS Mitigation o DoS Mitigation
In many instances, a specific protocol currently deployed will offer In many instances, a specific protocol currently deployed will offer
a combination of these services. For example, AAA can offer user a combination of these services. For example, AAA can offer user
authentication, user authorization and audit / logging services while authentication, user authorization and audit / logging services while
SSH can provide data origin authentication, data integrity and data SSH can provide data origin authentication, data integrity and data
confidentiality. The services offered are more important than the confidentiality. The services offered are more important than the
actual protocol used. Each section ends with an additional actual protocol used. Note that access control will refer basically
considerations section which explains why specific protocols may or to logical access control, i.e. filtering. Each section ends with an
may not be used and also gives some information regarding additional considerations section which explains why specific
capabilities which are not possible today due to bugs or lack of ease protocols may or may not be used and also gives some information
of use. regarding capabilities which are not possible today due to bugs or
lack of ease of use.
1.6. Definitions
RFC 2119 Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in [RFC2119].
The use of the RFC 2119 keywords is an attempt, by the editor, to
assign the correct requirement levels ("MUST", "SHOULD",
"MAY"...). It must be noted that different organizations,
operational environments, policies and legal environments will
generate different requirement levels.
2. Protected Operational Functions 2. Protected Operational Functions
2.1. Device Physical Access 2.1. Device Physical Access
Device physical access pertains to protecting the physical location Device physical access pertains to protecting the physical location
and access of the layer 2 or layer 3 network infrastructure device. and access of the layer 2 or layer 3 network infrastructure device.
Physical security is a large field of study/practice in and of Physical security is a large field of study/practice in and of
itself, arguably the largest. oldest and most well understood area of itself, arguably the largest, oldest and most well understood area of
security. Although it is important to have contingency plans for security. Although it is important to have contingency plans for
natural disasters such as earthquakes and floods which can cause natural disasters such as earthquakes and floods which can cause
damage to networking devices, this is out-of-scope for this document. damage to networking devices, this is out-of-scope for this document.
Here we concern ourselves with protecting access to the physical Here we concern ourselves with protecting access to the physical
location and how a device can be further protected from unauthorized location and how a device can be further protected from unauthorized
access if the physical location has been compromised, i.e protecting access if the physical location has been compromised, i.e protecting
the console access. This is aimed largely at stopping an intruder the console access. This is aimed largely at stopping an intruder
with physical access from gaining operational control of the with physical access from gaining operational control of the
device(s). Note that nothing will stop an attacker with physical device(s). Note that nothing will stop an attacker with physical
access from effecting a denial of service attack, which can be easily access from effecting a denial of service attack, which can be easily
skipping to change at page 9, line 50 skipping to change at page 9, line 50
ways even if critical devices are under high-security. There still ways even if critical devices are under high-security. There still
occur cases where attackers have impersonated maintenance workers to occur cases where attackers have impersonated maintenance workers to
gain physical access to critical devices that have caused major gain physical access to critical devices that have caused major
outages and privacy compromises. Insider attacks from authorized outages and privacy compromises. Insider attacks from authorized
personnel also pose a real threat and must be adequately recognized personnel also pose a real threat and must be adequately recognized
and dealt with. and dealt with.
2.1.2. Security Practices 2.1.2. Security Practices
For physical device security, equipment is kept in highly restrictive For physical device security, equipment is kept in highly restrictive
environments. Only authorized users with card key badges have access environments. Only authorized users with cardkey badges have access
to any of the physical locations that contain critical network to any of the physical locations that contain critical network
infrastructure devices. These card-key systems keep track of who infrastructure devices. These cardkey systems keep track of who
accessed which location and at what time. 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 cardkey system is NOT online/
functional).
All console access is always password protected and the login time is All console access is always password protected and the login time is
set to time out after a specified amount of inactivity - typically set to time out after a specified amount of inactivity - typically
between 3-10 minutes. Individual users are authentication to get between 3-10 minutes. The type of privileges that you obtain from a
basic access. For privileged (i.e. enable) access, a second console login varies between separate vendor devices. In some cases
authentication step needs to be completed. Typically all console you get initial basic access and need to perform a second
access is provided via an out-of-band (OOB) management infrastructure authentication step to get more privileged (i.e. enable or root)
which is discussed in the section on OOB management. access. 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 can 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 the section on
OOB management.
2.1.3. Security Services 2.1.3. Security Services
The following security services are offered through the use of the The following security services are offered through the use of the
practices described in the previous section: practices described in the previous section:
o User Authentication - All individuals who have access to the o User Authentication - All individuals who have access to the
physical facility are authenticated. Console access is physical facility are authenticated. Console access is
authenticated. authenticated.
o User Authorization - An authenticated individual has implicit o User Authorization - An authenticated individual has implicit
authorization to perform commands on the device. Console access authorization to perform commands on the device. In some cases
is usually granted via at least two privilege levels: multiple authentication is required to differentiate between basic
authorization for performing a basic set of commands vs and more privileged access.
authorization for performing all commands.
o Data Origin Authentication - Not applicable o Data Origin Authentication - Not applicable
o Access Control - Not applicable o Access Control - Not applicable
o Data Integrity - Not applicable o Data Integrity - Not applicable
o Data Confidentiality - Not applicable o Data Confidentiality - Not applicable
o Auditing / Logging - All access to the physical locations of the o Auditing / Logging - All access to the physical locations of the
infrastructure equipment is logged via electronic card-key infrastructure equipment is logged via electronic card-key
systems. All console access is logged (refer to the OOB systems. All console access is logged (refer to the OOB
management section for more details) management section for more details)
o DoS Mitigation - Not applicable o DoS Mitigation - Not applicable
2.1.4. Additional Considerations 2.1.4. Additional Considerations
Physical security is relevant to operational security practices as Physical security is relevant to operational security practices as
skipping to change at page 11, line 17 skipping to change at page 11, line 30
locations. These systems need to be secured to ensure that they locations. These systems need to be secured to ensure that they
themselves will not be compromised which could give the intruder themselves will not be compromised which could give the intruder
valuable authentication and logging information. valuable authentication and logging information.
Social engineering plays a big role in many physical access Social engineering plays a big role in many physical access
compromises. Most ISPs have set up training classes and awareness compromises. Most ISPs have set up training classes and awareness
programs to educate company personnel to deny physical access to programs to educate company personnel to deny physical access to
people who are not properly authenticated or authorized to have people who are not properly authenticated or authorized to have
physical access to critical infrastructure devices. physical access to critical infrastructure devices.
2.2. Device In-Band Management 2.2. Device Management - In-Band and Out-of-Band (OOB)
In-band management is generally considered to be device access where In-band management is generally considered to be device access where
the control traffic takes the same data path as the data which the control traffic takes the same data path as the data which
traverses the network. In many environments, device management for traverses the network. Out-of-band management is generally
layer 2 and layer 3 infrastructure devices is deployed as part of an considered to be device access where the control traffic takes a
out-of-band management infrastructure although there are some separate path as the data which traverses the network. In many
instances where it is deployed in-band as well. Presently, the environments, device management for layer 2 and layer 3
mechanisms used for in-band management are via virtual terminal infrastructure devices is deployed as part of an out-of-band
access (i.e. Telnet or SSH), SNMP, or HTTP. In all large ISPs that management infrastructure although there are some instances where it
were interviewed, HTTP management is never used and is explicitly is deployed in-band as well. Note that while many of the security
disabled. Note that file transfer protocols (TFTP, FTP, SCP) will be concerns and practices are the same for OOB management and in-band
covered in the 'Software Upgrades and Configuration Integrity/ management, most ISPs prefer an OOB management system since access to
Validation' section. the devices which 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), SNMP, or HTTP. In all
large ISPs that were interviewed, HTTP management is never used and
is explicitly disabled. Note that file transfer protocols (TFTP,
FTP, SCP) will be covered in the 'Software Upgrades and Configuration
Integrity/Validation' section.
2.2.1. Threats / Attacks 2.2.1. Threats / Attacks
For in-band device management, passive attacks are possible if For device management, passive attacks are possible if someone has
someone has the capability to intercept data between the management the capability to intercept data between the management device and
device and the managed device. The threat is possible if a single the managed device. The threat is possible if a single
infrastructure device is somehow compromised and can act as a network infrastructure device is somehow compromised and can act as a network
sniffer or if it is possible to insert a new device which acts as a sniffer or if it is possible to insert a new device which acts as a
network sniffer. network sniffer.
Active attacks are possible for both on-path and off-path scenarios. 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 For on-path active attacks, the situation is the same as for a
passive attack, where either a device has to already be compromised passive attack, where either a device has to already be compromised
or a device can be inserted into the path. For off-path active or a device can be inserted into the path. For off-path active
attacks, the attack is generally limited to message insertion or attacks, where a topology subversion is required to reroute traffic
modification. and essentially bring the attacker on-path, the attack is generally
limited to message insertion or modification.
2.2.1.1. Confidentiality Violations 2.2.1.1. Confidentiality Violations
Confidentiality violations can occur when a miscreant intercepts Confidentiality violations can occur when a miscreant intercepts any
confidential data that has been sent in cleartext. This includes management data that has been sent in cleartext or with weak
interception of usernames and passwords with which an intruder can encryption. This includes interception of usernames and passwords
obtain unauthorized access to network devices. It can also include with which an intruder can obtain unauthorized access to network
other information such as logging or configuration information if an devices. It can also include other information such as logging or
administrator is remotely viewing local logfiles or configuration configuration information if an administrator is remotely viewing
information. local logfiles or configuration information.
2.2.1.2. Offline Cryptographic Attacks 2.2.1.2. Offline Cryptographic Attacks
If username/password information was encrypted but the cryptographic If username/password information was encrypted but the cryptographic
mechanism used made it easy to capture data and break the encryption mechanism used made it easy to capture data and break the encryption
key, the device management traffic could be compromised. The traffic key, the device management traffic could be compromised. The traffic
would need to be captured either by eavesdropping on the network or would need to be captured either by eavesdropping on the network or
by being able to divert traffic to a malicious user. by being able to divert traffic to a malicious user.
2.2.1.3. Replay Attacks 2.2.1.3. Replay Attacks
For a replay attack to be successful, in-band management traffic For a replay attack to be successful, the management traffic would
would need to first be captured either on-path or diverted to an need to first be captured either on-path or diverted to an attacker
attacker to later be replayed to the intended recipient. to later be replayed to the intended recipient.
2.2.1.4. Message Insertion/Deletion/Modification 2.2.1.4. Message Insertion/Deletion/Modification
Data can be manipulated by someone in control of intermediary hosts. Data can be manipulated by someone in control of intermediary hosts.
Forging data is also possible with IP spoofing, where a remote host Forging data is also possible with IP spoofing, where a remote host
sends out packets which appear to come from another, trusted host. sends out packets which appear to come from another, trusted host.
2.2.1.5. Man-In-The-Middle 2.2.1.5. Man-In-The-Middle
A man-in-the-middle attack attacks the identity of a communicating A man-in-the-middle attack attacks the identity of a communicating
peer rather than the data stream itself. The attacker intercepts peer rather than the data stream itself. The attacker intercepts
traffic that is sent from an in-band management system to the traffic that is sent from a management system to the networking
networking infrastructure device and traffic that is sent from the infrastructure device and traffic that is sent from the network
network infrastructure device to the in-band management system. infrastructure device to the management system.
2.2.2. Security Practices 2.2.2. Security Practices
All in-band management access to layer 2 and layer 3 devices is OOB management is done via a terminal server at each location. SSH
authenticated. The user authentication and authorization is access is used to get to the terminal server from where sessions to
typically controlled by a AAA server (i.e. RADIUS and/or TACACS+). the devices are initiated. Dial-in access is deployed as a backup if
Credentials used to determine the identity of the user vary from the network is not available however, it is common to use dial-back,
static username/password to one-time username/password scheme such as encrypting modems and/or one-time-password (OTP) modems to avoid the
Secure-ID. Static username/passwords are expired after a specified security weaknesses of plain dial-in access.
period of time, usually 30 days. Every authenticated entity via AAA
is an individual user for greater granularity of control. In some All in-band management and OOB management access to layer 2 and layer
deployments, the AAA servers used for in-band management 3 devices is authenticated. The user authentication and
authentication/authorization/accounting are on separate out-of-band authorization is typically controlled by a AAA server (i.e. RADIUS
networks to provide a demarcation for any other authentication and/or TACACS+). Credentials used to determine the identity of the
functions. user vary from static username/password to one-time username/password
scheme 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 For backup purposes, there is often a single local database entry for
authentication which is known to a very limited set of key personnel. authentication which is known to a very limited set of key personnel.
It is usually the highest privilege level username/password It is usually the highest privilege level username/password
combination, which in most cases is the same across all devices. combination, which in most cases is the same across all devices.
This local device password is routinely regenerated once every 2-3 This local device password is routinely regenerated once every 2-3
months and is also regenerated immediately after an employee who had months and is also regenerated immediately after an employee who had
access to that password leaves the company or is no longer authorized access to that password leaves the company or is no longer authorized
to have knowledge of that password. to have knowledge of that password.
skipping to change at page 13, line 25 skipping to change at page 14, line 10
authorization capability. Specific commands are either individually authorization capability. Specific commands are either individually
denied or permitted depending on the capability of the device to be denied or permitted depending on the capability of the device to be
accessed. Multiple privilege levels are deployed. Most individuals accessed. Multiple privilege levels are deployed. Most individuals
are authorized with basic authorization to perform a minimal set of are authorized with basic authorization to perform a minimal set of
commands while a subset of individuals are authorized to perform more commands while a subset of individuals are authorized to perform more
privileged commands. Securing the AAA server is imperative and privileged commands. Securing the AAA server is imperative and
access to the AAA server itself is strictly controlled. When an access to the AAA server itself is strictly controlled. When an
individual leaves the company, his/her AAA account is immediately individual leaves the company, his/her AAA account is immediately
deleted and the TACACS/RADIUS shared secret is reset for all devices. 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 SSH is always used for virtual terminal access to provide for an
encrypted communication channel. There are exceptions due to encrypted communication channel. There are exceptions due to
equipment limitations which are described in the additional equipment limitations which are described in the additional
considerations section. considerations section.
If SNMP is used for in-band management, it is for read queries only If SNMP is used for management, it is for read queries only and
and restricted to specific hosts. If possible, the view is also restricted to specific hosts. If possible, the view is also
restricted to only send the information that the management station restricted to only send the information that the management station
needs rather than expose the entire configuration file with the read- needs rather than expose the entire configuration file with the read-
only SNMP community. The community strings are carefully chosen to only SNMP community. The community strings are carefully chosen to
be difficult to crack and there are procedures in place to change be difficult to crack and there are procedures in place to change
these community strings between 30-90 days. If systems support two these community strings between 30-90 days. If systems support two
SNMP community strings, the old string is replaced by first SNMP community strings, the old string is replaced by first
configuring a second newer community string and then migrating over configuring a second newer community string and then migrating over
from the currently used string to the newer one. Most large ISPs from the currently used string to the newer one. Most large ISPs
have multiple SNMP systems accessing their routers so it takes more have multiple SNMP systems accessing their routers so it takes more
then one maintenance period to get all the strings fixed in all the then one maintenance period to get all the strings fixed in all the
right systems. SNMP RW is not used and disabled by configuration. right systems. SNMP RW is not used and is disabled by configuration.
Access control is strictly enforced for infrastructure devices by Access control is strictly enforced for infrastructure devices by
using stringent filtering rules. A limited set of IP addresses are using stringent filtering rules. A limited set of IP addresses are
allowed to initiate connections to the infrastructure devices and are allowed to initiate connections to the infrastructure devices and are
specific to the services which they are to limited to (i.e. SSH and specific to the services which they are to limited to (i.e. SSH and
SNMP). SNMP).
All in-band device management access is audited and any violations All device management access is audited and any violations trigger
trigger alarms which initiate automated email, pager and/or telephone alarms which initiate automated email, pager and/or telephone
notifications. AAA servers keeps track of the authenticated entity notifications. AAA servers keeps track of the authenticated entity
as well as all the commands that were carried out on a specific as well as all the commands that were carried out on a specific
device. Additionally, the device itself logs any access control device. Additionally, the device itself logs any access control
violations (i.e. if an SSH request comes in from an IP address which violations (i.e. if an SSH request comes in from an IP address which
is not explicitly permitted, that event is logged so that the is not explicitly permitted, that event is logged so that the
offending IP address can be tracked down and investigations made as offending IP address can be tracked down and investigations made as
to why it was trying to access a particular infrastructure device) to why it was trying to access a particular infrastructure device)
2.2.3. Security Services 2.2.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 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 from spoofed
traffic. Using SSH for device access ensures that noone can spoof
the traffic during the SSH session.
o Access Control - In-band 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. Often OOB management is used to lower that
risk.
2.2.4. Additional Considerations
Password selection for any in-band device management protocol used is
critical to ensure that the passwords are hard to guess or break
using a brute-force attack.
IPsec is considered too difficult to deploy and the common protocol
to provide for confidential in-band management access is SSH. There
are exceptions for using SSH due to equipment limitations since SSH
may not be supported on legacy equipment. 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 it is connecting to. 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 Telent is NEVER
allowed to an infrastructure device except from specific jumphosts;
i.e. packet filters are used 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. Kerberos is used to automate
the authentication process. 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.
2.3. Device Out-of-Band Management
Out-of-band management is generally considered to be device access
where the control traffic takes a separate path as the data which
traverses the network. Console access is always architected via an
OOB network. SNMP management is also usually carried out via that
same OOB network infrastructure. Note that 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 which make up this management network are more
vigilantly protected and considered to be less susceptible to
malicious activity.
2.3.1. Threats / Attacks
For OOB 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 which 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 attack is generally limited to message insertion or
modification.
2.3.1.1. Confidentiality Violations
Confidentiality violations can occur when a miscreant intercepts any
of the OOB management data that has been sent in cleartext. 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.3.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 OOB 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.3.1.3. Replay Attacks
For a replay attack to be successful, the OOB management traffic
would need to first be captured either on-path or diverted to an
attacker to later be replayed to the intended recipient.
2.3.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 which appear to come from another, trusted host.
2.3.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 an OOB management system to the networking
infrastructure device and traffic that is sent from the network
infrastructure device to the OOB management system.
2.3.2. Security Practices
OOB 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 OOB management access to layer 2 and layer 3 devices is
authenticated. The user authentication and authorization is
typically controlled by a AAA server (i.e. RADIUS and/or TACACS+).
Credentials used to determine the identity of the user vary from
static username/password to one-time username/password scheme 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.
For backup purposes, there is often a single local database entry for
authentication which 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.
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.
Some OOB 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 OOB management, it is for read queries only and
restricted to specific hosts. 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 strings, a second new string is set and then migrate
over from the 1st to the 2nd. 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 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 which they are to limited to (i.e. SSH and
SNMP).
All OOB device management access is audited. The AAA server keeps
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 which is not 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.3.3. Security Services
The security services offered for device OOB management are nearly The security services offered for device OOB management are nearly
identical to those of device in-band management. Due to the critical identical to those of device in-band management. Due to the critical
nature of controlling and limiting device access, many ISPs feel that nature of controlling and limiting device access, many ISPs feel that
physically separating the management traffic from the normal customer physically separating the management traffic from the normal customer
data traffic will provide an added level of risk mitigation and limit data traffic will provide an added level of risk mitigation and limit
the potential attack vectors. For OOB management, the security the potential attack vectors. The following security services are
services offered through the use of the practices described in the offered through the use of the practices described in the previous
previous section are: section:
o User Authentication - All individuals are authenticated via AAA o User Authentication - All individuals are authenticated via AAA
services. services.
o User Authorization - All individuals are authorized via AAA o User Authorization - All individuals are authorized via AAA
services to perform specific operations once successfully services to perform specific operations once successfully
authenticated. authenticated.
o Data Origin Authentication - Management traffic is strictly o Data Origin Authentication - Management traffic is strictly
filtered to allow only specific IP addresses to have access to the filtered to allow only specific IP addresses to have access to the
infrastructure devices. This does not alleviate risk from spoofed infrastructure devices. This does not alleviate risk from spoofed
traffic. Using SSH for device access ensures that noone can spoof traffic, although when combined with edge filtering using BCP38
the traffic during the SSH session. [RFC2827] and BCP84 [RFC3704] guidelines (discussed in the section
2.5), then the risk of spoofing is mitigated barring a compromised
internal system. Also, using SSH for device access ensures that
noone can spoof the traffic during the SSH session.
o Access Control - In-band management traffic is filtered to allow o Access Control - Management traffic is filtered to allow only
only specific IP addresses to have access to the infrastructure specific IP addresses to have access to the infrastructure
devices. devices.
o Data Integrity - Using SSH provides data integrity and ensures o Data Integrity - Using SSH provides data integrity and ensures
that noone has altered the management data in transit. that no one has altered the management data in transit.
o Data Confidentiality - Using SSH provides data confidentiality. o Data Confidentiality - Using SSH provides data confidentiality.
o Auditing / Logging - Using AAA provides an audit trail for who o Auditing / Logging - Using AAA provides an audit trail for who
accessed which device and which operations were performed. accessed which device and which operations were performed.
o DoS Mitigation - Using packet filters to allow only specific IP o DoS Mitigation - Using packet filters to allow only specific IP
addresses to have access to the infrastructure devices. This addresses to have access to the infrastructure devices. This
limits but does not prevent spoofed DoS attacks directed at an limits but does not prevent spoofed DoS attacks directed at an
infrastructure device. However, the risk is lowered by using a infrastructure device. However, the risk is lowered by using a
separate physical network for management purposes. separate physical network for management purposes.
2.3.4. Additional Considerations 2.2.4. Additional Considerations
Password selection for any OOB device management protocol used is Password selection for any device management protocol used is
critical to ensure that the passwords are hard to guess or break critical to ensure that the passwords are hard to guess or break
using a brute-force attack. using a brute-force attack.
IPsec is considered too difficult to deploy and the common protocol IPsec is considered too difficult to deploy and the common protocol
to provide for confidential OOB management access is SSH. There are to provide for confidential management access is SSH. There are
exceptions for using SSH due to equipment limitations since SSH may exceptions for using SSH due to equipment limitations since SSH may
not be supported on legacy equipment. In some cases changing the not be supported on legacy equipment. In some cases changing the
hostname of a device requires an SSH rekey event since the key is hostname of a device requires an SSH rekey event since the key is
based on some combination of host name, MAC address and time. Also, based on some combination of host name, MAC address and time. Also,
in the case where the SSH key is stored on a route processor card, a 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 re-keying of SSH would be required whenever the route processor card
needs to be swapped. Some providers feel that some of these needs to be swapped. Some providers feel that this operational
operational impacts exceed the security necessary and instead use impact exceeds the security necessary and instead use Telnet from
Telnet from trusted inside hosts (called 'jumphosts') to manage those trusted inside hosts (called 'jumphosts' or 'bastion hosts') to
device. An individual would first SSH to the jumphost and then manage those devices. An individual would first SSH to the jumphost
Telnet from the jumphost to the terminal server before logging in to and then Telnet from the jumphost to the actual infrastructure
the device console. All authentication and authorization is still device, fully understanding that any passwords will be sent in the
carried out using AAA servers. clear between the jumphost and the device it is connecting to. All
authentication and authorization is still carried out using AAA
servers.
In instances where Telnet access is used, the logs on the 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 are more verbose and more attention is paid to them to detect any
abnormal behavior. The jumphosts themselves are carefully controlled abnormal behavior. The jumphosts themselves are carefully controlled
machines and usually have limited access. Note that Telent is NEVER machines and usually have limited access. Note that Telnet is NEVER
allowed to an infrastructure device except from specific jumphosts; allowed to an infrastructure device except from specific jumphosts;
i.e. packet filters are used at the console server and/or i.e. packet filters are used at the console server and/or
infrastructure device to ensure that Telnet is only allowed from infrastructure device to ensure that Telnet is only allowed from
specific IP addresses. 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 In instances where SNMP is used, some legacy devices only support
SNMPv1 which then requires the provider to mandate its use across all SNMPv1 which then requires the provider to mandate its use across all
infrastructure devices for operational simplicity. SNMPv2 is infrastructure devices for operational simplicity. SNMPv2 is
primarily deployed since it is easier to set up than v3. primarily deployed since it is easier to set up than v3.
2.4. Data Path 2.3. Data Path
This section refers to how traffic is handled which traverses the This section refers to how traffic is handled which traverses the
network infrastructure device. The primary goal of ISPs is to network infrastructure device. The primary goal of ISPs is to
forward customer traffic. However, due to the large amount of forward customer traffic. However, due to the large amount of
malicious traffic that can cause DoS attacks and render the network malicious traffic that can cause DoS attacks and render the network
unavailable, specific measures are sometimes deployed to ensure the unavailable, specific measures are sometimes deployed to ensure the
availability to forward legitimate customer traffic. availability to forward legitimate customer traffic.
2.4.1. Threats / Attacks 2.3.1. Threats / Attacks
Any data traffic can potentially be attack traffic and the challenge Any data traffic can potentially be attack traffic and the challenge
is to detect and potentially stop forwarding any of the malicious is to detect and potentially stop forwarding any of the malicious
traffic. The deliberately sourced attack traffic can consist of traffic. The deliberately sourced attack traffic can consist of
packets with spoofed source and/or destination addresses or any other packets with spoofed source and/or destination addresses or any other
malformed packet which mangle any portion of a header field to cause malformed packet which mangle any portion of a header field to cause
protocol-related security issues (such as resetting connections, protocol-related security issues (such as resetting connections,
causing unwelcome ICPM redirects, creating unwelcome IP options or causing unwelcome ICMP redirects, creating unwelcome IP options or
packet fragmentations). packet fragmentations).
2.4.2. Security Practices 2.3.2. Security Practices
Filtering and rate limiting are the primary mechanism to provide risk Filtering and rate limiting are the primary mechanism to provide risk
mitigation of malicious traffic rendering the ISP services mitigation of malicious traffic rendering the ISP services
unavailable. However, filtering and rate limiting of data path unavailable. However, filtering and rate limiting of data path
traffic is deployed in a variety of ways depending on how automated traffic is deployed in a variety of ways depending on how automated
the process is and what the capabilities and performance limitations the process is and what the capabilities and performance limitations
of existing deployed hardware are. of existing deployed hardware are.
The ISPs which do not have performance issues with their equipment The ISPs which do not have performance issues with their equipment
follow BCP38 [RFC2827] and BCP84 [RFC3704] guidelines for ingress follow BCP38 [RFC2827] and BCP84 [RFC3704] guidelines for ingress
filtering. BCP38 recommends filtering ingress packets with obviously filtering. BCP38 recommends filtering ingress packets with obviously
spoofed and/or 'reserved' source addresses to limit the effects of spoofed and/or 'reserved' source addresses to limit the effects of
denial of service attacks while BCP84 extends the recommendation for denial of service attacks while BCP84 extends the recommendation for
multi-homed environments. Null routes and black-hole triggered multi-homed environments. Filters are also used to help alleviate
routing are used to deter any detected malicious traffic streams. issues between service providers. Without any filtering, an inter-
These techniques are described in more detail in section 2.9 below. exchange peer could steal transit just by using static routes and
essentially redirect data traffic. Therefore, some ISPs have
implemented ingress/egress filters which block unexpected source and
destination addresses not defined in the above-mentioned documents.
Null routes and black-hole triggered routing 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 Most ISPs consider layer 4 filtering useful but it is only
implemented if performance limitations allow for it. Layer 4 implemented if performance limitations allow for it. Layer 4
filtering is typically only when no other option exists since it does filtering is typically only when no other option exists since it does
pose a large administrative overhead and ISPs are very much opposed pose a large administrative overhead and ISPs are very much opposed
to acting as the Internet firewall. Netflow is used for tracking to acting as the Internet firewall. Netflow is used for tracking
traffic flows but there is some concern whether sampling is good traffic flows but there is some concern whether sampling is good
enough to detect malicious behavior. enough to detect malicious behavior.
Unicast RPF is not consistently implemented. Some ISPs are in Unicast RPF is not consistently implemented. Some ISPs are in
process of doing so while other ISPs think that the perceived benefit process of doing so while other ISPs think that the perceived benefit
of knowing that spoofed traffic comes from legitimate addresses are of knowing that spoofed traffic comes from legitimate addresses are
not worth the operational complexity. Some providers have a policy not worth the operational complexity. Some providers have a policy
of implementing uRPF at link speeds of DS3 and below. of implementing uRPF at link speeds of DS3 and below.
2.4.3. Security Services 2.3.3. Security Services
o User Authentication - Not applicable o User Authentication - Not applicable
o User Authorization - Not applicable o User Authorization - Not applicable
o Data Origin Authentication - When IP address filtering per BCP38 o Data Origin Authentication - When IP address filtering per BCP38,
and uRPF are deployed at network edges it can ensure that any BCP84 and uRPF are deployed at network edges it can ensure that
spoofed traffic comes from at least a legitimate IP address and any spoofed traffic comes from at least a legitimate IP address
can be tracked. and can be tracked.
o Access Control - IP address filtering and layer 4 filtering is o Access Control - IP address filtering and layer 4 filtering is
used to deny forbidden protocols and limit traffic destined for used to deny forbidden protocols and limit traffic destined for
infrastructure device itself. infrastructure device itself. Filters are also used to block
unexpected source/destination addresses.
o Data Integrity - Not applicable o Data Integrity - Not applicable
o Data Confidentiality - Not applicable o Data Confidentiality - Not applicable
o Auditing / Logging - Filtering exceptions are logged for potential o Auditing / Logging - Filtering exceptions are logged for potential
attack traffic. attack traffic.
o DoS Mitigation - Black-hole triggered filtering and rate-limiting o DoS Mitigation - Black-hole triggered filtering and rate-limiting
are used to limit the risk of DoS attacks. are used to limit the risk of DoS attacks.
2.4.4. Additional Considerations 2.3.4. Additional Considerations
For layer 2 devices, MAC address filtering and authentication is not For layer 2 devices, MAC address filtering and authentication is not
used. This is due to the problems it can cause when troubleshooting used in large-scale deployments. This is due to the problems it can
networking issues. Port security becomes unmanageable at a large cause when troubleshooting networking issues. Port security becomes
scale where 1000s of switches are deployed. unmanageable at a large scale where 1000s of switches are deployed.
Rate limiting is used by some ISPs although other ISPs believe it is 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 not really useful since attackers are not well behaved and it doesn't
provide any operational benefit over the complexity. Some ISPs feel provide any operational benefit over the complexity. Some ISPs feel
that rate limiting can also make an attacker's job easier by that rate limiting can also make an attacker's job easier by
requiring the attacker to send less traffic to starve legitimate requiring the attacker to send less traffic to starve legitimate
traffic that is part of a rate limiting scheme. Rate limiting may be traffic that is part of a rate limiting scheme. Rate limiting may be
improved by developing flow-based rate-limiting capabilities with improved by developing flow-based rate-limiting capabilities with
filtering hooks. This would improve the performance as well as the filtering hooks. This would improve the performance as well as the
granularity over current capabilities. granularity over current capabilities.
Lack of consistency regarding the ability to filter, especially with Lack of consistency regarding the ability to filter, especially with
respect to performance issues cause some ISPs to not implement BCP38 respect to performance issues cause some ISPs to not implement BCP38
guidelines for ingress filtering. One such example is at edge boxes and BCP84 guidelines for ingress filtering. One such example is at
where you have up to 1000 T1's connecting into a router with an OC-12 edge boxes where you have up to 1000 T1's connecting into a router
uplink. Some deployed devices experience a large performance impact with an OC-12 uplink. Some deployed devices experience a large
with filtering which is unacceptable for passing customer traffic performance impact with filtering which is unacceptable for passing
through. Where performance is not an issue, the ISPs make a tradeoff customer traffic through, though ingress filtering (uRPF) might be
between management versus risk. applicable at the devices connecting these aggregation routers.
Where performance is not an issue, the ISPs make a tradeoff between
management versus risk.
2.5. Routing Control Plane 2.4. Routing Control Plane
The routing control plane deals with all the traffic which is part of The routing control plane deals with all the traffic which is part of
establishing and maintaining routing protocol information. establishing and maintaining routing protocol information.
2.5.1. Threats / Attacks 2.4.1. Threats / Attacks
Attacks on the routing control plane can be both from passive or Attacks on the routing control plane can be both from passive or
active sources. Passive attacks are possible if someone has the active sources. Passive attacks are possible if someone has the
capability to intercept data between the communicating routing peers. capability to intercept data between the communicating routing peers.
This can be accomplished if a single routing peer is somehow 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 compromised and can act as a network sniffer or if it is possible to
insert a new device which acts as a network sniffer. insert a new device which acts as a network sniffer.
Active attacks are possible for both on-path and off-path scenarios. 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 For on-path active attacks, the situation is the same as for a
skipping to change at page 23, line 10 skipping to change at page 19, line 49
attacker impersonating a legitimate routing peer and exchanging attacker impersonating a legitimate routing peer and exchanging
routing information. Unintentional active attacks are more common routing information. Unintentional active attacks are more common
due to configuration errors, which cause legitimate routing peers to due to configuration errors, which cause legitimate routing peers to
feed invalid routing information to other neighboring peers. feed invalid routing information to other neighboring peers.
For off-path active attacks, the attacks are generally limited to For off-path active attacks, the attacks are generally limited to
message insertion or modification which can divert traffic to message insertion or modification which can divert traffic to
illegitimate destinations and cause traffic to never reach its illegitimate destinations and cause traffic to never reach its
intended destination. intended destination.
2.5.2. Confidentiality Violations 2.4.1.1. Confidentiality Violations
Confidentiality violations can occur when a miscreant intercepts any Confidentiality violations can occur when a miscreant intercepts any
of the routing update traffic. This is becoming more of a concern of the routing update traffic. This is becoming more of a concern
because many ISPs are classifying addressing schemes and network because many ISPs are classifying addressing schemes and network
topologies as private and proprietary information. It is also a topologies as private and proprietary information. It is also a
concern because the routing protocol packets contain information that concern because the routing protocol packets contain information that
may show ways in which routing sessions could be spoofed or hijacked. 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 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 miscreants can insert themselves into the traffic path or divert the
traffic path and violate the confidentiality of user data. traffic path and violate the confidentiality of user data.
2.5.3. Offline Cryptographic Attacks 2.4.1.2. Offline Cryptographic Attacks
If any cryptographic mechanism was used to provide for data integrity If any cryptographic mechanism was used to provide for data integrity
and confidentiality, an offline cryptographic attack could and confidentiality, an offline cryptographic attack could
potentially compromise the data. The traffic would need to be potentially compromise the data. The traffic would need to be
captured either by eavesdropping on the network or by being able to captured either by eavesdropping on the network or by being able to
divert traffic to a malicious user. Note that by using divert traffic to a malicious user. Note that by using
cryptographically protected routing information, the latter would cryptographically protected routing information, the latter would
require the cryptographic key to already be compromised anyway so require the cryptographic key to already be compromised anyway so
this attack is only feasible if a device was able eavesdrop and this attack is only feasible if a device was able eavesdrop and
capture the cryptographically protected routing information. capture the cryptographically protected routing information.
2.5.4. Replay Attacks 2.4.1.3. Replay Attacks
For a replay attack to be successful, the routing control plane For a replay attack to be successful, the routing control plane
traffic would need to first be captured either on-path or diverted to traffic would need to first be captured either on-path or diverted to
an attacker to later be replayed to the intended recipient. 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.5.5. Message Insertion/Deletion/Modification 2.4.1.4. Message Insertion/Deletion/Modification
Routing control plane traffic can be manipulated by someone in Routing control plane traffic can be manipulated by someone in
control of intermediate hosts. In addition, traffic can be injected control of intermediate hosts. In addition, traffic can be injected
by forging IP addresses, where a remote router sends out packets by forging IP addresses, where a remote router sends out packets
which appear to come from another, trusted router. If enough traffic which appear to come from another, trusted router. If enough traffic
is injected to be processed by limited memory routers it can cause a is injected to be processed by limited memory routers it can cause a
DoS attack. DoS attack.
2.5.6. Man-In-The-Middle 2.4.1.5. Man-In-The-Middle
A man-in-the-middle attack attacks the identity of a communicating A man-in-the-middle attack attacks the identity of a communicating
peer rather than the data stream itself. The attacker intercepts peer rather than the data stream itself. The attacker intercepts
traffic that is sent from one routing peer to the other and traffic that is sent from one routing peer to the other and
communicates on behalf of one of the peers. This can lead to communicates on behalf of one of the peers. This can lead to
diversion of the user traffic to either an unauthorized receiving diversion of the user traffic to either an unauthorized receiving
party or cause legitimate traffic to never reach its intended party or cause legitimate traffic to never reach its intended
destination. destination.
2.5.7. Security Practices 2.4.2. Security Practices
Securing the routing control plane takes many features which are Securing the routing control plane takes many features which are
generally deployed as a system. MD5 authentication is used by some generally deployed as a system. MD5 authentication is used by some
ISPs to validate the sending peer and to ensure that the data in ISPs to validate the sending peer and to ensure that the data in
transit has not been altered. Some ISPs only deploy MD5 transit has not been altered. Some ISPs only deploy MD5
authentication at customer's request. Additional sanity checks to authentication at customer's request. Additional sanity checks to
ensure with reasonable certainty that the received routing update was ensure with reasonable certainty that the received routing update was
originated by a valid routing peer include route filters and the originated by a valid routing peer include route filters and the
Generalized TTL Security Mechanism (GTSM) feature [RFC3682] Generalized TTL Security Mechanism (GTSM) feature [RFC3682]
(sometimes also referred to as the TTL-Hack). Note that validating (sometimes also referred to as the TTL-Hack). The GTSM feature is
whether a legitimate peer has the authority to send the contents of used for protocols such as BGP and makes use of a packet's Time To
the routing update is a difficult problem that needs yet to be Live (TTL) field (IPv4) or Hop Limit (IPv6) to protect communicating
resolved. peers.
In the case of BGP routing, a variety of policies are deployed to Packet filters are used to limit which systems can appear as a valid
limit the propagation of invalid routing information. These include: peer while route filters are used to limit which routes are believed
incoming and outgoing prefix filters for BGP customers, incoming and from a valid peer. In the case of BGP routing, a variety of policies
outgoing prefix filters for peers and upstream neighbors, incoming are deployed to limit the propagation of invalid routing information.
AS-PATH filter for BGP customers, outgoing AS-PATH filter towards These include: incoming and outgoing prefix filters for BGP
peers and upstream neighbors, route dampening and rejecting selected customers, incoming and outgoing prefix filters for peers and
attributes and communities. Consistency between these policies upstream neighbors, incoming AS-PATH filter for BGP customers,
varies greatly although there is a trend to start depending on AS- outgoing AS-PATH filter towards peers and upstream neighbors, route
PATH filters because they are much more manageable than the large dampening and rejecting selected attributes and communities.
numbers of prefix filters that would need to be maintained. Many Consistency between these policies varies greatly and there is a
ISPs also do not propagate interface IP addresses to further reduce definite distinction whether the other end is an end-site vs an
attack vectors on routers and connected customers. 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.
2.5.8. Security Services 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 overload attacks. When the limit is
exceeded, the session is either reset or further updates are denied.
Typically a lower warning threshold is also configured.
Some large ISPs require that routes be registered in an Internet
Routing Registry [IRR] which can then be part of the 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 Authentication - Not applicable
o User Authorization - Not applicable o User Authorization - Not applicable
o Data Origin Authentication - By using MD5 authentication and/or o Data Origin Authentication - By using MD5 authentication and/or
the TTL-hack a routing peer can be reasonably certain that traffic the TTL-hack a routing peer can be reasonably certain that traffic
originated from a valid peer. originated from a valid peer.
o Access Control - Route filters, AS-PATH filters and prefix limits o Access Control - Route filters, AS-PATH filters and prefix limits
skipping to change at page 25, line 19 skipping to change at page 22, line 32
o Data Confidentiality - Not implemented o Data Confidentiality - Not implemented
o Auditing / Logging - Filter exceptions are logged. o Auditing / Logging - Filter exceptions are logged.
o DoS Mitigation - Many DoS attacks are mitigated using a o DoS Mitigation - Many DoS attacks are mitigated using a
combination of techniques including: MD5 authentication, the GTSM combination of techniques including: MD5 authentication, the GTSM
feature, filtering routing advertisements to bogons and filtering feature, filtering routing advertisements to bogons and filtering
routing advertisements to one's own network. routing advertisements to one's own network.
2.5.9. Additional Considerations 2.4.4. Additional Considerations
So far the primary concern to secure the routing control plane has 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 been to validate the sending peer and to ensure that the data in
transit has not been altered. Although MD5 routing protocol transit has not been altered. Although MD5 routing protocol
extensions have been implemented which can provide both services, extensions have been implemented which can provide both services,
they are not consistently deployed amongst ISPs. Two major they are not consistently deployed amongst ISPs. Two major
deployment concerns have been implementation issues where both deployment concerns have been implementation issues where both
software bugs and the lack of graceful re-keying options have caused software bugs and the lack of graceful re-keying options have caused
significant network down times. Also, some ISPs express concern that significant network down times. Also, some ISPs express concern that
deploying MD5 authentication will itself be a worse DoS attack victim deploying MD5 authentication will itself be a worse DoS attack victim
and prefer to use a combination of other risk mitigation mechanisms and prefer to use a combination of other risk mitigation mechanisms
such as GTSM and route filters. such as GTSM (for BGP) and route filters. An issue with GTSM is that
it is not supported on all devices across different vendors
Route filters are used to limit what routes are believed from a valid products'.
peer. Packet filters are used to limit which systems can appear as a
valid peer. 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. Additionally,
some large ISPs require that routes be registered in an Internet
Routing Registry [IRR] which can then be part of the 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.
IPsec is not deployed since the operational management aspects of IPsec is not deployed since the operational management aspects of
ensuring interoperability and reliable configurations is too complex ensuring interoperability and reliable configurations is too complex
and time consuming to be operationally viable. There is also limited and time consuming to be operationally viable. There is also limited
concern to the confidentiality of the routing information. The concern to the confidentiality of the routing information. The
integrity and validity of the updates are of much greater concern. integrity and validity of the updates are of much greater concern.
There is concern for manual or automated actions which introduce new There is concern for manual or automated actions which introduce new
routes and can affect the entire routing domain. routes and can affect the entire routing domain.
2.6. Software Upgrades and Configuration Integrity / Validation 2.5. Software Upgrades and Configuration Integrity / Validation
Software upgrades and configuration changes are usually performed as Software upgrades and configuration changes are usually performed as
part of either in-band or OOB management functions. However, there part of either in-band or OOB management functions. However, there
are additional considerations to be taken into account which are are additional considerations to be taken into account which are
enumerated in this section. enumerated in this section.
2.6.1. Threats / Attacks 2.5.1. Threats / Attacks
Attacks performed on system software and configurations can be both Attacks performed on system software and configurations can be both
from passive or active sources. Passive attacks are possible if from passive or active sources. Passive attacks are possible if
someone has the capability to intercept data between the network someone has the capability to intercept data between the network
infrastructure device and the system which is downloading or infrastructure device and the system which is downloading or
uploading the software or configuration information. This can be uploading the software or configuration information. This can be
accomplished if a single infrastructure device is somehow compromised 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 and can act as a network sniffer or if it is possible to insert a new
device which acts as a network sniffer. device which acts as a network sniffer.
Active attacks are possible for both on-path and off-path scenarios. 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 For on-path active attacks, the situation is the same as for a
passive attack, where either a device has to already be compromised passive attack, where either a device has to already be compromised
or a device can be inserted into the path. For off-path active or a device can be inserted into the path. For off-path active
attacks, the attacks are generally limited to message insertion or attacks, the attacks are generally limited to message insertion or
modification where the attacker may wish to load illegal software or modification where the attacker may wish to load illegal software or
configuration files to an infrastructure device. configuration files to an infrastructure device.
2.6.2. Confidentiality Violations 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 Confidentiality violations can occur when a miscreant intercepts any
of the software image or configuration information. The software of the software image or configuration information. The software
image may give an indication of exploits which the device is image may give an indication of exploits which the device is
vulnerable to while the configuration information can inadvertently vulnerable to while the configuration information can inadvertently
lead attackers to identify critical infrastructure IP addresses and lead attackers to identify critical infrastructure IP addresses and
passwords. passwords.
2.6.3. Offline Cryptographic Attacks 2.5.1.2. Offline Cryptographic Attacks
If any cryptographic mechanism was used to provide for data integrity If any cryptographic mechanism was used to provide for data integrity
and confidentiality, an offline cryptographic attack could and confidentiality, an offline cryptographic attack could
potentially compromise the data. The traffic would need to be potentially compromise the data. The traffic would need to be
captured either by eavesdropping on the network or by being able to captured either by eavesdropping on the communication path or by
divert traffic to a malicious user. being able to divert traffic to a malicious user.
2.6.4. Replay Attacks 2.5.1.3. Replay Attacks
For a replay attack to be successful, the software image or For a replay attack to be successful, the software image or
configuration file would need to first be captured either on-path or configuration file would need to first be captured either on-path or
diverted to an attacker to later be replayed to the intended diverted to an attacker to later be replayed to the intended
recipient. recipient. Additionally, since many protocols do have replay
protection capabilities, these would have to be subverted as well in
applicable situations.
2.6.5. Message Insertion/Deletion/Modification 2.5.1.4. Message Insertion/Deletion/Modification
Software images and configuration files can be manipulated by someone Software images and configuration files can be manipulated by someone
in control of intermediate hosts. By forging an IP address and in control of intermediate hosts. By forging an IP address and
impersonating a valid host which can download software images or impersonating a valid host which can download software images or
configuration files, invalid files can be downloaded to an configuration files, invalid files can be downloaded to an
infrastructure device. An invalid software image or configuration infrastructure device. This can also be the case from trusted
file can cause a device to hang and become inoperable. Spoofed vendors who may unbeknownst to them have compromised trusted hosts.
configuration files can be hard to detect, especially when the only An invalid software image or configuration file can cause a device to
added command is to allow a miscreant access to that device by hang and become inoperable. Spoofed configuration files can be hard
entering a filter allowing a specific host access and configuring a to detect, especially when the only added command is to allow a
local username/password database entry for authentication to that miscreant access to that device by entering a filter allowing a
device. specific host access and configuring a local username/password
database entry for authentication to that device.
2.6.6. Man-In-The-Middle 2.5.1.5. Man-In-The-Middle
A man-in-the-middle attack attacks the identity of a communicating A man-in-the-middle attack attacks the identity of a communicating
peer rather than the data stream itself. The attacker intercepts peer rather than the data stream itself. The attacker intercepts
traffic that is sent between the infrastructure device and the host traffic that is sent between the infrastructure device and the host
used to upload/download the system image or configuration file. He/ used to upload/download the system image or configuration file. He/
she can then act on behalf of one or both of these systems. 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, If an attacker obtained a copy of the software image being deployed,
he could potentially exploit a known vulnerability and gain access to he could potentially exploit a known vulnerability and gain access to
the system. From a captured configuration file, he could obtain the system. From a captured configuration file, he could obtain
confidential network topology information or even more damaging confidential network topology information or even more damaging
information if any of the passwords in the configuration file were information if any of the passwords in the configuration file were
not encrypted. not encrypted.
2.6.7. Security Practices 2.5.2. Security Practices
Images and configurations are stored on specific hosts which have Images and configurations are stored on specific hosts which have
limited access. All access and activity relating to these hosts are limited access. All access and activity relating to these hosts are
authenticated and logged via AAA services. When uploaded/downloading authenticated and logged via AAA services. When uploaded/downloading
any system software or configuration files, either TFTP, FTP or SCP any system software or configuration files, either TFTP, FTP or SCP
can be used. Where possible, SCP is used to secure the data transfer 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 and FTP is generally never used. All SCP access is username/password
authenticated but since this requires an interactive shell, most ISPs authenticated but since this requires an interactive shell, most ISPs
will use shared key authentication to avoid the interactive shell. will use shared key authentication to avoid the interactive shell.
While TFTP access does not have any security measures, it is still While TFTP access does not have any security measures, it is still
skipping to change at page 28, line 11 skipping to change at page 25, line 23
written TFTP servers will support MAC-based authentication. The MAC- written TFTP servers will support MAC-based authentication. The MAC-
based authentication is more common when using TFTP to bootstrap based authentication is more common when using TFTP to bootstrap
routers remotely using TFTP. routers remotely using TFTP.
In most environments scripts are used for maintaining the images and In most environments scripts are used for maintaining the images and
configurations of a large number of routers. To ensure the integrity configurations of a large number of routers. To ensure the integrity
of the configurations, every hour the configuration files are polled of the configurations, every hour the configuration files are polled
and compared to the previously polled version to find discrepancies. and compared to the previously polled version to find discrepancies.
In at least one environment these tools are Kerberized to take In at least one environment these tools are Kerberized to take
advantage of automated authentication (not confidentiality). advantage of automated authentication (not confidentiality).
'Rancid' is one popular publicly available tool for detecting
configuration and system changes.
Filters are used to limit access to uploading/downloading Filters are used to limit access to uploading/downloading
configuration files and system images to specific IP addresses and configuration files and system images to specific IP addresses and
protocols. protocols.
The software images perform CRC-checks and the system binaries use The software images perform CRC-checks and the system binaries use
the MD5 algorithm to validate integrity. Many ISPs expressed the MD5 algorithm to validate integrity. Many ISPs expressed
interest in having software image integrity validation based on the interest in having software image integrity validation based on the
MD5 algorithm for enhanced security. MD5 algorithm for enhanced security.
In all configuration files, most passwords are stored in an In all configuration files, most passwords are stored in an encrypted
obfuscated format. This includes passwords for user authentication, format. Note that the encryption techniques used in varying products
MD5 shared secrets, AAA server shared secrets, NTP shared secrets, can vary and that some weaker encryption schemes may be subject to
etc. For older software which may not support this functionality, off-line dictionary attacks. This includes passwords for user
configuration files may contain some passwords in readable format. authentication, MD5-authentication shared secrets, AAA server shared
Most ISPs mitigate any risk of password compromise by either storing secrets, NTP shared secrets, etc. For older software which may not
these configuration files without the password lines or by requiring support this functionality, configuration files may contain some
authenticated and authorized access to the configuration files which passwords in readable format. Most ISPs mitigate any risk of
are stored on protected OOB management devices. password compromise by either storing these configuration files
without the password lines or by requiring authenticated and
authorized access to the configuration files which are stored on
protected OOB management devices.
Automated security validation is performed on infrastructure devices Automated security validation is performed on infrastructure devices
using nmap and nessus to ensure valid configuration against many of using nmap and nessus to ensure valid configuration against many of
the well-known attacks. the well-known attacks.
2.6.8. Security Services 2.5.3. Security Services
o User Authentication - All users are authenticated before being o User Authentication - All users are authenticated before being
able to download/upload any system images or configuration files. able to download/upload any system images or configuration files.
o User Authorization - All authenticated users are granted specific o User Authorization - All authenticated users are granted specific
privileges to download or upload system images and/or privileges to download or upload system images and/or
configuration files. configuration files.
o Data Origin Authentication - Filters are used to limit access to o Data Origin Authentication - Filters are used to limit access to
uploading/downloading configuration files and system images to uploading/downloading configuration files and system images to
specific IP addresses. specific IP addresses.
o Access Control - Filters are used to limit access to uploading/ o Access Control - Filters are used to limit access to uploading/
downloading configuration files and system images to specific IP downloading configuration files and system images to specific IP
addresses and protocols. addresses and protocols.
o Data Integrity - All systems use either a CRC-check or MD5 o Data Integrity - All systems use either a CRC-check or MD5
authentication to ensure data integrity. authentication to ensure data integrity. Also tools such as
rancid are used to automatically detect configuration changes.
o Data Confidentiality - If the SCP protocol is used then there is o Data Confidentiality - If the SCP protocol is used then there is
confidentiality of the downloaded/uploaded configuration files and confidentiality of the downloaded/uploaded configuration files and
system images. system images.
o Auditing / Logging - All access and activity relating to o Auditing / Logging - All access and activity relating to
downloading/uploading system images and configuration files are downloading/uploading system images and configuration files are
logged via AAA services and filter exception rules. logged via AAA services and filter exception rules.
o DoS Mitigation - TBD o DoS Mitigation - TBD
2.6.9. Additional Considerations 2.5.4. Additional Considerations
Where the MD5 algorithm is not used to perform data integrity Where the MD5 algorithm is not used to perform data integrity
checking of software images and configuration files, ISPs have checking of software images and configuration files, ISPs have
expressed an interest in having this functionality. IPsec is expressed an interest in having this functionality. IPsec is
considered too cumbersome and operationally difficult to use for data considered too cumbersome and operationally difficult to use for data
integrity and confidentiality. integrity and confidentiality.
2.7. Logging Considerations 2.6. Logging Considerations
Although logging is part of all the previous sections, it is Although logging is part of all the previous sections, it is
important enough to be covered as a separate item. The main issues important enough to be covered as a separate item. The main issues
revolve around what gets logged, how long are logs kept and what revolve around what gets logged, how long are logs kept and what
mechanisms are used to secure the logged information while it is in mechanisms are used to secure the logged information while it is in
transit and while it is stored. transit and while it is stored.
2.7.1. Threats / Attacks 2.6.1. Threats / Attacks
Attacks on the logged data can be both from passive or active Attacks on the logged data can be both from passive or active
sources. Passive attacks are possible if someone has the capability sources. Passive attacks are possible if someone has the capability
to intercept data between the recipient logging server and the device to intercept data between the recipient logging server and the device
the logged data originated from. This can be accomplished if a the logged data originated from. This can be accomplished if a
single infrastructure device is somehow compromised and can act as a single infrastructure device is somehow compromised and can act as a
network sniffer or if it is possible to insert a new device which network sniffer or if it is possible to insert a new device which
acts as a network sniffer. acts as a network sniffer.
Active attacks are possible for both on-path and off-path scenarios. 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 For on-path active attacks, the situation is the same as for a
passive attack, where either a device has to already be compromised passive attack, where either a device has to already be compromised
or a device can be inserted into the path. For off-path active or a device can be inserted into the path. For off-path active
attacks, the attacks are generally limited to message insertion or attacks, the attacks are generally limited to message insertion or
modification which can alter the logged data to keep any compromise modification which can alter the logged data to keep any compromise
from being detected or to destroy any evidence which could be used from being detected or to destroy any evidence which could be used
for criminal prosecution. for criminal prosecution.
2.7.1.1. Confidentiality Violations 2.6.1.1. Confidentiality Violations
Confidentiality violations can occur when a miscreant intercepts any Confidentiality violations can occur when a miscreant intercepts any
of the logging data which is in transit on the network. This could of the logging data which is in transit on the network. This could
lead to privacy violations if some of the logged data has not been 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 sanitized to disallow any data that could be a violation of privacy
to be included in the logged data. to be included in the logged data.
2.7.1.2. Offline Cryptographic Attacks 2.6.1.2. Offline Cryptographic Attacks
If any cryptographic mechanism was used to provide for data integrity If any cryptographic mechanism was used to provide for data integrity
and confidentiality, an offline cryptographic attack could and confidentiality, an offline cryptographic attack could
potentially compromise the data. The traffic would need to be potentially compromise the data. The traffic would need to be
captured either by eavesdropping on the network or by being able to captured either by eavesdropping on the network or by being able to
divert traffic to a malicious user. divert traffic to a malicious user.
2.7.1.3. Replay Attacks 2.6.1.3. Replay Attacks
For a replay attack to be successful, the logging data would need to 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 first be captured either on-path or diverted to an attacker and later
replayed to the recipient. [is reply handled by syslog protocol?] replayed to the recipient.
2.7.1.4. Message Insertion/Deletion/Modification 2.6.1.4. Message Insertion/Deletion/Modification
Logging data could be injected, deleted or modified by someone in Logging data could be injected, deleted or modified by someone in
control of intermediate hosts. Logging data can also be injected by control of intermediate hosts. Logging data can also be injected by
forging packets from either legitimate or illegitimate IP addresses. forging packets from either legitimate or illegitimate IP addresses.
2.7.1.5. Man-In-The-Middle 2.6.1.5. Man-In-The-Middle
A man-in-the-middle attack attacks the identity of a communicating A man-in-the-middle attack attacks the identity of a communicating
peer rather than the data stream itself. The attacker intercepts peer rather than the data stream itself. The attacker intercepts
traffic that is sent between the infrastructure device and the traffic that is sent between the infrastructure device and the
logging server or traffic sent between the logging server and the logging server or traffic sent between the logging server and the
database which is used to archive the logged data. Any unauthorized database which is used to archive the logged data. Any unauthorized
access to logging information could lead to knowledge of private and access to logging information could lead to knowledge of private and
proprietary network topology information which could be used to proprietary network topology information which could be used to
compromise portions of the network. An additional concern is having compromise portions of the network. An additional concern is having
access to logging information which could be deleted or modified so access to logging information which could be deleted or modified so
as to cover any traces of a security breach. as to cover any traces of a security breach.
2.7.2. Security Practices 2.6.2. Security Practices
Logging is mostly performed on an exception auditing basis when it Logging is mostly performed on an exception auditing basis when it
comes to filtering (i.e. traffic which is NOT allowed is logged). comes to filtering (i.e. traffic which is NOT allowed is logged).
This is to assure that the logging servers are not overwhelmed with This is to assure that the logging servers are not overwhelmed with
data which would render most logs unusable. Typically the data data which would render most logs unusable. Typically the data
logged will contain the source and destination IP addresses and layer logged will contain the source and destination IP addresses and layer
4 port numbers as well as a timestamp. The syslog protocol is used 4 port numbers as well as a timestamp. The syslog protocol is used
to transfer the logged data between the infrastructure device to the to transfer the logged data between the infrastructure device to the
syslog server. Many ISPs use the OOB management network to transfer syslog server. Many ISPs use the OOB management network to transfer
syslog data since there is virtually no security performed between syslog data since there is virtually no security performed between
the syslog server and the device. All ISPs have multiple syslog the syslog server and the device. All ISPs have multiple syslog
servers - some ISPs choose to use separate syslog servers for varying servers - some ISPs choose to use separate syslog servers for varying
infrastructure devices (i.e. one syslog server for backbone routers, infrastructure devices (i.e. one syslog server for backbone routers,
one syslog server for customer edge routers, etc.) one syslog server for customer edge routers, etc.)
The timestamp is derived from NTP which is generally configured as a The timestamp is derived from NTP which is generally configured as a
flat hierarchy at stratum1 and stratum2 to have less configuration flat hierarchy at stratum1 and stratum2 to have less configuration
and less maintenance. Each router is configured with one stratum1 and less maintenance. Consistency of configuration and redundancy is
peer both locally and remotely. 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 In addition to logging filtering exceptions, the following is
typically logged: Routing protocol state changes, all device access typically logged: Routing protocol state changes, all device access
(regardless of authentication success or failure), all commands (regardless of authentication success or failure), all commands
issued to a device, all configuration changes and all router events issued to a device, all configuration changes and all router events
(boot-up/flaps). (boot-up/flaps).
The main function of any of these log messages is to see what the 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 device is doing as well as to try and ascertain what certain
malicious attackers are trying to do. Some ISPs put in passive malicious attackers are trying to do. Since syslog is an unreliable
devices to see routing updates and withdrawals and not rely solely on protocol, when routers boot or lose adjacencies, not all messages
the device for log files. This provides a backup mechanism to see will get delivered to the remote syslog server. Some vendors may
what is going on in the network in the event that a device may implement syslog buffering (e.g., buffer the messages until you have
'forget' to do syslog if the CPU is busy. 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 The logs from the various syslog server devices are generally
transferred into databases at a set interval which can be anywhere transferred into databases at a set interval which can be anywhere
from every 10 minutes to every hour. One ISP uses Rsync to push the 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 data into a database and then the information is sorted manually by
someone SSH'ing to that database. someone SSH'ing to that database.
2.7.3. Security Services 2.6.3. Security Services
o User Authentication - Not applicable o User Authentication - Not applicable
o User Authorization - Not applicable o User Authorization - Not applicable
o Data Origin Authentication - Not implemented o Data Origin Authentication - Not implemented
o Access Control - Filtering on logging host and server IP address o Access Control - Filtering on logging host and server IP address
to ensure that syslog information only goes to specific syslog to ensure that syslog information only goes to specific syslog
hosts. hosts.
skipping to change at page 32, line 16 skipping to change at page 29, line 43
o Data Confidentiality - Not implemented o Data Confidentiality - Not implemented
o Auditing / Logging - This entire section deals with logging. o Auditing / Logging - This entire section deals with logging.
o DoS Mitigation - An OOB management system is used and sometimes o DoS Mitigation - An OOB management system is used and sometimes
different syslog servers are used for logging information from different syslog servers are used for logging information from
varying equipment. Exception logging tries to keep information to varying equipment. Exception logging tries to keep information to
a minimum. a minimum.
2.7.4. Additional Considerations 2.6.4. Additional Considerations
There is no security with syslog and ISPs are fully cognizant of There is no security with syslog and ISPs are fully cognizant of
this. IPsec is considered too operationally expensive and cumbersome this. IPsec is considered too operationally expensive and cumbersome
to deploy. Syslog-ng and stunnel are being looked at for providing to deploy. Syslog-ng and stunnel are being looked at for providing
better authenticated and integrity protected solutions. Mechanisms better authenticated and integrity protected solutions. Mechanisms
to prevent unauthorized personnel from tampering with logs is to prevent unauthorized personnel from tampering with logs is
constrained to auditing who has access to the logging servers and constrained to auditing who has access to the logging servers and
files. files.
ISPs expressed requirements for more than just UDP syslog. ISPs expressed requirements for more than just UDP syslog.
Additionally, they would like more granular and flexible facilities Additionally, they would like more granular and flexible facilities
and priorities, i.e. specific logs to specific servers. Also, a and priorities, i.e. specific logs to specific servers. Also, a
common format for reporting standard events so that they don't have common format for reporting standard events so that they don't have
to modify parsers after each upgrade of vendor device or software. to modify parsers after each upgrade of vendor device or software.
2.8. Filtering Considerations 2.7. Filtering Considerations
Although filtering has been covered under many of the previous Although filtering has been covered under many of the previous
sections, this section will provide some more insights to the sections, this section will provide some more insights to the
filtering considerations that are currently being taken into account. filtering considerations that are currently being taken into account.
Filtering is now being categorized into three specific areas: data Filtering is now being categorized into three specific areas: data
plane, management plane and routing control plane. plane, management plane and routing control plane.
2.8.1. Data Plane Filtering 2.7.1. Data Plane Filtering
Data plane filters control the traffic that traverses through a Data plane filters control the traffic that traverses through a
device and affect transit traffic. Most ISPs deploy these kinds of device and affect transit traffic. Most ISPs deploy these kinds of
filters at the customer facing edge devices to mitigate spoofing filters at the customer facing edge devices to mitigate spoofing
attacks using BCP38 and BCP84 guidelines. attacks using BCP38 and BCP84 guidelines.
2.8.2. Management Plane Filtering 2.7.2. Management Plane Filtering
Management filters control the traffic to and from a device. All of Management filters control the traffic to and from a device. All of
the protocols which are used for device management fall under this the protocols which are used for device management fall under this
category and includes SSH, Telnet, SNMP, NTP, HTTP, DNS, TFTP, FTP, category and includes SSH, Telnet, SNMP, NTP, HTTP, DNS, TFTP, FTP,
SCP and Syslog. This type of traffic is often filtered per interface SCP and Syslog. This type of traffic is often filtered per interface
and is based on any combination of protocol, source and destination and is based on any combination of protocol, source and destination
IP address and source and destination port number. Some devices IP address and source and destination port number. Some devices
support functionality to apply management filters to the device support functionality to apply management filters to the device
rather than to the specific interfaces (e.g. receive ACL or loopback rather than to the specific interfaces (e.g. receive ACL or loopback
interface ACL) which is gaining wider acceptance. Note that logging interface ACL) which is gaining wider acceptance. Note that logging
skipping to change at page 33, line 20 skipping to change at page 30, line 49
granularity is often required to more specifically log the required granularity is often required to more specifically log the required
exceptions. exceptions.
Any services that are not specifically used are turned off. Any services that are not specifically used are turned off.
IPv6 networks require the use of specific ICMP messages for proper IPv6 networks require the use of specific ICMP messages for proper
protocol operation. Therefore, ICMP cannot be completely filtered to protocol operation. Therefore, ICMP cannot be completely filtered to
and from a device. Instead, granular ICMPv6 filtering is always and from a device. Instead, granular ICMPv6 filtering is always
deployed to allow for specific ICMPv6 types to be sourced or destined 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 to a network device. A good guideline for IPv6 filtering is in the
draft work in progress on Best Current Practices for Filtering ICMPv6 draft work in progress on Recommendations for Filtering ICMPv6
Messages in Firewalls [I-D.ietf-v6ops-icmpv6-filtering-bcp]. Messages in Firewalls [I-D.ietf-v6ops-icmpv6-filtering-recs].
2.8.3. Routing Control Plane Filtering 2.7.3. Routing Control Plane Filtering
Routing filters are used to control the flow of routing information. Routing filters are used to control the flow of routing information.
In IPv6 networks, some providers are liberal in accepting /48s due to In IPv6 networks, some providers are liberal in accepting /48s due to
the still unresolved multihoming issues. Any announcement received the still unresolved multihoming issues while others filter at
that is longer than a /48 for IPv6 routing and a /24 for IPv4 routing allocation boundaries which are typically at /32. Any announcement
is filtered out of eBGP. Note that this is for non-customer traffic. received that is longer than a /48 for IPv6 routing and a /24 for
Most ISPs will accept any agreed upon prefix length from its IPv4 routing is filtered out of eBGP. Note that this is for non-
customer(s). customer traffic. Most ISPs will accept any agreed upon prefix
length from its customer(s).
2.9. Denial of Service Tracking / Tracing 2.8. Denial of Service Tracking / Tracing
Denial of Service attacks are an ever increasing problem and require Denial of Service attacks are an ever increasing problem and require
vast amounts of resources to combat effectively. Some large ISPs do vast amounts of resources to combat effectively. Some large ISPs do
not concern themselves with attack streams that are less than 1G in not concern themselves with attack streams that are less than 1G in
bandwidth - this is on the larger pipes where 1G is essentially less bandwidth - this is on the larger pipes where 1G is essentially less
than 5% of offered load. This is largely due to the large amounts of than 5% of offered load. This is largely due to the large amounts of
DDoS traffic which continually requires investigation and mitigation. DDoS traffic which continually requires investigation and mitigation.
At last count the number of hosts making up large distributed DoS At last count the number of hosts making up large distributed DoS
botnets exceeded 1 million hosts. botnets exceeded 1 million hosts.
New techniques are continually evolving to automate the process of New techniques are continually evolving to automate the process of
detecting DoS sources and mitigating any adverse effects as quickly detecting DoS sources and mitigating any adverse effects as quickly
as possible. At this time, ISPs are using a variety of mitigation as possible. At this time, ISPs are using a variety of mitigation
techniques including: sink hole routing, black-hole triggered techniques including: sink hole routing, black-hole triggered
routing, uRPF and rate limiting. Each of these techniques will be routing, uRPF, rate limiting and specific control plane traffic
detailed below. enhancements. Each of these techniques will be detailed below.
2.9.1. Sink Hole Routing 2.8.1. Sink Hole Routing
Sink hole routing refers to injecting a more specific route for any Sink hole routing refers to injecting a more specific route for any
known attack traffic which will ensure that the malicious traffic is known attack traffic which will ensure that the malicious traffic is
redirected to a valid device or specific system where it can be redirected to a valid device or specific system where it can be
analyzed. analyzed.
2.9.2. Black-Hole Triggered Routing 2.8.2. Black-Hole Triggered Routing
Black-hole triggered routing (also referred to as Remote Triggered Black-hole triggered routing (also referred to as Remote Triggered
Black Hole Filtering) is a technique where the BGP routing protocol Black Hole Filtering) is a technique where the BGP routing protocol
is used to propagate routes which in turn redirects attack traffic to is used to propagate routes which in turn redirects attack traffic to
the null interface where it is effectively dropped. This technique the null interface where it is effectively dropped. This technique
is often used in large routing infrastructures since BGP can is often used in large routing infrastructures since BGP can
propagate the information in a fast effective manner as opposed to propagate the information in a fast effective manner as opposed to
using any packet-based filtering techniques on hundreds or thousands using any packet-based filtering techniques on hundreds or thousands
of routers. [refer to the following NANOG presentation for a more of routers. [refer to the following NANOG presentation for a more
complete description http://www.nanog.org/mtg-0402/pdf/morrow.pdf] 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 blackholing traffic
which appeared to come from a certain site. On the other hand, this
blackhole technique can decrease the collateral damage caused by an
overly large attack aimed at something other than critical services.
2.9.3. Unicast Reverse Path Forwarding 2.8.3. Unicast Reverse Path Forwarding
Unicast Reverse Path Forwarding (uRPF) is a mechanism for validating Unicast Reverse Path Forwarding (uRPF) is a mechanism for validating
whether an incoming packet has a legitimate source address or not. whether an incoming packet has a legitimate source address or not.
It has two modes: strict mode and loose mode. In strict mode, uRPF It has two modes: strict mode and loose mode. In strict mode, uRPF
checks whether the incoming packet has a source address that matches checks whether the incoming packet has a source address that matches
a prefix in the routing table, and whether the interface expects to a prefix in the routing table, and whether the interface expects to
receive a packet with this source address prefix. If the incoming receive a packet with this source address prefix. If the incoming
packet fails the unicast RPF check, the packet is not accepted on the packet fails the unicast RPF check, the packet is not accepted on the
incoming interface. Loose mode uRPF is not as specific and the incoming interface. Loose mode uRPF is not as specific and the
incoming packet is accepted if there is any route in the routing incoming packet is accepted if there is any route in the routing
table for the source address. table for the source address.
uRPF is not used on interfaces that are likely to have routing While BCP84 [RFC3704] and a study on uRPF experiences [I-D.savola-
asymmetry, meaning multiple routes to the source of a packet. bcp84-urpf-experiences] detail how asymmetry, i.e. multiple routes to
Usually for ISPs, uRPF is placed at the customer edge of a network. 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.9.4. Rate Limiting 2.8.4. Rate Limiting
Rate limiting refers to allocating a specific amount of bandwidth or Rate limiting refers to allocating a specific amount of bandwidth or
packets per second to specific traffic types. This technique is packets per second to specific traffic types. This technique is
widely used to mitigate well-known protocol attacks such as the TCP- widely used to mitigate well-known protocol attacks such as the TCP-
SYN attack where a large number of resources get allocated for SYN attack where a large number of resources get allocated for
spoofed TCP traffic. Although this technique does not stop an spoofed TCP traffic. Although this technique does not stop an
attack, it can sometimes lessen the damage and impact on a specific attack, it can sometimes lessen the damage and impact on a specific
service. However, it can also make the impact of a DDoS attack much service. However, it can also make the impact of a DDoS attack much
worse if the rate limiting is impacting (i.e. discarding) more worse if the rate limiting is impacting (i.e. discarding) more
legitimate traffic. legitimate traffic.
2.8.5. Specific Control Plane Traffic Enhancements
Some ISPs are starting to use capabilities which 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 3. Security Considerations
This entire document deals with current security practices in large This entire document deals with current security practices in large
ISP environments. It lists specific practices used in today's ISP environments. It lists specific practices used in today's
environments and as such does not in itself pose any security risk. environments and as such does not in itself pose any security risk.
4. References 4. References
4.1. Normative References 4.1. Normative References
skipping to change at page 36, line 31 skipping to change at page 34, line 31
July 2003. July 2003.
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
Security Mechanism (GTSM)", RFC 3682, February 2004. Security Mechanism (GTSM)", RFC 3682, February 2004.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
4.2. Informational References 4.2. Informational References
[I-D.ietf-v6ops-icmpv6-filtering-bcp] [I-D.ietf-v6ops-icmpv6-filtering-recs]
Davies, E. and J. Mohacsi, "Best Current Practice for Davies, E. and J. Mohacsi, "Recommendations for Filtering
Filtering ICMPv6 Messages in Firewalls", ICMPv6 Messages in Firewalls",
draft-ietf-v6ops-icmpv6-filtering-bcp-01 (work in draft-ietf-v6ops-icmpv6-filtering-recs-02 (work in
progress), March 2006. progress), July 2006.
[I-D.lewis-infrastructure-security] [I-D.lewis-infrastructure-security]
Lewis, D., "Service Provider Infrastructure Security", Lewis, D., "Service Provider Infrastructure Security",
draft-lewis-infrastructure-security-00 (work in progress), draft-lewis-infrastructure-security-00 (work in progress),
June 2006. June 2006.
[I-D.savola-bcp84-urpf-experiences] [I-D.savola-bcp84-urpf-experiences]
Savola, P., "Experiences from Using Unicast RPF", Savola, P., "Experiences from Using Unicast RPF",
draft-savola-bcp84-urpf-experiences-01 (work in progress), draft-savola-bcp84-urpf-experiences-01 (work in progress),
June 2006. June 2006.
[I-D.savola-rtgwg-backbone-attacks] [I-D.savola-rtgwg-backbone-attacks]
Savola, P., "Backbone Infrastructure Attacks and Savola, P., "Backbone Infrastructure Attacks and
Protections", draft-savola-rtgwg-backbone-attacks-01 (work Protections", draft-savola-rtgwg-backbone-attacks-02 (work
in progress), June 2006. in progress), July 2006.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The editor gratefully acknowledges the contributions of: George The editor gratefully acknowledges the contributions of: George
Jones, who has been instrumental in providing guidance and direction Jones, who has been instrumental in providing guidance and direction
for this document and the insighful comments from Ross Callon, Ron for this document and the insighful comments from Ross Callon, Ron
Bonica, Gaurab Upadhaya, Warren Kumari and the numerous ISP operators Bonica, Gaurab Upadhaya, Warren Kumari, Pekka Savola, Fernando Gont,
who supplied the information which is depicted in this document. Chris Morrow, Donald Smith and the numerous ISP operators who
supplied the information which is depicted in this document.
Appendix B. Protocol Specific Attacks Appendix B. Protocol Specific Attacks
This section will list many of the traditional protocol based attacks This section will list many of the traditional protocol based attacks
which have been observed over the years to cause malformed packets which have been observed over the years to cause malformed packets
and/or exploit protocol deficiencies. Note that they all exploit and/or exploit protocol deficiencies. Note that they all exploit
vulnerabilities in the actual protocol itself and often, additional vulnerabilities in the actual protocol itself and often, additional
authentication and auditing mechanisms are now used to detect and authentication and auditing mechanisms are now used to detect and
mitigate the impact of these attacks. The list is not exhaustive but mitigate the impact of these attacks. The list is not exhaustive but
is a fraction of the representation of what types of attacks are is a fraction of the representation of what types of attacks are
possible for varying protocols. possible for varying protocols.
B.1. Layer 2 Attacks B.1. Layer 2 Attacks
o ARP Flooding o ARP Flooding
B.2. IPv4 Attacks B.2. IPv4 Protocol Based Attacks
o IP Stream Option
o IP Address Spoofing
o IP Source Route Option o IP Addresses, either source or destination, can be spoofed which
in turn can circumvent established filtering rules.
o IP Short header o IP Source Route Option can allows attackers to establish stealth
TCP connections
o IP Malformed Packet o IP Record Route Option can discloses information about the
topology of the network.
o IP Bad Option o IP header that is too long or too short can cause DoS attacks to
devices.
o IP Address Session Limit o IP Timestamp Option can leak information which can be used to
discern network behavior.
o Fragments - too many 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 Fragments - large offset o IP ToS field (or the Differentiated Services (DSCP) field) can be
used to reroute or reclassify traffic based on specified
precedence.
o Fragments - same offset 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 Fragments - reassembly with different offsets (TearDrop Attac) o IP TTL field can be used to bypass certain network based intrusion
detection systems and to map network behavior.
o Fragments - reassembly off by one IP header (Nestea Attack) B.2.1. Higher Layer Protocol Attacks
o Fragment - flooding only initial fragment (Rose Attack) The following lists additional attacks but does not explicitly
numerate them in detail. It is for informational purposes only.
o IGMP oversized packet o IGMP oversized packet
o ICMP Source Quench o ICMP Source Quench
o ICMP Mask Request o ICMP Mask Request
o ICMP Large Packet (> 1472) o ICMP Large Packet (> 1472)
o ICMP Oversized packet (>65536) o ICMP Oversized packet (>65536)
o ICMP Flood o ICMP Flood
 End of changes. 124 change blocks. 
506 lines changed or deleted 404 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/