Mobility Extensions for IPv6 W. Haddad (Mext) Ericsson Internet-Draft March 13, 2011 Intended status: Standards Track Expires: September 14, 2011 Enhancing Mobile IPv6 Route Optimization Mode with Secure Social Dimension draft-haddad-mext-mobisoc-04 Abstract This memo introduces the concept of peer-to-peer route optimization mode which enables Mobile IPv6 route optimization, without requiring mobility signaling messages exchange between two mobile endpoints. For this purpose, we use a social dimension within the home network as one tool to implement our concept. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 14, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Haddad Expires September 14, 2011 [Page 1] Internet-Draft MIPv6 RO Mode Optimization March 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Motivation and Goal . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6 5. New Options, Bits and Messages Formats . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Haddad Expires September 14, 2011 [Page 2] Internet-Draft MIPv6 RO Mode Optimization March 2011 1. Introduction This memo introduces the concept of "peer-to-peer (P2P)" route optimization (RO) mode which enables Mobile IPv6 ([I-D.ietf-mext-rfc3775bis]) route optimization, without requiring mobility signaling messages exchange between two mobile endpoints. For this purpose, we use a social dimension within the home network as one tool (among others), to implement our concept. By limiting the scope to the home network, our suggested proposal can be applied only to mobile nodes using the same HA (or cluster of HAs). In this context, our tool enables two mobile endpoints which know each other "fairly" well (e.g., a la Facebook) to trigger the RO mode without exchanging any mobility signaling messages on the direct path. Haddad Expires September 14, 2011 [Page 3] Internet-Draft MIPv6 RO Mode Optimization March 2011 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 [RFC2119]. Haddad Expires September 14, 2011 [Page 4] Internet-Draft MIPv6 RO Mode Optimization March 2011 3. Motivation and Goal It is important to start this section by highlighting an important observation related to the selected tool. In fact, neither the selected tool nor any other tool may be needed in order to implement P2P RO mode (i.e., case where the decision to switch or not to the RO mode is made only by the common HA). In fact, using the social variable provides a clear description of how P2P RO mode could work in general. Our tool selection is motivated by the stunning growth of social networking especially now that is becoming a desirable component and enabler for successful and attractive technologies. It is also well known that the RO mode enables a more efficient data packets exchange than the bidirectional tunneling and thus, should be applied whenever possible unless the mobile node (MN) is not interested in disclosing its topological location, i.e., care-of address (CoA), for the correspondent node (CN), e.g., for privacy reasons. However, MIPv6 RO mode requires exchanging a significant amount of mobility signaling messages in order to establish, and periodically refresh a bidirectional security association (BSA) between the MN and the CN. While the mobility signaling exchange severely impacts the handoff latency, the BSA is needed to authenticate two particular messages only, namely the binding update (BU) and binding acknowledgement (BA) messages (although it can be argued that sending a BA is not mandatory). Note also that the amount of mobility signaling messages further increases when the CN is also mobile. Our goal is to enable RO mode between two mobile endpoints at minimum or no cost. This means that two mobile nodes should be able under some specific circumstances, e.g., if they both explicitly ask for it, to switch from BT mode to RO mode without exchanging additional mobility signaling messages on the direct path nor through their HA. The immediate results are a much lower handoff latency to apply RO mode and the absence of BSA. Haddad Expires September 14, 2011 [Page 5] Internet-Draft MIPv6 RO Mode Optimization March 2011 4. Protocol Description Our proposal enables two mobile users who are mutual friends, e.g., two "buddies", to translate their friendship at a network and device levels into a "bidirectional cryptographic relationship (BCR)". At some particular point, e.g., before or during an ongoing session, the two "buddies" confidentially disclose their BCR to their HA, in order to request implementing a fast "zero signaling message" RO mode. An important observation is to mention that expressing mutual friendship is by no means limited to establishing BCR between two or more "buddies". In this proposal, we use crypto-relationship only as an example to demonstrate how social networking can be used in order to optimize dual mobility. To better clarify our ideas, we consider in the following, two mobile "buddies" using each its mobile device, i.e., MN1 and MN2. Our proposal requires the mobile nodes to use "cryptographically generated address (CGA)" technique (described in [RFC3972]), in order to compute and auto-configure their IPv6 home addresses. Note that using CGA in our context can also serve for authentication purposes between the MN and its HA, as described in [I-D.laganier-mext-cga]. We also assume that the two mobile devices have already established a bidirectional cryptographic relationship. For this purpose, the "Secure Neighbor Discovery" protocol ([RFC3971]) can be used. Appendix 1 describes how the BCR can be computed between the two mobile devices and the parameters sent by each MN to the HA, in order to disclose the BCR. It should be noted that the established BCR MUST be disclosed to the HA either before or during an ongoing session between the two mobile devices. In the following, we consider that the BCR is disclosed when MIPv6 handoff signaling is exchanged between each MN and its HA. Let's consider that MN1 is the first to move to a foreign network. After configuring its CoA, MN1 sends a BU message to its HA. An explicit request to enabling P2P RO mode between the two mobile endpoints requires MN1 to disclose its BCR with MN2 to the HA. For this purpose, MN1 inserts BCR parameters related to MN2 in new options carried by the BU message. These parameters are then stored by the HA and a BA message is sent to MN1. No further action is required at this stage until MN2 moves to a foreign network. When MN2 attaches to a foreign network, it exlicitly requests from its HA a P2P RO mode service with MN1. This is done exactly in the same way as with MN1's request, i.e., by sending BCR parameters related to MN1 in the BU message sent to the HA. At this stage, the HA has all necessary BCR parameters to validate and act upon. Assuming that the claimed BCR between the two mobile nodes is valid, Haddad Expires September 14, 2011 [Page 6] Internet-Draft MIPv6 RO Mode Optimization March 2011 the HA proceeds in two directions simultaneously. In the first one, it sends back a BA message to MN2 in which it inserts MN1's CoA (and potentially a selected list of flows that should be moved to the direct path). In another direction, the HA sends a new signaling message ("Neighbor Binding Update (NBU)") to MN1. NBU message carries MN2's new CoA (and the same list of flows which has been sent to MN2 in the BA message). After validating the NBU message, MN1 MUST send back a new message ("Neighbor Binding Acknowledgement (NBA)") to the HA. It becomes clear at this stage that both NBU and NBA messages will be authenticated using the same security mechanisms already in place between MN1 and its HA. This means that both messages are injected in the same IPsec tunnel established between the two nodes. Consequently, no additional security mechanism between the MN and its HA is required at any stage. The inclusion of MN1's CoA in the BA message together with sending an NBU message to MN1 allow both mobile nodes to quickly learn each other's current topological location from a "trusted" source, and to create the necessary binding in order to immediately redirect their data packets on the direct path. As previously highlighted, such redirection does not require exchanging direct mobility signaling messages between the two MNs prior to exchanging data packets on the direct path. Hence, the return routability (RR) procedure is not needed anymore. Note that in order to increase the overall performance, the HA can send multiple consecutive copies of the NBU messages until it receives a valid NBA message. Subsequent BU messages sent to the HA and carrying new CoAs are processed in the same way as the first one as long as the selected flows (i.e., the one(s) that were moved to the direct path) are still active. This means that the HA should always simultaneously update the buddy node while acknowledging the BU message. The suggested proposal can be extended to include multiple mobile nodes in which case the neighbor update(s) would consist of sending one or multiple NBU messages to the designated "buddies" nodes located outside the home network. Haddad Expires September 14, 2011 [Page 7] Internet-Draft MIPv6 RO Mode Optimization March 2011 5. New Options, Bits and Messages Formats TBD Haddad Expires September 14, 2011 [Page 8] Internet-Draft MIPv6 RO Mode Optimization March 2011 6. Security Considerations This proposal aims to enhance the RO mode efficiency by removing the need for the return routability procedure. It should be noted that the RR procedure was carefully designed in order to mitigate a significant number of threats. Its main drawback was the amount of signaling messages which was needed between the MN and the CN. By removing the need for the RR procedure, these threats are also eliminated which in turn would significantly increase the overall security. In MIPv6 protocol, there is one mandatory secure path between the MN and its HA and one trusted node, i.e., the HA. Our suggested mechanism introduces two new signaling messages which are exchanged between the MN and its HA over the secure path. Consequently, these two messages do not introduce any new threats as they are exchanged within the IPsec ESP tunnel established between the MN and its HA. In addition to the encryption and integrity protection set up between the MN and the HA, there is also a mutual trust between the two nodes which provides insurance about the validity of the new messages content. However, the mutual trust between the MN and the HA does not propagate among mobile nodes sharing the same HA. Haddad Expires September 14, 2011 [Page 9] Internet-Draft MIPv6 RO Mode Optimization March 2011 7. References 7.1. Normative References [I-D.ietf-mext-rfc3775bis] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", draft-ietf-mext-rfc3775bis-13 (work in progress), March 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. 7.2. Informative References [I-D.laganier-mext-cga] Laganier, J., "Authorizing Mobile IPv6 Binding Update with Cryptographically Generated Addresses", draft-laganier-mext-cga-01 (work in progress), October 2010. Haddad Expires September 14, 2011 [Page 10] Internet-Draft MIPv6 RO Mode Optimization March 2011 Appendix A. The required BCR between the two mobile nodes is used as a proof of mutual friendship. For this purpose, each unidirectional crypto- relationship can be generated as it follows: When MN2 establishes a unidirectional crypto-relationship with MN1, it generates a 128-bit modifier from hashing MN1's public key together with a 128-bit random number (RAN): Modifier = First [128, SHA-2(PK(MN1) | RAN) ] MN2 confidentially notifies MN1 about the RAN used to generate its CGA address and MN1 stores the RAN together with MN2's CGA address. The same procedure is repeated by MN1 in order to compute its unidirectional relationship with MN2. Each MN can confidentially share its own part of the BCR with its HA whenever needed (e.g., in order to request a P2P RO mode service). For this purpose, the "proof of friendship" is inserted in the first BU message sent by MN1 to its HA. Such proof consists of MN2's IPv6 address, public key and RAN. After CGA validation, the HA stores the crypto-relationship in the binding cache entry (BCE) created for MN1. As already mentioned, when MN2 moves to a foreign network, it discloses its own crypto-relationship with MN1. At this stage, the HA can validate the BCR and take appropriate actions. Haddad Expires September 14, 2011 [Page 11] Internet-Draft MIPv6 RO Mode Optimization March 2011 Author's Address Wassim Michel Haddad Ericsson 300 Holger Dr San Jose, CA 95134 US Phone: +1 646 256 2030 Email: Wassim.Haddad@ericsson.com Haddad Expires September 14, 2011 [Page 12]