MIP6 J. Kempf
Internet-Draft DoCoMo Labs USA
Expires: June 3, 2005 E. Nordmark
SUN Microsystems
S. Chakrabarti
Sun
December 3, 2004
Bootstrapping Mobile IPv6
draft-chakrabarti-mip6-bmip-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she 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.
This Internet-Draft will expire on June 3, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document defines an easy mechanism of boot-strapping Mobile IPv6
service. The boot-strapping mechanism includes locating a home
agent, dynamic home-address allocation and setting up initial
security association with the home-agent using IKE version 2 and EAP.
Kempf, et al. Expires June 3, 2005 [Page 1]
Internet-Draft BMIP December 2004
This solution provides a way of secure and easy deployment without
the involvement of AAA servers for the boot-strapping purpose. It is
particularly useful in scenarios where AAA infrastructure is not
available, although this mechanism can be applicable in general.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Deployment Examples . . . . . . . . . . . . . . . . . . . . . 5
2.1 Universal Access Method . . . . . . . . . . . . . . . . . 5
2.2 Enterprise/University Campus Network . . . . . . . . . . . 6
2.3 Network Access Provider Service Only . . . . . . . . . . . 6
3. Protocol Descriptions . . . . . . . . . . . . . . . . . . . . 7
3.1 Obtaining Home Agent Address . . . . . . . . . . . . . . . 7
3.2 Setting up Security Association . . . . . . . . . . . . . 7
3.3 Dynamic Home Address Assignment . . . . . . . . . . . . . 8
3.4 Renewal of Bootstrapping Materials . . . . . . . . . . . . 8
4. Home Agent Requirements . . . . . . . . . . . . . . . . . . . 10
5. Mobile Node Requirements . . . . . . . . . . . . . . . . . . . 11
6. EAP Considerations . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
A. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 17
10.2 Informative References . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 19
Kempf, et al. Expires June 3, 2005 [Page 2]
Internet-Draft BMIP December 2004
1. Introduction
Mobile IPv6 [3] describes mobility protocol between a Mobile Node and
a Home Agent. This document describes a simple method to initiate
the Mobile IPv6 service by the Mobile Node, without requiring home
network topology-dependent information, such as the home agent
address, on the Mobile Node. The initiation or boot-strapping of
Mobile IPv6 [3] can happen any time depending on the policy applied
on the Mobile Node. It is possible that the boot-strapping method
starts every time a Mobile Node boots or wakes up from standby
status; alternately, it can be started when the user turns on
"Mobility Service".
Mobile IPv6 Bootstrapping problem statement [9] indicates that the
mobile node must know its Home Agent address, its own Home Address
and materials to obtain MN-HA [4] security association in order to
start the Mobility service in a deployment scenario. Mobile IPv6
[3][4] protocols do not describe a method to obtain such initial
information; it assumes that a Mobile Node is already configured with
a home-address from its Home Agent and MN-HA security association is
configured at MN and HA. However, in real deployment, this
assumption requires manual configuration which does not scale as the
Mobile Nodes increase in number.
This document, in the following sections describes a solution for
bootstrapping method that only involves Domain Naming Service (DNS)
and a Home Agent running IKE version 2 [6]. Hence it does not
require any other additional infrastructure such as AAA
(Authentication, Authorization and Accounting Protocol) and operates
separately from whatever scheme is used for authenticating the
network access for the mobile node.
The solution refers to other existing protocols and documents
whenever possible. The document assumes that the mobile node has
already acquired IP service at its location, which might have been
authenticated any number of ways:
o IEEE 802.1X
o PANA
o Universal Access Methods [13] or web-based credit card number
verification for authenticated and authorized network access.
o Other local schemes based on manually handling out L2 (WEP) keys,
registering MAC addresses, or controlling physical access a
(wired) network.
Thus it does not necessarily assume that the L2/EAP authentication is
used for network access authentication.
Privacy considerations are discussed in the Appendix.
Kempf, et al. Expires June 3, 2005 [Page 3]
Internet-Draft BMIP December 2004
The keywords MUST, MUST NOT, SHOULD, SHOULD NOT, MAY and RECOMMENDED
are defined in [1].
Kempf, et al. Expires June 3, 2005 [Page 4]
Internet-Draft BMIP December 2004
2. Deployment Examples
This section describes a few examples of where AAA bootstrapping
might not be available.
2.1 Universal Access Method
Universal Access Method [13] is a technology for basic network access
authentication and authorization that is widely used in 802.11
hotspot networks throughout the world. In a UAM network, the host is
allowed to perform DHCP to obtain an IP address and other parameters
necessary for network access, but routing to the Internet is
inhibited until the host completes a login process. The login
process requires the host's user to attempt to browse a Web page,
using a Web browser. Any other IP traffic is dropped. The HTTP GET
issued by the Web browser is redirected, and a login page is
displayed instead.
On the login page, the user typically has a choice to either provide
a login/password, for an account on file with the service provider,
or a credit card number, for one-time only access. If a
login/password is provided, the back end conducts a typical Radius
AAA transaction back to the home network AAA server. If a credit
card number is provided, a secure E-commerce protocol is used to
contact the user's credit card provider, and the charges are billed
to the user's credit card. Acceptance of the charge by the credit
card provider constitutes authorization for the user to get IP
service. Once the user has been authenticated and authorized for IP
service, routing to the Internet is established and the original Web
page browsed by the user is displayed. The only protocol involved in
the transaction is HTTP.
In this deployment scenario, there is no hook for providing the
Mobile Node with Mobile IPv6 bootstrapping parameters, because there
is no L2 AAA transaction conducted between the Mobile Node and the
network. For account-based access, Radius is used on the back end,
between the network access server (called a Public Access Control
(PAC) Gateway in the UAM architecture) and the home network of the
user, but there is no path from the PAC Gateway to the Mobile Node
for delivering the bootstrap parameters. For one-time access, there
is no AAA involved at all.
The protocol discussed in this document would be an appropriate
solution to bootstrapping in this scenario, because it could be run
after the PAC Gateway has opened Internet routing access.
Kempf, et al. Expires June 3, 2005 [Page 5]
Internet-Draft BMIP December 2004
2.2 Enterprise/University Campus Network
Many university and enterprise networks authenticate hosts attempting
to use their network by checking whether the MAC address corresponds
to a MAC address in a database of allowed terminals. Some such
deployments additionally require a login/password from the user for
an account, using the same kind of HTTP Redirect procedure used by
UAM. In order for a user to access the network, the MAC address of
the laptop must be provided to system administrators and an account
established.
In such deployment scenarios, there is also no L2 AAA transaction
between the Mobile Node and the network that can serve to provide
configuration parameters. The protocol described in this document
can be deployed by the campus or enterprise system administrator to
bootstrap Mobile IPv6 service.
2.3 Network Access Provider Service Only
The Mobile IPv6 Bootstrapping problem statement [9] describes a case
where an Internet service provider only provides network access and
does not provide mobility service. In this case, the initial L2 AAA
transaction cannot provide the Mobile Node with bootstrapping
parameters, because the access network provider doesn't provide
Mobile IPv6 service. In this case, the Mobile Node could use the
protocol discussed in this document to obtain service from another
provider, perhaps one discovered opportunistically or perhaps one
with which the user has a long term account.
Kempf, et al. Expires June 3, 2005 [Page 6]
Internet-Draft BMIP December 2004
3. Protocol Descriptions
Mobile IPv6 Bootstrapping [9] problem statement describes network
access service and Mobile IPv6 service. This document does not
define protocols for network access and assumes that network access
and authorization have taken place before the Mobile Node bootstraps
for mobility service. Thus, the following steps are required to
perform this solution, they are:
o Find appropriate Home Agent FQDN from DNS SRV record
o Use IKEv2, possibly with EAP method to obtain IKE security
association. (And this would allow an evolution towards
certificate-based authentication in the future without changing
any protocols.)
o Use IKEv2 to obtain the Home-address dynamically if its not
available to the Mobile Node already and then obtain MN-HA
security association
3.1 Obtaining Home Agent Address
A Mobile Node queries the DNS server to request information on Home
Agent service. RFC 2782[2] describes the policies to choose a
service agent based on the preference and weight values. The DNS SRV
record may contain the preference and weight values for multiple Home
Agents available to the Mobile Node in addition to the Home Agent
FQDNs. If multiple Home Agents are available in the DNS SRV record
then Mobile Node is responsible to process the information as per
policy and pick one Home Agent. If the Home Agent of choice does not
respond for some reason or the IKE authentication fails, the Mobile
Node SHOULD try other Home Agents on the list. The Home Agent
information MUST be stored in the Mobile Node as long as it is using
the mobility service or on the same access network in order to
expedite the bootstrapping process for obtaining security association
and home address.
The service name for Mobile IPv6 home agent service as required by
RFC 2782 is "mip6" and the protocol name is "ipv6". Note that a
transport name cannot be used here because Mobile IPv6 does not run
over a transport.
Example: A mobile node with the example.net home domain would perform
a SRV query for _mip6._ipv6.example.net.
3.2 Setting up Security Association
IKEv2 [6] describes IKE authentication by using EAP methods. IKE
version 2 allows a client to use an EAP method for authentication
Kempf, et al. Expires June 3, 2005 [Page 7]
Internet-Draft BMIP December 2004
while the responder uses certificates or pre-shared keys for the
server authentication. Thus the Mobile Node must have some
information about the Home Agent's certificate authority in order to
verify the certificate. Such information MUST be preconfigured on
the Mobile Node, if the Mobile Node has a long term relationship with
the mobility service provider. If that is not the case, the Home
Agent's certificate certificate authority (CA) or root CA information
SHOULD be obtained from the Home Agent's network through the DNS SRV
record. Each Home Agent's information is bound to its root CA or
certificate authority. While certificates are not commonly used on
hosts today, certificate-based authentication - in which no EAP
transaction is involved - can also be accommodated by the protocol.
For purposes of tying the Mobile Node's IKEv2 identity to its EAP
identity, the users Network Access Identifier [8] SHOULD be used to
establish the IKEv2 security association. This corresponds to an
IKEv2 identity type of 3 (ID_RFC822_ADDR). For more details in
setting up the parameters for IKE authentication phase and consequent
IKE child-SA phase refer to [5].
3.3 Dynamic Home Address Assignment
A Mobile Node may obtain its home address dynamically from the Home
Agent when it reboots or when its security association with the Home
Agent expires. If Home Agent knows its home address or the last used
home address for the corresponding Home Agent, it SHOULD include that
home address in the assignment request. If Mobile Node is using SEND
[10], it SHOULD supply a host id suffix for a CGA (Cryptographically
generated address).
The details of home address assignment using IKEv2 is described in
[5]. A Mobile Node SHOULD store the home address locally for
efficient renewal of security association with its Home Agent.
3.4 Renewal of Bootstrapping Materials
A Mobile Node SHOULD store the home address and the Home Agent
information locally as long as it is in the same network or using the
same Mobile IPv6 service. A Mobile Node MUST have its unique
identity (for example, NAI) which is bound with home address and
MN-HA IKEv2/IPsec security associations. This unique identity must
be stored both at Mobile Node and at the Home Agent. This identity
is used by the Home Agent to verify that it is talking to the same
node which perhaps expired the SA (security Association) recently.
This is useful for additional proof of authentication. Binding to
unique identity is also useful when a mobile node uses multiple home
addresses.
Kempf, et al. Expires June 3, 2005 [Page 8]
Internet-Draft BMIP December 2004
A Mobile Node SHOULD renew its IKE/IPsec security associations before
they expire. It is recommended that the default IKE security
association is at least same as IPsec SA and home-address lifetime.
The default IKE SA lifetime SHOULD be large (say
IKE_BMIP_SA_LIFETIME_MAX).
Thus the Mobile Node does not need to go through the whole
bootstrapping process to renew home Address and IKE SA if it stays on
the same access network for a long period of time. Dynamic home
address lifetime SHOULD be at least long enough to match IKE/IPsec SA
lifetimes in order to prevent unnecessary boot-strapping messaging
exchange.
Upon reboot, a Mobile Node may or may not lose its home address, Home
Agent address and IKE/IPsec security associations depending on the
Mobile Node configuration options. By default, a Mobile Node must
start bootstrapping process upon reboot.
If the access method involves user interaction, such as UAM, the user
may be presented with a Web page after initial network access
offering the FQDNs of one or several mobility service provider links.
These links, when selected, may directly or indirectly cause the
bootstrapping procedure described here to run.
Reasons for re-bootstrapping after the initial one are subject to
individual service provider policy, but some possible reasons for
re-bootstrapping are the following:
o Load balancing
o Home Agents being taken off line for maintenance
o Unanticipated HA failure
Note that RFC 3775 [3] currently defines no way for a HA to inform
its active Mobile Nodes that it is about to go down and that it
should find a new HA or recommending a new HA, like the ICMP Redirect
message used by a first hop router. By the existing Mobile IPv6
standard, an MN will only discover that its HA is unavailable when
either tunneled packets stop arriving, if traffic is not route
optimized, or when it tries to perform a binding update to the HA and
the HA does not respond. It is possible that IKEv2 could provide
some indication that the IPsec SA is being deactivated, but such an
indication would not provide enough information to determine whether
the MN should re-bootstrap and find a new HA, since the SA may be
deactivated for other reasons.
Kempf, et al. Expires June 3, 2005 [Page 9]
Internet-Draft BMIP December 2004
4. Home Agent Requirements
Home Agent MUST support [5].
A Home Agent MAY operate along with a AAA home-server. But the
communication between Home Agent and the AAA home-server is
independent of the boot-strapping process in this solution.
Kempf, et al. Expires June 3, 2005 [Page 10]
Internet-Draft BMIP December 2004
5. Mobile Node Requirements
o A Mobile Node is aware of its Home Domain name or Home ISP domain
name
o A Mobile Node MUST support [5].
o A Mobile Node must have configuration policies to control
bootstrapping frequencies
o A Mobile Node must be capable of storing home address and Home
Agent address and IKE MN-HA [5] security associations
o A Mobile Node MUST be configured with a Network Access Identifier
or other identity sufficient to obtain mobility service.
Kempf, et al. Expires June 3, 2005 [Page 11]
Internet-Draft BMIP December 2004
6. EAP Considerations
IKE version 2 [6] specifies that when using EAP authentication of the
initiator the responder must have a certificate. There is a draft
[11] discusses how EAP methods that provide mutual authentication and
key agreement can be used for responder authentication instead of
certificates. If this proposal is standardized as an extension of
EAP usage in IKEV2, then boot-strapping process does not need to use
or process certificates. However, for wide scale deployments,
responder authentication using certificates may be more practical.
Kempf, et al. Expires June 3, 2005 [Page 12]
Internet-Draft BMIP December 2004
7. Security Considerations
The protocol uses IKEv2/IPsec and EAP methods for secure exchange of
initial security material exchange and security association. It also
talks about an unique Mobile Node identity to bind with the offered
home addresses and the IPsec/IKE security associations.
Kempf, et al. Expires June 3, 2005 [Page 13]
Internet-Draft BMIP December 2004
8. Protocol Constants
IKE_BMIP_SA_LIFETIME_MAX 1 day
Kempf, et al. Expires June 3, 2005 [Page 14]
Internet-Draft BMIP December 2004
9. Acknowledgments
None so far.
Kempf, et al. Expires June 3, 2005 [Page 15]
Internet-Draft BMIP December 2004
Appendix A. Privacy Considerations
Bootstrapping process can be leveraged to assign a temporary address
[7] to the Mobile Node in addition to the home address. The Home
Agent SHOULD tie these temporary addresses with the same MN-HA tunnel
that is used for home address of the Mobile Node. Thus the Mobile
Node and Home Agent should share the same security associations as
with Home address. The unique identity binding is also useful in
this case. Purpose of having temporary home-address assignment is
that the Mobile Node may use them for some applications as it does in
non- mobile cases for privacy reasons.
Publishing Home Agent addresses publicly in DNS servers may lead to
unwarranted attention from undesirable elements seeking to disrupt
mobility service through DoS attack. While IKEv2 has been carefully
engineered to prevent subtle DoS attacks, such as state depletion, a
brute force DDoS attack can still be mounted. The threat from DDoS
in this case is no larger than for any other widely known public
Internet server, such as a popular Web site or, indeed, a DNS server
for a top level domain. Measures similar to those used by popular
Web site providers or DNS server operators can be deployed to
mitigate such attacks. Note that measures which "hide" Home Agent
addresses by only sending them to authorized nodes through AAA
transactions are not exempt from DDoS attack, because worm-style
probing - in which the attacker sequentially iterates through all
addresses on a subnet - can be used to determine whether a particular
address corresponds to a deployed Home Agent. In IPv6, such probing
attacks are expected to be less effective due to the enormously
enlarged address space, but with enough zombie nodes under their
control, an attacker could still tie up a network.
Kempf, et al. Expires June 3, 2005 [Page 16]
Internet-Draft BMIP December 2004
10. References
10.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[3] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[4] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[5] Devarapalli, V., "Mobile IPv6 Operation with IKEv2 and the
revised IPsec Architecture", draft-ietf-mip6-ikev2-ipsec-00
(work in progress), October 2004.
[6] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-17 (work in progress), October 2004.
10.2 Informative References
[7] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[8] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999.
[9] Kempf, J. and J. Arkko, "The Mobile IPv6 Bootstrapping
Problem", draft-kempf-mip6-bootstrap-00 (work in progress),
March 2004.
[10] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06
(work in progress), July 2004.
[11] Eronen, P., "Extension for EAP Authentication in IKEv2",
draft-eronen-ipsec-ikev2-eap-auth-02 (work in progress),
October 2004.
[12] Giaretta, G., "MIPv6 Authorization and Configuration based on
EAP", draft-giaretta-mip6-authorization-eap-02 (work in
progress), October 2004.
Kempf, et al. Expires June 3, 2005 [Page 17]
Internet-Draft BMIP December 2004
[13] Anton, B., Bullock, B. and J. Short, "Best Current Practices
for Wireless Service Provider (WISP) Roaming", Feb. 2003,
<http://www.wifialliance.org/OpenSection/downloads/wispr_v1.0.p
df>.
Authors' Addresses
James Kempf
DoCoMo Labs USA
181 Metro Drive
Suite 300
San Jose, CA, 95110
USA
Phone: +1 408 451 4711
EMail: kempf@docomolabs-usa.com
Erik Nordmark
Sun Microsystems
17 Network Circle
Menlo Park, CA 95025
USA
Phone: +1 650 786 2921
EMail: erik.nordmark@sun.com
Samita Chakrabarti
Sun Microsystems Inc.
16 Network Circle
Menlo Park, CA 95024
USA
Phone: +1 650 786 5068
EMail: samita.chakrabarti@sun.com
Kempf, et al. Expires June 3, 2005 [Page 18]
Internet-Draft BMIP December 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kempf, et al. Expires June 3, 2005 [Page 19]