[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/