draft-ietf-savi-threat-scope-07.txt   draft-ietf-savi-threat-scope-08.txt 
SAVI D. McPherson SAVI D. McPherson
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Intended status: Informational F.J. Baker Intended status: Informational F.J. Baker
Expires: October 05, 2013 Cisco Systems Expires: October 12, 2013 Cisco Systems
J.M. Halpern J.M. Halpern
Ericsson Ericsson
April 03, 2013 April 10, 2013
SAVI Threat Scope SAVI Threat Scope
draft-ietf-savi-threat-scope-07 draft-ietf-savi-threat-scope-08
Abstract Abstract
Source Address Validation Improvement (SAVI) effort aims to Source Address Validation Improvement (SAVI) effort aims to
complement ingress filtering with finer-grained, standardized IP complement ingress filtering with finer-grained, standardized IP
source address validation. This document describes threats enabled source address validation. This document describes threats enabled
by IP source address spoofing both in the global and finer-grained by IP source address spoofing both in the global and finer-grained
context, describes currently available solutions and challenges, and context, describes currently available solutions and challenges, and
provides a starting point analysis for finer-grained (host provides a starting point analysis for finer-grained (host
granularity) anti-spoofing work. granularity) anti-spoofing work.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 05, 2013. This Internet-Draft will expire on October 12, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4
3. Spoofed-based Attack Vectors . . . . . . . . . . . . . . . . 5 3. Spoofed-based Attack Vectors . . . . . . . . . . . . . . . . 5
3.1. Blind Attacks . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Blind Attacks . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Single Packet Attacks . . . . . . . . . . . . . . . . 6 3.1.1. Single Packet Attacks . . . . . . . . . . . . . . . . 6
3.1.2. Flood-Based DoS . . . . . . . . . . . . . . . . . . . 6 3.1.2. Flood-Based DoS . . . . . . . . . . . . . . . . . . . 6
3.1.3. Poisoning Attacks . . . . . . . . . . . . . . . . . . 7 3.1.3. Poisoning Attacks . . . . . . . . . . . . . . . . . . 8
3.1.4. Spoof-based Worm/Malware Propagation . . . . . . . . 8 3.1.4. Spoof-based Worm/Malware Propagation . . . . . . . . 8
3.1.5. Reflective Attacks . . . . . . . . . . . . . . . . . 8 3.1.5. Reflective Attacks . . . . . . . . . . . . . . . . . 8
3.1.6. Accounting Subversion . . . . . . . . . . . . . . . . 8 3.1.6. Accounting Subversion . . . . . . . . . . . . . . . . 9
3.1.7. Other Blind Spoofing Attacks . . . . . . . . . . . . 9 3.1.7. Other Blind Spoofing Attacks . . . . . . . . . . . . 9
3.2. Non-Blind Attacks . . . . . . . . . . . . . . . . . . . . 9 3.2. Non-Blind Attacks . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Man in the Middle (MITM) . . . . . . . . . . . . . . 9 3.2.1. Man in the Middle (MITM) . . . . . . . . . . . . . . 9
3.2.2. Third Party Recon . . . . . . . . . . . . . . . . . . 10 3.2.2. Third Party Recon . . . . . . . . . . . . . . . . . . 10
3.2.3. Other Non-Blind Spoofing Attacks . . . . . . . . . . 10 3.2.3. Other Non-Blind Spoofing Attacks . . . . . . . . . . 10
4. Current Anti-Spoofing Solutions . . . . . . . . . . . . . . . 10 4. Current Anti-Spoofing Solutions . . . . . . . . . . . . . . . 10
4.1. Topological Locations for Enforcement . . . . . . . . . . 12 4.1. Topological Locations for Enforcement . . . . . . . . . . 12
4.1.1. Host to link layer neighbor via switch . . . . . . . 12 4.1.1. Host to link layer neighbor via switch . . . . . . . 12
4.1.2. Upstream Switches . . . . . . . . . . . . . . . . . . 12 4.1.2. Upstream Switches . . . . . . . . . . . . . . . . . . 13
4.1.3. Upstream Routers . . . . . . . . . . . . . . . . . . 13 4.1.3. Upstream Routers . . . . . . . . . . . . . . . . . . 13
4.1.4. ISP Edge PE Router . . . . . . . . . . . . . . . . . 13 4.1.4. ISP Edge PE Router . . . . . . . . . . . . . . . . . 13
4.1.5. ISP NNI Router to ISP NNI Router . . . . . . . . . . 13 4.1.5. ISP NNI Router to ISP NNI Router . . . . . . . . . . 14
4.1.6. Cable Modem Subscriber Access . . . . . . . . . . . . 14 4.1.6. Cable Modem Subscriber Access . . . . . . . . . . . . 14
4.1.7. DSL Subscriber Access . . . . . . . . . . . . . . . . 14 4.1.7. DSL Subscriber Access . . . . . . . . . . . . . . . . 15
4.2. Currently Available Tools . . . . . . . . . . . . . . . . 15 4.2. Currently Available Tools . . . . . . . . . . . . . . . . 15
4.2.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . 15 4.2.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Unicast RPF . . . . . . . . . . . . . . . . . . . . . 15 4.2.2. Unicast RPF . . . . . . . . . . . . . . . . . . . . . 15
4.2.3. Port-based Address Binding . . . . . . . . . . . . . 15 4.2.3. Port-based Address Binding . . . . . . . . . . . . . 15
4.2.4. Cryptographic Techniques . . . . . . . . . . . . . . 16 4.2.4. Cryptographic Techniques . . . . . . . . . . . . . . 17
4.2.5. Residual Attacks . . . . . . . . . . . . . . . . . . 17 4.2.5. Residual Attacks . . . . . . . . . . . . . . . . . . 17
5. Topological Challenges Facing SAVI . . . . . . . . . . . . . 17 5. Topological Challenges Facing SAVI . . . . . . . . . . . . . 17
5.1. Address Provisioning Mechanisms . . . . . . . . . . . . . 17 5.1. Address Provisioning Mechanisms . . . . . . . . . . . . . 17
5.2. LAN devices with Multiple Addresses . . . . . . . . . . . 17 5.2. LAN devices with Multiple Addresses . . . . . . . . . . . 18
5.2.1. Routers . . . . . . . . . . . . . . . . . . . . . . . 17 5.2.1. Routers . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.3. Multi-Instance Hosts . . . . . . . . . . . . . . . . 18 5.2.3. Multi-Instance Hosts . . . . . . . . . . . . . . . . 18
5.2.4. Multi-LAN Hosts . . . . . . . . . . . . . . . . . . . 18 5.2.4. Multi-LAN Hosts . . . . . . . . . . . . . . . . . . . 19
5.2.5. Firewalls . . . . . . . . . . . . . . . . . . . . . . 19 5.2.5. Firewalls . . . . . . . . . . . . . . . . . . . . . . 20
5.2.6. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 19 5.2.6. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 20
5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . 19 5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . 20
5.3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . 19 5.3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . 20
6. Analysis of Host Granularity Anti-Spoofing . . . . . . . . . 20 6. Analysis of Host Granularity Anti-Spoofing . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8.1. Privacy Considerations . . . . . . . . . . . . . . . . . 22 8.1. Privacy Considerations . . . . . . . . . . . . . . . . . 23
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Overview 1. Overview
The Internet Protocol, specifically IPv4 [RFC0791] and IPv6 The Internet Protocol, specifically IPv4 [RFC0791] and IPv6
[RFC2460], employ a connectionless hop-by-hop packet forwarding [RFC2460], employ a connectionless hop-by-hop packet forwarding
paradigm. A host connected to an IP network that wishes to paradigm. A host connected to an IP network that wishes to
communicate with another host on the network generates an IP packet communicate with another host on the network generates an IP packet
with source and destination IP addressing information, among other with source and destination IP addressing information, among other
options. options.
At the IP Network Layer, or Internet Layer, there is typically no At the IP Network Layer, or Internet Layer, there is typically no
required transactional state when communicating with other hosts on required transactional state when communicating with other hosts on
the network. In particular, the network does not track any state the network. In particular, the network does not track any state
about the hosts using the network. This is normally a benefit. about the hosts using the network. This is normally a benefit.
However, as a consequence of this, hosts generating packets for However, as a consequence of this, hosts generating packets for
transmission have the opportunity to spoof (forge) the source address transmission have the opportunity to spoof (forge) the source address
of packets which they transmit, as the network does not have any way of packets which they transmit, as the network does not have any way
to tell that some of the information is false. to tell that some of the information is false.
Source address validation is necessary in order to detect and reject Source address validation is necessary in order to detect and reject
spoofed packets at the IP layer in the network, and contributes to IP spoofed packets in the network, and contributes to the overall
the overall security of IP networks. This draft deals with the security of IP networks. This draft deals with the subset of such
subset of such validation done by the network based on observed validation done by the network based on observed traffic and policy.
traffic and policy. Such source address validation techniques enable Such source address validation techniques enable detection and
detection and rejection of many spoofed packets, and also implicitly rejection of many spoofed packets, and also implicitly provide some
provide some assurances that the source address in an IP packet is assurances that the source address in an IP packet is legitimately
legitimately assigned to the system that generated the packet. assigned to the system that generated the packet.
Solutions such as BCP 38 [RFC2827] provide guidelines for one such Solutions such as BCP 38 [RFC2827] provide guidelines for one such
technique for network ingress filtering. However, if these technique for network ingress filtering. However, if these
techniques are not implemented at the ingress point of the IP techniques are not implemented at the ingress point of the IP
network, then the validity of the source address cannot be positively network, then the validity of the source address cannot be positively
ascertained. Furthermore, BCP 38 only implies source address ascertained. Furthermore, BCP 38 only implies source address
validation at the Internet Layer, and is most often implemented on IP validation at the Internet Layer, and is most often implemented on IP
subnetwork address boundaries. One of the difficulties in subnetwork address boundaries. One of the difficulties in
encouraging the deployment of BCP 38 is that there is relatively encouraging the deployment of BCP 38 is that there is relatively
little benefit until it is very widely deployed, which is not yet the little benefit until it is very widely deployed, which is not yet the
case. case.
Hence, in order to try to get better behavior, it is helpful to look Hence, in order to try to get better behavior, it is helpful to look
for an application like BCP 38, but one which can be applied locally, for an application like BCP 38, but one which can be applied locally,
and give locally beneficial results. The local benefit would provide and give locally beneficial results. The local benefit would provide
a reason for the site to deploy, while moving the Internet as a whole a reason for the site to deploy, while moving the Internet as a whole
towards an environment where BCP 38 is widely effected. SAVI is towards an environment where BCP 38 is widely effected. SAVI is
aimed at providing locally more specific protection, with the benefit aimed at providing locally more specific protection, with the benefit
of better local behavior and local traceability, while also providing of better local behavior and, in conjunction with appropriate
better compliance with the cases dealt with by BCP 38. logging, better local traceability, while also providing better
compliance with the cases dealt with by BCP 38.
It should be noted that while BCP 38 directs providers to provide It should be noted that while BCP 38 directs providers to provide
protection from spoofed prefixes, it is clearly desirable for protection from spoofed prefixes, it is clearly desirable for
enterprise operators to provide that protection more locally, and enterprise operators to provide that protection more locally, and
with better traceability. This allows the enterprise to be a better with better traceability. This allows the enterprise to be a better
Internet participant, and to quickly detect and remedy problems when Internet participant, and to quickly detect and remedy problems when
they occur. For example, when an enterprise receives a report of an they occur. For example, when an enterprise receives a report of an
attack originating within that enterprise, the operational staff attack originating within that enterprise, the operational staff
desires to be able to track from the IP address sourcing the attack desires to be able to track from the IP address sourcing the attack
to the particular machine within the enterprise that is the source. to the particular machine within the enterprise that is the source.
This is typically simpler and more reliable than other techniques, This is typically simpler and more reliable than other techniques,
such as trying to find the attack in ongoing outbound traffic To do such as trying to find the attack in ongoing outbound traffic To do
this, the enterprise needs both that the address assignment and usage this, the enterprise needs both that the address assignment and usage
information be usable (logging), and that the information be information be usable (appropriate logging), and that the information
accurate, i.e. that no other machine could have been using that be accurate (SAVI), i.e. that no other machine could have been using
address. that address.
Also, there is a possibility that in a LAN environment where multiple Also, there is a possibility that in a LAN environment where multiple
hosts share a single LAN or IP port on a switch or router, one of hosts share a single LAN or IP port on a switch or router, one of
those hosts may spoof the source addresses of other hosts within the those hosts may spoof the source addresses of other hosts within the
local subnet. Understanding these threats and the relevant local subnet. Understanding these threats and the relevant
topologies in which they're introduced is critical when assessing the topologies in which they're introduced is critical when assessing the
threats that exist with source address spoofing. threats that exist with source address spoofing.
This document provides additional details regarding spoofed-based This document provides additional details regarding spoofed-based
threat vectors, and discuss implications of various network threat vectors, and discuss implications of various network
skipping to change at page 5, line 27 skipping to change at page 5, line 27
NNI Router: Network to Network Interface Router. This router NNI Router: Network to Network Interface Router. This router
interface faces a similar system operated by another ISP or other interface faces a similar system operated by another ISP or other
large network. large network.
PE Router: Provider Edge Router. This router faces a customer of an PE Router: Provider Edge Router. This router faces a customer of an
ISP. ISP.
Spoofing: The act of sending a datagram header whose contents at the Spoofing: The act of sending a datagram header whose contents at the
Link or Network Layer do not match the network policies and Link or Network Layer do not match the network policies and
activities on address assignment or claiming. Generally, this activities on address assignment or claiming. Generally, this
corresponds o sending messages with source network or link layer corresponds to sending messages with source network or link layer
information that is assigned to or properly claimed by some other information that is assigned to or curretly properly claimed by
devices in the network some other devices in the network
TCP: The Transmission Control Protocol, used on end systems to TCP: The Transmission Control Protocol, used on end systems to
manage data exchange. manage data exchange.
uRPF: Unicast Reverse Path Forwarding. A procedure in which the uRPF: Unicast Reverse Path Forwarding. A procedure in which the
route table, which is usually used to look up destination route table, which is usually used to look up destination
addresses and route towards them, is used to look up the source addresses and route towards them, is used to look up the source
address and ensure that one is routing away from it. When this address and ensure that one is routing away from it. When this
test fails, the event may be logged, and the traffic is commonly test fails, the event may be logged, and the traffic is commonly
dropped. dropped.
skipping to change at page 6, line 23 skipping to change at page 6, line 23
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 (Denial of Service) attacks", involves an attacking system packet DoS (Denial of Service) attacks", involves an attacking system
injecting spoofed information into the network which results in injecting spoofed information into the network which results in
either a complete crash of the target system, or in some manner either a complete crash of the target system, or in some manner
poisons some network configuration or other information on a target poisons some network configuration or other information on a target
system so as to impact network or other services. system so as to impact network or other services.
An example of an attack that can cause a receiving system to crash is An example of an attack that can cause a receiving system to crash is
what is called a LAND attack. A LAND attack packet would consist of what is called a LAND (Local Area Network Denial) attack. A LAND
an attacking system sending a packet (e.g., TCP SYN) to a target attack packet would consist of an attacking system sending a packet
system that contains both a source and destination address of that (e.g., TCP SYN) to a target system that contains both a source and
target system. It would also contain a single value for port number, destination address of that target system. It would also contain a
used as both the source and destination port number. Certain target single value for port number, used as both the source and destination
systems will then "lock up" when creating connection state associated port number. Certain target systems will then "lock up" when
with the packet, or would get stuck in a state where it continuously creating connection state associated with the packet, or would get
replies to itself. As this is an attack that relies on bugs in the stuck in a state where it continuously replies to itself. As this is
target, it is possible, but by no means certain, that this threat is an attack that relies on bugs in the target, it is possible, but by
no longer viable. no means certain, that this threat is no longer viable.
Another form of blind attack is a RST probe [RFC0793]. The attacker Another form of blind attack is a RST probe [RFC4953] (section 2.3).
sends a series of packets to a destination which is engaged in a The attacker sends a series of packets to a destination which is
long-lived TCP session. The packets are RST packets, and the engaged in a long-lived TCP session. The packets are RST packets,
attacker uses the known source and destination addresses and port and the attacker uses the known source and destination addresses and
numbers, along with guesses at the sequence number. If he can send a port numbers, along with guesses at the sequence number. If he can
packet close enough to the right value, in theory he can terminate send a packet close enough to the right value, in theory he can
the TCP connection. While there are various steps that have been terminate the TCP connection. While there are various steps that
developed to ameliorate this attack, preventing the spoofing of have been developed to ameliorate this attack, preventing the
source addresses completely prevents the attack from occuring. spoofing of source addresses completely prevents the attack from
occuring.
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.
Because these attacks require no reply from the target system and Because these attacks require no reply from the target system and
require no legitimate transaction state, attackers often attempt to require no legitimate transaction state, attackers often attempt to
skipping to change at page 9, line 51 skipping to change at page 10, line 9
For example, an attacker with access to a host on LAN segment may For example, an attacker with access to a host on LAN segment may
wish to redirect all the traffic on the local segment destined for a wish to redirect all the traffic on the local segment destined for a
default gateway address (or all addresses) to itself in order to default gateway address (or all addresses) to itself in order to
perform man-in-the-middle attacks. In order to accomplish this, in perform man-in-the-middle attacks. In order to accomplish this, in
IPv4 the attacker might transmit gratuitous ARP [RFC0826] messages or IPv4 the attacker might transmit gratuitous ARP [RFC0826] messages or
ARP replies to the Ethernet broadcast address ff:ff:ff:ff:ff:ff, ARP replies to the Ethernet broadcast address ff:ff:ff:ff:ff:ff,
notifying all the hosts on the segment that the IP address(es) of the notifying all the hosts on the segment that the IP address(es) of the
target(s) now map to it's own Layer 2 address. The source IP address target(s) now map to it's own Layer 2 address. The source IP address
in this case is spoofed. Similar vulnerabilities exist in IPv6 NDP in this case is spoofed. Similar vulnerabilities exist in IPv6 NDP
[RFC4861]. [RFC4861], although the multicast requirements of IPv6 NDP make this
harder to perform with the same generality.
3.2.2. Third Party Recon 3.2.2. Third Party Recon
Another example of sighted attack is third party reconnaissance. The Another example of non-blind attack is third party reconnaissance.
use of spoofed addresses, while not necessary for this, can often The use of spoofed addresses, while not necessary for this, can often
provide additional information, and helps mask the traceability of provide additional information, and helps mask the traceability of
the activity. The attack involves sending packets towards a given the activity. The attack involves sending packets towards a given
target system and observing either target or intermediate system target system and observing either target or intermediate system
responses. For example, if an attacker were to source spoof TCP SYN responses. For example, if an attacker were to source spoof TCP SYN
packets towards a target system from a large set of source addresses, packets towards a target system from a large set of source addresses,
and observe responses from that target system or some intermediate and observe responses from that target system or some intermediate
firewall or other middle box, they would be able to identify what IP firewall or other middle box, they would be able to identify what IP
layer filtering policies may be in place to protect that system. layer filtering policies may be in place to protect that system.
3.2.3. Other Non-Blind Spoofing Attacks 3.2.3. Other Non-Blind Spoofing Attacks
skipping to change at page 10, line 51 skipping to change at page 11, line 11
the physical topology; for example, the source address is the physical topology; for example, the source address is
appropriate for the layer 2 switch port through which the datagram appropriate for the layer 2 switch port through which the datagram
was received. was received.
o The prefix to which the IP source address belongs is appropriate o The prefix to which the IP source address belongs is appropriate
for the part of the network topology from which the IP datagram for the part of the network topology from which the IP datagram
was received (while the individual system may be unknown, it is was received (while the individual system may be unknown, it is
reasonable to believe that the system is located in that part of reasonable to believe that the system is located in that part of
the network). the network).
In general, this involves two kinds of inspection. The primary
action is checking the source IP address in the IP header of IP
packets. In order to support such checking, the claimed or assigned
IP addresses in messages concerned with such claims or assignments
(IP ARP Requests and Responses, DHCP Replies, IPv6 ND DAD messages,
etc.) must also be examined and where appropriate verified. SAVI is
not concerned with verifying IP addresses in the contents of
arbitrary higher level protocol messages.
Filtering points farther away from the source of the datagram can Filtering points farther away from the source of the datagram can
make decreasingly authoritative assertions about the validity of the make decreasingly authoritative assertions about the validity of the
source address in the datagram. Nonetheless, there is value in source address in the datagram. Nonetheless, there is value in
dropping traffic that is clearly inappropriate, and in maintaining dropping traffic that is clearly inappropriate, and in maintaining
knowledge of the level of trust one can place in an address. knowledge of the level of trust one can place in an address.
Edge Network 1 CPE-ISP _.------------. Edge Network 1 CPE-ISP _.------------.
_.----------------. Ingress/ ISP A `--. _.----------------. Ingress/ ISP A `--.
,--'' `---. ,' `. ,--'' `---. ,' `.
,' +----+ +------+ +------+ `. / +------+ +------+ \\ ,' +----+ +------+ +------+ `. / +------+ +------+ \\
skipping to change at page 15, line 36 skipping to change at page 16, line 5
4.2.3. Port-based Address Binding 4.2.3. Port-based Address Binding
Much of the work of SAVI is initially targeting minimizing source Much of the work of SAVI is initially targeting minimizing source
address spoofing in the LAN. In particular, if mechanisms can be address spoofing in the LAN. In particular, if mechanisms can be
defined to accommodate configuration of port binding information for defined to accommodate configuration of port binding information for
IP, either to a port, to an an unchangeable or authenticated MAC IP, either to a port, to an an unchangeable or authenticated MAC
address, or to other credentials in the packet such that an impostor address, or to other credentials in the packet such that an impostor
can not create the needed values, a large portion of the spoofing can not create the needed values, a large portion of the spoofing
threat space in the LAN can be marginalized. threat space in the LAN can be marginalized.
However, establishing this binding is not trivial, and varying across However, establishing this binding is not trivial, and varyies across
both topologies type and address allocation mechanisms. both topology types and address allocation mechanisms.
4.2.3.1. Manual Binding 4.2.3.1. Manual Binding
Binding of a single Link Layer and Network Layer address to a port Binding of a single Link Layer and Network Layer address to a port
may initially seem trivial. However, two primary areas exist that may initially seem trivial. However, two primary areas exist that
can complicate such techniques. In particular, these areas involve can complicate such techniques. In particular, these areas involve
topologies where more than a single IP layer address may be topologies where more than a single IP layer address may be
associated with a MAC address on a given port, or where multiple associated with a MAC address on a given port, or where multiple
hosts are connected via a single physical port. Furthermore, if one hosts are connected via a single physical port. Furthermore, if one
or more dynamic address allocation mechanisms such as DHCP are or more dynamic address allocation mechanisms such as DHCP are
skipping to change at page 16, line 23 skipping to change at page 16, line 39
can create the bindings needed for address usage enforcement. can create the bindings needed for address usage enforcement.
For IPv6, there are two common automated address assignment For IPv6, there are two common automated address assignment
techniques. While there are many variations and details, for techniques. While there are many variations and details, for
purposes of understanding the threats and basic responses, these are purposes of understanding the threats and basic responses, these are
Stateless Address Autoconfiguration (SLAAC) and DHCPv6 based address Stateless Address Autoconfiguration (SLAAC) and DHCPv6 based address
assignment. For DHCP based IPv6 address assignment, the techniques assignment. For DHCP based IPv6 address assignment, the techniques
above are applicable and suitable. above are applicable and suitable.
When SLAAC is used for IPv address assignment, the switches can When SLAAC is used for IPv address assignment, the switches can
observe the SLAAC messages and use those to create the enforcement observe the duplicate address detection messages and use those to
bindings. This enables the switches to ensure that only properly create the enforcement bindings. This enables the switches to ensure
claimed IP addresses are used for data traffic. It does not enforce that only properly claimed IP addresses are used for data traffic.
that these addresses are assigned to the hosts, since SLAAC does not It does not enforce that these addresses are assigned to the hosts,
have a notion of address assignment. since SLAAC does not have a notion of address assignment.
4.2.3.3. IEEE 802.1x 4.2.3.3. IEEE 802.1x
IEEE 802.1x is an authentication protocol that permits a network to IEEE 802.1x is an authentication protocol that permits a network to
determine the identity of a user seeking to join it and apply determine the identity of a user seeking to join it and apply
authorization rules to permit or deny the action. In and of authorization rules to permit or deny the action. In and of
themselves, such tools confirm only that the user is authorized to themselves, such tools confirm only that the user is authorized to
use the network, but do not enforce what IP address the user is use the network, but do not enforce what IP address the user is
allowed to use. It is worth noting that elements of 802.1x may well allowed to use. It is worth noting that elements of 802.1x may well
be useful as binding anchors for SAVI solutions. be useful as binding anchors for SAVI solutions.
4.2.4. Cryptographic Techniques 4.2.4. Cryptographic Techniques
skipping to change at page 16, line 41 skipping to change at page 17, line 14
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 user seeking to join it and apply determine the identity of a user seeking to join it and apply
authorization rules to permit or deny the action. In and of authorization rules to permit or deny the action. In and of
themselves, such tools confirm only that the user is authorized to themselves, such tools confirm only that the user is authorized to
use the network, but do not enforce what IP address the user is use the network, but do not enforce what IP address the user is
allowed to use. It is worth noting that elements of 802.1x may well allowed to use. It is worth noting that elements of 802.1x may well
be useful as binding anchors for SAVI solutions. be useful as binding anchors for SAVI solutions.
4.2.4. Cryptographic Techniques 4.2.4. Cryptographic Techniques
Needless to say, MITM and replay attacks can typically be mitigated MITM and replay attacks can typically be mitigated with cryptographic
with cryptographic techniques. However, many of the applications techniques. However, many of the applications today either don't or
today either don't or can't employ cryptographic authentication and can't employ cryptographic authentication and protection mechanisms.
protection mechanisms. ARP for IPv4 does not use such protection. ARP for IPv4 does not use such protection. While SEND provides such
While SEND provides such protection for IPv6 NDP, SEND is not widely protection for IPv6 NDP, SEND is not widely used to date. Usage of
used to date. Usage of such techniques is outside the scope of this such techniques is outside the scope of this document.
document.
While DNSSEC will significantly help protect DNS from the effects of While DNSSEC will significantly help protect DNS from the effects of
spoof based poisoning attacks, such protection does not help protect spoof based poisoning attacks, such protection does not help protect
the rest of the network from spoofed attacks. the rest of the network from spoofed attacks.
4.2.5. Residual Attacks 4.2.5. Residual Attacks
It should be understood that not all combinations of network, service It should be understood that not all combinations of network, service
and enforcement choices will result in a protectable network. For and enforcement choices will result in a protectable network. For
example, if one uses conventional SLAAC, in a switched network, but example, if one uses conventional SLAAC, in a switched network, but
skipping to change at page 17, line 35 skipping to change at page 18, line 7
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 port-MAC- From the perspective of network topology, consider hosts connected to
IP bindings, hosts connected to switch ports that may have one or switch ports that may have one or more IP addresses, and devices that
more IP addresses, or certainly, devices that forward packets from forward packets from other network segments. It is much harder to
other network segments, present traffic that is much harder to make enforce port-MAC-IP bindings on traffic from such hosts and devices,
subject to such bindings and enforcement. than for traffic from more simply-conencted devices.
5.2.1. Routers 5.2.1. Routers
The most obvious example of devices that are problematic when Routers are the most obvious examples of devices for which it is
attempting to implement port-MAC-IP bindings is that of routers. problematic to implement port-MAC-IP bindings. Routers not only
Routers not only originate packets themselves and often have multiple originate packets themselves and often have multiple interfaces, but
interfaces, but also forward packets from other network segments. As also forward packets from other network segments. As a result, it's
a result, it's difficult for port-MAC-IP binding rules to be difficult for port-MAC-IP binding rules to be established a priori,
established a priori, because it's likely that many addresses and IP because it's likely that many addresses and IP subnets should be
subnets should be associated with the port-MAC in question. 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
becomes problematic, for the same reasons as routers. Because they Validating traffic from Prefix-based and multi-address NATs is also
may forward traffic from an array of address, a priori knowledge must problematic, for the same reasons as for routers. Because they may
exist providing what IPs should be associated with a given port-MAC forward traffic from an array of addresses, validation requires
pair. advance knowledge of what IPs should be associated with a given port-
MAC 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, e.g. with internal blades each When the device is a blade server, e.g. with internal blades each
hosting a physical machine, there is essentially a physical switch hosting a physical machine, there is essentially a physical switch
inside the blade server. While tractable, this creates some inside the blade server. While feasible, this creates some
complexity for determining where enforcement logic can or should complexity for determining where enforcement logic can or should
live. 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 virtual machines, each with IP and MAC addresses, multiple internal virtual machines. Each virutal machine may have
and what is essentially (or sometimes literally) an internal LAN it's own IP and MAC addresses. These ae conected by what is
switch. While it may be possible for this internal switch to help essentially (or sometimes literally) an internal LAN switch. While
control threats among the virtual hosts, or between virtual hosts and this internal switch may be a SAVI enforcemet point to help control
other parts of the network, such enforcement cannot be counted on at threats among the virtual hosts, or between virtual hosts and other
this time. parts of the network, such enforcement cannot be counted on i ll
implementations. If the virtual machines are interconnected by the
interal switch, than that logical device is the first switch for the
purposes of this analysis.
A further complication with multi-instance hosts is that in many A further complication with multi-instance hosts is that in many
environments these hosts may move while retaining their IP addresses. environments these hosts may move while retaining their IP addresses.
This can be an actual relocation of the running software, or a backup This can be an actual relocation of the running software, or a backup
instance taking over the functions of the software. In both cases, instance taking over the functions of the software. In both cases,
the IP address will appear at a new topological location. Depending the IP address will appear at a new topological location. Depending
upon the protocols used, it may have the same MAC address or upon the protocols used, it may have the same MAC address or
different one, and the system may or may not issue a gratuitous ARP different one, and the system may or may not issue a gratuitous ARP
request after relocation. When such a move is done without changing request after relocation. When such a move is done without changing
the MAC address, the SAVI switches will need to update their state. the MAC address, the SAVI switches will need to update their state.
skipping to change at page 19, line 38 skipping to change at page 20, line 30
mobile hosts comply with source address validity requirements.) 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. Thus, if the
Mobile IP home agent is trusted, it can itself perform IP Source
address checking on the packets it forwards on behalf of mobile
nodes. This would utilize bindings established by the Mobile IP
registration mechanisms.
5.2.7. Other Topologies 5.2.7. Other Topologies
Any topology that results in the possibility that a device connected Any topology that results in the possibility that a device connected
to a switch port may forward packets with more than a single source to a switch port may forward packets with more than a single source
address for packet which it originated may be problematic. address for packet which it originated may be problematic.
Additionally, address allocation schemas introduce additional Additionally, address allocation schemas introduce additional
considerations when examining a given SAVI solutions space. considerations when examining a given SAVI solutions space.
5.3. IPv6 Considerations 5.3. IPv6 Considerations
skipping to change at page 20, line 44 skipping to change at page 21, line 40
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 detected, either within a site, above. When a security incident is detected, either within a site,
or externally (and traced to the site) it can be critical to or externally (and traced to the site) it can be critical to
determine what the actual source of the incident was. If address determine what the actual source of the incident was. If address
usage can be tied to the kinds of anchors described earlier, then it usage can be tied to the kinds of anchors described earlier, this can
is possible to respond to security incidents. help in responding to security incidents.
In addition to these local observable benefits, there can be more In addition to these local observable benefits, there can be more
global benefits. For example, if address usage is tied to anchors, global benefits. For example, if address usage is tied to anchors,
it may be possible to prevent or control the use of large numbers of it may be possible to prevent or control the use of large numbers of
anonymous IPv6 addresses for attacks, or at least to track even those anonymous IPv6 addresses for attacks, or at least to track even those
attacks back to their source. attacks back to their source.
As described below in the security considerations, these operational As described below in the security considerations, these operational
behaviors need to be evaluated in the context of the reduction in behaviors need to be evaluated in the context of the reduction in
user privacy implied if one logs traffic bindings. In particular, in user privacy implied if one logs traffic bindings. In particular, in
skipping to change at page 21, line 45 skipping to change at page 22, line 40
In the Internet Layer, the source address of a datagram should be the In the Internet Layer, the source address of a datagram should be the
address of the system that originated it and to which any reply is address of the system that originated it and to which any reply is
expected to come. But systems fall into several broad categories. expected to come. But systems fall into several broad categories.
Many are single user systems, such as laptops and PDAs. Multi-user Many are single user systems, such as laptops and PDAs. Multi-user
systems are commonly used in industry, and a wide variety of systems are commonly used in industry, and a wide variety of
middleware systems and application servers have no user at all, but middleware systems and application servers have no user at all, but
by design relay messages or perform services on behalf of users of by design relay messages or perform services on behalf of users of
other systems (e.g., SMTP and peer-to-peer file sharing). other systems (e.g., SMTP and peer-to-peer file sharing).
Until every Internet-connected network implements source address Even if 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 cannot be used as an authentication mechanism. The
The only technique to unquestionably validate source addresses of a only technique to unquestionably validate source addresses of a
received datagram are cryptographic authentication mechanisms such as received datagram are cryptographic authentication mechanisms such as
IPsec. IPsec.
It must be presume that there will be some failure modes in any SAVI It must be presume that there will be some failure modes in any SAVI
deployment, given the history of technical security mechanisms. A deployment, given the history of technical security mechanisms. A
possible attack to be considered by network administrators is an possible attack to be considered by network administrators is an
inside attack probing the network for modes of spoofing that can be inside attack probing the network for modes of spoofing that can be
accomplished. If the probes are conducted at a level below alarm accomplished. If the probes are conducted at a level below alarm
thresholds, this might allow an internal attacker to safely determine thresholds, this might allow an internal attacker to safely determine
what spoof modes he can use. Thus, the use of these techniques must what spoof modes he can use. Thus, the use of these techniques must
be managed in such a way as to avoid giving a false sense of security be managed in such a way as to avoid giving a false sense of security
to the network administrator. to the network administrator.
8.1. Privacy Considerations 8.1. Privacy Considerations
It should be understood that enforcing and recording IP address It should be understood that enforcing and recording IP address
bindings has privacy implications. In general, collecting private bindings has privacy implications. In some circumstances this
information about users brings ethical and legal responsibilities to binding data may be considerd to be personally identifying
the network administrator. information. In general, collecting private information about users
brings ethical and legal responsibilities to the network
administrator.
For this reason, the collection and retention of logged binding
information needs to be considered carefully. Prevention of spoofing
does not in itself require suhc retnetion. Analysis of immediate
events may rely on having logs of current bindings. Thus, privacy
issues can be ameliorated by removing binding logs after the binding
lifetimes expire. Logs of apparent spoof attempts are a separate
matter, and may require longer retention to detect patterns of
deliberate or accidental abuse.
With operations of the type described here, the network administrator With operations of the type described here, the network administrator
is collecting information about where on his network the user is is collecting information about where on his network the user is
active. In addition, the recorded bindings supplement address usage active. In addition, the recorded bindings supplement address usage
information about users that is available from DHCP logs. For information about users that is available from DHCP logs. For
example, if IPv6 SLAAC is being used, ad IP to Layer 2 address example, if IPv6 SLAAC is being used, ad IP to Layer 2 address
bindings are being logged, the administrator will have access to bindings are being logged, the administrator will have access to
information associating users with their IP addresses even if IPv6 information associating users with their IP addresses even if IPv6
privacy addresses are used. privacy addresses are used.
skipping to change at page 23, line 24 skipping to change at page 24, line 27
[I-D.baker-sava-operational] [I-D.baker-sava-operational]
Baker, F. and R. Droms, "IPv4/IPv6 Source Address Baker, F. and R. Droms, "IPv4/IPv6 Source Address
Verification", draft-baker-sava-operational-00 (work in Verification", draft-baker-sava-operational-00 (work in
progress), June 2007. progress), June 2007.
[IEEE802.3ad] [IEEE802.3ad]
Standards Association, IEEE., "IEEE 801.1AX-2008, IEEE Standards Association, IEEE., "IEEE 801.1AX-2008, IEEE
Standard for Local and Metropolitan Area Networks - Link Standard for Local and Metropolitan Area Networks - Link
Aggregation", 2008. Aggregation", 2008.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37, address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982. RFC 826, November 1982.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
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
skipping to change at page 23, line 49 skipping to change at page 24, line 49
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC
4953, July 2007.
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
 End of changes. 41 change blocks. 
118 lines changed or deleted 147 lines changed or added

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