[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
Internet Engineering Task Force                            Wassim Haddad
Internet Draft                         Helsinki University of Technology
Expires in February 2004                        Ericsson Research Canada
                                                           Alan Kavanagh
                                                         Suresh Krishnan
                                                Ericsson Research Canada
                                                          Francis Dupont
                                                           ENST Bretagne
                                                              Hannu Kari
                                       Helsinki University of Technology
                                                          September 2003



                     BUB: Binding Update Backhauling

                     <draft-haddad-mipv6-bub-00.txt>


Status of this Memo

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   This document is an Internet-Draft.  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.

   Distribution of this memo is unlimited


Abstract

   Mobile IPv6 [1] defines two different modes to handle the
   mobility problem (i.e., mobile node moving accross different
   networks and changing its IP address). The two modes had been
   mainly designed for scenarios involving one mobile node and
   one static node (correspondent node). This document answers
   issues related to scenarios involving two mobile nodes (i.e.,
   the correspodent node is also a mobile node). The document
   addresses also the double jumping problem where two mobile nodes



Haddad, et al.                Expires February 2004             [Page 1]


INTERNET-DRAFT             Binding Update Backhauling     September 2003



   move at the same time (i.e., switch to new subnets).
   The document proposes a new mode called "BUB" (Binding Update
   Backhauling) allowing a more secure, reliable and optimized
   exchange of Binding Updates (BUs) between two mobile endpoints.


Table of Contents


   1. Introduction................................................2
   2. Terminology.................................................3
   3. Identifying the Problem.....................................3
   4. Proposed solution...........................................4
   5. Defining BUB................................................5
      5.1 The BUB test............................................5
      5.2 The BUB Option format...................................6
      5.3 Establishing the bidirectional SA.......................8
   6. Impact on BU/BA and RR test messages........................8
   7. Security Considerations.....................................9
   8. Acknowledgements............................................9
   9. Normative References.......................................10
   10. Informative References....................................10
   11. Author's Addresses........................................10
   12. Full Copyright Statement..................................11
   Appendix A....................................................13


1. Introduction

   The mobility problem has been described, in most of the cases,
   as a scenario involving one mobile endpoint (referred to as MN)
   and another static endpoint (referred to as CN).

   Mobile IPv6 defines two different modes to handle the mobility
   problem. These modes are the bidirectional tunneling and
   route optimization (RO). The two modes represent a trade-off
   between security and efficiency. For instance, the bidirectional
   tunneling mode enables a secure exchange but is not optimized at
   all, while the route optimization (RO) mode offers better
   efficiency but raises many security concerns.

   This draft proposes a new mode called Binding Update Backhauling
   (BUB) especially designed to be used when two endpoints are
   mobile. This mode enables a more secure and reliable way for
   exchanging mobility signaling messages, while preserving at the
   same time the efficiency of the routing optimization mode.






Haddad, et al.                Expires February 2004             [Page 2]


INTERNET-DRAFT             Binding Update Backhauling     September 2003



2. Terminology

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY"
   in this document are to be interpreted as described in RFC 2219
   [3].


3. Identifying the Problem

   The route optimization (RO) mode allows two endpoints to
   exchange data traffic by using the direct path between them.
   This is achieved by using new mobility headers and relies on
   exchanging mobility signaling messages each time the MN
   switches to a new network (i.e., changes its IP address).

   Each time a MN gets a new IP address (i.e., care-of address), it
   needs, according to [1], to run a return routability (RR) test
   in order to test the reachability of its new care-of address and
   home address by the CN, prior to sending any binding update (BU)
   message to the CN.
   Such test is performed by exchanging two signaling messages
   (CoTI/CoT) on the new direct path (i.e., the path used to
   exchange data traffic), and two signaling messages (HoTI/HoT)
   using the path going through the MNs'HAs. The result of the test
   creates a new state at the CN to be used to check the
   authenticity of the BU sent by the MN. Only a successful test
   allows the MN to send a BU to the CN to update its binding cache
   entry (BCE). The CN should acknowledge the BU by sending a
   binding acknowledgement (BA) to the MN.
   In total, 6 messages are needed to update the CN about the new
   MN's IP address.

   If the CN becomes mobile, it needs to go through the same
   procedure (i.e., exchange 6 messages) each time it gets a new IP
   address, in order to keep the session alive.

   Note that, for security reasons, it is stated in [1] and
   explained in [4] that the lifetime of the state created at the
   correspondent node is deliberately restricted to a few minutes,
   in order to limit the potential ability of time shifting attack.

   From the above scenario it appears that when the RO mode is
   used between two mobile endpoints, it may create additional
   and undesirable traffic, due to a high redundancy of mobility
   signaling messages, and more vulnerabilities. Actually, when the
   CN becomes mobile, the frequency, as well as the redundancy, of
   mobility signaling messages will increase, thus making them more
   visible for a malicious node moving nearby the two endpoints.
   Note that when the CN is mobile, it is highly probable that a



Haddad, et al.                Expires February 2004             [Page 3]


INTERNET-DRAFT             Binding Update Backhauling     September 2003



   malicious node may be positioned nearby, thus creating a
   vulnerability on both sides (since another one may probably be
   standing nearby the MN). Such scenario makes the exchange of
   signaling messages between the two endpoints more challenging
   with regards to the security requirements.

   If MN2 moves at the same time than MN1, mobility signaling
   messages may get lost due to the fact that MN1's care-of address
   and MN2's care-of address have changed at the same time. Such
   scenario will probably increase the latency of the handover
   process, which is not desired especially for time sensitive
   applications.

   To address all issues described above, any possible solution
   should offer an efficient optimization with regards to security
   requirements and the number of signaling messages.

   This document describes one such optimization which meets all
   these requirements.


4. Proposed solution:

   The Binding Update Backhauling (BUB) is a new mode designed to
   be used by two mobile endpoints. The suggested mode should be
   considered as an enhancement to the route optimization mode
   since it uses the same direct path between MN and CN for the
   data traffic exchange.

   The main objectives of the BUB mode are to reduce the number of
   mobility signaling messages exchanged between the two MNs and
   increase the security of what will remain. This is achieved by
   eliminating the HoTI/HoT messages and diverting the BUs/BAs
   messages to a more secure and reliable path going through the
   two HAs, while keep using the direct path for the data traffic
   exchange.

   The design of the proposed solution is based on the fact that
   the paths between the MNs and their HAs are protected by an ESP
   tunnel [2] and on the following assumptions:


    a) The path between the two HAs, being part of the backbone, is
       more secure and more stable than the dynamic path between
       the two MNs.

    b) A malicious node cannot be at the same time near the MNs and
       near the path going between the two HAs.




