Securing Mobile IPv6 Route Optimization Using a Static Shared Key
RFC 4449
Document | Type | RFC - Proposed Standard (June 2006; Errata) | |
---|---|---|---|
Author | Charles Perkins | ||
Last updated | 2015-10-14 | ||
Stream | Internet Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4449 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Jari Arkko | ||
Send notices to | (None) |
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 have some external basis for establishing trustworthy interactions. A typical example scenario where this mechanism is applicable is within a corporation, or between specific users. Application in the general Internet is typically not possible due to the effort that is required to manually configure the correspondent nodes. ApplicationShow full document text