draft-ietf-savi-threat-scope-00.txt   draft-ietf-savi-threat-scope-01.txt 
INTERNET-DRAFT Danny McPherson
Arbor Networks SAVI D. McPherson
Fred Baker Internet-Draft Arbor Networks
Cisco Systems Intended status: Informational F. Baker
Expires: July 2009 January 21, 2009 Expires: January 26, 2010 Cisco Systems
Intended Status: Informational J. Halpern
Ericsson
July 25, 2009
SAVI Threat Scope SAVI Threat Scope
<draft-ietf-savi-threat-scope-00.txt> draft-ietf-savi-threat-scope-01
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 to IETF 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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as 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 January 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
This memo discusses threats enabled by IP source address spoofing and This memo discusses threats enabled by IP source address spoofing and
discusses a number of techniques aimed at mitigating those threats. discusses a number of techniques aimed at mitigating those threats.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Glossary of Terms. . . . . . . . . . . . . . . . . . . . . . . 6 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 5
3. Spoofed-based Attack Vectors . . . . . . . . . . . . . . . . . 6 3. Spoofed-based Attack Vectors . . . . . . . . . . . . . . . . . 5
3.1. Blind Attacks . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Blind Attacks . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Single Packet DoS. . . . . . . . . . . . . . . . . . . . 7 3.1.1. Single Packet Attacks . . . . . . . . . . . . . . . . 6
3.1.2. Flood-Based DoS. . . . . . . . . . . . . . . . . . . . . 7 3.1.2. Flood-Based DoS . . . . . . . . . . . . . . . . . . . 6
3.1.3. Poisoning Attacks. . . . . . . . . . . . . . . . . . . . 8 3.1.3. Poisoning Attacks . . . . . . . . . . . . . . . . . . 7
3.1.4. Third Party Recon. . . . . . . . . . . . . . . . . . . . 9 3.1.4. Third Party Recon . . . . . . . . . . . . . . . . . . 7
3.1.5. Spoof-based Worm/Malware Propagation . . . . . . . . . . 9 3.1.5. Spoof-based Worm/Malware Propagation . . . . . . . . . 7
3.1.6. Reflective Attacks . . . . . . . . . . . . . . . . . . . 9 3.1.6. Reflective Attacks . . . . . . . . . . . . . . . . . . 7
3.1.7. Accounting Subversion. . . . . . . . . . . . . . . . . . 10 3.1.7. Accounting Subversion . . . . . . . . . . . . . . . . 8
3.1.8. Other Blind Spoofing Attacks . . . . . . . . . . . . . . 10 3.1.8. Other Blind Spoofing Attacks . . . . . . . . . . . . . 8
3.2. Non-Blind Attacks . . . . . . . . . . . . . . . . . . . . . 10 3.2. Non-Blind Attacks . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Man in the Middle (MITM) . . . . . . . . . . . . . . . . 10 3.2.1. Man in the Middle (MITM) . . . . . . . . . . . . . . . 8
3.2.2. Third Party Recon. . . . . . . . . . . . . . . . . . . . 11 3.2.2. Third Party Recon . . . . . . . . . . . . . . . . . . 9
4. Current Anti-Spoofing Solutions. . . . . . . . . . . . . . . . 11 4. Current Anti-Spoofing Solutions . . . . . . . . . . . . . . . 9
4.1. Host to link layer neighbor or switch . . . . . . . . . . . 13 4.1. Host to link layer neighbor or switch . . . . . . . . . . 11
4.2. Upstream routers. . . . . . . . . . . . . . . . . . . . . . 13 4.2. Upstream routers . . . . . . . . . . . . . . . . . . . . . 11
4.3. ISP Edge PE Router. . . . . . . . . . . . . . . . . . . . . 14 4.3. ISP Edge PE Router . . . . . . . . . . . . . . . . . . . . 12
4.4. ISP NNI Router to ISP NNI Router. . . . . . . . . . . . . . 14 4.4. ISP NNI Router to ISP NNI Router . . . . . . . . . . . . . 12
4.5. Spoofing In Local Area Network Segments . . . . . . . . . . 14 4.5. Spoofing In Local Area Network Segments . . . . . . . . . 12
4.6. Cable Modem Subscriber Access . . . . . . . . . . . . . . . 15 4.6. Cable Modem Subscriber Access . . . . . . . . . . . . . . 12
4.7. DSL Subscriber Access . . . . . . . . . . . . . . . . . . . 15 4.7. DSL Subscriber Access . . . . . . . . . . . . . . . . . . 13
4.8. BCP 38. . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.8. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.9. Unicast RPF . . . . . . . . . . . . . . . . . . . . . . . . 15 4.9. Unicast RPF . . . . . . . . . . . . . . . . . . . . . . . 13
4.10. Port-based Address Binding . . . . . . . . . . . . . . . . 15 4.10. Port-based Address Binding . . . . . . . . . . . . . . . . 13
4.10.1. Manual Binding. . . . . . . . . . . . . . . . . . . . . 16 4.10.1. Manual Binding . . . . . . . . . . . . . . . . . . . . 13
4.10.2. Automated Binding . . . . . . . . . . . . . . . . . . . 16 4.10.2. Automated Binding . . . . . . . . . . . . . . . . . . 14
4.10.3. IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . . 16 4.10.3. IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . 14
4.11. Cryptographic Techniques . . . . . . . . . . . . . . . . . 16 4.11. Cryptographic Techniques . . . . . . . . . . . . . . . . . 14
4.12. Residual Attacks . . . . . . . . . . . . . . . . . . . . . 17 4.12. Residual Attacks . . . . . . . . . . . . . . . . . . . . . 14
5. Topological Considerations . . . . . . . . . . . . . . . . . . 17 5. Topological Considerations . . . . . . . . . . . . . . . . . . 14
5.1. Address Provisioning Mechanisms . . . . . . . . . . . . . . 17 5.1. Address Provisioning Mechanisms . . . . . . . . . . . . . 14
5.2. LAN devices with Multiple Addresses . . . . . . . . . . . . 17 5.2. LAN devices with Multiple Addresses . . . . . . . . . . . 15
5.2.1. Routers. . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.1. Routers . . . . . . . . . . . . . . . . . . . . . . . 15
5.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2.3. Multi-Instance Hosts . . . . . . . . . . . . . . . . . . 18 5.2.3. Multi-Instance hosts . . . . . . . . . . . . . . . . . 15
5.2.4. Multi-LAN Hosts. . . . . . . . . . . . . . . . . . . . . 18 5.2.4. Multi-LAN Hosts . . . . . . . . . . . . . . . . . . . 15
5.2.5. Firewalls. . . . . . . . . . . . . . . . . . . . . . . . 19 5.2.5. Firewalls . . . . . . . . . . . . . . . . . . . . . . 16
5.2.6. Mobile IP. . . . . . . . . . . . . . . . . . . . . . . . 19 5.2.6. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 16
5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . . . 19 5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . . 16
6. Applicability of Anti-Spoofing Solutions . . . . . . . . . . . 19 5.3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . 16
6.1. Analysis of Host Granularity Anti-Spoofing. . . . . . . . . 19 6. Applicability of Anti-Spoofing Solutions . . . . . . . . . . . 17
7. Existing Techniques for IP Source Address Valida- 6.1. Analysis of Host Granularity Anti-Spoofing . . . . . . . . 17
tion" 20 771. . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Existing Techniques for IP Source Address Validation . . . . . 18
8. Deployment Considerations. . . . . . . . . . . . . . . . . . . 21 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 19
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . . 21
13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Overview 1. Overview
The Internet Protocol, specifically IPv4 [RFC791] and IPv6 [RFC2460], The Internet Protocol, specifically IPv4 [RFC0791] and IPv6
employ a connectionless hop-by-hop packet forwarding paradigm. A [RFC2460], employ a connectionless hop-by-hop packet forwarding
host connected to an IP network that wishes to communicate with paradigm. A host connected to an IP network that wishes to
another host on the network generates an IP packet with source and communicate with another host on the network generates an IP packet
destination IP addressing information, among other options. with source and destination IP addressing information, among other
options.
At the IP Network Layer, or Internet Layer, there is typically no At the IP Network Layer, or Internet Layer, there is typically no
required transactional state when communicating with other hosts on required transactional state when communicating with other hosts on
the network. Hosts generating packets for transmission have the the network. Hosts generating packets for transmission have the
opportunity to spoof (forge) the source address of packets which they opportunity to spoof (forge) the source address of packets which they
transmit. transmit.
Source address verification is necessary in order to detect and Source address verification is necessary in order to detect and
reject spoofed packets and contribute to the overall security of IP reject spoofed packets and contribute to the overall security of IP
networks. In particular, source address verification techniques networks. In particular, source address verification techniques
enable detection and rejection of spoofed packets, and also enable detection and rejection of spoofed packets, and also
implicitly provide some assurances that the source address in an IP implicitly provide some assurances that the source address in an IP
packet is legitimately assigned to the system that generated the packet is legitimately assigned to the system that generated the
packet. packet.
Solutions such as BCP 38 [RFC2827] provide guidelines for one such Solutions such as BCP 38 [RFC2827] provide guidelines for one such
technique for network ingress filtering. However, if these technique for network ingress filtering. However, if these
techniques are not implemented on 32-bit prefix boundaries at the techniques are not implemented at the ingress point of the IP
ultimate ingress point of the IP network then the validity of the network, then the validity of the source address can not be
source address can not be positively ascertained. Furthermore, BCP positively ascertained. Furthermore, BCP 38 only implies source
38 only implies source address verification at the Internet Layer, address verification at the Internet Layer, and is most often
and is most often implemented on IP subnetwork address boundaries. implemented on IP subnetwork address boundaries. One of the
difficulties in encouraging the deployment of BCP 38 is that there 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
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
widely followed.
There is a possibility that in an LAN environment where multiple There is a possibility that in a LAN environment where multiple hosts
hosts share a single IP port on a switch or router, one of those share a single LAN or IP port on a switch or router, one of those
hosts may source address spoof the source addresses of other hosts hosts may spoof the source addresses of other hosts within the local
within the local subnet. Understanding these threats and the subnet. Understanding these threats and the relevant topologies in
relevant topologies in which they're introduced is critical when which they're introduced is critical when assessing the threats that
assessing the threats that exists with source address spoofing. 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 21 skipping to change at page 5, line 21
CPE Router: Customer Premises Equipment Router. The router on the CPE Router: Customer Premises Equipment Router. The router on the
customer premises, whether owned by the customer or the provider. customer premises, whether owned by the customer or the provider.
Also called the Customer Endpoint, or CE, Router. Also called the Customer Endpoint, or CE, Router.
IP Address: An Internet Protocol Address, whether IPv4 or IPv6. IP Address: An Internet Protocol Address, whether IPv4 or IPv6.
ISP: Internet Service Provider. Any person or company that delivers ISP: Internet Service Provider. Any person or company that delivers
Internet service to another. Internet service to another.
MAC Address: An Ethernet Address. MAC Address: An Ethernet Address or comparable IEEE 802 series
address.
NNI Router: Network to Network Interface Router. This router NNI Router: Network to Network Interface Router. This router
interface faces a similar system operated by another ISP or other interface faces a similar system operated by another ISP or other
large network. large network.
PE Router: Provider Endpoint Router. This router faces a customer PE Router: Provider Endpoint Router. This router faces a customer
of an ISP. of an ISP.
Spoofing: The act of forging datagram header contents at the Link Spoofing: The act of forging datagram header contents at the Link or
or Network Layer Network Layer
TCP: The Transmission Control Protocol, used on end systems to TCP: The Transmission Control Protocol, used on end systems to
manage data exchange. manage data exchange.
uRPF: Unicast Reverse Path Forwarding. A procedure in which the uRPF: Unicast Reverse Path Forwarding. A procedure in which the
route table, which is usually used to look up destination route table, which is usually used to look up destination
addresses and route towards them, is used to look up the source addresses and route towards them, is used to look up the source
address and ensure that one is routing away from it. When this address and ensure that one is routing away from it. When this
test fails, the event may be logged, and the traffic is commonly test fails, the event may be logged, and the traffic is commonly
dropped. dropped.
skipping to change at page 7, line 16 skipping to change at page 6, line 13
attacks. attacks.
3.1. Blind Attacks 3.1. Blind Attacks
Blind attacks typically occur when an attacker isn't on the same Blind attacks typically occur when an attacker isn't on the same
local area network as a source or target, or when an attacker has no local area network as a source or target, or when an attacker has no
access to the datapath between the attack source(s) and the target access to the datapath between the attack source(s) and the target
systems. The result is that they have no access to legitimate source systems. The result is that they have no access to legitimate source
and target systems. and target systems.
3.1.1. Single Packet DoS 3.1.1. Single Packet Attacks
One type of blind attacks, which we'll refer to here as "single One type of blind attacks, which we'll refer to here as "single
packet DoS attacks", involves an attacking system injecting spoofed packet DoS attacks", involves an attacking system injecting spoofed
information into the network which results in either a complete crash information into the network which results in either a complete crash
of the target system, or in some manner poisons some network of the target system, or in some manner poisons some network
configuration or other information on a target system such to impact configuration or other information on a target system such to impact
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
skipping to change at page 9, line 28 skipping to change at page 8, line 6
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.6. 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 illicts 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
512k of upstream attack bandwidth could generate one Gbps of response 512k of upstream attack bandwidth could generate one Gbps of response
attack traffic towards a target system. attack traffic towards a target system.
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
skipping to change at page 10, line 17 skipping to change at page 8, line 35
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.
3.1.8. Other Blind Spoofing Attacks 3.1.8. 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. network. It may also be possible in some environments to use
spoofing techniques to perform blind or non-blind attacks on the
routers in a site or in the Internet. There are many techniques to
mitigate these attacks, but it is well known that there are
vulnerabilities in this area.
3.2. Non-Blind Attacks 3.2. Non-Blind Attacks
Non-blind attacks often involve mechansisms 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)
Connection Hijacking is one of the more common man in the middle Connection Hijacking is one of the more common man in the middle
attack vectors. In order to hijack a connection an attacker usually attack vectors. In order to hijack a connection an attacker usually
needs to be in the forwarding path and often times employs TCP RST or needs to be in the forwarding path and often times employs TCP RST or
other attacks in order to reset a transaction. The attacker may have other attacks in order to reset a transaction. The attacker may have
already compromised a system that's in the forwarding path, or they already compromised a system that's in the forwarding path, or they
may which to insert themselves in the forwarding path. may which to insert themselves in the forwarding path.
For example, an attacker with access to a host on LAN segment may For example, an attacker with access to a host on LAN segment may
wish to redirect all the traffic on the local segment destined for a wish to redirect all the traffic on the local segment destined for a
default gateway address (or all addresses) to itself in order to default gateway address (or all addresses) to itself in order to
perform man-in-the-middle attacks. In order to accomplish this the perform man-in-the-middle attacks. In order to accomplish this the
attacker might transmit gratuitous ARP [RFC826] messages or ARP attacker might transmit gratuitous ARP [RFC0826] messages or ARP
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
skipping to change at page 12, line 10 skipping to change at page 10, line 19
Filtering points farther away from the source of the datagram can Filtering points farther away from the source of the datagram can
make decreasingly authoritative assertions about the validity of the make decreasingly authoritative assertions about the validity of the
source address in the datagram. Nonetheless, there is value in source address in the datagram. Nonetheless, there is value in
dropping traffic that is clearly inappropriate, and in maintaining dropping traffic that is clearly inappropriate, and in maintaining
knowledge of the level of trust one can place in an address. knowledge of the level of trust one can place in an address.
Edge Network 1 CPE-ISP _.------------. Edge Network 1 CPE-ISP _.------------.
_.----------------. Ingress/ ISP A `--. _.----------------. Ingress/ ISP A `--.
,--'' `---. ,' `. ,--'' `---. ,' `.
,' +----+ +------+ +------+ `. / +------+ +------+ \ ,' +----+ +------+ +------+ `. / +------+ +------+ \\
( |Host+--+Switch+--+ CPE +---)-(---+ PE +- - - -+ NNI | ) ( |Host+--+Switch+--+ CPE +---)-(---+ PE +- - - -+ NNI | )
`. +----+ +------+ |Router| ,' \ |Router| |Router| / `. +----+ +------+ |Router| ,' \\ |Router| |Router| /
`---. Host-neighbor +------+' `.+------+ +--+---+,' `---. Host-neighbor +------+' `.+------+ +--+---+,'
`----------------'' '--. |_.-' `----------------'' '--. |_.-'
`------------'| `------------'|
| |
Edge Network 2 ISP-ISP Ingress | Edge Network 2 ISP-ISP Ingress |
_.----------------. _.----------.| _.----------------. _.----------.|
,--'' `---. ,-'' |--. ,--'' `---. ,-'' |--.
,' +----+ +------+ +------+ `. ,+------+ +--+---+. ,' +----+ +------+ +------+ `. ,+------+ +--+---+.
( |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 places where a source address can be
validated: validated:
o Host to host or host to switch, o Host to host or host to switch,
skipping to change at page 15, line 20 skipping to change at page 13, line 11
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.. Something about DSLAMs here..
4.8. BCP 38 4.8. BCP 38
If BCP 38 is implemented in LAN segments, it is typically done so on If BCP 38 [RFC2827] is implemented in LAN segments, it is typically
subnetwork boundaries and traditionally relates only to Network Layer done so on subnetwork boundaries and traditionally relates only to
ingress filtering policies. The result is that hosts within the Network Layer ingress filtering policies. The result is that hosts
segment cannot spoof packets from address space outside of the local within the segment cannot spoof packets from address space outside of
segment itself, however, they may still spoof packets using sources the local segment itself, however, they may still spoof packets using
addresses that exist within the local network segment. sources addresses that exist within the local network segment.
4.9. Unicast RPF 4.9. Unicast RPF
Unicast RPF is a crude mechanism to automate definition of BCP 38 Unicast RPF is a crude mechanism to automate definition of BCP 38
style filters based on routing table information. It's applicability style filters based on routing table information. It's applicability
parallels that of BCP 38, although deployment caveats exists, as parallels that of BCP 38, although deployment caveats exists, as
outlined in [RFC3704]. outlined in [RFC3704].
4.10. Port-based Address Binding 4.10. Port-based Address Binding
skipping to change at page 16, line 32 skipping to change at page 14, line 11
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.. DHCP, RADIUS, Other solutions, Cisco IP Source Guard, etc..
4.10.3. IEEE 802.1X 4.10.3. IEEE 802.1X
IEEE 802.1x is an authentication protocol that permits a network to
determine the identity of a system seeking to join it and apply
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 and DNS are two examples. DNSSEC does
propose to assist, but until it's deployed ubiquitously, from propose to assist, but until it's deployed ubiquitously, from
clients, to resolvers, to authoritative roots, clients and resolvers clients, to resolvers, to authoritative roots, clients and resolvers
are still vulnerable to replay, cache poisoning and MITM attacks. are still vulnerable to replay, cache poisoning and MITM attacks.
skipping to change at page 17, line 33 skipping to change at page 15, line 7
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.
5.2. LAN devices with Multiple Addresses 5.2. LAN devices with Multiple Addresses
From a topology considerations perspective, when attempting port-MAC- From a topology considerations perspective, when attempting
IP bindings, host connected to switch ports that may have one or more port-MAC-IP bindings, host connected to switch ports that may have
IP addresses, or certainly, devices that forward packets from other one or more IP addresses, or certainly, devices that forward packets
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 Prefix-based and multi-address NATs also become problematic, for the
same reasons as routers. Because they may forward traffic from an same reasons as routers. Because they may forward traffic from an
array of address, a priori knowledge must exist providing what IPs array of address, a priori knowledge must exist providing what IPs
should be associated with a given port-MAC pair. 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. Multi clients, with the
same or different MACs, may be attached to the port and may either same or different MACs, may be attached to the port and may either
have static IP addresses assigned, or may receive one or more have static IP addresses assigned, or may receive one or more
dynamically via DHCP or similar means. Accommodating multi-instance dynamically via DHCP or similar means. Accommodating multi-instance
hosts, or even blade-server type devices dynamic is feasible, buy may hosts, or even blade-server type devices dynamic is feasible, buy may
introduces complexities if the solution in question does not introduces complexities if the solution in question does not
accommodate unique considerations introduced in these environments. accommodate unique considerations introduced in these environments.
skipping to change at page 19, line 14 skipping to change at page 16, line 13
priori knowledge on address assignment and topology is required. priori knowledge on address assignment and topology is required.
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
Need to say something here, I think... Mobile IP 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
properly assigned address that is on the link they are using. And
their packets are sent and received using that address. (There was
at one time consideration of allowing mobile hosts to use their home
address when away from home. This was not done, precisely to ensure
that mobile hosts comply with source address validity requirements.)
Mobile Hosts with multiple physical interfaces fall into the cases
above.
Mobile IP home agents are somewhat more interesting. Although they
are (typically) fixed devices, they are required to send and receive
packets addressed from or to any currently properly registered mobile
node. From an analysis point of view, even though the packets that a
Home Agent handles are actually addressed to or from the link the HA
is on, it is probably best to think of them as routers, with a
virtual interface to the actual hosts they are serving.
5.2.7. Other Topologies 5.2.7. Other Topologies
Any topology that results in the possibility that a device connected Any topology that results in the possibility that a device connected
to a switch port may forward packets with more than a single source to a switch port may forward packets with more than a single source
address for packet which it originated may be problematic. address for packet which it originated may be problematic.
Additionally, address allocation schemas introduce additional Additionally, address allocation schemas introduce additional
considerations when examining a given SAVI solutions space. considerations when examining a given SAVI solutions space.
5.3. IPv6 Considerations
IPv6 introduces additional capabilities which indirectly complicate
the spoofing analysis. IPv6 introduces and recommends the use of
stateless address autoconfiguration (often referred to as SLAAC).
This allows hosts to determine their IP prefix, select an ID, and
then start communicating. While there are many advantages to this,
the absence of control interactions complicates the process of
behavioral enforcement.
An additional complication is the very large ID space. Again, this
64 bit ID space provided by IPv6 has many advantages. It provides
the opportunity for many useful behaviors. However, it also means
that in the absence of controls, hosts can mint anonymous addresses
as often as they like, modulo the idosyncrasies of the duplicate
address procedure. Like many behaviors, this is a feature for some
purposes, and a problem for others. But it does have implications
for switch cost; the switch needs to store more addresses and so
needs more memory.
6. Applicability of Anti-Spoofing Solutions 6. Applicability of Anti-Spoofing Solutions
What works where, what's needed? The above sections covered a number of security threats. Not all
these threats can be prevented by anti-spoofing techniques. However,
all of these threats can be ameliorated to some degree. We can look
at three categories of effect we can achieve:
Ingress filtering is useful, even with botnets using real addresses Prevention: Some of the threats described above explicitly require
that a host send packets using some other active hosts IP address
as a source. Anti-Spoofing measures can prevent these attacks.
Ingress filtering on the admin border is not sufficient, and more Impediment: Many of the attacks above, such as some kinds of DoS
fine-grained filtering from savi is necessary. attacks, can be conducted more easily if the attacking host can
use multiple different IP addresses. Depending upon the kind of
anti-spoofing available, the scope of such false addresses, or
even their use, may be prevented, hindering the attacker even if
the attack is not completely prevented.
Traceability: Even when attacks can not be prevented, the ability to
reliably trace an attack allows appropriate responses, and thereby
also creates an environment which discourages attacks instead of
encouraging them. Thus, ensuring that even attacks which are not
dependent upon spoofing can not use source address spoofing to
hide their origin is extremely important.
For example, sites which deploy BCP 38 can not be the source of
attacks which rely on spoofing the source site from which an attack
was launched. Wide deployment of BCP 38 would also simplify the task
of tracking attacks back to their actual origin.
6.1. Analysis of Host Granularity Anti-Spoofing 6.1. Analysis of Host Granularity Anti-Spoofing
Most IP spoofing validation can be provided with standard IP-based Applying anti-spoofing techniques at the host level enables a site to
policies such as those defined in BCP 38. However, at the ultimate achieve several valuable objectives. While it is likely the case
network ingress, the ability to perform a binding for port-MAC-IP that for many site topologies and policies, full source spoofing
provides considerable benefits over vanilla prefix-based source protection is not possible, it is also true that for many sites there
address validation. While it is true that a large array of are steps that can be taken that provide benefit.
topologies and address allocation schemas will introduce complexities
with automation of port-MAC-IP binding specifications, application of
source address validation for static and common dynamic addressed
allocation environments (e.g., DHCP) would significantly raise the
bar for effectively launching spoof-based attacks.
7. Existing Techniques for IP Source Address Validation" One important class of benefit is masquerade prevention. Security
threats involving one machine masquerading as another, for example in
order to hijack an apparently secure session, can occur within a site
with significant impact. Having mechanisms such that host facing
devices prevent this is a significant intra-site security
improvement. Given that security experts report that most security
breaches are internal, this can be valuable. One example of this is
that such techniques should mitigate internal attacks on the site
routing system.
Existing techniques for IP source address validation are insufficient A second class of benefit is related to the traceability described
for at least some of the following reasons: above. When a security incident is detect, either within a site, or
externally (and traced to the site, it can be critical to determine
what the actual source of the incident was. If address usage can be
tied to the kinds of anchors described earlier, then it is possible
to respond to security incidents.
o False negatives: Techniques may yield false negatives, In addition to these local observable benefits, there can be more
thus enabling an attacker to select an IP source address global benefits. For example, if address usage is tied to anchors,
that is spoofed, but still passes IP source address it may be possible to prevent or control the use of large numbers of
validation. anonymous IPv6 addresses for attacks, or at least to track even those
attacks back to their source.
o False positives: Techniques may yield false positives, 7. Existing Techniques for IP Source Address Validation
thereby causing interruption or denial of service to hosts
that use legitimate IP source addresses.
o Non-trivial configuration: Requirements for non-trivial Existing techniques for IP source address validation are
insufficient. While each technique has its own shortcomings, the
following list of general categories of reasons include some of the
deficiencies of all existing technique:
False negatives: Techniques may yield false negatives, thus enabling
an attacker to select an IP source address that is spoofed, but
still passes IP source address validation.
False positives: Techniques may yield false positives, thereby
causing interruption or denial of service to hosts that use
legitimate IP source addresses.
Non-trivial configuration: Requirements for non-trivial
configuration imply expenditures and pose a risk for configuration imply expenditures and pose a risk for
misconfiguration, which may again lead to false positives misconfiguration, which may again lead to false positives or false
or false negatives. Both may discourage operators from negatives. Both may discourage operators from employing a given
employing a given technique. technique.
o Proprietary: Procurement policies oftentimes require Proprietary: Procurement policies oftentimes require techniques that
techniques that are standardized, hence hindering or are standardized, hence hindering or preventing the deployment of
preventing the deployment of proprietary techniques. proprietary techniques.
The only standardized technique for IP source address validation is The only standardized technique for IP source address validation is
ingress filtering [RFC2827]. This calls for routers to check whether ingress filtering [RFC2827]. This calls for routers to check whether
the prefix of a to-be-forwarded packet's IP source address is amongst the prefix of a to-be-forwarded packet's IP source address is amongst
a list of prefixes considered legitimate for the interface through a list of prefixes considered legitimate for the interface through
which the packet arrives. Packets that fail this check are which the packet arrives. Packets that fail this check are
discarded. discarded.
Ingress filtering may yield false negatives in a deterministic Ingress filtering may yield false negatives in a deterministic
manner. Packets with a legitimate IP source address prefix, but a manner. Packets with a legitimate IP source address prefix, but a
skipping to change at page 22, line 6 skipping to change at page 20, line 14
choices have global implications, and act upon this responsibility, choices have global implications, and act upon this responsibility,
the problem is not going to go away. the problem is not going to go away.
Ideally, with additional work in the areas of SAVI to ease deployment Ideally, with additional work in the areas of SAVI to ease deployment
and management burdens, the deployment cost to operators will and management burdens, the deployment cost to operators will
decrease and more wide-scale deployment will continue. Furthermore, decrease and more wide-scale deployment will continue. Furthermore,
application of SAVI-like techniques provides more obvious benefits to application of SAVI-like techniques provides more obvious benefits to
network administrators that are concerned with MITM and similar network administrators that are concerned with MITM and similar
attacks. attacks.
9. Security Considerations As mentioned earlier, there are local security benefits to the
deployment of SAVI security mechanisms. This may help motivate the
deployment of tools with widespread benefit.
9. IANA Considerations
This memo asks the IANA for no new parameters.
Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are
required, or if those assignments or registries are created during
the RFC publication process. From the author"s perspective, it may
therefore be removed upon publication as an RFC at the RFC Editor"s
discretion.
10. Security Considerations
This document provides limited discussion of some security threats This document provides limited discussion of some security threats
source address validation improvements will help to mitigate. It is source address validation improvements will help to mitigate. It is
not meant to be all-inclusive, either from a threat analysis not meant to be all-inclusive, either from a threat analysis
perspective, or from the source address verification application perspective, or from the source address verification application
side. side.
It is seductive to think of SAVI solutions as providing the ability It is seductive to think of SAVI solutions as providing the ability
to use this technology to trace a datagram to the person, or at least to use this technology to trace a datagram to the person, or at least
end system, that originated it. For several reasons, the technology end system, that originated it. For several reasons, the technology
skipping to change at page 22, line 37 skipping to change at page 21, line 14
other systems (e.g., SMTP and peer-to-peer file sharing). other systems (e.g., SMTP and peer-to-peer file sharing).
Until every Internet-connected network implements source address Until every Internet-connected network implements source address
validation at the ultimate network ingress, and assurances exist that validation at the ultimate network ingress, and assurances exist that
intermediate devices are to never modify datagram source addresses, intermediate devices are to never modify datagram source addresses,
source addresses must not be used as an authentication mechanism. source addresses must not be used as an authentication mechanism.
The only technique to unquestionably verify source addresses of a The only technique to unquestionably verify source addresses of a
received datagram are cryptographic authentication mechanisms such as received datagram are cryptographic authentication mechanisms such as
IPSEC. IPSEC.
10. IANA Considerations 11. Acknowledgements
This document introduces no IANA considerations.
11. Acknowledgments
A portion of the primer text in this document came directly from A portion of the primer text in this document came directly from
[savi-operational], authored by Fred Back and Ralph Droms. Many [I-D.baker-sava-operational], authored by Fred Baker and Ralph Droms.
thanks to Christian Vogt for contributing text and a careful review Many thanks to Christian Vogt for contributing text and a careful
of this document. review of this document.
12. References 12. References
12.1. Normative References 12.1. Normative References
12.2. Informative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
http://tools.ietf.org/html/draft-baker-sava-cisco-ip-source-guard
"Cisco IP Version 4 Source Guard", Fred Baker, 7-Nov-07,
<draft-baker-sava-cisco-ip-source-guard-00.txt>
http://tools.ietf.org/html/draft-baker-sava-implementation
"Source address validation in the local environment", Fred Baker,
8-Nov-07,
<draft-baker-sava-implementation-00.txt>
http://tools.ietf.org/html/draft-baker-sava-operational [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
"IPv4/IPv6 Source Address Verification", Fred Baker, Ralph Droms, (IPv6) Specification", RFC 2460, December 1998.
19-Jun-07,
<draft-baker-sava-operational-00.txt>
http://tools.ietf.org/html/draft-baker-6man-multiprefix-default-route 12.2. Informative References
"Multiprefix IPv6 Routing for Ingress Filters", Fred Baker,
7-Nov-07,
<draft-baker-6man-multiprefix-default-route-00.txt>
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, [I-D.baker-sava-operational]
September 1981. Baker, F. and R. Droms, "IPv4/IPv6 Source Address
Verification", draft-baker-sava-operational-00 (work in
progress), June 2007.
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37, address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982. RFC 826, November 1982.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[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.
13. Authors' Addresses Authors' Addresses
Danny McPherson Danny McPherson
Arbor Networks, Inc. Arbor Networks
Email: danny@arbor.net Email: danny@arbor.net
Fred Baker Fred Baker
Cisco Systems Cisco Systems
Email: fred@cisco.com Email: fred@cisco.com
Acknowledgment Joel M. Halpern
Ericsson
Funding for the RFC Editor function is provided by the IETF Email: jhalpern@redback.com
Administrative Support Activity (IASA).
 End of changes. 51 change blocks. 
174 lines changed or deleted 269 lines changed or added

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