< draft-ietf-opsec-current-practices-03.txt   draft-ietf-opsec-current-practices-04.txt >
OPSEC M. Kaeo OPSEC M. Kaeo
Internet-Draft Double Shot Security, Inc. Internet-Draft Double Shot Security, Inc.
Expires: November 25, 2006 May 24, 2006 Expires: December 27, 2006 June 25, 2006
Operational Security Current Practices Operational Security Current Practices
draft-ietf-opsec-current-practices-03 draft-ietf-opsec-current-practices-04
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 November 25, 2006. This Internet-Draft will expire on December 27, 2006.
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
skipping to change at page 2, line 13 skipping to change at page 2, line 13
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 . . . . . . . . . 5
1.5. Document Layout . . . . . . . . . . . . . . . . . . . . . 7 1.5. Document Layout . . . . . . . . . . . . . . . . . . . . . 7
1.6. Definitions . . . . . . . . . . . . . . . . . . . . . . . 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 In-Band Management . . . . . . . . . . . . . . . . 11
2.3. Device Out-of-Band Management . . . . . . . . . . . . . . 15 2.3. Device Out-of-Band Management . . . . . . . . . . . . . . 15
2.4. Data Path . . . . . . . . . . . . . . . . . . . . . . . . 19 2.4. Data Path . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5. Routing Control Plane . . . . . . . . . . . . . . . . . . 21 2.5. Routing Control Plane . . . . . . . . . . . . . . . . . . 22
2.6. Software Upgrades and Configuration Integrity / 2.6. Software Upgrades and Configuration Integrity /
Validation . . . . . . . . . . . . . . . . . . . . . . . . 25 Validation . . . . . . . . . . . . . . . . . . . . . . . . 25
2.7. Logging Considerations . . . . . . . . . . . . . . . . . . 28 2.7. Logging Considerations . . . . . . . . . . . . . . . . . . 29
2.8. Filtering Considerations . . . . . . . . . . . . . . . . . 31 2.8. Filtering Considerations . . . . . . . . . . . . . . . . . 32
2.9. Denial of Service Tracking / Tracing . . . . . . . . . . . 32 2.9. Denial of Service Tracking / Tracing . . . . . . . . . . . 33
3. Security Considerations . . . . . . . . . . . . . . . . . . . 34 3. Security Considerations . . . . . . . . . . . . . . . . . . . 35
4. Normative References . . . . . . . . . . . . . . . . . . . . . 34 4. Normative References . . . . . . . . . . . . . . . . . . . . . 35
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 35 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 36
Appendix B. Protocol Specific Attacks . . . . . . . . . . . . . . 36 Appendix B. Protocol Specific Attacks . . . . . . . . . . . . . . 37
B.1. Layer 2 Attacks . . . . . . . . . . . . . . . . . . . . . 36 B.1. Layer 2 Attacks . . . . . . . . . . . . . . . . . . . . . 37
B.2. IPv4 Attacks . . . . . . . . . . . . . . . . . . . . . . . 36 B.2. IPv4 Attacks . . . . . . . . . . . . . . . . . . . . . . . 37
B.3. IPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . . 37 B.3. IPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . . . . 40
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 27 skipping to change at page 3, line 27
infrastructures. infrastructures.
1.1. Scope 1.1. Scope
The scope for this survey is restricted to security practices that The scope for this survey is restricted to security practices that
mitigate exposure to risks with the potential to adversely impact mitigate exposure to risks with the potential to adversely impact
network availability and reliability. Securing the actual data network availability and reliability. Securing the actual data
traffic is outside the scope of the conducted survey. This document traffic is outside the scope of the conducted survey. This document
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 apply to primarily focused on IPv4, many of the same practices can (and
IPv6 networks. Both IPv4 and IPv6 network infrastructures are taken should) apply to IPv6 networks. Both IPv4 and IPv6 network
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 is
subject to a multitude of threat actions, or attacks, i.e. an assault subject to a multitude of threat actions, or attacks, i.e. an assault
on system security that derives from an intelligent act that is a on system security that derives from an intelligent act that is a
deliberate attempt to evade security services and violate the 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. either the sender or recipient of a communication stream while
inserting, modifying or dropping certain traffic. This type of
attack also covers phishing and session hijacks.
Protocol Vulnerability Exploitation: An attack which takes advantage Protocol Vulnerability Exploitation: An attack which takes advantage
of known protocol deficiencies to cause inappropriate behavior. of known protocol deficiencies 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-
directed to a network segment that is normally not part of the data directed to a network segment that is normally not part of the data
path. path.
Message Modification: This is a subset of a message insertion attack Message Modification: This is a subset of a message insertion attack
where a previous message has been captured and modified before being where a previous message has been captured and modified before being
retransmitted. The message can be captured by using a man-in-the- retransmitted. The message can be captured by using a man-in-the-
middle attack or message diversion. middle attack or message diversion.
Note that sometimes Denial of service attacks are listed as separate Note that sometimes Denial of service attacks are listed as separate
categories. A denial of service is a consequence of an attack and categories. A denial of service is a consequence of an attack and
can be the result of too much traffic (i.e. flooding), or exploting can be the result of too much traffic (i.e. flooding), or exploiting
protocol expoitation or inserting/deleting/diverting/midifying protocol exploitation or inserting/deleting/diverting/modifying
messages. messages.
1.3. Attack Sources 1.3. Attack Sources
These attacks can be sourced in a variety of ways: These attacks can be sourced in a variety of ways:
Active vs passive attacks Active vs passive attacks
An active attack involves writing data to the network. It is An active attack involves writing data to the network. It is
common practice in active attacks to disguise one's address and common practice in active attacks to disguise one's address and
skipping to change at page 8, line 4 skipping to change at page 8, line 8
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. Each section ends with an additional
considerations section which explains why specific protocols may or considerations section which explains why specific protocols may or
may not be used and also gives some information regarding may not be used and also gives some information regarding
capabilities which are not possible today due to bugs or lack of ease capabilities which are not possible today due to bugs or lack of ease
of use. of use.
1.6. Definitions 1.6. Definitions
RFC 2119 Keywords RFC 2119 Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in [RFC2119]. 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 The use of the RFC 2119 keywords is an attempt, by the editor, to
assign the correct requirement levels ("MUST", "SHOULD", assign the correct requirement levels ("MUST", "SHOULD",
"MAY"...). It must be noted that different organizations, "MAY"...). It must be noted that different organizations,
operational environments, policies and legal environments will operational environments, policies and legal environments will
generate different requirement levels. 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
of the layer 2 or layer 3 network infrastructure device. Although it and access of the layer 2 or layer 3 network infrastructure device.
is important to have contingency plans for natural disasters such as Physical security is a large field of study/practice in and of
earthquakes and floods which can cause damage to networking devices, itself, arguably the largest. oldest and most well understood area of
this is out-of-scope for this document. Here we concern ourselves security. Although it is important to have contingency plans for
with protecting access to the physical location and how a device can natural disasters such as earthquakes and floods which can cause
be further protected from unauthorized access if the physical damage to networking devices, this is out-of-scope for this document.
location has been compromised, i.e protecting the console access. Here we concern ourselves with protecting access to the physical
location and how a device can be further protected from unauthorized
access if the physical location has been compromised, i.e protecting
the console access. This is aimed largely at stopping an intruder
with physical access from gaining operational control of the
device(s). Note that nothing will stop an attacker with physical
access from effecting a denial of service attack, which can be easily
accomplished by powering off the device or just unplugging some
cables.
2.1.1. Threats / Attacks 2.1.1. Threats / Attacks
If any intruder gets physical access to a layer 2 or layer 3 device, If any intruder gets physical access to a layer 2 or layer 3 device,
the entire network infrastructure can be under the control of the the entire network infrastructure can be under the control of the
intruder. At a minimum, the intruder can take the compromised device intruder. At a minimum, the intruder can take the compromised device
out-of-service, causing network disruption, the extent of which out-of-service, causing network disruption, the extent of which
depends on the network topology. A worse scenario is where the depends on the network topology. A worse scenario is where the
intruder can use this device to crack the console password and have intruder can use this device to crack the console password and have
complete control of the device, perhaps without anyone detecting such complete control of the device, perhaps without anyone detecting such
skipping to change at page 10, line 45 skipping to change at page 11, line 7
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
described in this document mostly from a console access perspective. described in this document mostly from a console access perspective.
Most ISPs provide console access via an OOB management infrastructure Most ISPs provide console access via an OOB management infrastructure
which is discussed in the OOB management section of this document. which is discussed in the OOB management section of this document.
The physical and logical authentication and logging systems should be The physical and logical authentication and logging systems should be
run independently of each other and reside in different physical run independently of each other and reside in different physical
locations. locations. These systems need to be secured to ensure that they
themselves will not be compromised which could give the intruder
valuable authentication and logging information.
Social engineering plays a big role in many physical access 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 In-Band Management
In-band management is generally considered to be device access where In-band management is generally considered to be device access where
skipping to change at page 12, line 37 skipping to change at page 12, line 47
2.2.2. Security Practices 2.2.2. Security Practices
All in-band management access to layer 2 and layer 3 devices is All in-band management access to layer 2 and layer 3 devices is
authenticated. The user authentication and authorization is authenticated. The user authentication and authorization is
typically controlled by a AAA server (i.e. RADIUS and/or TACACS+). typically controlled by a AAA server (i.e. RADIUS and/or TACACS+).
Credentials used to determine the identity of the user vary from Credentials used to determine the identity of the user vary from
static username/password to one-time username/password scheme such as static username/password to one-time username/password scheme such as
Secure-ID. Static username/passwords are expired after a specified Secure-ID. Static username/passwords are expired after a specified
period of time, usually 30 days. Every authenticated entity via AAA period of time, usually 30 days. Every authenticated entity via AAA
is an individual user for greater granularity of control. In some is an individual user for greater granularity of control. In some
deployments, The AAA servers used for in-band management deployments, the AAA servers used for in-band management
authentication/authorization/accounting are on separate out-of-band authentication/authorization/accounting are on separate out-of-band
networks to provide a demarcation for any other authentication networks to provide a demarcation for any other authentication
functions. 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.
Each individual user in the AAA database is configured with specific Each individual user in the AAA database is configured with specific
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. privileged commands. Securing the AAA server is imperative and
access to the AAA server itself is strictly controlled. When an
individual leaves the company, his/her AAA account is immediately
deleted and the TACACS/RADIUS shared secret is reset for all devices.
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 in-band management, it is for read queries only
and restricted to specific hosts. The community strings are and restricted to specific hosts. If possible, the view is also
carefully chosen to be difficult to crack and there are procedures in restricted to only send the information that the management station
place to change these community strings between 30-90 days. If needs rather than expose the entire configuration file with the read-
systems support two SNMP community strings, the old string is only SNMP community. The community strings are carefully chosen to
replaced by first configuring a second newer community string and be difficult to crack and there are procedures in place to change
then migrating over from the currently used string to the newer one. these community strings between 30-90 days. If systems support two
Most large ISPs have multiple SNMP systems accessing their routers so SNMP community strings, the old string is replaced by first
it takes more then one maintenance period to get all the strings configuring a second newer community string and then migrating over
fixed in all the right systems. SNMP RW is not used and disabled by from the currently used string to the newer one. Most large ISPs
configuration. 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 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 in-band device management access is audited and any violations
trigger alarms which initiate automated email, pager and/or telephone trigger 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
skipping to change at page 14, line 20 skipping to change at page 14, line 34
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. Using SSH for device access ensures that noone can spoof
the traffic during the SSH session. the traffic during the SSH session.
o Access Control - In-band management traffic is filtered to allow o Access Control - In-band management traffic is filtered to allow
only specific IP addresses to have access to the infrastructure only 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. Often OOB management is used to lower that infrastructure device. Often OOB management is used to lower that
skipping to change at page 14, line 47 skipping to change at page 15, line 14
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 in-band management access is SSH. There to provide for confidential in-band management access is SSH. There
are exceptions for using SSH due to equipment limitations since SSH are exceptions for using SSH due to equipment limitations since SSH
may not be supported on legacy equipment. Also, in the case where 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 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 would be required whenever the route processor card needs to be
swapped. Some providers feel that this operational impact exceeds swapped. Some providers feel that this operational impact exceeds
the security necessary and instead use Telnet from trusted inside the security necessary and instead use Telnet from trusted inside
hosts (called 'jumphosts') to manage those devices. An individual hosts (called 'jumphosts' or 'bastion hosts') to manage those
would first SSH to the jumphost and then Telnet from the jumphost to devices. An individual would first SSH to the jumphost and then
the actual infrastructure device. All authentication and Telnet from the jumphost to the actual infrastructure device, fully
authorization is still carried out using AAA servers. 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 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 Telent 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 to ensure that Telnet is only allowed i.e. packet filters are used to ensure that Telnet is only allowed
from specific IP addresses. from specific IP addresses.
With thousands of devices to manage, some ISPs have created automated With thousands of devices to manage, some ISPs have created automated
skipping to change at page 15, line 30 skipping to change at page 15, line 48
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.3. Device Out-of-Band Management 2.3. Device Out-of-Band Management
Out-of-band management is generally considered to be device access Out-of-band management is generally considered to be device access
where the control traffic takes a separate path as the data which where the control traffic takes a separate path as the data which
traverses the network. Console access is always architected via an traverses the network. Console access is always architected via an
OOB network. SNMP management is also usually carried out via that OOB network. SNMP management is also usually carried out via that
same OOB network infrastructure. 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 2.3.1. Threats / Attacks
For OOB device management, passive attacks are possible if someone For OOB device management, passive attacks are possible if someone
has the capability to intercept data between the management device has the capability to intercept data between the management device
and the managed device. The threat is possible if a single and 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.
skipping to change at page 16, line 43 skipping to change at page 17, line 18
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 OOB management system to the networking traffic that is sent from an OOB management system to the networking
infrastructure device and traffic that is sent from the network infrastructure device and traffic that is sent from the network
infrastructure device to the OOB management system. infrastructure device to the OOB management system.
2.3.2. Security Practices 2.3.2. Security Practices
OOB is done via a terminal server at each location. SSH access is 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 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 are initiated. Dial-in access is deployed as a backup if the network
is not available. 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 All OOB management access to layer 2 and layer 3 devices is
authenticated. The user authentication and authorization is authenticated. The user authentication and authorization is
typically controlled by a AAA server (i.e. RADIUS and/or TACACS+). typically controlled by a AAA server (i.e. RADIUS and/or TACACS+).
Credentials used to determine the identity of the user vary from Credentials used to determine the identity of the user vary from
static username/password to one-time username/password scheme such as static username/password to one-time username/password scheme such as
Secure-ID. Static username/passwords are expired after a specified Secure-ID. Static username/passwords are expired after a specified
period of time, usually 30 days. Every authenticated entity via AAA period of time, usually 30 days. Every authenticated entity via AAA
is an individual user for greater granularity of control. Note that is an individual user for greater granularity of control. Note that
often the AAA server used for OOB management authentication is a often the AAA server used for OOB management authentication is a
skipping to change at page 19, line 17 skipping to change at page 19, line 42
2.3.4. Additional Considerations 2.3.4. Additional Considerations
Password selection for any OOB device management protocol used is Password selection for any OOB 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 OOB 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. Also, in the case where the not be supported on legacy equipment. In some cases changing the
SSH key is stored on a route processor card, a re-keying of SSH would hostname of a device requires an SSH rekey event since the key is
be required whenever the route processor card needs to be swapped. based on some combination of host name, MAC address and time. Also,
Some providers feel that this operational impact exceeds the security in the case where the SSH key is stored on a route processor card, a
necessary and instead use Telnet from trusted inside hosts (called re-keying of SSH would be required whenever the route processor card
'jumphosts') to manage those device. An individual would first SSH needs to be swapped. Some providers feel that some of these
to the jumphost and then Telnet from the jumphost to the terminal operational impacts exceed the security necessary and instead use
server before logging in to the device console. All authentication Telnet from trusted inside hosts (called 'jumphosts') to manage those
and authorization is still carried out using AAA servers. device. An individual would first SSH to the jumphost and then
Telnet from the jumphost to the terminal server before logging in to
the device console. 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 Telent 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.
skipping to change at page 20, line 26 skipping to change at page 20, line 50
2.4.2. Security Practices 2.4.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 [BCP38] guidelines. Null routes and black-hole follow BCP38 [BCP38] and BCP84 [BCP84] guidelines. Null routes and
filtering are used to deter any detected malicious traffic streams. black-hole triggered routing [BHTR] are used to deter any detected
Most ISPs consider layer 4 filtering useful but it is only malicious traffic streams. Most ISPs consider layer 4 filtering
implemented if there is no performance limitations on the devices. useful but it is only implemented if performance limitations allow
Netflow is used for tracking traffic flows but there is some concern for it. Layer 4 filtering is typically only when no other option
whether sampling is good enough to detect malicious behavior. exists since it does pose a large administrative overhead and ISPs
are very much opposed to acting as the Internet firewall. Netflow is
used for tracking traffic flows but there is some concern whether
sampling is good 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.4.3. Security Services
o User Authentication - Not applicable o User Authentication - Not applicable
skipping to change at page 21, line 25 skipping to change at page 22, line 5
2.4.4. Additional Considerations 2.4.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. This is due to the problems it can cause when troubleshooting
networking issues. Port security becomes unmanageable at a large networking issues. Port security becomes unmanageable at a large
scale where 1000s of switches are deployed. 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. Rate limiting provide any operational benefit over the complexity. Some ISPs feel
may be improved by developing flow-based rate-limiting capabilities that rate limiting can also make an attacker's job easier by
with filtering hooks. This would improve the performance as well as requiring the attacker to send less traffic to starve legitimate
the granularity over current capabilities. traffic that is part of a rate limiting scheme. Rate limiting may be
improved by developing flow-based rate-limiting capabilities with
filtering hooks. This would improve the performance as well as the
granularity over current capabilities.
Lack of consistency regarding the ability to filter, especially with 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 guidelines for ingress filtering. One such example is at edge boxes
where you have up to 1000 T1's connecting into a router with an OC-12 where you have up to 1000 T1's connecting into a router with an OC-12
uplink. Some deployed devices experience a large performance impact uplink. Some deployed devices experience a large performance impact
with filtering which is unacceptable for passing customer traffic with filtering which is unacceptable for passing customer traffic
through. Where performance is not an issue, the ISPs make a tradeoff through. Where performance is not an issue, the ISPs make a tradeoff
between management versus risk. between management versus risk.
skipping to change at page 23, line 24 skipping to change at page 24, line 10
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.5.7. 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 MD-5 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 BTSH originated by a valid routing peer include route filters and the
feature [BTSH]. Note that validating whether a legitimate peer has Generalized TTL Security Mechanism (GTSM) feature [GTSM] (sometimes
the authority to send the contents of the routing update is a also referred to as the TTL-Hack). Note that validating whether a
difficult problem that needs yet to be resolved. legitimate peer has the authority to send the contents of the routing
update is a difficult problem that needs yet to be resolved.
In the case of BGP routing, a variety of policies are deployed to In the case of BGP routing, a variety of policies are deployed to
limit the propagation of invalid routing information. These include: limit the propagation of invalid routing information. These include:
incoming and outgoing prefix filters for BGP customers, incoming and incoming and outgoing prefix filters for BGP customers, incoming and
outgoing prefix filters for peers and upstream neighbors, incoming outgoing prefix filters for peers and upstream neighbors, incoming
AS-PATH filter for BGP customers, outgoing AS-PATH filter towards AS-PATH filter for BGP customers, outgoing AS-PATH filter towards
peers and upstream neighbors, route dampening and rejecting selected peers and upstream neighbors, route dampening and rejecting selected
attributes and communities. Consistency between these policies attributes and communities. Consistency between these policies
varies greatly although there is a trend to start depending on AS- varies greatly although there is a trend to start depending on AS-
PATH filters because they are much more manageable than the large PATH filters because they are much more manageable than the large
skipping to change at page 24, line 17 skipping to change at page 25, line 4
o Access Control - Route filters, AS-PATH filters and prefix limits o Access Control - Route filters, AS-PATH filters and prefix limits
are used to control access to specific parts of the network. are used to control access to specific parts of the network.
o Data Integrity - By using MD5 authentication a peer can be o Data Integrity - By using MD5 authentication a peer can be
reasonably certain that the data has not been modified in transit reasonably certain that the data has not been modified in transit
but there is no mechanism to prove the validity of the routing but there is no mechanism to prove the validity of the routing
information itself. information itself.
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 BTSH 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.5.9. 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 MD-5 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 BTSH and route filters. such as GTSM and route filters.
Route filters are used to limit what routes are believed from a valid Route filters are used to limit what routes are believed from a valid
peer. Packet filters are used to limit which systems can appear as a peer. Packet filters are used to limit which systems can appear as a
valid peer. Due to the operational constraints of maintaining large valid peer. Due to the operational constraints of maintaining large
prefix filter lists, many ISPs are starting to depend on BGP AS-PATh prefix filter lists, many ISPs are starting to depend on BGP AS-PATH
filters to/from their peers and upstream neighbors. 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.
skipping to change at page 26, line 44 skipping to change at page 27, line 35
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.6.7. 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 TFTP and SCP access is and FTP is generally never used. All SCP access is username/password
username/password authenticated and in most environments scripts are authenticated but since this requires an interactive shell, most ISPs
used for maintaining a large number of routers. To ensure the will use shared key authentication to avoid the interactive shell.
integrity of the configurations, every hour the configuration files While TFTP access does not have any security measures, it is still
are polled and compared to the previously polled version to find widely used especially in OOB management scenarios. Some ISPs
discrepancies. In at least one environment these tools are implement IP-based restriction on the TFTP server while some custom
Kerberized to take advantage of automated authentication (not written TFTP servers will support MAC-based authentication. The MAC-
confidentiality). based authentication is more common when using TFTP to bootstrap
routers remotely using TFTP.
In most environments scripts are used for maintaining the images and
configurations of a large number of routers. To ensure the integrity
of the configurations, every hour the configuration files are polled
and compared to the previously polled version to find discrepancies.
In at least one environment these tools are Kerberized to take
advantage of automated authentication (not confidentiality).
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 but many ISPs expressed The software images perform CRC-checks and the system binaries use
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. The system binaries use the MD5 MD5 algorithm for enhanced security.
algorithm to validate integrity.
In all configuration files, most passwords are stored in an In all configuration files, most passwords are stored in an
obfuscated format. This includes passwords for user authentication, obfuscated format. This includes passwords for user authentication,
MD5 shared secrets, AAA server shared secrets, NTP shared secrets, MD5 shared secrets, AAA server shared secrets, NTP shared secrets,
etc. For older software which may not support this functionality, etc. For older software which may not support this functionality,
configuration files may contain some passwords in readable format. configuration files may contain some passwords in readable format.
Most ISPs mitigate any risk of password compromise by either storing Most ISPs mitigate any risk of password compromise by either storing
these configuration files without the password lines or by requiring these configuration files without the password lines or by requiring
authenticated and authorized access to the configuration files which authenticated and authorized access to the configuration files which
are stored on protected OOB management devices. are stored on protected OOB management devices.
skipping to change at page 29, line 42 skipping to change at page 30, line 42
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.7.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).
Typically the data logged will contain the source and destination IP This is to assure that the logging servers are not overwhelmed with
addresses and layer 4 port numbers as well as a timestamp. The data which would render most logs unusable. Typically the data
syslog protocol is used to transfer the logged data between the logged will contain the source and destination IP addresses and layer
infrastructure device to the syslog server. Many ISPs use the OOB 4 port numbers as well as a timestamp. The syslog protocol is used
management network to transfer syslog data since there is virtually to transfer the logged data between the infrastructure device to the
no security performed between the syslog server and the device. All syslog server. Many ISPs use the OOB management network to transfer
ISPs have multiple syslog servers - some ISPs choose to use separate syslog data since there is virtually no security performed between
syslog servers for varying infrastructure devices (i.e. one syslog the syslog server and the device. All ISPs have multiple syslog
server for backbone routers, one syslog server for customer edge servers - some ISPs choose to use separate syslog servers for varying
routers, etc.) infrastructure devices (i.e. one syslog server for backbone routers,
one syslog server for customer edge routers, etc.)
The timestamp is derived from NTP which is generally configured as a 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. Each router is configured with one stratum1
peer both locally and remotely. peer both locally and remotely.
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).
skipping to change at page 30, line 47 skipping to change at page 31, line 47
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.
o Data Integrity - Not implemented o Data Integrity - Not implemented
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 - TBD o DoS Mitigation - Logs are useful in providing traceback
information to potentially trace the attack to as close to the
source as possible.
2.7.4. Additional Considerations 2.7.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. They ISPs expressed requirements for more than just UDP syslog.
would also like more granular and flexible facilities and priorities, Additionally, they would like more granular and flexible facilities
i.e. specific logs to specific servers. and priorities, i.e. specific logs to specific servers. Also, a
common format for reporting standard events so that they don't have
to modify parsers after each upgrade of vendor device or software.
2.8. Filtering Considerations 2.8. 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.8.1. Data Plane Filtering
skipping to change at page 31, line 39 skipping to change at page 32, line 41
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. attacks.
2.8.2. Management Plane Filtering 2.8.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 currently filtered per SCP and Syslog. This type of traffic is often filtered per interface
interface and is based on any combination of protocol, source and and is based on any combination of protocol, source and destination
destination IP address and source and destination port number. Note IP address and source and destination port number. Some devices
that logging the filtering rules can today place a burden on many support functionality to apply management filters to the device
systems and more granularity is often required to more specifically rather than to the specific interfaces (e.g. receive ACL or loopback
log the required exceptions. interface ACL) which is gaining wider acceptance. Note that logging
the filtering rules can today place a burden on many systems and more
granularity is often required to more specifically log the required
exceptions.
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. to a network device.
2.8.3. Routing Control Plane Filtering 2.8.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. Any announcement received
that is longer than a /48 for IPv6 routing and a /24 for IPv4 routing that is longer than a /48 for IPv6 routing and a /24 for IPv4 routing
is discarded on EBGP. is filtered out of eBGP. Note that this is for non-customer traffic.
Most ISPs will accept any agreed upon prefix length from its
customer(s).
2.9. Denial of Service Tracking / Tracing 2.9. 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 and rate limiting. Each of these techniques will be
detailed below. detailed below.
2.9.1. Sink Hole Routing 2.9.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 subnet or specific IP address 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.9.2. Black-Hole Triggered Routing
Black-hole triggered routing is a technique where the BGP routing Black-hole triggered routing is a technique where the BGP routing
protocol is used to propagate static routes which in turn redirects protocol is used to propagate routes which in turn redirects attack
attack traffic to the null interface where it is effectively dropped. traffic to the null interface where it is effectively dropped. This
This technique is often used in large routing infrastructures since technique is often used in large routing infrastructures since BGP
BGP can propagate the information in a fast effective manner as can propagate the information in a fast effective manner as opposed
opposed to using any packet-based filtering techniques on hundreds or to using any packet-based filtering techniques on hundreds or
thousands of routers. thousands of routers.
2.9.3. Unicast Reverse Path Forwarding 2.9.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
skipping to change at page 33, line 23 skipping to change at page 34, line 29
asymmetry, meaning multiple routes to the source of a packet. asymmetry, meaning multiple routes to the source of a packet.
Usually for ISPs, uRPF is placed at the customer edge of a network. Usually for ISPs, uRPF is placed at the customer edge of a network.
2.9.4. Rate Limiting 2.9.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 lessen the damage and impact on a specific service. 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
worse if the rate limiting is impacting (i.e. discarding) more
legitimate traffic.
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. As a synopsis, a table is shown below which ISP environments. As a synopsis, a table is shown below which
summarizes the operational functions which are to be protected and summarizes the operational functions which are to be protected and
the security services which currently deployed security practices the security services which currently deployed security practices
offer: [ Table to be added ] offer: [ Table to be added ]
4. Normative References 4. Normative References
skipping to change at page 35, line 9 skipping to change at page 36, line 9
May 2000. May 2000.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
July 2003. July 2003.
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 and the for this document and the insighful comments from Ross Callon, Ron
numerous ISP operators who supplied the information which is depicted Bonica, Gaurab Upadhaya, Warren Kumari and the numerous ISP operators
in this document. who supplied the information which is depicted in this document.
Appendix B. Protocol Specific Attacks Appendix B. Protocol Specific Attacks
This section will enumerate many of the traditional protocol based This section will enumerate many of the traditional protocol based
attacks which have been observed over the years to cause malformed attacks which have been observed over the years to cause malformed
packets and/or exploit protocol deficiencies. packets and/or exploit protocol deficiencies.
B.1. Layer 2 Attacks B.1. Layer 2 Attacks
o ARP Flooding o ARP Flooding
skipping to change at page 38, line 10 skipping to change at page 39, line 10
Today, IPv6 enabled hosts are starting to be used to create IPv6 Today, IPv6 enabled hosts are starting to be used to create IPv6
tunnels which can effectively hide botnet and other malicious traffic tunnels which can effectively hide botnet and other malicious traffic
if firewalls and network flow collection tools are not capable of if firewalls and network flow collection tools are not capable of
detecting this traffic. detecting this traffic.
Author's Address Author's Address
Merike Kaeo Merike Kaeo
Double Shot Security, Inc. Double Shot Security, Inc.
3518 Fremont Avenue North #363 3518 Fremont Avenue North #363
Seattley, WA 98103 Seattle, WA 98103
U.S.A. U.S.A.
Phone: +1 310 866 0165 Phone: +1 310 866 0165
Email: merike@doubleshotsecurity.com Email: merike@doubleshotsecurity.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
 End of changes. 44 change blocks. 
126 lines changed or deleted 189 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/