Securing Mobile IPv6 Route Optimization Using a Static Shared Key
RFC 4449
|
| Document |
Type |
|
RFC - Proposed Standard
(June 2006; Errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4449 (Proposed Standard)
|
|
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
Show full document text