Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6)
RFC 5419
Document | Type | RFC - Informational (January 2009; No errata) | |
---|---|---|---|
Authors | Basavaraj Patil , Gopal Dommety | ||
Last updated | 2015-10-14 | ||
Stream | Internet Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5419 (Informational) | |
Action Holders |
(None)
|
||
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 integrate well with an Authentication, Authorization, and Accounting (AAA) backend infrastructure. IKEv2 solves this problem. However, at the time of discussion on the need for the authenticationShow full document text