One document matched: draft-deng-mip6-bootstrap-bcf-00.txt
INTERNET-DRAFT Hui Deng
<draft-deng-mip6-bootstrap-bcf-00.txt> Hitachi(China)
Date: October 2004 Qin Li
BeiHang University
Chongfeng Xie
China Telecom
Minghui Wang
China Unicom
Bootstrap Control Function mechanism for Mobile IPv6 Bootstrap
draft-deng-mip6-bootstrap-bcf-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
This document specifies a mechanism for Mobile IPv6 bootstrap
procedure. By making a extension of MIP6 specification and using IKE
to guarantee its security, this mechanism bring into a new component
BCF(Bootstrap Control Function) to handle MNí¯s bootstrap procedure
between MN and multiple HAs. Two new bootstrap messages Init and Ack
has been defined to support bootstrap procedure.
Deng, Li, Xie, Wang [Page i]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004
Table of Contents
Status of This Memo ............................................... i
1. Introduction............................................... 1
2. Terminology................................................ 1
3. Architecture overview...................................... 2
4. Detailed Description....................................... 3
4.1 Seed Information....................................... 4
4.2 BCF (Bootstrap Control Function)....................... 4
4.3 Authentication Mechanism............................... 5
4.4 Dynamic Home Address Assignment........................ 5
4.5 Dynamic Home Agent Assignment.......................... 5
4.6 Interface between HA and BCF........................... 6
5. Detailed Message Format.................................... 6
5.1 MIPv6 Bootstrap Init Message Type...................... 6
5.1.1 Mobile Header Type............................... 6
5.1.2 Message Format................................... 6
5.2 MIPv6 Bootstrap Acknowledgement Message Type........... 7
5.2.1 Mobile Header Type............................... 7
5.2.2 Message Format................................... 7
5.3 Mobile Node Considerations............................. 8
5.4 Bootstrap Control Function Considerations.............. 8
5.5 Processing Considerations.............................. 8
6. Performance Implication in Wireless Networks............... 9
7. IANA Considerations........................................ 9
8. Security Considerations.................................... 9
9. Acknowledgements........................................... 9
References.................................................10
Authors' Addresses.........................................11
Intellectual Property and Copyright Statements.............12
Deng, Li, Xie, Wang [Page ii]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004
1. Introduction
Mobile IPv6 [5] bootstrap [2] problem is about how to transfer MN's
home address, Home Agent address, and security association between
MN and HA.
Current solution [7, 8] is mainly based on IASP scenario. These
solutions are more applicable to the scenario which integrates the
network access authentication with MIP6 bootstrap procedure. However
MSP scenario might be more suitable for the current network operator
since most network operator would like to separate the network access
and MIP6 service management. For example, China Telecom and China
Unicom consider separating initiation of mobility service with that
of network access during their deployment plan.
The protocol discussed later is applicable in a scenario where the
ASP and the MSP is different provider as defined in [2]. By just
making a small extension of MIP6 specification and using IKE to
guarantee its security, this protocol bring into a new component BCF
(Bootstrap Control Function) to handle MNí¯s bootstrap procedure
between MN and multiple HAs. Bootstrap procedure can be realised by
Home Agent Handover message defined in [3] as well as two new
bootstrap messages and defined in this solution.
2. Terminology
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in RFC 2119 [1].
General mobility terminology can be found in [6]. The following
Additional terms related to bootstrap problem of Mobile IPv6 are
used here:
ASP Access Service Provider
IASP Integrated Access Service Provider
MSP Mobility Service Provider
AAA Authentication Authorization Accounting
BCF Bootstrap Control Function
NAI Network Acesss Indentifier
BoI Bootstrap Init Message
Deng, Li, Xie, Wang [Page 1]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004
BoA Bootstrap Acknowledge Message
HAH Home Agent Handover Message
3. Architecture overview
Visited Network | Home Network
|
|
| +-------+
| | AAA | +-------+
| +-------+ +--------| HA1 |
| | | +-------+
| | |
| | |
+------+ | +-------+ | +-------+
| MN |<--------|-------->| BCF |---+--------| HA2 |
+------+ | +-------+ | +-------+
| | ...
| |
| | +-------+
| +--------| HAn |
| +-------+
Figure 1. Architecture
Figure 1 shows the network architecture of our proposed solution.
Based on this architecture, MN send Mobile IPv6 Bootstrap Init
message to a conceptual entity, called Bootstrap Control Function,
the BoI message consists of NAI option, mobility message
identification option and authentication option. BCF then athenticate
this BoI message with the help of AAA for Mobility Service, and can
assign a HoA, HA to the MN. BCF will response with a Mobile IPv6
Bootstrap Ack messages back to the MN which convey the MN's assigned
HoA and HA.
Deng, Li, Xie, Wang [Page 2]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004
4. Detailed Description
MN +-----------------+ BCF +------------+ AAA +--+ HA1 HA2 HAn
| | |
| ------------------\ | |
(1)| BoI with \ | |
| auth & nai & id / | |
| ------------------/ | |
| | (2) |
| | /------------\ |
| | / authenticate \ |
| | \ with AAA / |
| | \------------/ |
| |
| + +
| | (3) |
| + +
| |
| /------------------ |
(4)| / BoA with |
| \ HoA & auth option |
| \------------------ |
| |
| /------------------ |
(5)| / HAH message |
| \ defined in [3] |
| \------------------ |
| |
(6) /----------------------------------------------\
/ MIPv6 Binding Update \
\ & Binding ckowledgement /
\----------------------------------------------/
Figure 2. Operational Flow
Figure 3 shows an overview of the procedure defined to handle MIPv6
bootstrap for both MN and HAs. The whole bootstrap procedure can be
divided in five steps, and the sixth step is the first Binding
Update/Binding Ackowledgement messages between MN and selected HA:
1. This is a bootstrap init message initiated by MN. This BoI MUST
include NAI option, mobility message identification option and
authentication option.
Deng, Li, Xie, Wang [Page 3]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004
2. The HA SHOULD extract MN-AAA authenticator, SPI[12] and the NAI
from BoI message, generate AAA specific AVPs, and initiate the
authentication procedure via AAA infrastructure.
3. After sucessfully athentication with AAA, BCF should do two
things. The first one is to assign a HA for MN based on load balance
information. The second one is to allocate either stateful or
stateless HoA for MN, BCF MUST do a DAD check for the allocated HoA
in home network.
4. BCF replies a Bootstrap Acknowledge message to MN. This BoA
message MUST include HoA option, and also mobility message
identification option and authentication option.
5. BCF replies a Home Agent Handover message [3] indicate the
selected HA to MN. MN can extract HA address from HAH message. This
step is the last bootstrap message of the whole procedure.
6. MN send the first BU message to the assigned HA. The HoA, HA
address are provisioned in above bootstrap process. There are two
authentication mechanism that can be applied to the BU message, as
discussed in section 4.3
4.1 Seed Information
In this bootstrap solution for an independent MSP, Bootstrap seed
information is Mobility Service credential and related parameters, no
nework access credential is needed. The seed information includes:
1. Host Identifier of BCF for MN to bootstrap from, that is,
domain name, FQDN, or at least IP address of BCF host.
2. AAA credential for mutual authentication between MN and the BCF:
a. Network access indentifier for mobility service
b. Preshared secret between MN and AAA of Mobility Service
4.2 BCF (Bootstrap Control Function)
In this solution, BCF and multiple HAs are under the same
administrative domain. BCF and multiple HA should share a
preconfigured trust relationship. Though the router advertisement
message, BCF can get the load information of multiple HAs. When
receiving BoI from MN, BCF will allocate a HA for MN based on those
information.
Deng, Li, Xie, Wang [Page 4]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004
Besides router advertisement message, BCF can also send Router
Solicitation message to HA to get modified Home Agent List
information.
BCF will handle the bootstrap init message sent from MN, and allocate
a HA and a HoA for MN. BCF will use HA handover mechanism to redirect
a new HA for MN based on the solution defined in [3].
4.3 Authentication Mechanism
Athentication mechanism that can be applied in bootstrap signals
between MN and BCF in this solution is Mobile IPv6 Authencation
Protocol defined in [12] where MN-AAA authentication mobility option
MUST be used in BoI message.
In this solution, there are two kinds of athentication mechanism that
can be applied in Binding Update message between MN and HA after
a bootstrap procedure take place.
The first one is IPSec + IKEv2. In this case, IKEv2 of MN and HA
should support host authentication under AAA infrastructure. And the
bootstrap credential of MN is also used as the IKE credential for
mutual authentication between MN and HA. After bootstrap, MN will get
the assgined HA address from BCF. Before MN send the first BU message
to HA, an IKEv2 session will be established based on the AAA
credential, and the result is IPSec SA negotiated to protect the BU
message.
The second one is also the Mobile IPv6 Authencation Protocol. In this
case, MN could send the binding update message to HA with MN-AAA
authentication mobility option, NAI option, and message
indentification option as defined in [12].
4.4 Dynamic Home Address Assignment
Before BCF assign a HoA to MN, BCF will using DAD (Duplicate Address
Detection) in the home network. After DAD checking, BCF will response
a bootstrap acknowledgement message with an option for assigning MNí¯s
HoA.
4.5 Dynamic Home Agent Assignment
Here we can use HA load balance mechanism [3] for dynamic home agent
assignment. Since MIP6 HA are not only responsible for the
Deng, Li, Xie, Wang [Page 5]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004
registration of MN, but also tunneling the data packets to the MN
even if there will be router optimization. Because each home agent
have to maintains a separate HA list for each link, by extending this
home agent list and modifying router advertisement message, load
balance mechanism among multiple Has will be supported. BCF can
assign a HA for MN based on this dynamical load balance mechanism
among multiple HAs.
4.6 Interface between HA and BCF
Router advertisement message has been used among multiple HAs.
5. Detailed Message Format
5.1 MIPv6 Bootstrap Init Message
5.1.1 Mobile Header Type
BOOTSTRAP-INIT-TYPE to be defined by IANA. An 8-bit identifier of
the type mobility header.
5.1.2 Message Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence #
A 16-bit unsigned integer used by the Bootstrap Control Function
to sequence Bootstrap Init message and by the mobile node to match
a returned Boostrap Acknowledgement with this Bootstrap Init.
Deng, Li, Xie, Wang [Page 6]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004
Reserved
These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
5.2 MIPv6 Bootstrap Acknowledgement Message
5.2.1 Mobile Header Type
BOOTSTRAP-ACK-TYPE to be defined by IANA. An 8-bit identifier of the
type mobility header.
5.2.2 Message Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence #
The Sequence Number in the Bootstrap Acknowledgement is copied
from the Sequence Number field in the Bootstrap Acknowledgement
with an outstanding bootstrap.
Status
8-bit unsigned integer indicating the disposition of the
Bootstrap.
MIPV6-BOOTSTRAP-SUCCESS 0
MIPV6-BOOTSTRAP-BADCRED 127
MIPV6-BOOTSTRAP-ID-MISMATCH 126
Deng, Li, Xie, Wang [Page 7]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004
Reserved
These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
5.3 Mobile Node Considerations
MN must send Bootstrap Init message with MN-AAA mobility message
authentication option (defined in section 6 of [12], subtype value
is 2), mobility message identification option (define in section 7
of [12]). The MN SHOULD use NAI option to enable the BCF to make use
of available AAA infrastructure which requires NAI. (defined in
[10]).
5.4 Bootstrap Control Function Considerations
BCF must send Bootstrap Acknowledge message with MN-AAA mobility
message authentication option (defined in section 6 of [12], subtype
value is 2), mobility message identification option (define in
section 7 of [12]).
BoA message MUST include HoA option and status code of MIPV6-
BOOTSRAP-SUCCESS if the MN is authenticated by AAA server. Otherwise,
an error result code MUST be given in status field of BoA message to
indicate the reason as defined in section 5.5
5.5 Processing Considerations
Mobility message identification option in BoI MUST be verified by
BCF, to asure that the message has been generated recently by the MN,
and it is not replayed by an attacker from some older BoI message. If
this verification failed, BCF MUST send a Bootstrap Acknowledgement
with error code MIPV6-BOOTSRAP-ID-MISMATCH in status field.
The MN-AAA authentication mobility option MUST be verified by the AAA
infrastructure that has the shared secret with the MN. The HA relays
the authenticating information to the HAAA. The HA relies on the
Home AAA for Mobility Service to admit or reject the home regis-
tration request from the MN. If authentication failed, BCF MUST send
a Bootstrap Acknowledgement with error code MIPV6-BOOTSRAP-BADCRED in
status field.
Deng, Li, Xie, Wang [Page 8]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004
6. Performance Implication in Wireless Networks
By bringing into two new Mobile IPv6 message, and Handover message,
this mechanism will not bring signal burdern to wireless network.
BCF will act as the anchor point for multiple home agents, it
also reduce some signal message among home network.
7. IANA Considerations
This document defines two new messages type for bootstrap,
o New Mobile Header Type, Bootstrap Init message, described in
section 5.1
o New Mobile Header Type, Bootstrap Acknowledge message, described
in section 5.2
8. Security Considerations
This document described a AAA mechanism to guarantee security among
MN, BCF, HA, and AAA by bring into a new component BCF to handle
security association with MN on behalf of the AAA and multiple home
agents during bootstrap procedure. whether the message between MN
and BCF should be encrypted or not will be considered in the near
future
9. Acknowledgements
The authors would like to thank many kindly comments.
Deng, Li, Xie, Wang [Page 9]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004
References
[1] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Patel, A. et al. "Problem Statement for bootstrapping Mobile
IPv6", draft-ietf-mip6-bootstrap-ps-00 (work in progress), July
2004.
[3] Hui Deng, et al. "Load Balance for Distributed Home Agents in
Mobile IPv6", draft-deng-mip6-ha-loadbalance-02(work in
progress), October 2004.
[4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[5] J. Arkko, et al. "Using IPsec to Protect Mobile IPv6 Signaling
Between Mobile Nodes and Home Agents", RFC3776, June 2004.
[6] Manner, J., Kojo, M. "Mobility Related Terminology", RFC 3753,
June 2004.
[7] G. Giaretta, et al. "MIPv6 Authorization and Configuration
based on EAP", draft-giaretta-mip6-authorization-eap-01.txt
[8] K. Chowdhury , et al., "RADIUS Attributes for Mobile IPv6
bootstrapping", draft-chowdhury-mip6-bootstrap-radius-00.txt
[9] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[10] Patel, A., Leung, K., Akthar, H., Khalil, M. and K. Chowdhury,
"Network Access Identifier Option for Mobile IPv6",
draft-ietf-mip6-nai-option-00 (work in progress), July
2004.
[11] T. Kivinen, "Design of the MOBIKE protocol",
draft-ietf-mobike-design-00 (work in progress), June 2004.
[12] A. Patel, et al. "Authentication Protocol for Mobile IPv6",
draft-ietf-mip6-auth-protocol-00.txt
Deng, Li, Xie, Wang [Page 10]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 2004
Authors' Addresses
Hui Deng
Research & Development Center
Hitachi (China), Investment Ltd.
Beijing Fortune Bldg. 1701, 5 Dong San Huan Bei-Lu
Chao Yang District, Beijing 100004, China
E-mail: hdeng@hitachi.cn
Qin Li
Department of Computer Science
BeiHang University
Beijing 100083, China
Email: lynch@vmails.net
Chongfeng Xie
Beijing Research Institute
China Telecom
Beijing 100035, China
Email: xiechf@ctbri.com.cn
Minghui Wang
Department of Technology
China Unicom
Beijing 100032, China
Email: wangmh@chinaunicom.com.cn
Deng, Li, Xie, Wang [Page 11]
INTERNET-DRAFT BCF Bootstrap for Mobile IPv6 October 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.
Deng, Li, Xie, Wang [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 01:11:05 |