Haddad, et al.                Expires February 2004             [Page 4]


INTERNET-DRAFT             Binding Update Backhauling     September 2003



      By diverting the signaling messages to a more reliable path, BUB
  addresses the following issues:

    - Security of BUs: By sending the BUs through the link between
      the two HAs and by establishing a bidirectional security
      association (SA) between the two MNs.

    - Double jumping problem: By avoiding the loss of mobility
      signaling messages, BUB reduces the latency caused by such
      loss.

    - Excessive signaling: BUB reduces the number of signaling
      messages, exchanged between the two MNs, by eliminating the
      need for HoTI/HoT messages.


5. Defining BUB


5.1 The BUB Test

   When both endoints are mobile, the following four entities become
   involved:



                     MN1                 CN(MN2)
                      |                    |
                      |                    |
                      |                    |
                      |                    |
                      |                    |
                     HA1------------------HA2



   Mobile nodes should be able to switch to BUB mode at the
   beginning of the session (i.e., when at least one MN moves
   outside of its home network) or at any time during the ongoing
   session.

   In both cases, the switch to BUB mode should not be performed
   before running a successful BUB test. The BUB test makes both
   endpoints agree on using the link going through the two HAs for
   exchanging BU/BA messages. This is a simple test, which consists
   on exchanging four messages and MUST be run in parallel with the
   RR test.

   In the following scheme, MN1 is asking MN2 to switch to BUB mode:



Haddad, et al.                Expires February 2004             [Page 5]


