INTERNET-DRAFT Danny McPherson
Arbor Networks
Fred Baker
Cisco Systems
Expires: July 2009 January 21, 2009
Intended Status: Informational
SAVI Threat Scope
<draft-ietf-savi-threat-scope-00.txt>
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (c) 2009 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
McPherson, et al. [Page 1]
INTERNET-DRAFT Expires: July 2009 January 2009
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
This memo discusses threats enabled by IP source address spoofing and
discusses a number of techniques aimed at mitigating those threats.
McPherson, et al. [Page 2]
INTERNET-DRAFT Expires: July 2009 January 2009
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Glossary of Terms. . . . . . . . . . . . . . . . . . . . . . . 6
3. Spoofed-based Attack Vectors . . . . . . . . . . . . . . . . . 6
3.1. Blind Attacks . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Single Packet DoS. . . . . . . . . . . . . . . . . . . . 7
3.1.2. Flood-Based DoS. . . . . . . . . . . . . . . . . . . . . 7
3.1.3. Poisoning Attacks. . . . . . . . . . . . . . . . . . . . 8
3.1.4. Third Party Recon. . . . . . . . . . . . . . . . . . . . 9
3.1.5. Spoof-based Worm/Malware Propagation . . . . . . . . . . 9
3.1.6. Reflective Attacks . . . . . . . . . . . . . . . . . . . 9
3.1.7. Accounting Subversion. . . . . . . . . . . . . . . . . . 10
3.1.8. Other Blind Spoofing Attacks . . . . . . . . . . . . . . 10
3.2. Non-Blind Attacks . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Man in the Middle (MITM) . . . . . . . . . . . . . . . . 10
3.2.2. Third Party Recon. . . . . . . . . . . . . . . . . . . . 11
4. Current Anti-Spoofing Solutions. . . . . . . . . . . . . . . . 11
4.1. Host to link layer neighbor or switch . . . . . . . . . . . 13
4.2. Upstream routers. . . . . . . . . . . . . . . . . . . . . . 13
4.3. ISP Edge PE Router. . . . . . . . . . . . . . . . . . . . . 14
4.4. ISP NNI Router to ISP NNI Router. . . . . . . . . . . . . . 14
4.5. Spoofing In Local Area Network Segments . . . . . . . . . . 14
4.6. Cable Modem Subscriber Access . . . . . . . . . . . . . . . 15
4.7. DSL Subscriber Access . . . . . . . . . . . . . . . . . . . 15
4.8. BCP 38. . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.9. Unicast RPF . . . . . . . . . . . . . . . . . . . . . . . . 15
4.10. Port-based Address Binding . . . . . . . . . . . . . . . . 15
4.10.1. Manual Binding. . . . . . . . . . . . . . . . . . . . . 16
4.10.2. Automated Binding . . . . . . . . . . . . . . . . . . . 16
4.10.3. IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . . 16
4.11. Cryptographic Techniques . . . . . . . . . . . . . . . . . 16
4.12. Residual Attacks . . . . . . . . . . . . . . . . . . . . . 17
5. Topological Considerations . . . . . . . . . . . . . . . . . . 17
5.1. Address Provisioning Mechanisms . . . . . . . . . . . . . . 17
5.2. LAN devices with Multiple Addresses . . . . . . . . . . . . 17
5.2.1. Routers. . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.3. Multi-Instance Hosts . . . . . . . . . . . . . . . . . . 18
5.2.4. Multi-LAN Hosts. . . . . . . . . . . . . . . . . . . . . 18
5.2.5. Firewalls. . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.6. Mobile IP. . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . . . 19
6. Applicability of Anti-Spoofing Solutions . . . . . . . . . . . 19
6.1. Analysis of Host Granularity Anti-Spoofing. . . . . . . . . 19
7. Existing Techniques for IP Source Address Valida-
McPherson, et al. [Page 3]
INTERNET-DRAFT Expires: July 2009 January 2009
tion" 20 771. . . . . . . . . . . . . . . . . . . . . . . . . . .
8. Deployment Considerations. . . . . . . . . . . . . . . . . . . 21
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . . 24
13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 25
McPherson, et al. [Page 4]
INTERNET-DRAFT Expires: July 2009 January 2009
1. Overview
The Internet Protocol, specifically IPv4 [RFC791] 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 on 32-bit prefix boundaries at the
ultimate ingress point of the IP network then the validity of the
source address can not 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.
There is a possibility that in an LAN environment where multiple
hosts share a single IP port on a switch or router, one of those
hosts may source address spoof the source addresses of other hosts
within the local subnet. Understanding these threats and the
relevant topologies in which they're introduced is critical when
assessing the threats that exists with source address spoofing.
The aim of this document is to provide some additional details
regarding spoofed-based threat vectors, and discuss implications of
various network topologies.
McPherson, et al. Section 1. [Page 5]
INTERNET-DRAFT Expires: July 2009 January 2009
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 Endpoint, 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.
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 Endpoint Router. This router faces a customer
of an ISP.
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
McPherson, et al. Section 3. [Page 6]
INTERNET-DRAFT Expires: July 2009 January 2009
attack vectors exists; blind attacks and non-blind attacks. The
follow 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 DoS
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 such 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 forwarding a packet (e.g., TCP SYN) to a target system that
contains both a source and destination address of that target system.
The target system would "lock up" when creating connection state
associated with the packet, or would get stuck in a state where it
continuously replies to itself.
Another example of a single packet DoS attack involves that of a
system poisoning network or DNS cache information, perhaps in order
to simply break a given hosts connection, enable MITM or other
attacks. Network level attacks that could involve single packet DoS
include ARP cache poisoning and ICMP redirects.
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
McPherson, et al. Section 3.1.2. [Page 7]
INTERNET-DRAFT Expires: July 2009 January 2009
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
discriminate if the sources are not directly connected to the local
routing system.
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 addresses, 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.
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
As discussed in single-packet DoS above, there are several other
attack mechanisms that employ source address spoofing. The more
common of these attack vectors include DNS cache poisoning, ARP cache
poisoning, and ICMP redirects. While these attacks can be used for
disrupting services, they're often used to redirect traffic to
network elements where attack intends to carry out additional
malicious activities.
McPherson, et al. Section 3.1.3. [Page 8]
INTERNET-DRAFT Expires: July 2009 January 2009
3.1.4. Third Party Recon
Third party reconnaissance attacks may be either blind or non-blind
attacks. An example of third party reconnaissance is when an
attacker wishes to fingerprint a remote operating system type,
perhaps in order to initiate some TCP session hijacking, and in order
to do so must be able to identify the TCP sequence and algorithm
employed by the target system. Initiating a determined number of
connections with the target system may assist with this.
3.1.5. Spoof-based Worm/Malware Propagation
Self-propagating malware has been observed that spoofs it's source
address when attempting to propagate to other systems. Presumably,
this was done to obfuscate the actual source address of the infected
system.
3.1.6. Reflective Attacks
DNS reflective amplification attacks are a particularly potent DoS
attack vector on the Internet today. Like other amplification
attacks, an attack source generates a packet with a source-spoofed
address mapping to that of the target system. The packet, upon
receipt by the victim or some intermediate node, typically illicts a
large reply message, which is directed to the target of the attack.
The amplification 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
512k 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.
McPherson, et al. Section 3.1.6. [Page 9]
INTERNET-DRAFT Expires: July 2009 January 2009
3.1.7. 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.
3.1.8. 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.
3.2. Non-Blind Attacks
Non-blind attacks often involve mechansisms such as eavesdropping on
connection, resetting state so that new connections may be hijacking,
and an array of other attack vectors. Perhaps the most common of
these attack vectors is known as man in the middle attacks.
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 which 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 the
attacker might transmit gratuitous ARP [RFC826] 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. If the port to which the
McPherson, et al. Section 3.2.1. [Page 10]
INTERNET-DRAFT Expires: July 2009 January 2009
attacker is connected were to implement policy that binds a single
Link Layer and IP address tuple to that port upon initial
provisioning, spoofed packets, at the Link Layer and/or Network
Layer, would be discarded on ingress.
3.2.2. Third Party Recon
Another example of third party reconnaissance that falls into both
the blind and non-blind attack class involves spoofing 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
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)
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
McPherson, et al. Section 4. [Page 11]
INTERNET-DRAFT Expires: July 2009 January 2009
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 places where a source address can be
validated:
o Host to host or host to switch,
o Host to enterprise CPE Router,
o Enterprise CPE Router to ISP edge PE Router,
o ISP NNI Router to ISP NNI Router, and the
o ISP edge PE Router facing the destination CPE Router.
In general, datagrams with spoofed addresses can be detected and
discarded by devices that have an authoritative mapping between IP
addresses and the network topology. For example, a device that has
McPherson, et al. Section 4. [Page 12]
INTERNET-DRAFT Expires: July 2009 January 2009
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. Host to link layer neighbor or 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
neighboring hosts, or by the first hop router.
On a shared medium link, such as 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.
4.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.
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
McPherson, et al. Section 4.2. [Page 13]
INTERNET-DRAFT Expires: July 2009 January 2009
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.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.
4.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.
4.5. Spoofing In Local Area Network Segments
On Link Layer segments where multiple hosts reside, or a single MAC
address can be associated with a port or interface, if a binding
between a hardware address (e.g., MAC address) and corresponding IP
McPherson, et al. Section 4.5. [Page 14]
INTERNET-DRAFT Expires: July 2009 January 2009
address(es) are not provisioned via some means (either manual or
dynamic mechanisms), then an attacker may exploit attack vectors that
enable MITM or other spoof-based attacks.
4.6. Cable Modem Subscriber Access
Cable Modem Termination Systems (CMTS) employ DOCSIS Media Access
Control (MAC) domains, which are similar to Ethernet LAN
environments.
4.7. DSL Subscriber Access
Something about DSLAMs here..
4.8. BCP 38
If BCP 38 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.9. Unicast RPF
Unicast RPF is a crude mechanism to automate definition of BCP 38
style filters based on routing table information. It's applicability
parallels that of BCP 38, although deployment caveats exists, as
outlined in [RFC3704].
4.10. Port-based Address Binding
Much of the work SAVI appears to be initially targeting is aimed at
McPherson, et al. Section 4.10. [Page 15]
INTERNET-DRAFT Expires: July 2009 January 2009
minimizing source address spoofing in the LAN. In particular, if
mechanisms can be defined to accommodate configuration of port
binding information for IP and MAC layer addresses in LAN
environments, a large portion of the spoofing threat space in the LAN
can be marginalized.
However, establishing these binding is not trivial, and varying
across both topologies type and address allocation mechanisms.
4.10.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 area involves
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 to a single IP 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.10.2. Automated Binding
DHCP, RADIUS, Other solutions, Cisco IP Source Guard, etc..
4.10.3. IEEE 802.1X
4.11. 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 and DNS are two examples. DNSSEC does
propose to assist, but until it's deployed ubiquitously, from
clients, to resolvers, to authoritative roots, clients and resolvers
McPherson, et al. Section 4.11. [Page 16]
INTERNET-DRAFT Expires: July 2009 January 2009
are still vulnerable to replay, cache poisoning and MITM attacks.
4.12. Residual Attacks
Stuff which these solutions don't address
Stuff which no one will use the existing solutions for
5. Topological Considerations
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.
5.2. LAN devices with Multiple Addresses
From a topology considerations perspective, when attempting port-MAC-
IP bindings, host connected to switch ports that may have one or more
IP addresses, or certainly, devices that forward packets from other
network segments, are problematic.
McPherson, et al. Section 5.2. [Page 17]
INTERNET-DRAFT Expires: July 2009 January 2009
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
Prefix-based and multi-address NATs also become 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. Multi clients, with the
same or different MACs, may be attached to the port and may either
have static IP addresses assigned, or may receive one or more
dynamically via DHCP or similar means. Accommodating multi-instance
hosts, or even blade-server type devices dynamic is feasible, buy may
introduces complexities if the solution in question does not
accommodate unique considerations introduced in these environments.
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
and forward through in 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
McPherson, et al. Section 5.2.4. [Page 18]
INTERNET-DRAFT Expires: July 2009 January 2009
priori knowledge on address assignment and topology is required.
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
Need to say something here, I think... Mobile IP
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
address for packet which it originated may be problematic.
Additionally, address allocation schemas introduce additional
considerations when examining a given SAVI solutions space.
6. Applicability of Anti-Spoofing Solutions
What works where, what's needed?
Ingress filtering is useful, even with botnets using real addresses
Ingress filtering on the admin border is not sufficient, and more
fine-grained filtering from savi is necessary.
6.1. Analysis of Host Granularity Anti-Spoofing
Most IP spoofing validation can be provided with standard IP-based
policies such as those defined in BCP 38. However, at the ultimate
McPherson, et al. Section 6.1. [Page 19]
INTERNET-DRAFT Expires: July 2009 January 2009
network ingress, the ability to perform a binding for port-MAC-IP
provides considerable benefits over vanilla prefix-based source
address validation. While it is true that a large array of
topologies and address allocation schemas will introduce complexities
with automation of port-MAC-IP binding specifications, application of
source address validation for static and common dynamic addressed
allocation environments (e.g., DHCP) would significantly raise the
bar for effectively launching spoof-based attacks.
7. Existing Techniques for IP Source Address Validation"
Existing techniques for IP source address validation are insufficient
for at least some of the following reasons:
o False negatives: Techniques may yield false negatives,
thus enabling an attacker to select an IP source address
that is spoofed, but still passes IP source address
validation.
o False positives: Techniques may yield false positives,
thereby causing interruption or denial of service to hosts
that use legitimate IP source addresses.
o Non-trivial configuration: Requirements for non-trivial
configuration imply expenditures and pose a risk for
misconfiguration, which may again lead to false positives
or false negatives. Both may discourage operators from
employing a given technique.
o Proprietary: Procurement policies oftentimes require
techniques that are standardized, hence hindering or
preventing the deployment of proprietary techniques.
The only standardized technique for IP source address validation is
ingress filtering [RFC2827]. This calls for routers to check whether
the prefix of a to-be-forwarded packet's IP source address is amongst
a list of prefixes considered legitimate for the interface through
which the packet arrives. Packets that fail this check are
discarded.
Ingress filtering may yield false negatives in a deterministic
manner. Packets with a legitimate IP source address prefix, but a
spoofed interface identifier, pass ingress filtering checks. Also,
packets with an illegitimate IP source address prefix pass the checks
as long as the prefix is from the list of prefixes considered
McPherson, et al. Section 7. [Page 20]
INTERNET-DRAFT Expires: July 2009 January 2009
legitimate, if more than one prefix is considered as legitimate on
the ingress interface..
Ingress filtering implementations that require manual establishment
of the list of legitimate prefixes cause considerable configuration
overhead. Unicast Reverse Path Forwarding (uRPF) mitigates this
issue by automatically deriving the list of legitimate prefixes from
a router's forwarding table: A to-be-forwarded packet's IP source
address prefix is considered legitimate if the packet is coming
through an interface via which return traffic would be routed. On
the other hand, Unicast Reverse Path Forwarding may yield false
positives, in particular for hosts and networks with multiple,
topologically separate Internet attachments [RFC3704].
Consequently, there is a need for an IP source address validation
technique that avoids false negatives and false positives, that can
be set up with no or only trivial configuration, and that has been
standardized. The development of such a technique is the goal of the
proposed Source Address Validation Improvements (SAVI) working group
in the Internet Engineering Task Force.
8. Deployment Considerations
From a global Internet perspective, deployment of anti- spoofing
techniques tends to suffer from a "tragedy of the commons" situation.
That is, there is a general consensus that everyone should implement
anti-spoofing measures, yet individual organizations don't want to
bear the cost of deployment themselves, often because demonstrating
direct tangible return on investment is not possible. Upon analysis,
it often seems apparent that local implementation of anti-spoofing
measures is of more benefit to the "greater Internet" than the local
network domain itself. A similar situation occurs with de-
aggregation of Internet routing information for multi-homing and
traffic engineering purposes, as well as the lack of explicit inter-
domain routing prefix filters on the Internet.
Until network operators begin to accept that their local design
choices have global implications, and act upon this responsibility,
the problem is not going to go away.
Ideally, with additional work in the areas of SAVI to ease deployment
and management burdens, the deployment cost to operators will
decrease and more wide-scale deployment will continue. Furthermore,
application of SAVI-like techniques provides more obvious benefits to
network administrators that are concerned with MITM and similar
McPherson, et al. Section 8. [Page 21]
INTERNET-DRAFT Expires: July 2009 January 2009
attacks.
9. 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
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.
10. IANA Considerations
This document introduces no IANA considerations.
McPherson, et al. Section 10. [Page 22]
INTERNET-DRAFT Expires: July 2009 January 2009
11. Acknowledgments
A portion of the primer text in this document came directly from
[savi-operational], authored by Fred Back and Ralph Droms. Many
thanks to Christian Vogt for contributing text and a careful review
of this document.
McPherson, et al. Section 11. [Page 23]
INTERNET-DRAFT Expires: July 2009 January 2009
12. References
12.1. Normative References
12.2. Informative References
http://tools.ietf.org/html/draft-baker-sava-cisco-ip-source-guard
"Cisco IP Version 4 Source Guard", Fred Baker, 7-Nov-07,
<draft-baker-sava-cisco-ip-source-guard-00.txt>
http://tools.ietf.org/html/draft-baker-sava-implementation
"Source address validation in the local environment", Fred Baker,
8-Nov-07,
<draft-baker-sava-implementation-00.txt>
http://tools.ietf.org/html/draft-baker-sava-operational
"IPv4/IPv6 Source Address Verification", Fred Baker, Ralph Droms,
19-Jun-07,
<draft-baker-sava-operational-00.txt>
http://tools.ietf.org/html/draft-baker-6man-multiprefix-default-route
"Multiprefix IPv6 Routing for Ingress Filters", Fred Baker,
7-Nov-07,
<draft-baker-6man-multiprefix-default-route-00.txt>
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC826] 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.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
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
McPherson, et al. Section 12.2. [Page 24]
INTERNET-DRAFT Expires: July 2009 January 2009
Networks", BCP 84, RFC 3704, March 2004.
13. Authors' Addresses
Danny McPherson
Arbor Networks, Inc.
Email: danny@arbor.net
Fred Baker
Cisco Systems
Email: fred@cisco.com
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
McPherson, et al. Section 13. [Page 25]
