Network Working Group E. Nordmark Request for Comments: 4218 Sun Microsystems Category: Informational T. Li October 2005 Threats Relating to IPv6 Multihoming Solutions Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005).
AbstractThis document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses. The intent is to look at how IPv6 multihoming solutions might make the Internet less secure; we examine threats that are inherent to all IPv6 multihoming solutions rather than study any specific proposed solution. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work. 1. Introduction ....................................................2 1.1. Assumptions ................................................3 1.2. Authentication, Authorization, and Identifier Ownership ....4 2. Terminology .....................................................5 3. Today's Assumptions and Attacks .................................6 3.1. Application Assumptions ....................................6 3.2. Redirection Attacks Today ..................................8 3.3. Packet Injection Attacks Today .............................9 3.4. Flooding Attacks Today ....................................10 3.5. Address Privacy Today .....................................11 4. Potential New Attacks ..........................................13 4.1. Cause Packets to Be Sent to the Attacker ..................13 4.1.1. Once Packets Are Flowing ...........................13 4.1.2. Time-Shifting Attack ...............................14 4.1.3. Premeditated Redirection ...........................14 4.1.4. Using Replay Attacks ...............................15
4.2. Cause Packets to Be Sent to a Black Hole ..................15 4.3. Third Party Denial-of-Service Attacks .....................16 4.3.1. Basic Third Party DoS ..............................17 4.3.2. Third Party DoS with On-Path Help ..................18 4.4. Accepting Packets from Unknown Locators ...................19 4.5. New Privacy Considerations ................................20 5. Granularity of Redirection .....................................20 6. Movement Implications? .........................................22 7. Other Security Concerns ........................................23 8. Security Considerations ........................................24 9. Acknowledgements ...............................................24 10. Informative References ........................................25 Appendix A: Some Security Analysis ................................27
As a result of not analyzing a particular solution, this document is inherently incomplete. An actual solution would need to be analyzed as part of its own threat analysis, especially in the following areas: 1) If the solution makes the split between locators and identifiers, then most application security mechanisms should be tied to the identifier, not to the locator. Therefore, work would be needed to understand how attacks on the identifier mechanism affect security, especially attacks on the mechanism that would bind locators to identifiers. 2) How does the solution apply multihoming to IP multicast? Depending on how this is done, there might be specific threats relating to multicast that need to be understood. This document does not discuss any multicast-specific threats. 3) Connection-less transport protocols probably need more attention. They are already difficult to secure, even without a locator/identifier split.
In some cases it might make sense to make a distinction between on-path attackers, which can monitor packets and perhaps also inject packets, without being able to block packets from passing through. On-path attackers that only need to monitor might be lucky and find a non-switched Ethernet in the path, or use capacitive or inductive coupling to listen on a copper wire. But if the attacker is on an Ethernet that is on the path, whether switched or not, the attacker can also employ Address Resolution Protocol/Neighbor Discovery (ARP/ND) spoofing to get access to the packet flow which allows blocking as well. Similarly, if the attacker has access to the wire, the attacker can also place a device on the wire to block. Other on-path attacks would be those that gain control of a router or a switch (or gain control of one of the endpoints), and most likely those would allow blocking as well. So the strongest currently known case where monitoring is easier than blocking, is when switches and routers have monitoring capabilities (for network management or for lawful intercept) where an attacker might be able to bypass the authentication and authorization checks for those capabilities. However, this document makes the simplifying assumption treat all on-path attackers the same by assuming that such an attacker can monitor, inject, and block packets. A security analysis of a particular proposal can benefit from not making this assumption, and look at how on-path attackers with different capabilities can generate different attacks perhaps not present in today's Internet. The document assumes that an off-path attacker can neither see packets between the peers (for which it is not on the path) nor block them from being delivered. Off-path attackers can, in general, send packets with arbitrary IP source addresses and content, but such packets might be blocked if ingress filtering [INGRESS] is applied. Thus, it is important to look at the multihoming impact on security both in the presence and absence of ingress filtering.
Hence, there is a different way to describe the same thing. If the peer can somehow prove that it is the owner of the identifier, and the communication is bound to the identifier (and not the locator), then the peer is allowed to control the locators that are used with the identifier. This way to describe the problem is used in [OWNER]. Both ways to look at the problem, hence both sets of terminology, are useful when trying to understand the problem space and the threats. NSRG]), that is, something that might be commonly referred to as a "host". The transport endpoint name is a function of the transport protocol and would typically include the IP identifier plus a port number. There might be use for having multiple identifiers per stack/per host. An identifier continues to function regardless of the state of any one interface.
address field - the source and destination address fields in the IPv6 header. As IPv6 is currently specified, these fields carry "addresses". If identifiers and locators are separated, these fields will contain locators. FQDN - Fully Qualified Domain Name [FYI18]
The second class of security configurations uses existing IP source addresses from outside of their immediate local site as a means of authentication without any form of verification. Today, with source IP address spoofing and TCP sequence number guessing as rampant attacks [RFC1948], such applications are effectively opening themselves for public connectivity and are reliant on other systems, such as firewalls, for overall security. We do not consider this class of configurations in this document because they are in any case fully open to all forms of network layer spoofing. The third class of security configurations receives existing IP source addresses, but attempt some verification using the DNS, effectively using the FQDN for access control. (This is typically done by performing a reverse lookup from the IP address, followed by a forward lookup and verifying that the IP address matches one of the addresses returned from the forward lookup.) These applications are already subject to a number of attacks using techniques like source address spoofing and TCP sequence number guessing since an attacker, knowing this is the case, can simply create a DoS attack using a forged source address that has authentic DNS records. In general this class of security configurations is strongly discouraged, but it is probably important that a multihoming solution doesn't introduce any new and easier ways to perform such attacks. However, we note that some people think we should treat this class the same as the second class of security configurations. The fourth class of security configurations uses cryptographic security techniques to provide both a strong identity for the peer and data integrity with or without confidentiality. Such systems are still potentially vulnerable to denial of service attacks that could be introduced by a multihoming solution. Finally, the fifth class of security configurations uses cryptographic security techniques, but without strong identity (such as opportunistic IPsec). Thus, data integrity with or without confidentiality is provided when communicating with an unknown/unauthenticated principal. Just like the first category above, such applications can't perform access control based on network layer information since they do not know the identity of the peer. However, they might perform access control using higher-level notions of identity. The availability of IPsec (and similar solutions) together with channel bindings allows protocols (which, in themselves, are vulnerable to man-in-the-middle (MITM) attacks) to operate with a high level of confidentiality in the security of the identification of the peer. A typical example is the Remote Direct Data Placement Protocol (RDDP), which, when used with opportunistic IPsec, works well if channel bindings are available. Channel
bindings provide a link between the IP-layer identification and the application protocol identification. A variant of the fifth class are those that use "leap-of-faith" during some initial communication. They do not provide strong identities except where subsequent communication is bound to the initial communication, providing strong assurance that the peer is the same as during the initial communication. The fifth class is important and its security properties must be preserved by a multihoming solution. The requirement for a multihoming solution is that security be no worse than it is today in all situations. Thus, mechanisms that provide confidentiality, integrity, or authentication today should continue to provide these properties in a multihomed environment. DNS-THREATS]. Any system that is along the path from the source to the destination host can be compromised and used to redirect traffic. Systems may be added to the best path to accomplish this. Further, even systems that are on multi-access links that do not provide security can also be used to redirect traffic off of the normal path. For example, ARP and ND spoofing can be used to attract all traffic for the legitimate next hop across an Ethernet. And since the vast majority of applications rely on DNS lookups, if DNSsec is not deployed, then attackers that are on the path between the host and the DNS servers can also cause redirection by modifying the responses from the DNS servers. In general, the above attacks work only when the attacker is on the path at the time it is performing the attack. However, in some cases it is possible for an attacker to create a DoS attack that remains at least some time after the attacker has moved off the path. An
example of this is an attacker that uses ARP or ND spoofing while on path to either insert itself or send packets to a black hole (a non-existent L2 address). After the attacker moves away, the ARP/ND entries will remain in the caches in the neighboring nodes for some amount of time (a minute or so in the case of ARP). This will result in packets continuing to be black-holed until ARP entry is flushed. Finally, the hosts themselves that terminate the connection can also be compromised and can perform functions that were not intended by the end user. All of the above protocol attacks are the subject of ongoing work to secure them (DNSsec, security for BGP, Secure ND) and are not considered further within this document. The goal for a multihoming solution is not to solve these attacks. Rather, it is to avoid adding to this list of attacks. INGRESS], the IP layer allows the sender to use an arbitrary source address, thus the transport protocols and/or applications need some protection against malicious senders injecting bogus packets into the packet stream between two communicating peers. If this protection can be circumvented, then it is possible for an attacker to cause harm without necessarily needing to redirect the return packets. There are various levels of protection in different transport protocols. For instance, in general TCP packets have to contain a sequence that falls in the receiver's window to be accepted. If the TCP initial sequence numbers are random, then it is very hard for an off-path attacker to guess the sequence number close enough for it to belong to the window, and as a result be able to inject a packet into an existing connection. How hard this is depends on the size of the available window, whether the port numbers are also predictable, and the lifetime of the connection. Note that there is ongoing work to strengthen TCP's protection against this broad class of attacks [TCPSECURE]. SCTP provides a stronger mechanism with the verification tag; an off-path attacker would need to guess this random 32-bit number. Of course, IPsec provides cryptographically strong mechanisms that prevent attackers, on or off path, from injecting packets once the security associations have been established.
When ingress filtering is deployed between the potential attacker and the path between the communicating peers, it can prevent the attacker from using the peer's IP address as source. In that case, the packet injection will fail in today's Internet. We don't expect a multihoming solution to improve the existing degree of prevention against packet injection. However, it is necessary to look carefully at whether a multihoming solution makes it easier for attackers to inject packets because the desire to have the peer present at multiple locators, and perhaps at a dynamic set of locators, can potentially result in solutions that, even in the presence of ingress filtering, make packet injection easier. PAXSON01]. Reflection without amplification can be accomplished by an attacker 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 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.
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.
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.
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.
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.
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.
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. RFC3041].
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. 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.
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. 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.
[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.
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).
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- firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.