Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6)
RFC 5419

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 07

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 authentication