Securing Mobile IPv6 Route Optimization Using a Static Shared Key
RFC 4449

 
Document
Type RFC - Proposed Standard (June 2006; Errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream
WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG
IESG state RFC 4449 (Proposed Standard)
Telechat date
Responsible AD Jari Arkko
Send notices to basavaraj.patil@nokia.com, gdommety@cisco.com

Email authors IPR References Referenced by Nits Search lists

Network Working Group                                         C. Perkins
Request for Comments: 4449                         Nokia Research Center
Category: Standards Track                                      June 2006

   Securing Mobile IPv6 Route Optimization Using a Static Shared Key

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   A mobile node and a correspondent node may preconfigure data useful
   for precomputing a Binding Management Key that can subsequently be
   used for authorizing Binding Updates.

Table of Contents

   1. Introduction ....................................................1
   2. Applicability Statement .........................................2
   3. Precomputing a Binding Management Key (Kbm) .....................3
   4. Security Considerations .........................................4
   5. Acknowledgement .................................................5
   6. References ......................................................5
      6.1. Normative References .......................................5
      6.2. Informative References .....................................6

1.  Introduction

   This specification introduces an alternative, low-latency security
   mechanism for protecting signaling related to the route optimization
   in Mobile IPv6.  The default mechanism specified in [1] uses a
   periodic return routability test to verify both the "right" of the
   mobile node to use a specific home address, as well as the validity
   of the claimed care-of address.  That mechanism requires no
   configuration and no trusted entities beyond the mobile node's home
   agent.

Perkins                     Standards Track                     [Page 1]
RFC 4449           Shared Data for Precomputable Kbm           June 2006

   The mechanism specified in this document, however, requires the
   configuration of a shared secret between mobile node and its
   correspondent node.  As a result, messages relating to the
   routability tests can be omitted, leading to significantly smaller
   latency.  In addition, the right to use a specific home address is
   ensured in a stronger manner than in [1].  On the other hand, the
   applicability of this mechanisms is limited due to the need for
   preconfiguration.  This mechanism is also limited to use only in
   scenarios where mobile nodes can be trusted not to misbehave, as the
   validity of the claimed care-of addresses is not verified.

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [2].  Other
   terminology is used as already defined in [1].

2.  Applicability Statement

   This mechanism is useful in scenarios where the following conditions
   are all met:

    -  Mobile node and correspondent node are administered within the
       same domain.

    -  The correspondent node has good reason to trust the actions of
       the mobile node.  In particular, the correspondent node needs to
       be certain that the mobile node will not launch flooding attacks
       against a third party as described in [5].

    -  The configuration effort related to this mechanism is acceptable.
       Users MUST be able to generate/select a sufficiently good value
       for Kcn (see [3])

    -  There is a desire to take advantage of higher efficiency or
       greater assurance with regards to the correctness of the home
       address offered via this mechanism.

    -  This mechanism is used only for authenticating Binding Update
       messages (and not, e.g., data), so the total volume of traffic is
       low (see RFC 4107 [4], and the discussion in section 4).

   This mechanism can also be useful in software development, testing,
   and diagnostics related to mobility signaling.

   Generally speaking, the required level of trust that the
   correspondent node needs for enabling a precomputable Kbm with a
   mobile node is more often found within relatively small, closed
   groups of users who are personally familiar with each other, or who

Perkins                     Standards Track                     [Page 2]
RFC 4449           Shared Data for Precomputable Kbm           June 2006
Show full document text