idnits 2.17.1 draft-bournelle-pana-mip6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 397. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 387. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 26, 2006) is 6513 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'HA-Information' on line 213 == Unused Reference: '4' is defined on line 314, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-01 == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-11 == Outdated reference: A later version (-03) exists of draft-ietf-mip6-aaa-ha-goals-01 == Outdated reference: A later version (-07) exists of draft-ietf-mip6-bootstrapping-split-02 == Outdated reference: A later version (-12) exists of draft-ietf-dime-mip6-integrated-00 == Outdated reference: A later version (-02) exists of draft-chowdhury-mip6-radius-01 Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Bournelle (Ed.) 3 Internet-Draft M. Laurent-Maknavicius 4 Expires: December 28, 2006 GET/INT 5 J-M. Combes 6 France Telecom R&D 7 June 26, 2006 9 Using PANA in the Mobile IPv6 Integrated Case 10 draft-bournelle-pana-mip6-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 28, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 A Mobile IPv6 node needs a home address, a home agent address and a 44 security association with its home agent. One of the current 45 challenge is to dynamically provide these information to the Mobile 46 Node. This problem is known as the Mobile IPv6 Bootstrapping 47 problem. A solution for this is to rely on the AAA infrastructure to 48 provide the Home Agent Information to the Network Access server 49 (NAS). Then the Mobile Node uses DHCPv6 to get this information. 50 This document provides a way for the Mobile Node to get the Home 51 Agent information by using the PANA protocol instead of DHCPv6. 53 Before the authentication phase, the PANA Authentication Agent (PAA) 54 indicates to the PANA Client (PaC) that it can provide him with the 55 Home Agent Information. According to the PANA client's response, 56 after the authentication and authorization phase with the AAA 57 infrastructure, the PAA will send this information to the PaC. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 63 3. PANA overview . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. The Mobile IPv6 Bootstrapping Integrated scenario . . . . . . 4 65 5. Using PANA instead of DHCPv6 . . . . . . . . . . . . . . . . . 5 66 6. Advantages of using PANA instead of DHCPv6 . . . . . . . . . . 6 67 7. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 7.1. Mobility-Capability AVP . . . . . . . . . . . . . . . . . 6 69 7.2. Home Agent related AVPs . . . . . . . . . . . . . . . . . 6 70 7.2.1. MIP6-Home-Agent-Address AVP . . . . . . . . . . . . . 6 71 7.2.2. MIP6-Home-Agent-FQDN AVP . . . . . . . . . . . . . . . 7 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 11.1. Normative References . . . . . . . . . . . . . . . . . . . 7 77 11.2. Informative References . . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 79 Intellectual Property and Copyright Statements . . . . . . . . . . 10 81 1. Introduction 83 One of the major issue of Mobile IPv6 [1] is currently the 84 bootstrapping problem. Indeed, a mobile node needs a home address, a 85 home agent address and a security association with its home agent to 86 register. The problem is to find a way for the mobile to get those 87 information. 89 The document [5] describes various deployment scenarios. In 90 particular, it makes a clear distinction between the Access Service 91 Provider (ASP) and the Mobility Service Provider (MSP). Both can be 92 integrated in a Integrated Access Service Provider (IASP). 94 In the integrated scenario [2], the home AAA server is in charge of 95 allocating a Home Agent to the MN. This Home Agent information is 96 carried in the AAA protocol from the AAA server to the NAS. Then the 97 Mobile Node uses DHCPv6 to get the HA information. 99 In this document, we propose to use the Protocol for carrying 100 Authentication Network Access (PANA) insted of DHCPv6. For this, we 101 describe what should be added to the current PANA specification and 102 the related operations. This solution suppose that we are in the 103 IASP scenario. 105 2. Terminology and Definitions 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [3]. 111 The MIPv6 bootstrapping terminology is taken from [5]. 113 This document also uses the following terms or abbreviations: 114 PANA Protocol for Carrying Network Authentication for Network Access. 116 PANA Client (PaC) A mobile node (MN) using a PANA protocol 117 implementation to authenticate itself to the network. 119 PAA The PANA Authentication Agent (PAA) is the entity responsible to 120 verify the credentials provided by the PANA client. It is also 121 responsible of granting network access. 123 HA The home agent is a Mobile IPv6 device. It is a router in charge 124 of delivering IPv6 packets addressed to the home address of the 125 mobile node. 127 3. PANA overview 129 PANA [4]is a protocol that carries EAP over IP/UDP to authenticate 130 users. The PAA (PANA Authentication Agent) is the endpoint of the 131 PANA protocol at the access network. The PAA itself might not be 132 able to authenticate the user by terminating the EAP protocol. 133 Instead the PAA might forward the EAP payloads to the backend AAA 134 infrastructure. 136 The Enforcement Point (EP) is an entity which enforces the result of 137 the PANA protocol exchange. The EP might be co-located with the PAA 138 or separated as a stand-alone device. 140 A successful EAP authentication exchange results in a PANA security 141 association (PANA SA) if the EAP method was able to derive session 142 keys. In this case, all further PANA messages between PaC and PAA 143 will be authenticated, replay and integrity protected thanks to the 144 MAC AVP. 146 4. The Mobile IPv6 Bootstrapping Integrated scenario 148 This section is extracted from [6]. 150 In the integrated scenario [2], the assumption is that the IPv6 151 mobility service is authorized by the same authorizer than network 152 access service. Basically Mobility Service Authorizer (MSA) and the 153 Access Service Authorizer (ASA) are the same entity. The scenario 154 considers two cases: 156 1. Mobile Node requests a home agent to its home domain (ASA/MSA). 158 2. Mobile Node requests a home agent to the Access Service Provider 159 (ASP) 161 In the first case, Home Agent is allocated by user's home domain. In 162 the second case it is allocated by user's visited domain. In both 163 cases, it is assumed that the AAA server in the home domain (AAAH) 164 authorizes both network access service and mobility service. 166 In this scenario, Mobile Node discovers the Home Agent Address using 167 DHCPv6. During network access service authentication and 168 authorization, AAAH also verifies if authenticating user is 169 authorized to use mobility service. In affirmative case, AAAH sends 170 to the Network Access Server (NAS) where the Mobile Node is attached, 171 the information about the assigned home agent. Then NAS stores that 172 information. To request home agent data, Mobile Node sends a DHCPv6 173 Information Request to the All_DHCP_Relay_Agents_and_Servers 174 multicast address. With this request, Mobile Node can specify if it 175 wants a home agent provided by the visited domain (ASP) or by the 176 home domain (ASA). In both cases, the NAS acts a DHCPv6 relay. When 177 the NAS receives DHCPv6 Information Request then it attaches home 178 agent information received from AAAH in a new DHC Relay Agent Option. 180 In case Mobile Node cannot acquire home agent information via DHCPv6, 181 it can try the default mechanism based on DNS described in [7]. 182 After the Mobile Node has acquired home agent information, the 183 mechanism used to bootstrap the HoA, IPsec Security Association, and 184 Authentication and Authorization with the MSA is the same described 185 in the bootstrapping solution for split scenario [7]. 187 5. Using PANA instead of DHCPv6 189 The goal of this document is to provide a way for the MN to acquire 190 the Home Agent Information through PANA messages instead of relying 191 on DHCPv6. 193 For this purpose, the PAA indicates to the PaC/MN that it can provide 194 him with a Home Agent. This is realized during the PANA-Start 195 exchange. The PAA adds a Mobility-Capability AVP (To Be Allocated) 196 in the PANA-Start-Request message which indicates what type of 197 Mobility Agents it can provide. The PaC replies with a PSA message 198 which will contain its answer to this proposal in the Mobility- 199 Capability AVP. If the PaC requires a Home Agent, the PAA adds the 200 Home Agent information in the PANA-Bind exchange. This Home-Agent 201 information is received by the PAA from the AAA infrastructure (cf. 202 [8] and [9]). After this negotiation, the MN/PaC falls back in the 203 split scenario case [7]. 205 PaC PAA AAA 206 --- --- --- 207 PSR[Mobility-Capability=Mobile IPv6] 208 <--------------- 209 PSA[Mobility-Capability=Mobile IPv6] 210 ---------------> 211 Authentication/authorization phase 212 <----------------><-------------------------> 213 PANA-Bind-Exchange[HA-Information] 214 <---------------> 216 Figure 1: PANA for Mobile IPv6 bootstrapping 218 If the PaC/MN does not support this specification or does not need a 219 Home Agent, it simply ignore the Mobility-Capability AVP. In this 220 case, the PAA should not provide the Home Agent Information in the 221 PANA-Bind-Exchange. 223 6. Advantages of using PANA instead of DHCPv6 225 One of the advantage of this proposal is that in a PANA-Based network 226 access, this proposal avoids to use DHCPv6 to get the HA information. 228 The other advantage is that the HA-Information is naturally Integrity 229 protected thanks to the AUTH AVP. 231 7. New AVPs 233 7.1. Mobility-Capability AVP 235 The Mobility-Capability AVP (AVP Code TBD) is of type Unsigned 32 and 236 contains the type of Mobility Agent that the PAA can provide to the 237 PaC/MN. This AVP is also used by the PaC/MN to indicates its need. 238 Below is a list of valid data values and associated Mobility Agent: 240 1. IPv6 Home Agent 242 The support of this AVP is not required. For this reason, the 'M' 243 bit MUST NOT be set. 245 [Editor's Note: it is left for further study if other mobility agents 246 could be provided by this proposal (e.g. IPv4 HA, HIP rendez-vous 247 server)] 249 7.2. Home Agent related AVPs 251 The two AVPs presented below are extracted from [8]. These AVPs can 252 be reused by the PAA to provide HA information to the PaC. These 253 AVPs must be included in the PANA-Bind-Request message. 255 7.2.1. MIP6-Home-Agent-Address AVP 257 The MIP6-Home-Agent-Address AVP (AVP Code TBD) is of type OctetString 258 and contains the Mobile IPv6 home agent address and the prefix length 259 of the said address. The AVP is a discriminated union, representing 260 IPv6 address in network byte order. The first two octets of this AVP 261 represents the home link prefix length followed by 16 octets of the 262 IPv6 address. 264 The Diameter server MAY decide to assign a MIPv6 home agent to the MN 265 that is in close proximity to the point of attachment (e.g. 267 determined by the NAS-Identifier). There may be other reasons for 268 dynamically assigning home agents to the MN, for example to share the 269 traffic load. The AVP also contains the prefix length so that the MN 270 can easily infer one of the possible Home Link prefixes from the home 271 agent address. 273 7.2.2. MIP6-Home-Agent-FQDN AVP 275 The MIP6-Home-Agent-FQDN AVP (AVP Code TBD) is of type UTF8String and 276 contains the FQDN of a Mobile IPv6 home agent. 278 8. Security Considerations 280 The Home Agent Information may be a sensitive information from an 281 operator's perspective. This proposal permits to provide integrity 282 to the Home Agent Information since the PANA-Bind exchange can be 283 protected by the AUTH AVP. 285 9. IANA Considerations 287 This document defines a new AVP: 289 Mobility-Capability is set to TBD 291 10. Acknowledgements 293 The authors would like to thanks Junghoon Jee, Sondes Larafa and 294 Hannes Tschofenig for useful discussion on this topic. 296 The authors would also like to thanks France Telecom R&D for partly 297 funding this work. 299 11. References 301 11.1. Normative References 303 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 304 IPv6", RFC 3775, June 2004. 306 [2] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for 307 the Integrated Scenario", 308 draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in 309 progress), June 2006. 311 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 312 Levels", BCP 14, RFC 2119, March 1997. 314 [4] Forsberg, D., "Protocol for Carrying Authentication for Network 315 Access (PANA)", draft-ietf-pana-pana-11 (work in progress), 316 March 2006. 318 11.2. Informative References 320 [5] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping 321 Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in 322 progress), May 2006. 324 [6] Giaretta, G., "Goals for AAA-HA interface", 325 draft-ietf-mip6-aaa-ha-goals-01 (work in progress), 326 January 2006. 328 [7] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 329 draft-ietf-mip6-bootstrapping-split-02 (work in progress), 330 March 2006. 332 [8] Korhonen, J., "Diameter MIPv6 Bootstrapping for the Integrated 333 Scenario", draft-ietf-dime-mip6-integrated-00 (work in 334 progress), June 2006. 336 [9] Chowdhury, K., "RADIUS Mobile IPv6 Support", 337 draft-chowdhury-mip6-radius-01 (work in progress), March 2006. 339 Authors' Addresses 341 Julien Bournelle 342 GET/INT 343 9 rue Charles Fourier 344 Evry 91011 345 France 347 Email: julien.bournelle@int-evry.fr 349 Maryline Laurent-Maknavicius 350 GET/INT 351 9 rue Charles Fourier 352 Evry 91011 353 France 355 Email: maryline.maknavicius@int-evry.fr 357 Jean-Michel Combes 358 France Telecom R&D 359 38/40 rue du General Leclerc 360 Issy-les-Moulineaux 92794 361 France 363 Email: jeanmichel.combes@orange-ft.com 365 Intellectual Property Statement 367 The IETF takes no position regarding the validity or scope of any 368 Intellectual Property Rights or other rights that might be claimed to 369 pertain to the implementation or use of the technology described in 370 this document or the extent to which any license under such rights 371 might or might not be available; nor does it represent that it has 372 made any independent effort to identify any such rights. Information 373 on the procedures with respect to rights in RFC documents can be 374 found in BCP 78 and BCP 79. 376 Copies of IPR disclosures made to the IETF Secretariat and any 377 assurances of licenses to be made available, or the result of an 378 attempt made to obtain a general license or permission for the use of 379 such proprietary rights by implementers or users of this 380 specification can be obtained from the IETF on-line IPR repository at 381 http://www.ietf.org/ipr. 383 The IETF invites any interested party to bring to its attention any 384 copyrights, patents or patent applications, or other proprietary 385 rights that may cover technology that may be required to implement 386 this standard. Please address the information to the IETF at 387 ietf-ipr@ietf.org. 389 Disclaimer of Validity 391 This document and the information contained herein are provided on an 392 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 393 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 394 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 395 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 396 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 397 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 399 Copyright Statement 401 Copyright (C) The Internet Society (2006). This document is subject 402 to the rights, licenses and restrictions contained in BCP 78, and 403 except as set forth therein, the authors retain all their rights. 405 Acknowledgment 407 Funding for the RFC Editor function is currently provided by the 408 Internet Society.