Network Working Group W. Haddad Internet-Draft S. Krishnan Expires: December 21, 2006 Ericsson Research F. Dupont CELAR June 19, 2006 Mobility Signaling Delegation in OptiSEND draft-haddad-mipshop-mobisig-del-00 Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo describes a mechanism, which delegates the exchange of mobility signaling messages between the mobile node and the correspondent node(s) to the network infrastructure. Goals outlining the proposed delegation are to further reduce the IP handoff latency and to relieve the mobile node from exchanging a considerable amount of signaling messages with the CN(s) while retaining full control on Haddad, et al. Expires December 21, 2006 [Page 1] Internet-Draft Mobility Signaling Delegation June 2006 the critical ones. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Suggested Solution . . . . . . . . . . . . . . . . . . . . . . 7 5. New Options and Messages . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Haddad, et al. Expires December 21, 2006 [Page 2] Internet-Draft Mobility Signaling Delegation June 2006 1. Introduction Optimized Mobile IPv6 (OMIPv6) protocol (described in [OMIPv6]) provides a mechanism, which allows significant reduction in the amount of signaling messages generated by the Mobile IPv6 (MIPv6) protocol ([MIPv6]), a shorter handoff latency and a better overall security. However, a care-of address (CoA) test exchange between the mobile node (MN) and each correspondent node (CN) remains a compulsory step prior to exchanging critical mobility signaling messages, namely binding update(s) and acknowledgment(s) messages between them. The CoA reachability test involves two mobility signaling messages (CoTI/CoT) and is unaffected by the optimization introduced by OMIPv6 protocol. This memo describes a mechanism, which delegates the exchange of mobility signaling messages between the MN and the CN(s) to the network infrastructure, as part of the ongoing work to design an optimization to the IPv6 secure neighbor discovery (described in [SEND]) protocol. Goals outlining the proposed delegation are to further reduce the IP handoff latency and to relieve the MN from exchanging a considerable amount of signaling messages with each CN while retaining full control on the BU/BA messages. Haddad, et al. Expires December 21, 2006 [Page 3] Internet-Draft Mobility Signaling Delegation June 2006 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [TERM]. Haddad, et al. Expires December 21, 2006 [Page 4] Internet-Draft Mobility Signaling Delegation June 2006 3. Motivation OMIPv6 protocol achieves three different goals: it alleviates the load of mobility signaling messages, improves the overall security and reduces the IP handoff latency. The latency reduction caused by OMIPv6 protocol is mainly due to eliminating the MN's home IPv6 address reachability test, which requires signaling messages exchange through the MN's Home Agent. Another set of factors (excluding the link layer), e.g., network detection, network prefix discovery and address configuration are still among main contributors to the handoff latency. These factors remain totally unaffected by using OMIPv6. In addition, OMIPv6 still require a CoA reachability test with each CN prior to updating them with its new CoA (nCoA), i.e., exchanging BU/BA messages. Consequently, such exchange guarantees a residual latency and additional mobility signaling messages. Furthermore, it is important to mention that a fast growing class of mobile devices tend to have very limited battery power. Thus the available energy must be meticulously controlled and consumed, i.e., not to be wasted on exchanging non-critical signaling messages. Such statement becomes more challenging when the MN is talking to different CNs at the same time (which may probably be a very common case) while moving fast. In fact, it has been shown that the wireless transmission of one bit can require over 1000 times more energy than a single 32-bit computation [EALDC]. Consequently, a fast moving MN communicating with multiple CNs will have to dedicate a significant amount of its available energy to exchange only mobility signaling messages with the CNs. OMIPv6 provides a credit-based mechanism (described in [CBA]), which aims to reduce further the latency caused by the care-of address test exchange. However, such mechanism has two drawbacks: the CN may not have this feature, in which case the latency problem remains unsolved and it consumes battery power in both scenarios. Note that the suggested protocol does not prevent both endpoints from using the CBA mechanism on top of the suggested protocol. On the other side, the Optimized Secure Neighbor Discovery (OptiSEND) protocol (described in [OptiSEND]) is an ongoing work, which aims to better adapt the requirements for securing the IPv6 neighbor discovery to low computation and battery power devices (e.g., mobile devices and sensors). OptiSEND enables fixed/mobile nodes to avoid using expensive RSA signatures to secure neighbor discovery messages exchange, by providing a mechanism to quickly share a long lifetime Haddad, et al. Expires December 21, 2006 [Page 5] Internet-Draft Mobility Signaling Delegation June 2006 symmetric key with the AR(s). On the infrastructure side, OptiSEND enables ARs to use one-way hash chains to authenticate the Router Advertisement (RtAdv) messages sent to the fixed/mobile node(s) attached to the same link. Haddad, et al. Expires December 21, 2006 [Page 6] Internet-Draft Mobility Signaling Delegation June 2006 4. Suggested Solution Our proposal delegates the task of performing CoA reachability test(s) to the network infrastructure, which in turn enables to eliminate the residual latency due to the CoA rechability test, ensures that the messages exchanged are authenticated and optimize the battery power consumption by relieving the MN from performing CoA reachability test(s). In fact, our protocol adopts another approach to perform reachability tests, which consists on testing the reachability of the new MN's 64-bit subnet prefix only instead of testing the reachability of the whole nCoA, and relies on two new messages to perform such test. For these purposes, the MN must securely send to the access network infrastructure necessary information called mobility package to enable performing the CoA reachability test(s) on its behalf and also to forward the mobility package to potential new ARs. To achieve this goal, a new message called router mobility solicitation (RtMobSol) is used by the MN to send its mobility package to its current AR(s). The RtMobSol message MUST carry the CNs'IPv6 addresses and the MN's IPv6 home address (HoA) and MUST be authenticated with the shared key obtained from OptiSEND. Upon receiving a valid RtMobSol message, the selected AR replies with a unicast and authenticated router mobility acknowledgment (RtMobAck) message. The content of the RtMobSol message SHOULD be forwarded to neighboring ARs and should be stored together with data obtained from running OptiSEND protocol. The RtMobSol message is also used by the MN to add or delete entries from a mobility package stored in the AR cache memory. For example, when the MN establishes a session with a new CN, it SHOULD send a RtMobSol message to its current AR and SHOULD set a new bit (called Address "A" bit) to request the AR to forward the new CN's IPv6 address to potential new AR(s). The MN MAY also set another bit (called Suppress "S" bit) to request the AR(s) to remove an existing CN's IPv6 address from its list. In order to eliminate the residual latency due to performing the CoA reachability test, the nAR SHOULD perform the test immediately after receiving a first hint (e.g., on layer 2) indicating an attachment of the MN (e.g., when using [FRD]) and SHOULD forward the message(s) sent by the CN(s) to the MN after it attaches to the nAR. For this purpose, the nAR SHOULD use a source address, which includes the prefix advertised by the nAR on the link and MUST authenticate the message with Kms. We call such message Prefix Test Init (PreTI). In addition, the PreTI message MUST carry the MN's HoA to allow the CN to fetch the corresponding Kms from its correspondent BCE in order to validate the message authentication. Upon receiving a valid PreTI message, the CN computes a prefix keygen Haddad, et al. Expires December 21, 2006 [Page 7] Internet-Draft Mobility Signaling Delegation June 2006 (prekey) token from the prefix used in the IPv6 source address and the long lifetime shared secret (i.e., kbmperm) generated from using OMIPv6 protocol. After computing the token, the CN SHOULD send back an acknowledgment message called Prefix Test (PreT), which will carry the prekey token to the same IPv6 source address carried in the PreTI message. The PreT message MUST also carry the MN's HoA and MUST be authenticated with Kms. The Prekey token MUST be computed by the CN in the following way: Prekey Token = First (64, SHA1(SA_Prefix | nonce | SHA1(Kbmperm)) Where SA_Prefix is the 64-bit prefix carried by the IPv6 source address sent in the PreTI message and Kbmperm is the long lifetime shared secret generated by the CN when running OMIPv6 protocol. As mentioned above, the prefix reachability test SHOULD be authenticated. In order to do so, the hash of the symmetric key generated from running OptiSEND protocol SHOULD be used. In the following, we call such key mobility signaling key (Kms) and we suppose that the MN sends Kms to each CN in the first BU message. However, Kms MUST be sent encrypted to each CN. For this purpose, the MN SHOULD use the Kbm generated during the first (and only) return routability test performed in OMIPv6 (i.e., until the expiration of the shared secret) to encrypt Kms. Finally, Kms will be carried in a new option called signaling delegation (SID). Upon receiving a BU message carrying a SID option, the CN SHOULD decrypt the Kms and store it in the MN's BCE. All subsequent reachability test messages SHOULD be sent by the MN's current AR on behalf of the MN and SHOULD be authenticated with Kms. Haddad, et al. Expires December 21, 2006 [Page 8] Internet-Draft Mobility Signaling Delegation June 2006 5. New Options and Messages TBD Haddad, et al. Expires December 21, 2006 [Page 9] Internet-Draft Mobility Signaling Delegation June 2006 6. Security Considerations This draft proposes a scheme to delegate mobility signalling from the mobile node to the network infrastructure. Since the network infrastructure nodes are well known and trustworthy, it makes firewalling easier at the administrative boundaries. Also since the network infrastructure nodes are likely to be more powerful than mobile nodes, this scheme will allow us to use higher strength crypto to protect the signaling. This draft does not introduce any new security holes into existing route optimization solutions. Haddad, et al. Expires December 21, 2006 [Page 10] Internet-Draft Mobility Signaling Delegation June 2006 7. References 7.1. Normative References [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [SEND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B., and P. Nikander, "Secure Neighbor Discovery (SEND)", RFC 3971, March 2005. [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, BCP , March 1997. 7.2. Informative References [CBA] Vogt, C. and J. Arkko, "Credit-Based Authorization for Concurrent Reachability Verification", Internet Draft, draft-vogt-mobopts-simple-cba-00.txt, February 2006. [EALDC] Barr, K. and K. Asanovic, "Energy Aware Lossless Data Compression", ACM Proceedings of MobiSys, May 2003. [FRD] Choi, J., Shin, D., and W. Haddad, "Fast Router Discovery with L2 Support", Internet Draft, draft-ietf-dna-frd-00.txt, October 2005. [OMIPv6] Vogt, C., Arkko, J., and W. Haddad, "Applying CGA and CBA to Mobile IPv6", Internet Draft, draft-arkko-mipshop-cga-cba-03.txt, March 2006. [OptiSEND] Haddad, W., Krishnan, S., and J. Choi, "Secure Neighbor Discovery (SEND) Optimization and Adapation for Mobility: The OptiSEND Protocol", Internet Draft, draft-haddad-mipshop-optisend-01.txt, March 2006. Haddad, et al. Expires December 21, 2006 [Page 11] Internet-Draft Mobility Signaling Delegation June 2006 Authors' Addresses Wassim Haddad Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm Sweden Email: Wassim.Haddad@ericsson.com Suresh Krishnan Ericsson Research 8400 Decarie Blvd. Town of Mount Royal, QC Canada Phone: +1 514 345 7900 Email: Suresk.Krishnan@ericsson.com Francis Dupont CELAR Email: Francis.Dupont@point6.net Haddad, et al. Expires December 21, 2006 [Page 12] Internet-Draft Mobility Signaling Delegation June 2006 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 (2006). 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. Haddad, et al. Expires December 21, 2006 [Page 13]