Request for Comments: 4218 Sun Microsystems
Category: Informational T. Li
October 2005
Threats Relating to IPv6 Multihoming Solutions
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document lists security threats related to IPv6 multihoming.
Multihoming can introduce new opportunities to redirect packets to
different, unintended IP addresses.
The intent is to look at how IPv6 multihoming solutions might make
the Internet less secure; we examine threats that are inherent to all
IPv6 multihoming solutions rather than study any specific proposed
solution. The threats in this document build upon the threats
discovered and discussed as part of the Mobile IPv6 work.
Table of Contents
1. Introduction ....................................................2
1.1. Assumptions ................................................3
1.2. Authentication, Authorization, and Identifier Ownership ....4
2. Terminology .....................................................5
3. Today’s Assumptions and Attacks .................................6
3.1. Application Assumptions ....................................6
3.2. Redirection Attacks Today ..................................8
3.3. Packet Injection Attacks Today .............................9
3.4. Flooding Attacks Today ....................................10
3.5. Address Privacy Today .....................................11
4. Potential New Attacks ..........................................13
4.1. Cause Packets to Be Sent to the Attacker ..................13
4.1.1. Once Packets Are Flowing ...........................13
4.1.2. Time-Shifting Attack ...............................14
4.1.3. Premeditated Redirection ...........................14
4.1.4. Using Replay Attacks ...............................15
4.2. Cause Packets to Be Sent to a Black Hole ..................15
4.3. Third Party Denial-of-Service Attacks .....................16
4.3.1. Basic Third Party DoS ..............................17
4.3.2. Third Party DoS with On-Path Help ..................18
4.4. Accepting Packets from Unknown Locators ...................19
4.5. New Privacy Considerations ................................20
5. Granularity of Redirection .....................................20
6. Movement Implications? .........................................22
7. Other Security Concerns ........................................23
8. Security Considerations ........................................24
9. Acknowledgements ...............................................24
10. Informative References ........................................25
Appendix A: Some Security Analysis ................................27
1. Introduction
The goal of the IPv6 multihoming work is to allow a site to take
advantage of multiple attachments to the global Internet, without
having a specific entry for the site visible in the global routing
table. Specifically, a solution should allow hosts to use multiple
attachments in parallel, or to switch between these attachment points
dynamically in the case of failures, without an impact on the
transport and application layer protocols.
At the highest level, the concerns about allowing such "rehoming" of
packet flows can be called "redirection attacks"; the ability to
cause packets to be sent to a place that isn’t tied to the transport
and/or application layer protocol’s notion of the peer. These
attacks pose threats against confidentiality, integrity, and
availability. That is, an attacker might learn the contents of a
particular flow by redirecting it to a location where the attacker
has a packet recorder. If, instead of a recorder, the attacker
changes the packets and then forwards them to the ultimate
destination, the integrity of the data stream would be compromised.
Finally, the attacker can simply use the redirection of a flow as a
denial of service attack.
This document has been developed while considering multihoming
solutions architected around a separation of network identity and
network location, whether or not this separation implies the
introduction of a new and separate identifier name space. However,
this separation is not a requirement for all threats, so this
taxonomy may also apply to other approaches. This document is not
intended to examine any single proposed solution. Rather, it is
intended as an aid to discussion and evaluation of proposed
solutions. By cataloging known threats, we can help to ensure that
all proposals deal with all of the available threats.
As a result of not analyzing a particular solution, this document is
inherently incomplete. An actual solution would need to be analyzed
as part of its own threat analysis, especially in the following
areas:
1) If the solution makes the split between locators and identifiers,
then most application security mechanisms should be tied to the
identifier, not to the locator. Therefore, work would be needed
to understand how attacks on the identifier mechanism affect
security, especially attacks on the mechanism that would bind
locators to identifiers.
2) How does the solution apply multihoming to IP multicast?
Depending on how this is done, there might be specific threats
relating to multicast that need to be understood. This document
does not discuss any multicast-specific threats.
3) Connection-less transport protocols probably need more attention.
They are already difficult to secure, even without a
locator/identifier split.
1.1. Assumptions
This threat analysis doesn’t assume that security has been applied to
other security relevant parts of the Internet, such as DNS and
routing protocols; but it does assume that, at some point in time, at
least parts of the Internet will be operating with security for such
key infrastructure. With that assumption, it then becomes important
that a multihoming solution would not, at that point in time, become
the weakest link. This is the case even if, for instance, insecure
DNS might be the weakest link today.
This document doesn’t assume that the application protocols are
protected by strong security today or in the future. However, it is
still useful to assume that the application protocols that care about
integrity and/or confidentiality apply the relevant end-to-end
security measures, such as IPsec, TLS, and/or application layer
security.
For simplicity, this document assumes that an on-path attacker can
see packets, modify packets and send them out, and block packets from
being delivered. This is a simplification because there might exist
ways (for instance, monitoring capability in switches) that allow
authenticated and authorized users to observe packets without being
able to send or block the packets.
In some cases it might make sense to make a distinction between
on-path attackers, which can monitor packets and perhaps also inject
packets, without being able to block packets from passing through.
On-path attackers that only need to monitor might be lucky and find a
non-switched Ethernet in the path, or use capacitive or inductive
coupling to listen on a copper wire. But if the attacker is on an
Ethernet that is on the path, whether switched or not, the attacker
can also employ Address Resolution Protocol/Neighbor Discovery
(ARP/ND) spoofing to get access to the packet flow which allows
blocking as well. Similarly, if the attacker has access to the wire,
the attacker can also place a device on the wire to block. Other
on-path attacks would be those that gain control of a router or a
switch (or gain control of one of the endpoints), and most likely
those would allow blocking as well.
So the strongest currently known case where monitoring is easier than
blocking, is when switches and routers have monitoring capabilities
(for network management or for lawful intercept) where an attacker
might be able to bypass the authentication and authorization checks
for those capabilities. However, this document makes the simplifying
assumption treat all on-path attackers the same by assuming that such
an attacker can monitor, inject, and block packets. A security
analysis of a particular proposal can benefit from not making this
assumption, and look at how on-path attackers with different
capabilities can generate different attacks perhaps not present in
today’s Internet.
The document assumes that an off-path attacker can neither see
packets between the peers (for which it is not on the path) nor block
them from being delivered. Off-path attackers can, in general, send
packets with arbitrary IP source addresses and content, but such
packets might be blocked if ingress filtering [INGRESS] is applied.
Thus, it is important to look at the multihoming impact on security
both in the presence and absence of ingress filtering.
1.2. Authentication, Authorization, and Identifier Ownership
The overall problem domain can be described using different
terminology.
One way to describe it is that it is necessary to first authenticate
the peer and then verify that the peer is authorized to control the
locators used for a particular identifier. While this is correct, it
might place too much emphasis on the authorization aspect. In this
case, the authorization is conceptually very simple; each host (each
identifier) is authorized to control which locators are used for
itself.
Hence, there is a different way to describe the same thing. If the
peer can somehow prove that it is the owner of the identifier, and
the communication is bound to the identifier (and not the locator),
then the peer is allowed to control the locators that are used with
the identifier. This way to describe the problem is used in [OWNER].
Both ways to look at the problem, hence both sets of terminology, are
useful when trying to understand the problem space and the threats.
2. Terminology
link - a communication facility or medium over which nodes
can communicate at the link layer, i.e., the layer
immediately below IPv6. Examples are Ethernets
(simple or bridged); PPP links; X.25, Frame Relay,
or ATM networks; and Internet (or higher) layer
"tunnels", such as tunnels over IPv4 or IPv6 itself.
interface - a node’s attachment to a link.
address - an IP layer name that has both topological
significance (i.e., a locator) and identifies an
interface. There may be multiple addresses per
interface. Normally an address uniquely identifies
an interface, but there are exceptions: the same
unicast address can be assigned to multiple
interfaces on the same node, and an anycast address
can be assigned to different interfaces on different
nodes.
locator - an IP layer topological name for an interface or a
set of interfaces. There may be multiple locators
per interface.
identifier - an IP layer identifier for an IP layer endpoint
(stack name in [NSRG]), that is, something that
might be commonly referred to as a "host". The
transport endpoint name is a function of the
transport protocol and would typically include the
IP identifier plus a port number. There might be
use for having multiple identifiers per stack/per
host.
An identifier continues to function regardless of
the state of any one interface.
address field
- the source and destination address fields in the
IPv6 header. As IPv6 is currently specified, these
fields carry "addresses". If identifiers and
locators are separated, these fields will contain
locators.
FQDN - Fully Qualified Domain Name [FYI18]
3. Today’s Assumptions and Attacks
The two interesting aspects of security for multihoming solutions are
(1) the assumptions made by the transport layer and application layer
protocols about the identifiers that they see, and (2) the existing
abilities to perform various attacks that are related to the
identity/location relationship.
3.1. Application Assumptions
In the Internet today, the initiating part of applications either
starts with a FQDN, which it looks up in the DNS, or already has an
IP address from somewhere. For the FQDN to perform IP address
lookup, the application effectively places trust in the DNS. Once it
has the IP address, the application places trust in the routing
system delivering packets to that address. Applications that use
security mechanisms, such as IPSEC or TLS, have the ability to bind
an address or FQDN to cryptographic keying material. Compromising
the DNS and/or routing system can result in packets being dropped or
delivered to an attacker in such cases, but since the attacker does
not possess the keying material, the application will not trust the
attacker, and the attacker cannot decrypt what it receives.
At the responding (non-initiating) end of communication today, we
find that the security configurations used by different applications
fall into approximately five classes, where a single application
might use different classes of configurations for different types of
communication.
The first class is the set of public content servers. These systems
provide data to any and all systems and are not particularly
concerned with confidentiality, as they make their content available
to all. However, they are interested in data integrity and denial of
service attacks. Having someone manipulate the results of a search
engine, for example, or prevent certain systems from reaching a
search engine would be a serious security issue.
The second class of security configurations uses existing IP source
addresses from outside of their immediate local site as a means of
authentication without any form of verification. Today, with source
IP address spoofing and TCP sequence number guessing as rampant
attacks [RFC1948], such applications are effectively opening
themselves for public connectivity and are reliant on other systems,
such as firewalls, for overall security. We do not consider this
class of configurations in this document because they are in any case
fully open to all forms of network layer spoofing.
The third class of security configurations receives existing IP
source addresses, but attempt some verification using the DNS,
effectively using the FQDN for access control. (This is typically
done by performing a reverse lookup from the IP address, followed by
a forward lookup and verifying that the IP address matches one of the
addresses returned from the forward lookup.) These applications are
already subject to a number of attacks using techniques like source
address spoofing and TCP sequence number guessing since an attacker,
knowing this is the case, can simply create a DoS attack using a
forged source address that has authentic DNS records. In general
this class of security configurations is strongly discouraged, but it
is probably important that a multihoming solution doesn’t introduce
any new and easier ways to perform such attacks. However, we note
that some people think we should treat this class the same as the
second class of security configurations.
The fourth class of security configurations uses cryptographic
security techniques to provide both a strong identity for the peer
and data integrity with or without confidentiality. Such systems are
still potentially vulnerable to denial of service attacks that could
be introduced by a multihoming solution.
Finally, the fifth class of security configurations uses
cryptographic security techniques, but without strong identity (such
as opportunistic IPsec). Thus, data integrity with or without
confidentiality is provided when communicating with an
unknown/unauthenticated principal. Just like the first category
above, such applications can’t perform access control based on
network layer information since they do not know the identity of the
peer. However, they might perform access control using higher-level
notions of identity. The availability of IPsec (and similar
solutions) together with channel bindings allows protocols (which, in
themselves, are vulnerable to man-in-the-middle (MITM) attacks) to
operate with a high level of confidentiality in the security of the
identification of the peer. A typical example is the Remote Direct
Data Placement Protocol (RDDP), which, when used with opportunistic
IPsec, works well if channel bindings are available. Channel
bindings provide a link between the IP-layer identification and the
application protocol identification.
A variant of the fifth class are those that use "leap-of-faith"
during some initial communication. They do not provide strong
identities except where subsequent communication is bound to the
initial communication, providing strong assurance that the peer is
the same as during the initial communication.
The fifth class is important and its security properties must be
preserved by a multihoming solution.
The requirement for a multihoming solution is that security be no
worse than it is today in all situations. Thus, mechanisms that
provide confidentiality, integrity, or authentication today should
continue to provide these properties in a multihomed environment.
3.2. Redirection Attacks Today
This section enumerates some of the redirection attacks that are
possible in today’s Internet.
If routing can be compromised, packets for any destination can be
redirected to any location. This can be done by injecting a long
prefix into global routing, thereby causing the longest match
algorithm to deliver packets to the attacker.
Similarly, if DNS can be compromised, and a change can be made to an
advertised resource record to advertise a different IP address for a
hostname, effectively taking over that hostname. More detailed
information about threats relating to DNS are in [DNS-THREATS].
Any system that is along the path from the source to the destination
host can be compromised and used to redirect traffic. Systems may be
added to the best path to accomplish this. Further, even systems
that are on multi-access links that do not provide security can also
be used to redirect traffic off of the normal path. For example, ARP
and ND spoofing can be used to attract all traffic for the legitimate
next hop across an Ethernet. And since the vast majority of
applications rely on DNS lookups, if DNSsec is not deployed, then
attackers that are on the path between the host and the DNS servers
can also cause redirection by modifying the responses from the DNS
servers.
In general, the above attacks work only when the attacker is on the
path at the time it is performing the attack. However, in some cases
it is possible for an attacker to create a DoS attack that remains at
least some time after the attacker has moved off the path. An
example of this is an attacker that uses ARP or ND spoofing while on
path to either insert itself or send packets to a black hole (a
non-existent L2 address). After the attacker moves away, the ARP/ND
entries will remain in the caches in the neighboring nodes for some
amount of time (a minute or so in the case of ARP). This will result
in packets continuing to be black-holed until ARP entry is flushed.
Finally, the hosts themselves that terminate the connection can also
be compromised and can perform functions that were not intended by
the end user.
All of the above protocol attacks are the subject of ongoing work to
secure them (DNSsec, security for BGP, Secure ND) and are not
considered further within this document. The goal for a multihoming
solution is not to solve these attacks. Rather, it is to avoid
adding to this list of attacks.
3.3. Packet Injection Attacks Today
In today’s Internet the transport layer protocols, such as TCP and
SCTP, which use IP, use the IP addresses as the identifiers for the
communication. In the absence of ingress filtering [INGRESS], the IP
layer allows the sender to use an arbitrary source address, thus the
transport protocols and/or applications need some protection against
malicious senders injecting bogus packets into the packet stream
between two communicating peers. If this protection can be
circumvented, then it is possible for an attacker to cause harm
without necessarily needing to redirect the return packets.
There are various levels of protection in different transport
protocols. For instance, in general TCP packets have to contain a
sequence that falls in the receiver’s window to be accepted. If the
TCP initial sequence numbers are random, then it is very hard for an
off-path attacker to guess the sequence number close enough for it to
belong to the window, and as a result be able to inject a packet into
an existing connection. How hard this is depends on the size of the
available window, whether the port numbers are also predictable, and
the lifetime of the connection. Note that there is ongoing work to
strengthen TCP’s protection against this broad class of attacks
[TCPSECURE]. SCTP provides a stronger mechanism with the
verification tag; an off-path attacker would need to guess this
random 32-bit number. Of course, IPsec provides cryptographically
strong mechanisms that prevent attackers, on or off path, from
injecting packets once the security associations have been
established.
When ingress filtering is deployed between the potential attacker and
the path between the communicating peers, it can prevent the attacker
from using the peer’s IP address as source. In that case, the packet
injection will fail in today’s Internet.
We don’t expect a multihoming solution to improve the existing degree
of prevention against packet injection. However, it is necessary to
look carefully at whether a multihoming solution makes it easier for
attackers to inject packets because the desire to have the peer
present at multiple locators, and perhaps at a dynamic set of
locators, can potentially result in solutions that, even in the
presence of ingress filtering, make packet injection easier.
3.4. Flooding Attacks Today
In the Internet today there are several ways for an attacker to use a
redirection mechanism to launch DoS attacks that cannot easily be
traced to the attacker. An example of this is to use protocols that
cause reflection with or without amplification [PAXSON01].
Reflection without amplification can be accomplished by an attacker
sending a TCP SYN packet to a well-known server with a spoofed source