INTERNET-DRAFT             Binding Update Backhauling     September 2003





                     MN1                         MN2
                      |                           |
                    _ |          Do BUB           |
                   |  |  -----------------------> |
                   |  |                           |
         HoTI/HoT  |  |          BUB ACK          |
         messages  |_ |  <----------------------- |
                      |                           |
                      |                           |
                      |          Do BUB           | _
                      |  -----------------------> |  |
                      |                           |  | CoTI/CoT
                      |          BUB ACK          |  | messages
                      |  <----------------------  | _|
                      |                           |
                      |                           |



   A successful completion of a BUB test consists of sending two
   messages "Do BUB" and receiving two messages "BUB ACK". Each
   request is incorporated into HoTI/CoTI message and each response
   is incorporated into HoT/CoT message. This enables MN1 to use
   two different paths to test the willingness of MN2, without
   adding new messages.

   A BUB test fails if both of the "BUB ACK" messages are not
   received after two successive tries. In this case, MN1 MUST send
   the BUs according to the RO mode.

   Note that in case of test failure, the endpoint, which has
   launched the BUB test procedure MUST NOT run it again during the
   same session. However, the other endpoint MUST always be able to
   start a BUB test at any time during the same ongoing session.


5.2 The BUB Option format

   A new BUB option will be defined for carrying BUB messages. This
   option MAY be inserted in all Return Routability test messages
   (i.e., HoTI, HoT, CoTI, CoT). The format of the new option is
   the following:








Haddad, et al.                Expires February 2004             [Page 6]


INTERNET-DRAFT             Binding Update Backhauling     September 2003



   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Option Type  | Option Length |   Option Data...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Option Type

   TBD

   Option Length

   Length of the option: 1

   Option Data

   This field can contain one of two possible messages defined in
   three different codes as following:

     code 0 => "Do BUB"
     code 1 => "BUB ACK"
     code 2 => "BUB NACK"

     - When used in a HoTI message: the field MUST contain the code
       "0".

     - When used in a HoT message: the field MUST contain either
       code "1" or code "2".

     - When used in a CoTI message: the field MUST contain the code
       "0".

     - When used in a CoT message: the field MUST contain either
       code "1" or code "2".

   Note that if the sender gets two different responses in the CoT
   and the HoT messages, it MUST re-run the RR test procedure and
   the BUB test. In the latter case, if the sender gets again two
   different responses, it MUST abandon switching to the BUB mode.

   If one mobile node launchs a BUB test and the other endpoint
   does not wish to switch to the BUB mode, it MUST reply to the
   BUB test by sending two negative acknowledgements (NACK).
   Such scenario may occur in case the other endpoint is static
   or it has became static (i.e., it has not sent any BUs since a
   predefined time).

   If the two mobile endpoints agree to switch to the BUB mode,



Haddad, et al.                Expires February 2004             [Page 7]


INTERNET-DRAFT             Binding Update Backhauling     September 2003



   they SHOULD NOT switch back at any time to the RO mode in the
   ongoing session.


5.3. Establishing the bidirectional SA:

   After a successful BUB test, the two MNs MUST establish a
   bidirectional security association (SA) between them. Such SA
   (more details in Appendix 1) MAY use the binding management key
   (Kbm), generated from the RR test, as a pre-shared secret
   between the two MNs.


6. Impact on BU/BA and RR test messages

   As it has been mentioned earlier, the main reasons for designing
   BUB are the security concerns around BU messages and the high
   redundancy in mobility signaling messages. The establishment of
   a bidirectional SA between the two MNs enable them to
   substantially improve the safety of the BU/BA messages and
   eliminates the need for any further HoTI/HoT messages during the
   ongoing session. Such optimization leads to a reduction of 2
   messages between the two MNs each time a BU is sent.

   As another optimization, an MN can extend the use of the BA
   message to notify the CN about the change in its IP address
   without sending another BU carrying the same information. This
   eliminates one pair of BU/BA.

   The two MNs SHOULD perform a test of reachability for any new
   direct path (i.e., RO mode) resulting from one MN switching to a
   new network. The reachability MUST be tested in both directions.
   Such test SHOULD be achieved by using the pair of CoTI/CoT
   messages. The test MAY be run in the following way:

   If MN1 moves to a new network, it will send, in parallel, with
   the BU a CoTI message to MN2 using the new direct path between
   them (i.e., MN1 MUST perform a BCE lookup). In case MN2 has not
   moved at the same time than MN1, it will reply to MN1 by sending
   a CoT message. MN2 SHOULD NOT acknowledge the CoTI message
   before it receives a BU from MN1 related to the same new IP
   address. The two messages SHOULD be protected by the session key
   generated from the DH exchange between the two MNs.
   The protection of the CoTI/CoT messages MAY be limited to an
   authentication.

   If MN2 moves at the same time than MN1, it may not receive the
   CoTI message sent by MN1. To address this issue, each time MN1
   sends a CoTI, it MUST check the validity of the destination



