idnits 2.17.1 draft-korhonen-dime-nai-routing-02.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 437. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 444. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 450. 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 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 (October 27, 2008) is 5654 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 3588 (ref. '1') (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4282 (ref. '2') (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 2486 (ref. '4') (Obsoleted by RFC 4282) -- Obsolete informational reference (is this intentional?): RFC 4005 (ref. '9') (Obsoleted by RFC 7155) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and J. Korhonen (ed.) 3 Extensions (DIME) TeliaSonera 4 Internet-Draft M. Jones 5 Intended status: Standards Track Bridgewater Systems 6 Expires: April 30, 2009 L. Morand 7 Orange Labs 8 T. Tsou 9 Huawei 10 October 27, 2008 12 Diameter User-Name and Realm Based Request Routing Clarifications 13 draft-korhonen-dime-nai-routing-02.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 30, 2009. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This specification clarifies the Diameter realm based request 47 routing. We focus on the case where a Network Access Identifier in 48 the User-Name AVP is used to populate the Destination-Realm AVP and 49 the Network Access Identifier contains more than one realm. This 50 particular case is possible when the Network Access Identifier 51 decoration is used to force a routing of request messages through a 52 predefined list of realms. However, this functionality is not 53 unambiguously specified in the Diameter Base Protocol specification. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 59 3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Interpretation of Decorated NAIs . . . . . . . . . . . . . 6 62 4.2. Enhanced Request Routing Solution . . . . . . . . . . . . 6 63 4.3. Backwards Compatibility Considerations . . . . . . . . . . 7 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 71 Intellectual Property and Copyright Statements . . . . . . . . . . 11 73 1. Introduction 75 This specification clarifies the Diameter realm based request routing 76 defined in RFC 3588 [1]. We focus on the case where the Network 77 Access Identifier (NAI) [2] in the User-Name AVP is used to populate 78 the Destination-Realm AVP and the NAI contains more than one realm. 79 This particular case is possible when the NAI decoration is used to 80 force a routing of request messages through a predefined list of 81 realms. 83 According to the Diameter request routing processing rules in RFC 84 3588, the request originator may populate the Destination-Realm AVP 85 with the realm part of the NAI available in the User-Name AVP. 86 Unfortunately, there is no unambiguous mandatory language in RFC 3588 87 how Diameter agents participating to the request routing should 88 update the Destination-Realm AVP at each realm. 90 This specification presents both the issue regarding to the Diameter 91 realm based request routing with NAI decoration and also a solution 92 for the problem. The solution would only apply to Diameter Base 93 Protocol implementations that take the solution presented in this 94 specification into account. The solution, however, is fully 95 backwards compatible with the RFC 3588 Diameter Base Protocol. 97 2. Terminology and Abbreviations 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC2119 [3]. 103 Network Access Identifier (NAI): 105 The Network Access Identifier (NAI) is the user identity submitted 106 by the client during access authentication. In roaming, the 107 purpose of the NAI is to identify the user as well as to assist in 108 the routing of the authentication request. 110 Decorated NAI: 112 A NAI specifying a source route. See Section 2.7 of RFC 4282 for 113 more information. 115 Network Access Provider (NAP): 117 A business entity that provides network access infrastructure to 118 one or more realms. A NAP infrastructure constitutes of one or 119 more NASes. 121 Network Access Server (NAS): 123 The device that peers connect to in order to obtain access to the 124 network. 126 3. Problem Overview 128 The Diameter Base Protocol RFC 3588 Section 6.1 defines the request 129 routing in detail. This specification concerns only those cases 130 where a Destination-Realm AVP is included in a request message. A 131 Diameter peer originating a request message MAY retrieve the realm 132 information from the User-Name AVP and use that realm to populate the 133 Destination-Realm AVP. The User-Name AVP is in form of a NAI (in 134 this case a NAI with the realm part). The realm based request 135 routing, as described in RFC 3588, does not discuss how to handle 136 Decorated NAIs. The original NAI RFC 2486 [4] that RFC 3588 137 references to, does not defined how to construct a NAI with multiple 138 realms. Since then RFC 2486 has been obsoleted by RFC 4282 which in 139 turn defines how to construct Decorated NAIs. 141 Decorated NAIs are used to force routing of messages through a 142 predefined list of realms and in that way force certain inter-realm 143 roaming arrangements, see Section 2.7. of RFC 4282 [2]. For example, 144 a terminal (e.g., a mobile host) may learn based on some application 145 or implementation specific manner that its network access 146 authentication signaling must traverse through certain realms in 147 order to reach the home realm. In this case the terminal would 148 decorate its NAI during the network access authentication with the 149 list of intermediating realms and the home realm. As a result, the 150 network access server (NAS) and intermediating Diameter agents would 151 make sure that all subsequent request messages traverse through the 152 desired realms as long as the request messages contain the User-Name 153 AVP with a Decorated NAI. 155 NAI Decoration has previously been used, for example, in RADIUS [5] 156 based roaming networks using RFC 2486 NAIs in a proprietary manner. 157 There is a need to replicate the same NAI based routing enforcement 158 functionality also in Diameter based roaming networks. There are 159 also publicly available specifications (e.g., see [6], [7] and [8]) 160 that assume NAI Decoration based request routing enforcement is fully 161 supported by RFC 3588. The same assumption is carried over to NASREQ 162 [9] and EAP [10] Diameter applications. 164 Figure 1 illustrates an example deployment scenario where Decorated 165 NAIs would be used to force a certain route through desired realms. 166 A roaming terminal (e.g., a mobile host) discovers a number of 167 Network Access Providers (NAP): NAP A and NAP B. None of the NAPs are 168 able to provide direct connectivity to roaming terminals home realm 169 (i.e. Realm-H). However, the roaming terminal learns, somehow, that 170 NAP B is able to provide connectivity to the Realm-H through the 171 Realm-X (i.e. the visited realm from the roaming terminal point of 172 view). During the network access authentication, the roaming 173 terminal would decorate its NAI as Realm-H!username@Realm-X. The 174 roaming terminal has also an alternative route to its home realm 175 through NAP A, Realm-Z and Realm-X. If the roaming terminal were to 176 choose to use NAP A, then it would decorate its NAI as Realm-X!Realm- 177 H!username@Realm-Z. Diameter agents should now be able to route the 178 request message through desired realms using the Decorated NAI 179 originally found in the User-Name AVP. 181 .--. .--. .--. 182 _(. `) _(. `) _(. `) 183 _(Visited`)_ _(Visited`)_ _( Home `)_ 184 ( Realm-Z `)<---->( Realm-X `)<------>( Realm-H `) 185 ( ` . ) ) ( ` . ) ) ( ` . ) ) 186 `--(_______)--' `--(_______)--' `--(_______)--' 187 | __ / 188 | / 189 .--. .--. 190 _( `. _( `. 191 ( NAP A ) ( NAP B ) 192 ( ` . ) ) ( ` . ) ) 193 `--(___.-' `--(___.-' 194 ) 195 ( ( ) 196 ( | 197 +-+ 198 |M| 199 +-+ 201 Figure 1: Example roaming scenario with intermediating realms. The 202 mobile host authenticates to the home realm through one or more 203 visited realms. 205 NAI Decoration is not limited to the network access authentication 206 and authorization procedures. It can be used with any Diameter 207 application whose commands are proxiable and include the User-Name 208 AVP with a NAI. Generally NAI Decoration can be used to force a 209 certain route for all request messages at a realm granularity. 211 As a problem summary we have two main issues: 213 o Updating both Destination-Realm and User-Name AVPs based on the 214 Decorated NAI extracted from the User-Name AVP. The update would 215 be done by intermediating Diameter agents that participate to 216 realm based request routing. Specifically, this would concern 217 Diameter proxies. 219 o How Diameter agents could implement the handling of the NAI 220 Decoration based routing enforcement in a way that is still 221 backwards compatible with RFC 3588. 223 RFC 5113 [11] Section 2.3 also discusses NAI decoration related 224 issues with EAP [12] in general. 226 4. Solution Overview 228 This specification defines a solution for Diameter realm based 229 request routing with routing enforcement using the User-Name AVP NAI 230 Decoration. Diameter proxy agent implementations can claim 231 compliance using the solution described in this specification. 233 4.1. Interpretation of Decorated NAIs 235 Implementations compliant to this specification MUST have an uniform 236 way of interpreting decorated NAIs. That is, in the case of 237 decoration, the character '!' is used to separate realms in the list 238 of decorated realms in the NAI (as shown in examples in [2]). 240 4.2. Enhanced Request Routing Solution 242 When a Diameter agent receives a request message containing a 243 Destination-Realm AVP with a realm that the agent is configured to 244 process locally (and in the case of proxies the Diameter application 245 is locally supported), it MUST do the following further processing 246 before handling the message locally: 248 o If the User-Name AVP is available in the request message, then the 249 Diameter agent MUST inspect whether the User-Name AVP contains a 250 Decorated NAI. If the NAI is not decorated then the Diameter 251 agent proceeds with a normal RFC 3588 message processing. 253 o If the User-Name AVP contains a Decorated NAI, then the Diameter 254 agent MUST process the NAI as defined in RFC 4282 and update the 255 value of the User-Name AVP accordingly. Furthermore, the Diameter 256 agent MUST update the Destination-Realm AVP to match the new realm 257 in the User-Name AVP. 259 o The request message is then sent to the next hop using the normal 260 request routing rules as defined in RFC 3588. 262 Figure 2 illustrates an example of a roaming terminal originated 263 signaling with the home realm (Realm-H) through a NAP and two 264 intermediating realms (Realm-Z, Realm-X) before reaching the home 265 realm (Realm-H). The example shows how the User-Name AVP and the 266 Destination-Realm AVP change at each realm before reaching the final 267 destination. If the signaling were originated from the NAS/NAP only, 268 then the step 1) can be omitted. 270 1) Roaming Terminal -> NAS/NAP 271 Identity/NAI = realm-X!realm-H!username@realm-Z 273 2) NAS/NAP -> Realm-Z 274 User-Name = realm-X!realm-H!username@realm-Z 275 Destination-Realm = realm-Z 277 3) Realm-Z -> realm-X 278 User-Name = realm-H!username@realm-X 279 Destination-Realm = realm-X 281 4) Realm-X -> Realm-H 282 User-Name = username@realm-H 283 Destination-Realm = realm-H 285 Figure 2: The roaming terminal decides that the Diameter messages 286 must be routed via Realm-Z, Realm- X and Realm-H. 288 4.3. Backwards Compatibility Considerations 290 Obviously, the functionality described in Section 4.2 cannot be 291 guaranteed to work with the existing implementations of RFC 3588 or 292 any other strictly RFC 3588 compliant existing application (such as 293 NASREQ and EAP). An incompliant implementation would automatically 294 fall back to the normal RFC 3588 request routing behavior that, 295 unfortunately, cannot offer desired enhanced request routing 296 functionality. Therefore, it is RECOMMENDED that the solution 297 defined in this specification is only applied to newly specified 298 Diameter applications. A Diameter agent MAY implement the solution 299 defined in this specification also for the existing application. A 300 Diameter client SHOULD NOT assume the functionality described in 301 Section 4.2 from Diameter applications that do not comply with this 302 specification. 304 5. IANA Considerations 306 This specification has no actions to IANA. 308 6. Security Considerations 310 A malicious node initiating (or indirectly causing initiation of) 311 Diameter request may purposely create malformed list of realms in the 312 NAI. This may cause the routing of requests through realms that 313 would normally have nothing to do with the initiated Diameter message 314 exchange. Furthermore, a malformed list of realms may contain non- 315 existing realms causing the routing of Diameter messages that cannot 316 ultimately be routed anywhere. However, the request message might 317 get routed several hops before such non-existent realms are 318 discovered and thus creating unnecessary overhead to the routing 319 system in general. 321 The NAI decoration is used in AAA infrastructures where the Diameter 322 messages are transported between the NAS and the Diameter server via 323 one or more AAA brokers or Diameter proxies. In this case the NAS to 324 the Diameter server AAA communication rely on the security properties 325 of the intermediate AAA brokers and Diameter proxies. 327 7. Acknowledgements 329 The authors would like to thank Victor Fajardo and Stefan Winter for 330 their comments on this draft. 332 Jouni Korhonen would like to thank TEKES WISEciti project for 333 providing funding to work on this document. 335 8. References 337 8.1. Normative References 339 [1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 340 "Diameter Base Protocol", RFC 3588, September 2003. 342 [2] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network 343 Access Identifier", RFC 4282, December 2005. 345 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 346 Levels", BCP 14, RFC 2119, March 1997. 348 8.2. Informative References 350 [4] Aboba, B. and M. Beadles, "The Network Access Identifier", 351 RFC 2486, January 1999. 353 [5] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 354 Authentication Dial In User Service (RADIUS)", RFC 2865, 355 June 2000. 357 [6] 3GPP, "3GPP system to Wireless Local Area Network (WLAN) 358 interworking; System description", 3GPP TS 23.234 6.10.0, 359 October 2006. 361 [7] 3GPP, "3GPP system to Wireless Local Area Network (WLAN) 362 interworking; WLAN User Equipment (WLAN UE) to network 363 protocols; Stage 3", 3GPP TS 24.234 6.7.0, October 2006. 365 [8] 3GPP, "Numbering, addressing and identification", 3GPP 366 TS 23.003 3.15.0, October 2006. 368 [9] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 369 Network Access Server Application", RFC 4005, August 2005. 371 [10] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 372 Authentication Protocol (EAP) Application", RFC 4072, 373 August 2005. 375 [11] Arkko, J., Aboba, B., Korhonen, J., and F. Bari, "Network 376 Discovery and Selection Problem", RFC 5113, January 2008. 378 [12] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 379 Levkowetz, "Extensible Authentication Protocol (EAP)", 380 RFC 3748, June 2004. 382 Authors' Addresses 384 Jouni Korhonen 385 TeliaSonera 387 Email: jouni.nospam@gmail.com 388 Mark Jones 389 Bridgewater Systems 390 303 Terry Fox Drive 391 Ottawa, Ontario K2K 3J1 392 Canada 394 Email: Mark.Jones@bridgewatersystems.com 396 Lionel Morand 397 Orange Labs 398 38-40 rue du general Leclerc 399 Issy-moulineaux Cedex 9, 92794 400 France 402 Email: Lionel.morand@orange-ftgroup.com 404 Tina Tsou 405 Huawei 406 R&D Center, Huawei Technologies Co., Ltd 407 Bantian, Shenzhen 408 P.R. China 410 Email: tena@huawei.com 412 Full Copyright Statement 414 Copyright (C) The IETF Trust (2008). 416 This document is subject to the rights, licenses and restrictions 417 contained in BCP 78, and except as set forth therein, the authors 418 retain all their rights. 420 This document and the information contained herein are provided on an 421 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 422 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 423 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 424 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 425 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 426 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 428 Intellectual Property 430 The IETF takes no position regarding the validity or scope of any 431 Intellectual Property Rights or other rights that might be claimed to 432 pertain to the implementation or use of the technology described in 433 this document or the extent to which any license under such rights 434 might or might not be available; nor does it represent that it has 435 made any independent effort to identify any such rights. Information 436 on the procedures with respect to rights in RFC documents can be 437 found in BCP 78 and BCP 79. 439 Copies of IPR disclosures made to the IETF Secretariat and any 440 assurances of licenses to be made available, or the result of an 441 attempt made to obtain a general license or permission for the use of 442 such proprietary rights by implementers or users of this 443 specification can be obtained from the IETF on-line IPR repository at 444 http://www.ietf.org/ipr. 446 The IETF invites any interested party to bring to its attention any 447 copyrights, patents or patent applications, or other proprietary 448 rights that may cover technology that may be required to implement 449 this standard. Please address the information to the IETF at 450 ietf-ipr@ietf.org. 452 Acknowledgment 454 Funding for the RFC Editor function is provided by the IETF 455 Administrative Support Activity (IASA).