draft-ietf-savi-threat-scope-05.txt   draft-ietf-savi-threat-scope-06.txt 
SAVI D. McPherson SAVI D. McPherson
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Intended status: Informational F. Baker Intended status: Informational F. Baker
Expires: October 13, 2011 Cisco Systems Expires: August 27, 2013 Cisco Systems
J. Halpern J. Halpern
Ericsson Ericsson
April 11, 2011 February 23, 2013
SAVI Threat Scope SAVI Threat Scope
draft-ietf-savi-threat-scope-05 draft-ietf-savi-threat-scope-06
Abstract Abstract
Source Address Validation Improvement (SAVI) effort aims to Source Address Validation Improvement (SAVI) effort aims to
complement ingress filtering with finer-grained, standardized IP complement ingress filtering with finer-grained, standardized IP
source address validation. This document describes threats enabled source address validation. This document describes threats enabled
by IP source address spoofing both in the global and finer-grained by IP source address spoofing both in the global and finer-grained
context, describes currently available solutions and challenges, and context, describes currently available solutions and challenges, and
provides a starting point analysis for finer-grained (host provides a starting point analysis for finer-grained (host
granularity) anti-spoofing work. granularity) anti-spoofing work.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on October 13, 2011. This Internet-Draft will expire on August 27, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2013 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . 7
3.1.2. Flood-Based DoS . . . . . . . . . . . . . . . . . . . 7 3.1.2. Flood-Based DoS . . . . . . . . . . . . . . . . . . . 7
3.1.3. Poisoning Attacks . . . . . . . . . . . . . . . . . . 8 3.1.3. Poisoning Attacks . . . . . . . . . . . . . . . . . . 8
3.1.4. Spoof-based Worm/Malware Propagation . . . . . . . . . 8 3.1.4. Spoof-based Worm/Malware Propagation . . . . . . . . . 9
3.1.5. Reflective Attacks . . . . . . . . . . . . . . . . . . 8 3.1.5. Reflective Attacks . . . . . . . . . . . . . . . . . . 9
3.1.6. Accounting Subversion . . . . . . . . . . . . . . . . 9 3.1.6. Accounting Subversion . . . . . . . . . . . . . . . . 9
3.1.7. Other Blind Spoofing Attacks . . . . . . . . . . . . . 9 3.1.7. Other Blind Spoofing Attacks . . . . . . . . . . . . . 10
3.2. Non-Blind Attacks . . . . . . . . . . . . . . . . . . . . 9 3.2. Non-Blind Attacks . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Man in the Middle (MITM) . . . . . . . . . . . . . . . 10 3.2.1. Man in the Middle (MITM) . . . . . . . . . . . . . . . 10
3.2.2. Third Party Recon . . . . . . . . . . . . . . . . . . 10 3.2.2. Third Party Recon . . . . . . . . . . . . . . . . . . 10
4. Current Anti-Spoofing Solutions . . . . . . . . . . . . . . . 10 3.2.3. Other Non-Blind Spoofing Attacks . . . . . . . . . . . 11
4. Current Anti-Spoofing Solutions . . . . . . . . . . . . . . . 11
4.1. Topological Locations for Enforcement . . . . . . . . . . 12 4.1. Topological Locations for Enforcement . . . . . . . . . . 12
4.1.1. Host to link layer neighbor via switch . . . . . . . . 12 4.1.1. Host to link layer neighbor via switch . . . . . . . . 13
4.1.2. Upstream routers . . . . . . . . . . . . . . . . . . . 12 4.1.2. Upstream Switches . . . . . . . . . . . . . . . . . . 13
4.1.3. ISP Edge PE Router . . . . . . . . . . . . . . . . . . 13 4.1.3. Upstream Routers . . . . . . . . . . . . . . . . . . . 13
4.1.4. ISP NNI Router to ISP NNI Router . . . . . . . . . . . 13 4.1.4. ISP Edge PE Router . . . . . . . . . . . . . . . . . . 14
4.1.5. Cable Modem Subscriber Access . . . . . . . . . . . . 14 4.1.5. ISP NNI Router to ISP NNI Router . . . . . . . . . . . 14
4.1.6. DSL Subscriber Access . . . . . . . . . . . . . . . . 14 4.1.6. Cable Modem Subscriber Access . . . . . . . . . . . . 15
4.2. Currently Available Tools . . . . . . . . . . . . . . . . 14 4.1.7. DSL Subscriber Access . . . . . . . . . . . . . . . . 15
4.2.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Currently Available Tools . . . . . . . . . . . . . . . . 15
4.2.2. Unicast RPF . . . . . . . . . . . . . . . . . . . . . 14 4.2.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.3. Port-based Address Binding . . . . . . . . . . . . . . 15 4.2.2. Unicast RPF . . . . . . . . . . . . . . . . . . . . . 16
4.2.4. Cryptographic Techniques . . . . . . . . . . . . . . . 16 4.2.3. Port-based Address Binding . . . . . . . . . . . . . . 16
4.2.5. Residual Attacks . . . . . . . . . . . . . . . . . . . 16 4.2.4. Cryptographic Techniques . . . . . . . . . . . . . . . 17
5. Topological Challenges Facing SAVI . . . . . . . . . . . . . . 16 4.2.5. Residual Attacks . . . . . . . . . . . . . . . . . . . 17
5.1. Address Provisioning Mechanisms . . . . . . . . . . . . . 16 5. Topological Challenges Facing SAVI . . . . . . . . . . . . . . 18
5.2. LAN devices with Multiple Addresses . . . . . . . . . . . 17 5.1. Address Provisioning Mechanisms . . . . . . . . . . . . . 18
5.2.1. Routers . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. LAN devices with Multiple Addresses . . . . . . . . . . . 18
5.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2.1. Routers . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.3. Multi-Instance Hosts . . . . . . . . . . . . . . . . . 17 5.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.4. Multi-LAN Hosts . . . . . . . . . . . . . . . . . . . 18 5.2.3. Multi-Instance Hosts . . . . . . . . . . . . . . . . . 19
5.2.5. Firewalls . . . . . . . . . . . . . . . . . . . . . . 18 5.2.4. Multi-LAN Hosts . . . . . . . . . . . . . . . . . . . 19
5.2.6. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 18 5.2.5. Firewalls . . . . . . . . . . . . . . . . . . . . . . 20
5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . . 18 5.2.6. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 20
5.3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . 19 5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . . 20
5.3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . 20
6. Analysis of Host Granularity Anti-Spoofing . . . . . . . . . . 19 6. Analysis of Host Granularity Anti-Spoofing . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
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.
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. In particular, the network does not track any state
opportunity to spoof (forge) the source address of packets which they about the hosts using the network. This is normally a benefit.
transmit. However, as a consequence of this, hosts generating packets for
transmission have the opportunity to spoof (forge) the source address
of packets which they transmit, as the network does not have any way
to tell that some of the information is false.
Source address verification is necessary in order to detect and Source address validation is necessary in order to detect and reject
reject spoofed packets and contribute to the overall security of IP spoofed packets at the IP layer in the network, and contributes to
networks. In particular, source address verification techniques the overall security of IP networks. This draft deals with the
enable detection and rejection of spoofed packets, and also subset of such validation done by the network based on observed
implicitly provide some assurances that the source address in an IP traffic and policy. Such source address validation techniques enable
packet is legitimately assigned to the system that generated the detection and rejection of many spoofed packets, and also implicitly
packet. provide some assurances that the source address in an IP packet is
legitimately assigned to the system that generated the 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 at the ingress point of the IP techniques are not implemented at the ingress point of the IP
network, then the validity of the source address cannot be positively network, then the validity of the source address cannot be positively
ascertained. Furthermore, BCP 38 only implies source address ascertained. Furthermore, BCP 38 only implies source address
verification at the Internet Layer, and is most often implemented on validation at the Internet Layer, and is most often implemented on IP
IP subnetwork address boundaries. One of the difficulties in subnetwork address boundaries. One of the difficulties in
encouraging the deployment of BCP 38 is that there is relatively encouraging the deployment of BCP 38 is that there is relatively
little benefit until it is very widely deployed, which is not yet the little benefit until it is very widely deployed, which is not yet the
case. case.
Hence, in order to try to get better behavior, it is helpful to look Hence, in order to try to get better behavior, it is helpful to look
for an application like BCP 38, but one which can be applied locally, for an application like BCP 38, but one which can be applied locally,
and give locally beneficial results. The local benefit would provide and give locally beneficial results. The local benefit would provide
a reason for the site to deploy, while moving the Internet as a whole a reason for the site to deploy, while moving the Internet as a whole
towards an environment where BCP 38 is widely effected. SAVI is towards an environment where BCP 38 is widely effected. SAVI is
aimed at providing locally more specific protection, with the benefit aimed at providing locally more specific protection, with the benefit
of better local behavior and local traceability, while also providing of better local behavior and local traceability, while also providing
better compliance with the cases dealt with by BCP 38. better compliance with the cases dealt with by BCP 38.
It should be noted that while BCP 38 directs providers to provide It should be noted that while BCP 38 directs providers to provide
protection from spoofed prefixes, it is clearly desirable for protection from spoofed prefixes, it is clearly desirable for
enterprise operators to provide that protection more locally, and enterprise operators to provide that protection more locally, and
with better traceability. This allows the enterprise to be a better with better traceability. This allows the enterprise to be a better
Internet participant, and to quickly detect and remedy problems when Internet participant, and to quickly detect and remedy problems when
they occur. For example, when an enterprise receives a report of an they occur. For example, when an enterprise receives a report of an
attack originating within that enterprise, the operational staff attack originating within that enterprise, the operational staff
needs to be able to track from the IP address sourcing the attack to desires to be able to track from the IP address sourcing the attack
the particular machine within the enterprise that is the source. to the particular machine within the enterprise that is the source.
This both that the information be useable (logging), and that the This is typically simpler and more reliable than other techniques,
information be accurate, i.e. that no other machine could have been such as trying to find the attack in ongoing outbound traffic To do
using that address. this, the enterprise needs both that the address assignment and usage
information be usable (logging), and that the information be
accurate, i.e. that no other machine could have been using that
address.
Also, there is a possibility that in a LAN environment where multiple 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 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 those hosts may spoof the source addresses of other hosts within the
local subnet. Understanding these threats and the relevant local subnet. Understanding these threats and the relevant
topologies in which they're introduced is critical when assessing the topologies in which they're introduced is critical when assessing the
threats that exist with source address spoofing. threats that exist with source address spoofing.
The aim of this document is to provide some additional details This document provides additional details regarding spoofed-based
regarding spoofed-based threat vectors, and discuss implications of threat vectors, and discuss implications of various network
various network topologies. 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.
binding anchor: The relationship used by a device performing source
address enforcement to perform the validation and enforcement.
Examples in different situations include Layer 2 addresses or
physical ports.
BGP: The Border Gateway Protocol, used to manage routing policy BGP: The Border Gateway Protocol, used to manage routing policy
between large networks. between large networks.
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 Edge, or CE, Router. Also called the Customer Edge, 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
skipping to change at page 6, line 5 skipping to change at page 6, line 18
MAC Address: An Ethernet Address or comparable IEEE 802 series MAC Address: An Ethernet Address or comparable IEEE 802 series
address. 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 Edge Router. This router faces a customer of an PE Router: Provider Edge Router. This router faces a customer of an
ISP. ISP.
Spoofing: The act of forging datagram header contents at the Link or Spoofing: The act of sending a datagram header whose contents at the
Network Layer Link or Network Layer do not match the network policies and
activities on address assignment or claiming. Generally, this
corresponds o sending messages with source network or link layer
information that is assigned to or properly claimed by some other
devices in the network
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.
3. Spoofed-based Attack Vectors 3. Spoofed-based Attack Vectors
Spoofing is employed on the Internet for a number of reasons, most of Spoofing is employed on the Internet for a number of reasons, most of
which are in some manner associated with malicious or otherwise which are in some manner associated with malicious or otherwise
nefarious activities. In general, two classes of spoofed-based nefarious activities. In general, two classes of spoofed-based
attack vectors exist: blind attacks and non-blind attacks. The attack vectors exist: blind attacks and non-blind attacks. The
following sections provide some information of blind and non-blind following sections provide some information of blind and non-blind
attacks. attacks. The section includes information on attacks where the
spoofing is primarily intended to interfere with tracing the attacks,
as well as attacks where spoofing the source address is a necessary
component to the damage or interference.
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 data path between the attack source(s) and the target
systems. The result is that they have no access to legitimate source systems. In this situation, the attacker has no access to the source
and target systems. and target systems.
3.1.1. Single Packet Attacks 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 (Denial of Service) attacks", involves an attacking system
information into the network which results in either a complete crash injecting spoofed information into the network which results in
of the target system, or in some manner poisons some network either a complete crash of the target system, or in some manner
configuration or other information on a target system so as to impact poisons some network configuration or other information on a target
network or other services. system so as to impact 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 what is called a LAND attack. A LAND attack packet would consist of
system sending a packet (e.g., TCP SYN) to a target system that an attacking system sending a packet (e.g., TCP SYN) to a target
contains both a source and destination address of that target system. system that contains both a source and destination address of that
It would also contain a single value for port number, used as both target system. It would also contain a single value for port number,
the source and destination port number. Certain target systems will used as both the source and destination port number. Certain target
then "lock up" when creating connection state associated with the systems will then "lock up" when creating connection state associated
packet, or would get stuck in a state where it continuously replies with the packet, or would get stuck in a state where it continuously
to itself. As this is an attack that relies on bugs in the target, replies to itself. As this is an attack that relies on bugs in the
it is possible, but by no means certain, that this threat is no target, it is possible, but by no means certain, that this threat is
longer viable. no longer viable.
Another form of blind attack is a RST probe [RFC0793]. The attacker Another form of blind attack is a RST probe [RFC0793]. The attacker
sends a series of packets to a destination which is engaged in a sends a series of packets to a destination which is engaged in a
long-lived TCP session. The packets are RST packets, and the long-lived TCP session. The packets are RST packets, and the
attacker uses the known source and destination addresses and port attacker uses the known source and destination addresses and port
numbers, along with guesses at the sequence number. If he can send a numbers, along with guesses at the sequence number. If he can send a
packet close enough to the right value, in theory he can terminate packet close enough to the right value, in theory he can terminate
the TCP connection. While there are various steps that have been the TCP connection. While there are various steps that have been
developed to ameliorate this attack, preventing the spoofing of developed to ameliorate this attack, preventing the spoofing of
source addresses completely prevents the attack from occuring. source addresses completely prevents the attack from occuring.
skipping to change at page 8, line 25 skipping to change at page 8, line 45
3.1.3. Poisoning Attacks 3.1.3. Poisoning Attacks
While poison attacks can often be done with single packets, it is While poison attacks can often be done with single packets, it is
also true that a stream of packets can be used to find a window where also true that a stream of packets can be used to find a window where
the target will accept the incorrect information. In general, this the target will accept the incorrect information. In general, this
can be used to perform broadly the same kinds of poisonings as above, can be used to perform broadly the same kinds of poisonings as above,
with more versatility. with more versatility.
One important class of poisoning attacks are attacks aimed at One important class of poisoning attacks are attacks aimed at
poisoning network or DNS cache information, perhaps to simply break a poisoning network or DNS cache information, perhaps to simply break a
given host's connection, enable MITM or other attacks. Network level given host's connection, enable MITM (Man in the Middle) or other
attacks that could involve single packet DoS include ARP cache attacks. Network level attacks that could involve single packet DoS
poisoning and ICMP redirects. The most obvious example which depends include ARP cache poisoning and ICMP redirects. The most obvious
upon falsifying an IP source address is an on-link attacker poisoning example which depends upon falsifying an IP source address is an on-
a router's ARP or ND cache. The ability to forge a source address link attacker poisoning a router's ARP or ND cache. The ability to
can also be helpful in causing a DNS cache to accept and use forge a source address can also be helpful in causing a DNS cache to
incorrect information. accept and use incorrect information.
3.1.4. Spoof-based Worm/Malware Propagation 3.1.4. Spoof-based Worm/Malware Propagation
Self-propagating malware has been observed that spoofs its source Self-propagating malware has been observed that spoofs its 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. This attack is important both in terms of an attack vector system. This attack is important both in terms of an attack vector
that SAVI may help prevent, and also as a problem which SAVI can help that SAVI may help prevent, and also as a problem which SAVI can help
track back to find infected systems. track back to find infected systems.
skipping to change at page 9, line 38 skipping to change at page 10, line 13
without the ability to receive responses. without the ability to receive responses.
3.1.7. 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. Among other attacks, if there are vulnerabilities in this area.
multiple routers 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 hijacked, connection, resetting state so that new connections may be hijacked,
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. In this these attack vectors is known as man in the middle attacks. In this
case, we are concerned not with an attacker who can modify a stream, case, we are concerned not with an attacker who can modify a stream,
but rather one who has access to information from the stream, and but rather one who has access to information from the stream, and
uses that to launch his own attacks. uses that to launch his own attacks.
skipping to change at page 10, line 21 skipping to change at page 10, line 41
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 wish to insert themselves in the forwarding path. may wish 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, in perform man-in-the-middle attacks. In order to accomplish this, in
IPv4 the attacker might transmit gratuitous ARP [RFC0826] messages or IPv4 the attacker might transmit gratuitous ARP [RFC0826] messages or
ARP replies to the Ethernet broadcast address ff:ff:ff:ff:ff:ff, ARP 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. Similar vulnerabilities target(s) now map to it's own Layer 2 address. The source IP address
exist in IPv6 NDP [RFC4861]. in this case is spoofed. Similar vulnerabilities exist in IPv6 NDP
[RFC4861].
3.2.2. Third Party Recon 3.2.2. Third Party Recon
Another example of sighted attack is third party reconnaissance. The Another example of sighted attack is third party reconnaissance. The
use of spoofed addresses, while not necessary for this, can often use of spoofed addresses, while not necessary for this, can often
provide additional information, and helps mask the traceability of provide additional information, and helps mask the traceability of
the activity. The attack involves sending packets towards a given the activity. The attack involves sending packets towards a given
target system and observing either target or intermediate system target system and observing either target or intermediate system
responses. For example, if an attacker were to source spoof TCP SYN responses. For example, if an attacker were to source spoof TCP SYN
packets towards a target system from a large set of source addresses, packets towards a target system from a large set of source addresses,
and observe responses from that target system or some intermediate and observe responses from that target system or some intermediate
firewall or other middle box, they would be able to identify what IP firewall or other middle box, they would be able to identify what IP
layer filtering policies may be in place to protect that system. layer filtering policies may be in place to protect that system.
3.2.3. Other Non-Blind Spoofing Attacks
There are presumably many other attacks that can be performed based
on the ability t spoof source address while seeing the target. Among
other attacks, if there are multiple routers 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.
4. Current Anti-Spoofing Solutions 4. Current Anti-Spoofing Solutions
The first requirement is to eliminate datagrams with spoofed IP The goal of this work is to reduce datagrams with spoofed IP
addresses from the Internet. Identifying and dropping datagrams addresses from the Internet. This can be aided by Identifying and
whose source address is incompatible with the Internet topology at dropping datagrams whose source address binding is incompatible with
the Internet topology and learned information. This can be done 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 and binding information can be checked. For example, With these
devices can confirm that: bindings, in many networks Internet devices can confirm that:
o The IP source address is appropriate for the lower layer address o The IP source address is appropriate for the lower layer address
(they both identify the same system) (they both identify the same system)
o The IP source address is appropriate for the device at the layer 2 o The IP source address is explicitly identified as appropriate for
switch port (the address was assigned to a, and perhaps the, the physical topology; for example, the source address is
system that uses that port) appropriate for the layer 2 switch port through which the datagram
was received.
o The prefix to which the IP source address belongs is appropriate o The prefix to which the IP source address belongs is appropriate
for the part of the network topology from which the IP datagram for the part of the network topology from which the IP datagram
was received (while the individual system may be unknown, it is was received (while the individual system may be unknown, it is
reasonable to believe that the system is located in that part of reasonable to believe that the system is located in that part of
the network). the network).
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
skipping to change at page 12, line 15 skipping to change at page 12, line 52
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. Topological Locations for Enforcement 4.1. Topological Locations for Enforcement
There are a number of kinds of places, which one might call There are a number of kinds of places, which one might call
topological locations, where solutions may or should be deployed. topological locations, where solutions may or should be deployed. As
can be seen in the details below, as the point of enforcement moves
away from a single cable attached directly to the host being
validated, additional complications arise. It is likely that fully
addressing many of these cases may require additional coordination
mechanisms across the device which cover the disparate paths.
4.1.1. Host to link layer neighbor via switch 4.1.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 validated against each
other. A datagram in which the IP source address does not match the other, and potentially against the physical port being used. 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 a which the mappings are developed. This mechanism can be applied by a
first hop router, or switch on the link. The first hop switch has first hop router, or switch on the link. The first hop switch has
the most precise information for this. the most precise information for this.
On a truly shared medium link, such as classic Ethernet, the best On a truly shared medium link, such as classic Ethernet, the best
that can be done is to verify the Link Layer and IP addresses against that can be done is to validate the Link Layer and IP addresses
the mappings. When the link is not shared, such as when the hosts against the mappings. When the link is not shared, such as when the
are connected through a switch, the source host can be identified hosts are connected through a switch, the source host can be
precisely based on the port through which the datagram is received or identified precisely based on the port through which the datagram is
the MAC address if it is known to the switch. Port identification received or the Layer 2 address if it is known to the switch. Port
prevents transmission of malicious datagrams whose Link Layer and IP identification prevents transmission of malicious datagrams whose
addresses are both spoofed to mimic another host. Link Layer and IP addresses are both spoofed to mimic another host.
Other kinds of links may fall at different places in this spectrum, Other kinds of links may fall at different places in this spectrum,
with some wireless links having easier ways of identifying individual with some wireless links having easier ways of identifying individual
devices than others, for example. devices than others, for example.
4.1.2. Upstream routers 4.1.2. Upstream Switches
In many topologies, there can be additional switches between the host
attached switch and the first router in the network. In these cases,
additional issues can arise which affect SAVI operations. If the
bridging topologies which connects the switches changes, or if LACP
[IEEE802.3ad] changes which links are used to deliver traffic, the
switch may need to move the SAVI state to a different port, are the
state may need to be moved or reestablished on a different switch.
4.1.3. 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.
Options include the use of simple access lists or the use of unicast Options include the use of simple access lists or the use of unicast
reverse path filtering (uRPF). Access lists are generally reverse path filtering (uRPF). Access lists are generally
appropriate only for the simplest cases, as management can be appropriate only for the simplest cases, as management can be
difficult. Strict Unicast RPF accepts the source address on a difficult. Strict Unicast RPF accepts the source address on a
datagram if and only if it comes from a direction that would be datagram if and only if it comes from a direction that would be
rational to send a datagram directed to the address, which means that rational to send a datagram directed to the address, which means that
the filter is derived from routing information. These filtering the filter is derived from routing information. These filtering
procedures are discussed in more detail in [RFC3704]. procedures are discussed in more detail in [RFC3704].
4.1.3. ISP Edge PE Router In many cases, this router has access to information about what IP
prefixes are to be used on a given subnet. This might be because it
delegated that prefix through DHCP or monitored such a delegation.
It may have advertised that prefix in IPv6 Neighbor Discovery Router
Advertisement messages, or monitored such an advertisement. These
can be seen as generalizations of the access lists above. When the
topology permits, the router can enforce that these prefixes are used
by the hosts.
4.1.4. ISP Edge PE Router
An obvious special case of the discussion is with an ISP PE router, An obvious special case of the discussion is with an ISP PE router,
where it provides its customer with access. BCP 38 specifically where it provides its customer with access. BCP 38 specifically
encourages ISPs to use ingress filtering to limit the incidence of encourages ISPs to use ingress filtering to limit the incidence of
spoofed addresses in the network. spoofed addresses in the network.
The question that the ISP must answer for itself is the degree to The question that the ISP must answer for itself is the degree to
which it trusts its downstream network. A contract might be written which it trusts its downstream network. A contract might be written
between an ISP and its customer requiring that the customer apply the between an ISP and its customer requiring that the customer apply the
procedures of network ingress filtering to the customer's own procedures of network ingress filtering to the customer's own
network, although there's no way upstream networks would be able to network, although there's no way upstream networks would be able to
verify this. validate this.
Conversely, if the provider has assigned a single IP address to the Conversely, if the provider has assigned a single IP address to the
customer (for example, with IPv4 NAT in the CPE) PE enforcement of customer (for example, with IPv4 NAT in the CPE) PE enforcement of
BCP 38 can be on the full address, simplifying many issues. BCP 38 can be on the full address, simplifying many issues.
4.1.4. ISP NNI Router to ISP NNI Router 4.1.5. ISP NNI Router to ISP NNI Router
The considerations explicitly related to customer networks can also The considerations explicitly related to customer networks can also
be applied to neighboring ISPs. An interconnection agreement might be applied to neighboring ISPs. An interconnection agreement might
be written between two companies requiring network ingress filtering be written between two companies requiring network ingress filtering
policy be implemented on all customers connections. ISPs might, for policy be implemented on all customers connections. ISPs might, for
example, mark datagrams from neighboring ISPs that do not sign such a example, mark datagrams from neighboring ISPs that do not sign such a
contract or demonstrably do not behave in accordance with it as contract or demonstrably do not behave in accordance with it as
'untrusted'. Alternatively, the ISP might place untrusted prefixes 'untrusted'. Alternatively, the ISP might place untrusted prefixes
into a separate BGP community [RFC4271] and use that to advertise the into a separate BGP community [RFC4271] and use that to advertise the
level of trust to its BGP peers. level of trust to its BGP peers.
In this case, uRPF is less effective as a verification tool, due to In this case, uRPF is less effective as a validation tool, due to
asymmetric routing. However, when it can be shown that spoofed asymmetric routing. However, when it can be shown that spoofed
addresses are present, the procedure can be applied. addresses are present, the procedure can be applied.
Part of the complication here is that in the abstract it is very Part of the complication here is that in the abstract it is very
difficult to know what addresses should appear in packets sent from difficult to know what addresses should appear in packets sent from
one ISP to another. Hence packet level filtering and enforcement is one ISP to another. Hence packet level filtering and enforcement is
very difficult at this point in the network. Whether one views this very difficult at this point in the network. Whether one views this
as specific to the NNI, or a general property of the Internet, it is as specific to the NNI, or a general property of the Internet, it is
still a major factor that needs to be taken into account. still a major factor that needs to be taken into account.
4.1.5. Cable Modem Subscriber Access 4.1.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. These share some properties with general Control (MAC) domains. These share some properties with general
switched networks, as described above in Section 4.1.1, some switched networks, as described above in Section 4.1.1, some
properties with DSL access networks, as described below in properties with DSL access networks, as described below in
Section 4.1.6. They also often have their own provisioning and Section 4.1.7. They also often have their own provisioning and
monitoring tools which may address some of the issues described here. monitoring tools which may address some of the issues described here.
4.1.6. DSL Subscriber Access 4.1.7. DSL Subscriber Access
While DSL subscriber access can be bridged or routed, as seen by the While DSL subscriber access can be bridged or routed, as seen by the
service provider's device, it is generally the case that the service provider's device, it is generally the case that the
protocols carry enough information to verify which subscriber is protocols carry enough information to validate which subscriber is
sending packets. Thus, for ensuring that one DSL subscriber does not sending packets. Thus, for ensuring that one DSL subscriber does not
spoof another, enforcement can generally be done at the aggregation spoof another, enforcement can generally be done at the aggregation
router. This is true even when there is a bridged infrastructure router. This is true even when there is a bridged infrastructure
among the subscribers, as DSL access generally requires all among the subscribers, as DSL access generally requires all
subscriber traffic to go through the access aggregation router. subscriber traffic to go through the access aggregation router.
If it is desirable to provide spoofing protection among the devices If it is desirable to provide spoofing protection among the devices
within a residence, that would need to be provided by the CPE device, within a residence, that would need to be provided by the CPE device,
as the ISPs router does not have enough visibility to do that. It is as the ISPs router does not have enough visibility to do that. It is
not clear at this time that this problem is seen as a relevant not clear at this time that this problem is seen as a relevant
skipping to change at page 15, line 10 skipping to change at page 16, line 26
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. Its applicability style filters based on routing table information. Its applicability
parallels that of BCP 38, although deployment caveats exist, as parallels that of BCP 38, although deployment caveats exist, as
outlined in [RFC3704]. outlined in [RFC3704].
4.2.3. Port-based Address Binding 4.2.3. Port-based Address Binding
Much of the work of SAVI is initially targeting minimizing source Much of the work of SAVI is initially targeting minimizing source
address spoofing in the LAN. In particular, if mechanisms can be address spoofing in the LAN. In particular, if mechanisms can be
defined to accommodate configuration of port binding information for defined to accommodate configuration of port binding information for
IP, either to a port, to an unforgeable MAC address, or to other IP, either to a port, to an an unchangeable or authenticated MAC
unforgeable credentials in the packet, a large portion of the address, or to other credentials in the packet such that an impostor
spoofing threat space in the LAN can be marginalized. can not create the needed values, a large portion of the spoofing
threat space in the LAN can be marginalized.
However, establishing this binding is not trivial, and varying across However, establishing this binding is not trivial, and varying across
both topologies type and address allocation mechanisms. both topologies type and address allocation mechanisms.
4.2.3.1. Manual Binding 4.2.3.1. Manual Binding
Binding of a single Link Layer and Network Layer address to a port Binding of a single Link Layer and Network Layer address to a port
may initially seem trivial. However, two primary areas exist that may initially seem trivial. However, two primary areas exist that
can complicate such techniques. In particular, these areas involve can complicate such techniques. In particular, these areas involve
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 via a single physical port. Furthermore, if one hosts are connected via a single physical port. Furthermore, if one
or more dynamic address allocation mechanisms such as DHCP are or more dynamic address allocation mechanisms such as DHCP are
employed, then some mechanism must exist to associate those IP layer employed, then some mechanism must exist to associate those IP layer
addresses with the appropriate Link layer ports, as addresses are addresses with the appropriate Link layer ports, as addresses are
allocated or reclaimed. allocated or reclaimed.
4.2.3.2. Automated Binding 4.2.3.2. Automated Binding
For IPv4 the primary and very widely used automated address For IPv4 the primary and very widely used automated address
assignment technique is DHCP based address assignment. Controlling assignment technique is DHCP based address assignment. This can be
where authoritative information can be sourced, coupled with sniffing coupled with filtering policies which control which hosts can
and enforcing the assignments is an effective technique, which can in originate DHCP replies. Under such circumstances, SAVI switches can
many networks automatically provide sufficient binding information. treat DHCP replies as authoritative sources of IP Address binding
information. By eavesdropping on the DHCP exchanges, the SAVI switch
can create the bindings needed for address usage enforcement.
For IPv6, there are two common automated address assignment For IPv6, there are two common automated address assignment
techniques. While there are many variations and details, for techniques. While there are many variations and details, for
purposes of understanding the threats and basic responses, these are purposes of understanding the threats and basic responses, these are
Stateless Address Autoconfiguration (SLAAC) and DHCPv6 based address Stateless Address Autoconfiguration (SLAAC) and DHCPv6 based address
assignment. In both cases, SAVI binding establishment needs to be assignment. For DHCP based IPv6 address assignment, the techniques
tied to the state machines for these address assignment protocols, above are applicable and suitable.
with appropriate message sniffing and enforcement. For DHCPv6 based
techniques, it is also necessary to use classification techniques to When SLAAC is used for IPv address assignment, the switches can
ensure that responses which are trusted actually come from observe the SLAAC messages and use those to create the enforcement
authoritative sources. bindings. This enables the switches to ensure that only properly
claimed IP addresses are used for data traffic. It does not enforce
that these addresses are assigned to the hosts, since SLAAC does not
have a notion of address assignment.
4.2.3.3. IEEE 802.1x 4.2.3.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 user seeking to join it and apply
authorization rules to permit or deny the action. In and of authorization rules to permit or deny the action. In and of
themselves, such tools confirm only that the user is authorized to themselves, such tools confirm only that the user is authorized to
use the network, but do not enforce what IP address the user is use the network, but do not enforce what IP address the user is
allowed to use. It is worth noting that elements of 802.1x may well allowed to use. It is worth noting that elements of 802.1x may well
be useful as binding anchors for SAVI solutions. be useful as binding anchors for SAVI solutions.
4.2.4. Cryptographic Techniques 4.2.4. 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 for IPv4 does not use such protection. protection mechanisms. ARP for IPv4 does not use such protection.
While SEND provides such protection for IPv6 NDP, SEND is not widely While SEND provides such protection for IPv6 NDP, SEND is not widely
used to date. used to date. Usage of such techniques is outside the scope of this
document.
While DNSSEC will significantly help protect DNS from the effects of While DNSSEC will significantly help protect DNS from the effects of
spoof based poisoning attacks, such protection does not help protect spoof based poisoning attacks, such protection does not help protect
the rest of the network from spoofed attacks. the rest of the network from spoofed attacks.
4.2.5. Residual Attacks 4.2.5. Residual Attacks
It should be understood that not all combinations of network, service It should be understood that not all combinations of network, service
and enforcement choices will result in a protectable network. For and enforcement choices will result in a protectable network. For
example, if one uses conventional SLAAC, in a switched network, but example, if one uses conventional SLAAC, in a switched network, but
skipping to change at page 18, line 5 skipping to change at page 19, line 26
Logically distinct hosts such as are provided by many varieties of Logically distinct hosts such as are provided by many varieties of
virtualization logic result in a single physical host, connect to a virtualization logic result in a single physical host, connect to a
single port on the Ethernet switch in the topology, actually having single port on the Ethernet switch in the topology, actually having
multiple internal virtual machines, each with IP and MAC addresses, multiple internal virtual machines, each with IP and MAC addresses,
and what is essentially (or sometimes literally) an internal LAN and what is essentially (or sometimes literally) an internal LAN
switch. While it may be possible for this internal switch to help switch. While it may be possible for this internal switch to help
control threats among the virtual hosts, or between virtual hosts and control threats among the virtual hosts, or between virtual hosts and
other parts of the network, such enforcement cannot be counted on at other parts of the network, such enforcement cannot be counted on at
this time. this time.
A further complication with multi-instance hosts is that in many
environments these hosts may move while retaining their IP addresses.
This can be an actual relocation of the running software, or a backup
instance taking over the functions of the software. In both cases,
the IP address will appear at a new topological location. Depending
upon the protocols used, it may have the same MAC address or
different one, and the system may or may not issue a gratuitous ARP
request after relocation.
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
forwarded through an interface for which the port-MAC-IP binding forwarded through an 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
skipping to change at page 20, line 14 skipping to change at page 21, line 44
determine what the actual source of the incident was. If address determine what the actual source of the incident was. If address
usage can be tied to the kinds of anchors described earlier, then it usage can be tied to the kinds of anchors described earlier, then it
is possible to respond to security incidents. is possible to respond to security incidents.
In addition to these local observable benefits, there can be more In addition to these local observable benefits, there can be more
global benefits. For example, if address usage is tied to anchors, global benefits. For example, if address usage is tied to anchors,
it may be possible to prevent or control the use of large numbers of it may be possible to prevent or control the use of large numbers of
anonymous IPv6 addresses for attacks, or at least to track even those anonymous IPv6 addresses for attacks, or at least to track even those
attacks back to their source. attacks back to their source.
As described below in the security considerations, these operational
behaviors need to be evaluated in the context of the reduction in
user privacy implied if one logs traffic bindings. In particular, in
addition to the architectural trade offs, the network administrator
must plan for the proper handling of this privacy relevant
information about his users.
7. IANA Considerations 7. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
Note to RFC Editor: This section will have served its purpose if it Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are correctly tells IANA that no new assignments or registries are
required, or if those assignments or registries are created during required, or if those assignments or registries are created during
the RFC publication process. From the authors' perspective, it may the RFC publication process. From the authors' perspective, it may
therefore be removed upon publication as an RFC at the RFC Editor's therefore be removed upon publication as an RFC at the RFC Editor's
discretion. discretion.
8. Security Considerations 8. 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 validation 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
can be used to derive circumstantial evidence, but does not actually can be used to derive circumstantial evidence, but does not actually
solve that problem. solve that problem.
In the Internet Layer, the source address of a datagram should be the In the Internet Layer, the source address of a datagram should be the
address of the system that originated it and to which any reply is address of the system that originated it and to which any reply is
expected to come. But systems fall into several broad categories. expected to come. But systems fall into several broad categories.
Many are single user systems, such as laptops and PDAs. Multi-user Many are single user systems, such as laptops and PDAs. Multi-user
systems are commonly used in industry, and a wide variety of systems are commonly used in industry, and a wide variety of
middleware systems and application servers have no user at all, but middleware systems and application servers have no user at all, but
by design relay messages or perform services on behalf of users of by design relay messages or perform services on behalf of users of
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 validate source addresses of a
received datagram are cryptographic authentication mechanisms such as received datagram are cryptographic authentication mechanisms such as
IPsec. IPsec.
It must be presume that there will be some failure modes in any SAVI
deployment, given the history of technical security mechanisms. A
possible attack to be considered by network administrators is an
inside attack probing the network for modes of spoofing that can be
accomplished. If the probes are conducted at a level below alarm
thresholds, this might allow an internal attacker to safely determine
what spoof modes he can use. Thus, the use of these techniques must
be managed in such a way as to avoid giving a false sense of security
to the network administrator.
8.1. Privacy Considerations
It should be understood that enforcing and recording IP address
bindings has privacy implications. In general, collecting private
information about users brings ethical and legal responsibilities to
the network administrator.
With operations of the type described here, the network administrator
is collecting information about where on his network the user is
active. In addition, the recorded bindings supplement address usage
information about users that is available from DHCP logs. For
example, if IPv6 SLAAC is being used, ad IP to Layer 2 address
bindings are being logged, the administrator will have access to
information associating users with their IP addresses even if IPv6
privacy addresses are used.
In addition to this, care must be taken in attributing actions to
users on the basis of this sort of information. Whatever the
theoretical strength of the tools, administrators should always allow
for such information being wrong, and should be careful about any
actions taken on the basis of apparent attribution. These techniques
do nothing about address spoofing from other sites, so any evaluation
of attribution also needs to allow for such cases.
9. Acknowledgments 9. 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
[I-D.baker-sava-operational], authored by Fred Baker and Ralph Droms. [I-D.baker-sava-operational], authored by Fred Baker and Ralph Droms.
Many thanks to Christian Vogt, Suresh Bhogavilli, and Pekka Savola Many thanks to Christian Vogt, Suresh Bhogavilli, and Pekka Savola
for contributing text and a careful review of this document. for contributing text and a careful review of this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 21, line 34 skipping to change at page 24, line 12
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
10.2. Informative References 10.2. Informative References
[I-D.baker-sava-operational] [I-D.baker-sava-operational]
Baker, F. and R. Droms, "IPv4/IPv6 Source Address Baker, F. and R. Droms, "IPv4/IPv6 Source Address
Verification", draft-baker-sava-operational-00 (work in Verification", draft-baker-sava-operational-00 (work in
progress), June 2007. progress), June 2007.
[IEEE802.3ad]
Standards Association, IEEE., "IEEE 801.1AX-2008, IEEE
Standard for Local and Metropolitan Area Networks - Link
Aggregation", 2008.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC0826] 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.
[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
 End of changes. 51 change blocks. 
141 lines changed or deleted 257 lines changed or added

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