Haddad, et al.               Expires February 2004              [Page 8]


INTERNET-DRAFT             Binding Update Backhauling     September 2003



   address used in the message by comparing it with the IP address
   received in the latest BA message. If the IP address matches the
   one used by MN1, then no further action is required and MN1
   should wait for a CoT message before it resumes the session. If
   the IP address in the BA message is different from the one used
   in the CoTI, then MN1 MUST send a new CoTI message using the new
   IP address except if it has already received a CoTI message from
   MN2. In the latter case, MN1 SHOULD send only a CoT message
   after receiving a BU.
   Note that in this situation, MN1 SHOULD silently discard any
   ICMP message (e.g., indicating an unreachable destination).


   The different paths used to exchange BU/BAs and CoTI/CoT
   messages appears in the following scheme:




                  +------+        CoTI     +------+
                  |      |---------------->|      |
                  |  MN1 |                 | MN2  |
                  |      |<----------------|      |
                  +------+        CoT      +------+
                    |  ^                     |  ^
                    |  |                     |  |
                  BU|  |BA                 BA|  |BU
                    |  |                     |  |
                    V  |                     v  |
                  +------+        BA       +------+
                  |      |<----------------|      |
                  |  HA1 |                 | HA2  |
                  |      |---------------->|      |
                  +------+        BU       +------+




7. Security considerations

   This draft proposes a new mode which makes the exchange of
   BUs/BAs more secure. It should be considered as an enhancement
   to the security of the signaling  messages exchange between two
   mobile endpoints.


8. Acknowledgements

   Authors would like to thank Laurent Marchand for his review and



Haddad, et al.               Expires February 2004              [Page 9]


INTERNET-DRAFT             Binding Update Backhauling     September 2003



   comments on the draft. Thanks to Karim El-Malki and Shinta
   Sugimoto for improving the draft.


9. Normative References

   [1] D. Johnson and C. Perkins, "Mobility Support in IPv6",
       draft-ietf-mobileip-ipv6-24.txt, June 2003.

   [2] J.Arkko, V. Devarapalli, F. Dupont, "Using IPsec to Protect
       Mobile IPv6 Signaling between Mobile Nodes and Home Agents",
       draft-ietf-mobileip-mipv6-ha-ipsec-06.txt.

   [3] S. Bradner, "Key words for use in RFCs to Indicate
       Requirement Levels", BCP 14, RFC 2119.


10. Informative References

   [4] P. Nikander, T. Aura, J. Arkko, G.Montenegro and E. Nordmark
       "Mobile IP version 6 Route Optimization Security Design
       Background", draft-nikander-mobileip-v6-ro-sec-01.txt.

   [5] Krawczyk, H., "SIGMA: the 'SIGn-and-MAC'Approach to
       Authenticated Diffie-Hellman and its use in the IKE
       Protocols", in Advanceds in Cryptography - CRYPTO 2003
       Proceedings, LNCS 2729, Springer, 2003. Available at:
       http://www.ee.technion.ac.il/~hugo/sigma.html


11. Authors' Addresses

   Wassim Haddad
   Ericsson Research Canada
   8400, Decarie Blvd
   Town of Mount Royal
   Quebec H4P 2N2
   CANADA
   Tel: +1 514 345 7900
   Fax: +1 514 345 7900
   E-mail: Wassim.Haddad@lmc.ericsson.se

   Alan Kavanagh
   Ericsson Research Canada
   8400, Decarie Blvd
   Town of Mount Royal
   Quebec H4P 2N2
   CANADA
   Tel: +1 514 345 7900



Haddad, et al.               Expires February 2004            [Page 10]


