summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5729.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5729.txt')
-rw-r--r--doc/rfc/rfc5729.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc5729.txt b/doc/rfc/rfc5729.txt
new file mode 100644
index 0000000..c422077
--- /dev/null
+++ b/doc/rfc/rfc5729.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group J. Korhonen, Ed.
+Request for Comments: 5729 Nokia Siemens Networks
+Updates: 3588 M. Jones
+Category: Standards Track Bridgewater Systems
+ L. Morand
+ Orange Labs
+ T. Tsou
+ Huawei
+ December 2009
+
+
+ Clarifications on the Routing of Diameter
+ Requests Based on the Username and the Realm
+
+Abstract
+
+ This specification defines the behavior required of Diameter agents
+ to route requests when the User-Name Attribute Value Pair contains a
+ Network Access Identifier formatted with multiple realms. These
+ multi-realm, or "Decorated", Network Access Identifiers are used in
+ order to force the routing of request messages through a predefined
+ list of mediating realms.
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the BSD License.
+
+
+
+
+
+
+Korhonen, et al. Standards Track [Page 1]
+
+RFC 5729 Diameter Realm Routing Clarifications December 2009
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Terminology and Abbreviations ...................................2
+ 3. Problem Overview ................................................3
+ 4. Solution Overview ...............................................5
+ 4.1. Interpretation of Decorated NAIs ...........................5
+ 4.2. Internationalization of Decorated NAIs .....................5
+ 4.3. Ensuring Backwards Compatibility ...........................6
+ 4.4. Enhanced Request Routing Solution ..........................7
+ 5. Security Considerations .........................................8
+ 6. Acknowledgements ................................................8
+ 7. References ......................................................9
+ 7.1. Normative References .......................................9
+ 7.2. Informative References .....................................9
+
+1. Introduction
+
+ This specification defines the behavior required of Diameter agents
+ to route requests when the User-Name Attribute Value Pair (AVP)
+ contains a Network Access Identifier (NAI) formatted with multiple
+ realms (hereafter referred to as a Decorated NAI). Decorated NAIs
+ are used in order to force the routing of request messages through a
+ predefined list of mediating realms. This specification does not
+ define a new Diameter application but instead defines behaviour that
+ would be common across all new Diameter applications that require
+ request routing based on Decorated NAI.
+
+ The Diameter Base Protocol [RFC3588] NAI usage is originally based on
+ [RFC2486], which has since been revised to [RFC4282]. While the use
+ of multiple realms is generally discouraged, RFC 4282 does allow
+ multiple realms. The use of this facility appears in, for instance,
+ [RFC4284]. However, RFC 4282 does not define how the Decorated NAIs
+ should be handled by Diameter agents, so this specification was
+ written to capture those requirements.
+
+2. Terminology and Abbreviations
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+ Network Access Identifier (NAI):
+
+ The user identity submitted by the client during access
+ authentication. In roaming, the purpose of the NAI is to identify
+ the user as well as to assist in the routing of the authentication
+ request.
+
+
+
+Korhonen, et al. Standards Track [Page 2]
+
+RFC 5729 Diameter Realm Routing Clarifications December 2009
+
+
+ Decorated NAI:
+
+ An NAI containing multiple realms used to specify a source route
+ and formatted according to Section 2.7 in RFC 4282.
+
+ Network Access Provider (NAP):
+
+ A business entity that provides network access infrastructure to
+ one or more realms. A NAP infrastructure comprises one or more
+ network access servers.
+
+ Network Access Server (NAS):
+
+ The device to which peers connect in order to obtain access to the
+ network.
+
+3. Problem Overview
+
+ Section 6.1 of "The Diameter Base Protocol" (RFC 3588) defines the
+ request routing in detail. That specification concerns only the
+ cases where a Destination-Realm AVP is included in a Diameter request
+ message. As described in RFC 3588 Section 6.1, a Diameter peer
+ originating a request message MAY retrieve the realm information from
+ the User-Name AVP and use that realm to populate the Destination-
+ Realm AVP. In that case, the User-Name AVP is in form of an NAI
+ including the realm part.
+
+ Decorated NAIs are used to force routing of messages through a
+ predefined list of realms and, in that way, force certain inter-realm
+ roaming arrangements; see Section 2.7 of RFC 4282. For example, a
+ terminal (e.g., a mobile host) may learn, based on some application-
+ or implementation-specific manner, that its network access
+ authentication signaling must traverse certain realms in order to
+ reach the home realm. In this case, the terminal would decorate its
+ NAI during the network access authentication with the list of
+ intermediating realms and the home realm. As a result, the network
+ access server (NAS) and intermediating Diameter agents would make
+ sure that all Diameter request messages traverse through the desired
+ realms as long as the request messages contain the User-Name AVP with
+ a Decorated NAI.
+
+ NAI decoration has previously been used in RADIUS-based [RFC2865]
+ roaming networks, using RFC 2486 NAIs in a proprietary manner. There
+ is a need to replicate the same NAI-based routing enforcement
+ functionality in Diameter-based roaming networks. Moreover, there
+ are publicly available specifications (e.g., see [3GPP.23.234],
+ [3GPP.24.234], [3GPP.23.003], [3GPP.29.273], and [WiMAX]) that assume
+ NAI-decoration-based request routing enforcement is fully supported
+
+
+
+Korhonen, et al. Standards Track [Page 3]
+
+RFC 5729 Diameter Realm Routing Clarifications December 2009
+
+
+ by RFC 3588. The same assumption is carried over to Network Server
+ Application Requirements (NASREQ) [RFC4005] and Extensible
+ Authentication Protocol (EAP) [RFC4072] Diameter applications.
+
+ Figure 1 illustrates an example deployment scenario where Decorated
+ NAIs would be used to force a certain route through desired realms.
+ A roaming terminal (e.g., a mobile host) discovers a number of
+ Network Access Providers (NAP): NAP A and NAP B. None of the NAPs
+ are able to provide direct connectivity to the roaming terminal's
+ home realm (i.e., h.example.com). However, the roaming terminal
+ learns, somehow, that NAP B is able to provide connectivity to
+ h.example.com through x.example.com (i.e., the visited realm from the
+ roaming terminal point of view). During the network access
+ authentication, the roaming terminal would decorate its NAI as
+ h.example.com!username@x.example.com. The roaming terminal has also
+ an alternative route to its home realm through NAP A: z.example.com
+ and x.example.com. If the roaming terminal were to choose to use NAP
+ A, then it would decorate its NAI as
+ x.example.com!h.example.com!username@z.example.com. Diameter agents
+ would now be able to route the request message through desired realms
+ using the Decorated NAI originally found in the User-Name AVP.
+
+ .--. .--. .--.
+ _(. `) _(. `) _(. `)
+ _( Visited`)_ _( Visited`)_ _( Home `)_
+ (z.example.com`)<---->(x.example.com`)<------>(h.example.com`)
+ ( ` . ) ) ( ` . ) ) ( ` . ) )
+ `--(_______)---' `--(_______)---' `--(_______)---'
+ | __ /
+ | /
+ .--. .--.
+ _( `. _( `.
+ ( NAP A ) ( NAP B )
+ ( ` . ) ) ( ` . ) )
+ `--(___.-' `--(___.-'
+ )
+ ( ( )
+ ( |
+ +-+
+ |M|
+ +-+
+
+ Figure 1: Example roaming scenario with intermediating realms. The
+ mobile host authenticates to the home realm through one or more
+ visited realms.
+
+
+
+
+
+
+Korhonen, et al. Standards Track [Page 4]
+
+RFC 5729 Diameter Realm Routing Clarifications December 2009
+
+
+ NAI decoration is not limited to the network access authentication
+ and authorization procedures. It can be used with any Diameter
+ application whose commands are proxiable and include the User-Name
+ AVP with an NAI. Generally, the NAI decoration can be used to force
+ a certain route for all Diameter request messages at a realm
+ granularity.
+
+ As a problem summary, we have two main issues:
+
+ o Updating both Destination-Realm and User-Name AVPs based on the
+ Decorated NAI extracted from the User-Name AVP. The update would
+ be done by intermediating Diameter agents that participate in
+ realm-based request routing. Specifically, this would concern
+ Diameter proxies.
+
+ o How Diameter agents could implement the handling of the NAI-
+ decoration-based routing enforcement in a way that is still
+ backwards compatible with RFC 3588.
+
+ Section 2.3 of [RFC5113] also discusses NAI-decoration-related issues
+ with EAP [RFC3748] in general.
+
+4. Solution Overview
+
+ This specification defines a solution for Diameter realm-based
+ request routing with routing enforcement using the User-Name AVP NAI
+ decoration. Diameter proxy agent implementations can claim
+ compliance using the solution described in this specification. The
+ Diameter answer processing is left unmodified and follows the
+ procedures described in Section 6.2 of RFC 3588.
+
+4.1. Interpretation of Decorated NAIs
+
+ Implementations compliant to this specification MUST have a uniform
+ way of interpreting decorated NAIs. That is, in the case of
+ decoration, the character '!' (hexadecimal 0x21) is used to separate
+ realms in the list of decorated realms in the NAI (as shown in
+ examples in [RFC4282]).
+
+4.2. Internationalization of Decorated NAIs
+
+ RFC 3588, Section 1.3 states that NAI realm names are required to be
+ unique and are piggybacked on the administration of the Domain Name
+ System (DNS) ([RFC1034], [RFC1035]) namespace. However, an NAI, with
+ or without decoration, may contain international characters as
+ allowed by RFC 4282. This causes problems, as international
+ characters as such are not supported by RFC 1034 and RFC 1035. The
+
+
+
+
+Korhonen, et al. Standards Track [Page 5]
+
+RFC 5729 Diameter Realm Routing Clarifications December 2009
+
+
+ conversion of International Domain Names (IDN), which in this
+ document's scope are NAI realms, are discussed in [RFC3490] and are
+ further to be revised in [IDNA].
+
+ The general guidance for handling NAI realms with international
+ characters is described in Section 2.4 of RFC 4282 and discussed more
+ in [NAI] based on recent operational experiences. This specification
+ does not attempt to fix the issue with the internationalization of
+ NAIs, as the problem space is large and concerns much more than just
+ NAI realms and NAI decoration. However, this specification has the
+ following assumptions:
+
+ o The conversion from a realm name that includes international
+ characters to ASCII-compatible encoding should only take place
+ when DNS infrastructure needs to be queried and not, for example,
+ during the realm-placement processing of Decorated NAIs. The
+ conversion is normally handled by a DNS resolver library on the
+ local Diameter agent or, when not available in the resolver
+ library, by the Diameter agent. In both cases, the realm in the
+ NAI remains unchanged.
+
+ o It is the responsibility of the operators administrating their
+ realm and domain name spaces to ensure that the DNS is provisioned
+ properly for all realms that may appear in Decorated NAIs. This
+ implicitly requires that the conversion from any realm with
+ international characters to a domain name cannot fail (i.e., the
+ realms conform to the preconditions for internationalized domain
+ names).
+
+ From the above discussion, it can be concluded that avoiding
+ international characters in realms contained in NAIs is the best way
+ to avoid problems with internationalized domain names and Decorated
+ NAI handling in general.
+
+4.3. Ensuring Backwards Compatibility
+
+ The handling of the NAI-decoration-based routing enforcement as
+ described in this specification will be supported by any new Diameter
+ application. Therefore, backwards compatibility with existing
+ Diameter implementations, applications, and deployments will be
+ guaranteed. Existing Diameter agents not compliant with this
+ specification will not advertise support for these new applications
+ that implement the enhanced routing solution based on Decorated NAIs,
+ and will therefore be bypassed.
+
+
+
+
+
+
+
+Korhonen, et al. Standards Track [Page 6]
+
+RFC 5729 Diameter Realm Routing Clarifications December 2009
+
+
+4.4. Enhanced Request Routing Solution
+
+ When a Diameter client originates a request message, the
+ Destination-Realm AVP is populated with the realm part of the NAI
+ available in the User-Name AVP (the realm given after the '@'
+ character of the NAI). The NAI in the User-Name AVP may or may not
+ be decorated.
+
+ When a Diameter agent receives a request message containing the
+ Destination-Realm AVP with a realm that the agent is configured to
+ process locally (and, in the case of proxies, the Diameter
+ application is locally supported), it MUST do the following further
+ processing before handling the message locally:
+
+ o If the User-Name AVP is available in the request message, then the
+ Diameter agent MUST inspect whether the User-Name AVP contains a
+ Decorated NAI. If the NAI is not decorated, then the Diameter
+ agent proceeds with a normal RFC 3588 message processing.
+
+ o If the User-Name AVP contains a Decorated NAI, then the Diameter
+ agent MUST process the NAI as defined in RFC 4282 and update the
+ value of the User-Name AVP accordingly. Furthermore, the Diameter
+ agent MUST update the Destination-Realm AVP to match the new realm
+ in the User-Name AVP.
+
+ o The request message is then sent to the next hop using the normal
+ request routing rules as defined in RFC 3588.
+
+ Figure 2 illustrates an example of a roaming terminal that originates
+ signaling with the home realm (h.example.com), through a NAP and two
+ intermediating realms (z.example.com, x.example.com) before reaching
+ the home realm (h.example.com). The example shows how the User-Name
+ AVP and the Destination-Realm AVP change at each realm before
+ reaching the final destination. If the signaling were originated
+ from the NAS/NAP only, then step 1 can be omitted.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Korhonen, et al. Standards Track [Page 7]
+
+RFC 5729 Diameter Realm Routing Clarifications December 2009
+
+
+ 1) Roaming Terminal -> NAS/NAP
+ Identity/NAI = x.example.com!h.example.com!username@z.example.com
+
+ 2) NAS/NAP -> z.example.com
+ User-Name = x.example.com!h.example.com!username@z.example.com
+ Destination-Realm = z.example.com
+
+ 3) Realm-Z -> x.example.com
+ User-Name = h.example.com!username@x.example.com
+ Destination-Realm = x.example.com
+
+ 4) Realm-X -> h.example.com
+ User-Name = username@h.example.com
+ Destination-Realm = h.example.com
+
+ Figure 2: The roaming terminal decides that the Diameter messages
+ must be routed via z.example.com and x.example.com to h.example.com.
+
+5. Security Considerations
+
+ A malicious node initiating (or indirectly causing initiation of) a
+ Diameter request may purposely create a malformed list of realms in
+ the NAI. This may cause the routing of requests through realms that
+ would normally have nothing to do with the initiated Diameter message
+ exchange. Furthermore, a malformed list of realms may contain non-
+ existing realms, causing the routing of Diameter messages that cannot
+ ultimately be routed anywhere. However, the request message might
+ get routed several hops before such non-existent realms are
+ discovered, thus creating unnecessary overhead to the routing system
+ in general.
+
+ The NAI decoration is used in Authentication, Authorization, and
+ Accounting (AAA) infrastructures where the Diameter messages are
+ transported between the NAS and the Diameter server via one or more
+ AAA brokers or Diameter proxies. In this case, the NAS to Diameter
+ server AAA communication relies on the security properties of the
+ intermediate AAA brokers and Diameter proxies.
+
+6. Acknowledgements
+
+ The authors would like to thank Victor Fajardo, Stefan Winter, Jari
+ Arkko, and Avi Lior for their detailed comments on this document.
+
+ Jouni Korhonen would like to thank the TEKES WISEciti project for
+ providing funding to work on this document while he was at
+ TeliaSonera's employ.
+
+
+
+
+
+Korhonen, et al. Standards Track [Page 8]
+
+RFC 5729 Diameter Realm Routing Clarifications December 2009
+
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
+ J. Arkko, "Diameter Base Protocol", RFC 3588, September
+ 2003.
+
+ [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
+ Network Access Identifier", RFC 4282, December 2005.
+
+7.2. Informative References
+
+ [3GPP.23.003] 3GPP, "Numbering, addressing and identification", 3GPP
+ TS 23.003 8.5.0, June 2009.
+
+ [3GPP.23.234] 3GPP, "3GPP system to Wireless Local Area Network
+ (WLAN) interworking; System description", 3GPP TS
+ 23.234 6.10.0, October 2006.
+
+ [3GPP.24.234] 3GPP, "3GPP system to Wireless Local Area Network
+ (WLAN) interworking; WLAN User Equipment (WLAN UE) to
+ network protocols; Stage 3", 3GPP TS 24.234 6.7.0,
+ October 2006.
+
+ [3GPP.29.273] 3GPP, "Evolved Packet System (EPS); 3GPP EPS AAA
+ interfaces", 3GPP TS 29.273 8.3.0, September 2009.
+
+ [NAI] DeKok, A., "The Network Access Identifier", Work in
+ Progress, September 2009.
+
+ [IDNA] Klensin, J., "Internationalized Domain Names in
+ Applications (IDNA): Protocol", Work in Progress,
+ October 2009.
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and
+ facilities", STD 13, RFC 1034, November 1987.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC2486] Aboba, B. and M. Beadles, "The Network Access
+ Identifier", RFC 2486, January 1999.
+
+
+
+
+
+Korhonen, et al. Standards Track [Page 9]
+
+RFC 5729 Diameter Realm Routing Clarifications December 2009
+
+
+ [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
+ "Remote Authentication Dial In User Service (RADIUS)",
+ RFC 2865, June 2000.
+
+ [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
+ "Internationalizing Domain Names in Applications
+ (IDNA)", RFC 3490, March 2003.
+
+ [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
+ H. Levkowetz, Ed., "Extensible Authentication Protocol
+ (EAP)", RFC 3748, June 2004.
+
+ [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
+ "Diameter Network Access Server Application", RFC 4005,
+ August 2005.
+
+ [RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter
+ Extensible Authentication Protocol (EAP) Application",
+ RFC 4072, August 2005.
+
+ [RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen,
+ "Identity Selection Hints for the Extensible
+ Authentication Protocol (EAP)", RFC 4284, January 2006.
+
+ [RFC5113] Arkko, J., Aboba, B., Korhonen, J., Ed., and F. Bari,
+ "Network Discovery and Selection Problem", RFC 5113,
+ January 2008.
+
+ [WiMAX] WiMAX Forum, "WiMAX Forum Network Architecture (Stage
+ 2: Architecture Tenets, Reference Model and Reference
+ Points)", Release 1 Version 1.2, January 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Korhonen, et al. Standards Track [Page 10]
+
+RFC 5729 Diameter Realm Routing Clarifications December 2009
+
+
+Authors' Addresses
+
+ Jouni Korhonen (editor)
+ Nokia Siemens Networks
+ Linnoitustie 6
+ Espoo FIN-02600
+ Finland
+
+ EMail: jouni.nospam@gmail.com
+
+
+ Mark Jones
+ Bridgewater Systems
+ 303 Terry Fox Drive
+ Ottawa, Ontario K2K 3J1
+ Canada
+
+ EMail: Mark.Jones@bridgewatersystems.com
+
+
+ Lionel Morand
+ Orange Labs
+ 38-40 rue du general Leclerc
+ Issy-moulineaux Cedex 9, 92794
+ France
+
+ EMail: Lionel.morand@orange-ftgroup.com
+
+
+ Tina Tsou (Ting ZOU)
+ Huawei
+ R&D Center, Huawei Technologies Co., Ltd
+ Bantian, Shenzhen
+ P.R. China
+
+ EMail: tena@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Korhonen, et al. Standards Track [Page 11]
+