< draft-ietf-opsec-current-practices-00.txt   draft-ietf-opsec-current-practices-01.txt >
OPSEC M. Kaeo OPSEC M. Kaeo
Internet-Draft Double Shot Security, Inc. Internet-Draft Double Shot Security, Inc.
Expires: August 14, 2005 February 10, 2005 Expires: January 18, 2006 July 17, 2005
Operational Security Current Practices Operational Security Current Practices
draft-ietf-opsec-current-practices-00 draft-ietf-opsec-current-practices-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 August 14, 2005. This Internet-Draft will expire on January 18, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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 Threat Model . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Threat Model . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Operational Security Impact from Threats . . . . . . . . . 3 1.2 Operational Security Impact from Threats . . . . . . . . . 3
1.3 Document Layout . . . . . . . . . . . . . . . . . . . . . 5 1.3 Document Layout . . . . . . . . . . . . . . . . . . . . . 6
1.4 Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 1.4 Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
2. Protected Operational Functions . . . . . . . . . . . . . . . 7 2. Protected Operational Functions . . . . . . . . . . . . . . . 8
2.1 Device Physical Access . . . . . . . . . . . . . . . . . . 7 2.1 Device Physical Access . . . . . . . . . . . . . . . . . . 8
2.2 Device In-Band Management . . . . . . . . . . . . . . . . 8 2.2 Device In-Band Management . . . . . . . . . . . . . . . . 10
2.3 Device Out-of-Band Management . . . . . . . . . . . . . . 12 2.3 Device Out-of-Band Management . . . . . . . . . . . . . . 14
2.4 Data Path . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4 Data Path . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Routing Control Plane . . . . . . . . . . . . . . . . . . 18 2.5 Routing Control Plane . . . . . . . . . . . . . . . . . . 20
2.6 Software Upgrades and Configuration Integrity / 2.6 Software Upgrades and Configuration Integrity /
Validation . . . . . . . . . . . . . . . . . . . . . . . . 20 Validation . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7 Logging Considerations . . . . . . . . . . . . . . . . . . 23 2.7 Logging Considerations . . . . . . . . . . . . . . . . . . 27
2.8 Filtering Considerations . . . . . . . . . . . . . . . . . 26 2.8 Denial of Service Tracking / Tracing . . . . . . . . . . . 30
2.9 Denial of Service Tracking / Tracing . . . . . . . . . . . 26 3. Security Considerations . . . . . . . . . . . . . . . . . . . 32
3. Security Considerations . . . . . . . . . . . . . . . . . . . 28 4. Normative References . . . . . . . . . . . . . . . . . . . . . 32
4. Normative References . . . . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 28 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 B. Protocol Specific Attacks . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . 36
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 33 skipping to change at page 3, line 33
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. for layer 2 and layer 3 network infrastructure devices.
1.2 Operational Security Impact from Threats 1.2 Operational Security Impact from Threats
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 breach security and cause harm [RFC2828]. Every operational network
is subject to a multitude of threat actions, or attacks, i.e. an is subject to a multitude of threat actions, or attacks, i.e. an
assault on system security that derives from an intelligent act that assault on system security that derives from an intelligent act that
is a 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]. These attacks can be sourced security policy of a system [RFC2828]. These attacks can be sourced
in a variety of ways: 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
conceal the identity of the traffic sender. A passive attack conceal the identity of the traffic sender. A passive attack
involves only reading information off the network. This is involves only reading information off the network. This is
possible if the attacker has control of a host in the possible if the attacker has control of a host in the
communications path between two victim machines or has compromised communications path between two victim machines or has compromised
the routing infrastructure to specifically arrange that traffic the routing infrastructure to specifically arrange that traffic
pass through a compromised machine. In general, the goal of a pass through a compromised machine. In general, the goal of a
passive attack is to obtain information that the sender and passive attack is to obtain information that the sender and
receiver would prefer to remain private. [RFC3552] receiver would prefer to remain private. [RFC3552]
skipping to change at page 4, line 6 skipping to change at page 4, line 6
conceal the identity of the traffic sender. A passive attack conceal the identity of the traffic sender. A passive attack
involves only reading information off the network. This is involves only reading information off the network. This is
possible if the attacker has control of a host in the possible if the attacker has control of a host in the
communications path between two victim machines or has compromised communications path between two victim machines or has compromised
the routing infrastructure to specifically arrange that traffic the routing infrastructure to specifically arrange that traffic
pass through a compromised machine. In general, the goal of a pass through a compromised machine. In general, the goal of a
passive attack is to obtain information that the sender and passive attack is to obtain information that the sender and
receiver would prefer to remain private. [RFC3552] receiver would prefer to remain private. [RFC3552]
On-path vs off-path attacks On-path vs off-path attacks
In order for a datagram to be transmitted from one host to In order for a datagram to be transmitted from one host to
another, it generally must traverse some set of intermediate links another, it generally must traverse some set of intermediate links
and gateways. Such gateways are naturally able to read, modify, and routers. Such routers are naturally able to read, modify, or
or remove any datagram transmitted along that path. This makes it remove any datagram transmitted along that path. This makes it
much easier to mount a wide variety of attacks if you are on-path. much easier to mount a wide variety of attacks if you are on-path.
Off-path hosts can transmit arbitrary datagrams that appear to Off-path hosts can transmit arbitrary datagrams that appear to
come from any hosts but cannot necessarily receive datagrams come from any hosts but cannot necessarily receive datagrams
intended for other hosts. Thus, if an attack depends on being intended for other hosts. Thus, if an attack depends on being
able to receive data, off-path hosts must first subvert the able to receive data, off-path hosts must first subvert the
topology in order to place themselves on-path. This is by no topology in order to place themselves on-path. This is by no
means impossible but is not necessarily trivial. [RFC3552] means impossible but is not necessarily trivial. [RFC3552]
Insider or outsider attacks Insider or outsider attacks
An "insider attack" is one which is initiated from inside a given An "insider attack" is one which is initiated from inside a given
security perimeter, by an entity that is authorized to access security perimeter, by an entity that is authorized to access
system resources but uses them in a way not approved by those who system resources but uses them in a way not approved by those who
granted the authorization. An "outside attack" is initiated from granted the authorization. An "outside attack" is initiated from
outside the perimeter, by an unauthorized or illegitimate user of outside the perimeter, by an unauthorized or illegitimate user of
the system. the system.
Deliberate attacks vs unintentional events Deliberate attacks vs unintentional events
A deliberate attack is one where a miscreant intentionally A deliberate attack is one where a miscreant intentionally
performs an assault on system security. However, there are also performs an assault on system security. However, there are also
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 be as easily detected and mitigated as with any
other attack source. Any of the specific attacks discussed further other attack source. Any of the specific attacks discussed further
in this document will elaborate on attacks which are sourced by an in this document will elaborate on attacks 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 be given to the feasibility of passive vs active and on-path vs off-
off-path attacks to show the motivation behind deploying certain path attacks to show the motivation behind deploying certain security
security features. features.
The threat consequences are the security violations which results The threat consequences are the security violations which results
from a threat action, i.e. an attack. These are typically from a threat action, i.e. an attack. These are typically classified
classified as follows: as follows:
(Unauthorized) Disclosure (Unauthorized) Disclosure
A circumstance or event whereby an entity gains access to data for A circumstance or event whereby an entity gains access to data for
which the entity is not authorized. which the entity is not authorized.
Deception Deception
A circumstance or event that may result in an authorized entity A circumstance or event that may result in an authorized entity
receiving false data and believing it to be true. receiving false data and believing it to be true.
Disruption Disruption
A circumstance or event that interrupts or prevents the correct A circumstance or event that interrupts or prevents the correct
operation of system services and functions. A broad variety of operation of system services and functions. A broad variety of
attacks, collectively called denial of service attacks, threaten attacks, collectively called denial of service attacks, threaten
the availability of systems and bandwidth to legitimate users. the availability of systems and bandwidth to legitimate users.
Many such attacks are designed to consume machine resources, Many such attacks are designed to consume machine resources,
making it difficult or impossible to serve legitimate users. making it difficult or impossible to serve legitimate users.
Other attacks cause the target machine to crash, completely Other attacks cause the target machine to crash, completely
denying service to users. denying service to users.
Usurpation Usurpation
skipping to change at page 7, line 50 skipping to change at page 8, line 50
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 card key 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 card-key systems keep track of who
accessed which location and at what time. accessed which location and at what time.
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. Individual users are authentication to get
basic access. For privileged (i.e. enable) access, a second basic access. For privileged (i.e. enable) access, a second
authentication step needs to be completed. Typically all console authentication step needs to be completed. Typically all console
access is provided via an out-of-band (OOB) management infrastructure access is provided via an out-of-band (OOB) management infrastructure
which is discussed in the section on OOB management. 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
skipping to change at page 8, line 14 skipping to change at page 9, line 14
which is discussed in the section on OOB management. 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. Console access
is usually granted via at least two privilege levels: is usually granted via at least two privilege levels:
authorization for performing a basic set of commands vs authorization for performing a basic set of commands vs
authorization for performing all commands. 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
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
run independently of each other and reside in different physical
locations.
Social engineering plays a big role in many physical access
compromises. Most ISPs have set up training classes and awareness
programs to educate company personnel to deny physical access to
people who are not properly authenticated or authorized to have
physical access to critical infrastructure devices.
2.2 Device 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
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. In many environments, device management for
layer 2 and layer 3 infrastructure devices is deployed as part of an layer 2 and layer 3 infrastructure devices is deployed as part of an
out-of-band management infrastructure although there are some out-of-band management infrastructure although there are some
instances where it is deployed in-band as well. Presently, the instances where it is deployed in-band as well. Presently, the
mechanisms used for in-band management are via virtual terminal mechanisms used for in-band management are via virtual terminal
access (i.e. Telnet or SSH), SNMP, or HTTP. In all large ISP access (i.e. Telnet or SSH), SNMP, or HTTP. In all large ISPs that
environments, HTTP management is never used and is explicitly were interviewed, HTTP management is never used and is explicitly
disabled. Note that file transfer protocols (TFTP, FTP, SCP) will disabled. Note that file transfer protocols (TFTP, FTP, SCP) will
be covered in the 'Software Upgrades and Configuration be covered in the 'Software Upgrades and Configuration Integrity/
Integrity/Validation' section. Validation' section.
2.2.1 Threats / Attacks 2.2.1 Threats / Attacks
For in-band device management, passive attacks are possible if For in-band device management, passive attacks are possible if
someone has the capability to intercept data between the management someone has the capability to intercept data between the management
device and the managed device. The threat is possible if a single device 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 11, line 5 skipping to change at page 12, line 22
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. The community strings are
carefully chosen to be difficult to crack and there are procedures in carefully chosen to be difficult to crack and there are procedures in
place to change these community strings between 30-90 days. If place to change these community strings between 30-90 days. If
systems support two SNMP strings, a second new string is set and then systems support two SNMP community strings, the old string is
migrate over from the 1st to the 2nd. Most large ISPs have multiple replaced by first configuring a second newer community string and
SNMP systems accessing their routers so it takes more then one then migrating over from the currently used string to the newer one.
maintenance period to get all the strings fixed in all the right Most large ISPs have multiple SNMP systems accessing their routers so
systems. SNMP RW is not used and disabled by configuration. 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. The AAA server All in-band device management access is audited and any violations
keeps track of the authenticated entity as well as all the commands trigger alarms which initiate automated email, pager and/or telephone
that were carried out on a specific device. Additionally, the device notifications. AAA servers keeps track of the authenticated entity
itself logs any access control violations (i.e. if an SSH request as well as all the commands that were carried out on a specific
comes in from an IP address which is not explicitly permitted, that device. Additionally, the device itself logs any access control
event is logged so that the offending IP address can be tracked down violations (i.e. if an SSH request comes in from an IP address which
and investigations made as to why it was trying to access a is not explicitly permitted, that event is logged so that the
particular infrastructure device) offending IP address can be tracked down and investigations made as
to why it was trying to access a particular infrastructure device)
2.2.3 Security Services 2.2.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 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. 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 noone 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 - Filtering to allow only specific IP addresses to
have access to the infrastructure devices. This does not defend
against spoofed traffic which may be used to source a DoS attack.
Often OOB management is used to lower that risk. 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 2.2.4 Additional Considerations
IPsec is considered too difficult to implement and the common Password selection for any in-band device management protocol used is
protocol to provide for confidential in-band management access is critical to ensure that the passwords are hard to guess or break
SSH. There are exceptions for using SSH due to equipment limitations using a brute-force attack.
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 IPsec is considered too difficult to deploy and the common protocol
re-keying of SSH would be required whenever the route processor card to provide for confidential in-band management access is SSH. There
needs to be swapped. Some providers feel that this operational are exceptions for using SSH due to equipment limitations since SSH
impact exceeds the security necessary and instead use Telnet from may not be supported on legacy equipment. Also, in the case where
trusted inside hosts (called 'jumphosts') to manage those devices. the SSH key is stored on a route processor card, a re-keying of SSH
An individual would first SSH to the jumphost and then Telnet from would be required whenever the route processor card needs to be
the jumphost to the actual infrastructure device. All authentication swapped. Some providers feel that this operational impact exceeds
and authorization is still carried out using AAA servers. In the security necessary and instead use Telnet from trusted inside
instances where Telnet access is used, the logs on the AAA servers hosts (called 'jumphosts') to manage those devices. An individual
would first SSH to the jumphost and then Telnet from the jumphost to
the actual infrastructure device. 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 are more verbose and more attention is paid to them to detect any
abnormal behavior. Note that Telent is NEVER allowed to an abnormal behavior. The jumphosts themselves are carefully controlled
infrastructure device except from specific jumphosts whose IP machines and usually have limited access. Note that Telent is NEVER
addresses are filtered at the infrastructure device. 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 With thousands of devices to manage, some ISPs have created automated
mechanisms to authenticate to devices. Kerberos is used to automate mechanisms to authenticate to devices. Kerberos is used to automate
the authentication process. An individual would first log in to a the authentication process. An individual would first log in to a
Kerberized UNIX server using SSH and generate a Kerberos 'ticket'. Kerberized UNIX server using SSH and generate a Kerberos 'ticket'.
This 'ticket' is generally set to have a lifespan of 10 hours and is This 'ticket' is generally set to have a lifespan of 10 hours and is
used to automatically authenticate the individual to the used to automatically authenticate the individual to the
infrastructure devices. infrastructure devices.
In instances where SNMP is used, some legacy devices only support In instances where SNMP is used, some legacy devices only support
skipping to change at page 15, line 24 skipping to change at page 17, line 12
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 OOB device management access is audited. The AAA server keeps All OOB device management access is audited. The AAA server keeps
track of the authenticated entity as well as all the commands that track of the authenticated entity as well as all the commands that
were carried out on a specific device. Additionally, the device were carried out on a specific device. Additionally, the device
itself logs any access control violations (i.e. if an SSH request itself logs any access control violations (i.e. if an SSH request
comes in from an IP address which is not explicitly permitted, that 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 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 and investigations made as to why it was trying to access a
particular infrastructure device) particular infrastructure device)
2.3.3 Security Services 2.3.3 Security Services
The security services offered for device OOB management are nearly
identical to those of device in-band management. Due to the critical
nature of controlling and limiting device access, many ISPs feel that
physically separating the management traffic from the normal customer
data traffic will provide an added level of risk mitigation and limit
the potential attack vectors. For OOB management, the security
services offered through the use of the practices described in the
previous section are:
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. 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 noone 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 - Filtering to allow only specific IP addresses to
have access to the infrastructure devices. This does not defend
against spoofed traffic which may be used to source a DoS attack.
The risk is lowered by using a separate network for management o DoS Mitigation - Using packet filters to allow only specific IP
purposes. addresses to have access to the infrastructure devices. This
limits but does not prevent spoofed DoS attacks directed at an
infrastructure device. However, the risk is lowered by using a
separate physical network for management purposes.
2.3.4 Additional Considerations 2.3.4 Additional Considerations
IPsec is considered too difficult to implement and the common Password selection for any OOB device management protocol used is
protocol to provide for confidential OOB management access is SSH. critical to ensure that the passwords are hard to guess or break
There are exceptions for using SSH due to equipment limitations using a brute-force attack.
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 IPsec is considered too difficult to deploy and the common protocol
re-keying of SSH would be required whenever the route processor card to provide for confidential OOB management access is SSH. There are
needs to be swapped. Some providers feel that this operational exceptions for using SSH due to equipment limitations since SSH may
impact exceeds the security necessary and instead use Telnet from not be supported on legacy equipment. Also, in the case where the
trusted inside hosts (called 'jumphosts') to manage those device. An SSH key is stored on a route processor card, a re-keying of SSH would
individual would first SSH to the jumphost and then Telnet from the be required whenever the route processor card needs to be swapped.
jumphost to the terminal server before logging in to the device Some providers feel that this operational impact exceeds the security
console. All authentication and authorization is still carried out necessary and instead use Telnet from trusted inside hosts (called
using AAA servers. In instances where Telnet access is used, the 'jumphosts') to manage those device. An individual would first SSH
logs on the AAA servers are more verbose and more attention is paid to the jumphost and then Telnet from the jumphost to the terminal
to them to detect any abnormal behavior. Note that Telent is NEVER server before logging in to the device console. All authentication
allowed to a console server or infrastructure device except from and authorization is still carried out using AAA servers.
specific jumphosts whose IP addresses are filtered at the console
server and/or infrastructure device. 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 at the console server and/or
infrastructure device to ensure that Telnet is only allowed from
specific IP addresses.
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.4 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 attack forward customer traffic. However, due to the large amount of
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.4.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. traffic. The deliberately sourced attack traffic can consist of
packets with spoofed source and/or destination addresses or any other
malformed packet which mangle any portion of a header field to cause
protocol-related security issues (such as resetting connections,
causing unwelcome ICPM redirects, creating unwelcome IP options or
packet fragmentations).
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 the reliability of existing deployed hardware. the process is and what the capabilities and performance limitations
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 guidelines. Null routes and black-hole filtering are follow BCP38 [BCP38] guidelines. Null routes and black-hole
used to deter any detected malicious traffic streams. Most ISPs filtering are used to deter any detected malicious traffic streams.
consider layer 4 filtering useful but it is only implemented if there Most ISPs consider layer 4 filtering useful but it is only
is no performance limitations on the devices. Netflow is used for implemented if there is no performance limitations on the devices.
tracking traffic flows but there is some concern whether sampling is Netflow is used for tracking traffic flows but there is some concern
good enough to detect malicious behavior. 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 17, line 25 skipping to change at page 19, line 45
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
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 and uRPF are deployed at network edges it can ensure that any
spoofed traffic comes from at least a legitimate IP address and spoofed traffic comes from at least a legitimate IP address and
can be tracked. 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.
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.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. Rate limiting
can be improved by (need info) may be improved by developing flow-based rate-limiting capabilities
Performance issues cause some ISPs to not implement BCP38 guidelines with filtering hooks. This would improve the performance as well as
for ingress filtering. One such example is at edge boxes where you the granularity over current capabilities.
have up to 1000 T1's connecting into a router with an OC-12 uplink.
Some ISP's experience a large performance impact with filtering which Lack of consistency regarding the ability to filter, especially with
is unacceptable for passing customer traffic through. Where respect to performance issues cause some ISPs to not implement BCP38
performance is not an issue, the ISPs make a tradeoff between guidelines for ingress filtering. One such example is at edge boxes
management versus risk. 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
with filtering which is unacceptable for passing customer traffic
through. Where performance is not an issue, the ISPs make a tradeoff
between management versus risk.
2.5 Routing Control Plane 2.5 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.5.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
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. This may lead to an
attacks, the attacks are generally limited to message insertion or attacker impersonating a legitimate routing peer and exchanging
modification which can divert traffic to illegitimate destinations routing information. Unintentional active attacks are more common
and cause traffic to never reach its intended destination. due to configuration errors, which cause legitimate routing peers to
feed invalid routing information to other neighboring peers.
For off-path active attacks, the attacks are generally limited to
message insertion or modification which can divert traffic to
illegitimate destinations and cause traffic to never reach its
intended destination.
2.5.2 Confidentiality Violations 2.5.2 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. [is this an issue?] of the routing update traffic. This is becoming more of a concern
because many ISPs are classifying addressing schemes and network
topologies as private and proprietary information. It is also a
concern because the routing protocol packets contain information that
may show ways in which routing sessions could be spoofed or hijacked.
This in turn could lead into a man-in-the-middle attack where the
miscreants can insert themselves into the traffic path or divert the
traffic path and violate the confidentiality of user data.
2.5.3 Offline Cryptographic Attacks 2.5.3 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
skipping to change at page 19, line 25 skipping to change at page 22, line 20
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.5.6 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. communicates on behalf of one of the peers. This can lead to
diversion of the user traffic to either an unauthorized receiving
party or cause legitimate traffic to never reach its intended
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 do MD-5 authentication transit has not been altered. Some ISPs only deploy MD-5
at customer's request. Many ISPs also deploy sanity checks to ensure authentication at customer's request. Additional sanity checks to
with some certainty that the received routing update has been ensure with reasonable certainty that the received routing update was
authorized to be sent by the sending party. In the case of BGP originated by a valid routing peer include route filters and the BTSH
routing, this is accomplished through the use of routing registries feature [BTSH]. Note that validating whether a legitimate peer has
and prefix limits. Additionally, route filters and the ttl-hack the authority to send the contents of the routing update is a
(politically correct name? BTSH?) ensure with reasonable probability difficult problem that needs yet to be resolved.
that the routing update came from a valid peer.
[editor's note: should more info be included on secure BGP policy? In the case of BGP routing, a variety of policies are deployed to
Rejecting advertisements for your own backbone, advertisements to limit the propagation of invalid routing information. These include:
bogons, route damping, rejecting selected attributes and communities, incoming and outgoing prefix filters for BGP customers, incoming and
etc. (Will need more specific input from provider deployment)] outgoing prefix filters for peers and upstream neighbors, incoming
AS-PATH filter for BGP customers, outgoing AS-PATH filter towards
peers and upstream neighbors, route dampening and rejecting selected
attributes and communities. Consistency between these policies
varies greatly although there is a trend to start depending on AS-
PATH filters because they are much more manageable than the large
numbers of prefix filters that would need to be maintained. Many
ISPs also do not propagate interface IP addresses to further reduce
attack vectors on routers and connected customers.
2.5.8 Security Services 2.5.8 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 filtering and prefix limits are used to o Access Control - Route filters, AS-PATH filters and prefix limits
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 - TBD o Auditing / Logging - TBD
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 combination of techniques including: MD5 authentication, the BTSH
ttl-hack, filtering advertisements to bogons and filtering feature, filtering routing advertisements to bogons and filtering
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 MD-5 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
(ttl-hack and route filters). such as BTSH and route filters.
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
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.
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 22, line 13 skipping to change at page 25, line 34
added command is to allow a miscreant access to that device by added command is to allow a miscreant access to that device by
entering a filter allowing a specific host access and configuring a entering a filter allowing a specific host access and configuring a
local username/password database entry for authentication to that local username/password database entry for authentication to that
device. device.
2.6.6 Man-In-The-Middle 2.6.6 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 and used to upload/download the system image or configuration file. He/
acts 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,
he could potentially exploit a known vulnerability and gain access to
the system. From a captured configuration file, he could obtain
confidential network topology information or even more damaging
information if any of the passwords in the configuration file were
not encrypted.
2.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 TFTP and SCP access is
username/password authenticated and in most environments scripts are username/password authenticated and in most environments scripts are
skipping to change at page 22, line 45 skipping to change at page 26, line 25
The software images perform CRC-checks but many ISPs expressed The software images perform CRC-checks but 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. The system binaries use the MD5
algorithm to validate integrity. algorithm to validate integrity.
In all configuration files, the passwords are stored in an obfuscated In all configuration files, the passwords are stored in an obfuscated
format. This includes passwords for user authentication, MD5 shared format. This includes passwords for user authentication, MD5 shared
secrets, AAA server shared secrets, NTP shared secrets, etc. For secrets, AAA server shared secrets, NTP shared secrets, etc. For
older software which may not support this functionality, older software which may not support this functionality,
configuration files are stored with passwords in readable format. configuration files are stored with passwords in readable format. [is
[is this true? are configuration files then protected? if passwords this true? are configuration files then protected? if passwords in
in readable format, is the thought that an OOB management network readable format, is the thought that an OOB management network with
with SCP will be enough protection? ] SCP will be enough protection? ]
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.6.8 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 - TBD o Data Origin Authentication - TBD
o Access Control - Filters are used to limit access to
uploading/downloading configuration files and system images to o Access Control - Filters are used to limit access to uploading/
specific IP addresses and protocols. downloading configuration files and system images to specific IP
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.
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.6.9 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, ISPs have expressed an interest in having this checking of software images and configuration files, ISPs have
functionality. IPsec is considered too cumbersome and operationally expressed an interest in having this functionality. IPsec is
difficult to use for data integrity and confidentiality. considered too cumbersome and operationally difficult to use for data
integrity and confidentiality.
2.7 Logging Considerations 2.7 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.7.1 Threats / Attacks
skipping to change at page 24, line 34 skipping to change at page 28, line 25
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.7.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. [is reply handled by syslog protocol?]
2.7.1.4 Message Insertion/Deletion/Modification 2.7.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.7.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. database which is used to archive the logged data. Any unauthorized
access to logging information could lead to knowledge of private and
proprietary network topology information which could be used to
compromise portions of the network. An additional concern is having
access to logging information which could be deleted or modified so
as to cover any traces of a security breach.
2.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 Typically the data logged will contain the source and destination IP
addresses and layer 4 port numbers as well as a timestamp. The addresses and layer 4 port numbers as well as a timestamp. The
syslog protocol is used to transfer the logged data between the syslog protocol is used to transfer the logged data between the
infrastructure device to the syslog server. Many ISPs use the OOB infrastructure device to the syslog server. Many ISPs use the OOB
management network to transfer syslog data since there is virtually management network to transfer syslog data since there is virtually
no security performed between the syslog server and the device. All no security performed between the syslog server and the device. All
ISPs have multiple syslog servers - some ISPs choose to use separate ISPs have multiple syslog servers - some ISPs choose to use separate
syslog servers for varying infrastructure devices (i.e. one syslog syslog servers for varying infrastructure devices (i.e. one syslog
server for backbone routers, one syslog server for customer edge server for backbone routers, one syslog server for customer edge
routers, etc.) 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
skipping to change at page 25, line 44 skipping to change at page 29, line 40
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.7.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 - TBD
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.
o Data Integrity - Not implemented o Data Integrity - Not implemented
o Data Confidentiality - Not implemented o Data Confidentiality - Not implemented
o Auditing / Logging - TBD o Auditing / Logging - TBD
o DoS Mitigation - TBD o DoS Mitigation - TBD
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. better authenticated and integrity protected solutions. Mechanisms
to prevent unauthorized personnel from tampering with logs is
constrained to auditing who has access to the logging servers and
files.
ISPs expressed requirements for more than just UDP syslog. They ISPs expressed requirements for more than just UDP syslog. They
would also like more granular and flexible facilities and priorities, would also like more granular and flexible facilities and priorities,
i.e. specific logs to specific servers. i.e. specific logs to specific servers.
2.8 Filtering Considerations
[Editor note: Already covered but could be a sum up. This section to
be added if enough proponents for it ]
2.8.1 Threats / Attacks
To be added.
2.8.2 Security Mechanisms
To be added.
2.8.3 Security Services
To be added.
o TBD
o TBD
2.8.4 Additional Considerations
TBD. 2.8 Denial of Service Tracking / Tracing
2.9 Denial of Service Tracking / Tracing Denial of Service attacks are an ever increasing problem and require
vast amounts of resources to combat effectively. Some large ISPs do
not concern themselves with attack streams that are less than 1G in
bandwidth - this is on the larger pipes where 1G is essentially less
than 5% of offered load. This is largely due to the large amounts of
DDoS traffic which continually requires investigation and mitigation.
At last count the number of hosts making up large distributed DoS
BOTnets exceeded 1 million hosts.
[special section for describing security techniques to avoid well New techniques are continually evolving to automate the process of
known attacks? Includes sink hole routing, black-hole filtering, detecting DoS sources and mitigating any adverse effects as quickly
uRPF, rate limiting] as possible. At this time, ISPs are using a variety of mitigation
techniques including: sink hole routing, black-hole triggered
routing, uRPF and rate limiting. Each of these techniques will be
detailed below.
2.9.1 Threats / Attacks 2.8.1 Sink Hole Routing
To be added. To be added.
2.9.2 Security Mechanisms 2.8.2 Black-Hole Triggered Routing
To be added. To be added.
2.9.3 Security Services 2.8.3 Unicast Reverse Path Forwarding
To be added. Unicast Reverse Path Forwarding (uRPF) is a mechanism for validating
whether an incoming packet has a legitimate source address or not.
It has two modes: strict mode and loose mode. In strict mode, uRPF
checks whether the incoming packet has a source address that matches
a prefix in the routing table, and whether the interface expects to
receive a packet with this source address prefix. If the incoming
packet fails the unicast RPF check, the packet is not accepted on the
incoming interface. Loose mode uRPF is not as specific and the
incoming packet is accepted if there is any route in the routing
table for the source address.
o TBD uRPF is not used on interfaces that are likely to have routing
o TBD asymmetry, meaning multiple routes to the source of a packet.
Usually for ISPs, uRPF is placed at the customer edge of a network.
2.9.4 Additional Considerations 2.8.4 Rate Limiting
TBD Details of rate limiting
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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828,
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, July Text on Security Considerations", BCP 72, RFC 3552,
2003. July 2003.
Author's Address Author's Address
Merike Kaeo Merike Kaeo
Double Shot Security, Inc. Double Shot Security, Inc.
520 Washington Blvd. #363 520 Washington Blvd. #363
Marina Del Rey, CA 90292 Marina Del Rey, CA 90292
U.S.A. U.S.A.
Phone: +1 310 866 0165 Phone: +1 310 866 0165
Email: merike@doubleshotsecurity.com Email: merike@doubleshotsecurity.com
Appendix A. Acknowledgments Appendix A. Acknowledgments
The editor gratefully acknowledges the contributions of: The editor gratefully acknowledges the contributions of: George
Jones, who has been instrumental in providing guidance and direction
for this document and the insighful comments from Ross Callon and the
numerous ISP operators who supplied the information which is depicted
in this document.
o George Jones, who has been instrumental in providing guidance and Appendix B. Protocol Specific Attacks
direction for this document.
o To be named
o To be named
This listing is intended to acknowledge contributions, not to imply This section will enumerate many of the traditional protocol based
that the individual or organizations approve the content of this attacks which have been observed over the years to cause malformed
document. packets and/or exploit protocol deficiencies.
o ARP Flooding
o IP Stream Option
o IP Address Spoofing
o IP Source Route Option
o IP Short header
o IP Malformed Packet
o Ip Bad Option
o Ip Address Session Limit
o Fragmenmts - too many
o Fragments - large offset
o Fragments - same offset
o Fragments - reassembly with different offsets (TearDrop Attac)
o Fragments - reassembly off by one IP header (Nestea Attack)
o Fragment - flooding only initial fragment (Rose Attack)
o IGMP oversized packet
o ICMP Source Quench
o ICMP Mask Request
o ICMP Large Packet (> 1472)
o ICMP Oversized packet (>65536)
o ICMP Flood
o ICMP Broadcast w/ Spoofed Source (Smurf Attack)
o ICMP Error Packet Flood
o ICMP Spoofed Unreachable
o TCP Packet without Flag
o TCP Oversized Packet
o TCP FIN bit with no ACK bit
o TCP Packet with URG/OOB flag (Nuke Attack)
o SYN Fragments
o SYN Flood
o SYN with IP Spoofing (Land Attack)
o SYN and FIN bits set
o TCP port scan attack
o UDP spoofed broadcast echo (Fraggle Attack)
o UDP attack on diag ports (Pepsi Attack)
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
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 113 change blocks. 
205 lines changed or deleted 413 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/