Network Working Group C. Vogt Internet-Draft Univ. of Karlsruhe, Germany Expires: August 18, 2005 February 14, 2005 Credit-Based Authorization for HIP Mobility with Concurrent IP-Address Tests draft-vogt-hip-credit-based-authorization-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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 August 18, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract End-host mobility with the Host Identity Protocol uses IP-address tests to protect against malicious packet redirection and third-party flooding. The tests cause handover signaling delays to increase by one round-trip time. This document proposes a credit-based strategy that allows peers to securely resume active communications after handover as soon as possible, and to pursue a concurrent IP-address Vogt Expires August 18, 2005 [Page 1] Internet-Draft Credit-Based Authorization February 2005 test subsequently. The optimization thus eliminates the additional handover delay that IP-address tests entail. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Redirection-Based Flooding . . . . . . . . . . . . . . . . . . 3 3. Review of HIP Mobility . . . . . . . . . . . . . . . . . . . . 5 4. Credit-Based Authorization . . . . . . . . . . . . . . . . . . 7 5. Applying CBA . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1 Normative References . . . . . . . . . . . . . . . . . . . 10 8.2 Informational References . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 13 Vogt Expires August 18, 2005 [Page 2] Internet-Draft Credit-Based Authorization February 2005 1. Introduction End-host mobility [3] with the Host Identity Protocol (HIP) [1] allows a mobile node to change its point of IP attachment without loosing active communications connections. Peers mutually authenticate themselves through their cryptographic identifiers. Unfortunately, mobility introduces the possibility for a new type of amplified flooding attacks in spite of authentication: In such an attack, the perpetrator, who may or may not be really mobile, claims to have moved to a new IP subnet and registers a victim's IP address as its alleged new locality. The correspondent node can so be tricked into spamming the victim with unwanted packets. Flooding attacks have been thoroughly considered in recent research [1][3][5][6][9]. In HIP, a mobile node must show that it is reachable at a new IP address which it wants to register with a peer. Specifically, it must return a probing packet with some unguessable piece of data that its peer sends to it. Yet, an adverse side effect of this IP-address test is that it increases handover latency by one round-trip time, precluding interactive or real-time applications in many scenarios. This document presents "Credit-Based Authorization" (CBA), an optimization mechanism that allows HIP nodes to securely use a new IP address while this address is being probed. CBA can reduce signaling delays by one round-trip time, which amounts to 50% of the overall latency in the case of HIP. Following this introduction, Section 2 further discusses the threat of redirection-based flooding attacks. Section 3 is a brief review of the HIP mobility protocol. Section 4 explains CBA conceptually, and Section 5 describes how CBA can be integrated with HIP mobility. Section 6 provides additional security considerations. Section 7 finally concludes this document. CBA was originally proposed for Mobile IPv6 Early Binding Updates [7][8], where it allows for secure concurrent care-of-address tests. It was first presented at the 59th IETF meeting in Seoul, Republic of Korea, in February 2004. 2. Redirection-Based Flooding This section discusses new possibilities for malicious packet redirection and third-party flooding that poorly designed mobility protocols could introduce. It relates these to similar threats in the non-mobile Internet, discusses the role of packet filtering, and outlines and evaluates the protection mechanism used in end-host mobility with HIP. Vogt Expires August 18, 2005 [Page 3] Internet-Draft Credit-Based Authorization February 2005 HIP nodes can mutually authenticate themselves by means of their cryptographic identifiers. Mutual authentication, however, does not imply any sort of trust between the nodes. As a consequence, it is often unclear from the correspondent node's perspective whether a mobile node is faithful with respect to its current locality. The mobile node might misuse such unawareness for redirecting packets, the true recipient of which it itself is, to a victim somewhere else in the Internet. Redirection-based flooding attacks are an attractive means for denial of service because of their enormous potential for amplification at relatively low cost [6]. For instance, a mobility protocol that fails to provide appropriate counter-measures would allow an attacker to setup a TCP connection through its own IP address, learn the initial sequence number this way, and subsequently redirect the connection to someone else's address. The attacker could influence the rate of misrouted TCP segments through fake acknowledgements that appear to originate from the redirection target. As the segments are typically much bigger than their acknowledgements, the correspondent node would spend, unknowingly, much more resources on the flooding attack than the attacker itself. One may argue that flooding attacks are already a major problem in the non-mobile Internet [10], and that mobility protocols such as [3] cannot do anything about them. However, it is important to understand that misuse of packet redirection could render these attacks much more accessible: Today's attackers gain amplification by compromising as many Internet nodes as possible through viral software and have them contribute to the attack this way. In contrast, a widely deployed, but improperly designed mobility protocol would allow the attacker to take advantage of the large base of co-operating nodes, making any viral assaults unnecessary. Most mobility protocols hinder registration of false IP addresses by requiring mobile nodes to put a new IP address in the Source Address field of the registration message's IP header. Filtering techniques on the mobile node's side [4] so get a chance to unveil fraudulent registration attempts. Yet, the problem with verifying IP source addresses at the fringe of the Internet is that it does not fully protect unless applied universally. It is questionable whether this will always be the case. As things stand, an attacker can always find a network where no filtering is applied, even though the technique has already been deployed in many places. Mobility protocols should hence provide independent protection against malicious packet redirection. As previously mentioned, end-host mobility with HIP requires the mobile node to receive and return some random data at a new IP address before any data packets are sent to that address. A Vogt Expires August 18, 2005 [Page 4] Internet-Draft Credit-Based Authorization February 2005 successful exchange guarantees that the mobile node either owns the new IP address, or is at least on the path towards it. In either case, any packets sent to the address are routed to, or via, the mobile node. The rationale for considering this evidential that no flooding attack is in the making is that an attacker in such a position would not depend on redirection: It could wage a flooding attack more easily by setting up, say, a TCP connection directly on behalf of its victim. 3. Review of HIP Mobility This section is a brief outline of the HIP base protocol and its extension for mobility support. The protocol details can be found in [2] and [3]. HIP uses a node's DSA or RSA public key, rather than an IP address, as a "Host Identifier" (HI) at stack layers above IP. A HI is hashed into a 128-bit "Host Identity Tag" (HIT) to have it be syntactically compatible with an IPv6 address. Peers swap their HITs and actual IP addresses within a shim layer between the IP stack and upper layers. The advantage of a HI over an IP address is that the owner can *cryptographically* prove to a peer that its identifier is correct through being able to sign or decrypt messages with the corresponding private key. HIP uses this feature to authenticate a Diffie-Hellman key exchange for IPsec ESP protection of both signaling and data packets. Mobile Node Correspondent Node | | |-I1--------------------------->| Select puzzle | | Solve puzzle |<---------------------------R1-| Compute D-H | | |-I2--------------------------->| Check puzzle | | Compute D-H |<---------------------------R2-| | | Figure 1: HIP Base Exchange Contact establishment is shown in Figure 1. Either one of the peers, the initiator, starts a "HIP base exchange" by sending the other, the responder, an I1 message. This prompts the responder to send its HI Vogt Expires August 18, 2005 [Page 5] Internet-Draft Credit-Based Authorization February 2005 and a public Diffie-Hellman key to the initiator in the R1 message. The initiator, in turn, provides its HI and a public Diffie-Hellman key in the I2 message. Based on their own private and the other's public Diffie-Hellman keys, both peers compute secret shared keying material from which authentication and encryption keys are taken. Finally, the R2 message serves to activate IPsec ESP processing on both sides. The R1, I2, and R2 messages are signed with the HIs. This makes the base exchange robust to man-in-the-middle attacks. Since a Diffie-Hellman key exchange includes heavy cryptographic computations, it can potentially be misused for a resource-exhaustion attack against the responder. In such an attack, the perpetrator uses any random number as its public Diffie-Hellman key and makes the responder compute keying material from it. The perpetrator may repeat the attack with different falsified IP source addresses and bogus HIs. (HI verification is equivalent to Diffie-Hellman key generation in terms of computational complexity.) Resource-exhaustion attacks can be averted by requiring the initiator to invest some reasonable effort before the responder does so. To this end, the R1 message contains a random number X, a "puzzle", which the initiator has to concatenate with both peers' HITs and with a number Y such that the hash on the concatenation yields a string with a certain minimum of trailing zeros. The R1 message, including its signature, can be pre-computed and reused across multiple base exchanges. The appealing property of a puzzle is that the complexity of solving it grows exponentially with the required count of trailing zeros, whereas a potential solution can be validated very efficiently. Mobile nodes can change their IP addresses without running the base exchange again. They may derive new keys at any time, but usually retain their existing ones across multiple handovers. When the mobile node moves to a different IP subnet, it configures a new IP address and signals it to its peer through an Update message carrying a Readdress parameter (UPD[REA]). The UPD[REA] holds the corresponding IPsec Security Parameter Index, the new IP address, and some auxiliary data. The IPsec ESP context, within which all signaling takes place, ensures the authenticity of this UPD[REA]. Figure 2 illustrates the registration procedure. Vogt Expires August 18, 2005 [Page 6] Internet-Draft Credit-Based Authorization February 2005 Mobile Node Correspondent Node | | Handover ~ | Use new address |-UPD[REA]--------------------->| | | |<----------------UPD[ECHO_REQ]-| | | |-UPD[ECHO_RESP]--------------->| Use new address | | Figure 2: HIP Address Registration A node may register multiple IP addresses with its peer and declare one of them "preferred". IP-address verification is mandatory only in case the preferred address changes to an address that has not yet been actively used. To verify a mobile node's reachability at a new preferred address, the peer sends an Update message including an Echo Request parameter (UPD[ECHO_REQ]). The UPD[ECHO_REQ] includes a random number, which the mobile node must return in an Update message with an Echo Response parameter (UPD[ECHO_RESP]). 4. Credit-Based Authorization The HIP mobility extension requires verification of a mobile node's reachability at a new IP address *before* data packets are sent to that address. This inhibits direct use of the new IP address as soon as it becomes available. At the same time, as previously explained, the severity of redirection-based flooding attacks over conventional flooding attacks not so much emanates from packet redirection per se, but rather from the enormous potential for flooding amplification. If no amplification could be gained through redirection, it would just be easier for an attacker to bombard its victim directly. As a consequence, introducing a mechanism that prevents this amplification would affort reasonably secure, *immediate* use of a new IP address subsequent to handover. Such is the approach followed by CBA. CBA allows a peer to probe a mobile node's reachability at a new IP address while the address is already in active use. This conforms with the UNVERIFIED and ACTIVE address states that [3] defines: The new IP address is UNVERIFIED until the correspondent node knows the result of the reachability test, and it is ACTIVE thereafter. The idea of CBA is to restrict the maximum data volume and rate that a peer can send to an UNVERIFIED IP address to the data volume and rate that the mobile node has sent the other way in the recent past. For Vogt Expires August 18, 2005 [Page 7] Internet-Draft Credit-Based Authorization February 2005 this, the mobile node has a credit account at the peer. The account fills up as the mobile node sends packets to the peer. Subsequent to handover, while the new IP address is UNVERIFIED, packets sent to this address consume the credit. Packets continue to be sent there as long as sufficient credit is left. The balance of a mobile node's credit account increases and decreases proportionally to the size of the received and sent packets. This guarantees that the data volume sent to an UNVERIFIED IP address cannot be greater than the previously received data volume. In addition, unused credit withers over time through exponential aging. This helps to bound the rate at which data can be sent to an UNVERIFIED IP address by the rate at which data was previously received. Up to this point, the mobile node earns credit for sending packets, while it needs the credit for receiving them. This works well when traffic patterns are for the most part symmetric, as it is in the case of Internet telephony. On the other hand, asymmetric traffic patterns are also very common. File transfers and media streaming, for instance, feature high throughput towards the client, typically the mobile node, and comparably little throughput towards the serving peer. To prevent a mobile node from running out of credit, CBA can be made a bit more sophisticated. The key observation is that the mobile node invests comparable effort for packet reception as for packet transmission, in terms of bandwidth, memory, and processing capacity. It hence stands to reason that packets received by the mobile node may be taken as the basis for credit allocation, just like the packets that the mobile node sends. The question, though, is how the peer can determine how many of the packets sent to the mobile node are actually received and processed at the other end. The mobile node may position itself behind a low-bandwidth link and deliberately collect more credit than appropriate. It may also fake transport-protocol acknowledgements as previously explained. To overcome the issue, the peer needs some feedback on packet-loss conditions along the path towards the mobile node. Such feedback can optionally be provided through "IP-Address Spot Checks". Here, the peer periodically tags packets that it sends to the mobile node with a random, unguessable token. When the mobile node receives the packet, it stores it in a cache until a local application delivers the next packet for the peer. The mobile node includes all cached tokens in this packet and sends it. The peer keeps an eye on how many of the tokens that it sent the mobile node correctly returns. New credit is allocated proportionally. The preciseness of IP-Address Spot Checks can be traded with overhead through the frequency with which they are exercised. Vogt Expires August 18, 2005 [Page 8] 5. Applying CBA Applying CBA to end-host mobility with HIP is straightforward. The peer switches to the new, UNVERIFIED IP address when it receives the UPD[REA], and changes the address status to ACTIVE upon reception of the UPD[ECHO_RESP]. Figure 3 illustrates this procedure. Mobile Node Correspondent Node | | Handover ~ | Use new address |-UPD[REA]--------------------->| Use UNVERIFIED | | address |<----------------UPD[ECHO_REQ]-| | | |-UPD[ECHO_RESP]--------------->| Address ACTIVE | | Figure 3: HIP Address Registration with CBA 6. Security Considerations The HIP mobility extension requires cryptographic authentication before packets can be redirected to a new IP address. This prevents unauthorized nodes from interfering with other nodes' communications connections. It is hence a common understanding that the only conceivable purpose of malicious packet redirection is third-party flooding. There are plenty of tactics for non-amplified flooding in the current, non-mobile Internet. In its simplest form, an attacker can directly spam a victim with unwanted packets. Another possibility is TCP-SYN flooding. Most of these tactics require less coordinative effort than a redirection-based flooding attack. It hence stands to reason that an attacker will use a redirection-based flooding attack only if it can expect a gain in terms of amplification. CBA precludes amplification and should therefore sufficiently discourage redirection-based flooding attacks. However, it is important to recognize that CBA does not prevent packet redirection per se. Heuristics for misuse detection have been considered as a possible Vogt Expires August 18, 2005 [Page 9] Internet-Draft Credit-Based Authorization February 2005 alternative to CBA. If responsive enough, they can prevent, or at least effectually discourage, malicious packet redirection. The challenge here seems to be a good trade-off: On one hand, the heuristic must be sufficiently rigid to stop an attacker early on. On the other hand, it should not adversely affect communications with faithful mobile nodes. 7. Conclusions Mobility protocols may introduce a new type of flooding attacks if designed without sufficient precautions. Compared to existing flooding techniques, such redirection-based flooding attacks can yield unprecedented amplification at negligible investments from the attacker's side, jeopardizing not only nodes that participate in the mobility protocol, but the Internet at a whole. This document explains the new threat of malicious packet redirection, clarifies why existing security techniques fail to provide full protection, and infers that it is up to the mobility protocols themselves to protect against it. The document evaluates the standard security mechanism adopted in end-host mobility with HIP, namely, to probe a new IP address before any data packets are sent there. As it becomes evident that this simple approach adversely affects handover latency, a credit-based strategy, Credit-Based Authorization, is proposed for secure concurrent probing. Finally, the document explains how Credit-Based Authorization can be integrated into mobility with HIP, where it can reduce handover-signaling delays by 50%. 8. References 8.1 Normative References [1] Moskowitz, R. and P. Nikander, "Host Identity Protocol Architecture", Internet-Draft draft-ietf-hip-arch (work in progress). [2] Moskowitz, R., Nikander, P., Jokela, P. and T. Henderson, "Host Identity Protocol", Internet-Draft draft-ietf-hip-base (work in progress). [3] Nikander, P., Arkko, J. and T. Henderson, "End-Host Mobility and Multi-Homing with Host Identity Protocol", Internet-Draft draft-ietf-hip-mm (work in progress). Vogt Expires August 18, 2005 [Page 10] Internet-Draft Credit-Based Authorization February 2005 8.2 Informational References [4] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2827, May 2000. [5] Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E. Nordmark, "Mobile IP version 6 Route Optimization Security Design Background", Internet-Draft draft-ietf-mip6-ro-sec (work in progress). [6] Roe, M., Aura, T., O'Shea, G. and J. Arkko, "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", Internet-Draft draft-roe-mobileip-updateauth (work in progress). [7] Vogt, C. and J. Arkko, "Credit-Based Authorization for Mobile IPv6 Early Binding Updates", Internet-Draft draft-vogt-mobopts-credit-based-authorization (work in progress). [8] Vogt, C., "Early Binding Updates for Mobile IPv6", Internet-Draft draft-vogt-mobopts-early-binding-updates (work in progress). [9] Aura, T., Roe, M. and J. Arkko, "Security of Internet Location Management", Proceedings of the Computer Security Applications Conference, December 2002. [10] Paxson, V., "An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks", ACM SIGCOMM Computer Communication Review, volume 31, number 3, July 2001. Author's Address Christian Vogt Institute of Telematics University of Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany Email: chvogt@tm.uka.de URI: http://www.tm.uka.de/~chvogt/ Vogt Expires August 18, 2005 [Page 11] Internet-Draft Credit-Based Authorization February 2005 Appendix A. Acknowledgements For their valuable feedback and advice with respect to the work presented in this paper the author wishes to thank Jari Arkko, Roland Bless, Mark Doll, Lars Eggert, Tobias Kuefner, Marco Liebsch, Pekka Nikander, and Lars Voelker. Vogt Expires August 18, 2005 [Page 12] Internet-Draft Credit-Based Authorization February 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Vogt Expires August 18, 2005 [Page 13]