draft-ietf-opsec-current-practices-06.txt   draft-ietf-opsec-current-practices-07.txt 
OPSEC M. Kaeo OPSEC M. Kaeo
Internet-Draft Double Shot Security, Inc. Internet-Draft Double Shot Security, Inc.
Expires: January 21, 2007 July 20, 2006 Intended status: Informational August 29, 2006
Expires: March 2, 2007
Operational Security Current Practices Operational Security Current Practices
draft-ietf-opsec-current-practices-06 draft-ietf-opsec-current-practices-07
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 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 21, 2007. This Internet-Draft will expire on March 2, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document is a survey of the current practices used in today's This document is a survey of the current practices used in today's
large ISP operational networks to secure layer 2 and layer 3 large ISP operational networks to secure layer 2 and layer 3
infrastructure devices. The information listed here is the result of infrastructure devices. The information listed here is the result of
skipping to change at page 2, line 20 skipping to change at page 2, line 29
1.3. Attack Sources . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Attack Sources . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Operational Security Impact from Threats . . . . . . . . . 6 1.4. Operational Security Impact from Threats . . . . . . . . . 6
1.5. Document Layout . . . . . . . . . . . . . . . . . . . . . 7 1.5. Document Layout . . . . . . . . . . . . . . . . . . . . . 7
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 Management - In-Band and Out-of-Band (OOB) . . . . 11 2.2. Device Management - In-Band and Out-of-Band (OOB) . . . . 11
2.3. Data Path . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3. Data Path . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4. Routing Control Plane . . . . . . . . . . . . . . . . . . 19 2.4. Routing Control Plane . . . . . . . . . . . . . . . . . . 19
2.5. Software Upgrades and Configuration Integrity / 2.5. Software Upgrades and Configuration Integrity /
Validation . . . . . . . . . . . . . . . . . . . . . . . . 23 Validation . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6. Logging Considerations . . . . . . . . . . . . . . . . . . 26 2.6. Logging Considerations . . . . . . . . . . . . . . . . . . 27
2.7. Filtering Considerations . . . . . . . . . . . . . . . . . 30 2.7. Filtering Considerations . . . . . . . . . . . . . . . . . 30
2.8. Denial of Service Tracking / Tracing . . . . . . . . . . . 31 2.8. Denial of Service Tracking / Tracing . . . . . . . . . . . 31
3. Security Considerations . . . . . . . . . . . . . . . . . . . 33 3. Security Considerations . . . . . . . . . . . . . . . . . . . 34
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
4.1. Normative References . . . . . . . . . . . . . . . . . . . 34 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
4.2. Informational References . . . . . . . . . . . . . . . . . 34 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 35 6.1. Normative References . . . . . . . . . . . . . . . . . . . 37
Appendix B. Protocol Specific Attacks . . . . . . . . . . . . . . 36 6.2. Informational References . . . . . . . . . . . . . . . . . 37
B.1. Layer 2 Attacks . . . . . . . . . . . . . . . . . . . . . 36 Appendix A. Protocol Specific Attacks . . . . . . . . . . . . . . 39
B.2. IPv4 Protocol Based Attacks . . . . . . . . . . . . . . . 36 A.1. Layer 2 Attacks . . . . . . . . . . . . . . . . . . . . . 39
B.3. IPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . . 38 A.2. IPv4 Protocol Based Attacks . . . . . . . . . . . . . . . 39
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39 A.3. IPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 40 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . . . 43
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 39 skipping to change at page 3, line 39
infrastructures are taken into account in this survey. infrastructures are taken into account in this survey.
1.2. Threat Model 1.2. Threat Model
A threat is a potential for a security violation, which exists when A threat is a potential for a security violation, which exists when
there is a circumstance, capability, action, or event that could there is a circumstance, capability, action, or event that could
breach security and cause harm [RFC2828]. Every operational network 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]. All of the threats in any security policy of a system [RFC2828]. Many of the threats to a
network infrastructure is an instantiation or combination of the network infrastructure occur from an instantiation (or combination)
following: of the following:
Reconnaissance: An attack whereby information is gathered to Reconnaissance: An attack whereby information is gathered to
ascertain the network topology or specific device information which ascertain the network topology or specific device information which
can be further used to exploit known vulnerabilities can be further used to exploit known vulnerabilities
Man-In-The-Middle: An attack where a malicious user impersonates Man-In-The-Middle: An attack where a malicious user impersonates
either the sender or recipient of a communication stream while either the sender or recipient of a communication stream while
inserting, modifying or dropping certain traffic. This type of inserting, modifying or dropping certain traffic. This type of
attack also covers phishing and session hijacks. attack also covers phishing and session hijacks.
skipping to change at page 4, line 43 skipping to change at page 4, line 43
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. There are also situations
passive attack is to obtain information that the sender and where mirrored traffic (often used for debugging, performance
receiver would prefer to remain private. [RFC3552] monitoring or accounting purposes) is diverted to a compromised
machine which would not necessarily subvert any existing topology
and could be harder to detect. In general, the goal of a passive
attack is to obtain information that the sender and receiver would
prefer to remain private. [RFC3552]
On-path vs off-path attacks 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 routers. Such routers are naturally able to read, modify, or and routers. Such routers are naturally able to read, modify, 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] A more
subtle attack is one where the traffic mirroring capability of a
device is hijacked and the traffic is diverted to a compromised
host since the network topology may not need to be subverted.
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.
skipping to change at page 17, line 45 skipping to change at page 17, line 45
follow BCP38 [RFC2827] and BCP84 [RFC3704] guidelines for ingress follow BCP38 [RFC2827] and BCP84 [RFC3704] guidelines for ingress
filtering. BCP38 recommends filtering ingress packets with obviously filtering. BCP38 recommends filtering ingress packets with obviously
spoofed and/or 'reserved' source addresses to limit the effects of spoofed and/or 'reserved' source addresses to limit the effects of
denial of service attacks while BCP84 extends the recommendation for denial of service attacks while BCP84 extends the recommendation for
multi-homed environments. Filters are also used to help alleviate multi-homed environments. Filters are also used to help alleviate
issues between service providers. Without any filtering, an inter- issues between service providers. Without any filtering, an inter-
exchange peer could steal transit just by using static routes and exchange peer could steal transit just by using static routes and
essentially redirect data traffic. Therefore, some ISPs have essentially redirect data traffic. Therefore, some ISPs have
implemented ingress/egress filters which block unexpected source and implemented ingress/egress filters which block unexpected source and
destination addresses not defined in the above-mentioned documents. destination addresses not defined in the above-mentioned documents.
Null routes and black-hole triggered routing are used to deter any Null routes and black-hole triggered routing [RFC3882] are used to
detected malicious traffic streams. These two techniques are deter any detected malicious traffic streams. These two techniques
described in more detail in section 2.8 below. are described in more detail in section 2.8 below.
Most ISPs consider layer 4 filtering useful but it is only Most ISPs consider layer 4 filtering useful but it is only
implemented if performance limitations allow for it. Layer 4 implemented if performance limitations allow for it. Layer 4
filtering is typically only when no other option exists since it does filtering is typically only when no other option exists since it does
pose a large administrative overhead and ISPs are very much opposed pose a large administrative overhead and ISPs are very much opposed
to acting as the Internet firewall. Netflow is used for tracking to acting as the Internet firewall. Netflow is used for tracking
traffic flows but there is some concern whether sampling is good traffic flows but there is some concern whether sampling is good
enough to detect malicious behavior. enough to detect malicious behavior.
Unicast RPF is not consistently implemented. Some ISPs are in Unicast RPF is not consistently implemented. Some ISPs are in
process of doing so while other ISPs think that the perceived benefit process of doing so while other ISPs think that the perceived benefit
of knowing that spoofed traffic comes from legitimate addresses are of knowing that spoofed traffic comes from legitimate addresses are
not worth the operational complexity. Some providers have a policy not worth the operational complexity. Some providers have a policy
of implementing uRPF at link speeds of DS3 and below. of implementing uRPF at link speeds of DS3 and below which was due to
the fact that all hardware in the network supported uRPF for DS3
speeds and below. At higher speed links the uRPF support was
inconsistent and it was easier for operational people to implement a
consistent solution.
2.3.3. Security Services 2.3.3. Security Services
o User Authentication - Not applicable o User Authentication - Not applicable
o User Authorization - Not applicable o User Authorization - Not applicable
o Data Origin Authentication - When IP address filtering per BCP38, o Data Origin Authentication - When IP address filtering per BCP38,
BCP84 and uRPF are deployed at network edges it can ensure that BCP84 and uRPF are deployed at network edges it can ensure that
any spoofed traffic comes from at least a legitimate IP address any spoofed traffic comes from at least a legitimate IP address
skipping to change at page 21, line 18 skipping to change at page 21, line 20
generally deployed as a system. MD5 authentication is used by some generally deployed as a system. MD5 authentication is used by some
ISPs to validate the sending peer and to ensure that the data in ISPs to validate the sending peer and to ensure that the data in
transit has not been altered. Some ISPs only deploy MD5 transit has not been altered. Some ISPs only deploy MD5
authentication at customer's request. Additional sanity checks to authentication at customer's request. Additional sanity checks to
ensure with reasonable certainty that the received routing update was ensure with reasonable certainty that the received routing update was
originated by a valid routing peer include route filters and the originated by a valid routing peer include route filters and the
Generalized TTL Security Mechanism (GTSM) feature [RFC3682] Generalized TTL Security Mechanism (GTSM) feature [RFC3682]
(sometimes also referred to as the TTL-Hack). The GTSM feature is (sometimes also referred to as the TTL-Hack). The GTSM feature is
used for protocols such as BGP and makes use of a packet's Time To used for protocols such as BGP and makes use of a packet's Time To
Live (TTL) field (IPv4) or Hop Limit (IPv6) to protect communicating Live (TTL) field (IPv4) or Hop Limit (IPv6) to protect communicating
peers. peers. If GTSM is used, it is typically only deployed in limited
scenarios between internal BGP peers due to lack of consistent
support between vendor products and operating system versions.
Packet filters are used to limit which systems can appear as a valid Packet filters are used to limit which systems can appear as a valid
peer while route filters are used to limit which routes are believed peer while route filters are used to limit which routes are believed
from a valid peer. In the case of BGP routing, a variety of policies from a valid peer. In the case of BGP routing, a variety of policies
are deployed to limit the propagation of invalid routing information. are deployed to limit the propagation of invalid routing information.
These include: incoming and outgoing prefix filters for BGP These include: incoming and outgoing prefix filters for BGP
customers, incoming and outgoing prefix filters for peers and customers, incoming and outgoing prefix filters for peers and
upstream neighbors, incoming AS-PATH filter for BGP customers, upstream neighbors, incoming AS-PATH filter for BGP customers,
outgoing AS-PATH filter towards peers and upstream neighbors, route outgoing AS-PATH filter towards peers and upstream neighbors, route
dampening and rejecting selected attributes and communities. dampening and rejecting selected attributes and communities.
Consistency between these policies varies greatly and there is a Consistency between these policies varies greatly and there is a
definite distinction whether the other end is an end-site vs an definite distinction whether the other end is an end-site vs an
internal peer vs another big ISP or customer. Mostly ISPs do prefix- internal peer vs another big ISP or customer. Mostly ISPs do prefix-
filter their end-site customers but due to the operational filter their end-site customers but due to the operational
constraints of maintaining large prefix filter lists, many ISPs are constraints of maintaining large prefix filter lists, many ISPs are
starting to depend on BGP AS-PATH filters to/from their peers and starting to depend on BGP AS-PATH filters to/from their peers and
upstream neighbors. upstream neighbors.
In cases where prefix lists are not used, operators often define a In cases where prefix lists are not used, operators often define a
maximum prefix limit per peer to prevent misconfiguration (e.g., maximum prefix limit per peer to prevent misconfiguration (e.g.,
unintentional de-aggregation) or overload attacks. When the limit is unintentional de-aggregation or neighbor routing policy mis-
exceeded, the session is either reset or further updates are denied. configuration) or overload attacks. ISPs need to coordinate between
Typically a lower warning threshold is also configured. each other what the expected prefix exchange is, and increase this
number by some sane amount. It is important for ISPs to pad the max-
prefix number enough to allow for valid swings in routing
announcements to prevent an unintentional shutting down of the BGP
session. Individual implementation amongst ISPs are unique, and
depending on equipment supplier(s) different implementation options
are available. Most equipment vendors offer implementation options
ranging from just logging excessive prefixes being received to
automatically shutting down the session. If the option of
reestablishing a session after some pre-configured idle timeout has
been reached is available, it should be understood that automatically
reestablishing the session may potentially introduce instability
continuously into the overall routing table if a policy mis-
configuration on the adjacent neighbor is causing the condition. If
a serious mis-configuration on a peering neighbor has occurred then
automatically shutting down the session and leaving it shut down
until being manually cleared is sometimes best and allows for
operator intervention to correct as needed.
Some large ISPs require that routes be registered in an Internet Some large ISPs require that routes be registered in an Internet
Routing Registry [IRR] which can then be part of the RADB - a public Routing Registry [IRR] which can then be part of the RADB - a public
registry of routing information for networks in the Internet that can registry of routing information for networks in the Internet that can
be used to generate filter lists. Some ISPs, especially in europe, be used to generate filter lists. Some ISPs, especially in europe,
require registered routes before agreeing to become an eBGP peer with require registered routes before agreeing to become an eBGP peer with
someone. someone.
Many ISPs also do not propagate interface IP addresses to further Many ISPs also do not propagate interface IP addresses to further
reduce attack vectors on routers and connected customers. reduce attack vectors on routers and connected customers.
skipping to change at page 25, line 15 skipping to change at page 25, line 37
any system software or configuration files, either TFTP, FTP or SCP any system software or configuration files, either TFTP, FTP or SCP
can be used. Where possible, SCP is used to secure the data transfer can be used. Where possible, SCP is used to secure the data transfer
and FTP is generally never used. All SCP access is username/password and FTP is generally never used. All SCP access is username/password
authenticated but since this requires an interactive shell, most ISPs authenticated but since this requires an interactive shell, most ISPs
will use shared key authentication to avoid the interactive shell. will use shared key authentication to avoid the interactive shell.
While TFTP access does not have any security measures, it is still While TFTP access does not have any security measures, it is still
widely used especially in OOB management scenarios. Some ISPs widely used especially in OOB management scenarios. Some ISPs
implement IP-based restriction on the TFTP server while some custom implement IP-based restriction on the TFTP server while some custom
written TFTP servers will support MAC-based authentication. The MAC- written TFTP servers will support MAC-based authentication. The MAC-
based authentication is more common when using TFTP to bootstrap based authentication is more common when using TFTP to bootstrap
routers remotely using TFTP. routers remotely.
In most environments scripts are used for maintaining the images and In most environments scripts are used for maintaining the images and
configurations of a large number of routers. To ensure the integrity configurations of a large number of routers. To ensure the integrity
of the configurations, every hour the configuration files are polled of the configurations, every hour the configuration files are polled
and compared to the previously polled version to find discrepancies. and compared to the previously polled version to find discrepancies.
In at least one environment these tools are Kerberized to take In at least one environment these tools are Kerberized to take
advantage of automated authentication (not confidentiality). advantage of automated authentication (not confidentiality).
'Rancid' is one popular publicly available tool for detecting 'Rancid' is one popular publicly available tool for detecting
configuration and system changes. configuration and system changes.
skipping to change at page 26, line 34 skipping to change at page 27, line 9
rancid are used to automatically detect configuration changes. rancid are used to automatically detect configuration changes.
o Data Confidentiality - If the SCP protocol is used then there is o Data Confidentiality - If the SCP protocol is used then there is
confidentiality of the downloaded/uploaded configuration files and confidentiality of the downloaded/uploaded configuration files and
system images. system images.
o Auditing / Logging - All access and activity relating to o Auditing / Logging - All access and activity relating to
downloading/uploading system images and configuration files are downloading/uploading system images and configuration files are
logged via AAA services and filter exception rules. logged via AAA services and filter exception rules.
o DoS Mitigation - TBD o DoS Mitigation - A combination of filtering and CRC-check / MD5-
based integrity checks are used to mitigate the risks of DoS
attacks. If the software updates and configuration changes are
performed via an OOB management system, this is also added
protection.
2.5.4. Additional Considerations 2.5.4. Additional Considerations
Where the MD5 algorithm is not used to perform data integrity Where the MD5 algorithm is not used to perform data integrity
checking of software images and configuration files, ISPs have checking of software images and configuration files, ISPs have
expressed an interest in having this functionality. IPsec is expressed an interest in having this functionality. IPsec is
considered too cumbersome and operationally difficult to use for data considered too cumbersome and operationally difficult to use for data
integrity and confidentiality. integrity and confidentiality.
2.6. Logging Considerations 2.6. Logging Considerations
skipping to change at page 32, line 23 skipping to change at page 33, line 7
whether an incoming packet has a legitimate source address or not. whether an incoming packet has a legitimate source address or not.
It has two modes: strict mode and loose mode. In strict mode, uRPF It has two modes: strict mode and loose mode. In strict mode, uRPF
checks whether the incoming packet has a source address that matches checks whether the incoming packet has a source address that matches
a prefix in the routing table, and whether the interface expects to a prefix in the routing table, and whether the interface expects to
receive a packet with this source address prefix. If the incoming receive a packet with this source address prefix. If the incoming
packet fails the unicast RPF check, the packet is not accepted on the packet fails the unicast RPF check, the packet is not accepted on the
incoming interface. Loose mode uRPF is not as specific and the incoming interface. Loose mode uRPF is not as specific and the
incoming packet is accepted if there is any route in the routing incoming packet is accepted if there is any route in the routing
table for the source address. table for the source address.
While BCP84 [RFC3704] and a study on uRPF experiences [I-D.savola- While BCP84 [RFC3704] and a study on uRPF experiences
bcp84-urpf-experiences] detail how asymmetry, i.e. multiple routes to [I-D.savola-bcp84-urpf-experiences] detail how asymmetry, i.e.
the source of a packet, does not preclude applying feasible paths multiple routes to the source of a packet, does not preclude applying
strict uRPF, it is generally not used on interfaces that are likely feasible paths strict uRPF, it is generally not used on interfaces
to have routing asymmetry. Usually for the larger ISPs, uRPF is that are likely to have routing asymmetry. Usually for the larger
placed at the customer edge of a network. ISPs, uRPF is placed at the customer edge of a network.
2.8.4. Rate Limiting 2.8.4. Rate Limiting
Rate limiting refers to allocating a specific amount of bandwidth or Rate limiting refers to allocating a specific amount of bandwidth or
packets per second to specific traffic types. This technique is packets per second to specific traffic types. This technique is
widely used to mitigate well-known protocol attacks such as the TCP- widely used to mitigate well-known protocol attacks such as the TCP-
SYN attack where a large number of resources get allocated for SYN attack where a large number of resources get allocated for
spoofed TCP traffic. Although this technique does not stop an spoofed TCP traffic. Although this technique does not stop an
attack, it can sometimes lessen the damage and impact on a specific attack, it can sometimes lessen the damage and impact on a specific
service. However, it can also make the impact of a DDoS attack much service. However, it can also make the impact of a DDoS attack much
skipping to change at page 34, line 5 skipping to change at page 35, line 5
against any control plane traffic can therefore be much more damaging against any control plane traffic can therefore be much more damaging
to a critical device than other types of traffic. No consistent to a critical device than other types of traffic. No consistent
deployment of this capability was found at the time of this writing. deployment of this capability was found at the time of this writing.
3. Security Considerations 3. Security Considerations
This entire document deals with current security practices in large This entire document deals with current security practices in large
ISP environments. It lists specific practices used in today's ISP environments. It lists specific practices used in today's
environments and as such does not in itself pose any security risk. environments and as such does not in itself pose any security risk.
4. References 4. IANA Considerations
4.1. Normative References This document has no actions for IANA.
5. Acknowledgments
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, Ron
Bonica, Ryan Mcdowell, Gaurab Upadhaya, Warren Kumari, Pekka Savola,
Fernando Gont, Chris Morrow, Ted Seely, Donald Smith and the numerous
ISP operators who supplied the information which is depicted in this
document.
6. References
6.1. 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.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828,
May 2000. May 2000.
skipping to change at page 34, line 29 skipping to change at page 37, line 29
[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.
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
Security Mechanism (GTSM)", RFC 3682, February 2004. Security Mechanism (GTSM)", RFC 3682, February 2004.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
4.2. Informational References [RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service
Attacks", RFC 3882, September 2004.
6.2. Informational References
[I-D.ietf-v6ops-icmpv6-filtering-recs] [I-D.ietf-v6ops-icmpv6-filtering-recs]
Davies, E. and J. Mohacsi, "Recommendations for Filtering Davies, E. and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", ICMPv6 Messages in Firewalls",
draft-ietf-v6ops-icmpv6-filtering-recs-02 (work in draft-ietf-v6ops-icmpv6-filtering-recs-02 (work in
progress), July 2006. progress), July 2006.
[I-D.lewis-infrastructure-security] [I-D.lewis-infrastructure-security]
Lewis, D., "Service Provider Infrastructure Security", Lewis, D., "Service Provider Infrastructure Security",
draft-lewis-infrastructure-security-00 (work in progress), draft-lewis-infrastructure-security-00 (work in progress),
skipping to change at page 35, line 5 skipping to change at page 39, line 5
[I-D.savola-bcp84-urpf-experiences] [I-D.savola-bcp84-urpf-experiences]
Savola, P., "Experiences from Using Unicast RPF", Savola, P., "Experiences from Using Unicast RPF",
draft-savola-bcp84-urpf-experiences-01 (work in progress), draft-savola-bcp84-urpf-experiences-01 (work in progress),
June 2006. June 2006.
[I-D.savola-rtgwg-backbone-attacks] [I-D.savola-rtgwg-backbone-attacks]
Savola, P., "Backbone Infrastructure Attacks and Savola, P., "Backbone Infrastructure Attacks and
Protections", draft-savola-rtgwg-backbone-attacks-02 (work Protections", draft-savola-rtgwg-backbone-attacks-02 (work
in progress), July 2006. in progress), July 2006.
Appendix A. Acknowledgments Appendix A. Protocol Specific Attacks
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, Ron
Bonica, Gaurab Upadhaya, Warren Kumari, Pekka Savola, Fernando Gont,
Chris Morrow, Donald Smith and the numerous ISP operators who
supplied the information which is depicted in this document.
Appendix B. Protocol Specific Attacks
This section will list many of the traditional protocol based attacks This section will list many of the traditional protocol based attacks
which have been observed over the years to cause malformed packets which have been observed over the years to cause malformed packets
and/or exploit protocol deficiencies. Note that they all exploit and/or exploit protocol deficiencies. Note that they all exploit
vulnerabilities in the actual protocol itself and often, additional vulnerabilities in the actual protocol itself and often, additional
authentication and auditing mechanisms are now used to detect and authentication and auditing mechanisms are now used to detect and
mitigate the impact of these attacks. The list is not exhaustive but mitigate the impact of these attacks. The list is not exhaustive but
is a fraction of the representation of what types of attacks are is a fraction of the representation of what types of attacks are
possible for varying protocols. possible for varying protocols.
B.1. Layer 2 Attacks A.1. Layer 2 Attacks
o ARP Flooding o ARP Flooding
B.2. IPv4 Protocol Based Attacks A.2. IPv4 Protocol Based Attacks
o IP Addresses, either source or destination, can be spoofed which o IP Addresses, either source or destination, can be spoofed which
in turn can circumvent established filtering rules. in turn can circumvent established filtering rules.
o IP Source Route Option can allows attackers to establish stealth o IP Source Route Option can allows attackers to establish stealth
TCP connections TCP connections
o IP Record Route Option can discloses information about the o IP Record Route Option can discloses information about the
topology of the network. topology of the network.
skipping to change at page 37, line 7 skipping to change at page 40, line 7
used to reroute or reclassify traffic based on specified used to reroute or reclassify traffic based on specified
precedence. precedence.
o IP checksum field has been used for scanning purposes, for example o IP checksum field has been used for scanning purposes, for example
when some firewalls did not check the checksum and allowed an when some firewalls did not check the checksum and allowed an
attacker to differentiate when the response came from an end- attacker to differentiate when the response came from an end-
system, and when from a firewall system, and when from a firewall
o IP TTL field can be used to bypass certain network based intrusion o IP TTL field can be used to bypass certain network based intrusion
detection systems and to map network behavior. detection systems and to map network behavior.
B.2.1. Higher Layer Protocol Attacks A.2.1. Higher Layer Protocol Attacks
The following lists additional attacks but does not explicitly The following lists additional attacks but does not explicitly
numerate them in detail. It is for informational purposes only. numerate them in detail. It is for informational purposes only.
o IGMP oversized packet o IGMP oversized packet
o ICMP Source Quench o ICMP Source Quench
o ICMP Mask Request o ICMP Mask Request
skipping to change at page 38, line 6 skipping to change at page 41, line 6
o SYN with IP Spoofing (Land Attack) o SYN with IP Spoofing (Land Attack)
o SYN and FIN bits set o SYN and FIN bits set
o TCP port scan attack o TCP port scan attack
o UDP spoofed broadcast echo (Fraggle Attack) o UDP spoofed broadcast echo (Fraggle Attack)
o UDP attack on diagnostic ports (Pepsi Attack) o UDP attack on diagnostic ports (Pepsi Attack)
B.3. IPv6 Attacks A.3. IPv6 Attacks
Any of the above-mentioned IPv4 attacks could be used in IPv6 Any of the above-mentioned IPv4 attacks could be used in IPv6
networks with the exception of any fragmentation and broadcast networks with the exception of any fragmentation and broadcast
traffic, which operate differently in IPv6. Note that all of these traffic, which operate differently in IPv6. Note that all of these
attacks are based on either spoofing or misusing any part of the attacks are based on either spoofing or misusing any part of the
protocol field(s). protocol field(s).
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
skipping to change at page 40, line 5 skipping to change at page 43, line 5
Merike Kaeo Merike Kaeo
Double Shot Security, Inc. Double Shot Security, Inc.
3518 Fremont Avenue North #363 3518 Fremont Avenue North #363
Seattle, 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 Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any 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
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 40, line 29 skipping to change at page 43, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 26 change blocks. 
72 lines changed or deleted 116 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/