SAVI D. McPherson
Internet-Draft VeriSign, Inc.
Intended status: Informational F. Baker
Expires: September 3, 2011 Cisco Systems
J. Halpern
Ericsson
March 2, 2011
SAVI Threat Scope
draft-ietf-savi-threat-scope-04
Abstract
Source Address Validation Improvement (SAVI) effort aims to
complement ingress filtering with finer-grained, standardized IP
source address validation. This document describes threats enabled
by IP source address spoofing both in the global and finer-grained
context, describes currently available solutions and challenges, and
provides a starting point analysis for finer-grained (host
granularity) anti-spoofing work.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 3, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
McPherson, et al. Expires September 3, 2011 [Page 1]
Internet-Draft SAVI Threat Scope March 2011
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 5
3. Spoofed-based Attack Vectors . . . . . . . . . . . . . . . . . 6
3.1. Blind Attacks . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Single Packet Attacks . . . . . . . . . . . . . . . . 6
3.1.2. Flood-Based DoS . . . . . . . . . . . . . . . . . . . 7
3.1.3. Poisoning Attacks . . . . . . . . . . . . . . . . . . 8
3.1.4. Spoof-based Worm/Malware Propagation . . . . . . . . . 8
3.1.5. Reflective Attacks . . . . . . . . . . . . . . . . . . 8
3.1.6. Accounting Subversion . . . . . . . . . . . . . . . . 9
3.1.7. Other Blind Spoofing Attacks . . . . . . . . . . . . . 9
3.2. Non-Blind Attacks . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Man in the Middle (MITM) . . . . . . . . . . . . . . . 10
3.2.2. Third Party Recon . . . . . . . . . . . . . . . . . . 10
4. Current Anti-Spoofing Solutions . . . . . . . . . . . . . . . 10
4.1. Topological Locations for Enforcement . . . . . . . . . . 12
4.1.1. Host to link layer neighbor via switch . . . . . . . . 12
4.1.2. Upstream routers . . . . . . . . . . . . . . . . . . . 12
4.1.3. ISP Edge PE Router . . . . . . . . . . . . . . . . . . 13
4.1.4. ISP NNI Router to ISP NNI Router . . . . . . . . . . . 13
4.1.5. Cable Modem Subscriber Access . . . . . . . . . . . . 14
4.1.6. DSL Subscriber Access . . . . . . . . . . . . . . . . 14
4.2. Currently Available Tools . . . . . . . . . . . . . . . . 14
4.2.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2. Unicast RPF . . . . . . . . . . . . . . . . . . . . . 14
4.2.3. Port-based Address Binding . . . . . . . . . . . . . . 15
4.2.4. Cryptographic Techniques . . . . . . . . . . . . . . . 16
4.2.5. Residual Attacks . . . . . . . . . . . . . . . . . . . 16
5. Topological Challenges Facing SAVI . . . . . . . . . . . . . . 16
5.1. Address Provisioning Mechanisms . . . . . . . . . . . . . 16
5.2. LAN devices with Multiple Addresses . . . . . . . . . . . 17
5.2.1. Routers . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.3. Multi-Instance Hosts . . . . . . . . . . . . . . . . . 17
5.2.4. Multi-LAN Hosts . . . . . . . . . . . . . . . . . . . 18
5.2.5. Firewalls . . . . . . . . . . . . . . . . . . . . . . 18
5.2.6. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 18
5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . . 18
5.3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . 19
McPherson, et al. Expires September 3, 2011 [Page 2]
Internet-Draft SAVI Threat Scope March 2011
6. Analysis of Host Granularity Anti-Spoofing . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
McPherson, et al. Expires September 3, 2011 [Page 3]
Internet-Draft SAVI Threat Scope March 2011
1. Overview
The Internet Protocol, specifically IPv4 [RFC0791] and IPv6
[RFC2460], employ a connectionless hop-by-hop packet forwarding
paradigm. A host connected to an IP network that wishes to
communicate with another host on the network generates an IP packet
with source and destination IP addressing information, among other
options.
At the IP Network Layer, or Internet Layer, there is typically no
required transactional state when communicating with other hosts on
the network. Hosts generating packets for transmission have the
opportunity to spoof (forge) the source address of packets which they
transmit.
Source address verification is necessary in order to detect and
reject spoofed packets and contribute to the overall security of IP
networks. In particular, source address verification techniques
enable detection and rejection of spoofed packets, and also
implicitly 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
technique for network ingress filtering. However, if these
techniques are not implemented at the ingress point of the IP
network, then the validity of the source address cannot be positively
ascertained. Furthermore, BCP 38 only implies source address
verification at the Internet Layer, and is most often 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.
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,
and give locally beneficial results. The local benefit would provide
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
aimed at providing locally more specific protection, with the benefit
of better local behavior and local traceability, while also providing
better compliance with the cases dealt with by BCP 38.
It should be noted that while BCP 38 directs providers to provide
protection from spoofed prefixes, it is clearly desirable for
enterprise operators to provide that protection more locally, and
with better traceability. This allows the enterprise to be a better
Internet participant, and to quickly detect and remedy problems when
McPherson, et al. Expires September 3, 2011 [Page 4]
Internet-Draft SAVI Threat Scope March 2011
they occur. For example, when an enterprise receives a report of an
attack originating within that enterprise, the operational staff
needs to be able to track from the IP address sourcing the attack to
the particular machine within the enterprise that is the source.
This both that the information be useable (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
hosts share a single LAN or IP port on a switch or router, one of
those hosts may spoof the source addresses of other hosts within the
local subnet. Understanding these threats and the relevant
topologies in which they're introduced is critical when assessing the
threats that exist with source address spoofing.
The aim of this document is to provide some additional details
regarding spoofed-based threat vectors, and discuss implications of
various network topologies.
2. Glossary of Terms
The following acronyms and terms are used throughout this memo.
BGP: The Border Gateway Protocol, used to manage routing policy
between large networks.
CPE Router: Customer Premises Equipment Router. The router on the
customer premises, whether owned by the customer or the provider.
Also called the Customer Edge, or CE, Router.
IP Address: An Internet Protocol Address, whether IPv4 or IPv6.
ISP: Internet Service Provider. Any person or company that delivers
Internet service to another.
MAC Address: An Ethernet Address or comparable IEEE 802 series
address.
NNI Router: Network to Network Interface Router. This router
interface faces a similar system operated by another ISP or other
large network.
PE Router: Provider Edge Router. This router faces a customer of an
ISP.
McPherson, et al. Expires September 3, 2011 [Page 5]
Internet-Draft SAVI Threat Scope March 2011
Spoofing: The act of forging datagram header contents at the Link or
Network Layer
TCP: The Transmission Control Protocol, used on end systems to
manage data exchange.
uRPF: Unicast Reverse Path Forwarding. A procedure in which the
route table, which is usually used to look up destination
addresses and route towards them, is used to look up the source
address and ensure that one is routing away from it. When this
test fails, the event may be logged, and the traffic is commonly
dropped.
3. Spoofed-based Attack Vectors
Spoofing is employed on the Internet for a number of reasons, most of
which are in some manner associated with malicious or otherwise
nefarious activities. In general, two classes of spoofed-based
attack vectors exist: blind attacks and non-blind attacks. The
following sections provide some information of blind and non-blind
attacks.
3.1. Blind Attacks
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
access to the datapath between the attack source(s) and the target
systems. The result is that they have no access to legitimate source
and target systems.
3.1.1. Single Packet Attacks
One type of blind attacks, which we'll refer to here as "single
packet DoS attacks", involves an attacking system injecting spoofed
information into the network which results in either a complete crash
of the target system, or in some manner poisons some network
configuration or other information on a target system so as to impact
network or other services.
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
system sending a packet (e.g., TCP SYN) to a target system that
contains both a source and destination address of that target system.
It would also contain a single value for port number, used as both
the source and destination port number. Certain target systems will
then "lock up" when creating connection state associated with the
packet, or would get stuck in a state where it continuously replies
McPherson, et al. Expires September 3, 2011 [Page 6]
Internet-Draft SAVI Threat Scope March 2011
to itself. As this is an attack that relies on bugs in the target,
it is possible, but by no means certain, that this threat is no
longer viable.
Another form of blind attack is a RST probe. The attacker sends a
series of packets to a destination which is engaged in a long-lived
TCP session. The packets are RST packets, and the attacker uses the
known source and destination addresses and port 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 the TCP connection.
While there are various steps that have been developed to ameliorate
this attack, preventing the spoofing of source addresses completely
prevents the attack from occuring.
3.1.2. Flood-Based DoS
Flooding-based DoS attack vectors are particularly effective attacks
on the Internet today. They usually entail flooding a large number
of packets towards a target system, with the hopes of either
exhausting connection state on the target system, consuming all
packet processing capabilities of the target or intermediate systems,
or consuming a great deal of bandwidth available to the target system
such that they are essentially inaccessible.
Because these attacks require no reply from the target system and
require no legitimate transaction state, attackers often attempt to
obfuscate the identity of the systems that are generating the attack
traffic by spoofing the source IP address of the attacking traffic
flows. Because ingress filtering isn't applied ubiquitously on the
Internet today, spoof-based flooding attack vectors are typically
very difficult to traceback. In particular, there may be one or more
attacking sources beyond your network border, and the attacking
sources may or may not be legitimate sources, it's difficult to
determine if the sources are not directly connected to the local
routing system. These attacks might be seen as primarily to be
addressed by BCP 38 deployment, which would not be in scope for this
document. However, as noted earlier, deployment of SAVI can help
remediate lack of BCP 38, and even when BCP 38 is deployed can help
provide useful information for responding to such attacks.
Common flood-based DoS attack vectors today include SYN floods, ICMP
floods, and IP fragmentation attacks. Attackers may use a single
legitimate or spoofed fixed attacking source address, although
frequently they cycle through large swaths of address space. As a
result, mitigating these attacks on the receiving end with source-
based policies is extremely difficult.
If an attacker can inject messages for a protocol which requires
McPherson, et al. Expires September 3, 2011 [Page 7]
Internet-Draft SAVI Threat Scope March 2011
control plane activity, it may be possible to deny network control
services at a much lower attack level. While there are various forms
of protection deployed against this, they are by no means complete.
Attacks which are harder to trace (such as with spoofed addresses)
are of course of more concern.
Furthermore, the motivator for spoof-based DoS attacks may actually
be to encourage the target to filter explicitly on a given set of
source addresses, or order to disrupt the legitimate owner(s) access
to the target system.
3.1.3. Poisoning Attacks
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
the target will accept the incorrect information. In general, this
can be used to perform broadly the same kinds of poisonings as above,
with more versatility.
One important class of poisoning attacks are attacks aimed at
poisoning network or DNS cache information, perhaps to simply break a
given host's connection, enable MITM or other attacks. Network level
attacks that could involve single packet DoS include ARP cache
poisoning and ICMP redirects. The most obvious example which depends
upon falsifying an IP source address is an on-link attacker poisoning
a router's ARP or ND cache. The ability to forge a source address
can also be helpful in causing a DNS cache to accept and use
incorrect information.
3.1.4. Spoof-based Worm/Malware Propagation
Self-propagating malware has been observed that spoofs its source
address when attempting to propagate to other systems. Presumably,
this was done to obfuscate the actual source address of the infected
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
track back to find infected systems.
3.1.5. Reflective Attacks
Reflective amplifications attacks, wherein a sender sends a single
packet to an intermediary, resulting in the intermediary sending a
large number of packets, or much larger packets, to the target, are a
particularly potent DoS attack vector on the Internet today. Many of
these attacks rely on using a false source address, so that the
amplifier attacks the target by responding to the messages.
DNS is one of the common targets of such attacks. The amplification
McPherson, et al. Expires September 3, 2011 [Page 8]
Internet-Draft SAVI Threat Scope March 2011
factor observed for attacks targeting DNS root and 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 512Kbps of upstream
attack bandwidth could generate one Gbps of response attack traffic
towards a target system.
Smurf attacks employ a similar reflective amplification attack
vector, exploiting traditional default IP subnet directed broadcast
address behaviors that would result in all the active hosts on a
given subnet responding to (spoofed) ICMP echo request from an
attacker, and generating a large amount of ICMP echo response traffic
directed towards a target system. They were particularly effective
in large campus LAN environments where 50k or more hosts might reside
on a single subnet.
3.1.6. Accounting Subversion
If an attacker wishes to distribute content or other material in a
manner that employs protocols that require only uni-directional
flooding and generate no end-end transactional state, they may desire
to spoof the source IP address of that content in order to avoid
detection or accounting functions enabled at the IP layer. While
this particular attack has not been observed, it is included here to
reflect the range of power that spoofed addresses may have even
without the ability to receive responses.
3.1.7. Other Blind Spoofing Attacks
Other Blind spoofing attacks might include spoofing in order to
exploit source routing or other policy based routing implemented in a
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. 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.
3.2. Non-Blind Attacks
Non-blind attacks often involve mechanisms such as eavesdropping on
connection, resetting state so that new connections may be hijacked,
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
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
uses that to launch his own attacks.
McPherson, et al. Expires September 3, 2011 [Page 9]
Internet-Draft SAVI Threat Scope March 2011
3.2.1. Man in the Middle (MITM)
Connection Hijacking is one of the more common man in the middle
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
other attacks in order to reset a transaction. The attacker may have
already compromised a system that's in the forwarding path, or they
may wish to insert themselves in the forwarding path.
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
default gateway address (or all addresses) to itself in order to
perform man-in-the-middle attacks. In order to accomplish this, in
IPv4 the attacker might transmit gratuitous ARP [RFC0826] messages or
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
target(s) now map to it's own MAC address. Similar vulnerabilities
exist in IPv6 NDP.
3.2.2. Third Party Recon
Another example of sighted attack is third party reconnaissance. The
use of spoofed addresses, while not necessary for this, can often
provide additional information, and helps mask the traceability of
the activity. The attack involves sending packets towards a given
target system and observing either target or intermediate system
responses. For example, if an attacker were to source spoof TCP SYN
packets towards a target system from a large set of source addresses,
and observe responses from that target system or some intermediate
firewall or other middle box, they would be able to identify what IP
layer filtering policies may be in place to protect that system.
4. Current Anti-Spoofing Solutions
The first requirement is to eliminate datagrams with spoofed IP
addresses from the Internet. Identifying and dropping datagrams
whose source address is incompatible with the Internet topology at
sites where the relationship between the source address and topology
can be checked can eliminate such datagrams. For example, Internet
devices can confirm that:
o The IP source address is appropriate for the lower layer address
(they both identify the same system)
o The IP source address is appropriate for the device at the layer 2
switch port (the address was assigned to a, and perhaps the,
system that uses that port)
McPherson, et al. Expires September 3, 2011 [Page 10]
Internet-Draft SAVI Threat Scope March 2011
o The prefix to which the IP source address belongs is appropriate
for the part of the network topology from which the IP datagram
was received (while the individual system may be unknown, it is
reasonable to believe that the system is located in that part of
the network).
Filtering points farther away from the source of the datagram can
make decreasingly authoritative assertions about the validity of the
source address in the datagram. Nonetheless, there is value in
dropping traffic that is clearly inappropriate, and in maintaining
knowledge of the level of trust one can place in an address.
Edge Network 1 CPE-ISP _.------------.
_.----------------. Ingress/ ISP A `--.
,--'' `---. ,' `.
,' +----+ +------+ +------+ `. / +------+ +------+ \\
( |Host+--+Switch+--+ CPE +---)-(---+ PE +- - - -+ NNI | )
`. +----+ +------+ |Router| ,' \\ |Router| |Router| /
`---. Host-neighbor +------+' `.+------+ +--+---+,'
`----------------'' '--. |_.-'
`------------'|
|
Edge Network 2 ISP-ISP Ingress |
_.----------------. _.----------.|
,--'' `---. ,-'' |--.
,' +----+ +------+ +------+ `. ,+------+ +--+---+.
( |Host+--+Switch+--+ CPE +---)---+-+ PE +- - - -+ NNI | \\
`. +----+ +------+ |Router| ,' ( |Router| |Router| )
`---. +------+' \\ +------+ +------+ /
`----------------'' `. ,'
'--. ISP B _.-'
`----------''
Figure 1: Points where an address can be validated
Figure 1 illustrates five related paths where a source address can be
validated:
o host to switch, including host to host via the switch
o Host to enterprise CPE Router
o Enterprise CPE Router to ISP edge PE Router, and the reverse
o ISP NNI Router to ISP NNI Router
In general, datagrams with spoofed IP addresses can be detected and
discarded by devices that have an authoritative mapping between IP
McPherson, et al. Expires September 3, 2011 [Page 11]
Internet-Draft SAVI Threat Scope March 2011
addresses and the network topology. For example, a device that has
an authoritative table between Link Layer and IP addresses on a link
can discard any datagrams in which the IP address is not associated
with the Link Layer address in the datagram. The degree of
confidence in the source address depends on where the spoofing
detection is performed and the prefix aggregation in place between
the spoofing detection and the source of the datagram.
4.1. Topological Locations for Enforcement
There are a number of kinds of places, which one might call
topological locations, where solutions may or should be deployed.
4.1.1. Host to link layer neighbor via switch
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
connected. At this point in the network, the source Link Layer and
IP addresses are both available, and can be verified against each
other. A datagram in which the IP source address does not match the
corresponding Link Layer address can be discarded. Of course, the
trust in the filtering depends on the trust in the method through
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
the most precise information for this.
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
the mappings. When the link is not shared, such as when the hosts
are connected through a switch, the source host can be identified
precisely based on the port through which the datagram is received or
the MAC address if it is known to the switch. Port identification
prevents transmission of malicious datagrams whose Link Layer and IP
addresses are both spoofed to mimic another host.
Other kinds of links may fall at different places in this spectrum,
with some wireless links having easier ways of identifying individual
devices than others, for example.
4.1.2. Upstream routers
Beyond the first hop router, subsequent routers may additionally
filter traffic from downstream networks. Because these routers do
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
IP address is within a prefix that is appropriate for downstream
router from which the datagram was received.
McPherson, et al. Expires September 3, 2011 [Page 12]
Internet-Draft SAVI Threat Scope March 2011
Options include the use of simple access lists or the use of unicast
reverse path filtering (uRPF). Access lists are generally
appropriate only for the simplest cases, as management can be
difficult. Strict Unicast RPF accepts the source address on a
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
the filter is derived from routing information. These filtering
procedures are discussed in more detail in [RFC3704].
4.1.3. ISP Edge 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
encourages ISPs to use ingress filtering to limit the incidence of
spoofed addresses in the network.
The question that the ISP must answer for itself is the degree to
which it trusts its downstream network. A contract might be written
between an ISP and its customer requiring that the customer apply the
procedures of network ingress filtering to the customer's own
network, although there's no way upstream networks would be able to
verify this.
Conversely, if the provider has assigned a single IP address to the
customer (for example, with IPv4 NAT in the CPE) PE enforcement of
BCP 38 can be on the full address, simplifying many issues.
4.1.4. ISP NNI Router to ISP NNI Router
The considerations explicitly related to customer networks can also
be applied to neighboring ISPs. An interconnection agreement might
be written between two companies requiring network ingress filtering
policy be implemented on all customers connections. ISPs might, for
example, mark datagrams from neighboring ISPs that do not sign such a
contract or demonstrably do not behave in accordance with it as
'untrusted'. Alternatively, the ISP might place untrusted prefixes
into a separate BGP community and use that to advertise the level of
trust to its BGP peers.
In this case, uRPF is less effective as a verification tool, due to
asymmetric routing. However, when it can be shown that spoofed
addresses are present, the procedure can be applied.
Part of the complication here is that in the abstract it is very
difficult to know what addresses should appear in packets sent from
one ISP to another. Hence packet level filtering and enforcement is
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
McPherson, et al. Expires September 3, 2011 [Page 13]
Internet-Draft SAVI Threat Scope March 2011
still a major factor that needs to be taken into account.
4.1.5. Cable Modem Subscriber Access
Cable Modem Termination Systems (CMTS) employ DOCSIS Media Access
Control (MAC) domains. These share some properties with general
switched networks, as described above in Section 4.1.1, some
properties with DSL access networks, as described below in
Section 4.1.6. They also often have their own provisioning and
monitoring tools which may address some of the issues described here.
4.1.6. DSL Subscriber Access
While DSL subscriber access can be bridged or routed, as seen by the
service provider's device, it is generally the case that the
protocols carry enough information to verify which subscriber is
sending packets. Thus, for ensuring that one DSL subscriber does not
spoof another, enforcement can generally be done at the aggregation
router. This is true even when there is a bridged infrastructure
among the subscribers, as DSL access generally requires all
subscriber traffic to go through the access aggregation router.
If it is desirable to provide spoofing protection among the devices
within a residence, that would need to be provided by the CPE device,
as the ISPs router does not have enough visibility to do that. It is
not clear at this time that this problem is seen as a relevant
threat.
4.2. Currently Available Tools
There are a number of tools which have been developed, and have seen
some deployment, for addressing these attacks.
4.2.1. BCP 38
If BCP 38 [RFC2827] is implemented in LAN segments, it is typically
done so on subnetwork boundaries and traditionally relates only to
Network Layer ingress filtering policies. The result is that hosts
within the segment cannot spoof packets from address space outside of
the local segment itself, however, they may still spoof packets using
sources addresses that exist within the local network segment.
4.2.2. Unicast RPF
Unicast RPF is a crude mechanism to automate definition of BCP 38
style filters based on routing table information. Its applicability
parallels that of BCP 38, although deployment caveats exist, as
outlined in [RFC3704].
McPherson, et al. Expires September 3, 2011 [Page 14]
Internet-Draft SAVI Threat Scope March 2011
4.2.3. Port-based Address Binding
Much of the work of SAVI is initially targeting minimizing source
address spoofing in the LAN. In particular, if mechanisms can be
defined to accommodate configuration of port binding information for
IP, either to a port, to an unforgeable MAC address, or to other
unforgeable credentials in the packet, a large portion of the
spoofing threat space in the LAN can be marginalized.
However, establishing this binding is not trivial, and varying across
both topologies type and address allocation mechanisms.
4.2.3.1. Manual Binding
Binding of a single Link Layer and Network Layer address to a port
may initially seem trivial. However, two primary areas exist that
can complicate such techniques. In particular, these areas involve
topologies where more than a single IP layer address may be
associated with a MAC address on a given port, or where multiple
hosts are connected via a single physical port. Furthermore, if one
or more dynamic address allocation mechanisms such as DHCP are
employed, then some mechanism must exist to associate those IP layer
addresses with the appropriate Link layer ports, as addresses are
allocated or reclaimed.
4.2.3.2. Automated Binding
For IPv4 the primary and very widely used automated address
assignment technique is DHCP based address assignment. Controlling
where authoritative information can be sourced, coupled with sniffing
and enforcing the assignments is an effective technique, which can in
many networks automatically provide sufficient binding information.
For IPv6, there are two common automated address assignment
techniques. While there are many variations and details, for
purposes of understanding the threats and basic responses, these are
Stateless Address AutoConfiguration (SLAAC) and DHCPv6 based address
assignment. In both cases, SAVI binding establishment needs to be
tied to the state machines for these address assignment protocols,
with appropriate message sniffing and enforcement. For DHCPv6 based
techniques, it is also necessary to use classification techniques to
ensure that responses which are trusted actually come from
authoritative sources.
4.2.3.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
McPherson, et al. Expires September 3, 2011 [Page 15]
Internet-Draft SAVI Threat Scope March 2011
authorization rules to permit or deny the action. In and of
themselves, such tools confirm only that the user is authorized to
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
be useful as binding anchors for SAVI solutions.
4.2.4. Cryptographic Techniques
Needless to say, MITM and replay attacks can typically be mitigated
with cryptographic techniques. However, many of the applications
today either don't or can't employ cryptographic authentication and
protection mechanisms. ARP for IPv4 does not use such protection.
While SEND provides such protection for IPv6 ND, SEND is not widely
used to date.
While DNSSEC will significantly help protect DNS from the effects of
spoof based poisoning attacks, such protection does not help protect
the rest of the network from spoofed attacks.
4.2.5. Residual Attacks
It should be understood that not all combinations of network, service
and enforcement choices will result in a protectable network. For
example, if one uses conventional SLAAC, in a switched network, but
tries to only provide address enforcement on the routers on the
network, then the ability to provide protection is severely limited.
5. Topological Challenges Facing SAVI
As noted previously, topological components and address allocation
mechanisms have significant implications on what is feasible with
regard to Link layer address and IP address port bindings. The
following sections discuss some of the various topologies and address
allocation mechanisms that proposed SAVI solutions should attempt to
address.
5.1. Address Provisioning Mechanisms
In a strictly static environment, configuration management for access
filters that map Link Layer and Network Layer addresses on a specific
switch port might be a viable option. However, most networks,
certainly those that accommodate actual human users, are much more
dynamic in nature. As such, mechanisms that provide port-MAC-IP
bindings need to accommodate dynamic address allocation schemes
enabled by protocols such as DHCP, DHCPv6 for address allocation, and
IPv6 Stateless Address Autoconfiguration.
McPherson, et al. Expires September 3, 2011 [Page 16]
Internet-Draft SAVI Threat Scope March 2011
5.2. LAN devices with Multiple Addresses
From a topology considerations perspective, when attempting
port-MAC-IP bindings, hosts connected to switch ports that may have
one or more IP addresses, or certainly, devices that forward packets
from other network segments, present traffic that is much harder to
make subject to such bindings and enforcement.
5.2.1. Routers
The most obvious example of devices that are problematic when
attempting to implement port-MAC-IP bindings is that of routers.
Routers not only originate packets themselves and often have multiple
interfaces, but also forward packets from other network segments. As
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
subnets should be associated with the port-MAC in question.
5.2.2. NATs
Validating traffic from Prefix-based and multi-address NATs also
becomes problematic, for the same reasons as routers. Because they
may forward traffic from an array of address, a priori knowledge must
exist providing what IPs should be associated with a given port-MAC
pair.
5.2.3. Multi-Instance Hosts
Another example that introduces complexities is that of multi-
instance hosts attached to a switch port. These are single physical
devices, which internally run multiple physical or logical hosts.
When the device is a blade server, e.g. with internal blades each
hosting a physical machine, there is essentially a physical switch
inside the blade server. While tractable, this creates some
complexity for determining where enforcement logic can or should
live.
Logically distinct hosts such as are provided by many varieties of
virtualization logic result in a single physical host, connect to a
single port on the Ethernet switch in the topology, actually having
multiple internal virtual machines, each with IP and MAC addresses,
and what is essentially (or sometimes literally) an internal LAN
switch. While it may be possible for this internal switch to help
control threats among the virtual hosts, or between virtual hosts and
other parts of the network, such enforcement cannot be counted on at
this time.
McPherson, et al. Expires September 3, 2011 [Page 17]
Internet-Draft SAVI Threat Scope March 2011
5.2.4. Multi-LAN Hosts
Multi-interface hosts, in particular those that are multi-homed and
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
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
forwarded through an interface for which the port-MAC-IP binding
doesn't map, the traffic may be discarded. Static configuration of
port-MAC-IP bindings may accommodate this scenario, although some a
priori knowledge on address assignment and topology is required.
While the use of loopback addressing or sending packets out one
interface with the source address from another are rare, they do
legitimately occur. Some servers, particularly ones that have
underlying virtualization, use loopback techniques for management.
5.2.5. Firewalls
Firewalls that forward packets from other network segments, or serve
as a source for locally originated packets, suffer from the same
issues as routers.
5.2.6. Mobile IP
Mobile IP hosts in both IPv4 and IPv6 are 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. Thus, they
do not introduce any additional complications. (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
Any topology that results in the possibility that a device connected
to a switch port may forward packets with more than a single source
McPherson, et al. Expires September 3, 2011 [Page 18]
Internet-Draft SAVI Threat Scope March 2011
address for packet which it originated may be problematic.
Additionally, address allocation schemas introduce additional
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 IID, 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 IID 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 idiosyncrasies of the duplicate
address procedure. Like many behaviors, this is a feature for some
purposes, and a problem for others. For example, without claiming
the entire ID space, an on-link attacker may be able to generate
enough IP addresses to fill the Neighbor Discovery table space of the
other L3 devices on the link, including switches which are monitoring
L3 behavior. This could seriously interfere with the ability for
other devices on the link to function.
6. Analysis of Host Granularity Anti-Spoofing
Applying anti-spoofing techniques at the host level enables a site to
achieve several valuable objectives. While it is likely the case
that for many site topologies and policies, full source spoofing
protection is not possible, it is also true that for many sites there
are steps that can be taken that provide benefit.
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.
A second class of benefit is related to the traceability described
above. When a security incident is detected, either within a site,
McPherson, et al. Expires September 3, 2011 [Page 19]
Internet-Draft SAVI Threat Scope March 2011
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.
In addition to these local observable benefits, there can be more
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
anonymous IPv6 addresses for attacks, or at least to track even those
attacks back to their source.
7. 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 authors' perspective, it may
therefore be removed upon publication as an RFC at the RFC Editor's
discretion.
8. Security Considerations
This document provides limited discussion of some security threats
source address validation improvements will help to mitigate. It is
not meant to be all-inclusive, either from a threat analysis
perspective, or from the source address verification application
side.
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
end system, that originated it. For several reasons, the technology
can be used to derive circumstantial evidence, but does not actually
solve that problem.
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
expected to come. But systems fall into several broad categories.
Many are single user systems, such as laptops and PDAs. Multi-user
systems are commonly used in industry, and a wide variety of
middleware systems and application servers have no user at all, but
by design relay messages or perform services on behalf of users of
other systems (e.g., SMTP and peer-to-peer file sharing).
Until every Internet-connected network implements source address
McPherson, et al. Expires September 3, 2011 [Page 20]
Internet-Draft SAVI Threat Scope March 2011
validation at the ultimate network ingress, and assurances exist that
intermediate devices are to never modify datagram source addresses,
source addresses must not be used as an authentication mechanism.
The only technique to unquestionably verify source addresses of a
received datagram are cryptographic authentication mechanisms such as
IPsec.
9. Acknowledgments
A portion of the primer text in this document came directly from
[I-D.baker-sava-operational], authored by Fred Baker and Ralph Droms.
Many thanks to Christian Vogt, Suresh Bhogavilli, and Pekka Savola
for contributing text and a careful review of this document.
10. References
10.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
10.2. Informative References
[I-D.baker-sava-operational]
Baker, F. and R. Droms, "IPv4/IPv6 Source Address
Verification", draft-baker-sava-operational-00 (work in
progress), June 2007.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
McPherson, et al. Expires September 3, 2011 [Page 21]
Internet-Draft SAVI Threat Scope March 2011
Authors' Addresses
Danny McPherson
VeriSign, Inc.
Email: dmcpherson@verisign.com
Fred Baker
Cisco Systems
Email: fred@cisco.com
Joel M. Halpern
Ericsson
Email: joel.halpern@ericsson.com
McPherson, et al. Expires September 3, 2011 [Page 22]
