< draft-nordmark-multi6-threats-00.txt   draft-nordmark-multi6-threats-01.txt >
INTERNET-DRAFT Erik Nordmark INTERNET-DRAFT Erik Nordmark
Oct 20, 2003 Sun Microsystems June 1, 2004 Sun Microsystems
Tony Li Tony Li
Procket Networks Procket Networks
Threats relating to IPv6 multihoming solutions Threats relating to IPv6 multihoming solutions
<draft-nordmark-multi6-threats-00.txt> <draft-nordmark-multi6-threats-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet Draft expires April 20, 2004. This Internet Draft expires December 1, 2004.
Abstract Abstract
This document lists security threats related to IPv6 multihoming. This document lists security threats related to IPv6 multihoming.
Multihoming can introduce new opportunities to redirect packets to Multihoming can introduce new opportunities to redirect packets to
different, unintended IP addresses. different, unintended IP addresses.
The intent is to look at how IPv6 multihoming solutions might make The intent is to look at how IPv6 multihoming solutions might make
the Internet less secure than the current Internet, without studying the Internet less secure than the current Internet, without studying
any proposed solution but instead looking at threats that are any proposed solution but instead looking at threats that are
inherent in the problem itself. The threats in this document build inherent in the problem itself. The threats in this document build
upon the threats discovered and discussed as part of the Mobile IPv6 upon the threats discovered and discussed as part of the Mobile IPv6
work. work.
Contents Contents
1. INTRODUCTION............................................. 2 1. INTRODUCTION............................................. 3
1.1. Assumptions......................................... 3
2. TERMINOLOGY.............................................. 3 2. TERMINOLOGY.............................................. 4
3. TODAY'S ASSUMPTIONS...................................... 4 3. TODAY'S ASSUMPTIONS...................................... 5
3.1. Application Assumptions............................. 4 3.1. Application Assumptions............................. 5
3.2. Redirection Attacks Today........................... 6 3.2. Redirection Attacks Today........................... 6
3.3. Flooding Attacks Today.............................. 6 3.3. Packet Injection Attacks Today...................... 7
3.4. Flooding Attacks Today.............................. 8
4. POTENTIAL NEW REDIRECTION ATTACKS........................ 8 4. POTENTIAL NEW REDIRECTION ATTACKS........................ 9
4.1. Cause Packets to be Sent to the Attacker............ 8 4.1. Cause Packets to be Sent to the Attacker............ 10
4.1.1. Once Packets are Flowing....................... 8 4.1.1. Once Packets are Flowing....................... 10
4.1.2. Premeditated Redirection....................... 9 4.1.2. Premeditated Redirection....................... 10
4.1.3. Using Replay Attacks........................... 9 4.1.3. Using Replay Attacks........................... 11
4.2. Cause Packets to be Sent to a Black Hole............ 10 4.2. Cause Packets to be Sent to a Black Hole............ 12
4.3. Third Party Denial-of-Service Attacks............... 10 4.3. Third Party Denial-of-Service Attacks............... 12
4.3.1. Basic Third Party DoS.......................... 11 4.3.1. Basic Third Party DoS.......................... 13
4.3.2. Third Party DoS with On-Path Help.............. 12 4.3.2. Third Party DoS with On-Path Help.............. 14
4.4. Accepting Packets from Unknown Locators............. 13 4.4. Accepting Packets from Unknown Locators............. 15
5. OTHER SECURITY CONCERNS.................................. 14 5. GRANULARITY OF REDIRECTION............................... 16
6. SECURITY CONSIDERATIONS.................................. 15 6. MOVEMENT IMPLICATIONS?................................... 17
7. ACKNOWLEDGMENTS.......................................... 16 7. OTHER SECURITY CONCERNS.................................. 18
8. REFERENCES............................................... 16 8. PRIVACY CONSIDERATIONS................................... 19
8.1. Normative References................................ 16
8.2. Informative References.............................. 16
AUTHORS' ADDRESSES........................................... 17 9. SECURITY CONSIDERATIONS.................................. 19
10. ACKNOWLEDGMENTS......................................... 20
11. REFERENCES.............................................. 20
11.1. Normative References............................... 20
11.2. Informative References............................. 20
AUTHORS' ADDRESSES........................................... 22
APPENDIX A: CHANGES SINCE PREVIOUS DRAFT..................... 22
APPENDIX B: SOME SECURITY ANALYSIS........................... 23
1. INTRODUCTION 1. INTRODUCTION
The goal of the IPv6 multihoming work is to allow a site to take The goal of the IPv6 multihoming work is to allow a site to take
advantage of multiple attachments to the global Internet without advantage of multiple attachments to the global Internet without
having a specific entry for the site visible in the global routing having a specific entry for the site visible in the global routing
table. Specifically, a solution should allow hosts to use multiple table. Specifically, a solution should allow hosts to use multiple
attachments in parallel, or to switch between these attachment points attachments in parallel, or to switch between these attachment points
dynamically in the case of failures, without an impact on the upper dynamically in the case of failures, without an impact on the upper
layer protocols. layer protocols.
skipping to change at page 3, line 27 skipping to change at page 3, line 37
This document has been developed while considering multihoming This document has been developed while considering multihoming
solutions architected around a separation of network identity and solutions architected around a separation of network identity and
network location. However, this separation is not a requirement for network location. However, this separation is not a requirement for
all threats, so this taxonomy may also apply to other approaches. all threats, so this taxonomy may also apply to other approaches.
This document is not intended to examine any single proposed This document is not intended to examine any single proposed
solution. Rather, it is intended as an aid to discussion and solution. Rather, it is intended as an aid to discussion and
evaluation of proposed solutions. By cataloging known threats, we evaluation of proposed solutions. By cataloging known threats, we
can help to ensure that all proposals deal with all of the available can help to ensure that all proposals deal with all of the available
threats. threats.
1.1. Assumptions
This threat analysis doesn't assume that security has been applied
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 which care
about integrity and/or confidentiality apply the relevant end-to-end
security measures, such as IPsec or TLS.
For simplicity we assume 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, which allow
authenticated and authorized users to observe packets without being
able to send or block the packets.
We assume 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.
2. TERMINOLOGY 2. TERMINOLOGY
upper layer protocol (ULP) upper layer protocol (ULP)
- a protocol layer immediately above IP. Examples are - a protocol layer immediately above IP. Examples are
transport protocols such as TCP and UDP, control transport protocols such as TCP and UDP, control
protocols such as ICMP, routing protocols such as protocols such as ICMP, routing protocols such as
OSPF, and Internet or lower-layer protocols being OSPF, and Internet or lower-layer protocols being
"tunneled" over (i.e., encapsulated in) IP such as "tunneled" over (i.e., encapsulated in) IP such as
IPX, AppleTalk, or IP itself. IPX, AppleTalk, or IP itself.
skipping to change at page 4, line 19 skipping to change at page 5, line 12
locators are separated these fields will contain locators are separated these fields will contain
locators. locators.
FQDN - Fully Qualified Domain Name FQDN - Fully Qualified Domain Name
3. TODAY'S ASSUMPTIONS 3. TODAY'S ASSUMPTIONS
The two interesting aspects of security for multihoming solutions are The two interesting aspects of security for multihoming solutions are
the assumptions made by the applications and upper layer protocols the assumptions made by the applications and upper layer protocols
about the identifiers that they see on one hand, and the existing about the identifiers that they see on one hand, and the existing
abilities to perform redirection attacks today, on the other hand. abilities to perform today various attacks related to the
identity/location relationship, on the other hand.
3.1. Application Assumptions 3.1. Application Assumptions
In the Internet today, the initiating part of applications either 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 starts with a FQDN, which it looks up in the DNS, or already has an
IP address from somewhere. For the FQDN to IP address lookup the IP address from somewhere. For the FQDN to IP address lookup the
application effectively places trust in the DNS. Once it has the IP application effectively places trust in the DNS. Once it has the IP
address, the application places trust in the routing system address, the application places trust in the routing system
delivering packets to that address. Applications that use security delivering packets to that address. Applications that use security
mechanisms, such as IPsec or TLS, with mutual authentication have the mechanisms, such as IPsec or TLS, with mutual authentication have the
skipping to change at page 6, line 17 skipping to change at page 7, line 9
This section enumerates some of the redirection attacks that are This section enumerates some of the redirection attacks that are
possible in today's Internet. possible in today's Internet.
If routing can be compromised, packets for any destination can be If routing can be compromised, packets for any destination can be
redirected to any location. This can be done by injecting a long redirected to any location. This can be done by injecting a long
prefix into global routing, thereby causing the longest match prefix into global routing, thereby causing the longest match
algorithm to deliver packets to the attacker. algorithm to deliver packets to the attacker.
Similarly, if DNS can be compromised, and a change can be made to an 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 advertised resource record to advertise a different IP address for a
hostname, effectively taking over that hostname. 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 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 host can be compromised and used to redirect traffic. Systems may be
added to the best path to accomplish this. Further, even systems added to the best path to accomplish this. Further, even systems
that are on multi-access links that do not provide security can also 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 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 and ND spoofing can be used to attract all traffic for the legitimate
next hop across an Ethernet. 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.
Finally, the hosts themselves that terminate the connection can also Finally, the hosts themselves that terminate the connection can also
be compromised and can perform functions that were not intended by be compromised and can perform functions that were not intended by
the end user. the end user.
All of the above protocol attacks are the subject of ongoing work to All of the above protocol attacks are the subject of ongoing work to
secure them (DNSsec, security for BGP, Secure ND) and are not secure them (DNSsec, security for BGP, Secure ND) and are not
considered further within this document. The goal for a multihoming considered further within this document. The goal for a multihoming
solution is not to solve these attacks. Rather, it is to avoid solution is not to solve these attacks. Rather, it is to avoid
adding to this list of attacks. adding to this list of attacks.
3.3. Flooding Attacks Today 3.3. Packet Injection Attacks Today
In today's Internet the upper-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
ULPs 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 level of protection in different ULPs. 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 relatively hard for an off-
path attacker to guess the sequence number close enough for it to
belong to the window, and as result be able to inject a packet into
an existing connection. How hard this is depends on the size of the
available window. 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 provide cryptographically
strong mechanisms which prevent attackers on or off path to inject
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 improve the existing degree of
prevention against packet injection. However, it is necessary to
look carefully whether a multihoming solution makes it easier for
attackers to inject packets since the desire to have the peer be
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 In the Internet today there are several ways for an attacker to use a
redirection mechanism to launch DoS attacks that can not easily be redirection mechanism to launch DoS attacks that can not easily be
traced to the attacker. An example of this is to use protocols which traced to the attacker. An example of this is to use protocols which
cause reflection with or without amplification [PAXSON01]. cause reflection with or without amplification [PAXSON01].
Reflection without amplification can be accomplished by an attacker Reflection without amplification can be accomplished by an attacker
sending a TCP SYN packet to a well-known server with a spoofed source sending a TCP SYN packet to a well-known server with a spoofed source
address; the resulting TCP SYN ACK packet will be sent to the spoofed address; the resulting TCP SYN ACK packet will be sent to the spoofed
source address. source address.
Devices on the path between two communicating entities can also Devices on the path between two communicating entities can also
launch DoS attacks. While such attacks might not be interesting launch DoS attacks. While such attacks might not be interesting
today, it is necessary to understand them better in order to today, it is necessary to understand them better in order to
determine whether a multihoming solution might enables new types of determine whether a multihoming solution might enables new types of
DoS attacks. DoS attacks.
skipping to change at page 7, line 32 skipping to change at page 9, line 22
packets from A to B it can also prevent A from sending any explicit packets from A to B it can also prevent A from sending any explicit
"slow down" packets to B. Similar attacks can presumably be launched "slow down" packets to B. Similar attacks can presumably be launched
using protocols that carry streaming media by forging such a using protocols that carry streaming media by forging such a
protocol's notion of acknowledgment and feedback. protocol's notion of acknowledgment and feedback.
An attribute of this type of attack is that A will simply think that An attribute of this type of attack is that A will simply think that
B is faulty since its flow and congestion control mechanisms don't B is faulty since its flow and congestion control mechanisms don't
seem to be working. Detecting that the stream of ACK packets is seem to be working. Detecting that the stream of ACK packets is
generated from X and not from A might be challenging, since the rate generated from X and not from A might be challenging, since the rate
of ACK packets might be relatively low. This type of attack might of ACK packets might be relatively low. This type of attack might
not be common today because it requires that X remain on the path in not be common today because, in the presence of ingress filtering, it
order to sustain the DoS attack, but the addition of multihoming requires that X remain on the path in order to sustain the DoS
redirection mechanisms might potentially remove that constraint. And attack. And in the absence of ingress filtering an attacker can
with the current, no-multihoming support, using end-to-end strong launch simpler DoS attacks by spoofing its source IP address.
security at a protocol level at (or below) this "ACK" processing
would prevent this type of attack. But if a multihoming solution is The danger is that the addition of multihoming redirection mechanisms
provided underneath IPsec that prevention mechanism would not exist. might potentially remove the constraint that the attacker remain on
the path. And with the current, no-multihoming support, using end-
to-end strong security at a protocol level at (or below) this "ACK"
processing would prevent this type of attack. But if a multihoming
solution is provided underneath IPsec that prevention mechanism would
potentially not exist.
Thus the challenge for multihoming solutions is to not create Thus the challenge for multihoming solutions is to not create
additional types of attacks in this area, or make existing types of additional types of attacks in this area, or make existing types of
attacks significantly easier. attacks significantly easier.
4. POTENTIAL NEW REDIRECTION ATTACKS 4. POTENTIAL NEW REDIRECTION ATTACKS
This section documents the additional redirection attacks that have This section documents the additional redirection attacks that have
been discovered that result from an architecture where hosts can been discovered that result from an architecture where hosts can
change their topological connection to the network in the middle of a change their topological connection to the network in the middle of a
skipping to change at page 8, line 38 skipping to change at page 10, line 28
using redirection attacks. using redirection attacks.
4.1.1. Once Packets are Flowing 4.1.1. Once Packets are Flowing
This might be viewed as the "classic" redirection attack. This might be viewed as the "classic" redirection attack.
While A and B are communicating X might send packets to B and claim: While A and B are communicating X might send packets to B and claim:
"Hi, I'm A, send my packets to my new location." where the location "Hi, I'm A, send my packets to my new location." where the location
is really X's location. is really X's location.
"Standard" solutions to this include requiring the node requesting "Standard" solutions to this include requiring the host requesting
redirection somehow be verified to be the same node as the initial redirection somehow be verified to be the same host as the initial
node to establish communication. However, the burdens of such host to establish communication. However, the burdens of such
verification must not be onerous, or the redirection requests verification must not be onerous, or the redirection requests
themselves can be used as a DoS attack. themselves can be used as a DoS attack.
To prevent this type of attack, a solution would need some mechanism To prevent this type of attack, a solution would need some mechanism
that B can use to verify whether a locator belongs to A before B that B can use to verify whether a locator belongs to A before B
starts using that locator, and be able to do this when multiple starts using that locator, and be able to do this when multiple
locators are assigned to A. locators are assigned to A.
4.1.2. Premeditated Redirection 4.1.2. Premeditated Redirection
skipping to change at page 9, line 14 skipping to change at page 11, line 4
4.1.2. Premeditated Redirection 4.1.2. Premeditated Redirection
This is a variant of the above where the attacker "installs" itself This is a variant of the above where the attacker "installs" itself
before communication starts. before communication starts.
For example, if the attacker X can predict that A and B will For example, if the attacker X can predict that A and B will
communicate in the (near) future, then the attacker can tell B: "Hi, communicate in the (near) future, then the attacker can tell B: "Hi,
I'm A and I'm at this location". When A later tries to communicate I'm A and I'm at this location". When A later tries to communicate
with B, will B believe it is really A? with B, will B believe it is really A?
If the solution to the classic redirection attack is based on "prove If the solution to the classic redirection attack is based on "prove
you are the same as initially", then A will fail to prove this to B you are the same as initially", then A will fail to prove this to B
since X initiated communication. since X initiated communication.
Depending on details that would be specific to a proposed solution, Depending on details that would be specific to a proposed solution,
this type of attack could either case redirection (so that the this type of attack could either cause redirection (so that the
packets intended for A will be sent to X) or they could cause DoS packets intended for A will be sent to X) or they could cause DoS
(where A would fail to communicate with B since it can't prove it is (where A would fail to communicate with B since it can't prove it is
the same node as X). the same host as X).
To prevent this attack, the verification whether a locator belongs to To prevent this attack, the verification whether a locator belongs to
the peer can not simply be based on the first peer that made contact. the peer can not simply be based on the first peer that made contact.
4.1.3. Using Replay Attacks 4.1.3. Using Replay Attacks
While the multihoming problem doesn't inherently imply any While the multihoming problem doesn't inherently imply any
topological movement it is useful to also consider the impact of site topological movement it is useful to also consider the impact of site
renumbering in combination with multihoming. In that case the set of renumbering in combination with multihoming. In that case the set of
locators for a node will change each time its site renumbers and at locators for a host will change each time its site renumbers and at
some point in time after a renumbering event the old locator prefix some point in time after a renumbering event the old locator prefix
might be reassigned to some other site. might be reassigned to some other site.
This potentially opens up the ability for an attacker to replay This potentially opens up the ability for an attacker to replay
whatever protocol mechanism was used to inform a node of a peer's whatever protocol mechanism was used to inform a host of a peer's
locators so that the node would incorrectly be lead to believe that locators so that the host would incorrectly be lead to believe that
the old locator (set) should be used even long after a renumbering the old locator (set) should be used even long after a renumbering
event. This is similar to the risk of replay of Binding Updates in event. This is similar to the risk of replay of Binding Updates in
[MIPv6] but the time constant is quite different; Mobile IPv6 might [MIPv6] but the time constant is quite different; Mobile IPv6 might
see movements every second while site renumbering followed by see movements every second while site renumbering followed by
reassignment of the site locator prefix might be a matter of weeks or reassignment of the site locator prefix might be a matter of weeks or
months. months.
To prevent such replay attacks the protocol which is used to verify To prevent such replay attacks the protocol which is used to verify
which locators can be used with a particular identifier needs some which locators can be used with a particular identifier needs some
replay protection mechanism. replay protection mechanism.
Also, in this space one needs to be concerned about potential Also, in this space one needs to be concerned about potential
interaction between such replay protection and the administrative act interaction between such replay protection and the administrative act
of reassignment of a locator. If the identifier and locator of reassignment of a locator. If the identifier and locator
relationship is distributed across the network one would need to make relationship is distributed across the network one would need to make
sure that the old information has been completely purged from the sure that the old information has been completely purged from the
network before any reassignment. Note that this does not require network before any reassignment. Note that this does not require an
explicit mechanism. This can instead be implemented by locator reuse explicit mechanism. This can instead be implemented by locator reuse
policy and careful timeouts of locator information. policy and careful timeouts of locator information.
4.2. Cause Packets to be Sent to a Black Hole 4.2. Cause Packets to be Sent to a Black Hole
This is also a variant of the classic redirection attack. The This is also a variant of the classic redirection attack. The
difference is that the new location is a locator that is nonexistent difference is that the new location is a locator that is nonexistent
or unreachable. Thus the effect is that sending packets to the new or unreachable. Thus the effect is that sending packets to the new
locator causes the packets to be dropped by the network somewhere. locator causes the packets to be dropped by the network somewhere.
skipping to change at page 10, line 45 skipping to change at page 12, line 38
The first is that the attacker might be able to completely hide its The first is that the attacker might be able to completely hide its
identity and location. It might suffice for X to send and receive a identity and location. It might suffice for X to send and receive a
few packets to A in order to perform the redirection, and A might not few packets to A in order to perform the redirection, and A might not
retain any state on who asked for the redirection to C's location. retain any state on who asked for the redirection to C's location.
Even if A had retained such state, that state would probably not be Even if A had retained such state, that state would probably not be
easily available to C, thus C can't determine who was the attacker easily available to C, thus C can't determine who was the attacker
once C is being DoS'ed. once C is being DoS'ed.
The second concern is that with a direct DoS attack from X to C, the The second concern is that with a direct DoS attack from X to C, the
attacker is limited by the bandwidth of its own path towards C. If attacker is limited by the bandwidth of its own path towards C. If
the attacker can fool another node like A to redirect its traffic to the attacker can fool another host like A to redirect its traffic to
C then the bandwidth is limited by the path from A towards C. If A C then the bandwidth is limited by the path from A towards C. If A
is a high-capacity Internet service and X has slow (e.g., dialup) is a high-capacity Internet service and X has slow (e.g., dialup)
connectivity this difference could be substantial. Thus in effect connectivity this difference could be substantial. Thus in effect
this could be similar to packet amplifying reflectors in [PAXSON01]. this could be similar to packet amplifying reflectors in [PAXSON01].
The third, and final concern, is that if an attacker only need a few The third, and final concern, is that if an attacker only need a few
packets to convince one node to flood a third party, then it wouldn't packets to convince one host to flood a third party, then it wouldn't
be hard for the attacker to convince lots of nodes to flood the same be hard for the attacker to convince lots of hosts to flood the same
third party. Thus this could be used for Distributed Denial-of- third party. Thus this could be used for Distributed Denial-of-
Service attacks. Service attacks.
In today's Internet the ability to perform this type of attack is In today's Internet the ability to perform this type of attack is
quite limited. In order for the attacker to initiate communication quite limited. In order for the attacker to initiate communication
it will in most cases need to be able to receive some packets from it will in most cases need to be able to receive some packets from
the peer (the potential exception being combining this with TCP the peer (the potential exception being combining this with TCP
sequence number guessing type of techniques). Furthermore, to the sequence number guessing type of techniques). Furthermore, to the
extent that parts of the Internet uses ingress filtering [INGRESS], extent that parts of the Internet uses ingress filtering [INGRESS],
even if the communication could be initiated it wouldn't be possible even if the communication could be initiated it wouldn't be possible
skipping to change at page 14, line 24 skipping to change at page 16, line 5
could potentially cause a DoS attack.) could potentially cause a DoS attack.)
There might also be a middle ground where arbitrary attackers are There might also be a middle ground where arbitrary attackers are
prevented from injecting packets by using the SCTP verification tag prevented from injecting packets by using the SCTP verification tag
type of approach [SCTP]. (This is a clear-text tag which is sent to type of approach [SCTP]. (This is a clear-text tag which is sent to
the peer which the peer is expected to include in each subsequent the peer which the peer is expected to include in each subsequent
packet.) Such an approach doesn't prevent packet injection from on- packet.) Such an approach doesn't prevent packet injection from on-
path attackers (since they can observe the verification tag), but path attackers (since they can observe the verification tag), but
neither does ingress filtering. neither does ingress filtering.
5. OTHER SECURITY CONCERNS 5. GRANULARITY OF REDIRECTION
Different multihoming solutions might approach the problem at
different layers in the protocol stack. For instance, there has been
proposals on a shim layer inside IP as well as transport layer
approaches. The former would have the capability to redirect an IP
address while the latter might be constrained to only redirect a
single transport connection. This difference might be important when
it comes to understanding the security impact.
For instance, premeditated attacks might have quite different impact
in the two cases. In an IP-based multihoming solution a successful
premeditated redirection could be due to the attacker connecting to a
server and claiming to be 'A' which would result in the server
retaining some state about 'A' which it received from the attacker.
Later, when the real 'A' tries to connect to the server, the
existence of this state might mean that 'A' fails to communicate, or
that its packets are sent to the attacker. But if the same scenario
is applied to a transport-layer approach then the state created due
to the attacker would perhaps be limited to the existing transport
connection. Thus while this might prevent the real 'A' from
connecting to the server while the attacker is connected (if they
happen to use the same transport port number) most likely it would
not affect 'A's ability to connect after the attacker has
disconnected.
A particular aspect of the granularity question is the direction
question; will the created state be used for communication in the
reverse direction from the direction when it was created? For
instance, if the attacker 'X' suspects that 'A' will connect to 'B'
in the near future, can X connect to A and claim to be B and have
that later make A connect to the attacker instead of to the real B?
Note that transport layer approaches are limited to the set of ULPs
that the implementation makes aware of multihoming. In many cases
there would be ULPs that are unknown to the multihoming capability of
the system, such as applications built on top of UDP. To understand
the impact of the granularity question on the security, one would
also need to understand how such applications/ULPs would be handled.
A property of transport granularity is that the amount of work
performed by a legitimate host is proportional to the number of
transport connections it creates that uses the multihoming support,
since each such connection would require some multihoming signaling.
And the same is true for the attacker. This means that an attacker
could presumably do a premeditated attack for all TCP connections to
port 80 from A to B, by setting up 65,536 (for all TCP source port
numbers) to the server B and causing B to think those connections
should be directed to the attacker and keeping those TCP connections
open. Any attempt to make legitimate communication more efficient,
e.g., by being able to signal for multiple transport connections at a
time, would provide as much relative benefit for an attacker as the
legitimate hosts.
Discussion: Perhaps the key issue is not about the granularity,
but about the lifetime of the state that is created? In a
transport-layer approach the multihoming state would presumably be
destroyed when the transport state is deleted as part of closing
the connection. But an IP-layer approach would have to rely on
some timeout or garbage collection mechanisms perhaps combined
with some new explicit signally to remove the multihoming state.
The coupling between the connection state and multihoming state in
the transport-layer approach might make it more expensive for the
attacker, since it needs to keep the connections open. Is this
the case?
In summary, there are issues we don't yet understand well about
granularity and reuse of the multihoming state.
6. MOVEMENT IMPLICATIONS?
In the case when nothing moves around we have a reasonable
understanding of the security requirements. Something that is on the
path can be a MiTM in today's Internet and a multihoming solution
doesn't need to make that aspect any more secure.
But it is more difficult to understand the requirements when hosts
are moving around. For instance, a host might be on the path for a
short moment in time by driving by an 802.11 hotspot. Would we or
would we not be concerned if such a drive-by (which many call a
"time-shifting" attack) would result in the temporarily on-path host
being able to act as a MiTM for future communication? Depending on
the solution this might be possible by the attacker causing
multihoming state to be created in various peer hosts while the
attacker was on the path, and that state remaining in the peers for
some time.
The answer to this question doesn't seem to be obvious even in the
absence of any new multihoming support. We don't have much
experience with hosts moving around that are able to attack things as
they move. In Mobile IPv6 [MIPv6] a conservative approach was taken
which limits the effect of such drive-by attacks to the maximum
lifetime of the binding, which is set to a few minutes.
With multihoming support the issue gets a bit more complicated
because we explicitly want to allow a host to be present at multiple
locators at the same time, thus there might be a need to distinguish
between the host moving between different locators, and the host
sending packets with different source locators because it is present
at multiple locators without any topological movement.
Note that the multihoming solutions that have been discussed range
from such drive-by's being impossible (for instance, due to a strong
binding to a separate identifier as in HIP, or due to reliance on the
relative security of the DNS for forward plus reverse lookups in
NOID), to systems that are first-come/first-serve (WIMP being an
example with a separate ID space, a MAST approach with a PBK being an
example without a separate ID space) that allow the first host which
is using an ID/address to claim that without any time limit.
7. OTHER SECURITY CONCERNS
The protocol mechanisms added as part of a multihoming solution The protocol mechanisms added as part of a multihoming solution
shouldn't introduce any new DoS in the mechanisms themselves. In shouldn't introduce any new DoS in the mechanisms themselves. In
particular, care must be taken not to: particular, care must be taken not to:
- create state on the first packet in an exchange, since that could - create state on the first packet in an exchange, since that could
result in state consumption attacks similar to the TCP SYN result in state consumption attacks similar to the TCP SYN
flooding attack. flooding attack.
- perform much work on the first packet in an exchange (such as - perform much work on the first packet in an exchange (such as
expensive verification) expensive verification)
There is a potential chicken-and-egg problem here, because There is a potential chicken-and-egg problem here, because
potentially one would want to avoid doing work or creating state potentially one would want to avoid doing work or creating state
until the peer has been verified, but verification will probably need until the peer has been verified, but verification will probably need
some state and some work to be done. some state and some work to be done.
A possible approach that solutions might investigate is to defer A possible approach that solutions might investigate is to defer
verification until there appears to be two different nodes (or two verification until there appears to be two different hosts (or two
different locators for the same node) that want to use the same different locators for the same host) that want to use the same
identifier. identifier.
Another possible approach is to first establish communications, and Another possible approach is to first establish communications, and
then perform verification in parallel with normal data transfers. then perform verification in parallel with normal data transfers.
Redirection would only be permitted after verification was complete, Redirection would only be permitted after verification was complete,
but prior to that event, data could transfer in a normal, non- but prior to that event, data could transfer in a normal, non-
multihomed manner. multihomed manner.
Finally, the new protocol mechanisms should be protected against Finally, the new protocol mechanisms should be protected against
spoofed packets, at least from off-path sources, and replayed spoofed packets, at least from off-path sources, and replayed
packets. packets.
6. SECURITY CONSIDERATIONS 8. PRIVACY CONSIDERATIONS
While introducing identifiers can be helpful by providing ways to
identify hosts across events when its IP address(es) might change,
there is a risk that such mechanisms can be abused to track the
identity of the host over long periods of time. Designers of
solutions to multihoming need to be aware of this concern.
A solution could address this for instance by allowing each host to
have multiple identifiers at the same time and perhaps even changing
the set of identifiers that are used over time. Such an approach
could be analogous to what is done for IPv6 addresses in [RFC3041].
9. SECURITY CONSIDERATIONS
In section 3 we discussed existing protocol-based redirection In section 3 we discussed existing protocol-based redirection
attacks. But there are also non-protocol redirection attacks. An attacks. But there are also non-protocol redirection attacks. An
attacker which can gain physical access to one of attacker which can gain physical access to one of
- The copper/fiber somewhere in the path. - The copper/fiber somewhere in the path.
- A router or L2 device in the path. - A router or L2 device in the path.
- One of the end systems - One of the end systems
can also redirect packets. This could be possible for instance by can also redirect packets. This could be possible for instance by
physical break-ins or by bribing staff that have access to the physical break-ins or by bribing staff that have access to the
physical infrastructure. Such attacks are out of scope for this physical infrastructure. Such attacks are out of scope for this
discussion, but are worth to keep in mind when looking at the cost discussion, but are worth to keep in mind when looking at the cost
for an attacker to exploit any protocol-based attacks against for an attacker to exploit any protocol-based attacks against
multihoming solutions; making protocol-based attacks much more multihoming solutions; making protocol-based attacks much more
expensive to launch than break-ins/bribery type of attacks might be expensive to launch than break-ins/bribery type of attacks might be
overkill. overkill.
7. ACKNOWLEDGMENTS 10. ACKNOWLEDGMENTS
This document is a product of a MULTI6 design team consisting of (in This document is a product of a MULTI6 design team consisting of (in
alphabetical order): Iljitsch van Beijnum, Steve Bellovin, Brian alphabetical order): Iljitsch van Beijnum, Steve Bellovin, Brian
Carpenter, Mike O'Dell, Sean Doran, Dave Katz, Tony Li, Erik Carpenter, Mike O'Dell, Sean Doran, Dave Katz, Tony Li, Erik
Nordmark, and Pekka Savola. Nordmark, and Pekka Savola.
Much of the awareness of these threats come from the work on Mobile Much of the awareness of these threats come from the work on Mobile
IPv6 [MIPv6, NIKANDER03, AURA02]. IPv6 [MIPv6, NIKANDER03, AURA02].
8. REFERENCES Masataka Ohta brought up privacy concern related to stable
identifiers. The suggestion to discuss transport versus IP
granularity was contributed by Marcelo Bagnulo.
8.1. Normative References 11. REFERENCES
8.2. Informative References 11.1. Normative References
11.2. Informative References
[NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from the [NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from the
NSRG", draft-irtf-nsrg-report-09.txt (work in progress), NSRG", draft-irtf-nsrg-report-09.txt (work in progress),
March 2003. March 2003.
[MIPv6] Johnson, D., C. Perkins, and J. Arkko, "Mobility Support in [MIPv6] Johnson, D., C. Perkins, and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-24.txt (work in progress), IPv6", draft-ietf-mobileip-ipv6-24.txt (work in progress),
June 2003. June 2003.
[AURA02] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", [AURA02] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses",
skipping to change at page 17, line 4 skipping to change at page 21, line 19
[PAXSON01] V. Paxson, "An Analysis of Using Reflectors for [PAXSON01] V. Paxson, "An Analysis of Using Reflectors for
Distributed Denial-of-Service Attacks", Computer Distributed Denial-of-Service Attacks", Computer
Communication Review 31(3), July 2001. Communication Review 31(3), July 2001.
[INGRESS] Ferguson P., and D. Senie, "Network Ingress Filtering: [INGRESS] 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", RFC 2827, May 2000. Address Spoofing", RFC 2827, May 2000.
[SCTP] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. [SCTP] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H.
Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and
V. Paxson, "Stream Control Transmission Protocol", RFC V. Paxson, "Stream Control Transmission Protocol", RFC
2960, October 2000. 2960, October 2000.
[ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6
Addressing Architecture", RFC 3513, April 2003. Addressing Architecture", RFC 3513, April 2003.
[IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2461. 6 (IPv6) Specification", RFC 2461.
[IPv6-SA] R. Atkinson. "Security Architecture for the Internet [IPv6-SA] R. Atkinson. "Security Architecture for the Internet
Protocol". RFC 2401, November 1998. Protocol". RFC 2401, November 1998.
[IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 2402, [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 2402,
November 1998. November 1998.
[IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)",
RFC 2406, November 1998. RFC 2406, November 1998.
[RFC3041] T. Narten and Draves, R, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", January 2001.
[DNS-THREATS] Derek Atkins, Rob Austein, "Threat Analysis Of The
Domain Name System", 5-Apr-04, <draft-ietf-dnsext-dns-
threats-07.txt>
[PBK] Scott Bradner, Allison Mankin, Jeffrey Schiller, "A Framework
for Purpose-Built Keys (PBK)", 9-Jun-03, <draft-bradner-
pbk-frame-06.txt>
[NOID] Erik Nordmark, "Multihoming without IP Identifiers", Oct 27,
2003, <draft-nordmark-multi6-noid-01.txt>
[MAST] D. Crocker, "MULTIPLE ADDRESS SERVICE FOR TRANSPORT
(MAST): AN EXTENDED PROPOSAL", September 2003, <draft-
crocker-mast-proposal-01.txt>
[HIP] Pekka Nikander, "Considerations on HIP based IPv6 multi-
homing", 23-Jan-04, <draft-nikander-multi6-hip-00.txt>
[WIMP] Jukka Ylitalo, 13-Feb-04, "Weak Identifier Multihoming
Protocol (WIMP)", <draft-ylitalo-multi6-wimp-00.txt>
[CBHI] Iljitsch van Beijnum, "Crypto Based Host Identifiers", 2-
Feb-04, <draft-van-beijnum-multi6-cbhi-00.txt>
AUTHORS' ADDRESSES AUTHORS' ADDRESSES
Erik Nordmark Tony Li Erik Nordmark Tony Li
Sun Microsystems, Inc. Procket Networks, Inc. Sun Microsystems, Inc. Procket Networks, Inc.
17 Network Circle 1110 Cadillac Ct. 17 Network Circle 1110 Cadillac Ct.
Mountain View, CA Milpitas, CA Mountain View, CA Milpitas, CA
USA USA USA USA
phone: +1 650 786 2921 phone: +1 408 635 7903 phone: +1 650 786 2921 phone: +1 408 635 7903
fax: +1 650 786 5896 fax: +1 408 635 7522 fax: +1 650 786 5896 fax: +1 408 635 7522
email: erik.nordmark@sun.com email: Tony.Li@procket.com email: erik.nordmark@sun.com email: Tony.Li@procket.com
Full Copyright Statement APPENDIX A: CHANGES SINCE PREVIOUS DRAFT
Copyright (C) The Internet Society (2003). All Rights Reserved. The following changes have been made since version 00 of the draft.
This document and translations of it may be copied and furnished to o Added reference to [DNS-THREATS] and clarified that attackers on
others, and derivative works that comment on or otherwise explain it the path between the host and the DNS servers can redirect traffic
or assist in its implementation may be prepared, copied, published today.
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be o Added a section on existing packet injection attacks to talk about
revoked by the Internet Society or its successors or assignees. TCP sequence number guessing etc.
This document and the information contained herein is provided on an o Clarified ingress filtering relationship in section on today's
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING flooding attacks.
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment o Added a new section on granularity to list some issues about
transport-level versus IP-level approaches and what we understand
about the differences in security. This is still very much a work
in progress.
Funding for the RFC Editor function is currently provided by the o Added a new section on movement to discuss how things change when
Internet Society. hosts move around the network. This is still very much a work in
progress.
o Added Appendix B - but this should probably be moved to a
different document to keep this document focused on the threats.
APPENDIX B: SOME SECURITY ANALYSIS
When looking at the proposals that have been made for multihoming
solutions and the above threats it seems like there are two separable
aspects of handling the redirection threats:
- Redirection of existing communication
- Redirection of an identity before any communication
The former can be addressed by a large class of approaches which are
based on setting up some form of security material at the beginning
of communication, and later using the existence of that material for
one end to prove to the other that it remains the same. An example
of this is Purpose Built Keys [PBK]. One can envision different
approaches for such schemes with different complexity, performance,
and resulting security such as anonymous Diffie-Hellman exchange, the
reverse hash chains presented in [WIMP], or even a clear-text token
exchanged at the initial communication.
However, the mechanisms for addressing the latter issue can be quite
different. One way to prevent premeditated redirection is to simply
not introduce a new identifier name space but instead rely on
existing name space(s) as in [NOID]; in this case premeditated
redirection is as easy or as hard as redirecting an IP address today.
Essentially this relies on the return-routability check associated
with a roundtrip of communication which verifies that the routing
system delivers packets to the IP address in question.
Alternatively, one can use the crypto-based identifiers such as in
[HIP] or crypto-generated addresses as in [CBHI], which both rely on
public-key crypto, to prevent premeditated attacks. In some cases it
is also possible to avoid the problem by having (one end of the
communication) use ephemeral identifiers as in [WIMP]. This avoids
premeditated redirection by detecting that some other entity is using
the same identifier at the peer and switching to use another
ephemeral ID.
A solution would need to combine elements which provide protection
against both premeditated and on-going communication redirection.
This can be done in several ways, and the current set of proposals do
not appear to contain all useful combinations. For instance, the HIP
CBID property could be used to prevent premeditated attacks while the
WIMP hash chains could be used to prevent on-going redirection. And
there are probably other interesting combinations.
A related, but perhaps separate aspect, is whether the solution
provides for protection against Man-in-The-Middle attacks with on-
path attackers. Some schemes, such as [HIP] and [NOID] do, but given
that an on-path attacker can see and modify the data traffic whether
or not it can modify the multihoming signaling, this level of
protection seems like overkill. Protecting against on-path MiTM for
the data traffic can be done separately using IPsec, TLS, etc.
Finally, preventing third party DoS attacks is conceptually simpler;
it would suffice to somehow verify that the peer is indeed reachable
at the new locator before sending a large number of packets to that
locator.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 45 change blocks. 
82 lines changed or deleted 317 lines changed or added

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