draft-ietf-mip6-bootstrap-ps-02.txt   draft-ietf-mip6-bootstrap-ps-03.txt 
MIP6 A. Patel, Editor MIP6 A. Patel, Editor
Internet-Draft Cisco Internet-Draft Cisco
Expires: September 16, 2005 March 18, 2005 Expires: January 15, 2006 July 14, 2005
Problem Statement for bootstrapping Mobile IPv6 Problem Statement for bootstrapping Mobile IPv6
draft-ietf-mip6-bootstrap-ps-02.txt draft-ietf-mip6-bootstrap-ps-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 16, 2005. This Internet-Draft will expire on January 15, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
A mobile node needs at least the following information: a home A mobile node needs at least the following information: a home
address, home agent address and a security association with home address, home agent address and a security association with home
agent to register with the home agent. The process of obtaining this agent to register with the home agent. The process of obtaining this
information is called bootstrapping. This document discuss the information is called bootstrapping. This document discuss the
issues involved with how the mobile node can be bootstrapped for issues involved with how the mobile node can be bootstrapped for
Mobile IPv6 and various potential deployment scenarios for Mobile IPv6 and various potential deployment scenarios for
bootstrapping the mobile node. bootstrapping the mobile node.
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1.2 What is Bootstrapping? . . . . . . . . . . . . . . . . . . 4 1.2 What is Bootstrapping? . . . . . . . . . . . . . . . . . . 4
1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Motivation for bootstrapping . . . . . . . . . . . . . . . . . 10 5. Motivation for bootstrapping . . . . . . . . . . . . . . . . . 10
5.1 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1 Dynamic Home Address Assignment . . . . . . . . . . . 10 5.1.1 Dynamic Home Address Assignment . . . . . . . . . . . 10
5.1.2 Dynamic Home Agent Assignment . . . . . . . . . . . . 11 5.1.2 Dynamic Home Agent Assignment . . . . . . . . . . . . 11
5.1.3 Management requirements . . . . . . . . . . . . . . . 12 5.1.3 Management requirements . . . . . . . . . . . . . . . 12
5.2 Security Infrastructure . . . . . . . . . . . . . . . . . 12 5.2 Security Infrastructure . . . . . . . . . . . . . . . . . 13
5.2.1 Integration with AAA Infrastructure . . . . . . . . . 12 5.2.1 Integration with AAA Infrastructure . . . . . . . . . 13
5.2.2 "Opportunistic" or "Local" Discovery . . . . . . . . . 13 5.2.2 "Opportunistic" or "Local" Discovery . . . . . . . . . 13
5.3 Topology Change . . . . . . . . . . . . . . . . . . . . . 13 5.3 Topology Change . . . . . . . . . . . . . . . . . . . . . 13
5.3.1 Dormant Mode Mobile Nodes . . . . . . . . . . . . . . 13 5.3.1 Dormant Mode Mobile Nodes . . . . . . . . . . . . . . 13
6. Network Access and Mobility services . . . . . . . . . . . . . 14 6. Network Access and Mobility services . . . . . . . . . . . . . 15
7. Deployment scenarios . . . . . . . . . . . . . . . . . . . . . 16 7. Deployment scenarios . . . . . . . . . . . . . . . . . . . . . 17
7.1 Mobility Service Subscription Scenario . . . . . . . . . . 16 7.1 Mobility Service Subscription Scenario . . . . . . . . . . 17
7.2 Integrated ASP network scenario . . . . . . . . . . . . . 16 7.2 Integrated ASP network scenario . . . . . . . . . . . . . 17
7.3 Third party MSP scenario . . . . . . . . . . . . . . . . . 17 7.3 Third party MSP scenario . . . . . . . . . . . . . . . . . 18
7.4 Infrastructure-less scenario . . . . . . . . . . . . . . . 18 7.4 Infrastructure-less scenario . . . . . . . . . . . . . . . 19
8. Parameters for authentication . . . . . . . . . . . . . . . . 19 8. Parameters for authentication . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.1 Security Requirements of Mobile IPv6 . . . . . . . . . . . 21 9.1 Security Requirements of Mobile IPv6 . . . . . . . . . . . 22
9.2 Threats to the Bootstrapping Process . . . . . . . . . . . 22 9.2 Threats to the Bootstrapping Process . . . . . . . . . . . 23
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 24 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27
12.1 Normative References . . . . . . . . . . . . . . . . . . . . 25 13. IPR Disclosure Acknowledgement . . . . . . . . . . . . . . . 28
12.2 Informative References . . . . . . . . . . . . . . . . . . . 25 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 26 14.1 Normative References . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . 27 14.2 Informative References . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . 31
1. Introduction 1. Introduction
Mobile IPv6 [RFC3775] specifies mobility support based on the Mobile IPv6 [RFC3775] specifies mobility support based on the
assumption that a mobile node has a trust relationship with an entity assumption that a mobile node has a trust relationship with an entity
called the home agent. Once the home agent address has been learned called the home agent. Once the home agent address has been learned
for example via manual configuration, via anycast discovery for example via manual configuration, via anycast discovery
mechanisms, via DNS lookup; Mobile IPv6 signaling messages between mechanisms, via DNS lookup; Mobile IPv6 signaling messages between
the mobile node and the home agent are secured with IPsec or the mobile node and the home agent are secured with IPsec or
authentication protocol [I-D.ietf-mip6-mn-auth-protocol-02]. The authentication protocol [I-D.ietf-mip6-mn-auth-protocol-02]. The
skipping to change at page 4, line 41 skipping to change at page 4, line 43
form of signalling) to do so etc. form of signalling) to do so etc.
Also, in certain scenarios, after the MN bootstraps for the first Also, in certain scenarios, after the MN bootstraps for the first
time (out of the box), subsequent bootstrapping is implementation time (out of the box), subsequent bootstrapping is implementation
dependent. For instance, the MN may bootstrap everytime it boots, dependent. For instance, the MN may bootstrap everytime it boots,
bootstrap everytime on prefix change, bootstrap periodically to bootstrap everytime on prefix change, bootstrap periodically to
anchor to an optimal (distance, load etc) HA, etc. anchor to an optimal (distance, load etc) HA, etc.
1.3 Terminology 1.3 Terminology
General mobility terminology can be found in General mobility terminology can be found in [I-D.ietf-seamoby-
[I-D.ietf-seamoby-mobility]. The following additional terms are used mobility]. The following additional terms are used here:
here:
Trust relationship Trust relationship
In the context of this draft, trust relationship means that two In the context of this draft, trust relationship means that two
parties in question, typically the user of the mobile host and the parties in question, typically the user of the mobile host and the
mobility or access service provider, have some sort of prior mobility or access service provider, have some sort of prior
contact in which the mobile host was provisioned with credentials. contact in which the mobile host was provisioned with credentials.
These credentials allow the mobile host to authenticate itself to These credentials allow the mobile host to authenticate itself to
the mobility or access service authorizer and to prove its the mobility or access service authorizer and to prove its
authorization to obtain service. authorization to obtain service.
skipping to change at page 16, line 32 skipping to change at page 17, line 34
Many commercial deployments are based on the assumption that mobile Many commercial deployments are based on the assumption that mobile
nodes have a subscription with a service provider. In particular, in nodes have a subscription with a service provider. In particular, in
this scenario the MN has a subscription with an MSP, called the home this scenario the MN has a subscription with an MSP, called the home
MSP, for Mobile IPv6 service. As stated in Section 6, the MSP is MSP, for Mobile IPv6 service. As stated in Section 6, the MSP is
responsible of setting up a home agent on a subnet that acts as a responsible of setting up a home agent on a subnet that acts as a
Mobile IPv6 home link. As a consequence, the home MSP should Mobile IPv6 home link. As a consequence, the home MSP should
explicitly authorize and control the whole bootstrapping procedure. explicitly authorize and control the whole bootstrapping procedure.
Since the MN is assumed to have a pre-established trust relationship Since the MN is assumed to have a pre-established trust relationship
with its home provider, it must be configured with an identity and with its home provider, it must be configured with an identity and
credentials, for instance an NAI and a shared secret by some credentials, for instance an NAI and a shared secret by some out-of-
out-of-band means before bootstrapping, for example by manual band means before bootstrapping, for example by manual configuration.
configuration.
In order to guarantee ubiquitous service, the MN should be able to In order to guarantee ubiquitous service, the MN should be able to
bootstrap MIPv6 operations with its home MSP from any possible access bootstrap MIPv6 operations with its home MSP from any possible access
location, such as an open network or a network managed by an ASP, location, such as an open network or a network managed by an ASP,
that may be different from the MSP and may not have any that may be different from the MSP and may not have any pre-
pre-established trust relationship with it. established trust relationship with it.
7.2 Integrated ASP network scenario 7.2 Integrated ASP network scenario
In this scenario, the ASP and MSP are the same ASP. MN shares In this scenario, the ASP and MSP are the same ASP. MN shares
security credentials for access to the network and these credentials security credentials for access to the network and these credentials
can be used to bootstrap MIPv6. This bootstrapping can be done can be used to bootstrap MIPv6. This bootstrapping can be done
during the same phase as access authentication/authorization or at a during the same phase as access authentication/authorization or at a
later time (probably based on some state created during access later time (probably based on some state created during access
authentication/authorization). authentication/authorization).
skipping to change at page 23, line 5 skipping to change at page 25, line 5
network access authentication are separate services, keys generated network access authentication are separate services, keys generated
for these services need to be cryptographically separate, separately for these services need to be cryptographically separate, separately
named, and have separate lifetimes, including if the keys are named, and have separate lifetimes, including if the keys are
generated from the same authentication credentials This is necessary generated from the same authentication credentials This is necessary
because a mobile host must be able to move from one serving (or because a mobile host must be able to move from one serving (or
roaming) network access provider to another without needing to change roaming) network access provider to another without needing to change
its mobility access provider. Finally, basic cryptographic processes its mobility access provider. Finally, basic cryptographic processes
must provide for multiple algorithms in order to accommodate the must provide for multiple algorithms in order to accommodate the
widely varying deployment needs. widely varying deployment needs.
10. Contributors 10. IANA Considerations
No new protocol numbers are required.
11. Contributors
This contribution is a joint effort of the problem statement design This contribution is a joint effort of the problem statement design
team of the Mobile IPv6 WG. The contributors include Basavaraj team of the Mobile IPv6 WG. The contributors include Basavaraj
Patil, Gerardo Giaretta, Jari Arkko, James Kempf, Yoshihiro Ohba, Patil, Gerardo Giaretta, Jari Arkko, James Kempf, Yoshihiro Ohba,
Ryuji Wakikawa, Hiroyuki Ohnishi, Mayumi Yanagiya Samita Chakrabarti, Ryuji Wakikawa, Hiroyuki Ohnishi, Mayumi Yanagiya Samita Chakrabarti,
Gopal Dommety, Kent Leung, Alper Yegin, Hannes Tschofenig, Vijay Gopal Dommety, Kent Leung, Alper Yegin, Hannes Tschofenig, Vijay
Devarapalli, Kuntal Chowdury. Devarapalli, Kuntal Chowdury.
The design team members can be reached at: The design team members can be reached at:
skipping to change at page 24, line 5 skipping to change at page 27, line 5
Kent Leung kleung@cisco.com Kent Leung kleung@cisco.com
Alper Yegin alper.yegin@samsung.com Alper Yegin alper.yegin@samsung.com
Hannes Tschofenig hannes.tschofenig@siemens.com Hannes Tschofenig hannes.tschofenig@siemens.com
Vijay Devarapalli vijayd@iprg.nokia.com Vijay Devarapalli vijayd@iprg.nokia.com
Kuntal Chowdury kchowdury@starentnetworks.com Kuntal Chowdury kchowdury@starentnetworks.com
11. Acknowledgments 12. Acknowledgments
Special thanks to James Kempf and Jari Arkko for writing the initial Special thanks to James Kempf and Jari Arkko for writing the initial
version of the bootstrapping statement. Thanks to John Loughney for version of the bootstrapping statement. Thanks to John Loughney for
a detailed editorial review. a detailed editorial review.
12. References 13. IPR Disclosure Acknowledgement
12.1 Normative References 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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
14. References
14.1 Normative References
[I-D.ietf-mip6-mn-auth-protocol-02] [I-D.ietf-mip6-mn-auth-protocol-02]
Patel et. al., A., "Authentication Protocol for Mobile Patel et. al., A., "Authentication Protocol for Mobile
IPv6", draft-ietf-mip6-auth-protocol-02.txt (work in IPv6", draft-ietf-mip6-auth-protocol-02.txt (work in
progress), November 2004, progress), November 2004,
<draft-ietf-mip6-auth-protocol-02.txt>.
<http://www.ietf.org/internet-drafts/draft-ietf-mip6-auth-protocol-02.txt>
.
[I-D.ietf-seamoby-mobility] [I-D.ietf-seamoby-mobility]
Manner, J. and M. Kojo, "Mobility Related Terminology", Manner, J. and M. Kojo, "Mobility Related Terminology",
draft-ietf-seamoby-mobility-terminology-06 (work in draft-ietf-seamoby-mobility-terminology-06 (work in
progress), February 2004, progress), February 2004,
<draft-ietf-seamoby-mobility-terminology-06.txt>.
<http://www.ietf.org/internet-drafts/draft-ietf-seamoby-mobility-terminology
-06.txt>
.
[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC 2794, March 2000. Identifier Extension for IPv4", RFC 2794, March 2000.
[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC3776] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, June 2004. Home Agents", RFC 3776, June 2004.
12.2 Informative References 14.2 Informative References
[2284bis] Levkowetz, Ed., H., "Extensible Authentication Protocol [2284bis] Levkowetz, Ed., H., "Extensible Authentication Protocol
(EAP)", February 2004, (EAP)", February 2004, <draft-ietf-eap-rfc2284bis-09.txt>.
<http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-09.txt>
.
[I-D.giaretta-mip6-authorization-eap] [I-D.giaretta-mip6-authorization-eap]
Giaretta, G., "MIPv6 Authorization and Configuration based Giaretta, G., "MIPv6 Authorization and Configuration based
on EAP", draft-giaretta-mip6-authorization-eap-00 (work in on EAP", draft-giaretta-mip6-authorization-eap-00 (work in
progress), February 2004, progress), February 2004,
<draft-giaretta-mip6-authorization-eap-00.txt>.
<http://www.ietf.org/internet-drafts/draft-giaretta-mip6-authorization-eap-0
0.txt>
.
[I-D.ietf-mip6-mn-ident-option-02] [I-D.ietf-mip6-mn-ident-option-02]
Patel, A., Leung, K., Akthar, H., Khalil, M. and K. Patel, A., Leung, K., Akthar, H., Khalil, M., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile Chowdhury, "Mobile Node Identifier Option for Mobile
IPv6", draft-ietf-mip6-mn-ident-option-02.txt (work in IPv6", draft-ietf-mip6-mn-ident-option-02.txt (work in
progress), February 2004, progress), February 2004,
<draft-ietf-mip6-mn-ident-option-02.txt>.
<http://www.ietf.org/internet-drafts/draft-ietf-mip6-mn-ident-option-02.txt>
.
[I-D.kempf-mip6-bootstrap] [I-D.kempf-mip6-bootstrap]
Kempf, J. and J. Arkko, "The Mobile IPv6 Bootstrapping Kempf, J. and J. Arkko, "The Mobile IPv6 Bootstrapping
Problem", draft-kempf-mip6-bootstrap-00 (work in Problem", draft-kempf-mip6-bootstrap-00 (work in
progress), March 2004, progress), March 2004,
<draft-kempf-mip6-bootstrap-00.txt>.
<http://www.ietf.org/internet-drafts/draft-kempf-mip6-bootstrap-00.txt>
.
[I-D.mariblanca-aaa-eap-lla-00] [I-D.mariblanca-aaa-eap-lla-00]
Mariblanca, D., "EAP lower layer attributes for AAA Mariblanca, D., "EAP lower layer attributes for AAA
protocols", May 2004, protocols", May 2004,
<draft-mariblanca-aaa-eap-lla-00.txt>.
<http://www.ietf.org/internet-drafts/draft-mariblanca-aaa-eap-lla-00.txt>
.
[I-D.rosec] [I-D.rosec]
Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E. Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP version 6 Route Optimization Security Nordmark, "Mobile IP version 6 Route Optimization Security
Design Background", draft-ietf-mip6-ro-sec-02 (work in Design Background", draft-ietf-mip6-ro-sec-02 (work in
progress), October 2004, progress), October 2004, <draft-ietf-mip6-ro-sec-02.txt>.
<http://www.ietf.org/internet-drafts/draft-ietf-mip6-ro-sec-02.txt>
.
[eap_keying] [eap_keying]
Aboba et. al., B., "Extensible Authentication Protocol Aboba et. al., B., "Extensible Authentication Protocol
(EAP) Key Management Framework", (EAP) Key Management Framework",
draft-ietf-eap-keying-05.txt (work in progress), February draft-ietf-eap-keying-05.txt (work in progress),
2005, February 2005, <draft-ietf-eap-keying-05.txt>.
<http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-05.txt>
.
Author's Address Author's Address
Alpesh Patel Alpesh Patel
Cisco Cisco
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 853 9580 Phone: +1 408 853 9580
EMail: alpesh@cisco.com Email: alpesh@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/