Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6)
RFC 5419
|
| Document |
Type |
|
RFC - Informational
(January 2009; No 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 5419 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Jari Arkko
|
|
Send notices to |
|
mext-chairs@ietf.org
|
Network Working Group B. Patil
Request for Comments: 5419 Nokia
Category: Informational G. Dommety
Cisco
January 2009
Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (c) 2009 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.
Abstract
Mobile IPv6 defines a set of signaling messages that enable the
mobile node (MN) to authenticate and perform registration with its
home agent (HA). These authentication signaling messages between the
mobile node and home agent are secured by an IPsec security
association (SA) that is established between the MN and HA. The MIP6
working group has specified a mechanism to secure the Binding Update
(BU) and Binding Acknowledgement (BAck) messages using an
authentication option, similar to the authentication option in Mobile
IPv4, carried within the signaling messages that are exchanged
between the MN and HA to establish a binding. This document provides
the justifications as to why the authentication option mechanism is
needed for Mobile IPv6 deployment in certain environments.
Patil & Dommety Informational [Page 1]
RFC 5419 Why Authdata Option for MIPv6 January 2009
Table of Contents
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Background ......................................................3
4. Applicability Statement .........................................3
5. Justification for the Use of the Authentication Option ..........5
5.1. Motivation for Use of the Authentication Option in
CDMA2000 ...................................................5
5.2. Additional Arguments for the Use of the
Authentication Option ......................................6
6. Application of Mobile IPv6 in CDMA Networks .....................9
6.1. IPv4-Based Mobility Architecture in CDMA2000 Networks ......9
6.2. IPv6-Based Mobility Architecture in CDMA2000 Networks .....11
6.2.1. Overview of the Mobility Operation in
IPv6-Based CDMA2000 Networks .......................11
6.2.2. Authentication and Security Details ................12
7. Limitations of the Authentication Protocol Option ..............14
8. Security Considerations ........................................16
9. Conclusion .....................................................16
10. Acknowledgements ..............................................17
11. References ....................................................17
11.1. Normative References .....................................17
11.2. Informative References ...................................18
1. Introduction
Mobile IPv6 relies on the IPsec Security Association between the
Mobile Node (MN) and the Home Agent (HA) for authentication of the MN
to its HA before a binding cache can be created at the HA. An
alternate mechanism that does not rely on the existence of the IPsec
SA between the MN and HA for authenticating the MN is needed in
certain deployment environments. Such an alternate mechanism is
outlined in [RFC4285]. This document is intended to capture for
archival purposes the reasoning behind the need for the
authentication protocol [RFC4285]. It should be noted that the
alternate solution does not imply that the IPsec-based solution will
be deprecated. It simply means that in certain deployment scenarios
there is a need for supporting MIPv6 without an IPsec SA between the
MN and HA. So the alternate solution is in addition to the IPsec-
based mechanism specified in the base RFCs, i.e., [RFC3775],
[RFC3776], and [RFC4877]. It has been noted that some of the
challenges of deploying MIPv6 in certain types of networks arose from
dependence on the Internet Key Exchange (IKE), which did not
Show full document text