One document matched: draft-ietf-savi-threat-scope-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="info" docName="draft-ietf-savi-threat-scope-02"
ipr="trust200902">
<front>
<title abbrev="">SAVI Threat Scope</title>
<author fullname="Danny McPherson" initials="D." surname="McPherson">
<organization>Verisign, Inc.</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<region></region>
<country></country>
</postal>
<email>dmcpherson@verisign.com</email>
</address>
</author>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<region></region>
<country></country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<author fullname="Joel M. Halpern" initials="J.M." surname="Halpern">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<region></region>
<country></country>
</postal>
<email>joel.halpern@ericsson.com</email>
</address>
</author>
<date year="2010" />
<area>Internet Area</area>
<workgroup>SAVI</workgroup>
<abstract>
<t>This memo discusses threats enabled by IP source address spoofing and
discusses a number of techniques aimed at mitigating those threats.</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<!--
<note title="Requirements">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</note>
-->
<!--
<?rfc needLines="10" ?>
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section anchor="intro" title="Overview">
<t>The Internet Protocol, specifically <xref
target="RFC0791">IPv4</xref> and <xref target="RFC2460">IPv6</xref>,
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.</t>
<t>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.</t>
<t>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.</t>
<t>Solutions such as <xref target="RFC2827">BCP 38</xref> 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 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. One of the difficulties in encouraging
the deployment of BCP 38 is that there is relatively little benefit
until it is very widely deployed, which is not yet the case. The local
application of the principle of BCP 38 fortunately has local benefit,
even before BCP 38 is fully deployed. It also helps get the Internet
towards a state where BCP 38 is more widely followed.</t>
<t>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
tracability. This allows the enterprise to be a better Internet participant,
and to quickly detect and remedy problems when they occur.</t>
<t>Also, there is a possibility that in a LAN environment where multiple hosts
share a single LAN or IP port on a switch or router, one of those hosts
may spoof the source addresses of other hosts within the local subnet.
Understanding these threats and the relevant topologies in which they're
introduced is critical when assessing the threats that exists with
source address spoofing.</t>
<t>The aim of this document is to provide some additional details
regarding spoofed-based threat vectors, and discuss implications of
various network topologies.</t>
</section>
<section anchor="glossary" title="Glossary of Terms">
<t>The following acronyms and terms are used throughout this memo.<list
style="hanging">
<t hangText="BGP:">The Border Gateway Protocol, used to manage
routing policy between large networks.</t>
<t hangText="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.</t>
<t hangText="IP Address:">An Internet Protocol Address, whether IPv4
or IPv6.</t>
<t hangText="ISP:">Internet Service Provider. Any person or company
that delivers Internet service to another.</t>
<t hangText="MAC Address:">An Ethernet Address or comparable IEEE
802 series address.</t>
<t hangText="NNI Router:">Network to Network Interface Router. This
router interface faces a similar system operated by another ISP or
other large network.</t>
<t hangText="PE Router:">Provider Endpoint Router. This router faces
a customer of an ISP.</t>
<t hangText="Spoofing:">The act of forging datagram header contents
at the Link or Network Layer</t>
<t hangText="TCP:">The Transmission Control Protocol, used on end
systems to manage data exchange.</t>
<t hangText="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.</t>
</list></t>
</section>
<section anchor="attacks" title="Spoofed-based Attack Vectors">
<t>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 exists; blind attacks and non-blind attacks. The follow sections
provide some information of blind and non-blind attacks.</t>
<section anchor="blind" title="Blind Attacks">
<t>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.</t>
<section anchor="spdos" title="Single Packet Attacks">
<t>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.</t>
<t>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.</t>
<t>Another class of a single packet attacks involves an attacker
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. The most obvious
example which depends upon faslifying an IP source address is an
on-link attacker poisoning a routers ARP or ND cache. The ability
to forge a source address can also be helpful in causing a DNS
cache to accept and use incorrect information.</t>
</section>
<section anchor="flood-dos" title="Flood-Based DoS">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="poison-dos" title="Poisoning Attacks">
<t>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 poinsonings as above, with more versatility.</t>
</section>
<section anchor="propogation"
title="Spoof-based Worm/Malware Propagation">
<t>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.</t>
</section>
<section anchor="reflection" title="Reflective Attacks">
<t>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 elicits 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.</t>
<t>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.</t>
</section>
<section anchor="beancount" title="Accounting Subversion">
<t>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.</t>
</section>
<section anchor="other-blind" title="Other Blind Spoofing Attacks">
<t>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 rotuers on-link with hosts, a host may be able to cause
problems for the routing system by replaying modified or unmodified
routing packets as if they came from another router.</t>
</section>
</section>
<!-- end section 3.1 -->
<section anchor="sighted-attack" title="Non-Blind Attacks">
<t>Non-blind attacks often involve mechanisms 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.</t>
<section anchor="mitm" title="Man in the Middle (MITM)">
<t>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.</t>
<t>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 <xref
target="RFC0826"></xref> 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 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.</t>
</section>
<section anchor="sighted-recon" title="Third Party Recon">
<t>Another example of sighted attack isthird party reconnaissance.
The use of spoofed addresses, while not necessary for this, can often
provide additional information, and helps mask the tracability 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.</t>
</section>
</section>
<!-- end section 3.2 -->
</section>
<!-- end section 3 -->
<section anchor="current" title="Current Anti-Spoofing Solutions">
<t>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: <list style="symbols">
<t>The IP source address is appropriate for the lower layer address
(they both identify the same system)</t>
<t>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)</t>
<t>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).</t>
</list></t>
<t>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.</t>
<figure anchor="figure1"
title="Points where an address can be validated">
<artwork align="center"><![CDATA[
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 _.-'
`----------''
]]></artwork>
</figure>
<t><xref target="figure1"></xref> illustrates five related pathes
where a source address can be validated: <list style="symbols">
<t>host to switch, including host to host via the switch</t>
<t>Host to enterprise CPE Router,</t>
<t>Enterprise CPE Router to ISP edge PE Router, and the reverse</t>
<t>ISP NNI Router to ISP NNI Router, and the</t>
</list></t>
<t>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 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.</t>
<section anchor="host" title="Host to link layer neighbor via switch">
<t>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.</t>
<t>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.</t>
</section>
<section anchor="upstream" title="Upstream routers">
<t>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.</t>
<t>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 <xref target="RFC3704"></xref>.</t>
</section>
<section anchor="edge-pe" title="ISP Edge PE Router">
<t>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.</t>
<t>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.</t>
</section>
<section anchor="nni-nni" title="ISP NNI Router to ISP NNI Router">
<t>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.</t>
<t>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.</t>
</section>
<section anchor="lan-spoof"
title="Spoofing In Local Area Network Segments">
<t>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
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.</t>
</section>
<section anchor="cable" title="Cable Modem Subscriber Access">
<t>Cable Modem Termination Systems (CMTS) employ DOCSIS Media Access
Control (MAC) domains, which are similar to Ethernet LAN
environments.</t>
</section>
<section anchor="dsl" title="DSL Subscriber Access">
<t>While DSL subscriber access can be bridged or rotued, as seen by the
service provide3rs device, it is generally the case that the protocols
carry enough information to very which subscriber is sending packets.
Thus, for ensuring that one DSL subscriber does not spoof another,
enforcement can generally be done at the aggregation router. This is true
even when there is a bridged infrastructure among the subscribers, as DSL
access generally requires all subscriber traffic to go through the access
aggregation router.</t>
<t>If it is desirable to provide spoofing protection among the devices
within a residence, that would need to be provided by the CPE device, as
the ISPs rotuer does not have enough visiblity to do that. It is not clear
at this time that this problem is seen as a relevant threat.</t>
</section>
<section anchor="bcp38" title="BCP 38">
<t>If <xref target="RFC2827">BCP 38</xref> 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.</t>
</section>
<section anchor="urpf" title="Unicast RPF">
<t>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 <xref target="RFC3704"></xref>.</t>
</section>
<section anchor="port-binding" title="Port-based Address Binding">
<t>Much of the work SAVI appears to be initially targeting is aimed at
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.</t>
<t>However, establishing these binding is not trivial, and varying
across both topologies type and address allocation mechanisms.</t>
<section anchor="manual" title="Manual Binding">
<t>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.</t>
</section>
<section anchor="auto-bind" title="Automated Binding">
<t>For IPv4 the primary and very widely used automated binding
technique is DHCP based address assignment. Controlling where
authoratitive information can be source, coupled with sniffing
and enforcing the assignments is an effective technique.</t>
<t>For IPv6, there are two common automated address binding
techniques. While there are many variations and details, for
purposes of understanding the threats and basic responses,
these are Stateless Address AutoConfiguration (SLAAC) and DHCPv6
based address assignment. In both cases, binding establishment
needs to be tied to the state machines for these protocols, and
appropriate message sniffing and enforcement. For DHCPv6 based
techniques, it is also necessary to use classification techniques
to ensure that responses come from authoritative sources.</t>
</section>
<section anchor="802.1x" title="IEEE 802.1X">
<t>IEEE 802.1x is an authentication protocol that permits a network
to determine the identity of a system seeking to join it and apply
authorization rules to permit or deny the action.</t>
</section>
</section>
<section anchor="crypto" title="Cryptographic Techniques">
<t>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 IP v4 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 spoof
based poisoning attacks, it will probably be sufficiently long fortruly
widespread use that other protections can be usefully deployed as well.</t>
</section>
<section anchor="residual" title="Residual Attacks">
<t>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 enforment on the routers on the network, then the
ability to provide protection is severly limited.</t>
</section>
</section>
<!-- end of 4.0 -->
<section anchor="topology" title="Topological Considerations">
<t>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.</t>
<section anchor="provisioning" title="Address Provisioning Mechanisms">
<t>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.</t>
</section>
<section anchor="multi-address"
title="LAN devices with Multiple Addresses">
<t>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.</t>
<section anchor="Routers" title="Routers">
<t>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.</t>
</section>
<section anchor="nat" title="NATs">
<t>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.</t>
</section>
<section anchor="vHosts" title="Multi-Instance hosts">
<t>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, with internal blades each
hosting a 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.</t>
<t>Logically distinct hosts such as are provided by many varieties of
virtualization logic result in a single physical host, connect to
a single port on the ethernet switch in the topology, actually having
multiple internal IP and MAC addresses, and essentially an internal
switch. While it may be possible for this internal switch to help
control threats among the virtual hosts, or between virtual hosts
and other parts of the network, such enforcement can not be counted
on at this time.</t>
</section>
<section anchor="multihome" title="Multi-LAN Hosts">
<t>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 priori knowledge on address assignment and topology
is required.</t>
<t>While the use of loopback addresssing or sending packets out one
interface with the source address from another are rare, they do
legitimately occur. Some servers, particularly ones that have underlying
virtualization, use loopback techniques for management.</t>
</section>
<section anchor="firewall" title="Firewalls">
<t>Firewalls that forward packets from other network segments, or
serve as a source for locally originated packets, suffer from the
same issues as routers.</t>
</section>
<section anchor="mip" title="Mobile IP">
<t>Mobile IP hosts in both IPv4 and IPv6 as proper members of the
site where they are currently located. Their care-of-address is a
properly assigned address that is on the link they are using. And
their packets are sent and received using that address. (There was
at one time consideration of allowing mobile hosts to use their home
address when away from home. This was not done, precisely to ensure
that mobile hosts comply with source address validity requirements.)
Mobile Hosts with multiple physical interfaces fall into the cases
above.</t>
<t>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.</t>
</section>
<section anchor="other-topo" title="Other Topologies">
<t>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.</t>
</section>
</section>
<!-- end of 5.2 -->
<section anchor="ipv6" title="IPv6 Considerations">
<t>IPv6 introduces additional capabilities which indirectly complicate
the spoofing analysis. IPv6 introduces and recommends the use of
stateless address autoconfiguration (often referred to as SLAAC). This
allows hosts to determine their IP prefix, select an ID, and then
start communicating. While there are many advantages to this, the
absence of control interactions complicates the process of behavioral
enforcement.</t>
<t>An additional complication is the very large ID space. Again, this
64 bit ID space provided by IPv6 has many advantages. It provides the
opportunity for many useful behaviors. However, it also means that in
the absence of controls, hosts can mint anonymous addresses as often
as they like, modulo the idosyncrasies of the duplicate address
procedure. Like many behaviors, this is a feature for some purposes,
and a problem for others. But it does have implications for switch
cost; the switch needs to store more addresses and so needs more
memory.</t>
</section>
</section>
<!-- end of 5.0 -->
<section anchor="applicability"
title="Applicability of Anti-Spoofing Solutions">
<t>The above sections covered a number of security threats. Not all
these threats can be prevented by anti-spoofing techniques. However, all
of these threats can be ameliorated to some degree. We can look at three
categories of effect we can achieve:<list style="hanging">
<t hangText="Prevention:">Some of the threats described above
explicitly require that a host send packets using some other active
hosts IP address as a source. Anti-Spoofing measures can prevent
these attacks.</t>
<t hangText="Impediment:">Many of the attacks above, such as some
kinds of DoS attacks, can be conducted more easily if the attacking
host can use multiple different IP addresses. Depending upon the
kind of anti-spoofing available, the scope of such false addresses,
or even their use, may be prevented, hindering the attacker even if
the attack is not completely prevented.</t>
<t hangText="Traceability:">Even when attacks can not be prevented,
the ability to reliably trace an attack allows appropriate
responses, and thereby also creates an environment which discourages
attacks instead of encouraging them. Thus, ensuring that even
attacks which are not dependent upon spoofing can not use source
address spoofing to hide their origin is extremely important.</t>
</list></t>
<t>For example, sites which deploy BCP 38 can not be the source of
attacks which rely on spoofing the source site from which an attack was
launched. Wide deployment of BCP 38 would also simplify the task of
tracking attacks back to their actual origin.</t>
<section anchor="analysis"
title="Analysis of Host Granularity Anti-Spoofing">
<t>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.</t>
<t>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.</t>
<t>A second class of benefit is related to the traceability described
above. When a security incident is detect, either within a site, or
externally (and traced to the site, it can be critical to determine
what the actual source of the incident was. If address usage can be
tied to the kinds of anchors described earlier, then it is possible to
respond to security incidents.</t>
<t>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.</t>
</section>
</section>
<section anchor="existing"
title="Existing Techniques for IP Source Address Validation">
<t>Existing techniques for IP source address validation are
insufficient. While each technique has its own shortcomings, the
following list of general categories of reasons include some of the
deficiencies of all existing technique: <list style="hanging">
<t hangText="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.</t>
<t hangText="False positives:">Techniques may yield false positives,
thereby causing interruption or denial of service to hosts that use
legitimate IP source addresses.</t>
<t hangText="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.</t>
<t hangText="Proprietary:">Procurement policies oftentimes require
techniques that are standardized, hence hindering or preventing the
deployment of proprietary techniques.</t>
</list></t>
<t>The only standardized technique for IP source address validation is
ingress filtering <xref target="RFC2827"></xref>. 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.</t>
<t>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 legitimate,
if more than one prefix is considered as legitimate on the ingress
interface..</t>
<t>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
<xref target="RFC3704"></xref>.</t>
<t>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.</t>
</section>
<!-- end of existing -->
<section anchor="deploy" title="Deployment Considerations">
<t>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.</t>
<t>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.</t>
<t>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 attacks.</t>
<t>As mentioned earlier, there are local security benefits to the
deployment of SAVI security mechanisms. This may help motivate the
deployment of tools with widespread benefit.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t>
<t>Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are required,
or if those assignments or registries are created during the RFC
publication process. From the author"s perspective, it may therefore be
removed upon publication as an RFC at the RFC Editor"s discretion.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
<t>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.</t>
<t>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).</t>
<t>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.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>A portion of the primer text in this document came directly from
<xref target="I-D.baker-sava-operational"></xref>, authored by Fred
Baker and Ralph Droms. Many thanks to Christian Vogt for contributing
text and a careful review of this document.</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.0791"?>
<?rfc include="reference.RFC.2460"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.0826"?>
<?rfc include="reference.RFC.2827"?>
<?rfc include="reference.RFC.3704"?>
<?rfc include="reference.I-D.baker-sava-operational"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:58:25 |