idnits 2.17.1 draft-chowdhury-mip6-bootstrap-radius-00.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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 402. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 392. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 408), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** There are 2 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 188: '... The attributes MAY be present in Acc...' RFC 2119 keyword, line 290: '...Pv6 Home Address MUST be considered ex...' RFC 2119 keyword, line 310: '... This attribute MUST NOT be present....' RFC 2119 keyword, line 311: '...ance of this attribute MAY be present....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 155 has weird spacing: '...ined by the N...' -- 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 (July 12, 2004) is 7227 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) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Chowdhury 3 Internet-Draft Nortel Networks 4 Expires: January 10, 2005 A. Lior 5 Bridgewater Systems 6 July 12, 2004 8 RADIUS Attributes for Mobile IPv6 bootstrapping 9 draft-chowdhury-mip6-bootstrap-radius-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 10, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document defines new attributes to facilitate Mobile IPv6 43 bootstrapping via a RADIUS infrastructure. In an access network 44 where the user attaches to get IPv6 access, there may be a Network 45 Access Server (NAS) or an Access Gateway that will require 46 authentication and authorization. In some cases, this type of access 47 authentication takes place via RADIUS infrastructure. As part of the 48 authentication setup the NAS may receive useful configuration 49 information from the home RADIUS server of the user. In case of 50 Mobile IPv6 access, the Home RADIUS server may assign various 51 information relevant to the user's device for bootstrapping. 53 Table of Contents 55 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1 Home Agent or a List of Home Agents . . . . . . . . . . . 4 58 2.2 Home Link Prefix or a list of Home Link prefixes . . . . . 5 59 2.3 Home Address . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. RADIUS attributes to carry Mobile IPv6 parameters . . . . . . 7 62 4.1 Home Agent Attribute . . . . . . . . . . . . . . . . . . . 7 63 4.2 Home Link Prefix Attribute . . . . . . . . . . . . . . . . 7 64 4.3 Home Address . . . . . . . . . . . . . . . . . . . . . . . 8 65 5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 10 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 69 9. Normative References . . . . . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 71 Intellectual Property and Copyright Statements . . . . . . . . 14 73 1. Motivation 75 Mobile IPv6 specification [RFC3775] requires a Mobile Node (MN) to 76 perform registration with a Home Agent with information about its 77 current point of attachment (Care-of Address). The Home Agent 78 creates and maintains binding between the MN's Home Address and the 79 MN's Care-of Address. 81 In order to register with a Home Agent, the MN needs to know 82 information such as, the Home Link prefix, the Home Agent Address, 83 the Home Address, the Home Link prefix Length etc. Moreover during 84 normal operation of the Mobile IPv6 session, the MN needs to know the 85 lifetime of the Home Address. 87 The aforementioned set of information may be statically provisioned 88 in the MN. However, static provisioning of this information has its 89 drawbacks. It increases provisioning and network maintenance burden 90 for the operator. Moreover, static provisioning does not allow load 91 balancing, failover, opportunistic home link assignment etc. For 92 example, the user may be accessing the network from a location that 93 may be geographically far away from the preconfigured home link; or 94 the cost of the link between the NAS and the Home Link is too great. 95 In these situations static provisioning may not be desirable. 97 Dynamic assignment of Mobile IPv6 home registration information is a 98 desirable feature for ease of deployment and network maintenance. 99 For this purpose, the Home RADIUS server, which is used for access 100 authentication, can be leveraged to assign some or all of the 101 necessary parameters. The Home RADIUS server may return these 102 parameters to the NAS. 104 The NAS may convey the received information to the MN using various 105 techniques. One such technique may utilize the role of the NAS as a 106 relay agent for Dynamic Host Configuration Protocol. In this case, 107 upon receiving the information from the Home RADIUS server, the NAS 108 forwards the set of parameters to the DHCP server. The DHCP server 109 attaches the information in new DHCP options while responding to an 110 information-request from the MN. The part where the NAS acts as a 111 DHCP relay agent and forwards the received information to the DHCP 112 server is outside the scope of this document. 114 2. Overview 116 | 117 Visited Network | Home Network 118 | 119 +-------+ | +-------+ 120 | | | | | 121 |Visited|----------|--------| Home | 122 |RADIUS | | |RADIUS | 123 | | | | | 124 +-------+ | +-------+ 125 | | 126 | | 127 | +------+ | 128 | +---| DHCP | | 129 | | |Server| | 130 | | +------+ | 131 | | | 132 +-----+ | +-----+ 133 +----+ | | | | Home| 134 | MN |--------------| NAS/| | |Agent| 135 +----+ |Relay| | | | 136 +-----+ | +-----+ 138 In the typical Mobile IPv6 access scenario as shown above, the MN 139 attaches in a visited network. During this attach procedure, the NAS 140 authenticates and authorizes the MN for IPv6 access service. In the 141 scenario shown, the authentication and authorization happens via 142 RADIUS infrastructure. 144 At the time of authorizing the user for IPv6 access, the Home RADIUS 145 server detects that the user is authorized for Mobile IPv6 access. 146 Based on Home network policy, the Home RADIUS server may allocate 147 several parameters to the MN for use during the subsequent Mobile 148 IPv6 Binding Update. A list of such parameters is described in the 149 following sub sections. 151 2.1 Home Agent or a List of Home Agents 153 The Home network provider may decide to assign a Home Agent to the MN 154 that is in close proximity to the point of attachment (e.g. 155 determined by the NAS-ID). There may be other reasons for assigning 156 Home Agents to the MN, e.g. load sharing in the network. The Home 157 network may also assign a list of Home Agents for the MN to choose 158 from. 160 2.2 Home Link Prefix or a list of Home Link prefixes 162 For the same reason as HA assignment, the Home network may assign a 163 Home Link that is in close proximity to the point of attachment 164 (NAS-ID). The Home RADIUS server may also assign a list of Home Link 165 prefixes to the MN and allow the MN to choose one. The MN can 166 perform [RFC3775] specific procedures to discover other information 167 for Mobile IPv6 registration. The length of the assigned prefix(es) 168 can be included as well. 170 2.3 Home Address 172 The Home RADIUS server may assign a Home Address to the MN. This 173 allows the network operator to support mobile devices that are not 174 configured with static addresses. The lifetime of the Home Address 175 can be indicated along with the address. 177 3. Terminology 179 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 181 this document are to be interpreted as described in RFC 2119. 183 4. RADIUS attributes to carry Mobile IPv6 parameters 185 This section defines format and syntax for the attribute that carries 186 the Mobile IPv6 parameters described in section 2. 188 The attributes MAY be present in Access-Accept, Accounting-Request. 190 4.1 Home Agent Attribute 192 This attribute is sent by the RADIUS server to the NAS in an 193 Access-Accept message. The attribute carries one or more assigned 194 Home Agent addresses to the NAS. 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Type | Length | Reserved | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | IPv6 address of assigned HA-1 | 202 | ... | 203 | IPv6 address of assigned HA-n | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Type: 208 ASSIGNED-HA-TYPE to be defined by IANA. 210 Length: 212 >= 20 octets 214 Reserved: 216 Reserved for future use. All bits set to 0. 218 IPv6 address of assigned HA-1 to HA-n: 220 128-bit IPv6 address of one or more assigned Home Agents. The 221 addresses appear in the order of preference. 223 4.2 Home Link Prefix Attribute 225 This attribute is sent by the RADIUS server to the NAS in an 226 Access-Accept message. The attribute carries the assigned Home Link 227 prefix or a list of assigned Home Link Prefixes. to the NAS. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type | Length | HL Length | Reserved | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | IPv6 address of assigned HL-1 | 235 | ... | 236 | IPv6 address of assigned HL-n ... 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Type: 241 ASSIGNED-HL-TYPE to be defined by IANA. 243 Length: 245 >= 4 octets + the minimum length of a prefix. 247 HL Length: 249 8-bit unsigned integer, representing the length in octets of 250 the Home Link Prefix(es). 252 Reserved: 254 Reserved for future use. All bits set to 0. 256 IPv6 address of assigned HL-1 to HL-n: 258 Home Link prefixes (upper order bits) of the assigned Home 259 Links where the MN should send binding update. The Home Link 260 prefixes appear in the order of preference. 262 4.3 Home Address 264 This attribute is sent by the RADIUS server to the NAS in an 265 Access-Accept message. The attribute carries the assigned Home IPv6 266 Address for the MN. 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Type | Length | Lifetime | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | 274 | | 275 | Assigned IPv6 Home Address | 276 | | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Type: 281 ASSIGNED-HOA-TYPE to be defined by IANA. 283 Length: 285 >= 20 octets. 287 Lifetime: 289 16-bit unsigned integer. The number of time units remaining 290 before the IPv6 Home Address MUST be considered expired. A 291 value of zero indicates that the IPv6 Home Address has expired. 292 One time unit is 4 seconds. 294 Assigned IPv6 Home Address: 296 IPv6 Home Address that is assigned to the MN. 298 5. Table of Attributes 300 The following table provides a guide to which attributes may be found 301 in RADIUS message and in what number. 303 Request Accept Reject Challenge # Attribute 304 0 0-1 0 0 TBD Home Agent 305 0 0-1 0 0 TBD Home Link Prefix 306 0 0-1 0 0 TBD Home Address 308 The following table defines the meaning of the above table entries. 310 0 This attribute MUST NOT be present. 311 0-1 Zero or one instance of this attribute MAY be present. 313 6. Security Considerations 315 Assignment of these values to a user should be based on successful 316 authentication of the user's access at the NAS. The Home RADIUS 317 server should only assign these values to an user who is authorized 318 for Mobile IPv6 service (this check could be performed with user's 319 subscription profile in the Home Network). 321 The NAS to the Home RADIUS server transactions must be adequately 322 secured. Otherwise there is a possibility that the user may receive 323 fraudulent values from a rogue RADIUS server potentially hijacking 324 the user's Mobile IPv6 session. 326 These new attributes do not introduce additional security threats 327 besides the one identified in [RFC2865]. 329 7. IANA Considerations 331 The RADIUS attribute types: ASSIGNED-HA-TYPE, ASSIGNED-HL-TYPE, 332 ASSIGNED-HOA-TYPE Must be assigned by IANA. 334 8. Acknowledgements 336 Thanks to the following individuals for their review and constructive 337 comments during the development of this document: 339 Mark Watson, Jayshree Bharatia. 341 9 Normative References 343 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 344 "Remote Authentication Dial In User Service (RADIUS)", RFC 345 2865, June 2000. 347 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 348 in IPv6", RFC 3775, June 2004. 350 Authors' Addresses 352 Kuntal Chowdhury 353 Nortel Networks 354 2221 Lakeside Blvd. 355 Richardson, TX 75082 356 US 358 Phone: +1 972-685-7788 359 EMail: chowdury@nortelnetworks.com 361 Avi Lior 362 Bridgewater Systems 363 303 Terry Fox Drive, Suite 100 364 Ottawa, Ontario 365 Canada K2K 3J1 367 Phone: +1 613-591-6655 368 EMail: avi@bridgewatersystems.com 370 Intellectual Property Statement 372 The IETF takes no position regarding the validity or scope of any 373 Intellectual Property Rights or other rights that might be claimed to 374 pertain to the implementation or use of the technology described in 375 this document or the extent to which any license under such rights 376 might or might not be available; nor does it represent that it has 377 made any independent effort to identify any such rights. Information 378 on the procedures with respect to rights in RFC documents can be 379 found in BCP 78 and BCP 79. 381 Copies of IPR disclosures made to the IETF Secretariat and any 382 assurances of licenses to be made available, or the result of an 383 attempt made to obtain a general license or permission for the use of 384 such proprietary rights by implementers or users of this 385 specification can be obtained from the IETF on-line IPR repository at 386 http://www.ietf.org/ipr. 388 The IETF invites any interested party to bring to its attention any 389 copyrights, patents or patent applications, or other proprietary 390 rights that may cover technology that may be required to implement 391 this standard. Please address the information to the IETF at 392 ietf-ipr@ietf.org. 394 Disclaimer of Validity 396 This document and the information contained herein are provided on an 397 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 398 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 399 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 400 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 401 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 402 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 404 Copyright Statement 406 Copyright (C) The Internet Society (2004). This document is subject 407 to the rights, licenses and restrictions contained in BCP 78, and 408 except as set forth therein, the authors retain all their rights. 410 Acknowledgment 412 Funding for the RFC Editor function is currently provided by the 413 Internet Society.