Internet DRAFT - draft-bournelle-pana-mip6
draft-bournelle-pana-mip6
Network Working Group J. Bournelle (Ed.)
Internet-Draft M. Laurent-Maknavicius
Expires: December 28, 2006 GET/INT
J-M. Combes
France Telecom R&D
June 26, 2006
Using PANA in the Mobile IPv6 Integrated Case
draft-bournelle-pana-mip6-01
Status of this Memo
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.
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 December 28, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
A Mobile IPv6 node needs a home address, a home agent address and a
security association with its home agent. One of the current
challenge is to dynamically provide these information to the Mobile
Node. This problem is known as the Mobile IPv6 Bootstrapping
problem. A solution for this is to rely on the AAA infrastructure to
provide the Home Agent Information to the Network Access server
Bournelle (Ed.), et al. Expires December 28, 2006 [Page 1]
Internet-Draft PANA for Mobile IPv6 June 2006
(NAS). Then the Mobile Node uses DHCPv6 to get this information.
This document provides a way for the Mobile Node to get the Home
Agent information by using the PANA protocol instead of DHCPv6.
Before the authentication phase, the PANA Authentication Agent (PAA)
indicates to the PANA Client (PaC) that it can provide him with the
Home Agent Information. According to the PANA client's response,
after the authentication and authorization phase with the AAA
infrastructure, the PAA will send this information to the PaC.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 3
3. PANA overview . . . . . . . . . . . . . . . . . . . . . . . . 4
4. The Mobile IPv6 Bootstrapping Integrated scenario . . . . . . 4
5. Using PANA instead of DHCPv6 . . . . . . . . . . . . . . . . . 5
6. Advantages of using PANA instead of DHCPv6 . . . . . . . . . . 6
7. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Mobility-Capability AVP . . . . . . . . . . . . . . . . . 6
7.2. Home Agent related AVPs . . . . . . . . . . . . . . . . . 6
7.2.1. MIP6-Home-Agent-Address AVP . . . . . . . . . . . . . 6
7.2.2. MIP6-Home-Agent-FQDN AVP . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative References . . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Bournelle (Ed.), et al. Expires December 28, 2006 [Page 2]
Internet-Draft PANA for Mobile IPv6 June 2006
1. Introduction
One of the major issue of Mobile IPv6 [1] is currently the
bootstrapping problem. Indeed, a mobile node needs a home address, a
home agent address and a security association with its home agent to
register. The problem is to find a way for the mobile to get those
information.
The document [5] describes various deployment scenarios. In
particular, it makes a clear distinction between the Access Service
Provider (ASP) and the Mobility Service Provider (MSP). Both can be
integrated in a Integrated Access Service Provider (IASP).
In the integrated scenario [2], the home AAA server is in charge of
allocating a Home Agent to the MN. This Home Agent information is
carried in the AAA protocol from the AAA server to the NAS. Then the
Mobile Node uses DHCPv6 to get the HA information.
In this document, we propose to use the Protocol for carrying
Authentication Network Access (PANA) insted of DHCPv6. For this, we
describe what should be added to the current PANA specification and
the related operations. This solution suppose that we are in the
IASP scenario.
2. Terminology and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
The MIPv6 bootstrapping terminology is taken from [5].
This document also uses the following terms or abbreviations:
PANA Protocol for Carrying Network Authentication for Network Access.
PANA Client (PaC) A mobile node (MN) using a PANA protocol
implementation to authenticate itself to the network.
PAA The PANA Authentication Agent (PAA) is the entity responsible to
verify the credentials provided by the PANA client. It is also
responsible of granting network access.
HA The home agent is a Mobile IPv6 device. It is a router in charge
of delivering IPv6 packets addressed to the home address of the
mobile node.
Bournelle (Ed.), et al. Expires December 28, 2006 [Page 3]
Internet-Draft PANA for Mobile IPv6 June 2006
3. PANA overview
PANA [4]is a protocol that carries EAP over IP/UDP to authenticate
users. The PAA (PANA Authentication Agent) is the endpoint of the
PANA protocol at the access network. The PAA itself might not be
able to authenticate the user by terminating the EAP protocol.
Instead the PAA might forward the EAP payloads to the backend AAA
infrastructure.
The Enforcement Point (EP) is an entity which enforces the result of
the PANA protocol exchange. The EP might be co-located with the PAA
or separated as a stand-alone device.
A successful EAP authentication exchange results in a PANA security
association (PANA SA) if the EAP method was able to derive session
keys. In this case, all further PANA messages between PaC and PAA
will be authenticated, replay and integrity protected thanks to the
MAC AVP.
4. The Mobile IPv6 Bootstrapping Integrated scenario
This section is extracted from [6].
In the integrated scenario [2], the assumption is that the IPv6
mobility service is authorized by the same authorizer than network
access service. Basically Mobility Service Authorizer (MSA) and the
Access Service Authorizer (ASA) are the same entity. The scenario
considers two cases:
1. Mobile Node requests a home agent to its home domain (ASA/MSA).
2. Mobile Node requests a home agent to the Access Service Provider
(ASP)
In the first case, Home Agent is allocated by user's home domain. In
the second case it is allocated by user's visited domain. In both
cases, it is assumed that the AAA server in the home domain (AAAH)
authorizes both network access service and mobility service.
In this scenario, Mobile Node discovers the Home Agent Address using
DHCPv6. During network access service authentication and
authorization, AAAH also verifies if authenticating user is
authorized to use mobility service. In affirmative case, AAAH sends
to the Network Access Server (NAS) where the Mobile Node is attached,
the information about the assigned home agent. Then NAS stores that
information. To request home agent data, Mobile Node sends a DHCPv6
Information Request to the All_DHCP_Relay_Agents_and_Servers
Bournelle (Ed.), et al. Expires December 28, 2006 [Page 4]
Internet-Draft PANA for Mobile IPv6 June 2006
multicast address. With this request, Mobile Node can specify if it
wants a home agent provided by the visited domain (ASP) or by the
home domain (ASA). In both cases, the NAS acts a DHCPv6 relay. When
the NAS receives DHCPv6 Information Request then it attaches home
agent information received from AAAH in a new DHC Relay Agent Option.
In case Mobile Node cannot acquire home agent information via DHCPv6,
it can try the default mechanism based on DNS described in [7].
After the Mobile Node has acquired home agent information, the
mechanism used to bootstrap the HoA, IPsec Security Association, and
Authentication and Authorization with the MSA is the same described
in the bootstrapping solution for split scenario [7].
5. Using PANA instead of DHCPv6
The goal of this document is to provide a way for the MN to acquire
the Home Agent Information through PANA messages instead of relying
on DHCPv6.
For this purpose, the PAA indicates to the PaC/MN that it can provide
him with a Home Agent. This is realized during the PANA-Start
exchange. The PAA adds a Mobility-Capability AVP (To Be Allocated)
in the PANA-Start-Request message which indicates what type of
Mobility Agents it can provide. The PaC replies with a PSA message
which will contain its answer to this proposal in the Mobility-
Capability AVP. If the PaC requires a Home Agent, the PAA adds the
Home Agent information in the PANA-Bind exchange. This Home-Agent
information is received by the PAA from the AAA infrastructure (cf.
[8] and [9]). After this negotiation, the MN/PaC falls back in the
split scenario case [7].
PaC PAA AAA
--- --- ---
PSR[Mobility-Capability=Mobile IPv6]
<---------------
PSA[Mobility-Capability=Mobile IPv6]
--------------->
Authentication/authorization phase
<----------------><------------------------->
PANA-Bind-Exchange[HA-Information]
<--------------->
Figure 1: PANA for Mobile IPv6 bootstrapping
If the PaC/MN does not support this specification or does not need a
Home Agent, it simply ignore the Mobility-Capability AVP. In this
Bournelle (Ed.), et al. Expires December 28, 2006 [Page 5]
Internet-Draft PANA for Mobile IPv6 June 2006
case, the PAA should not provide the Home Agent Information in the
PANA-Bind-Exchange.
6. Advantages of using PANA instead of DHCPv6
One of the advantage of this proposal is that in a PANA-Based network
access, this proposal avoids to use DHCPv6 to get the HA information.
The other advantage is that the HA-Information is naturally Integrity
protected thanks to the AUTH AVP.
7. New AVPs
7.1. Mobility-Capability AVP
The Mobility-Capability AVP (AVP Code TBD) is of type Unsigned 32 and
contains the type of Mobility Agent that the PAA can provide to the
PaC/MN. This AVP is also used by the PaC/MN to indicates its need.
Below is a list of valid data values and associated Mobility Agent:
1. IPv6 Home Agent
The support of this AVP is not required. For this reason, the 'M'
bit MUST NOT be set.
[Editor's Note: it is left for further study if other mobility agents
could be provided by this proposal (e.g. IPv4 HA, HIP rendez-vous
server)]
7.2. Home Agent related AVPs
The two AVPs presented below are extracted from [8]. These AVPs can
be reused by the PAA to provide HA information to the PaC. These
AVPs must be included in the PANA-Bind-Request message.
7.2.1. MIP6-Home-Agent-Address AVP
The MIP6-Home-Agent-Address AVP (AVP Code TBD) is of type OctetString
and contains the Mobile IPv6 home agent address and the prefix length
of the said address. The AVP is a discriminated union, representing
IPv6 address in network byte order. The first two octets of this AVP
represents the home link prefix length followed by 16 octets of the
IPv6 address.
The Diameter server MAY decide to assign a MIPv6 home agent to the MN
that is in close proximity to the point of attachment (e.g.
Bournelle (Ed.), et al. Expires December 28, 2006 [Page 6]
Internet-Draft PANA for Mobile IPv6 June 2006
determined by the NAS-Identifier). There may be other reasons for
dynamically assigning home agents to the MN, for example to share the
traffic load. The AVP also contains the prefix length so that the MN
can easily infer one of the possible Home Link prefixes from the home
agent address.
7.2.2. MIP6-Home-Agent-FQDN AVP
The MIP6-Home-Agent-FQDN AVP (AVP Code TBD) is of type UTF8String and
contains the FQDN of a Mobile IPv6 home agent.
8. Security Considerations
The Home Agent Information may be a sensitive information from an
operator's perspective. This proposal permits to provide integrity
to the Home Agent Information since the PANA-Bind exchange can be
protected by the AUTH AVP.
9. IANA Considerations
This document defines a new AVP:
Mobility-Capability is set to TBD
10. Acknowledgements
The authors would like to thanks Junghoon Jee, Sondes Larafa and
Hannes Tschofenig for useful discussion on this topic.
The authors would also like to thanks France Telecom R&D for partly
funding this work.
11. References
11.1. Normative References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for
the Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in
progress), June 2006.
Bournelle (Ed.), et al. Expires December 28, 2006 [Page 7]
Internet-Draft PANA for Mobile IPv6 June 2006
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Forsberg, D., "Protocol for Carrying Authentication for Network
Access (PANA)", draft-ietf-pana-pana-11 (work in progress),
March 2006.
11.2. Informative References
[5] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping
Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in
progress), May 2006.
[6] Giaretta, G., "Goals for AAA-HA interface",
draft-ietf-mip6-aaa-ha-goals-01 (work in progress),
January 2006.
[7] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
draft-ietf-mip6-bootstrapping-split-02 (work in progress),
March 2006.
[8] Korhonen, J., "Diameter MIPv6 Bootstrapping for the Integrated
Scenario", draft-ietf-dime-mip6-integrated-00 (work in
progress), June 2006.
[9] Chowdhury, K., "RADIUS Mobile IPv6 Support",
draft-chowdhury-mip6-radius-01 (work in progress), March 2006.
Bournelle (Ed.), et al. Expires December 28, 2006 [Page 8]
Internet-Draft PANA for Mobile IPv6 June 2006
Authors' Addresses
Julien Bournelle
GET/INT
9 rue Charles Fourier
Evry 91011
France
Email: julien.bournelle@int-evry.fr
Maryline Laurent-Maknavicius
GET/INT
9 rue Charles Fourier
Evry 91011
France
Email: maryline.maknavicius@int-evry.fr
Jean-Michel Combes
France Telecom R&D
38/40 rue du General Leclerc
Issy-les-Moulineaux 92794
France
Email: jeanmichel.combes@orange-ft.com
Bournelle (Ed.), et al. Expires December 28, 2006 [Page 9]
Internet-Draft PANA for Mobile IPv6 June 2006
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 (2006). 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.
Bournelle (Ed.), et al. Expires December 28, 2006 [Page 10]
