draft-ietf-savi-threat-scope-04.txt   draft-ietf-savi-threat-scope-05.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: September 3, 2011 Cisco Systems Expires: October 13, 2011 Cisco Systems
J. Halpern J. Halpern
Ericsson Ericsson
March 2, 2011 April 11, 2011
SAVI Threat Scope SAVI Threat Scope
draft-ietf-savi-threat-scope-04 draft-ietf-savi-threat-scope-05
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 September 3, 2011. This Internet-Draft will expire on October 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 3, line 12 skipping to change at page 3, line 12
5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . . 18 5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . . 18
5.3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . 19 5.3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . 19
6. Analysis of Host Granularity Anti-Spoofing . . . . . . . . . . 19 6. Analysis of Host Granularity Anti-Spoofing . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
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.
skipping to change at page 7, line 8 skipping to change at page 7, line 8
system sending a packet (e.g., TCP SYN) to a target system that system sending 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.
It would also contain a single value for port number, used as both It would also contain a single value for port number, used as both
the source and destination port number. Certain target systems will the source and destination port number. Certain target systems will
then "lock up" when creating connection state associated with the then "lock up" when creating connection state associated with the
packet, or would get stuck in a state where it continuously replies packet, or would get stuck in a state where it continuously replies
to itself. As this is an attack that relies on bugs in the target, to itself. As this is an attack that relies on bugs in the target,
it is possible, but by no means certain, that this threat is no it is possible, but by no means certain, that this threat is no
longer viable. longer viable.
Another form of blind attack is a RST probe. The attacker sends a Another form of blind attack is a RST probe [RFC0793]. The attacker
series of packets to a destination which is engaged in a long-lived sends a series of packets to a destination which is engaged in a
TCP session. The packets are RST packets, and the attacker uses the long-lived TCP session. The packets are RST packets, and the
known source and destination addresses and port numbers, along with attacker uses the known source and destination addresses and port
guesses at the sequence number. If he can send a packet close enough numbers, along with guesses at the sequence number. If he can send a
to the right value, in theory he can terminate the TCP connection. packet close enough to the right value, in theory he can terminate
While there are various steps that have been developed to ameliorate the TCP connection. While there are various steps that have been
this attack, preventing the spoofing of source addresses completely developed to ameliorate this attack, preventing the spoofing of
prevents the attack from occuring. 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.
skipping to change at page 10, line 22 skipping to change at page 10, line 22
may wish 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, 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 MAC address. Similar vulnerabilities target(s) now map to it's own MAC address. Similar vulnerabilities
exist in IPv6 NDP. exist in IPv6 NDP [RFC4861].
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 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 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,
skipping to change at page 13, line 41 skipping to change at page 13, line 41
4.1.4. ISP NNI Router to ISP NNI Router 4.1.4. ISP NNI Router to ISP NNI Router
The considerations explicitly related to customer networks can also The considerations explicitly related to customer networks can also
be applied to neighboring ISPs. An interconnection agreement might be applied to neighboring ISPs. An interconnection agreement might
be written between two companies requiring network ingress filtering be written between two companies requiring network ingress filtering
policy be implemented on all customers connections. ISPs might, for policy be implemented on all customers connections. ISPs might, for
example, mark datagrams from neighboring ISPs that do not sign such a example, mark datagrams from neighboring ISPs that do not sign such a
contract or demonstrably do not behave in accordance with it as contract or demonstrably do not behave in accordance with it as
'untrusted'. Alternatively, the ISP might place untrusted prefixes 'untrusted'. Alternatively, the ISP might place untrusted prefixes
into a separate BGP community and use that to advertise the level of into a separate BGP community [RFC4271] and use that to advertise the
trust to its BGP peers. level of trust to its BGP peers.
In this case, uRPF is less effective as a verification tool, due to In this case, uRPF is less effective as a verification tool, due to
asymmetric routing. However, when it can be shown that spoofed asymmetric routing. However, when it can be shown that spoofed
addresses are present, the procedure can be applied. addresses are present, the procedure can be applied.
Part of the complication here is that in the abstract it is very Part of the complication here is that in the abstract it is very
difficult to know what addresses should appear in packets sent from difficult to know what addresses should appear in packets sent from
one ISP to another. Hence packet level filtering and enforcement is one ISP to another. Hence packet level filtering and enforcement is
very difficult at this point in the network. Whether one views this very difficult at this point in the network. Whether one views this
as specific to the NNI, or a general property of the Internet, it is as specific to the NNI, or a general property of the Internet, it is
skipping to change at page 15, line 41 skipping to change at page 15, line 41
For IPv4 the primary and very widely used automated address For IPv4 the primary and very widely used automated address
assignment technique is DHCP based address assignment. Controlling assignment technique is DHCP based address assignment. Controlling
where authoritative information can be sourced, coupled with sniffing where authoritative information can be sourced, coupled with sniffing
and enforcing the assignments is an effective technique, which can in and enforcing the assignments is an effective technique, which can in
many networks automatically provide sufficient binding information. many networks automatically provide sufficient binding information.
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. In both cases, SAVI binding establishment needs to be assignment. In both cases, SAVI binding establishment needs to be
tied to the state machines for these address assignment protocols, tied to the state machines for these address assignment protocols,
with appropriate message sniffing and enforcement. For DHCPv6 based with appropriate message sniffing and enforcement. For DHCPv6 based
techniques, it is also necessary to use classification techniques to techniques, it is also necessary to use classification techniques to
ensure that responses which are trusted actually come from ensure that responses which are trusted actually come from
authoritative sources. authoritative sources.
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
skipping to change at page 16, line 16 skipping to change at page 16, line 16
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 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 IPv4 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 NDP, SEND is not widely
used to date. used to date.
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
skipping to change at page 19, line 12 skipping to change at page 19, line 12
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
IPv6 introduces additional capabilities which indirectly complicate IPv6 introduces additional capabilities which indirectly complicate
the spoofing analysis. IPv6 introduces and recommends the use of the spoofing analysis. IPv6 introduces and recommends the use of
stateless address autoconfiguration (often referred to as SLAAC). SLAAC [RFC4862]. This allows hosts to determine their IP prefix,
This allows hosts to determine their IP prefix, select an IID, and select an IID, and then start communicating. While there are many
then start communicating. While there are many advantages to this, advantages to this, the absence of control interactions complicates
the absence of control interactions complicates the process of the process of behavioral enforcement.
behavioral enforcement.
An additional complication is the very large IID space. Again, this An additional complication is the very large IID 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 idiosyncrasies 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. For example, without claiming purposes, and a problem for others. For example, without claiming
the entire ID space, an on-link attacker may be able to generate the entire ID space, an on-link attacker may be able to generate
enough IP addresses to fill the Neighbor Discovery table space of the enough IP addresses to fill the Neighbor Discovery table space of the
skipping to change at page 21, line 35 skipping to change at page 21, line 34
[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.
10.2. Informative References 10.2. Informative References
[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.
[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
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 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
 End of changes. 13 change blocks. 
24 lines changed or deleted 36 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/