One document matched: draft-ohba-mip6-boot-arch-dhcp-00.txt
MIP6 Working Group Y. Ohba
Internet-Draft TARI
Expires: April 17, 2005 R. Lopez
Univ. of Murcia
M. Yanagiya
H. Ohnishi
NTT
K. Chowdhury
Nortel Networks
October 17, 2004
Mobile IPv6 Bootstrapping Architecture Using DHCP
draft-ohba-mip6-boot-arch-dhcp-00
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.
This Internet-Draft will expire on April 17, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
A mobile node needs home address, home agent address and security
association with home agent to register with the home agent. The
process of obtaining this information is called bootstrapping. This
Ohba, et al. Expires April 17, 2005 [Page 1]
Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004
document describes a bootstrapping architecture in which there is
some dependency between AAA for network access and AAA for mobility
service and DHCP in the visited network is used for carrying Mobile
IPv6 bootstrap information to the mobile node. The architecture is
based on an assumption that the mobile node uses network access
credentials as the seed information without a need to pre-configure
any Mobile IPv6 service parameters.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Basic Architecture . . . . . . . . . . . . . . . . . . . . . . 4
3. Model 1: NAS as a AAA Client for Mobility Service . . . . . . 6
3.1 Integrated ASP Scenario . . . . . . . . . . . . . . . . . 9
3.2 Third Party MSP Scenario . . . . . . . . . . . . . . . . . 10
4. Model 2: NAS as a AAA Client for MIP6 Service . . . . . . . . 12
4.1 Integrated ASP Scenario . . . . . . . . . . . . . . . . . 13
4.2 Third Party MSP Scenario . . . . . . . . . . . . . . . . . 14
5. Comparison with Other Bootstrapping Architectures . . . . . . 15
5.1 Home Agent as NAS for AAA for Mobility Service . . . . . . 15
5.2 MIPv6 Authorization and Configuration based on EAP . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 18
8.2 Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 20
Ohba, et al. Expires April 17, 2005 [Page 2]
Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004
1. Introduction
A mobile node needs home address, home agent address and security
association with home agent to register with the home agent. The
process of obtaining this information is called bootstrapping
[I-D.ietf-mip6-bootstrap-ps]. Two minimal sets of parameters or seed
information with which the mobile node is expected to configure prior
to bootstrap the rest of the parameters as well as possible
deployment scenarios where bootstrapping deems necessary are also
defined in [I-D.ietf-mip6-bootstrap-ps].
It is important for a bootstrapping architecture to be integrated
with AAA (Authentication, Authorization and Accounting)
infrastructure considering large-scale deployment where operators
rely on a AAA protocol such as RADIUS for providing authentication,
authorization and accounting functionalities for their subscribers of
services. Such services include network access and mobility service.
This document describes a bootstrapping architecture in which there
is some dependency between AAA for network access and AAA for
mobility service and DHCP in the visited network is used for carrying
Mobile IPv6 bootstrap information to the mobile node. The
architecture is based on an assumption that the mobile node uses
network access credentials as the seed information without a need to
pre-configure any Mobile IPv6 service parameters. This document also
discusses how the proposed architecture is mapped to several
deployment scenarios described in [I-D.ietf-mip6-bootstrap-ps]. The
deployment scenarios discussed in this document are integrated ASP
network scenario and third party MSP scenario. Other deployment
scenarios, namely mobility service subscription scenario and
infrastructure-less scenario, are not discussed in this document
since it appears that those scenarios are used when AAA for mobility
service is independent of AAA for network access.
There are two other bootstrapping architectures that are developed
based on different assumptions. One architecture is defined for the
case where the mobile node is aware of its home agent address
[I-D.yegin-mip6-aaa-fwk] by some means. Another architecture is
based on an assumption that there is some dependency between AAA for
network access and AAA for mobility service and EAP [RFC3748] is used
for carrying Mobile IPv6 bootstrap information to the mobile node
[I-D.giaretta-mip6-authorization-eap]. Comparison with those two
bootstrapping architectures is also provided in this document.
Ohba, et al. Expires April 17, 2005 [Page 3]
Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004
2. Basic Architecture
|
ASP or IASP | Serving or Home MSP
|
+-------+ | +-------+
| |------------|--------| |
|AAA-NA | | |AAA-MS |
|Server |-----+ | |Server |
+-------+ | | +-------+
| | | |
| | | |
| +------+ | |
| | DHCP | | |
| +--|Server| | |
| | +------+ | -----------------------
| | | | | Serving MSP
+------+ +------+ | | +------+
|Mobile| | NAS | | | | Home |
|Node/ |---------| | | | | Agent|
|DHCP | +------+ | | +------+
|Client|---------------------+ |
+------+
Figure 1: The Basic Architecture for Bootstrapping MIP6 via DHCP
In the typical Mobile IPv6 access scenario as shown above, the mobile
node attaches in an Access Service Provider's (ASP) network. During
this attach procedure, the NAS authenticates and authorizes the
mobile node for IPv6 access service. In the scenario shown, the
authentication and authorization happens via a AAA infrastructure.
In the architecture shown above the mobile node acquires the Mobile
IPv6 bootstrap information using Parameter Set 2 as the seed
information as described in [I-D.ietf-mip6-bootstrap-ps].
There are two models described in this document. The first model
termed as Model 1, shows how the mobile node performs Mobile IPv6
bootstrapping operation using a DHCP server as the AAA client. The
DHCP server receives the Mobile IPv6 bootstrap information such as a
home agent address, a home link prefix information from the AAA-MS
(AAA for Mobility Service) server in the home Mobility Service
Provider (MSP) via the AAA-NA (AAA for Network Access) server in the
ASP. The AAA-MS server may also send the delayed authentication key
to the DHCP server for DHCP authentication [RFC3118]. The details of
the procedures and call flows are described in Section 3 of this
document.
In the second model termed as Model 2, the NAS authenticates and
Ohba, et al. Expires April 17, 2005 [Page 4]
Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004
authorizes the mobile node via the AAA infrastructure. The mobile
node still uses Parameter Set 2 as defined in
[I-D.ietf-mip6-bootstrap-ps]. The NAS receives the Mobile IPv6
bootstrap information from the AAA-MS server in the home MSP via the
AAA-NA server in the ASP. The NAS forwards the received Mobile IPv6
bootstrap information along with any delayed authentication parameter
such as the shared secret for the authenticator calculation [RFC3118]
to the DHCP server. In this model, the NAS acts as the authorization
delegation point as described in
[I-D.ohba-aaaarch-authorization-delegation]. The mobile node
acquires the Mobile IPv6 bootstrap information from the DHCP server
via the normal DHCPv6 procedures with optional delayed authentication
option. The details of the procedures involved in Model 2 is
described in Section 4 of this document.
Ohba, et al. Expires April 17, 2005 [Page 5]
Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004
3. Model 1: NAS as a AAA Client for Mobility Service
In this model, the DHCPv6 server acts as a AAA client for mobility
service. In this model, AAA for mobility service is used not only
for retrieving Mobile IPv6 bootstrap information but also DHCPv6
delayed authentication keys from the AAA infrastructure. A home
address is assigned to the mobile node either through DHCPv6 or
through IKE.
Network Access
Client Authentication
+-------+ Protocol AAA-NA --------------
|Network--------------- NAS ----------------- ( )
|Access | ( )
|Client | ( )
| | | ( AAA )
| |DHCP |DHCPv6 (Infrastructure)
| vkey |w/delayed auth. AAA-MS ( )
|DHCP -------------- DHCP Server ------------ ( )
|Client |<--- <--- --------------
| |MIP6 bootinfo MIP6 bootinfo{HA[,HoA]} |
| |{HA[,HoA]} DHCP key |
| | | AAA-MS
| | IKE |
|Mobile-------------- Home Agent --------------------+
|Node |<--- <---
+-------+ MIP6 bootinfo MIP6 bootinfo
{[HoA]} {IKE credential[,HoA]}
Figure 2: DHCPv6 Server as a AAA Client for Mobility Service
In this model, the bootstrapping procedure is executed as described
below;
1. First, network access authentication is executed by using a
network access authentication protocol and a AAA-NA protocol.
2. After IP connectivity is established, the DHCP client sends a
request message (DHCP-SOLICIT).
3. When the DHCP server has received the request message, it
requests Mobile IPv6 bootstrap information and a DHCP delayed
authentication key [RFC3315][RFC3118] to the AAA infrastructure.
4. According to the identifier of the mobile node such as a MAC
address or an NAI (Network Access Identifier) which is included
in a AAA-MS protocol request sent from the DHCP server, the AAA
Ohba, et al. Expires April 17, 2005 [Page 6]
Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004
server selects the Mobile IPv6 bootstrap information and a DHCP
delayed authentication key, and sends these parameters to the
DHCP server.
5. The DHCP server executes delayed authentication with the
retrieved key.
6. When the DHCP server receives a valid DHCP Request message
(DHCP-REQUEST) from the DHCP client, it creates the binding for
the DHCP client and sends a reply message (DHCP-REPLY) including
"confirmed" configuration information including Mobile IPv6
bootstrap information such as a home agent address and a home
prefix.
7. The mobile node starts Mobile IPv6 binding update procedure.
When the home agent receives an authentication request message
(e.g., an IKE_SA_INIT request message in IKEv2) from the mobile
node, it requests IKE credentials such as a symmetric key to the
AAA server. Alternatively, the AAA server may send the IKE
credentials to the home agent before the home agent receives the
authentication request message.
8. The home agent authenticates the mobile node by using the IKE
credentials.
The DHCP delayed authentication key and a shared secret used for IKE
can be derived dynamically in network access authentication protocol
exchanges based on e.g., IEEE 802.1X or PANA.
Figure 3 shows an example sequence. For simplicity, it is assumed in
Figure 3 that the AAA-NA server and the AAA-MS server are integrated
in a single AAA server.
Ohba, et al. Expires April 17, 2005 [Page 7]
Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004
Mobile Node/ NAS/ Home Agent AAA
DHCP Client DHCP Server Server
|Network Access | |
|Authentication Protocol| AAA-NA |
|<--------------------->|<----------------------------------->|
| DHCP-SOLICIT | | |
|---------------------->| AAA-MS(REQUEST parameters) |
| |------------------------------------>|
| | AAA-MS(parameters) |
| |<------------------------------------|
| +---------------+ | |
| | Delayed auth. | | |
| +---------------+ | |
| DHCP-ADVERTISE | | |
|(bootstrap info.) | | |
|<---------------------| | |
+--------------+ | | |
| Delayed Auth | | | |
+--------------+ | | |
| DHCP-REQUEST | | |
|--------------------->| | |
| +---------------+ | |
| | Delayed auth. | | |
| +---------------+ | |
| | | |
| +----------------+ | |
| | create binding | | |
| +----------------+ | |
| | <Report authentication result> |
| DHCP-REPLY |- - - - - - - - - - - - - - - - - - >|
| [confirmed bootstrap info.] | |
|<----------------------| | |
+--------------+ | | |
| Delayed Auth | | | |
+--------------+ | | |
| IKE (authentication request) | |
|-------------------------------------->| REQUEST(key for IKE)|
| | |-------------------->|
| | | REPLY (key for IKE) |
| | |<--------------------|
| | +-----------+ |
| | | User Auth | |
| | +-----------+ |
| IKE (authentication result) | |
|<--------------------------------------| |
Figure 3: Model 1 Message Sequence
Ohba, et al. Expires April 17, 2005 [Page 8]
Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004
3.1 Integrated ASP Scenario
In this scenario the ASP and MSP are in the same integrated entity
called IASP (Integrated ASP). Furthermore, this scenario is based on
Parameter Set 2 where it is supposed that some dependency exists
between AAA-NA and AAA-MS.
In this scenario, the AAA-NA server and the AAA-MS server in the IASP
play the role as described below.
o The AAA-NA server authorizes network access and the AAA-MS server
authorizes mobility service.
o The AAA-MS server provides Mobile IPv6 bootstrap information to
the DHCP server.
+-----------------------------+
| IASP(ASP+MSP) |
+--------+ +-------------+ +------+ |
| Mobile |--- | NAS/ |------| Home | |
| Node | | DHCP Server | | Agent| |
+--------+ +-------------+ +------+ |
: | \ : \ |
: | \ +------+ : \ +------+ |
: | -|AAA-NA| : -|AAA-MS| |
: | |Server| : |Server| |
: | +------+ : +------+ |
: +-------------:--------:------+
: : MIP6 bootinfo{IKE credential,[HoA]}
: :<------>:
: MIP6 bootinfo{HA[HoA]} :
: [DHCP key] :
:<----------------------->:
: :
Figure 4: Integrated ASP Scenario in Model 1
The DHCP server are also located in the IASP's network. In general,
we can assume that there is a security association between the DHCP
server and the AAA server in the IASP so that the DHCP server can get
Mobile IPv6 bootstrap information from the AAA server.
If the mobile node is allowed to roam among IASPs, the DHCP server
that is serving the mobile node may belong to an IASP other than the
home IASP. Thus, to apply this mechanism, some trust relationship
such as a roaming agreement among the IASPs is required.
Ohba, et al. Expires April 17, 2005 [Page 9]
Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004
3.2 Third Party MSP Scenario
In this scenario, AAA servers in the ASP, the home MSP and the
serving MSP operate as described below.
o The AAA-MS server in the home MSP may authorize mobility service.
o The AAA-MS server in the serving MSP provides Mobile IPv6
bootstrap information to the DHCP server.
o The AAA-NA server in the ASP authorizes network access service.
In this scenario, the DHCP server may belong to the ASP. The DHCP
server needs to get Mobile IPv6 bootstrap information from the AAA-MS
server in the home MSP, and the home agent needs to get Mobile IPv6
bootstrap information from the AAA-MS server in the home MSP. So,
some trust relationship between the home MSP and the ASP is required
in addition to the trust relationship between the home MSP and the
serving MSP. In this case, the AAA-NA server in the ASP would
contact the AAA-MS server in the home MSP and the AAA-MS server in
the home MSP would contact the AAA-MS server in the serving MSP to
exchange Mobile IPv6 bootstrap information for a newly authenticated
client.
Ohba, et al. Expires April 17, 2005 [Page 10]
Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004
+--------------+ +-----------+
| ASP | | Serving |
| | | MSP |
+-------+ +------------+ | | +------+ | +----------+
|Mobile |--- | NAS/ | | | | Home | | | Home |
| Node | |DHCP Server | |===| | Agent| | | MSP |
+-------+ +------------+ | | +------+ | | +------+ |
: | \ +------+ | | : \ | | |AAA-MS| |
: | -|AAA-NA| | | : ----------|Server| |
: | |Server| | | : | | +------+ |
: | +------+ | +--:--------+ +----:-----+
: +--------------+ : :
: :MIP6 bootinfo{IKE credential,[HoA]}
: :<-------------->:
: : (roaming agreement)
: :
: MIP6 bootinfo {HA[HoA],[DHCP key] } :
:<-------------------------------------->:
: (roaming agreement) :
Figure 5: Third Party MSP Scenario in Model 1
Ohba, et al. Expires April 17, 2005 [Page 11]
Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004
4. Model 2: NAS as a AAA Client for MIP6 Service
In this model, the NAS acts as a AAA client for mobility service as
well as a AAA client for network access. The NAS delivers Mobile
IPv6 bootstrap information to the DHCP server. A home address is
assigned to the mobile node either through DHCPv6 or through IKE.
Note that this model is assuming a MIPv6-aware NAS in the network
that is providing network access, where the MIPv6-aware NAS is a NAS
that receives Mobile IPv6 bootstrap information from the AAA
infrastructure via a AAA-MS protocol and has the responsibility to
deliver the bootstrap information to the client by some means.
Client Network Access
+-------+ Authentication
|Network| Protocol AAA-NA --------------
|Access --------------------- NAS --------------- ( )
|Client | MIP6 bootinfo | \ ( )
| |DHCP| {HA[,HoA]}, | \ ( AAA )
| |key | [DHCP key] | \ (Infrastructure)
| | | DHCPv6 | \ AAA-MS ( )
| v | w/delayed auth. v +---------- ( )
| DHCP -------------------- DHCP Server <--- --------------
|Client | <--- MIP6 bootinfo{HA[,HoA]} |
| | MIP6 bootinfo{HA[,HoA]} [DHCP key] | AAA-MS
| | |
|Mobile | IKE |
| Node ------------------- Home Agent -------------------+
+-------+ <--- <--
MIP6 bootinfo{[HoA]} MIP6 bootinfo{IKE credential[,HoA]}
Figure 6: NAS as a AAA Client for MIP6 Service
When network access authentication is being carried out, mobility
service authentication is also carried out. That is, when the client
requests network access to NAS by using a network access
authentication protocol (i.e. PANA, IEEE 802.1X), the NAS acts as a
AAA client for network access and sends a AAA request to the AAA
infrastructure in order to authenticate to the client. Note that at
the same time, the AAA client for mobility service could send a AAA
request to the AAA infrastructure to get Mobile IPv6 bootstrap
information. One alternative is that the AAA request sent by the NAS
is used to get Mobile IPv6 bootstrap information. In this case the
information is carried to the NAS during the AAA-NA procedure,
meaning that the AAA-NA and AAA-MS procedures are supposed to be
integrated in this case.
It is also possible that the AAA client for mobility service invokes
the AAA-MS procedure after completion of the AAA-NA procedure. In
Ohba, et al. Expires April 17, 2005 [Page 12]
Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004
this case, the AAA-NA and AAA-MS procedures are supposed to be
performed separately.
In any of these previous alternatives, when a AAA request for network
access sent by the NAS is received by the AAA infrastructure and if
network access authentication succeeds, the AAA-MS server in the AAA
infrastructure contacts the home agent to exchange Mobile IPv6
bootstrap information and provide the mobility service for the mobile
node, where the bootstrap information includes IKE credentials and
optionally a home address. The home address could be assigned by the
home agent instead of the AAA-MS server.
When the mobility service is configured, the AAA infrastructure sends
the AAA-MS client (i.e., the NAS), the following bootstrap
information: a home agent address chosen by the AAA-MS server in the
AAA infrastructure and optionally a DHCP delayed authentication key
and/or a home address. Note that it is also possible that the DHCP
delayed authentication key is derived by the NAS based on the
cryptographic material (i.e. AAA_key [I-D.ietf-eap-keying]) provided
by the AAA-NA server in the AAA infrastructure after successful
completion of the AAA-NA procedure.
When the NAS receives from the AAA-MS server MIPv6 bootstrap
information for the client for which the AAA-NA procedure has been
successfully completed, it pushes the information to the DHCP server.
There are several protocols that can be used for carrying Mobile IPv6
bootstrap information and a DHCP delayed authentication key from the
NAS to the DHCP server. SNMP is one such protocol.
After that, the client obtains the Mobile IPv6 bootstrap information
through DHCP. A DHCP delayed authentication key is obtained through
the network access authentication procedure and installed to the DHCP
client.
Now, the client uses the obtained Mobile IPv6 bootstrap information
to know which home agent should be contacted. Optionally the
bootstrap information contains a home address though it is also
possible that a home address is securely assigned through IKE between
the mobile node and the home agent.
4.1 Integrated ASP Scenario
In this deployment scenario (as it is specified in
[I-D.ietf-mip6-bootstrap-ps]) the ASP and MSP are in the same
integrated entity called IASP (Integrated ASP). Furthermore, this
scenario is based on Parameter Set 2 where it is supposed that some
dependency exists between AAA-NA and AAA-MS. The following two cases
are considered for this scenario.
Ohba, et al. Expires April 17, 2005 [Page 13]
Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004
o In a single domain case where the home/serving ASP and the home/
serving MSP are in the same IASP. In this case, the AAA
infrastructure and rest of entities (the NAS, the DHCP server, the
home agent, etc.) are managed by the same IASP.
o In a roaming case where really the AAA infrastructure shown in
Figure 6 is at least divided in two AAA infrastructures: the AAA
infrastructure of the serving IASP and the AAA infrastructure of
the home IASP.
If the mobility service is provided by the home IASP, the home agent
depicted in Figure 6 belongs to the home IASP and it is configured by
the AAA-MS server of the home IASP. On the other hand, if the
mobility service is provided by the serving IASP, the home agent
belongs to the serving IASP and configured by the AAA-MS server of
the serving IASP.
4.2 Third Party MSP Scenario
This scenario could fall into either Parameter Set 1 or Parameter Set
2 depending on whether there is a dependency between AAA-NA and
AAA-MS. The first case is out of scope of this document however
second one is in scope. Parameter Set 2 case happens when there is
some trust relationship between the ASP and the home MSP in addition
to the trust relationship between the home MSP and the serving MSP.
In this case, the AAA-NA server in the ASP would contact the AAA-MS
server in the home MSP and the AAA-MS server in the home MSP would
contact the AAA-MS server in the serving MSP to exchange Mobile IPv6
bootstrap information for a newly authenticated client.
Ohba, et al. Expires April 17, 2005 [Page 14]
Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004
5. Comparison with Other Bootstrapping Architectures
5.1 Home Agent as NAS for AAA for Mobility Service
In [I-D.yegin-mip6-aaa-fwk], a bootstrapping architecture is defined
based on an assumption that the mobile node is aware of its home
agent address by some means. The known home agent acts as a NAS for
AAA for mobility service. This architecture is simpler than other
architectures. However, if the operator wants to have more
flexibility in assignment of Mobile IPv6 bootstrap information
including home agent addresses, e.g., assigning different home agents
depending on the profile of the subscriber of the Mobile IPv6
service, then other architectures like the one described in this
document would be useful.
5.2 MIPv6 Authorization and Configuration based on EAP
The architecture proposed in [I-D.giaretta-mip6-authorization-eap]
uses EAP for conveying Parameter Set 2 of
[I-D.ietf-mip6-bootstrap-ps] between the mobile node and the AAA-NA
server. An advantage of this architecture is that access networks
can be transparent to the bootstrapping procedure. A disadvantage is
its potential complexity in multi-domain environments where Mobile
IPv6 bootstrap information may be assigned by the visited
administrative domain, not by the home administrative domain of the
mobile node. In this case, the bootstrap information would need to
be transferred from the visited administrative domain to the AAA-NA
server in the home administrative domain in order to carry them to
the mobile node over EAP. Also, this architecture requires existing
EAP methods to be modified in order to carry Mobile IPv6 bootstrap
information.
Ohba, et al. Expires April 17, 2005 [Page 15]
Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004
6. Security Considerations
The bootstrapping architecture defined in this document uses DHCP in
the visited network for carrying Mobile IPv6 bootstrap information to
the mobile node. In an environment where the underlying AAA
infrastructure consists of multiple administrative domains, it is
possible that the Mobile IPv6 bootstrap information that is assigned
and issued by a home administrative domain of the mobile node are
passed to the visited administrative domain, which would result in
some topological information of the home administrative domain such
as home agent addresses to be known to the visited administrative
domain unless the information is encrypted between the home
administrative domain and the mobile node. However, such information
is eventually carried in clear text once the mobile node starts using
the bootstrap information by sending Mobile IPv6 Binding Update as
well as subsequent data packets and will be known to the visited
administrative domain. In this regard, the security risk of this
bootstrapping architecture is not much different from that of other
bootstrapping architectures if the bootstrap information are finally
used by the mobile node.
On the other hand, it is possible that the Mobile IPv6 bootstrap
information are delivered to the mobile node but not used by the
mobile at all. In this case, an operator of the home administrative
domain may want to avoid unnecessary information leakage to the
visited administrative domain. To achieve this, the bootstrap
information delivered via DHCP in the visited access network may be
encrypted by using the security association between the home
administrative domain and the mobile node. In this case, the DHCP
server would act as a configuration server for distributing opaque
configuration parameters.
Ohba, et al. Expires April 17, 2005 [Page 16]
Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004
7. Open Issues
o In the hybrid scenario of integrated ASP and third party MSP
scenarios, it is possible that both the MSP in the integrated ASP
and the third party MSP are able to provide Mobile IPv6 bootstrap
information for the mobile node. In such a scenario, some policy
might be needed for the mobile node and/or the MSPs to choose an
appropriate MSP that provides bootstrap information to the mobile
node or to have both MSPs provide bootstrap information to the
mobile node.
o Model 1 might have some security issue if the AAA server gives
Mobile IPv6 bootstrap information and a DHCP delayed
authentication key to a DHCP server per request from a DHCP client
which is actually not authenticated and authorized for access to
the network served by the DHCP server.
Ohba, et al. Expires April 17, 2005 [Page 17]
Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004
8. References
8.1 Normative References
[I-D.ietf-mip6-bootstrap-ps]
Patel, A., "Problem Statement for bootstrapping Mobile
IPv6", draft-ietf-mip6-bootstrap-ps-01 (work in progress),
October 2004.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
8.2 Informative References
[I-D.ohba-aaaarch-authorization-delegation]
Ohba, Y., "An Extended AAA Authorization Framework with
Delegation",
draft-ohba-aaaarch-authorization-delegation-00 (work in
progress), September 2004.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-03 (work in
progress), July 2004.
[I-D.yegin-mip6-aaa-fwk]
Yegin, A., "AAA Mobile IPv6 Application Framework",
draft-yegin-mip6-aaa-fwk-00 (work in progress), September
2004.
[I-D.giaretta-mip6-authorization-eap]
Giaretta, G., "MIPv6 Authorization and Configuration based
on EAP", draft-giaretta-mip6-authorization-eap-02 (work in
progress), October 2004.
[I-D.ietf-dhc-agentopt-radius]
Droms, R. and J. Schnizlein, "RADIUS Attributes Sub-option
for the DHCP Relay Agent Information Option",
draft-ietf-dhc-agentopt-radius-08 (work in progress),
September 2004.
Ohba, et al. Expires April 17, 2005 [Page 18]
Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004
Authors' Addresses
Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 5305
EMail: yohba@tari.toshiba.com
Rafael Marin Lopez
University of Murcia
30071 Murcia
Spain
EMail: rafa@dif.um.es
Mayumi Yanagiya
NTT Network service systems laboratories, NTT Corporation
9-11, Midori-Cho, 3-Chome
Musashino-Shi, Tokyo 180-8585
Japan
EMail: yanagiya.mayumi@lab.ntt.co.jp
Hiroyuki Ohnishi
NTT Network service systems laboratories, NTT Corporation
9-11, Midori-Cho, 3-Chome
Musashino-Shi, Tokyo 180-8585
Japan
EMail: ohnishi.hiroyuki@lab.ntt.co.jp
Kuntal Chowdhury
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082
U.S.A.
EMail: chowdury@nortelnetworks.com
Ohba, et al. Expires April 17, 2005 [Page 19]
Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 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.
Ohba, et al. Expires April 17, 2005 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-23 09:42:24 |