Network Working Group G. Montenegro Internet-Draft Sun Labs, Europe Expires: October 4, 2002 P. Nikander Ericsson Research NomadicLab April 5, 2002 Protecting Against Bidding Down Attacks draft-montenegro-mipv6sec-bit-method-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 4, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Mobile IPv6 uses "return routability" to secure route optimization. Even after using this procedure, there are residual threats for which other stronger methods provide protection. Since these are optional, and return routability is the default, an attacker may engage in "bidding down" attacks. These attacks aim at coercing participants in Mobile IPv6 route optimization to forgo the stronger methods for the default return routability. This document discusses what the participants in route optimization can do to deter or alleviate bidding down attacks: the "step down" procedure for the mobile node and the "bit method" at the correspondent node. Montenegro & Nikander Expires October 4, 2002 [Page 1] Internet-Draft Protecting Against Bidding Down Attacks April 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Bidding Down Attacks . . . . . . . . . . . . . . . . . . . . 6 2.1 Man-in-the-Middle Attack (MiTM) . . . . . . . . . . . . . . 7 2.1.1 General Case . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.2 Attack in the Mobile IPv6 Case . . . . . . . . . . . . . . . 8 2.1.3 Mallory situated between the Home Agent and Bob . . . . . . 10 2.2 Impostor Attack . . . . . . . . . . . . . . . . . . . . . . 11 3. Defending Against Bidding Down Attacks . . . . . . . . . . . 12 3.1 Step Down Procedure . . . . . . . . . . . . . . . . . . . . 12 3.2 Bit Method . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . 15 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 Full Copyright Statement . . . . . . . . . . . . . . . . . . 18 Montenegro & Nikander Expires October 4, 2002 [Page 2] Internet-Draft Protecting Against Bidding Down Attacks April 2002 1. Introduction Mobile IPv6 [2] must support route optimization between mobile nodes and correspondent nodes that have no previous security relationship with each other. It must do so without recourse to infrastructure based solutions. The default mechanism used is called "return routability" (RR). Since RR is not based on strong cryptographic assurances there are residual threats (see Residual_Threats.txt [1]), in particular, the so called "future attacks" [3][4], as compared to the baseline case of IPv6 without mobility, Bidding down attacks raise serious concerns in two special areas: 1. Effects on Stationary Nodes A stationary node may not wish to be involved in route optimization as a mobile node (i.e. to redirect its address by asking its correspondent nodes to instal binding cache entries on its behalf). Such a node would benefit from the ability to unequivocally (and securely) indicate that they never redirect their address. Otherwise, it can fall prey to attacks which exploit the residual threats allowed by RR. This is potentially a very serious threat, because it can make any "legacy" node in the Internet vulnerable to the future attacks. This includes nodes which are always stationary and which would never do that which mobile nodes do when they move: use RR to ask their peers to insert binding cache entries on their behalf (to redirect their addresses). Popular servers would be prime targets for attack given their well-known addresses: rogue nodes could "redirect" them by installing bogus binding cache entries. Of course, all IPv6 nodes are expected to implement route optimization as correspondent nodes, but not as mobile nodes. Therefore, it is highly desirable to set up a mechanism that allows correspondent nodes to easily check whether a given node's address is redirectable or not. 2. Implications for Improved IPv6 Signaling Security There are implications with respect to a future Internet with improved IPv6 control signaling security. For example, it is conceivable that Neighbour Discovery security could be improved. Due to existing issues with Neighbor Discovery [5] RR does not make current on-link security much worse. However, this could change as a result of improvements in ND security, and as a result RR might be left as the weakest link in Internet security. There is a need to future-proof IPv6 by (1) putting mechanisms in place Montenegro & Nikander Expires October 4, 2002 [Page 3] Internet-Draft Protecting Against Bidding Down Attacks April 2002 from the very start, and (2) requiring that all IPv6 nodes implement them. Only such an arrangement would allow a secure migration towards more secure Binding Update authorization mechanisms, for example, at the same time as ND is improved. However, this is very hard if attackers can claim that the nodes in question only support RR. Because of this, it is essential to allow other (non-default) stronger mechanisms to be used instead of RR. Thus, the selection mechanism should be impervious to the "bidding down" attack, in which an attacker forces parties that are initially interested in engaging in a more secure procedure, to fall back on a less secure one. All Mobile IPv6 implementations should protect against the "bidding down" attack. Several such mechanisms have been proposed. This document reviews the step down procedure used in conjunction with the "bit method" and examines their effectivity. The "bit method" essentially divides the IPv6 interface identifier space into two. Addresses from one space allow a node to express the following to its peers: "(1) I do not engage in redirection operations on my address, or, if I do, (2) I only do so with cryptographically strong mechanisms in which I will prove to your satisfaction that I do have authorization to use that address." Addresses from the other space allow a node to express the following to its peers: "(3) I engage in redirection operations on my address and do not intend to prove conclusively that I do have authorization to use this address (e.g. RR is ok)" (3) is a viable tradeoff for a mobile node to make: yes, there are some vulnerabilities, but it obtains route optimization by being able to redirect its address with a relatively simple mechanism free of intellectual property. For an unsuspecting stationary node that is not interested in redirecting its address, (3) may not be a viable tradeoff. It essentially means that the node only obtains the negative side of the tradeoff (it becomes a potential victim of the vulnerabilities in RR), as it is not at all interested in the benefit (route optimization of its addresses). Montenegro & Nikander Expires October 4, 2002 [Page 4] Internet-Draft Protecting Against Bidding Down Attacks April 2002 An attacker could just claim that the address is his and insert a binding cache entry (a host route) into any correspondent node. This will break communications between the correspondent node and the stationary node. If, on the other hand, the address expresses either (1) or (2) above to the correspondent node, this attack is no longer possible: the correspondent node will expect a cryptographic proof of authorization. If the attacker can produce it, there are much more serious problems at hand. Nevertheless, it is not absolutely necessary to separate the address space as described above by using the "bit method." It is enough to require all nodes interested in redirecting their addresses to prove cryptographically that their address is redirectable. This implies that ALL redirectable addresses must be "Hash Based Addresses," that is, they must be derived from a secure hash of some bit sequence (not necessarily a Public Key), and require proof of that derivation as part of the redirection procedure (e.g. route optimisation). Since stationary hosts do not produce their addresses in this manner, they are protected by the difficulty in inverting the secure hash: it is prohibitively expensive for attackers to produce derivation proofs for "stationary" addresses. The problem is that these "Hash Based Addresses" have IPR concerns. At the time of this writing it is not at all clear if those issues will be resolved. Accordingly, this document deals with what the Mobile IPv6 Security Design Team believes to be the second best method: the "bit method." Nonetheless, other methods are mentioned in Section 3.2. Section 2 discusses the Bidding Down attack, examining its implications with respect to the mobile node and the correspondent node. Thus, it motivates a subsequent Section 3 on the defense mechanisms. Montenegro & Nikander Expires October 4, 2002 [Page 5] Internet-Draft Protecting Against Bidding Down Attacks April 2002 2. Bidding Down Attacks The problem at hand consists of a node that wishes to affect how another node routes packets to it. Given that the problem is not limited to Mobile IP, it is worthwhile to adopt a more general model. Alice is the node that wishes to alter how Bob routes packets to it. We also assume that there is an attacker, Mallory, that launches the bidding down attack. Bidding down attacks exist in general outside the domain of Mobile IP. The analysis starts with a general model in which it may be more difficult to implement defenses, and then proceeds to the more specific Mobile IP model. Assume Alice and Bob are capable of two flavors of secure exchanges: "strong" flavor: As part of the exchange, Alice can provide cryptographical assurances to Bob about some of its properties, including its address (every single bit in it). This can be obtained in a variety of manners, infrastructure-less (CGA [6][7]) or infrastructure-based (PKI, key distribution center, trusted third party, AAA, etc). The exact method used does not matter. What matters is the requirement that in a strong exchange Alice can cryptographically prove to Bob certain properties about itself (including its address). The exchange itself is also integrity protected. "Strong" schemes under consideration for Mobile IP all do, of course, satisfy these requirements. "weak" flavor: As part of the exchange, Alice *cannot* provide cryptographical assurances to Bob about some of its properties, including its address. Alice wants to engage Bob in an exchange, and Mallory wishes to affect the result of the exchange such that they end up using the weak flavor. Let's assume a fixed bit (or bit pattern) in Alice's address (the "bit method") makes an explicit distinction between addresses used with the "strong" and "weak" exchanges. The objective is to avoid bidding down from the "strong" to the "weak" flavor. Of course, if Alice implements the "strong" exchange, a very valid policy would be for it not to engage any more in "weak" exchanges. This simplifies Alice's protocol processing and is more secure because Alice avoids any risk of falling victim to a bidding down attack. For a mobile node, this translates to requiring a "strong" mechanism for route optimization. The mobile node simply forgoes the benefits of route optimization and limits itself to bidirectional Montenegro & Nikander Expires October 4, 2002 [Page 6] Internet-Draft Protecting Against Bidding Down Attacks April 2002 tunneling [2] when it communicates with correspondent nodes that only implement the "weak" RR mechanism. If, however, Alice continues to employ the "strong" and "weak" exchanges, she cannot use the same address for both. Because of the fixed bit pattern in the address, in essence, she appears to her peers as two different hosts ("strong" Alice versus "weak" Alice), depending on which of her two different addresses she uses: As: address used with the "strong" exchange. Aw: address used with the "weak" exchange. At least the interface ID portions of these addresses (lower 64 bits) will most probably be completely different and uncorrelated. This is true of CGA [6][7] mechanisms under consideration as "strong" infrastructureless mechanisms for route optimization. Therefore, it is not always possible for an observer to derive one address from the other, although some methods may allow it. If, in fact, the routing prefix portions of both addresses (higher 64 bits) are also uncorrelated, the possibility that Mallory can remain "in the middle" is negligible. An attacker that can achieve such a feat has already subverted the routing infrastructure to such a degree that it will be in a position to launch much more serious attacks. Accordingly, if Alice uses both the "strong" and "weak" mechanisms, it is in her best interest to make sure that the corresponding addresses are completely uncorrelated (both the routing prefixes as well as the interface ID's). Additionally, if Alice is a mobile node it will also use a care-of address at its visiting link. 2.1 Man-in-the-Middle Attack (MiTM) Suppose the following situation: Alice ==== Mallory ==== Bob Mallory's convenient location may have been acquired by exploiting vulnerabilities in neighbor discovery, or by gaining control of a conveniently located network element (a router, for example). It is important to point out that routers that carry both incoming and outgoing traffic for Alice are in an ideal position to launch DoS attacks. 2.1.1 General Case The simplest attack is as follows: Montenegro & Nikander Expires October 4, 2002 [Page 7] Internet-Draft Protecting Against Bidding Down Attacks April 2002 Alice(As,strong) ===> Mallory X Bob Alice <== Mallory (weak) X Bob Alice sends, among other things, its "strong" address, itself an indication that it wishes to engage in the strong exchange. Mallory throws this packet away and replies spoofing Bob, indicating a preference for the weak variant. Notice that if Mallory is on the path ingress filtering does not apply to this spoofed packet. Also, this is much simpler than rewriting Alice's address with a "weak" address and then sending the packet to Bob. Mallory simply repeats this for any signaling packets to Bob in which Alice uses its strong address. The hope is that eventually, Alice will give up and use its weak address, at which point, Mallory will let the traffic through, presumably, because it can break the protocol: Alice(Aw,weak) ===> Mallory ==> Bob Alice(Aw,weak) <== Mallory <== Bob The above step is not as obvious as it seems. As explained above, generally there is no correlation whatsoever between the previous As address observed by Mallory, and the subsequent Aw address once Alice gives up and settles for the weak exchange. Mallory would need to use heuristics, or look at link layer information in order to establish that this newly observed address Aw belongs to Alice. Alternatively, Mallory could just be on the lookout for any signaling exchange carried out with weak addresses in order to exploit them. The attack depends on Mallory's being able to selectively drop all the exchange signaling packets from Alice and substitute them with its own. This also depends on As and Aw using the same route (both going through Mallory). 2.1.2 Attack in the Mobile IPv6 Case The above attack is not nearly as easy in MobileIPv6, because it is much harder for Mallory to selectively drop the exchange signaling packets from Alice and substitute with its own. This difficulty stems from the fact that in the RR mechanism, the mobile node sends simultaneous RR "initialization" messages through two different routes. The figure below shows a summarized rendition of the RR exchange. In it, messages 1 (HoTI) and 2 (CoTI) initialize the RR process. The mobile node reverse tunnels the HoTI via its Montenegro & Nikander Expires October 4, 2002 [Page 8] Internet-Draft Protecting Against Bidding Down Attacks April 2002 home agent (first route), and it sends the CoTI directly (second route). Likewise, the correspondent node responds with parallel messages by sending the HOT to the mobile node's home address HoA (which is then intercepted and tunneled to the mobile node's current location by the home agent), and the COT directly to the mobile node at its care-of address CoA. The mobile node is able to send a valid binding update (message 5) only after it receives valid HOT and COT messages [2]. 1. MN(HoA) -> CN: HoTI(HoA, ...) 2. MN(CoA) -> CN: CoTI(CoA, ...) 3. CN -> MN(HoA): HoT(...) 4. CN -> MN(CoA): CoT(...) 5. MN(CoA) -> CN: BU(HoA, CoA, ...) Of course, if Mallory is on Alice's local link it can discard all its packets. But this constitutes a DoS attack. To carry out a bidding down attack, Mallory must be more subtle. It must not to alert Alice that something out of the ordinary is happening. Thus it needs to be very selective as to which packets it will act upon. Because of this it is much safer for Alice to encrypt messages tunneled through its home agent, as MIPv6 says it SHOULD. Furthermore, it is much safer to encrypt the tunneled packets, and not merely the Mobility Header messages. This way Mallory cannot distinguish between data and signalling packets being tunneled by Alice through her home agent (HA). Here, both the strong and weak exchanges share the RR (return routability) procedure in which Alice and Bob exchange packets in parallel via topologically independent routes. Since the MN to HA path should be encrypted, this makes it very difficult for Mallory to actually remain in the middle (i.e. be able to see and selectively modify traffic) for all the packet exchanges. Suppose Alice using a strong address MN is the mobile node, and Bob is the correspondent node. Alice initiates the RR exchange by sending two packets simultaneously (HoTI via the home agent, and CoTI directly to the correspondent node), both of which express preference for a strong exchange. This preference is indicated in two ways by the HoTI: o by the use of a "strong" address, and o by explicit fields within the signaling packet The CoTI only uses the latter indication. The above attack would be: Montenegro & Nikander Expires October 4, 2002 [Page 9] Internet-Draft Protecting Against Bidding Down Attacks April 2002 strong HoTI: CoA(encrypted tunnel) ===> HA ==> Bob strong CoTI: CoA ===> Mallory X Bob Notice that Mallory is no longer "in the middle" because the HoT packet is encrypted. Mallory may discard only the packet it sees. In the second phase of the attack, the RR responses to the above arrive at Alice: strong HoT: CoA(encrypted tunnel) <=== HA <== Bob weak CoT: CoA <=== Mallory X Bob Alice must wait to receive both the HoT and the CoT before proceeding with the RR procedure. It will see two conflicting replies from Bob. In particular, it is quite suspicious that the safe reply (the HoT via the encrypted tunnel from its HA) indicates a preference for a strong exchange, while the CoT indicates the opposite. This is already a very strong indication that an attack is under way. However, if Alice is not encrypting, or if it is selectively encrypting only the signaling portion of the packets, it is possible for Mallory to launch the attack. Namely, it can discard signaling packets from Alice (HoTI and CoTI) and reply with its own indicating a preference for a weak exchange. In this case, both HoT and CoT would be consistent, and Alice might restart the RR procedure using its weak address in a subsequent HoTI. 2.1.3 Mallory situated between the Home Agent and Bob The above procedure is particularly important in this case. In this situation, RR is known to be breakable, and if Mallory is able to place itself in the middle (with the ability to discard packets selectively) then there is no further protection. However, if neighbor discovery is secure in the future, this may be very difficult for Mallory to achieve. In this case, the required retransmissions will give the mobile node a chance to hear back from the real correspondent node in case it does in fact support the strong exchange. Simply put, Alice must handle bidding down attacks by being very stubborn and insisting on (and re-requesting) a strong exchange. Protection on Bob's side is much simpler. It simply hinges on the fact that Bob will never engage in weak exchanges with nodes whose address have the bits set to indicate preference for a strong exchange. Montenegro & Nikander Expires October 4, 2002 [Page 10] Internet-Draft Protecting Against Bidding Down Attacks April 2002 2.2 Impostor Attack Mallory === Bob Alice .../ Here, Alice may not be actively communicating with Bob. It need not even be on line. Mallory poses as Alice and tries to convince Bob. We assume that Alice is either a stationary node that does participate in redirection procedures at all, or, if it does, that it wishes to use something other than the "weak" flavor: it does not use the baseline RR as its binding update authorization method, instead preferring a much stronger alternative. The attack starts by the attacker (Mallory) sending a fake request to the correspondent node (Bob), indicating the desire to use RR in the request. The correspondent node (Bob), not having any knowledge of the true desires of the mobile node (Alice) accepts this. 1. Attacker sends first message(s) of RR to the correspondent node (the HoTI and CoTI messages). In this network scenario both messages can be sent from the attacker's location towards the correspondent node. This is because the attacker can place itself between the correspondent node and the CoA by carefully choosing the care-of address it uses in RR. This can be done easily, for example, by selecting an address from the network where the attacker is located. 2. The correspondent node inspects the messages and continues the RR protocol by sending its COT and HOT messages. 3. Once the attacker receives the responses it is in a position to send a valid binding update. As a result, the attacker has established a binding cache entry for the mobile node's (Alice's) address at the correspondent node. It only had to use RR regardless of the mobile node's preference for a stronger mechanism. Montenegro & Nikander Expires October 4, 2002 [Page 11] Internet-Draft Protecting Against Bidding Down Attacks April 2002 3. Defending Against Bidding Down Attacks As can be seen from the analysis above, bidding down attacks have different characteristics depending on whether they are looked at from the point of view of the mobile node or the correspondent node. Accordingly, they must use different mechanisms. The two following sections detail the defenses used by the mobile node (Step Down Procedure) and the correspondent node (Bit Method). 3.1 Step Down Procedure By following certain rules a mobile node reduces the possibility of a bidding down attack and remains in control. This is called the step down procedure. When Mallory is on the same link as mobile node Alice it can launch attacks to make her desist of the strong mechanism and settle for the weak one. In order to prevent falling victim to these attacks, Alice must be very careful as to the conditions under which it will give up on using the strong mechanism. To begin with, above it has been noted that Alice MUST have valid HoT and CoT packets that indicate preference for the weak exchange. In the event that Mallory also produces false HoT packets, Alice MUST be able to give preference to those received from its HA under the protection of the ESP tunnel. It is not clear how this information is kept with the packet after it has been decapsulated and extracted from its ESP protection. Because Mallory could be dropping packets from the HA, Alice MUST handle bidding down packets in similar manner to how it handles lost packets and the corresponding retransmissions. The rules for a mobile node to carry out a step down procedure are: o Both a valid HoT and CoT are required to initiate a step down procedure. o The procedure requires two more pairs of related HoT and CoT packets (should we only require one more?). o Only after this complete step down procedure does a mobile node heed a correspondent's preference for a weak exchange and begin the corresponding weak RR process (in which the mobile node uses its weak address) or simply by desisting on using route optimization. If at any time during the step down procedure the mobile node receives any messages which specify preference for something other than RR (a stronger exchange), the step down procedure is aborted. Montenegro & Nikander Expires October 4, 2002 [Page 12] Internet-Draft Protecting Against Bidding Down Attacks April 2002 This means that the mobile node will not engage in a weak exchange. Of course, it may also desist on using route optimization. 3.2 Bit Method The first time Bob receives a packet sent by Alice, he has no other knowledge about her but the packet itself. In particular, the only information he has about Alice is the source IP address in the packet. If Alice is a stationary node, she does not want her address to be redirectable, so Bob must not install a binding cache entry for it. To prevent would-be attackers from "redirecting" Alice's address, Bob needs to learn if her address is indeed redirectable. He has several options: 1. He can query DNS, do a reverse lookup, and hope to learn something useful. However, this may be expensive in terms of time and number of packets, causing packets sent to the DNS server that serves the reverse map for Alice's address, and thereby somewhat dangerous from the Denial-of-Service point of view. Additionally, secure DNS is not widely deployed, and therefore he usually cannot fully trust the results. 2. He can try to use some other infrastructure, such as AAA, to obtain some information about Alice. However, this method requires that Alice participates in the same infrastructure, which, in general, is unlikely for a number of years to come. Secondly, this method has the same drawbacks as DNS lookups, generating delay and extra traffic. 3. He can send a probe to Alice, checking that there indeed is somebody who answers at her address. TCP SYN ACK is basically such a probe, and so are the new Mobile IPv6 RR packets (HoTI, CoTI, HoT, CoT). The drawback of this method is that it does not say anything about Alice's address being redirectable or not (the whole point of this exercise). Notice that once Bob knows that Alice's address is redirectable, this step is an integral part of that process, which is why it is part of RR. 4. He can require that, as part of the address redirection procedure, Alice prove in a cryptographically secure manner that her address is indeed redirectable. The problem is that the only known way to do this in an infrastructureless manner raises intellectual property concerns whose implications are not clear. 5. He can have a look at the address, and try to deduce something from the address itself. Currently, he can learn whether Alice is using a link local, site local or global address, whether Alice's address is supposed to contain a globally unique Montenegro & Nikander Expires October 4, 2002 [Page 13] Internet-Draft Protecting Against Bidding Down Attacks April 2002 interface ID, etc. The whole idea of the "bit method" is to extend the last option above so that Bob can tell by looking at the address if it is redirectable or not. The "bit method" allocates a bit (or a bit pattern) in the IPv6 64 bit Interface Identifier field, with the intention of later defining a method that allows peer hosts to securely find out what security protocols, and perhaps other functional features, the host using the address supports. That is, if a host's address has the bit set, the host indicates to its peers either of the following: It does not use "redirection procedures" to influence how packets destined to itself are routed by a peer. Currently, the only such "redirection procedure" proposed for widespread deployment is the Mobile IPv6 route optimization procedure. Other similar applications of such procedures may appear in the future (for example for certain anycast implementations). In the absence of any further signaling, the peer (correspondent node) assumes this is the case. If the node does use "redirection procedures", then it only does so by using a "strong" mechamism as defined above, i.e. using further signaling and strong cryptographic mechanisms. If the bit is cleared in the host's address, it relies on the default ("weak") mechanisms. In the case of Mobile IPv6, this is the RR procedure. Note that an active attacker on the path between Alice and Bob is able to clear a set bit. However, that changes the address, and Alice is not going to answer to any possible replies sent by Bob. Thus, the bit prevents the attacker from impersonating as Alice and fooling Bob to use the less secure protocol. If the bit is set, the correspondent host MUST require a cryptographic assurance before heeding any redirects for the address in question. Failure to do so means the correspondent host MUST NOT heed any redirects. This eliminates any potential misuse of Return Routability to attack a given address, and prevents the correspondent node from being bid down. Montenegro & Nikander Expires October 4, 2002 [Page 14] Internet-Draft Protecting Against Bidding Down Attacks April 2002 4. Security Considerations This note deals almost exclusively with security issues. The issue at hand is that the baseline Mobile IPv6 route optimization mechanism, RR, may "pollute" the Internet at large with some additional threats. These affect all hosts (not just mobile hosts). Any protection must be mandated as part of the baseline RR mechanism. We discuss the "bit method" in which a bit or bit pattern in the address prevents the use of RR to attack stationary hosts. Coupled with the "step down" procedure, it alleviates the attack against mobile nodes that implement route optimization mechanisms stronger than RR. Unlike the latter which relies on trust in the routing infrastructure in order to authorize binding updates, the "strong" mechanisms all employ cryptographic assurances of some sort or other. This document does not discuss the "bidding aside" attacks, in which an attacker forces the use of a "strong" mechanism instead of another also "strong" mechamism. Presumably, it would do so because not all such mechanisms are equally strong, so by choosing judiciously, an attacker can lower the bar. Nevertheless, this bar is sufficiently much higher than the RR level, since it requires carrying out successful cryptographic attacks. If an attacker is able to do this, it can basically attack the Internet at will. Furthermore, careful review before approving any future optional "strong" mechamisms can assure that the bar remains high enough. Montenegro & Nikander Expires October 4, 2002 [Page 15] Internet-Draft Protecting Against Bidding Down Attacks April 2002 5. Acknowledgements This document "borrows" extensively from Mobile IPv6 security Design Team write-ups [1] and discussions. Accordingly, it owes much to the other members (besides the authors) of the design team, Jari Arkko and Erik Nordmark. It also benefits from discussion on the Mobile IP and IPv6 mailing lists. Brian Carpenter's observations in the latter led to the the step down procedure. Montenegro & Nikander Expires October 4, 2002 [Page 16] Internet-Draft Protecting Against Bidding Down Attacks April 2002 References [1] Arkko, J., Nordmark, E., Nikander, P. and G. Montenegro, "Mobile IPv6 Security Design Team Writeups", see http://www.piuha.net/ ~jarkko/publications/mipv6/, April 2002. [2] Perkins, C. and D. Johnson, "Mobility Support in IPv6", Internet-Draft http://www.ietf.org/internet-drafts/draft-ietf- mobileip-ipv6-16, March 2002. [3] Arkko, j. and T. Aura, "MIPv6 BU Attacks and Defenses", draft- aura-mipv6-bu-attacks-01 (work in progress), March 2002. [4] Devarapalli, V., "Future Attacks and Threats", Thread on the Mobile IP alias http://playground.sun.com/mobile-ip/WG-archive/ frm04733.html, January 2002. [5] Kempf, J. and E. Nordmark, "Threat Analysis for IPv6 Public Multi-Access Links", draft-kempf-ipng-netaccess-threats-00 (work in progress), November 2001. [6] Roe, M., Aura, T., O'Shea, G. and J. Arkko, "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", draft-roe- mobileip-updateauth-02.txt (work in progress), February 2002. [7] Montenegro, G. and C. Castelluccia, "Statistically Unique and Cryptographically Verifiable (SUCV) Identifiers and Addresses.", NDSS 2002, February 2002. Authors' Addresses Gabriel Montenegro Sun Labs, Europe 29, chemin du Vieux Chene 38240 Meylan France EMail: gab@sun.com Pekka Nikander Ericsson Research NomadicLab Espoo Finland EMail: Pekka.Nikander@nomadiclab.com Montenegro & Nikander Expires October 4, 2002 [Page 17] Internet-Draft Protecting Against Bidding Down Attacks April 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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 assigns. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Montenegro & Nikander Expires October 4, 2002 [Page 18]