Mobility Extensions for IPv6 W. Haddad (Mext) Ericsson Internet-Draft July 13, 2009 Intended status: Standards Track Expires: January 14, 2010 Enhancing Mobile IPv6 Route Optimization Mode with Secure Social Dimension draft-haddad-mext-mobisoc-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 January 14, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Haddad Expires January 14, 2010 [Page 1] Internet-Draft MIPv6 RO Mode Optimization July 2009 Abstract This memo describes an enhancement to Mobile IPv6 route optimization mode which is derived from introducing a social dimension within the home network. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Motivation and Goal . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6 5. Dual Mobility With Different Home Networks . . . . . . . . . . 8 6. New Options, Bits and Messages Formats . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Haddad Expires January 14, 2010 [Page 2] Internet-Draft MIPv6 RO Mode Optimization July 2009 1. Introduction We suggest an enhancement to Mobile IPv6 protocol ([I-D.ietf-mext-rfc3775bis]) based on introducing a social dimension within the home network. Consequently, our mechansim is currently limited to mobile nodes using the same HA (or cluster of HAs). The proposed enhancement enables two mobile nodes which know each other "fairly well" to "switch on" the RO mode without the need for any mobility signaling messages. Haddad Expires January 14, 2010 [Page 3] Internet-Draft MIPv6 RO Mode Optimization July 2009 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 January 14, 2010 [Page 4] Internet-Draft MIPv6 RO Mode Optimization July 2009 3. Motivation and Goal We start by highlighting first that the stunning rapid growth of social networks is by itself a great motivation to investigate how to adapt such highly successful "trend" on current protocols which will sooner or later impact social networking 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 used whenever possible unless the mobile node is not interested in disclosing its topological location, i.e., care-of address, for the CN (e.g., for privacy reasons). However, MIPv6 RO mode requires exchanging a significant amount of signaling messages in order to establish, and periodically refresh a bidirectional security association (BSA) between the mobile node and the correspondent node (CN). While the mobility signaling exchange severely impacts the handoff latency, the BSA is needed to authenticate one particular message only, namely the binding update (it can be argued that two messages are authenticated with the BSA but we note that sending a binding acknowledgement is not mandatory). Last but not least, note that the amount of mobility signaling messages gets a boost when both endpoints are mobile. Our goal is to enable the RO mode between two mobile endpoints at minimum or no cost. This means that two mobile nodes should be able -if they both explicitly ask for it- to switch from BT mode to RO mode without any signaling message exchange (i.e., in which case, there won't be any need for establishing a BSA). Our optimization results in a much lower handoff latency when switching to the RO mode, the absence of BSA and all accompanying security concerns! While such goal may not be attainable in all situation, we limit our scope in this version to the case of two mobile nodes sharing the same HA or cluster of HAs. Haddad Expires January 14, 2010 [Page 5] Internet-Draft MIPv6 RO Mode Optimization July 2009 4. Protocol Description Our proposal enables two mobile nodes which have established mutual social bonds, e.g., two "buddies", to translate such relationship into a bidirectional 'symbiotic' relationship on a network and cryptographic levels. At some particular point, the two "buddies" will confidentially disclose their 'symbiotic' relationship to their home agent, in order to request implementing a "zero signaling message" RO mode. To clarify our ideas, we consider in the following a pair of mobile nodes, MN1 and MN2, which fulfills our requirement, then follow their movements outside their shared home network. We consider that MN1 and MN2 have established a session and MN1 is the first to step outside the home network. It follows that our proposal requires both mobile nodes to use the "cryptographically generated addresses" technique, defined in [RFC3972], in order to compute and auto- configure their IPv6 home addresses. Establishing their mutual symbiotic relationship can be achieved using for example, the "Secure Neighbor Discovery" protocol (described in [RFC3971]). The required mutual, i.e.. bidirectional, relationship between the two mobile nodes is of cryptographic nature (please refer to [I-D.haddad-csi-symbiotic-sendproxy]) and is supposed to be established as a consequence of a mutual social relationship. When MN2 establishes a unidirectional 'symbiotic' 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. As mentioned earlier, such unidirectional crypto-relationship can be seen as the translation of the social relationship into a network and security layer parameters. This means that when using its CGA feature with other "stranger" nodes, MN2 does not need to disclose the roots of the modifier used to configure its CGA address. It becomes clear that in order to make use of a 'symbiotic' relationship, the same crypto relationship should be established in the opposite direction, i.e., from MN1 to MN2. Since the crypto relationship is secure and unidirectional, each mobile node can confidentially share its own part of the bidirectional relationship with its HA whenever needed. For this purpose, the IPsec tunnel established between the MN and its HA in order to encrypt the BU messages is used and the "proof of relationship" is inserted in the first BU message sent by MN1 to its HA. After validation, the HA Haddad Expires January 14, 2010 [Page 6] Internet-Draft MIPv6 RO Mode Optimization July 2009 stores the crypto-relationship in the binding cache entry (BCE) created for MN1. No further action is taken until the other part of the crypto-relationship is also disclosed to the HA (i.e., recall that a 'symbiotic' relationship is unidirectional which means that a mutual one requires both parties to disclose each other's RAN and their signatures). At some point in time, MN2 decides also to move outside the home network and sends its first BU message to update its HA with its new CoA. Since MN2 is still exchanging data packets with MN1, it inserts in the BU message the crypto-relationship it has established earlier with MN1. When validating the BU message sent by MN2, the HA checks if the claimed crypto-relationship with MN1 is reciprocal, i.e., if the one between MN1 and MN2 is already stored in MN1's corresponding BCE, before sending a BA message to MN2. In case a bidirectional relationship is confirmed, then, and only then, can the HA send in parallel a BA message to MN2 in which, it includes MN1's CoA and another new message to MN1 (called "Neighbor Binding Update (NBU)") which carries MN2's freshly stored CoA. It follows immediately that the NBU message enjoys the same security level than a classic BU message sent by a MN to its HA. This means that the same IPsec tunnel established between the MN and its HA can be used to secure the NBU message transmission as well as the acknowledgement message called "Neighbor Binding Acknowledgement (NBA)". Note that the HA SHOULD set a new bit (called "Buddy" (B) bit) in the BA message sent to MN2, in order to notify it about a parallel update of MN1. 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 redirect their data packets on the optimized path. Note that in order to increase the overall performance, the HA can send multiple consecutive copies of the NBU messages until it receives the NBA message. Subsequent BU messages sent to the HA and carrying new CoAs are processed in the same way as the first one. This means that the HA should always update the other mobile node and acknowledge the BU message at the same time. The suggested proposal can be extended to include multiple mobile nodes in which case the update would consist of sending one or multiple NBU message to the ones located outside the home network. Haddad Expires January 14, 2010 [Page 7] Internet-Draft MIPv6 RO Mode Optimization July 2009 5. Dual Mobility With Different Home Networks In this section, we look at the scenario where the mobile "buddies", i.e., MN1 and MN2, have two different HAs, i.e., they belong to different home networks. In order to enable implementing a simplified "zero signaling" RO mode between the two mobile nodes, we make the following two assumptions: - Each of the two HAs has an up-to-date list of other HAs IPv6 addresses as well as their advertised prefix(es) and public keys. Consequently, when MN1 requests RO mode service from its own HA (i.e., by sending a BU message to HA1) for MN2's IPv6 address, then HA1 can lookup MN2's prefix and obtain HA2's corresponding parameters. - The two HAs can set up an IPsec tunnel between them. Note that the first assumption does not hint that each HA should have a list of all HAs around the globe. In fact, the selected HAs are to be agreed upon between operators. It follows that the RO mode service cannot be provided via an HA which is not included in the list stored by the other MN's HA. We consider in the following that the IPsec tunnel is already in place and we don't worry about how it is set up. In the following scenario, MN1 sends the first BU message to its HA (i.e., HA1) while MN2 is still attached to its home network. In the BU message sent to HA1, MN1 discloses its relationship with MN2 as an implicit request for enabling RO mode between the two mobile endpoints. On HA1 side, the first step after creating a binding cache entry for MN1 is to lookup parameters related to MN2's HA (i.e., HA2). After obtaining HA2's IPv6 address and public key, HA1 triggers the RO mode service by sending a new message to HA2 (called "RO Neighbor Solicitation (RNS)") in which, it requests confirmation for the mutual relationship between MN1 and MN2. RNS message must carry MN1's HoA and CoA and the same associated binding lifetime stored by HA1. Being sent through the IPsec tunnel, the RNS message is encrypted and integrity protected. In addition, the HA may sign the message. When receiving a valid RNS message, HA2 checks its binding cache table for MN2's HoA. If the binding is not found, e.g., MN2 is still attached to its home network, then HA2 stores the RNS parameters until the expiration of the lifetime suggested in the RNS message. This means that as long as MN1 keeps mentioning MN2's HoA in the BU messages sent to HA1, the latter must make sure that HA2 has also a valid request for enabling RO mode between MN1 and MN2. After Haddad Expires January 14, 2010 [Page 8] Internet-Draft MIPv6 RO Mode Optimization July 2009 storing the RNS parameters, HA2 sends another new message called "RO Neighbor Present (RNP)" to HA1 in order to clarify MN2 status. The RNP message is also encrypted and integrity protected as it is sent in the IPsec tunnel. Note that HA1 does not need to wait for the RNP message before acknowledging the BU message from MN1. In fact, as long as HA1 does not have any parameters related to MN2 stored in its cache memory, it can send the BA message immediately to MN1 and without carrying any additional information. When MN2 moves outside its home network, it sends a BU message to HA2 in which, it discloses its relationship with MN1. Such message triggers a lookup of MN1's HoA in HA2 cache memory which will ultimately return MN1's RNS parameters. Following the lookup, HA2 replies first to HA1 by sending an "RO Neighbor Update (RNU)" message which carries MN2's new CoA and HoA, then replies to MN2 with a BA message which carries MN1's CoA. In the meantime, HA1 updates MN1 with MN2's new CoA by sending an NBU message. Note that HA2 may wait for an acknowledgement message from HA1, prior to sending the BA message with MN1's CoA. The RNU message must be sent in the IPsec tunnel between the two HAs. HA2 may also sign the message. It should also be mentioned that the above mechanism remains efficient in case of double jumping at the potential cost of sending two NBU messages (one for each MN), which remains negligible. Note that an HA should always send the RNU message to the other HA before sending the BA message to its mobile node. Haddad Expires January 14, 2010 [Page 9] Internet-Draft MIPv6 RO Mode Optimization July 2009 6. New Options, Bits and Messages Formats TBD Haddad Expires January 14, 2010 [Page 10] Internet-Draft MIPv6 RO Mode Optimization July 2009 7. Security Considerations This proposal aims to enhance the RO mode efficiency by removing the need for the return routability procedure. Consequently, RO mode related mobility signaling messages exchange between the mobile node and the correspondent node are no more required. Removing the RR and its justification, i.e., the BU/BA exchange, quickly eliminates related threats and thus, contributes to further improving the overall security. However, it should be noted again that this proposal is limited in its applicability to mobile nodes using the same home agent (or cluster of home agents). Our suggested mechanism introduces two new signaling messages which are exchanged between the MN and its HA. These two messages do not introduce any new threats nor amplify existing ones as they are exchanged within the IPsec ESP tunnel established between the MN and its HA. In addition to the tunnel encryption and integrity protection between the MN and the HA, there is also a mutual trust between the two nodes which provide enough insurance about the validity of the message content. This in turn, positively impacts the overall security of the procedure. However, it should be highlighted that the mutual trust between the MN and the HA does not propagate among mobile nodes sharing the same HA. In fact, it can be argued that a simpler way to implement our protocol would be to let the mobile node update its HA with the list of IPv6 addresses which are used by his/her buddies. In this case, the HA would consider an IPv6 address as a "proof of friendship" if it is sent by the first MN and also by the owner of the address. We argue that such approach is flawed as it can disturb the mutual trust between the HA and MN by allowing the latter to claim fake relationship with the list of selected targets' IPv6 addresses without any additional proof. Opening such hole would immediately raise doubts about why the HA and the MN should trust each other in the first place! Furthermore, having multiple mobile nodes playing the same trick with the HA would increase the chances of assembling a fake bidirectional relationship between two mobile nodes which are only curious about each other's current location and would lead at least one of them to disclose its location to the other. Haddad Expires January 14, 2010 [Page 11] Internet-Draft MIPv6 RO Mode Optimization July 2009 8. References 8.1. Normative References [I-D.ietf-mext-rfc3775bis] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", draft-ietf-mext-rfc3775bis-03 (work in progress), March 2009. [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. 8.2. Informative References [I-D.haddad-csi-symbiotic-sendproxy] Haddad, W. and M. Naslund, "On Secure Neighbor Discovery Proxying Using 'Symbiotic' Relationship", draft-haddad-csi-symbiotic-sendproxy-00 (work in progress), October 2008. Haddad Expires January 14, 2010 [Page 12] Internet-Draft MIPv6 RO Mode Optimization July 2009 Author's Address Wassim Michel Haddad Ericsson 6210 Spine Rd Boulder, CO 80301 US Phone: +1 303 473 6963 Email: Wassim.Haddad@ericsson.com Haddad Expires January 14, 2010 [Page 13]