idnits 2.17.1 draft-ietf-dime-nai-routing-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3588, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3588, updated by this document, for RFC5378 checks: 2001-02-09) -- 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 6, 2009) is 5315 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 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) == Outdated reference: A later version (-02) exists of draft-dekok-radext-nai-00 == Outdated reference: A later version (-18) exists of draft-ietf-idnabis-protocol-16 -- Obsolete informational reference (is this intentional?): RFC 2486 (Obsoleted by RFC 4282) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 6 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) Nokia Siemens Networks 4 Internet-Draft M. Jones 5 Updates: 3588 (if approved) Bridgewater Systems 6 Intended status: Standards Track L. Morand 7 Expires: April 9, 2010 Orange Labs 8 T. Tsou 9 Huawei 10 October 6, 2009 12 Diameter User-Name and Realm Based Request Routing Clarifications 13 draft-ietf-dime-nai-routing-04.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 9, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This specification defines the behavior required of Diameter agents 52 to route requests when the User-Name Attribute Value Pair contains a 53 Network Access Identifier formatted with multiple realms. These 54 multi-realm or "Decorated" Network Access Identifiers are used in 55 order to force the routing of request messages through a predefined 56 list of mediating realms. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 62 3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. Interpretation of Decorated NAIs . . . . . . . . . . . . . 6 65 4.2. Internationalization of Decorated NAIs . . . . . . . . . . 6 66 4.3. Ensuring Backwards Compatibility . . . . . . . . . . . . . 7 67 4.4. Enhanced Request Routing Solution . . . . . . . . . . . . 7 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 This specification defines the behavior required of Diameter agents 79 to route requests when the User-Name Attribute Value Pair (AVP) 80 contains a Network Access Identifier (NAI) formatted with multiple 81 realms (hereafter referred to as Decorated NAI). Decorated NAIs are 82 used in order to force the routing of request messages through a 83 predefined list of mediating realms. This specification does not 84 define a new Diameter application but instead defines behaviour that 85 would be common across all new Diameter applications which require 86 request routing based on Decorated NAI. 88 The Diameter Base Protocol [RFC3588] NAI usage is originally based on 89 [RFC2486] which has since been revised to [RFC4282]. While the use 90 multiple realms is generally discouraged, RFC 4282 does allow 91 multiple realms. The use of this facility appears in, for instance, 92 [RFC4284]. However, RFC 4282 does not define how the Decorated NAIs 93 should be handled by Diameter agents so this specification was 94 written to capture those requirements. 96 2. Terminology and Abbreviations 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 Network Access Identifier (NAI): 104 The Network Access Identifier (NAI) is the user identity submitted 105 by the client during access authentication. In roaming, the 106 purpose of the NAI is to identify the user as well as to assist in 107 the routing of the authentication request. 109 Decorated NAI: 111 A NAI containing multiple realms used to specify a source route 112 and formatted according to Section 2.7 in RFC 4282. 114 Network Access Provider (NAP): 116 A business entity that provides network access infrastructure to 117 one or more realms. A NAP infrastructure constitutes of one or 118 more network access servers. 120 Network Access Server (NAS): 122 The device that peers connect to in order to obtain access to the 123 network. 125 3. Problem Overview 127 The Diameter Base Protocol RFC 3588 Section 6.1 defines the request 128 routing in detail. This specification concerns only in the cases 129 where a Destination-Realm AVP is included in a Diameter request 130 message. As described in RFC 3588 Section 6.1, a Diameter peer 131 originating a request message MAY retrieve the realm information from 132 the User-Name AVP and use that realm to populate the Destination- 133 Realm AVP. In that case, the User-Name AVP is in form of a NAI 134 including the realm part. 136 Decorated NAIs are used to force routing of messages through a 137 predefined list of realms and in that way e.g., force certain inter- 138 realm roaming arrangements, see Section 2.7 of RFC 4282. For 139 example, a terminal (e.g. a mobile host) may learn based on some 140 application or implementation specific manner that its network access 141 authentication signaling must traverse certain realms in order to 142 reach the home realm. In this case the terminal would decorate its 143 NAI during the network access authentication with the list of 144 intermediating realms and the home realm. As a result, the network 145 access server (NAS) and intermediating Diameter agents would make 146 sure that all Diameter request messages traverse through the desired 147 realms as long as the request messages contain the User-Name AVP with 148 a Decorated NAI. 150 NAI decoration has previously been used in RADIUS [RFC2865] based 151 roaming networks using RFC 2486 NAIs in a proprietary manner. There 152 is a need to replicate the same NAI based routing enforcement 153 functionality also in Diameter based roaming networks. Morover, 154 there are publicly available specifications (e.g., see [3GPP.23.234], 155 [3GPP.24.234], [3GPP.23.003], [3GPP.29.273] and [WiMAX]) that assume 156 NAI decoration based request routing enforcement is fully supported 157 by RFC 3588. The same assumption is carried over to NASREQ [RFC4005] 158 and EAP [RFC4072] Diameter applications. 160 Figure 1 illustrates an example deployment scenario where Decorated 161 NAIs would be used to force a certain route through desired realms. 162 A roaming terminal (e.g. a mobile host) discovers a number of Network 163 Access Providers (NAP): NAP A and NAP B. None of the NAPs are able to 164 provide direct connectivity to the roaming terminal's home realm 165 (i.e. h.example.com). However, the roaming terminal learns, somehow, 166 that NAP B is able to provide connectivity to the h.example.com 167 through the x.example.com (i.e. the visited realm from the roaming 168 terminal point of view). During the network access authentication, 169 the roaming terminal would decorate its NAI as 170 h.example.com!username@x.example.com. The roaming terminal has also 171 an alternative route to its home realm through NAP A, z.example.com 172 and x.example.com. If the roaming terminal were to choose to use NAP 173 A, then it would decorate its NAI as 174 x.example.com!h.example.com!username@z.example.com. Diameter agents 175 would now be able to route the request message through desired realms 176 using the Decorated NAI originally found in the User-Name AVP. 178 .--. .--. .--. 179 _(. `) _(. `) _(. `) 180 _( Visited`)_ _( Visited`)_ _( Home `)_ 181 (z.example.com`)<---->(x.example.com`)<------>(h.example.com`) 182 ( ` . ) ) ( ` . ) ) ( ` . ) ) 183 `--(_______)---' `--(_______)---' `--(_______)---' 184 | __ / 185 | / 186 .--. .--. 187 _( `. _( `. 188 ( NAP A ) ( NAP B ) 189 ( ` . ) ) ( ` . ) ) 190 `--(___.-' `--(___.-' 191 ) 192 ( ( ) 193 ( | 194 +-+ 195 |M| 196 +-+ 198 Figure 1: Example roaming scenario with intermediating realms. The 199 mobile host authenticates to the home realm through one or more 200 visited realms. 202 NAI decoration is not limited to the network access authentication 203 and authorization procedures. It can be used with any Diameter 204 application whose commands are proxiable and include the User-Name 205 AVP with a NAI. Generally, the NAI decoration can be used to force a 206 certain route for all Diameter request messages at a realm 207 granularity. 209 As a problem summary we have two main issues: 211 o Updating both Destination-Realm and User-Name AVPs based on the 212 Decorated NAI extracted from the User-Name AVP. The update would 213 be done by intermediating Diameter agents that participate to 214 realm based request routing. Specifically, this would concern 215 Diameter proxies. 217 o How Diameter agents could implement the handling of the NAI 218 decoration based routing enforcement in a way that is still 219 backwards compatible with RFC 3588. 221 Section 2.3 of [RFC5113] also discusses NAI decoration related issues 222 with EAP [RFC3748] in general. 224 4. Solution Overview 226 This specification defines a solution for Diameter realm based 227 request routing with routing enforcement using the User-Name AVP NAI 228 decoration. Diameter proxy agent implementations can claim 229 compliance using the solution described in this specification. The 230 Diameter answer processing is left unmodified and follows the 231 procedures described in Section 6.2 of RFC 3588. 233 4.1. Interpretation of Decorated NAIs 235 Implementations compliant to this specification MUST have a uniform 236 way of interpreting decorated NAIs. That is, in the case of 237 decoration, the character '!' (hexadecimal 0x21) is used to separate 238 realms in the list of decorated realms in the NAI (as shown in 239 examples in [RFC4282]). 241 4.2. Internationalization of Decorated NAIs 243 RFC 3588 Section 1.3 states that NAI realm names are required to be 244 unique, and are piggybacked on the administration of the Domain Name 245 System (DNS) [RFC1034][RFC1035] namespace. However, an NAI, with or 246 without decoration may contain international characters as allowed by 247 RFC 4282. This causes problems as international characters as such 248 are not supported by RFC 1034 and RFC 1035. The conversion of 249 International Domain Names (IDN), which in this document scope are 250 NAI realms, are discussed in [RFC3490] and further to be revised in 251 [I-D.ietf-idnabis-protocol]. 253 The general guidance for handling NAI realms with international 254 characters is described in Section 2.4 of RFC 4282 and discussed more 255 based on recent operational experiences in [I-D.dekok-radext-nai]. 256 This specification does not attempt to fix the issue with the 257 internationalization of NAIs as the problem space is large and 258 concerns much more than just NAI realms and NAI decoration. However, 259 this specification has the following assumptions: 261 o The conversion from a realm name including international 262 characters to ASCII compatible encoding should only take place 263 when DNS infrastructure needs to be queried and not for example 264 during the realm placement processing of Decorated NAIs. The 265 conversion is normally handled by a DNS resolver library on the 266 local Diameter agent and when not available in the resolver 267 library by the Diameter agent. In both cases the realm in the NAI 268 remains unchanged. 270 o It is the responsibility of the operators administrating their 271 realm and domain name spaces to ensure that the DNS is provisioned 272 properly for all realms that may appear in Decorated NAIs. This 273 implicitly requires that the conversion from any realm with 274 international characters to a domain name cannot fail (i.e. the 275 realms conform the preconditions for internationalized domain 276 names). 278 From the above discussion it can be concluded that avoiding 279 international characters in realms contained in NAIs is the best way 280 to avoid problems with internationalized domain names and Decorated 281 NAI handling in general. 283 4.3. Ensuring Backwards Compatibility 285 The handling of the NAI decoration based routing enforcement as 286 described in this specification will be supported by any new Diameter 287 application. Therefore, backwards compatibility with existing 288 Diameter implementations, applications and deployments will be 289 guaranteed. Existing Diameter agents not compliant with this 290 specification will not advertise support for these new applications 291 that implement the enhanced routing solution based on Decorated NAIs 292 and will therefore be bypassed. 294 4.4. Enhanced Request Routing Solution 296 When a Diameter client originates a request message, the Destination- 297 Realm AVP is populated with the realm part of the NAI available in 298 the User-Name AVP (realm given after the '@' character of the NAI). 299 The NAI in the User-Name AVP may or may not be decorated. 301 When a Diameter agent receives a request message containing the 302 Destination-Realm AVP with a realm that the agent is configured to 303 process locally (and in the case of proxies the Diameter application 304 is locally supported), it MUST do the following further processing 305 before handling the message locally: 307 o If the User-Name AVP is available in the request message, then the 308 Diameter agent MUST inspect whether the User-Name AVP contains a 309 Decorated NAI. If the NAI is not decorated then the Diameter 310 agent proceeds with a normal RFC 3588 message processing. 312 o If the User-Name AVP contains a Decorated NAI, then the Diameter 313 agent MUST process the NAI as defined in RFC 4282 and update the 314 value of the User-Name AVP accordingly. Furthermore, the Diameter 315 agent MUST update the Destination-Realm AVP to match the new realm 316 in the User-Name AVP. 318 o The request message is then sent to the next hop using the normal 319 request routing rules as defined in RFC 3588. 321 Figure 2 illustrates an example of a roaming terminal originated 322 signaling with the home realm (h.example.com) through a NAP and two 323 intermediating realms (z.example.com, x.example.com) before reaching 324 the home realm (h.example.com). The example shows how the User-Name 325 AVP and the Destination-Realm AVP change at each realm before 326 reaching the final destination. If the signaling were originated 327 from the NAS/NAP only, then the step 1) can be omitted. 329 1) Roaming Terminal -> NAS/NAP 330 Identity/NAI = x.example.com!h.example.com!username@z.example.com 332 2) NAS/NAP -> z.example.com 333 User-Name = x.example.com!h.example.com!username@z.example.com 334 Destination-Realm = z.example.com 336 3) Realm-Z -> x.example.com 337 User-Name = h.example.com!username@x.example.com 338 Destination-Realm = x.example.com 340 4) Realm-X -> h.example.com 341 User-Name = username@h.example.com 342 Destination-Realm = h.example.com 344 Figure 2: The roaming terminal decides that the Diameter messages 345 must be routed via z.example.com and x.example.com to h.example.com. 347 5. IANA Considerations 349 This specification has no actions to IANA. Note to the RFC Editor: 350 this section can be removed. 352 6. Security Considerations 354 A malicious node initiating (or indirectly causing initiation of) a 355 Diameter request may purposely create malformed list of realms in the 356 NAI. This may cause the routing of requests through realms that 357 would normally have nothing to do with the initiated Diameter message 358 exchange. Furthermore, a malformed list of realms may contain non- 359 existing realms causing the routing of Diameter messages that cannot 360 ultimately be routed anywhere. However, the request message might 361 get routed several hops before such non-existent realms are 362 discovered and thus creating unnecessary overhead to the routing 363 system in general. 365 The NAI decoration is used in AAA infrastructures where the Diameter 366 messages are transported between the NAS and the Diameter server via 367 one or more AAA brokers or Diameter proxies. In this case the NAS to 368 the Diameter server AAA communication relies on the security 369 properties of the intermediate AAA brokers and Diameter proxies. 371 7. Acknowledgements 373 The authors would like to thank Victor Fajardo, Stefan Winter, Jari 374 Arkko and Avi Lior for their detailed comments on this document. 376 Jouni Korhonen would like to thank TEKES WISEciti project for 377 providing funding to work on this document while he was at 378 TeliaSonera's employ. 380 8. References 382 8.1. Normative References 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, March 1997. 387 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 388 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 390 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 391 Network Access Identifier", RFC 4282, December 2005. 393 8.2. Informative References 395 [3GPP.23.003] 396 3GPP, "Numbering, addressing and identification", 3GPP 397 TS 23.003 8.5.0, June 2009. 399 [3GPP.23.234] 400 3GPP, "3GPP system to Wireless Local Area Network (WLAN) 401 interworking; System description", 3GPP TS 23.234 6.10.0, 402 October 2006. 404 [3GPP.24.234] 405 3GPP, "3GPP system to Wireless Local Area Network (WLAN) 406 interworking; WLAN User Equipment (WLAN UE) to network 407 protocols; Stage 3", 3GPP TS 24.234 6.7.0, October 2006. 409 [3GPP.29.273] 410 3GPP, "Evolved Packet System (EPS); 3GPP EPS AAA 411 interfaces", 3GPP TS 29.273 8.3.0, September 2009. 413 [I-D.dekok-radext-nai] 414 DeKok, A., "The Network Access Identifier", 415 draft-dekok-radext-nai-00 (work in progress), 416 September 2009. 418 [I-D.ietf-idnabis-protocol] 419 Klensin, J., "Internationalized Domain Names in 420 Applications (IDNA): Protocol", 421 draft-ietf-idnabis-protocol-16 (work in progress), 422 September 2009. 424 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 425 STD 13, RFC 1034, November 1987. 427 [RFC1035] Mockapetris, P., "Domain names - implementation and 428 specification", STD 13, RFC 1035, November 1987. 430 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 431 RFC 2486, January 1999. 433 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 434 "Remote Authentication Dial In User Service (RADIUS)", 435 RFC 2865, June 2000. 437 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 438 "Internationalizing Domain Names in Applications (IDNA)", 439 RFC 3490, March 2003. 441 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 442 Levkowetz, "Extensible Authentication Protocol (EAP)", 443 RFC 3748, June 2004. 445 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 446 "Diameter Network Access Server Application", RFC 4005, 447 August 2005. 449 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 450 Authentication Protocol (EAP) Application", RFC 4072, 451 August 2005. 453 [RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity 454 Selection Hints for the Extensible Authentication Protocol 455 (EAP)", RFC 4284, January 2006. 457 [RFC5113] Arkko, J., Aboba, B., Korhonen, J., and F. Bari, "Network 458 Discovery and Selection Problem", RFC 5113, January 2008. 460 [WiMAX] WiMAX Forum, "WiMAX Forum Network Architecture (Stage 2: 461 Architecture Tenets, Reference Model and Reference 462 Points)", Release 1 Version 1.2, January 2008. 464 Authors' Addresses 466 Jouni Korhonen (editor) 467 Nokia Siemens Networks 468 Linnoitustie 6 469 Espoo FIN-02600 470 Finland 472 Email: jouni.nospam@gmail.com 474 Mark Jones 475 Bridgewater Systems 476 303 Terry Fox Drive 477 Ottawa, Ontario K2K 3J1 478 Canada 480 Email: Mark.Jones@bridgewatersystems.com 482 Lionel Morand 483 Orange Labs 484 38-40 rue du general Leclerc 485 Issy-moulineaux Cedex 9, 92794 486 France 488 Email: Lionel.morand@orange-ftgroup.com 489 Tina Tsou 490 Huawei 491 R&D Center, Huawei Technologies Co., Ltd 492 Bantian, Shenzhen 493 P.R. China 495 Email: tena@huawei.com