draft-ietf-savi-threat-scope-02.txt   draft-ietf-savi-threat-scope-03.txt 
SAVI D. McPherson SAVI D. McPherson
Internet-Draft Verisign, Inc. Internet-Draft VeriSign, Inc.
Intended status: Informational F. Baker Intended status: Informational F. Baker
Expires: March 3, 2011 Cisco Systems Expires: March 12, 2011 Cisco Systems
J. Halpern J. Halpern
Ericsson Ericsson
August 30, 2010 September 8, 2010
SAVI Threat Scope SAVI Threat Scope
draft-ietf-savi-threat-scope-02 draft-ietf-savi-threat-scope-03
Abstract Abstract
This memo discusses threats enabled by IP source address spoofing and This memo discusses threats enabled by IP source address spoofing and
discusses a number of techniques aimed at mitigating those threats. discusses a number of techniques aimed at mitigating those threats.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 3, 2011. This Internet-Draft will expire on March 12, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 42 skipping to change at page 2, line 42
4.10.1. Manual Binding . . . . . . . . . . . . . . . . . . . . 14 4.10.1. Manual Binding . . . . . . . . . . . . . . . . . . . . 14
4.10.2. Automated Binding . . . . . . . . . . . . . . . . . . 14 4.10.2. Automated Binding . . . . . . . . . . . . . . . . . . 14
4.10.3. IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . 14 4.10.3. IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . 14
4.11. Cryptographic Techniques . . . . . . . . . . . . . . . . . 14 4.11. Cryptographic Techniques . . . . . . . . . . . . . . . . . 14
4.12. Residual Attacks . . . . . . . . . . . . . . . . . . . . . 15 4.12. Residual Attacks . . . . . . . . . . . . . . . . . . . . . 15
5. Topological Considerations . . . . . . . . . . . . . . . . . . 15 5. Topological Considerations . . . . . . . . . . . . . . . . . . 15
5.1. Address Provisioning Mechanisms . . . . . . . . . . . . . 15 5.1. Address Provisioning Mechanisms . . . . . . . . . . . . . 15
5.2. LAN devices with Multiple Addresses . . . . . . . . . . . 15 5.2. LAN devices with Multiple Addresses . . . . . . . . . . . 15
5.2.1. Routers . . . . . . . . . . . . . . . . . . . . . . . 15 5.2.1. Routers . . . . . . . . . . . . . . . . . . . . . . . 15
5.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.3. Multi-Instance hosts . . . . . . . . . . . . . . . . . 16 5.2.3. Multi-Instance Hosts . . . . . . . . . . . . . . . . . 16
5.2.4. Multi-LAN Hosts . . . . . . . . . . . . . . . . . . . 16 5.2.4. Multi-LAN Hosts . . . . . . . . . . . . . . . . . . . 16
5.2.5. Firewalls . . . . . . . . . . . . . . . . . . . . . . 16 5.2.5. Firewalls . . . . . . . . . . . . . . . . . . . . . . 16
5.2.6. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 17 5.2.6. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 17
5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . . 17 5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . . 17
5.3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . 17 5.3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . 17
6. Applicability of Anti-Spoofing Solutions . . . . . . . . . . . 18 6. Applicability of Anti-Spoofing Solutions . . . . . . . . . . . 18
6.1. Analysis of Host Granularity Anti-Spoofing . . . . . . . . 18 6.1. Analysis of Host Granularity Anti-Spoofing . . . . . . . . 18
7. Existing Techniques for IP Source Address Validation . . . . . 19 7. Existing Techniques for IP Source Address Validation . . . . . 19
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 20 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
skipping to change at page 4, line 31 skipping to change at page 4, line 31
reject spoofed packets and contribute to the overall security of IP reject spoofed packets and contribute to the overall security of IP
networks. In particular, source address verification techniques networks. In particular, source address verification techniques
enable detection and rejection of spoofed packets, and also enable detection and rejection of spoofed packets, and also
implicitly provide some assurances that the source address in an IP implicitly provide some assurances that the source address in an IP
packet is legitimately assigned to the system that generated the packet is legitimately assigned to the system that generated the
packet. packet.
Solutions such as BCP 38 [RFC2827] provide guidelines for one such Solutions such as BCP 38 [RFC2827] provide guidelines for one such
technique for network ingress filtering. However, if these technique for network ingress filtering. However, if these
techniques are not implemented at the ingress point of the IP techniques are not implemented at the ingress point of the IP
network, then the validity of the source address can not be network, then the validity of the source address cannot be positively
positively ascertained. Furthermore, BCP 38 only implies source ascertained. Furthermore, BCP 38 only implies source address
address verification at the Internet Layer, and is most often verification at the Internet Layer, and is most often implemented on
implemented on IP subnetwork address boundaries. One of the IP subnetwork address boundaries. One of the difficulties in
difficulties in encouraging the deployment of BCP 38 is that there is encouraging the deployment of BCP 38 is that there is relatively
relatively little benefit until it is very widely deployed, which is little benefit until it is very widely deployed, which is not yet the
not yet the case. The local application of the principle of BCP 38 case. The local application of the principle of BCP 38 fortunately
fortunately has local benefit, even before BCP 38 is fully deployed. has local benefit, even before BCP 38 is fully deployed. It also
It also helps get the Internet towards a state where BCP 38 is more helps get the Internet towards a state where BCP 38 is more widely
widely followed. followed.
It should be noted that while BCP 38 directs providers to provide It should be noted that while BCP 38 directs providers to provide
protection from spoofed prefixes, it is clearly desirable for protection from spoofed prefixes, it is clearly desirable for
enterprise operators to provide that protection more locally, and enterprise operators to provide that protection more locally, and
with better tracability. This allows the enterprise to be a better with better traceability. This allows the enterprise to be a better
Internet participant, and to quickly detect and remedy problems when Internet participant, and to quickly detect and remedy problems when
they occur. they occur.
Also, there is a possibility that in a LAN environment where multiple Also, there is a possibility that in a LAN environment where multiple
hosts share a single LAN or IP port on a switch or router, one of hosts share a single LAN or IP port on a switch or router, one of
those hosts may spoof the source addresses of other hosts within the those hosts may spoof the source addresses of other hosts within the
local subnet. Understanding these threats and the relevant local subnet. Understanding these threats and the relevant
topologies in which they're introduced is critical when assessing the topologies in which they're introduced is critical when assessing the
threats that exists with source address spoofing. threats that exist with source address spoofing.
The aim of this document is to provide some additional details The aim of this document is to provide some additional details
regarding spoofed-based threat vectors, and discuss implications of regarding spoofed-based threat vectors, and discuss implications of
various network topologies. various network topologies.
2. Glossary of Terms 2. Glossary of Terms
The following acronyms and terms are used throughout this memo. The following acronyms and terms are used throughout this memo.
BGP: The Border Gateway Protocol, used to manage routing policy BGP: The Border Gateway Protocol, used to manage routing policy
between large networks. between large networks.
CPE Router: Customer Premises Equipment Router. The router on the CPE Router: Customer Premises Equipment Router. The router on the
customer premises, whether owned by the customer or the provider. customer premises, whether owned by the customer or the provider.
Also called the Customer Endpoint, or CE, Router. Also called the Customer Edge, or CE, Router.
IP Address: An Internet Protocol Address, whether IPv4 or IPv6. IP Address: An Internet Protocol Address, whether IPv4 or IPv6.
ISP: Internet Service Provider. Any person or company that delivers ISP: Internet Service Provider. Any person or company that delivers
Internet service to another. Internet service to another.
MAC Address: An Ethernet Address or comparable IEEE 802 series MAC Address: An Ethernet Address or comparable IEEE 802 series
address. address.
NNI Router: Network to Network Interface Router. This router NNI Router: Network to Network Interface Router. This router
interface faces a similar system operated by another ISP or other interface faces a similar system operated by another ISP or other
large network. large network.
PE Router: Provider Endpoint Router. This router faces a customer PE Router: Provider Edge Router. This router faces a customer of an
of an ISP. ISP.
Spoofing: The act of forging datagram header contents at the Link or Spoofing: The act of forging datagram header contents at the Link or
Network Layer Network Layer
TCP: The Transmission Control Protocol, used on end systems to TCP: The Transmission Control Protocol, used on end systems to
manage data exchange. manage data exchange.
uRPF: Unicast Reverse Path Forwarding. A procedure in which the uRPF: Unicast Reverse Path Forwarding. A procedure in which the
route table, which is usually used to look up destination route table, which is usually used to look up destination
addresses and route towards them, is used to look up the source addresses and route towards them, is used to look up the source
address and ensure that one is routing away from it. When this address and ensure that one is routing away from it. When this
test fails, the event may be logged, and the traffic is commonly test fails, the event may be logged, and the traffic is commonly
dropped. dropped.
3. Spoofed-based Attack Vectors 3. Spoofed-based Attack Vectors
Spoofing is employed on the Internet for a number of reasons, most of Spoofing is employed on the Internet for a number of reasons, most of
which are in some manner associated with malicious or otherwise which are in some manner associated with malicious or otherwise
nefarious activities. In general, two classes of spoofed-based nefarious activities. In general, two classes of spoofed-based
attack vectors exists; blind attacks and non-blind attacks. The attack vectors exist: blind attacks and non-blind attacks. The
follow sections provide some information of blind and non-blind following sections provide some information of blind and non-blind
attacks. attacks.
3.1. Blind Attacks 3.1. Blind Attacks
Blind attacks typically occur when an attacker isn't on the same Blind attacks typically occur when an attacker isn't on the same
local area network as a source or target, or when an attacker has no local area network as a source or target, or when an attacker has no
access to the datapath between the attack source(s) and the target access to the datapath between the attack source(s) and the target
systems. The result is that they have no access to legitimate source systems. The result is that they have no access to legitimate source
and target systems. and target systems.
3.1.1. Single Packet Attacks 3.1.1. Single Packet Attacks
One type of blind attacks, which we'll refer to here as "single One type of blind attacks, which we'll refer to here as "single
packet DoS attacks", involves an attacking system injecting spoofed packet DoS attacks", involves an attacking system injecting spoofed
information into the network which results in either a complete crash information into the network which results in either a complete crash
of the target system, or in some manner poisons some network of the target system, or in some manner poisons some network
configuration or other information on a target system such to impact configuration or other information on a target system so as to impact
network or other services. network or other services.
An example of an attack that can cause a receiving system to crash is An example of an attack that can cause a receiving system to crash is
a LAND attack. A LAND attack packet would consist of an attacking a LAND attack. A LAND attack packet would consist of an attacking
system forwarding a packet (e.g., TCP SYN) to a target system that system forwarding a packet (e.g., TCP SYN) to a target system that
contains both a source and destination address of that target system. contains both a source and destination address of that target system.
The target system would "lock up" when creating connection state The target system would "lock up" when creating connection state
associated with the packet, or would get stuck in a state where it associated with the packet, or would get stuck in a state where it
continuously replies to itself. continuously replies to itself.
Another class of a single packet attacks involves an attacker Another class of a single packet attacks involves an attacker
poisoning network or DNS cache information, perhaps in order to poisoning network or DNS cache information, perhaps to simply break a
simply break a given hosts connection, enable MITM or other attacks. given host's connection, enable MITM or other attacks. Network level
Network level attacks that could involve single packet DoS include attacks that could involve single packet DoS include ARP cache
ARP cache poisoning and ICMP redirects. The most obvious example poisoning and ICMP redirects. The most obvious example which depends
which depends upon faslifying an IP source address is an on-link upon falsifying an IP source address is an on-link attacker poisoning
attacker poisoning a routers ARP or ND cache. The ability to forge a a router's ARP or ND cache. The ability to forge a source address
source address can also be helpful in causing a DNS cache to accept can also be helpful in causing a DNS cache to accept and use
and use incorrect information. incorrect information.
3.1.2. Flood-Based DoS 3.1.2. Flood-Based DoS
Flooding-based DoS attack vectors are particularly effective attacks Flooding-based DoS attack vectors are particularly effective attacks
on the Internet today. They usually entail flooding a large number on the Internet today. They usually entail flooding a large number
of packets towards a target system, with the hopes of either of packets towards a target system, with the hopes of either
exhausting connection state on the target system, consuming all exhausting connection state on the target system, consuming all
packet processing capabilities of the target or intermediate systems, packet processing capabilities of the target or intermediate systems,
or consuming a great deal of bandwidth available to the target system or consuming a great deal of bandwidth available to the target system
such that they are essentially inaccessible. such that they are essentially inaccessible.
skipping to change at page 7, line 24 skipping to change at page 7, line 24
flows. Because ingress filtering isn't applied ubiquitously on the flows. Because ingress filtering isn't applied ubiquitously on the
Internet today, spoof-based flooding attack vectors are typically Internet today, spoof-based flooding attack vectors are typically
very difficult to traceback. In particular, there may be one or more very difficult to traceback. In particular, there may be one or more
attacking sources beyond your network border, and the attacking attacking sources beyond your network border, and the attacking
sources may or may not be legitimate sources, it's difficult to sources may or may not be legitimate sources, it's difficult to
discriminate if the sources are not directly connected to the local discriminate if the sources are not directly connected to the local
routing system. routing system.
Common flood-based DoS attack vectors today include SYN floods, ICMP Common flood-based DoS attack vectors today include SYN floods, ICMP
floods, and IP fragmentation attacks. Attackers may use a single floods, and IP fragmentation attacks. Attackers may use a single
legitimate or spoofed fixed attacking source addresses, although legitimate or spoofed fixed attacking source address, although
frequently they cycle through large swaths of address space. As a frequently they cycle through large swaths of address space. As a
result, mitigating these attacks on the receiving end with source- result, mitigating these attacks on the receiving end with source-
based policies is extremely difficult. based policies is extremely difficult.
Furthermore, the motivator for spoof-based DoS attacks may actually Furthermore, the motivator for spoof-based DoS attacks may actually
be to encourage the target to filter explicitly on a given set of be to encourage the target to filter explicitly on a given set of
source addresses, or order to disrupt the legitimate owner(s) access source addresses, or order to disrupt the legitimate owner(s) access
to the target system. to the target system.
3.1.3. Poisoning Attacks 3.1.3. Poisoning Attacks
While poison attacks can often be done with single packets, it is While poison attacks can often be done with single packets, it is
also true that a stream of packets can be used to find a window where also true that a stream of packets can be used to find a window where
the target will accept the incorrect information. In general, this the target will accept the incorrect information. In general, this
can be used to perform broadly the same kinds of poinsonings as can be used to perform broadly the same kinds of poinsonings as
above, with more versatility. above, with more versatility.
3.1.4. Spoof-based Worm/Malware Propagation 3.1.4. Spoof-based Worm/Malware Propagation
Self-propagating malware has been observed that spoofs it's source Self-propagating malware has been observed that spoofs its source
address when attempting to propagate to other systems. Presumably, address when attempting to propagate to other systems. Presumably,
this was done to obfuscate the actual source address of the infected this was done to obfuscate the actual source address of the infected
system. system.
3.1.5. Reflective Attacks 3.1.5. Reflective Attacks
DNS reflective amplification attacks are a particularly potent DoS DNS reflective amplification attacks are a particularly potent DoS
attack vector on the Internet today. Like other amplification attack vector on the Internet today. Like other amplification
attacks, an attack source generates a packet with a source-spoofed attacks, an attack source generates a packet with a source-spoofed
address mapping to that of the target system. The packet, upon address mapping to that of the target system. The packet, upon
receipt by the victim or some intermediate node, typically elicits a receipt by the victim or some intermediate node, typically elicits a
large reply message, which is directed to the target of the attack. large reply message, which is directed to the target of the attack.
The amplification factor observed for attacks targeting DNS root and The amplification factor observed for attacks targeting DNS root and
other top level domain name infrastructure in early 2006 was on the other top level domain name infrastructure in early 2006 was on the
order of 76:1. The result is that just 15 attacking sources with order of 76:1. The result is that just 15 attacking sources with
512k of upstream attack bandwidth could generate one Gbps of response 512Kbps of upstream attack bandwidth could generate one Gbps of
attack traffic towards a target system. response attack traffic towards a target system.
Smurf attacks employ a similar reflective amplification attack Smurf attacks employ a similar reflective amplification attack
vector, exploiting traditional default IP subnet directed broadcast vector, exploiting traditional default IP subnet directed broadcast
address behaviors that would result in all the active hosts on a address behaviors that would result in all the active hosts on a
given subnet responding to (spoofed) ICMP echo request from an given subnet responding to (spoofed) ICMP echo request from an
attacker, and generating a large amount of ICMP echo response traffic attacker, and generating a large amount of ICMP echo response traffic
directed towards a target system. They were particularly effective directed towards a target system. They were particularly effective
in large campus LAN environments where 50k or more hosts might reside in large campus LAN environments where 50k or more hosts might reside
on a single subnet. on a single subnet.
skipping to change at page 8, line 48 skipping to change at page 8, line 48
3.1.7. Other Blind Spoofing Attacks 3.1.7. Other Blind Spoofing Attacks
Other Blind spoofing attacks might include spoofing in order to Other Blind spoofing attacks might include spoofing in order to
exploit source routing or other policy based routing implemented in a exploit source routing or other policy based routing implemented in a
network. It may also be possible in some environments to use network. It may also be possible in some environments to use
spoofing techniques to perform blind or non-blind attacks on the spoofing techniques to perform blind or non-blind attacks on the
routers in a site or in the Internet. There are many techniques to routers in a site or in the Internet. There are many techniques to
mitigate these attacks, but it is well known that there are mitigate these attacks, but it is well known that there are
vulnerabilities in this area. Among other attacks, if there are vulnerabilities in this area. Among other attacks, if there are
multiple rotuers on-link with hosts, a host may be able to cause multiple routers on-link with hosts, a host may be able to cause
problems for the routing system by replaying modified or unmodified problems for the routing system by replaying modified or unmodified
routing packets as if they came from another router. routing packets as if they came from another router.
3.2. Non-Blind Attacks 3.2. Non-Blind Attacks
Non-blind attacks often involve mechanisms such as eavesdropping on Non-blind attacks often involve mechanisms such as eavesdropping on
connection, resetting state so that new connections may be hijacking, connection, resetting state so that new connections may be hijacked,
and an array of other attack vectors. Perhaps the most common of and an array of other attack vectors. Perhaps the most common of
these attack vectors is known as man in the middle attacks. these attack vectors is known as man in the middle attacks.
3.2.1. Man in the Middle (MITM) 3.2.1. Man in the Middle (MITM)
Connection Hijacking is one of the more common man in the middle Connection Hijacking is one of the more common man in the middle
attack vectors. In order to hijack a connection an attacker usually attack vectors. In order to hijack a connection an attacker usually
needs to be in the forwarding path and often times employs TCP RST or needs to be in the forwarding path and often times employs TCP RST or
other attacks in order to reset a transaction. The attacker may have other attacks in order to reset a transaction. The attacker may have
already compromised a system that's in the forwarding path, or they already compromised a system that's in the forwarding path, or they
may which to insert themselves in the forwarding path. may wish to insert themselves in the forwarding path.
For example, an attacker with access to a host on LAN segment may For example, an attacker with access to a host on LAN segment may
wish to redirect all the traffic on the local segment destined for a wish to redirect all the traffic on the local segment destined for a
default gateway address (or all addresses) to itself in order to default gateway address (or all addresses) to itself in order to
perform man-in-the-middle attacks. In order to accomplish this the perform man-in-the-middle attacks. In order to accomplish this the
attacker might transmit gratuitous ARP [RFC0826] messages or ARP attacker might transmit gratuitous ARP [RFC0826] messages or ARP
replies to the Ethernet broadcast address ff:ff:ff:ff:ff:ff, replies to the Ethernet broadcast address ff:ff:ff:ff:ff:ff,
notifying all the hosts on the segment that the IP address(es) of the notifying all the hosts on the segment that the IP address(es) of the
target(s) now map to it's own MAC address. If the port to which the target(s) now map to it's own MAC address. If the port to which the
attacker is connected were to implement policy that binds a single attacker is connected were to implement policy that binds a single
Link Layer and IP address tuple to that port upon initial Link Layer and IP address tuple to that port upon initial
provisioning, spoofed packets, at the Link Layer and/or Network provisioning, spoofed packets, at the Link Layer and/or Network
Layer, would be discarded on ingress. Layer, would be discarded on ingress.
3.2.2. Third Party Recon 3.2.2. Third Party Recon
Another example of sighted attack isthird party reconnaissance. The Another example of sighted attack is third party reconnaissance. The
use of spoofed addresses, while not necessary for this, can often use of spoofed addresses, while not necessary for this, can often
provide additional information, and helps mask the tracability of the provide additional information, and helps mask the traceability of
activity. The attack involves sending packets towards a given target the activity. The attack involves sending packets towards a given
system and observing either target or intermediate system responses. target system and observing either target or intermediate system
For example, if an attacker were to source spoof TCP SYN packets responses. For example, if an attacker were to source spoof TCP SYN
towards a target system from a large set of source addresses, and packets towards a target system from a large set of source addresses,
observe responses from that target system or some intermediate and observe responses from that target system or some intermediate
firewall or other middle box, they would be able to identify what IP firewall or other middle box, they would be able to identify what IP
layer filtering policies may be in place to protect that system. layer filtering policies may be in place to protect that system.
4. Current Anti-Spoofing Solutions 4. Current Anti-Spoofing Solutions
The first requirement is to eliminate datagrams with spoofed The first requirement is to eliminate datagrams with spoofed
addresses from the Internet. Identifying and dropping datagrams addresses from the Internet. Identifying and dropping datagrams
whose source address is incompatible with the Internet topology at whose source address is incompatible with the Internet topology at
sites where the relationship between the source address and topology sites where the relationship between the source address and topology
can be checked can eliminate such datagrams. For example, Internet can be checked can eliminate such datagrams. For example, Internet
skipping to change at page 10, line 50 skipping to change at page 10, line 50
,' +----+ +------+ +------+ `. ,+------+ +--+---+. ,' +----+ +------+ +------+ `. ,+------+ +--+---+.
( |Host+--+Switch+--+ CPE +---)---+-+ PE +- - - -+ NNI | \\ ( |Host+--+Switch+--+ CPE +---)---+-+ PE +- - - -+ NNI | \\
`. +----+ +------+ |Router| ,' ( |Router| |Router| ) `. +----+ +------+ |Router| ,' ( |Router| |Router| )
`---. +------+' \\ +------+ +------+ / `---. +------+' \\ +------+ +------+ /
`----------------'' `. ,' `----------------'' `. ,'
'--. ISP B _.-' '--. ISP B _.-'
`----------'' `----------''
Figure 1: Points where an address can be validated Figure 1: Points where an address can be validated
Figure 1 illustrates five related pathes where a source address can Figure 1 illustrates five related paths where a source address can be
be validated: validated:
o host to switch, including host to host via the switch o host to switch, including host to host via the switch
o Host to enterprise CPE Router, o Host to enterprise CPE Router
o Enterprise CPE Router to ISP edge PE Router, and the reverse o Enterprise CPE Router to ISP edge PE Router, and the reverse
o ISP NNI Router to ISP NNI Router, and the o ISP NNI Router to ISP NNI Router
In general, datagrams with spoofed addresses can be detected and In general, datagrams with spoofed addresses can be detected and
discarded by devices that have an authoritative mapping between IP discarded by devices that have an authoritative mapping between IP
addresses and the network topology. For example, a device that has addresses and the network topology. For example, a device that has
an authoritative table between Link Layer and IP addresses on a link an authoritative table between Link Layer and IP addresses on a link
can discard any datagrams in which the IP address is not associated can discard any datagrams in which the IP address is not associated
with the Link Layer address in the datagram. The degree of with the Link Layer address in the datagram. The degree of
confidence in the source address depends on where the spoofing confidence in the source address depends on where the spoofing
detection is performed and the prefix aggregation in place between detection is performed and the prefix aggregation in place between
the spoofing detection and the source of the datagram. the spoofing detection and the source of the datagram.
skipping to change at page 13, line 13 skipping to change at page 13, line 13
enable MITM or other spoof-based attacks. enable MITM or other spoof-based attacks.
4.6. Cable Modem Subscriber Access 4.6. Cable Modem Subscriber Access
Cable Modem Termination Systems (CMTS) employ DOCSIS Media Access Cable Modem Termination Systems (CMTS) employ DOCSIS Media Access
Control (MAC) domains, which are similar to Ethernet LAN Control (MAC) domains, which are similar to Ethernet LAN
environments. environments.
4.7. DSL Subscriber Access 4.7. DSL Subscriber Access
While DSL subscriber access can be bridged or rotued, as seen by the While DSL subscriber access can be bridged or routed, as seen by the
service provide3rs device, it is generally the case that the service provider's device, it is generally the case that the
protocols carry enough information to very which subscriber is protocols carry enough information to verify which subscriber is
sending packets. Thus, for ensuring that one DSL subscriber does not sending packets. Thus, for ensuring that one DSL subscriber does not
spoof another, enforcement can generally be done at the aggregation spoof another, enforcement can generally be done at the aggregation
router. This is true even when there is a bridged infrastructure router. This is true even when there is a bridged infrastructure
among the subscribers, as DSL access generally requires all among the subscribers, as DSL access generally requires all
subscriber traffic to go through the access aggregation router. subscriber traffic to go through the access aggregation router.
If it is desirable to provide spoofing protection among the devices If it is desirable to provide spoofing protection among the devices
within a residence, that would need to be provided by the CPE device, within a residence, that would need to be provided by the CPE device,
as the ISPs rotuer does not have enough visiblity to do that. It is as the ISPs router does not have enough visibility to do that. It is
not clear at this time that this problem is seen as a relevant not clear at this time that this problem is seen as a relevant
threat. threat.
4.8. BCP 38 4.8. BCP 38
If BCP 38 [RFC2827] is implemented in LAN segments, it is typically If BCP 38 [RFC2827] is implemented in LAN segments, it is typically
done so on subnetwork boundaries and traditionally relates only to done so on subnetwork boundaries and traditionally relates only to
Network Layer ingress filtering policies. The result is that hosts Network Layer ingress filtering policies. The result is that hosts
within the segment cannot spoof packets from address space outside of within the segment cannot spoof packets from address space outside of
the local segment itself, however, they may still spoof packets using the local segment itself, however, they may still spoof packets using
sources addresses that exist within the local network segment. sources addresses that exist within the local network segment.
4.9. Unicast RPF 4.9. Unicast RPF
Unicast RPF is a crude mechanism to automate definition of BCP 38 Unicast RPF is a crude mechanism to automate definition of BCP 38
style filters based on routing table information. It's applicability style filters based on routing table information. Its applicability
parallels that of BCP 38, although deployment caveats exists, as parallels that of BCP 38, although deployment caveats exist, as
outlined in [RFC3704]. outlined in [RFC3704].
4.10. Port-based Address Binding 4.10. Port-based Address Binding
Much of the work SAVI appears to be initially targeting is aimed at Much of the work SAVI appears to be initially targeting is aimed at
minimizing source address spoofing in the LAN. In particular, if minimizing source address spoofing in the LAN. In particular, if
mechanisms can be defined to accommodate configuration of port mechanisms can be defined to accommodate configuration of port
binding information for IP and MAC layer addresses in LAN binding information for IP and MAC layer addresses in LAN
environments, a large portion of the spoofing threat space in the LAN environments, a large portion of the spoofing threat space in the LAN
can be marginalized. can be marginalized.
However, establishing these binding is not trivial, and varying However, establishing this binding is not trivial, and varying across
across both topologies type and address allocation mechanisms. both topologies type and address allocation mechanisms.
4.10.1. Manual Binding 4.10.1. Manual Binding
Binding of a single Link Layer and Network Layer address to a port Binding of a single Link Layer and Network Layer address to a port
may initially seem trivial. However, two primary areas exist that may initially seem trivial. However, two primary areas exist that
can complicate such techniques. In particular, these area involves can complicate such techniques. In particular, these areas involve
topologies where more than a single IP layer address may be topologies where more than a single IP layer address may be
associated with a MAC address on a given port, or where multiple associated with a MAC address on a given port, or where multiple
hosts are connected to a single IP port. Furthermore, if one or more hosts are connected to a single IP port. Furthermore, if one or more
dynamic address allocation mechanisms such as DHCP are employed, then dynamic address allocation mechanisms such as DHCP are employed, then
some mechanism must exist to associate those IP layer addresses with some mechanism must exist to associate those IP layer addresses with
the appropriate Link layer ports, as addresses are allocated or the appropriate Link layer ports, as addresses are allocated or
reclaimed. reclaimed.
4.10.2. Automated Binding 4.10.2. Automated Binding
For IPv4 the primary and very widely used automated binding technique For IPv4 the primary and very widely used automated binding technique
is DHCP based address assignment. Controlling where authoratitive is DHCP based address assignment. Controlling where authoritative
information can be source, coupled with sniffing and enforcing the information can be sourced, coupled with sniffing and enforcing the
assignments is an effective technique. assignments is an effective technique.
For IPv6, there are two common automated address binding techniques. For IPv6, there are two common automated address binding techniques.
While there are many variations and details, for purposes of While there are many variations and details, for purposes of
understanding the threats and basic responses, these are Stateless understanding the threats and basic responses, these are Stateless
Address AutoConfiguration (SLAAC) and DHCPv6 based address Address AutoConfiguration (SLAAC) and DHCPv6 based address
assignment. In both cases, binding establishment needs to be tied to assignment. In both cases, binding establishment needs to be tied to
the state machines for these protocols, and appropriate message the state machines for these protocols, and appropriate message
sniffing and enforcement. For DHCPv6 based techniques, it is also sniffing and enforcement. For DHCPv6 based techniques, it is also
necessary to use classification techniques to ensure that responses necessary to use classification techniques to ensure that responses
skipping to change at page 14, line 49 skipping to change at page 14, line 49
IEEE 802.1x is an authentication protocol that permits a network to IEEE 802.1x is an authentication protocol that permits a network to
determine the identity of a system seeking to join it and apply determine the identity of a system seeking to join it and apply
authorization rules to permit or deny the action. authorization rules to permit or deny the action.
4.11. Cryptographic Techniques 4.11. Cryptographic Techniques
Needless to say, MITM and replay attacks can typically be mitigated Needless to say, MITM and replay attacks can typically be mitigated
with cryptographic techniques. However, many of the applications with cryptographic techniques. However, many of the applications
today either don't or can't employ cryptographic authentication and today either don't or can't employ cryptographic authentication and
protection mechanisms. ARP for IP v4 does not use such protection. protection mechanisms. ARP for IPv4 does not use such protection.
While SEND provides such protection for IPv6 ND, SEND is not widely While SEND provides such protection for IPv6 ND, SEND is not widely
used to date. While DNSsec will significantly help protect DNS from used to date. While DNSsec will significantly help protect DNS from
spoof based poisoning attacks, it will probably be sufficiently long spoof based poisoning attacks, it will probably be sufficiently long
fortruly widespread use that other protections can be usefully for truly widespread use that other protections can be usefully
deployed as well. deployed as well.
4.12. Residual Attacks 4.12. Residual Attacks
It should be understood that not all combinations of network, service It should be understood that not all combinations of network, service
and enforcement choices will result in a protectable network. For and enforcement choices will result in a protectable network. For
example, if one uses conventional SLAAC, in a switched network, but example, if one uses conventional SLAAC, in a switched network, but
tries to only provide address enforment on the routers on the tries to only provide address enforcement on the routers on the
network, then the ability to provide protection is severly limited. network, then the ability to provide protection is severely limited.
5. Topological Considerations 5. Topological Considerations
As noted previously, topological components and address allocation As noted previously, topological components and address allocation
mechanisms have significant implications on what is feasible with mechanisms have significant implications on what is feasible with
regard to Link layer address and IP address port bindings. The regard to Link layer address and IP address port bindings. The
following sections discuss some of the various topologies and address following sections discuss some of the various topologies and address
allocation mechanisms that proposed SAVI solutions should attempt to allocation mechanisms that proposed SAVI solutions should attempt to
address. address.
5.1. Address Provisioning Mechanisms 5.1. Address Provisioning Mechanisms
In a strictly static environment configuration management for access In a strictly static environment, configuration management for access
filters that map Link Layer and Network Layer addresses on a specific filters that map Link Layer and Network Layer addresses on a specific
switch port might be a viable option. However, most networks, switch port might be a viable option. However, most networks,
certainly, those that accommodate actual human users, are much more certainly those that accommodate actual human users, are much more
dynamic in nature. As such, mechanisms that provide port-MAC-IP dynamic in nature. As such, mechanisms that provide port-MAC-IP
bindings need to accommodate dynamic address allocation schemes bindings need to accommodate dynamic address allocation schemes
enabled by protocols such as DHCP, DHCPv6 for address allocation, and enabled by protocols such as DHCP, DHCPv6 for address allocation, and
IPv6 Stateless Address Autoconfiguration. IPv6 Stateless Address Autoconfiguration.
5.2. LAN devices with Multiple Addresses 5.2. LAN devices with Multiple Addresses
From a topology considerations perspective, when attempting From a topology considerations perspective, when attempting
port-MAC-IP bindings, host connected to switch ports that may have port-MAC-IP bindings, host connected to switch ports that may have
one or more IP addresses, or certainly, devices that forward packets one or more IP addresses, or certainly, devices that forward packets
skipping to change at page 16, line 13 skipping to change at page 16, line 13
subnets should be associated with the port-MAC in question. subnets should be associated with the port-MAC in question.
5.2.2. NATs 5.2.2. NATs
Validating traffic from Prefix-based and multi-address NATs also Validating traffic from Prefix-based and multi-address NATs also
becomes problematic, for the same reasons as routers. Because they becomes problematic, for the same reasons as routers. Because they
may forward traffic from an array of address, a priori knowledge must may forward traffic from an array of address, a priori knowledge must
exist providing what IPs should be associated with a given port-MAC exist providing what IPs should be associated with a given port-MAC
pair. pair.
5.2.3. Multi-Instance hosts 5.2.3. Multi-Instance Hosts
Another example that introduces complexities is that of multi- Another example that introduces complexities is that of multi-
instance hosts attached to a switch port. These are single physical instance hosts attached to a switch port. These are single physical
devices, which internally run multiple physical or logical hosts. devices, which internally run multiple physical or logical hosts.
When the device is a blade server, with internal blades each hosting When the device is a blade server, with internal blades each hosting
a machine, there is essentially a physical switch inside the blade a machine, there is essentially a physical switch inside the blade
server. While tractable, this creates some complexity for server. While tractable, this creates some complexity for
determining where enforcement logic can or should live. determining where enforcement logic can or should live.
Logically distinct hosts such as are provided by many varieties of Logically distinct hosts such as are provided by many varieties of
virtualization logic result in a single physical host, connect to a virtualization logic result in a single physical host, connect to a
single port on the ethernet switch in the topology, actually having single port on the Ethernet switch in the topology, actually having
multiple internal IP and MAC addresses, and essentially an internal multiple internal IP and MAC addresses, and essentially an internal
switch. While it may be possible for this internal switch to help switch. While it may be possible for this internal switch to help
control threats among the virtual hosts, or between virtual hosts and control threats among the virtual hosts, or between virtual hosts and
other parts of the network, such enforcement can not be counted on at other parts of the network, such enforcement cannot be counted on at
this time. this time.
5.2.4. Multi-LAN Hosts 5.2.4. Multi-LAN Hosts
Multi-interface hosts, in particular those that are multi-homed and Multi-interface hosts, in particular those that are multi-homed and
may forward packets from any of a number of source addresses, can be may forward packets from any of a number of source addresses, can be
problematic as well. In particular, if a port-MAC-IP binding is made problematic as well. In particular, if a port-MAC-IP binding is made
on each of the interfaces, and then either a loopback IP or the on each of the interfaces, and then either a loopback IP or the
address of third interface is used as the source address of a packet address of third interface is used as the source address of a packet
and forward through in interface for which the port-MAC-IP binding forwarded through an interface for which the port-MAC-IP binding
doesn't map, the traffic may be discarded. Static configuration of doesn't map, the traffic may be discarded. Static configuration of
port-MAC-IP bindings may accommodate this scenario, although some a port-MAC-IP bindings may accommodate this scenario, although some a
priori knowledge on address assignment and topology is required. priori knowledge on address assignment and topology is required.
While the use of loopback addresssing or sending packets out one While the use of loopback addressing or sending packets out one
interface with the source address from another are rare, they do interface with the source address from another are rare, they do
legitimately occur. Some servers, particularly ones that have legitimately occur. Some servers, particularly ones that have
underlying virtualization, use loopback techniques for management. underlying virtualization, use loopback techniques for management.
5.2.5. Firewalls 5.2.5. Firewalls
Firewalls that forward packets from other network segments, or serve Firewalls that forward packets from other network segments, or serve
as a source for locally originated packets, suffer from the same as a source for locally originated packets, suffer from the same
issues as routers. issues as routers.
5.2.6. Mobile IP 5.2.6. Mobile IP
Mobile IP hosts in both IPv4 and IPv6 as proper members of the site 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 where they are currently located. Their care-of-address is a
properly assigned address that is on the link they are using. And properly assigned address that is on the link they are using. And
their packets are sent and received using that address. (There was their packets are sent and received using that address. Thus, they
at one time consideration of allowing mobile hosts to use their home do not introduce any additional complications. (There was at one
address when away from home. This was not done, precisely to ensure time consideration of allowing mobile hosts to use their home address
that mobile hosts comply with source address validity requirements.) 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 Mobile Hosts with multiple physical interfaces fall into the cases
above. above.
Mobile IP home agents are somewhat more interesting. Although they Mobile IP home agents are somewhat more interesting. Although they
are (typically) fixed devices, they are required to send and receive are (typically) fixed devices, they are required to send and receive
packets addressed from or to any currently properly registered mobile packets addressed from or to any currently properly registered mobile
node. From an analysis point of view, even though the packets that a 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 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 is on, it is probably best to think of them as routers, with a
virtual interface to the actual hosts they are serving. virtual interface to the actual hosts they are serving.
skipping to change at page 17, line 48 skipping to change at page 17, line 49
stateless address autoconfiguration (often referred to as SLAAC). stateless address autoconfiguration (often referred to as SLAAC).
This allows hosts to determine their IP prefix, select an ID, and This allows hosts to determine their IP prefix, select an ID, and
then start communicating. While there are many advantages to this, then start communicating. While there are many advantages to this,
the absence of control interactions complicates the process of the absence of control interactions complicates the process of
behavioral enforcement. behavioral enforcement.
An additional complication is the very large ID space. Again, this An additional complication is the very large ID space. Again, this
64 bit ID space provided by IPv6 has many advantages. It provides 64 bit ID space provided by IPv6 has many advantages. It provides
the opportunity for many useful behaviors. However, it also means the opportunity for many useful behaviors. However, it also means
that in the absence of controls, hosts can mint anonymous addresses that in the absence of controls, hosts can mint anonymous addresses
as often as they like, modulo the idosyncrasies of the duplicate as often as they like, modulo the idiosyncrasies of the duplicate
address procedure. Like many behaviors, this is a feature for some address procedure. Like many behaviors, this is a feature for some
purposes, and a problem for others. But it does have implications purposes, and a problem for others. But it does have implications
for switch cost; the switch needs to store more addresses and so for switch cost; the switch needs to store more addresses and so
needs more memory. needs more memory.
6. Applicability of Anti-Spoofing Solutions 6. Applicability of Anti-Spoofing Solutions
The above sections covered a number of security threats. Not all The above sections covered a number of security threats. Not all
these threats can be prevented by anti-spoofing techniques. However, these threats can be prevented by anti-spoofing techniques. However,
all of these threats can be ameliorated to some degree. We can look all of these threats can be ameliorated to some degree. We can look
skipping to change at page 18, line 24 skipping to change at page 18, line 25
that a host send packets using some other active hosts IP address that a host send packets using some other active hosts IP address
as a source. Anti-Spoofing measures can prevent these attacks. as a source. Anti-Spoofing measures can prevent these attacks.
Impediment: Many of the attacks above, such as some kinds of DoS Impediment: Many of the attacks above, such as some kinds of DoS
attacks, can be conducted more easily if the attacking host can attacks, can be conducted more easily if the attacking host can
use multiple different IP addresses. Depending upon the kind of use multiple different IP addresses. Depending upon the kind of
anti-spoofing available, the scope of such false addresses, or anti-spoofing available, the scope of such false addresses, or
even their use, may be prevented, hindering the attacker even if even their use, may be prevented, hindering the attacker even if
the attack is not completely prevented. the attack is not completely prevented.
Traceability: Even when attacks can not be prevented, the ability to Traceability: Even when attacks cannot be prevented, the ability to
reliably trace an attack allows appropriate responses, and thereby reliably trace an attack allows appropriate responses, and thereby
also creates an environment which discourages attacks instead of also creates an environment which discourages attacks instead of
encouraging them. Thus, ensuring that even attacks which are not encouraging them. Thus, ensuring that even attacks which are not
dependent upon spoofing can not use source address spoofing to dependent upon spoofing cannot use source address spoofing to hide
hide their origin is extremely important. their origin is extremely important.
For example, sites which deploy BCP 38 can not be the source of For example, sites which deploy BCP 38 cannot be the source of
attacks which rely on spoofing the source site from which an attack attacks which rely on spoofing the source site from which an attack
was launched. Wide deployment of BCP 38 would also simplify the task was launched. Wide deployment of BCP 38 would also simplify the task
of tracking attacks back to their actual origin. of tracking attacks back to their actual origin.
6.1. Analysis of Host Granularity Anti-Spoofing 6.1. Analysis of Host Granularity Anti-Spoofing
Applying anti-spoofing techniques at the host level enables a site to Applying anti-spoofing techniques at the host level enables a site to
achieve several valuable objectives. While it is likely the case achieve several valuable objectives. While it is likely the case
that for many site topologies and policies, full source spoofing that for many site topologies and policies, full source spoofing
protection is not possible, it is also true that for many sites there protection is not possible, it is also true that for many sites there
skipping to change at page 19, line 8 skipping to change at page 19, line 9
threats involving one machine masquerading as another, for example in threats involving one machine masquerading as another, for example in
order to hijack an apparently secure session, can occur within a site order to hijack an apparently secure session, can occur within a site
with significant impact. Having mechanisms such that host facing with significant impact. Having mechanisms such that host facing
devices prevent this is a significant intra-site security devices prevent this is a significant intra-site security
improvement. Given that security experts report that most security improvement. Given that security experts report that most security
breaches are internal, this can be valuable. One example of this is breaches are internal, this can be valuable. One example of this is
that such techniques should mitigate internal attacks on the site that such techniques should mitigate internal attacks on the site
routing system. routing system.
A second class of benefit is related to the traceability described A second class of benefit is related to the traceability described
above. When a security incident is detect, either within a site, or above. When a security incident is detected, either within a site,
externally (and traced to the site, it can be critical to determine or externally (and traced to the site( it can be critical to
what the actual source of the incident was. If address usage can be determine what the actual source of the incident was. If address
tied to the kinds of anchors described earlier, then it is possible usage can be tied to the kinds of anchors described earlier, then it
to respond to security incidents. is possible to respond to security incidents.
In addition to these local observable benefits, there can be more In addition to these local observable benefits, there can be more
global benefits. For example, if address usage is tied to anchors, global benefits. For example, if address usage is tied to anchors,
it may be possible to prevent or control the use of large numbers of it may be possible to prevent or control the use of large numbers of
anonymous IPv6 addresses for attacks, or at least to track even those anonymous IPv6 addresses for attacks, or at least to track even those
attacks back to their source. attacks back to their source.
7. Existing Techniques for IP Source Address Validation 7. Existing Techniques for IP Source Address Validation
Existing techniques for IP source address validation are Existing techniques for IP source address validation are
skipping to change at page 19, line 41 skipping to change at page 19, line 42
False positives: Techniques may yield false positives, thereby False positives: Techniques may yield false positives, thereby
causing interruption or denial of service to hosts that use causing interruption or denial of service to hosts that use
legitimate IP source addresses. legitimate IP source addresses.
Non-trivial configuration: Requirements for non-trivial Non-trivial configuration: Requirements for non-trivial
configuration imply expenditures and pose a risk for configuration imply expenditures and pose a risk for
misconfiguration, which may again lead to false positives or false misconfiguration, which may again lead to false positives or false
negatives. Both may discourage operators from employing a given negatives. Both may discourage operators from employing a given
technique. technique.
Proprietary: Procurement policies oftentimes require techniques that Proprietary: Procurement policies of organizations oftentimes
are standardized, hence hindering or preventing the deployment of require that devices purchased use techniques that are
proprietary techniques. standardized rather than proprietary. Such policies, for good or
ill, hinder or prevent the deployment of proprietary techniques.
The only standardized technique for IP source address validation is The only standardized technique for IP source address validation is
ingress filtering [RFC2827]. This calls for routers to check whether ingress filtering [RFC2827]. This calls for routers to check whether
the prefix of a to-be-forwarded packet's IP source address is amongst the prefix of a to-be-forwarded packet's IP source address is amongst
a list of prefixes considered legitimate for the interface through a list of prefixes considered legitimate for the interface through
which the packet arrives. Packets that fail this check are which the packet arrives. Packets that fail this check are
discarded. discarded.
Ingress filtering may yield false negatives in a deterministic Ingress filtering may yield false negatives in a deterministic
manner. Packets with a legitimate IP source address prefix, but a manner. Packets with a legitimate IP source address prefix, but a
skipping to change at page 21, line 20 skipping to change at page 21, line 23
deployment of SAVI security mechanisms. This may help motivate the deployment of SAVI security mechanisms. This may help motivate the
deployment of tools with widespread benefit. deployment of tools with widespread benefit.
9. IANA Considerations 9. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
Note to RFC Editor: This section will have served its purpose if it Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are correctly tells IANA that no new assignments or registries are
required, or if those assignments or registries are created during required, or if those assignments or registries are created during
the RFC publication process. From the author"s perspective, it may the RFC publication process. From the authors' perspective, it may
therefore be removed upon publication as an RFC at the RFC Editor"s therefore be removed upon publication as an RFC at the RFC Editor's
discretion. discretion.
10. Security Considerations 10. Security Considerations
This document provides limited discussion of some security threats This document provides limited discussion of some security threats
source address validation improvements will help to mitigate. It is source address validation improvements will help to mitigate. It is
not meant to be all-inclusive, either from a threat analysis not meant to be all-inclusive, either from a threat analysis
perspective, or from the source address verification application perspective, or from the source address verification application
side. side.
skipping to change at page 22, line 7 skipping to change at page 22, line 9
middleware systems and application servers have no user at all, but middleware systems and application servers have no user at all, but
by design relay messages or perform services on behalf of users of by design relay messages or perform services on behalf of users of
other systems (e.g., SMTP and peer-to-peer file sharing). other systems (e.g., SMTP and peer-to-peer file sharing).
Until every Internet-connected network implements source address Until every Internet-connected network implements source address
validation at the ultimate network ingress, and assurances exist that validation at the ultimate network ingress, and assurances exist that
intermediate devices are to never modify datagram source addresses, intermediate devices are to never modify datagram source addresses,
source addresses must not be used as an authentication mechanism. source addresses must not be used as an authentication mechanism.
The only technique to unquestionably verify source addresses of a The only technique to unquestionably verify source addresses of a
received datagram are cryptographic authentication mechanisms such as received datagram are cryptographic authentication mechanisms such as
IPSEC. IPsec.
11. Acknowledgements 11. Acknowledgements
A portion of the primer text in this document came directly from A portion of the primer text in this document came directly from
[I-D.baker-sava-operational], authored by Fred Baker and Ralph Droms. [I-D.baker-sava-operational], authored by Fred Baker and Ralph Droms.
Many thanks to Christian Vogt for contributing text and a careful Many thanks to Christian Vogt and Suresh Bhogavilli for contributing
review of this document. text and a careful review of this document.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
skipping to change at page 23, line 8 skipping to change at page 23, line 8
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
Authors' Addresses Authors' Addresses
Danny McPherson Danny McPherson
Verisign, Inc. VeriSign, Inc.
Email: dmcpherson@verisign.com Email: dmcpherson@verisign.com
Fred Baker Fred Baker
Cisco Systems Cisco Systems
Email: fred@cisco.com Email: fred@cisco.com
Joel M. Halpern Joel M. Halpern
Ericsson Ericsson
 End of changes. 53 change blocks. 
96 lines changed or deleted 98 lines changed or added

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