idnits 2.17.1 draft-ietf-softwire-6rd-radius-attrib-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 24, 2013) is 4109 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Dayong Guo 2 Internet Draft Sheng Jiang (Editor) 3 Intended status: Standards Track Huawei Technologies Co., Ltd 4 Expires: July 28, 2013 R. Despres 5 RD-IPtech 6 R. Maglione 7 Telecom Italia 8 January 24, 2013 10 RADIUS Attribute for 6rd 12 draft-ietf-softwire-6rd-radius-attrib-11.txt 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute working 21 documents as Internet-Drafts. The list of current Internet-Drafts is 22 at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on July 28, 2013. 31 Copyright Notice 33 Copyright (c) 2013 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Abstract 48 IPv6 Rapid Deployment (6rd) provides both IPv4 and IPv6 connectivity 49 services simultaneously during the IPv4/IPv6 co-existence period. The 50 Dynamic Host Configuration Protocol (DHCP) 6rd option has been 51 defined to configure the 6rd Customer Edge (CE). However, in many 52 networks, the configuration information may be stored in 53 Authentication Authorization and Accounting (AAA) servers while user 54 configuration is mainly acquired from a Broadband Network Gateway 55 (BNG) through the DHCP protocol. This document defines a Remote 56 Authentication Dial In User Service (RADIUS) attribute that carries 57 6rd configuration information from the AAA server to BNGs. 59 Table of Contents 61 1. Introduction ................................................ 3 62 2. Terminology ................................................. 3 63 3. IPv6 6rd Configuration with RADIUS .......................... 3 64 4. Attributes .................................................. 6 65 4.1. IPv6-6rd-Configuration Attribute ....................... 6 66 4.2. Table of attributes .................................... 8 67 5. Diameter Considerations ..................................... 9 68 6. Security Considerations ..................................... 9 69 7. IANA Considerations ........................................ 10 70 8. Acknowledgments ............................................ 10 71 9. References ................................................. 10 72 9.1. Normative References .................................. 10 73 9.2. Informative References ................................ 11 75 1. Introduction 77 Recently providers have started to deploy IPv6 and to consider 78 transition to IPv6. IPv6 Rapid Deployment (6rd) [RFC5969] provides 79 both IPv4 and IPv6 connectivity services simultaneously during the 80 IPv4/IPv6 co-existence period. 6rd is used to provide IPv6 81 connectivity service through legacy IPv4-only infrastructure. 6rd 82 uses Dynamic Host Configuration Protocol (DHCP) [RFC2131] and the 6rd 83 Customer Edge (CE) uses the DHCP 6rd option [RFC5969] to discover a 84 6rd border relay and to configure IPv6 prefix and address. 86 In many networks, user configuration information is managed by AAA 87 (Authentication, Authorization, and Accounting) servers. The Remote 88 Authentication Dial-In User Service (RADIUS) protocol [RFC2865] is 89 usually used by AAA servers to communicate with network elements. In 90 a fixed line broadband network, the Broadband Network Gateways (BNGs) 91 act as the access gateway for users. The BNGs are assumed to embed a 92 DHCP server function that allows them to handle locally any DHCP 93 requests issued by hosts. 95 Since the 6rd configuration information is stored in AAA servers and 96 user configuration is mainly through DHCP between BNGs and hosts/CEs, 97 new RADIUS attributes are needed to propagate the information from 98 AAA servers to BNGs. 100 2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 The terms 6rd Customer Edge (6rd CE) and 6rd Border Relay (BR) are 107 defined in [RFC5969]. 109 3. IPv6 6rd Configuration with RADIUS 111 Figure 1 illustrates how the RADIUS protocol and DHCP cooperate to 112 provide 6rd CE with 6rd configuration information. 114 6rd CE BNG AAA Server 115 | | | 116 |-------DHCPDISCOVER------>| | 117 |(Parameter Request w/ 6rd option) | 118 | |--Access-Request(6rd Attr)-->| 119 | | | 120 | |<--Access-Accept(6rd Attr)---| 121 |<-------DHCPOFFER---------| | 122 | (6rd option) | | 123 | | | 124 DHCP RADIUS 125 Figure 1: the cooperation between DHCP and RADIUS 126 combining with RADIUS authentication 128 The BNG acts as a client of RADIUS and as a DHCP server. First, the 129 6rd CE MAY initiate a DHCPDISCOVER message that includes a Parameter 130 Request option (55) [RFC2132] with the 6rd option [RFC5969]. When the 131 BNG receives the DHCPDISCOVER, it SHOULD initiate a RADIUS Access- 132 Request message, in which the User-Name attribute (1) SHOULD be 133 filled by the 6rd CE MAC address, to the RADIUS server and the User- 134 password (2) attribute SHOULD be filled by the shared 6rd password 135 that has been preconfigured on the DHCP server, requesting 136 authentication as defined in [RFC2865] with IPv6-6rd-Configuration 137 attribute, defined in the next Section, in the desired attribute 138 list. If the authentication request is approved by the AAA server, an 139 Access-Accept message MUST be acknowledged with the IPv6-6rd- 140 Configuration Attribute. Then, the BNG SHOULD respond to the 6rd CE 141 with a DHCPOFFER message, which contains a DHCP 6rd option. The 142 recommended format of the MAC address is as defined in Calling- 143 Station-Id ([RFC3580] Section 3.20) without the SSID (Service Set 144 Identifier) portion. 146 Figure 2 describes another scenario - later re-authorize - in which 147 the authorization operation is not coupled with authentication. 148 Authorization relevant to 6rd is done independently after the 149 authentication process. 151 6rd CE BNG AAA Server 152 | | | 153 |--------DHCPREQUEST------>| | 154 |(Parameter Request w/ 6rd option) | 155 | |--Access-Request(6rd Attr)-->| 156 | | | 157 | |<--Access-Accept(6rd Attr)---| 158 | | | 159 |<---------DHCPACK---------| | 160 | (6rd option) | | 161 | | | 162 DHCP RADIUS 163 Figure 2: the cooperation between DHCP and RADIUS 164 decoupled with RADIUS authentication 166 In this scenario, the Access-Request packet SHOULD contain a Service- 167 Type attribute (6) with the value Authorize Only (17); thus, 168 according to [RFC5080], the Access-Request packet MUST contain a 169 State attribute that obtains from the previous authentication 170 process. 172 In both above-mentioned scenarios, Message-authenticator (type 80) 173 [RFC2865] SHOULD be used to protect both Access-Request and Access- 174 Accept messages. 176 After receiving the IPv6-6rd-Configuration Attribute in the initial 177 Access-Accept, the BNG SHOULD store the received 6rd configuration 178 parameters locally. When the 6rd CE sends a DHCP Request message to 179 request an extension of the lifetime for the assigned address, the 180 BNG does not have to initiate a new Access-Request towards the AAA 181 server to request the 6rd configuration parameters. The BNG could 182 retrieve the previously stored 6rd configuration parameters and use 183 them in its reply. 185 If the BNG does not receive the IPv6-6rd-Configuration Attribute in 186 the Access-Accept it MAY fall back to a pre-configured default 6rd 187 configuration, if any. If the BNG does not have any pre-configured 188 default 6rd configuration or if the BNG receives an Access-Reject, 189 the tunnel cannot be established. 191 As specified in [RFC2131], section 4.4.5, "Reacquisition and 192 expiration", if the DHCP server to which the DHCP Request message was 193 sent at time T1 has not responded by time T2 (typically 194 0.375*duration_of_lease after T1), the 6rd CE (the DHCP client) 195 SHOULD enter the REBINDING state and attempt to contact any server. 197 In this situation, the secondary BNG receiving the new DHCP message 198 MUST initiate a new Access-Request towards the AAA server. The 199 secondary BNG MAY include the IPv6-6rd-Configuration Attribute in its 200 Access-Request. 202 4. Attributes 204 This section defines IPv6-6rd-Configuration Attribute which is used 205 in the both abovementioned scenarios. The attribute design follows 206 [RFC6158] and referring to [I-D.ietf-radext-radius-extensions]. 208 4.1. IPv6-6rd-Configuration Attribute 210 The specification requires that multiple IPv4 addresses are 211 associated with one IPv6 prefix. Given that RADIUS currently has no 212 recommended way of grouping multiple attributes, the design below 213 appears to be a reasonable compromise. The IPv6-6rd-Configuration 214 Attribute is structured as follows: 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Type | Length | SubType1 | SubLen1 | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | IPv4MaskLen | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | SubType2 | SubLen2 | Reserved | 6rdPrefixLen | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | | 226 + + 227 | | 228 + 6rdPrefix + 229 | | 230 + + 231 | | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | SubType3 | SubLen3 | 6rdBRIPv4Address | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | 6rdBRIPv4Address | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Type 240 TBD 242 Length 243 28 + n*6 (the length of the entire attribute in octets; n 244 stands for the number of BR IPv4 addresses, minimum n is 1). 246 SubType1 248 1 (SubType number, for the IPv4 Mask Length suboption) 250 SubLen1 252 6 (the length of the IPv4 Mask Length suboption) 254 IPv4MaskLen 256 The number of high-order bits that are identical across all CE 257 IPv4 addresses within a given 6rd domain. This may be any value 258 between 0 and 32. Any value greater than 32 is invalid. Since 259 [RFC6158] Section A.2.1 has forbidden 8-bit fields, a 32-bit 260 field is used here. 262 SubType2 264 2 (SubType number, for the 6rd prefix suboption) 266 SubLen2 268 20 (the length of the 6rd prefix suboption) 270 Reserved 272 Set to be all 0 for now. Reserved for future use. To be 273 compatible with other IPv6 prefix attributes in the RADIUS 274 Protocol. The bits MUST be set to zero by the sender and MUST 275 be ignored by the receiver. 277 6rdPrefixLen 279 The IPv6 Prefix length of the Service Provider's 6rd IPv6 280 prefix in number of bits. The 6rdPrefixLen MUST be less than or 281 equal to 128. 283 6rdPrefix 285 The Service Provider's 6rd IPv6 prefix represented as a 16 286 octet IPv6 address. The bits after the 6rdPrefixlen number of 287 bits in the prefix SHOULD be set to zero. 289 SubType3 290 3 (SubType number, for the 6rd Border Relay IPv4 address 291 suboption) 293 SubLen3 295 6 (the length of the 6rd Border Relay IPv4 address suboption) 297 6rdBRIPv4Address 299 One or more IPv4 addresses of the 6rd Border Relay(s) for a 300 given 6rd domain. The maximum RADIUS Attribute length of 255 301 octets results in a limit of 37 IPv4 addresses. 303 Since the subtypes have values, they can appear in any order. If 304 multiple 6rdBRIPv4Address (subtype 3) appear, they are RECOMMENDED to 305 be placed together. 307 The IPv6-6rd-Configuration Attribute is normally used in the 308 Access-Accept messages. It MAY be used in Access-Request packets as a 309 hint to the RADIUS server; for example if the BNG is pre-configured 310 with a default 6rd configuration, these parameters MAY be inserted in 311 the attribute. The RADIUS server MAY ignore the hint sent by the BNG 312 and it MAY assign different 6rd parameters. 314 If the BNG includes the IPv6-6rd-Configuration Attribute, but the AAA 315 server does not recognize it, this attribute MUST be ignored by the 316 AAA Server. 318 If the BNG does not receive the IPv6-6rd-Configuration Attribute in 319 the Access-Accept it MAY fallback to a pre-configured default 6rd 320 configuration, if any. If the BNG does not have any pre-configured 321 default 6rd configuration, the 6rd tunnel cannot be established. 323 If the BNG is pre-provisioned with a default 6rd configuration and 324 the 6rd configuration received in Access-Accept is different from the 325 configured default, then the 6rd configuration received in the 326 Access-Accept message MUST be used for the session. 328 If the BNG cannot support the received 6rd configuration for any 329 reason, the tunnel SHOULD NOT be established. 331 4.2. Table of attributes 333 The following table adds to the one in [RFC2865], Section 5.44, 334 providing a guide to the quantity of IPv6-6rd-Configuration 335 attributes that may be found in each kind of packet. 337 Request Accept Reject Challenge Accounting # Attribute 338 Request 339 0-1 0-1 0 0 0-1 TBD IPv6-6rd- 340 Configuration 341 0-1 0-1 0 0 0-1 1 User-Name 342 0-1 0 0 0 0-1 2 User-Password 343 0-1 0-1 0 0 0-1 6 Service-Type 344 0-1 0-1 0-1 0-1 0-1 80 Message-Authenticator 346 The following table defines the meanings of the above table entries. 348 0 This attribute MUST NOT be present in packet. 349 0+ Zero or more instances of this attribute MAY be present in 350 packet. 351 0-1 Zero or one instance of this attribute MAY be present in 352 packet. 353 1 Exactly one instance of this attribute MUST be present in 354 packet. 356 5. Diameter Considerations 358 This attribute is usable within either RADIUS or Diameter [RFC6733]. 359 Since the Attributes defined in this document will be allocated from 360 the standard RADIUS type space, no special handling is required by 361 Diameter entities. 363 6. Security Considerations 365 In 6rd scenarios, both CE and BNG are within a provider network, 366 which can be considered as a closed network and a lower security 367 threat environment. A similar consideration can be applied to the 368 RADIUS message exchange between BNG and the AAA server. 370 In 6rd scenarios, the RADIUS protocol is run over IPv4. Known 371 security vulnerabilities of the RADIUS protocol are discussed in 372 [RFC2607], [RFC2865], and [RFC2869]. Use of IPsec [RFC4301] for 373 providing security when RADIUS is carried in IPv6 is discussed in 374 [RFC3162]. 376 A malicious user may use MAC address proofing and/or dictionary 377 attack on the shared 6rd password that has been preconfigured on the 378 DHCP server to get unauthorized 6rd configuration information. The 379 follow-up secure issues have been considered in Section 12, 380 [RFC5969]. 382 Security considerations for 6rd specific between 6rd CE and BNG are 383 discussed in [RFC5969]. Furthermore, generic DHCP security mechanisms 384 can be applied DHCP intercommunication between 6rd CE and BNG. 386 Security considerations for the Diameter protocol are discussed in 387 [RFC6733]. 389 7. IANA Considerations 391 This document requests the assignment of one new RADIUS Attribute 392 Types in the "RADIUS Types" registry (currently located at 393 http://www.iana.org/assignments/radius-types for the following 394 attributes: 396 o IPv6-6rd-Configuration 398 IANA should allocate the number from the standard RADIUS Attributes 399 range (values 1-191). The RFC Editor should use the assigned value 400 to replace "TBD" in Sections 4.1 and 4.2, and should remove this 401 paragraph. 403 8. Acknowledgments 405 The authors would like to thank Alan DeKok, Yong Cui, Leaf Yeh, Sean 406 Turner, Joseph Salowey, Glen Zorn, Dave Nelson, Bernard Aboba, Benoit 407 Claise, Barry Lieba, Stephen Farrell, Adrian Farrel, Ralph Droms and 408 other members of Softwire WG, RADIUSExt WG, AAA-Doctors and Secdir 409 for valuable comments. 411 9. References 413 9.1. Normative References 415 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 416 Requirement Levels", BCP 14, RFC 2119, March 1997. 418 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 419 March 1997. 421 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 422 Extensions", RFC 2132, March 1997. 424 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 425 "Remote Authentication Dial In User Service (RADIUS)", RFC 426 2865, June 2000. 428 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 429 3162, August 2001. 431 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 432 Internet Protocol", RFC 4301, December 2005. 434 [RFC5080] Nelson, D. and DeKok A., "Common Remote Authentication Dial 435 In User Service (RADIUS) Implementation Issues and 436 Suggested Fixes", RFC 5080, December 2007. 438 [RFC5969] Townsley, M. and O. Troan, "IPv6 Rapid Deployment on IPv4 439 Infrastructures (6rd) -- Protocol Specification", RFC5969, 440 August 2010. 442 [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", RFC 443 6158, March 2011. 445 [RFC6733] V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed., 446 "Diameter Base Protocol", RFC 6733, October 2012. 448 9.2. Informative References 450 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 451 Implementation in Roaming", RFC 2607, June 1999. 453 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS 454 Extensions", RFC 2869, June 2000. 456 [RFC3580] Congdon, P., B. Aboba, A. Smith, G. Zorn and J. Roese, 457 "IEEE 802.1X Remote Authentication Dial In User Service 458 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 460 [I-D.ietf-radext-radius-extensions] 461 DeKok, A. and A. Lior, "Remote Authentication Dial In User 462 Service (RADIUS) Protocol Extensions", draft-ietf-radext- 463 radius-extensions, work in process. 465 Author's Addresses 467 Dayong Guo 468 Huawei Technologies Co., Ltd 469 Q14 Huawei Campus, 156 BeiQi Road, 470 ZhongGuan Cun, Hai-Dian District, Beijing 100095 471 P.R. China 472 Email: guoseu@huawei.com 474 Sheng Jiang (Editor) 475 Huawei Technologies Co., Ltd 476 Q14 Huawei Campus, 156 BeiQi Road, 477 ZhongGuan Cun, Hai-Dian District, Beijing 100095 478 P.R. China 479 Email: jiangsheng@huawei.com 481 Remi Despres 482 RD-IPtech 483 3 rue du President Wilson 484 Levallois, 485 France 486 Email: despres.remi@laposte.net 488 Roberta Maglione 489 Telecom Italia 490 Via Reiss Romoli 274 491 Torino 10148 492 Italy 493 Email: roberta.maglione@telecomitalia.it