INTERNET-DRAFT             Binding Update Backhauling    September 2003



   Fax: +1 514 345 7900
   E-mail: Alan.Kavanagh@lmc.ericsson.se

   Suresh Krishnan
   Ericsson Research Canada
   8400, Decarie Blvd
   Town of Mount Royal
   Quebec H4P 2N2
   CANADA
   Tel: +1 514 345 7900
   Fax: +1 514 345 7900
   E-mail: Suresh.Krishnan@lmc.ericsson.se

   Francis Dupont
   ENST Bretagne
   Campus de Rennes
   2, rue de la Chataigneraie
   BP 78
   35510 Cesson Sevigne Cedex
   FRANCE
   Fax: +33 2 99 12 70 30
   E-mail: Francis.Dupont@enst-bretagne.fr

   Hannu Kari
   Helsinki University of Technology
   Laboratory for Theoretical Computer Science
   P.O. Box 5400
   FIN-02015 HUT
   FINLAND
   Tel: +358 9 451 2918
   E-mail: Hannu.Kari@hut.fi



12. Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.
   This document and translations of it may be copied and furnished
   to others, and derivative works that comment on or otherwise
   explain it or assist in its implementation may be prepared,
   copied, published and distributed, in whole or in part, without
   restriction of any kind, provided that the above copyright
   notice and this paragraph are included on all such copies and
   derivative works. However, this document itself may not be
   modified in any way, such as by removing the copyright notice or
   references to the Internet Society or other Internet
   organizations, except as needed for the purpose of developing
   Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or



Haddad, et al.                Expires February 2004            [Page 11]


INTERNET-DRAFT             Binding Update Backhauling     September 2003



   as required to translate it into languages other than English.
   The limited permissions granted above are perpetual and will not
   be revoked by the Internet Society or its successors or
   assignees.
   This document and the information contained herein is provided
   on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS 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.









































Haddad, et al.                Expires February 2004            [Page 12]


INTERNET-DRAFT              Binding Update Backhauling    September 2003



Appendix A: Establishing Bidirectional Security Association


   As it has been stated in 4.3, after a successful BUB test, the
   two MNs MUST establish a bidirectional security association
   between them and generate a session key. The session key MUST be
   used to authenticate BUs/BAs messages exchanged between the two
   MNs via the path going through their two HAs. The session key
   MAY also be used to authenticate the CoTI/CoT messages exchanged
   via the direct path.

   The session key is generated from a Diffie-Hellman (DH) exchange
   which MUST be authenticated. Such authentication MAY use the Kbm
   key as a pre-shared secret used to sign the DH messages.
   Note that the Kbm key MUST be the last key generated from the RR
   test (i.e., the RR test during which, the BUB test has been
   launched).

   The DH messages exchanged between the two MNs are described in
   the following (for more details about the messages structure and
   how to generate different keys, please refer to [5]):



                        sid   , gX, N   , info
   MN1                     MN1       MN1      MN1               MN2
   --------------------------------------------------------------->


                     sid   , sid   , gY, N   , info
                        MN1     MN2       MN2      MN2
   <---------------------------------------------------------------



   sid   ,sid   ,MN1,SIG  (N   ,sid   ,gX,info ,info  ),  MAC(MN1)
      MN1    MN2      Kbm   MN2   MN1         MN1   MN2      Km
   --------------------------------------------------------------->



   sid   ,sid,  ,info  ,MN2,SIG  (N  ,sid  ,gY,info   ,info),MAC(MN2)
      MN1    MN2    MN2      Kbm   MN1  MN2       MN2    MN1   Km
   <---------------------------------------------------------------



   In the above scheme, the following abbreviations have been
   adopted:



Haddad, et al.                Expires February 2004            [Page 13]


INTERNET-DRAFT              Binding Update Backhauling    September 2003



     -gX = shared part of MN1's secret

     -gY = shared part of MN2's secret

     -sid = session identifier used to specify the ongoing session.

     -N = nonce

     -info = additional information carried in the protocol
             messages

     -MN1 = Identity of MN1 (e.g., MN1's Home IP address)

     -MN2 = Identity of MN2 (e.g., MN2's Home IP address)

     -Kbm = key generated from the RR test

     -SIG(msg) = denotes the signature of "msg" using the Kbm.

     -Km = key generated from DH (known only by MN1 and MN2)

     -MAC(msg) = denotes a message authenticated code computed from
        Km       "msg" and signed by Km.





























Haddad, et al.                Expires February 2004            [Page 14]