this concern.
Introducing the multihoming capability inherently implies that the
communicating peers need to know multiple locators for each other in
order to be resilient to failures of some paths/locators. In
addition, if the multihoming signaling protocol doesn’t provide
privacy, it might be possible for 3rd parties on the path to discover
many or all the locators assigned to a host, which would increase the
privacy exposure compared to a multihomed host today.
For instance, a solution could address this 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].
5. Granularity of Redirection
Different multihoming solutions might approach the problem at
different layers in the protocol stack. For instance, there have
been proposals for 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 of 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 then
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
"transport" protocols that the implementation makes aware of
multihoming. In many cases there would be "transport" protocols 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/protocols 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) connections to 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.
The issue isn’t only about the space (granularity), but also about
the lifetime component in the results of a multihoming request. 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 signaling, 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.
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 if the attacker causes a
multihoming state to be created in various peer hosts while the
attacker was on the path, and that state remained 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
that 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" attacks 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 that
uses an ID/address to claim it without any time limit.
7. Other Security Concerns
The protocol mechanisms added as part of a multihoming solution
shouldn’t introduce any new DoS in the mechanisms themselves. In
particular, care must be taken not to:
- create state on the first packet in an exchange, since that could
result in state consumption attacks similar to the TCP SYN
flooding attack.
- perform much work on the first packet in an exchange (such as
expensive verification)
There is a potential chicken-and-egg problem here, because
potentially one would want to avoid doing work or creating state
until the peer has been verified, but verification will probably need
some state and some work to be done. Avoiding any work does not seem
possible, but good protocol design can often delay state creation
until verification has been completed.
A possible approach that solutions might investigate is to defer
verification until there appears to be two different hosts (or two
different locators for the same host) that want to use the same
identifier. In such a case one would need to investigate whether a
combination of impersonation and DoS attack can be used to prevent
the discovery of the impersonation.
Another possible approach is to first establish communications, and
then perform verification in parallel with normal data transfers.
Redirection would only be permitted after verification was complete,
but prior to that event, data could transfer in a normal,
non-multihomed manner.
Finally, the new protocol mechanisms should be protected against
spoofed packets, at least from off-path sources, and replayed
packets.
8. Security Considerations
In section 3, the document presented existing protocol-based
redirection attacks. But there are also non-protocol redirection
attacks. An attacker that can gain physical access to one of
- the copper/fiber somewhere in the path,
- a router or L2 device in the path, or
- one of the end systems
can also redirect packets. This could be possible, for instance, by
physical break-ins or by bribing staff that have access to the
physical infrastructure. Such attacks are out of scope of this
discussion, but are worth keeping in mind when looking at the cost
for an attacker to exploit any protocol-based attacks against
multihoming solutions; making protocol-based attacks much more
expensive to launch than break-ins/bribery type of attacks might be
overkill.
9. Acknowledgements
This document was originally produced by a MULTI6 design team
consisting of (in alphabetical order): Iljitsch van Beijnum, Steve
Bellovin, Brian Carpenter, Mike O’Dell, Sean Doran, Dave Katz, Tony
Li, Erik Nordmark, and Pekka Savola.
Much of the awareness of these threats come from the work on Mobile
IPv6 [MIPv6, NIKANDER03, AURA02].
As the document has evolved, the MULTI6 WG participants have
contributed to the document. In particular: Masataka Ohta brought
up privacy concerns related to stable identifiers. The suggestion to
discuss transport versus IP granularity was contributed by Marcelo
Bagnulo, who also contributed text to Appendix B. Many editorial
clarifications came from Jari Arkko.
10. Informative References
[NSRG] Lear, E. and R. Droms, "What’s In A Name: Thoughts from
the NSRG", Work in Progress, September 2003.
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[AURA02] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses",
Work in Progress, March 2002.
[NIKANDER03] Nikander, P., T. Aura, J. Arkko, G. Montenegro, and E.
Nordmark, "Mobile IP version 6 Route Optimization
Security Design Background", Work in Progress, December
2003.
[PAXSON01] V. Paxson, "An Analysis of Using Reflectors for
Distributed Denial-of-Service Attacks", Computer
Communication Review 31(3), July 2001.
[INGRESS] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP
Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[SCTP] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[DNS-THREATS] Atkins, D. and R. Austein, "Threat Analysis of the
Domain Name System (DNS)", RFC 3833, August 2004.
[FYI18] Malkin, G., "Internet Users’ Glossary", RFC 1983,
August 1996.
[ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The
Addition of Explicit Congestion Notification (ECN) to
IP", RFC 3168, September 2001.
[OWNER] Nikander, P., "Denial-of-Service, Address Ownership,
and Early Authentication in the IPv6 World", Security
Protocols 9th International Workshop, Cambridge, UK,
April 25-27 2001, LNCS 2467, pages 12-26, Springer,
2002.
[RFC1948] Bellovin, S., "Defending Against Sequence Number
Attacks", RFC 1948, May 1996.
[PBK] Scott Bradner, Allison Mankin, Jeffrey Schiller, "A
Framework for Purpose-Built Keys (PBK)", Work in
Progress, June 2003.
[NOID] Erik Nordmark, "Multihoming without IP Identifiers",
Work in Progress, July 2004.
[HIP] Pekka Nikander, "Considerations on HIP based IPv6
multi-homing", Work in Progress, July 2004.
[WIMP] Jukka Ylitalo, "Weak Identifier Multihoming Protocol
(WIMP)", Work in Progress, June 2004.
[CBHI] Iljitsch van Beijnum, "Crypto Based Host Identifiers",
Work in Progress, February 2004.
[TCPSECURE] M. Dalal (ed), "Transmission Control Protocol security
considerations", Work in Progress, November 2004.
Appendix A: 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
This seems to be related to the fact that there are two different
classes of use of identifiers. One use is for:
o Initially establishing communication; looking up an FQDN to find
something that is passed to a connect() or sendto() API call.
o Comparing whether a peer entity is the same peer entity as in some
previous communication.
o Using the identity of the peer for future communication
("callbacks") in the reverse direction, or to refer to a 3rd party
("referrals").
The other use of identifiers is as part of being able to redirect
existing communication to use a different locator.
The first class of use seems to be related to something about the
ownership of the identifier; proving the "ownership" of the
identifier should be sufficient in order to be authorized to control
which locators are used to reach the identifier.
The second class of use seems to be related to something more
ephemeral. In order to redirect the existing communication to some
other locator, it seems to be sufficient to prove that the entity is
the same as the one that initiated the communication. One can view
this as proving the ownership of some context, where the context is
established around the time when the communication is initiated.
Preventing unauthorized redirection of existing communication can be
addressed by a large number of approaches that 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 preventing unauthorized use of an
identifier can be quite different. One way to prevent premeditated
redirection is to simply not introduce a new identifier name space,
and instead to rely on existing name space(s), a trusted third party,
and a sufficiently secure way to access the third party, as in
[NOID]. Such an approach relies on the third party (DNS in the case
of NOID) as the foundation. In terms of multihoming state creation,
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 the initiator does 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. While the ephemeral identifiers might
be problematic when used by applications, for instance due to
callbacks or referrals, note that for the end that has the ephemeral
identifier, one can skirt around the premeditated attacks (assuming
the solution has a robust way to pick a new identifier when one is in
use/stolen).
Assuming the problem can’t be skirted by using ephemeral identifiers,
there seem to be 3 types of approaches that can be used to establish
some form of identity ownership:
- A trusted third party, which states that a given identity is
reachable at a given set of locators, so the endpoint reached at
one of this locators is the owner of the identity.
- Crypto-based identifiers or crypto-generated addresses where the
public/private key pair can be used to prove that the identifier
was generated by the node knowing the private key (or by another
node whose public key hashes to the same value)
- A static binding, as currently defined in IP, where you trust that
the routing system will deliver the packets to the owner of the
locator, and since the locator and the identity are one, you prove
identity ownership as a sub-product.
A solution would need to combine elements that provide protection
against both premeditated and ongoing 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.
Just as the redirection attacks are conceptually prevented by proving
at some level the ownership of the identifier or the ownership of the
communication context, third party DoS attacks are conceptually
prevented by showing that the endpoint is authorized to use a given
locator.
The currently known approaches for showing such authorization are:
- Return routability. That is, if an endpoint is capable of
receiving packets at a given locator, it is because he is
authorized to do so. This relies on routing being reasonably hard
to subvert to deliver packets to the wrong place. While this
might be the case when routing protocols are used with reasonable
security mechanisms and practices, it isn’t the case on a single
link where ARP and Neighbor Discovery can be easily spoofed.
- Trusted third party. A third party establishes that a given
identity is authorized to use a given set of locators (for
instance the DNS).
Authors’ Addresses
Erik Nordmark
Sun Microsystems, Inc.
17 Network Circle
Mountain View, CA 94025
USA
Phone: +1 650 786 2921
Fax: +1 650 786 5896
EMail: erik.nordmark@sun.com
Tony Li
EMail: Tony.Li@tony.li
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.