address; the resulting TCP SYN ACK packet will be sent to the spoofed
source address.
Devices on the path between two communicating entities can also
launch DoS attacks. While such attacks might not be interesting
today, it is necessary to understand them better in order to
determine whether a multihoming solution might enable new types of
DoS attacks.
For example, today, if A is communicating with B, then A can try to
overload the path from B to A. If TCP is used, A could do this by
sending ACK packets for data that it has not yet received (but it
suspects B has already sent) so that B would send at a rate that
would cause persistent congestion on the path towards A. Such an
attack would seem self-destructive since A would only make its own
corner of the network suffer by overloading the path from the
Internet towards A.
A more interesting case is if A is communicating with B and X is on
the path between A and B, then X might be able to fool B to send
packets towards A at a rate that is faster than A (and the path
between A and X) can handle. For instance, if TCP is used, then X
can craft TCP ACK packets claiming to come from A to cause B to use a
congestion window that is large enough to potentially cause
persistent congestion towards A. Furthermore, if X can suppress the
packets from A to B, it can also prevent A from sending any explicit
"slow down" packets to B; that is, X can disable any flow or
congestion control mechanism such as Explicit Congestion Notification
[ECN]. Similar attacks can presumably be launched using protocols
that carry streaming media by forging such a protocol’s notion of
acknowledgement and feedback.
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
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
of ACK packets might be relatively low. This type of attack might
not be common today because, in the presence of ingress filtering, it
requires that X remain on the path in order to sustain the DoS
attack. And in the absence of ingress filtering an attacker would
need either to be present on the path initially and then move away,
or to be able to perform the setup of the communication "blind",
i.e., without seeing the return traffic (which, in the case of TCP,
implies guessing the initial sequence number).
The danger is that the addition of multihoming redirection mechanisms
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
additional types of attacks in this area, or make existing types of
attacks significantly easier.
3.5. Address Privacy Today
In today’s Internet there is limited ability to track a host as it
uses the Internet because in some cases, such as dialup connectivity,
the host will acquire different IPv4 addresses each time it connects.
However, with increasing use of broadband connectivity, such as DSL
or cable, it is becoming more likely that the host will maintain the
same IPv4 over time. Should a host move around in today’s Internet,
for instance, by visiting WiFi hotspots, it will be configured with a
different IPv4 address at each location.
We also observe that a common practice in IPv4 today is to use some
form of address translation, whether the site is multihomed or not.
This effectively hides the identity of the specific host within a
site; only the site can be identified based on the IP address.
In the cases where it is desirable to maintain connectivity as a host
moves around, whether using layer 2 technology or Mobile IPv4, the
IPv4 address will remain constant during the movement (otherwise the
connections would break). Thus, there is somewhat of a choice today
between seamless connectivity during movement and increased address
privacy.
Today when a site is multihomed to multiple ISPs, the common setup is
that a single IP address prefix is used with all the ISPs. As a
result it is possible to track that it is the same host that is
communication via all ISPs.
However, when a host (and not a site) is multi-homed to several ISPs
(e.g., through a General Packet Radio Service (GPRS) connection and a
wireless hot spot), the host is provided with different IP addresses
on each interface. While the focus of the multihoming work is on
site multihoming, should the solution also be applicable to host
multihoming, the privacy impact needs to be considered for this case
as well.
IPv6 stateless address auto-configuration facilitates IP address
management, but raises some concerns since the Ethernet address is
encoded in the low-order 64 bits of the IPv6 address. This could
potentially be used to track a host as it moves around the network,
using different ISPs, etc. IPv6 specifies temporary addresses
[RFC3041], which allow applications to control whether they need
long-lived IPv6 addresses or desire the improved privacy of using
temporary addresses.
Given that there is no address privacy in site multihoming setups
today, the primary concerns for the "do no harm" criteria are to
ensure that hosts that move around still have the same ability as in
today’s Internet to choose between seamless connectivity and improved
address privacy, and also that the introduction of multihoming
support should still provide the same ability as we have in IPv6 with
temporary addresses.
When considering privacy threats, it makes sense to distinguish
between attacks made by on-path entities observing the packets flying
by, and attacks by the communicating peer. It is probably feasible
to prevent on-path entities from correlating the multiple IP
addresses of the host; but the fact that the peer needs to be told
multiple IP addresses in order to be able to switch to using
different addresses, when communication fails, limits the ability of
the host to prevent correlating its multiple addresses. However,
using multiple pseudonyms for a host should be able address this
case.
4. Potential New Attacks
This section documents the additional attacks that have been
discovered that result from an architecture where hosts can change
their topological connection to the network in the middle of a
transport session without interruption. This discussion is again
framed in the context where the topological locators may be
independent of the host identifiers used by the transport and
application layer protocols. Some of these attacks may not be
applicable if traditional addresses are used. This section assumes
that each host has multiple locators and that there is some mechanism
for determining the locators for a correspondent host. We do not
assume anything about the properties of these mechanisms. Instead,
this list will serve to help us derive the properties of these
mechanisms that will be necessary to prevent these redirection
attacks.
Depending on the purpose of the redirection attack, we separate the
attacks into several different types.
4.1. Cause Packets to Be Sent to the Attacker
An attacker might want to receive the flow of packets, for instance
to be able to inspect and/or modify the payload or to be able to
apply cryptographic analysis to cryptographically protected payload,
using redirection attacks.
Note that such attacks are always possible today if an attacker is on
the path between two communicating parties, and a multihoming
solution can’t remove that threat. Hence, the bulk of these concerns
relate to off-path attackers.
4.1.1. Once Packets Are Flowing
This might be viewed as the "classic" redirection attack.
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
is really X’s location.
"Standard" solutions to this include requiring that the host
requesting redirection somehow be verified to be the same host as the
initial host that established communication. However, the burdens of
such verification must not be onerous, or the redirection requests
themselves can be used as a DoS attack.
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
starts using that locator, and be able to do this when multiple
locators are assigned to A.
4.1.2. Time-Shifting Attack
The term "time-shifting attack" is used to describe an attacker’s
ability to perform an attack after no longer being on the path.
Thus, the attacker would have been on the path at some point in time,
snooping and/or modifying packets; and later, when the attacker is no
longer on the path, it launches the attack.
In the current Internet, it is not possible to perform such attacks
to redirect packets. But for some time after moving away, the
attacker can cause a DoS attack, e.g., by leaving a bogus ARP entry
in the nodes on the path, or by forging TCP Reset packets based on
having seen the TCP Initial Sequence Numbers when it was on the path.
It would be reasonable to require that a multihoming solution limit
the ability to redirect and/or DoS traffic to a few minutes after the
attacker has moved off the path.
4.1.3. Premeditated Redirection
This is a variant of the above where the attacker "installs" itself
before communication starts.
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,
I’m A and I’m at this location". When A later tries to communicate
with B, will B believe it is really A?
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
because X initiated communication.
Depending on details that would be specific to a proposed solution,
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
(where A would fail to communicate with B since it can’t prove it is
the same host as X).
To prevent this attack, the verification of whether a locator belongs
to the peer cannot simply be based on the first peer that made
contact.
4.1.4. Using Replay Attacks
While the multihoming problem doesn’t inherently imply any
topological movement, it is useful to also consider the impact of
site renumbering in combination with multihoming. In that case, the
set of 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 might be reassigned to some other site.
This potentially give an attacker the ability to replay whatever
protocol mechanism was used to inform a host of a peer’s locators so
that the host would incorrectly be led to believe that 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 [MIPv6],
but the time constant is quite different; Mobile IPv6 might see
movements every second while site renumbering, followed by
reassignment of the site locator prefix, might be a matter of weeks
or months.
To prevent such replay attacks, the protocol used to verify which
locators can be used with a particular identifier needs some replay
protection mechanism.
Also, in this space one needs to be concerned about potential
interaction between such replay protection and the administrative act
of reassignment of a locator. If the identifier and locator
relationship is distributed across the network, one would need to
make sure that the old information has been completely purged from
the network before any reassignment. Note that this does not require
an explicit mechanism. This can instead be implemented by locator
reuse policy and careful timeouts of locator information.
4.2. Cause Packets to Be Sent to a Black Hole
This is also a variant of the classic redirection attack. The
difference is that the new location is a locator that is nonexistent
or unreachable. Thus, the effect is that sending packets to the new
locator causes the packets to be dropped by the network somewhere.
One would expect that solutions that prevent the previous redirection
attacks would prevent this attack as a side effect, but it makes
sense to include this attack here for completeness. Mechanisms that
prevented a redirection attack to the attacker should also prevent
redirection to a black hole.
4.3. Third Party Denial-of-Service Attacks
An attacker can use the ability to perform redirection to cause
overload on an unrelated third party. For instance, if A and B are
communicating, then the attacker X might be able to convince A to
send the packets intended for B to some third node C. While this
might seem harmless at first, since X could just flood C with packets
directly, there are a few aspects of these attacks that cause
concern.
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
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.
Even if A had retained such state, that state would probably not be
easily available to C, thus C can’t determine who the attacker was
once C has become the victim of a DoS attack.
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
the attacker can fool another host, such as A, to redirect its
traffic to 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) connectivity, this difference could be substantial.
Thus, in effect, this could be similar to packet amplifying
reflectors in [PAXSON01].
The third, and final concern, is that if an attacker only need a few
packets to convince one host to flood a third party, then it wouldn’t
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-
Service attacks.
A third party DoS attack might be against the resources of a
particular host (i.e., C in the example above), or it might be
against the network infrastructure towards a particular IP address
prefix, by overloading the routers or links even though there is no
host at the address being targeted.
In today’s Internet, the ability to perform this type of attack is
quite limited. In order for the attacker to initiate communication,
it will in most cases need to be able to receive some packets from
the peer (the potential exception being techniques that combine this
with TCP-sequence-number-guessing techniques). Furthermore, to the
extent that parts of the Internet uses ingress filtering [INGRESS],
even if the communication could be initiated, it wouldn’t be possible
to sustain it by sending ACK packets with spoofed source addresses
from an off-path attacker.
If this type of attack can’t be prevented, there might be mitigation
techniques that can be employed. For instance, in the case of TCP a
partial defense can be constructed by having TCP slow-start be
triggered when the destination locator changes. (Folks might argue
that, separately from security, this would be the correct action for
congestion control since TCP might not have any congestion-relation
information about the new path implied by the new locator.)
Presumably the same approach can be applied to other transport
protocols that perform different forms of (TCP-friendly) congestion
control, even though some of them might not adapt as rapidly as TCP.
But since all congestion-controlled protocols probably need to have
some reaction to the path change implied by a locator change, it
makes sense to think about 3rd party DoS attacks when designing how
the specific transport protocols should react to a locator change.
However, this would only be a partial solution since it would
probably take several packets and roundtrips before the transport
protocol would stop transmitting; thus, an attacker could still use
this as a reflector with packet amplification. Thus, the multihoming
mechanism probably needs some form of defense against third party DoS
attacks, in addition to the help we can get from the transport
protocols.
4.3.1. Basic Third Party DoS
Assume that X is on a slow link anywhere in the Internet. B is on a
fast link (gigabits; e.g., a media server) and A is the victim.
X could flood A directly but is limited by its low bandwidth. If X
can establish communication with B, ask B to send it a high-speed
media stream, then X can presumably fake out the
"acknowledgements/feedback" needed for B to blast out packets at full
speed. So far, this only hurts X and the path between X and the
Internet. But if X could also tell B "I’m at A’s locator", then X
has effectively used this redirection capability in multihoming to
amplify its DoS capability, which would be a source of concern.
One could envision rather simple techniques to prevent such attacks.
For instance, before sending to a new peer locator, perform a clear
text exchange with the claimed new locator of the form "Are you X?"
resulting in "Yes, I’m X.". This would suffice for the simplest of
attacks. However, as we will see below, more sophisticated attacks
are possible.
4.3.2. Third Party DoS with On-Path Help
The scenario is as above, but, in addition, the attacker X has a
friend Y on the path between A and B:
----- ----- -----
| A |--------| Y |--------| B |
----- ----- -----
/
/
/
/
/
/
-----
| X |
-----
With the simple solution suggested in the previous section, all Y
might need to do is fake a response to the "Are you X?" packet, and
after that point in time Y might not be needed; X could potentially
sustain the data flow towards A by generating the ACK packets. Thus,
it would be even harder to detect the existence of Y.
Furthermore, if X is not the actual end system but an attacker
between some node C and B, then X can claim to be C, and no finger
can be pointed at X either:
----- ----- -----
| A |--------| Y |--------| B |
----- ----- -----
/
/
/
/
/
/
----- -----
| C |-------| X |
----- -----
Thus, with two attackers on different paths, there might be no trace
of who did the redirection to the 3rd party once the redirection has
taken place.
A specific case of this is when X=Y, and X is located on the same LAN
as B.
A potential way to make such attacks harder would be to use the last
received (and verified) source locator as the destination locator.
That way, when X sends the ACK packets (whether it claims to be X or
C) the result would be that the packet flow from B would switch back
towards X/C, which would result in an attack similar to what can be
performed in today’s Internet.
Another way to make such attacks harder would be to perform periodic
verifications that the peer is available at the locator, instead of
just one when the new locator is received.
A third way that a multihoming solution might address this is to
ensure that B will only accept locators that can be authenticated to
be synonymous with the original correspondent. It must be possible
to securely ensure that these locators form an equivalence class. So
in the first example, not only does X need to assert that it is A,
but A needs to assert that it is X.
4.4. Accepting Packets from Unknown Locators
The multihoming solution space does not only affect the destination
of packets; it also raises the question from which sources packets
should be accepted. It is possible to build a multihoming solution
that allows traffic to be recognized as coming from the same peer
even if there is a previously unknown locator present in the source
address field. The question is whether we want to allow packets from
unverified sources to be passed on to transport and application layer
protocols.
In the current Internet, an attacker can’t inject packets with
arbitrary source addresses into a session if there is ingress
filtering present, so allowing packets with unverified sources in a
multihoming solution would fail our "no worse than what we have now"
litmus test. However, given that ingress filtering deployment is far
from universal and ingress filtering typically wouldn’t prevent
spoofing of addresses in the same subnet, requiring rejecting packets
from unverified locators might be too stringent.
An example of the current state are the ability to inject RST packets
into existing TCP connections. When there is no ingress filtering in
the network, this is something that the TCP endpoints need to sort
out themselves. However, deploying ingress filtering helps in
today’s Internet since an attacker is limited in the set of source
addresses it can use.
A factor to take into account to determine the "requirement level"
for this is that when IPsec is used on top of the multihoming
solution, then IPsec will reject such spoofed packets. (Note that
this is different than in the redirection attack cases where even
with IPsec an attacker could potentially cause a DoS attack.)
There might also be a middle ground where arbitrary attackers are
prevented from injecting packets by using the SCTP verification tag
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
packet.) Such an approach doesn’t prevent packet injection from
on-path attackers (since they can observe the verification tag), but
neither does ingress filtering.
4.5. New 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, whether using the
same (set of) ISP(s) or moving between different network attachment
points. Designers of solutions to multihoming need to be aware of