Mobility for IPv6 (MIP6) WG Basavaraj Patil
INTERNET-DRAFT Nokia
Date: September 2004 Gopal Dommety
Cisco
Why Authentication Data suboption is needed for MIP6
<draft-patil-mip6-whyauthdataoption-00.txt>
Status of This Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The security for signaling messages between the mobile node and home
agent in Mobile IPv6 is based on the existence of an IPsec SA between
the two entities. I-D: draft-ietf-mip6-auth-protocol-00.txt specifies
a mechanism to secure the binding update and binding acknowledgement
messages using an authentication option carried within these mes-
sages. This document captures the reasons why the authentication
option mechanism needs to be standardized by the Mobile IPv6 working
group.
Patil, Dommety [Page i]
INTERNET-DRAFT Authdata option for MIP6 September 2004
Table of Contents
Status of This Memo ............................................... i
1. Introduction ........ ......................................... 1
2. Background ....... ......................................... 1
3. Problem Description ......................................... 1
4. Solution .................................................... 4
5. Security Considerations .................................. 4
6. Conclusion ............................................... 4
Patil, Dommety [Page ii]
INTERNET-DRAFT Authdata option for MIP6 September 2004
1. Introduction
The MIP6 working group is currently debating the reasons why an
alternate mechanism to IPsec (specified in RFC 3775/3776) to secure
the binding update/Ack messages between the MN and HA is needed.
This document outlines some of the reasons why such a mechanism is
essential to ensure the wider deployment of the protocol. It should
be noted that the alternate solution does not imply that the IPsec
based solution would be deprecated. It simply means that in certain
deployment scenarios there is a need for supporting MIP6 without an
IPsec SA between the MN and HA. So the alternate solution would be in
addition to the IPsec based mechanism specified in the base RFCs.
2. Background
Mobile IPv6 signaling involves several messages. These include:
- The binding update/Binding ACK between the mobile node and the
home agent.
- The route optimization signaling messages which include
HoTI/Hot, CoTI/CoT and BU/BAck between the MN and CN. HoTI and
HoT signaling messages are routed through the MNs HA.
- Mobile prefix solicitation and advertisements between the MN
and HA.
- Home agent discovery by MNs.
The signaling messages between the MN and HA are secured using the
IPsec SA that is established between these entities. The exception
to this are the messages involved in the home agent discovery pro-
cess.
3. Problem Description
The use of IPsec for performing Registration with a home agent is
not always an optimal solution. While it is true that IPsec is an
integral part of the IPv6 stack, it is still a considerable
Patil, Dommety [Page 1]
INTERNET-DRAFT Authdata option for MIP6 September 2004
overhead from a deployment perspective of using IPsec as the secu-
rity mechanism for the signaling messages between the MN and HA.
Deployment of Mobile IPv6 on a large scale is possible only when
the protocol is flexible for being adapted to various scenarios.
The scenario being considered is the deployment in cdma2000 net-
works. cdma2000 networks are currently deployed in many countries
today. The packet data network architecture of cdma2000 [REF TIA-
835 C] includes a MIP4 foreign agent/Home agent and a Radius based
AAA infrastrucutre for authentication, authorization and account-
ing purposes. The AAA infrastructure provides the authentication
capability in the case of Mobile IPv4.
Typically, the Mobile Node shares a security association with the
AAA-Home entity. This is the preferred mode of operation over
having a shared secret between the MN and HA because the AAA-Home
entity provides a central location for provisioning and adminis-
tering the shared secrets for a large number of mobiles (mil-
lions). This mode of operation also makes dynamic home address and
dynamic home agent assignment easier. A similar approach is needed
for the deployment of Mobile IPv6 in these networks. There is no
practical mechanism to use IPsec directly with the AAA infras-
tructure with out the use of IKE or some other mechanism that
enables the establishment of the IPsec SA between the MN and HA.
Mobile IPv6 as specified in RFC3775 and RFC3776 implies a very
specific model for deployment. It anticipates the Mobile nodes
having a static home IPv6 address and a designated home agent. An
IPsec SA is expected to be created, either via manual keying or
established dynamically by using IKE. These assumptions do not
necessarily fit in very well for the deployment model envisioned
in cdma2000 networks.
cdma2000 networks would prefer to allocate home addresses to MNs
on a dynamic basis. The advantage of doing so is the fact that the
HA can be assigned on a link that is close to the MNs point of
attachment. While route-optimization negates the benefit of having
a home-agent on a link close to the MN, it cannot be always
guaranteed that the MN and CN will use or support route-
optimization. There may also be instances where the operator
prefers to not allow route optimization for various reasons such
as accounting aggregation or enforcing service contracts. In such
cases an HA that is close to the MNs point of attachment reduces
the issues of latency etc. of forward and reverse tunnelling of
pcakets between the MN and HA.
cdma2000 networks that are operational today have large numbers of
subscribers who are authenticated via the AAA infrastrucure.
Patil, Dommety [Page 2]
INTERNET-DRAFT Authdata option for MIP6 September 2004
Deployment of Mobile IPv6 should leverage the existing AAA infras-
tructure. The security model needed in these networks is an SA
between the MN and AAA-Home entity. This is the primary security
association that should be used for authenticating and authorizing
users to utilize MIPv6 service. This SA is then used for estab-
lishing session keys between the MN and the dynamically assigned
HA for authenticating Binding updates and binding acknowledgements
between them. Establishing an IPsec SA between the MN and HA using
AAA infrastrucure is not specified for Mobile IPv6 today. RFC3776
explains how IKE is used for establishing the SA between the MN
and HA. And even in this case, the MN has a designated home
address. cdma2000 network operators would prefer to assign home
addresses to the MN on a dynamic basis and do this preferably
using the AAA infrastrucutre which contains subscriber profile and
capability information.
A large subset of MNs in cdma2000 networks do not have IKE capa-
bility. As a result the use of RFC3776 for setting up the MN-HA
IPsec SA is not an option. It should also be noted that IKE
requires several transactions before it is able to establish the
IPsec SA.
cdma2000 operators are extremely concious in terms of the number
of messages sent and received over the air-interface for signal-
ing. The overhead associated with sending/receiving a large number
of signaling messages over the air interface has a direct impact
on the overall capacity and cost for the operator. Optimization of
the number of messages needed for using a service like Mobile IPv6
is of great concern. As a result the use of IKE for Mobile IPv6
deployment is detrimental to the operators bottom line.
Another downside of IKE for setting up the IPsec SA between the MN
and HA is that IKE does not integrate very well with the Radius
based AAA back-end. Since operators rely on the AAA infrastrucure
to provision subscribers as well as define profiles, keys etc. in
the AAA-Home, there is no getting away from the use of AAA in
cdma2000 networks.
In summary the current model of Mobile IPv6 deployment which man-
dates the existence of an IPsec SA between the MN and HA, as
specified in RFCs 3775 and 3776, is too rigid and does not meet
the requirements of operators building networks based on the
cdma2000 [TIA-835] specifications. This is a problem that needs to
be addressed in order to ensure wide-scale deployment of the pro-
tocol.
Patil, Dommety [Page 3]
INTERNET-DRAFT Authdata option for MIP6 September 2004
4. Solution
The above issues can be addressed by developing a solution that
allows MIPv6 deployment that does not mandate the use of IPsec for
securing the binding update and binding acknowledgment messages
between the MN and HA. A solution similar to the one that is used
in Mobile IPv4 today can be applied to Mobile IPv6 as well. The
experience gained in deploying Mobile IPv4 in cdma2000 networks on
a large scale can be reused for Mobile IPv6 also. The only con-
sideration is that the alternative solution should not be vulner-
able to attacks that are otherwise prevented by the use of IPsec.
5. Security Considerations
The security requirements for the signaling messages between
the MN and HA when using the authentication option mechanism
are the same as those when using IPsec to secure them.
6. Conclusion
Mobile IPv6 has been standardized only recently. Deployment of
this protocol on a large scale is in the interest of the IETF
and the working group as well as the many people who have
worked on this. A rigid model for deployment will cause the
protocol to be limited to an academic exercise only. It is
extremely critical that the working group consider the needs of
the industry and the deployemnt scenarios and address them
accordingly. Hence the solution proposed in I-D draft-ietf-
mip6-auth-protocol-00.txt should be standardized by the MIP6 WG
in the IETF.
7. Acknowledgments
The authors would like to thank Alpesh Patel, AC Mahendra, Kun-
tal Chowdhury and Vijay Devarapalli for their input and discus-
sions.
Patil, Dommety [Page 4]
INTERNET-DRAFT Authdata option for MIP6 September 2004
8. References
1 Mobility support in IPv6; RFC 3775
2 Using IPsec to Protest Mobile IPv6 Signaling between Mobile Nodes
and Home Agents; RFC 3776
3 TIA-835-C cdma2000 Wireless IP Network Standard
Patil, Dommety [Page 5]
INTERNET-DRAFT Authdata option for MIP6 September 2004
9. Authors's Addresses
Basavaraj Patil
Nokia
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 894-6709
E-mail: basavaraj.patil@nokia.com
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
USA
Phone: +1 408 525-1404
E-mail: gdommety@cisco.com
Patil, Dommety [Page 6]
INTERNET-DRAFT Authdata option for MIP6 September 2004
Patil, Dommety [Page iii]