draft-ietf-savi-threat-scope-01.txt   draft-ietf-savi-threat-scope-02.txt 
SAVI D. McPherson SAVI D. McPherson
Internet-Draft Arbor Networks Internet-Draft Verisign, Inc.
Intended status: Informational F. Baker Intended status: Informational F. Baker
Expires: January 26, 2010 Cisco Systems Expires: March 3, 2011 Cisco Systems
J. Halpern J. Halpern
Ericsson Ericsson
July 25, 2009 August 30, 2010
SAVI Threat Scope SAVI Threat Scope
draft-ietf-savi-threat-scope-01 draft-ietf-savi-threat-scope-02
Abstract
This memo discusses threats enabled by IP source address spoofing and
discusses a number of techniques aimed at mitigating those threats.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
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 This Internet-Draft will expire on March 3, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This memo discusses threats enabled by IP source address spoofing and described in the Simplified BSD License.
discusses a number of techniques aimed at mitigating those threats.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 5 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 5
3. Spoofed-based Attack Vectors . . . . . . . . . . . . . . . . . 5 3. Spoofed-based Attack Vectors . . . . . . . . . . . . . . . . . 6
3.1. Blind Attacks . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Blind Attacks . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Single Packet Attacks . . . . . . . . . . . . . . . . 6 3.1.1. Single Packet Attacks . . . . . . . . . . . . . . . . 6
3.1.2. Flood-Based DoS . . . . . . . . . . . . . . . . . . . 6 3.1.2. Flood-Based DoS . . . . . . . . . . . . . . . . . . . 6
3.1.3. Poisoning Attacks . . . . . . . . . . . . . . . . . . 7 3.1.3. Poisoning Attacks . . . . . . . . . . . . . . . . . . 7
3.1.4. Third Party Recon . . . . . . . . . . . . . . . . . . 7 3.1.4. Spoof-based Worm/Malware Propagation . . . . . . . . . 7
3.1.5. Spoof-based Worm/Malware Propagation . . . . . . . . . 7 3.1.5. Reflective Attacks . . . . . . . . . . . . . . . . . . 8
3.1.6. Reflective Attacks . . . . . . . . . . . . . . . . . . 7 3.1.6. Accounting Subversion . . . . . . . . . . . . . . . . 8
3.1.7. Accounting Subversion . . . . . . . . . . . . . . . . 8 3.1.7. Other Blind Spoofing Attacks . . . . . . . . . . . . . 8
3.1.8. Other Blind Spoofing Attacks . . . . . . . . . . . . . 8 3.2. Non-Blind Attacks . . . . . . . . . . . . . . . . . . . . 9
3.2. Non-Blind Attacks . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Man in the Middle (MITM) . . . . . . . . . . . . . . . 9
3.2.1. Man in the Middle (MITM) . . . . . . . . . . . . . . . 8
3.2.2. Third Party Recon . . . . . . . . . . . . . . . . . . 9 3.2.2. Third Party Recon . . . . . . . . . . . . . . . . . . 9
4. Current Anti-Spoofing Solutions . . . . . . . . . . . . . . . 9 4. Current Anti-Spoofing Solutions . . . . . . . . . . . . . . . 9
4.1. Host to link layer neighbor or switch . . . . . . . . . . 11 4.1. Host to link layer neighbor via switch . . . . . . . . . . 11
4.2. Upstream routers . . . . . . . . . . . . . . . . . . . . . 11 4.2. Upstream routers . . . . . . . . . . . . . . . . . . . . . 11
4.3. ISP Edge PE Router . . . . . . . . . . . . . . . . . . . . 12 4.3. ISP Edge PE Router . . . . . . . . . . . . . . . . . . . . 12
4.4. ISP NNI Router to ISP NNI Router . . . . . . . . . . . . . 12 4.4. ISP NNI Router to ISP NNI Router . . . . . . . . . . . . . 12
4.5. Spoofing In Local Area Network Segments . . . . . . . . . 12 4.5. Spoofing In Local Area Network Segments . . . . . . . . . 12
4.6. Cable Modem Subscriber Access . . . . . . . . . . . . . . 12 4.6. Cable Modem Subscriber Access . . . . . . . . . . . . . . 13
4.7. DSL Subscriber Access . . . . . . . . . . . . . . . . . . 13 4.7. DSL Subscriber Access . . . . . . . . . . . . . . . . . . 13
4.8. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.8. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.9. Unicast RPF . . . . . . . . . . . . . . . . . . . . . . . 13 4.9. Unicast RPF . . . . . . . . . . . . . . . . . . . . . . . 13
4.10. Port-based Address Binding . . . . . . . . . . . . . . . . 13 4.10. Port-based Address Binding . . . . . . . . . . . . . . . . 13
4.10.1. Manual Binding . . . . . . . . . . . . . . . . . . . . 13 4.10.1. Manual Binding . . . . . . . . . . . . . . . . . . . . 14
4.10.2. Automated Binding . . . . . . . . . . . . . . . . . . 14 4.10.2. Automated Binding . . . . . . . . . . . . . . . . . . 14
4.10.3. IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . 14 4.10.3. IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . 14
4.11. Cryptographic Techniques . . . . . . . . . . . . . . . . . 14 4.11. Cryptographic Techniques . . . . . . . . . . . . . . . . . 14
4.12. Residual Attacks . . . . . . . . . . . . . . . . . . . . . 14 4.12. Residual Attacks . . . . . . . . . . . . . . . . . . . . . 15
5. Topological Considerations . . . . . . . . . . . . . . . . . . 14 5. Topological Considerations . . . . . . . . . . . . . . . . . . 15
5.1. Address Provisioning Mechanisms . . . . . . . . . . . . . 14 5.1. Address Provisioning Mechanisms . . . . . . . . . . . . . 15
5.2. LAN devices with Multiple Addresses . . . . . . . . . . . 15 5.2. LAN devices with Multiple Addresses . . . . . . . . . . . 15
5.2.1. Routers . . . . . . . . . . . . . . . . . . . . . . . 15 5.2.1. Routers . . . . . . . . . . . . . . . . . . . . . . . 15
5.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.3. Multi-Instance hosts . . . . . . . . . . . . . . . . . 15 5.2.3. Multi-Instance hosts . . . . . . . . . . . . . . . . . 16
5.2.4. Multi-LAN Hosts . . . . . . . . . . . . . . . . . . . 15 5.2.4. Multi-LAN Hosts . . . . . . . . . . . . . . . . . . . 16
5.2.5. Firewalls . . . . . . . . . . . . . . . . . . . . . . 16 5.2.5. Firewalls . . . . . . . . . . . . . . . . . . . . . . 16
5.2.6. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 16 5.2.6. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 17
5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . . 16 5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . . 17
5.3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . 16 5.3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . 17
6. Applicability of Anti-Spoofing Solutions . . . . . . . . . . . 17 6. Applicability of Anti-Spoofing Solutions . . . . . . . . . . . 18
6.1. Analysis of Host Granularity Anti-Spoofing . . . . . . . . 17 6.1. Analysis of Host Granularity Anti-Spoofing . . . . . . . . 18
7. Existing Techniques for IP Source Address Validation . . . . . 18 7. Existing Techniques for IP Source Address Validation . . . . . 19
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 19 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Overview 1. Overview
The Internet Protocol, specifically IPv4 [RFC0791] and IPv6 The Internet Protocol, specifically IPv4 [RFC0791] and IPv6
[RFC2460], employ a connectionless hop-by-hop packet forwarding [RFC2460], employ a connectionless hop-by-hop packet forwarding
paradigm. A host connected to an IP network that wishes to paradigm. A host connected to an IP network that wishes to
communicate with another host on the network generates an IP packet communicate with another host on the network generates an IP packet
with source and destination IP addressing information, among other with source and destination IP addressing information, among other
options. options.
skipping to change at page 4, line 42 skipping to change at page 4, line 42
positively ascertained. Furthermore, BCP 38 only implies source positively ascertained. Furthermore, BCP 38 only implies source
address verification at the Internet Layer, and is most often address verification at the Internet Layer, and is most often
implemented on IP subnetwork address boundaries. One of the implemented on IP subnetwork address boundaries. One of the
difficulties in encouraging the deployment of BCP 38 is that there is difficulties in encouraging the deployment of BCP 38 is that there is
relatively little benefit until it is very widely deployed, which is relatively little benefit until it is very widely deployed, which is
not yet the case. The local application of the principle of BCP 38 not yet the case. The local application of the principle of BCP 38
fortunately has local benefit, even before BCP 38 is fully deployed. fortunately has local benefit, even before BCP 38 is fully deployed.
It also helps get the Internet towards a state where BCP 38 is more It also helps get the Internet towards a state where BCP 38 is more
widely followed. widely followed.
There is a possibility that in a LAN environment where multiple hosts It should be noted that while BCP 38 directs providers to provide
share a single LAN or IP port on a switch or router, one of those protection from spoofed prefixes, it is clearly desirable for
hosts may spoof the source addresses of other hosts within the local enterprise operators to provide that protection more locally, and
subnet. Understanding these threats and the relevant topologies in with better tracability. This allows the enterprise to be a better
which they're introduced is critical when assessing the threats that Internet participant, and to quickly detect and remedy problems when
exists with source address spoofing. they occur.
Also, there is a possibility that in a LAN environment where multiple
hosts share a single LAN or IP port on a switch or router, one of
those hosts may spoof the source addresses of other hosts within the
local subnet. Understanding these threats and the relevant
topologies in which they're introduced is critical when assessing the
threats that exists with source address spoofing.
The aim of this document is to provide some additional details The aim of this document is to provide some additional details
regarding spoofed-based threat vectors, and discuss implications of regarding spoofed-based threat vectors, and discuss implications of
various network topologies. various network topologies.
2. Glossary of Terms 2. Glossary of Terms
The following acronyms and terms are used throughout this memo. The following acronyms and terms are used throughout this memo.
BGP: The Border Gateway Protocol, used to manage routing policy BGP: The Border Gateway Protocol, used to manage routing policy
skipping to change at page 6, line 30 skipping to change at page 6, line 39
network or other services. network or other services.
An example of an attack that can cause a receiving system to crash is An example of an attack that can cause a receiving system to crash is
a LAND attack. A LAND attack packet would consist of an attacking a LAND attack. A LAND attack packet would consist of an attacking
system forwarding a packet (e.g., TCP SYN) to a target system that system forwarding a packet (e.g., TCP SYN) to a target system that
contains both a source and destination address of that target system. contains both a source and destination address of that target system.
The target system would "lock up" when creating connection state The target system would "lock up" when creating connection state
associated with the packet, or would get stuck in a state where it associated with the packet, or would get stuck in a state where it
continuously replies to itself. continuously replies to itself.
Another example of a single packet DoS attack involves that of a Another class of a single packet attacks involves an attacker
system poisoning network or DNS cache information, perhaps in order poisoning network or DNS cache information, perhaps in order to
to simply break a given hosts connection, enable MITM or other simply break a given hosts connection, enable MITM or other attacks.
attacks. Network level attacks that could involve single packet DoS Network level attacks that could involve single packet DoS include
include ARP cache poisoning and ICMP redirects. ARP cache poisoning and ICMP redirects. The most obvious example
which depends upon faslifying an IP source address is an on-link
attacker poisoning a routers ARP or ND cache. The ability to forge a
source address can also be helpful in causing a DNS cache to accept
and use incorrect information.
3.1.2. Flood-Based DoS 3.1.2. Flood-Based DoS
Flooding-based DoS attack vectors are particularly effective attacks Flooding-based DoS attack vectors are particularly effective attacks
on the Internet today. They usually entail flooding a large number on the Internet today. They usually entail flooding a large number
of packets towards a target system, with the hopes of either of packets towards a target system, with the hopes of either
exhausting connection state on the target system, consuming all exhausting connection state on the target system, consuming all
packet processing capabilities of the target or intermediate systems, packet processing capabilities of the target or intermediate systems,
or consuming a great deal of bandwidth available to the target system or consuming a great deal of bandwidth available to the target system
such that they are essentially inaccessible. such that they are essentially inaccessible.
skipping to change at page 7, line 23 skipping to change at page 7, line 36
result, mitigating these attacks on the receiving end with source- result, mitigating these attacks on the receiving end with source-
based policies is extremely difficult. based policies is extremely difficult.
Furthermore, the motivator for spoof-based DoS attacks may actually Furthermore, the motivator for spoof-based DoS attacks may actually
be to encourage the target to filter explicitly on a given set of be to encourage the target to filter explicitly on a given set of
source addresses, or order to disrupt the legitimate owner(s) access source addresses, or order to disrupt the legitimate owner(s) access
to the target system. to the target system.
3.1.3. Poisoning Attacks 3.1.3. Poisoning Attacks
As discussed in single-packet DoS above, there are several other While poison attacks can often be done with single packets, it is
attack mechanisms that employ source address spoofing. The more also true that a stream of packets can be used to find a window where
common of these attack vectors include DNS cache poisoning, ARP cache the target will accept the incorrect information. In general, this
poisoning, and ICMP redirects. While these attacks can be used for can be used to perform broadly the same kinds of poinsonings as
disrupting services, they're often used to redirect traffic to above, with more versatility.
network elements where attack intends to carry out additional
malicious activities.
3.1.4. Third Party Recon
Third party reconnaissance attacks may be either blind or non-blind
attacks. An example of third party reconnaissance is when an
attacker wishes to fingerprint a remote operating system type,
perhaps in order to initiate some TCP session hijacking, and in order
to do so must be able to identify the TCP sequence and algorithm
employed by the target system. Initiating a determined number of
connections with the target system may assist with this.
3.1.5. Spoof-based Worm/Malware Propagation 3.1.4. Spoof-based Worm/Malware Propagation
Self-propagating malware has been observed that spoofs it's source Self-propagating malware has been observed that spoofs it's source
address when attempting to propagate to other systems. Presumably, address when attempting to propagate to other systems. Presumably,
this was done to obfuscate the actual source address of the infected this was done to obfuscate the actual source address of the infected
system. system.
3.1.6. Reflective Attacks 3.1.5. Reflective Attacks
DNS reflective amplification attacks are a particularly potent DoS DNS reflective amplification attacks are a particularly potent DoS
attack vector on the Internet today. Like other amplification attack vector on the Internet today. Like other amplification
attacks, an attack source generates a packet with a source-spoofed attacks, an attack source generates a packet with a source-spoofed
address mapping to that of the target system. The packet, upon address mapping to that of the target system. The packet, upon
receipt by the victim or some intermediate node, typically elicits a receipt by the victim or some intermediate node, typically elicits a
large reply message, which is directed to the target of the attack. large reply message, which is directed to the target of the attack.
The amplification factor observed for attacks targeting DNS root and The amplification factor observed for attacks targeting DNS root and
other top level domain name infrastructure in early 2006 was on the other top level domain name infrastructure in early 2006 was on the
order of 76:1. The result is that just 15 attacking sources with order of 76:1. The result is that just 15 attacking sources with
skipping to change at page 8, line 23 skipping to change at page 8, line 28
Smurf attacks employ a similar reflective amplification attack Smurf attacks employ a similar reflective amplification attack
vector, exploiting traditional default IP subnet directed broadcast vector, exploiting traditional default IP subnet directed broadcast
address behaviors that would result in all the active hosts on a address behaviors that would result in all the active hosts on a
given subnet responding to (spoofed) ICMP echo request from an given subnet responding to (spoofed) ICMP echo request from an
attacker, and generating a large amount of ICMP echo response traffic attacker, and generating a large amount of ICMP echo response traffic
directed towards a target system. They were particularly effective directed towards a target system. They were particularly effective
in large campus LAN environments where 50k or more hosts might reside in large campus LAN environments where 50k or more hosts might reside
on a single subnet. on a single subnet.
3.1.7. Accounting Subversion 3.1.6. Accounting Subversion
If an attacker wishes to distribute content or other material in a If an attacker wishes to distribute content or other material in a
manner that employs protocols that require only uni-directional manner that employs protocols that require only uni-directional
flooding and generate no end-end transactional state, they may desire flooding and generate no end-end transactional state, they may desire
to spoof the source IP address of that content in order to avoid to spoof the source IP address of that content in order to avoid
detection or accounting functions enabled at the IP layer. detection or accounting functions enabled at the IP layer. While
this particular attack has not been observed, it is included here to
reflect the range of power that spoofed addresses may have even
without the ability to receive responses.
3.1.8. Other Blind Spoofing Attacks 3.1.7. Other Blind Spoofing Attacks
Other Blind spoofing attacks might include spoofing in order to Other Blind spoofing attacks might include spoofing in order to
exploit source routing or other policy based routing implemented in a exploit source routing or other policy based routing implemented in a
network. It may also be possible in some environments to use network. It may also be possible in some environments to use
spoofing techniques to perform blind or non-blind attacks on the spoofing techniques to perform blind or non-blind attacks on the
routers in a site or in the Internet. There are many techniques to routers in a site or in the Internet. There are many techniques to
mitigate these attacks, but it is well known that there are mitigate these attacks, but it is well known that there are
vulnerabilities in this area. vulnerabilities in this area. Among other attacks, if there are
multiple rotuers on-link with hosts, a host may be able to cause
problems for the routing system by replaying modified or unmodified
routing packets as if they came from another router.
3.2. Non-Blind Attacks 3.2. Non-Blind Attacks
Non-blind attacks often involve mechanisms such as eavesdropping on Non-blind attacks often involve mechanisms such as eavesdropping on
connection, resetting state so that new connections may be hijacking, connection, resetting state so that new connections may be hijacking,
and an array of other attack vectors. Perhaps the most common of and an array of other attack vectors. Perhaps the most common of
these attack vectors is known as man in the middle attacks. these attack vectors is known as man in the middle attacks.
3.2.1. Man in the Middle (MITM) 3.2.1. Man in the Middle (MITM)
skipping to change at page 9, line 24 skipping to change at page 9, line 36
replies to the Ethernet broadcast address ff:ff:ff:ff:ff:ff, replies to the Ethernet broadcast address ff:ff:ff:ff:ff:ff,
notifying all the hosts on the segment that the IP address(es) of the notifying all the hosts on the segment that the IP address(es) of the
target(s) now map to it's own MAC address. If the port to which the target(s) now map to it's own MAC address. If the port to which the
attacker is connected were to implement policy that binds a single attacker is connected were to implement policy that binds a single
Link Layer and IP address tuple to that port upon initial Link Layer and IP address tuple to that port upon initial
provisioning, spoofed packets, at the Link Layer and/or Network provisioning, spoofed packets, at the Link Layer and/or Network
Layer, would be discarded on ingress. Layer, would be discarded on ingress.
3.2.2. Third Party Recon 3.2.2. Third Party Recon
Another example of third party reconnaissance that falls into both Another example of sighted attack isthird party reconnaissance. The
the blind and non-blind attack class involves spoofing packets use of spoofed addresses, while not necessary for this, can often
towards a given target system and observing either target or provide additional information, and helps mask the tracability of the
intermediate system responses. For example, if an attacker were to activity. The attack involves sending packets towards a given target
source spoof TCP SYN packets towards a target system from a large set system and observing either target or intermediate system responses.
of source addresses, and observe responses from that target system or For example, if an attacker were to source spoof TCP SYN packets
some intermediate firewall or other middle box, they would be able to towards a target system from a large set of source addresses, and
identify what IP layer filtering policies may be in place to protect observe responses from that target system or some intermediate
that system. firewall or other middle box, they would be able to identify what IP
layer filtering policies may be in place to protect that system.
4. Current Anti-Spoofing Solutions 4. Current Anti-Spoofing Solutions
The first requirement is to eliminate datagrams with spoofed The first requirement is to eliminate datagrams with spoofed
addresses from the Internet. Identifying and dropping datagrams addresses from the Internet. Identifying and dropping datagrams
whose source address is incompatible with the Internet topology at whose source address is incompatible with the Internet topology at
sites where the relationship between the source address and topology sites where the relationship between the source address and topology
can be checked can eliminate such datagrams. For example, Internet can be checked can eliminate such datagrams. For example, Internet
devices can confirm that: devices can confirm that:
skipping to change at page 10, line 40 skipping to change at page 10, line 50
,' +----+ +------+ +------+ `. ,+------+ +--+---+. ,' +----+ +------+ +------+ `. ,+------+ +--+---+.
( |Host+--+Switch+--+ CPE +---)---+-+ PE +- - - -+ NNI | \\ ( |Host+--+Switch+--+ CPE +---)---+-+ PE +- - - -+ NNI | \\
`. +----+ +------+ |Router| ,' ( |Router| |Router| ) `. +----+ +------+ |Router| ,' ( |Router| |Router| )
`---. +------+' \\ +------+ +------+ / `---. +------+' \\ +------+ +------+ /
`----------------'' `. ,' `----------------'' `. ,'
'--. ISP B _.-' '--. ISP B _.-'
`----------'' `----------''
Figure 1: Points where an address can be validated Figure 1: Points where an address can be validated
Figure 1 illustrates five places where a source address can be Figure 1 illustrates five related pathes where a source address can
validated: be validated:
o Host to host or host to switch, o host to switch, including host to host via the switch
o Host to enterprise CPE Router, o Host to enterprise CPE Router,
o Enterprise CPE Router to ISP edge PE Router, o Enterprise CPE Router to ISP edge PE Router, and the reverse
o ISP NNI Router to ISP NNI Router, and the o ISP NNI Router to ISP NNI Router, and the
o ISP edge PE Router facing the destination CPE Router.
In general, datagrams with spoofed addresses can be detected and In general, datagrams with spoofed addresses can be detected and
discarded by devices that have an authoritative mapping between IP discarded by devices that have an authoritative mapping between IP
addresses and the network topology. For example, a device that has addresses and the network topology. For example, a device that has
an authoritative table between Link Layer and IP addresses on a link an authoritative table between Link Layer and IP addresses on a link
can discard any datagrams in which the IP address is not associated can discard any datagrams in which the IP address is not associated
with the Link Layer address in the datagram. The degree of with the Link Layer address in the datagram. The degree of
confidence in the source address depends on where the spoofing confidence in the source address depends on where the spoofing
detection is performed and the prefix aggregation in place between detection is performed and the prefix aggregation in place between
the spoofing detection and the source of the datagram. the spoofing detection and the source of the datagram.
4.1. Host to link layer neighbor or switch 4.1. Host to link layer neighbor via switch
The first point at which a datagram with a spoofed address can be The first point at which a datagram with a spoofed address can be
detected is on the link to which the source of the datagram is detected is on the link to which the source of the datagram is
connected. At this point in the network, the source Link Layer and connected. At this point in the network, the source Link Layer and
IP addresses are both available, and can be verified against each IP addresses are both available, and can be verified against each
other. A datagram in which the IP source address does not match the other. A datagram in which the IP source address does not match the
corresponding Link Layer address can be discarded. Of course, the corresponding Link Layer address can be discarded. Of course, the
trust in the filtering depends on the trust in the method through trust in the filtering depends on the trust in the method through
which the mappings are developed. This mechanism can be applied by which the mappings are developed. This mechanism can be applied by a
neighboring hosts, or by the first hop router. first hop router, or switch on the link. The first hop switch has
the most precise information for this.
On a shared medium link, such as Ethernet, the best that can be done On a truly shared medium link, such as classic Ethernet, the best
is to verify the Link Layer and IP addresses against the mappings. that can be done is to verify the Link Layer and IP addresses against
When the link is not shared, such as when the hosts are connected the mappings. When the link is not shared, such as when the hosts
through a switch, the source host can be identified precisely based are connected through a switch, the source host can be identified
on the port through which the datagram is received or the MAC address precisely based on the port through which the datagram is received or
if it is known to the switch. Port identification prevents the MAC address if it is known to the switch. Port identification
transmission of malicious datagrams whose Link Layer and IP addresses prevents transmission of malicious datagrams whose Link Layer and IP
are both spoofed to mimic another host. addresses are both spoofed to mimic another host.
4.2. Upstream routers 4.2. Upstream routers
Beyond the first hop router, subsequent routers may additionally Beyond the first hop router, subsequent routers may additionally
filter traffic from downstream networks. Because these routers do filter traffic from downstream networks. Because these routers do
not have access to the Link Layer address of the device from which not have access to the Link Layer address of the device from which
the datagram was sent, they are limited to confirming that the source the datagram was sent, they are limited to confirming that the source
IP address is within a prefix that is appropriate for downstream IP address is within a prefix that is appropriate for downstream
router from which the datagram was received. router from which the datagram was received.
skipping to change at page 13, line 7 skipping to change at page 13, line 13
enable MITM or other spoof-based attacks. enable MITM or other spoof-based attacks.
4.6. Cable Modem Subscriber Access 4.6. Cable Modem Subscriber Access
Cable Modem Termination Systems (CMTS) employ DOCSIS Media Access Cable Modem Termination Systems (CMTS) employ DOCSIS Media Access
Control (MAC) domains, which are similar to Ethernet LAN Control (MAC) domains, which are similar to Ethernet LAN
environments. environments.
4.7. DSL Subscriber Access 4.7. DSL Subscriber Access
Something about DSLAMs here.. While DSL subscriber access can be bridged or rotued, as seen by the
service provide3rs device, it is generally the case that the
protocols carry enough information to very which subscriber is
sending packets. Thus, for ensuring that one DSL subscriber does not
spoof another, enforcement can generally be done at the aggregation
router. This is true even when there is a bridged infrastructure
among the subscribers, as DSL access generally requires all
subscriber traffic to go through the access aggregation router.
If it is desirable to provide spoofing protection among the devices
within a residence, that would need to be provided by the CPE device,
as the ISPs rotuer does not have enough visiblity to do that. It is
not clear at this time that this problem is seen as a relevant
threat.
4.8. BCP 38 4.8. BCP 38
If BCP 38 [RFC2827] is implemented in LAN segments, it is typically If BCP 38 [RFC2827] is implemented in LAN segments, it is typically
done so on subnetwork boundaries and traditionally relates only to done so on subnetwork boundaries and traditionally relates only to
Network Layer ingress filtering policies. The result is that hosts Network Layer ingress filtering policies. The result is that hosts
within the segment cannot spoof packets from address space outside of within the segment cannot spoof packets from address space outside of
the local segment itself, however, they may still spoof packets using the local segment itself, however, they may still spoof packets using
sources addresses that exist within the local network segment. sources addresses that exist within the local network segment.
skipping to change at page 14, line 7 skipping to change at page 14, line 23
topologies where more than a single IP layer address may be topologies where more than a single IP layer address may be
associated with a MAC address on a given port, or where multiple associated with a MAC address on a given port, or where multiple
hosts are connected to a single IP port. Furthermore, if one or more hosts are connected to a single IP port. Furthermore, if one or more
dynamic address allocation mechanisms such as DHCP are employed, then dynamic address allocation mechanisms such as DHCP are employed, then
some mechanism must exist to associate those IP layer addresses with some mechanism must exist to associate those IP layer addresses with
the appropriate Link layer ports, as addresses are allocated or the appropriate Link layer ports, as addresses are allocated or
reclaimed. reclaimed.
4.10.2. Automated Binding 4.10.2. Automated Binding
DHCP, RADIUS, Other solutions, Cisco IP Source Guard, etc.. For IPv4 the primary and very widely used automated binding technique
is DHCP based address assignment. Controlling where authoratitive
information can be source, coupled with sniffing and enforcing the
assignments is an effective technique.
For IPv6, there are two common automated address binding techniques.
While there are many variations and details, for purposes of
understanding the threats and basic responses, these are Stateless
Address AutoConfiguration (SLAAC) and DHCPv6 based address
assignment. In both cases, binding establishment needs to be tied to
the state machines for these protocols, and appropriate message
sniffing and enforcement. For DHCPv6 based techniques, it is also
necessary to use classification techniques to ensure that responses
come from authoritative sources.
4.10.3. IEEE 802.1X 4.10.3. IEEE 802.1X
IEEE 802.1x is an authentication protocol that permits a network to IEEE 802.1x is an authentication protocol that permits a network to
determine the identity of a system seeking to join it and apply determine the identity of a system seeking to join it and apply
authorization rules to permit or deny the action. authorization rules to permit or deny the action.
4.11. Cryptographic Techniques 4.11. Cryptographic Techniques
Needless to say, MITM and replay attacks can typically be mitigated Needless to say, MITM and replay attacks can typically be mitigated
with cryptographic techniques. However, many of the applications with cryptographic techniques. However, many of the applications
today either don't or can't employ cryptographic authentication and today either don't or can't employ cryptographic authentication and
protection mechanisms. ARP and DNS are two examples. DNSSEC does protection mechanisms. ARP for IP v4 does not use such protection.
propose to assist, but until it's deployed ubiquitously, from While SEND provides such protection for IPv6 ND, SEND is not widely
clients, to resolvers, to authoritative roots, clients and resolvers used to date. While DNSsec will significantly help protect DNS from
are still vulnerable to replay, cache poisoning and MITM attacks. spoof based poisoning attacks, it will probably be sufficiently long
fortruly widespread use that other protections can be usefully
deployed as well.
4.12. Residual Attacks 4.12. Residual Attacks
Stuff which these solutions don't address It should be understood that not all combinations of network, service
and enforcement choices will result in a protectable network. For
Stuff which no one will use the existing solutions for example, if one uses conventional SLAAC, in a switched network, but
tries to only provide address enforment on the routers on the
network, then the ability to provide protection is severly limited.
5. Topological Considerations 5. Topological Considerations
As noted previously, topological components and address allocation As noted previously, topological components and address allocation
mechanisms have significant implications on what is feasible with mechanisms have significant implications on what is feasible with
regard to Link layer address and IP address port bindings. The regard to Link layer address and IP address port bindings. The
following sections discuss some of the various topologies and address following sections discuss some of the various topologies and address
allocation mechanisms that proposed SAVI solutions should attempt to allocation mechanisms that proposed SAVI solutions should attempt to
address. address.
5.1. Address Provisioning Mechanisms 5.1. Address Provisioning Mechanisms
In a strictly static environment configuration management for access In a strictly static environment configuration management for access
filters that map Link Layer and Network Layer addresses on a specific filters that map Link Layer and Network Layer addresses on a specific
switch port might be a viable option. However, most networks, switch port might be a viable option. However, most networks,
certainly, those that accommodate actual human users, are much more certainly, those that accommodate actual human users, are much more
dynamic in nature. As such, mechanisms that provide port-MAC-IP dynamic in nature. As such, mechanisms that provide port-MAC-IP
bindings need to accommodate dynamic address allocation schemes bindings need to accommodate dynamic address allocation schemes
enabled by protocols such as DHCP. enabled by protocols such as DHCP, DHCPv6 for address allocation, and
IPv6 Stateless Address Autoconfiguration.
5.2. LAN devices with Multiple Addresses 5.2. LAN devices with Multiple Addresses
From a topology considerations perspective, when attempting From a topology considerations perspective, when attempting
port-MAC-IP bindings, host connected to switch ports that may have port-MAC-IP bindings, host connected to switch ports that may have
one or more IP addresses, or certainly, devices that forward packets one or more IP addresses, or certainly, devices that forward packets
from other network segments, are problematic. from other network segments, are problematic.
5.2.1. Routers 5.2.1. Routers
The most obvious example of devices that are problematic when The most obvious example of devices that are problematic when
attempting to implement port-MAC-IP bindings is that of routers. attempting to implement port-MAC-IP bindings is that of routers.
Routers not only originate packets themselves and often have multiple Routers not only originate packets themselves and often have multiple
interfaces, but also forward packets from other network segments. As interfaces, but also forward packets from other network segments. As
a result, it's difficult for port-MAC-IP binding rules to be a result, it's difficult for port-MAC-IP binding rules to be
established a priori, because it's likely that many addresses and IP established a priori, because it's likely that many addresses and IP
subnets should be associated with the port-MAC in question. subnets should be associated with the port-MAC in question.
5.2.2. NATs 5.2.2. NATs
Prefix-based and multi-address NATs also become problematic, for the Validating traffic from Prefix-based and multi-address NATs also
same reasons as routers. Because they may forward traffic from an becomes problematic, for the same reasons as routers. Because they
array of address, a priori knowledge must exist providing what IPs may forward traffic from an array of address, a priori knowledge must
should be associated with a given port-MAC pair. exist providing what IPs should be associated with a given port-MAC
pair.
5.2.3. Multi-Instance hosts 5.2.3. Multi-Instance hosts
Another example that introduces complexities is that of multi- Another example that introduces complexities is that of multi-
instance hosts attached to a switch port. Multi clients, with the instance hosts attached to a switch port. These are single physical
same or different MACs, may be attached to the port and may either devices, which internally run multiple physical or logical hosts.
have static IP addresses assigned, or may receive one or more When the device is a blade server, with internal blades each hosting
dynamically via DHCP or similar means. Accommodating multi-instance a machine, there is essentially a physical switch inside the blade
hosts, or even blade-server type devices dynamic is feasible, buy may server. While tractable, this creates some complexity for
introduces complexities if the solution in question does not determining where enforcement logic can or should live.
accommodate unique considerations introduced in these environments.
Logically distinct hosts such as are provided by many varieties of
virtualization logic result in a single physical host, connect to a
single port on the ethernet switch in the topology, actually having
multiple internal IP and MAC addresses, and essentially an internal
switch. While it may be possible for this internal switch to help
control threats among the virtual hosts, or between virtual hosts and
other parts of the network, such enforcement can not be counted on at
this time.
5.2.4. Multi-LAN Hosts 5.2.4. Multi-LAN Hosts
Multi-interface hosts, in particular those that are multi-homed and Multi-interface hosts, in particular those that are multi-homed and
may forward packets from any of a number of source addresses, can be may forward packets from any of a number of source addresses, can be
problematic as well. In particular, if a port-MAC-IP binding is made problematic as well. In particular, if a port-MAC-IP binding is made
on each of the interfaces, and then either a loopback IP or the on each of the interfaces, and then either a loopback IP or the
address of third interface is used as the source address of a packet address of third interface is used as the source address of a packet
and forward through in interface for which the port-MAC-IP binding and forward through in interface for which the port-MAC-IP binding
doesn't map, the traffic may be discarded. Static configuration of doesn't map, the traffic may be discarded. Static configuration of
port-MAC-IP bindings may accommodate this scenario, although some a port-MAC-IP bindings may accommodate this scenario, although some a
priori knowledge on address assignment and topology is required. priori knowledge on address assignment and topology is required.
While the use of loopback addresssing or sending packets out one
interface with the source address from another are rare, they do
legitimately occur. Some servers, particularly ones that have
underlying virtualization, use loopback techniques for management.
5.2.5. Firewalls 5.2.5. Firewalls
Firewalls that forward packets from other network segments, or serve Firewalls that forward packets from other network segments, or serve
as a source for locally originated packets, suffer from the same as a source for locally originated packets, suffer from the same
issues as routers. issues as routers.
5.2.6. Mobile IP 5.2.6. Mobile IP
Mobile IP hosts in both IPv4 and IPv6 as proper members of the site Mobile IP hosts in both IPv4 and IPv6 as proper members of the site
where they are currently located. Their care-of-address is a where they are currently located. Their care-of-address is a
skipping to change at page 22, line 8 skipping to change at page 23, line 8
[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.
[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.
Authors' Addresses Authors' Addresses
Danny McPherson Danny McPherson
Arbor Networks Verisign, Inc.
Email: danny@arbor.net Email: dmcpherson@verisign.com
Fred Baker Fred Baker
Cisco Systems Cisco Systems
Email: fred@cisco.com Email: fred@cisco.com
Joel M. Halpern Joel M. Halpern
Ericsson Ericsson
Email: jhalpern@redback.com Email: joel.halpern@ericsson.com
 End of changes. 45 change blocks. 
138 lines changed or deleted 185 lines changed or added

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