aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/doc/standard/rfc7075.txt
diff options
context:
space:
mode:
authorAnders Svensson <[email protected]>2013-11-30 16:48:31 +0100
committerAnders Svensson <[email protected]>2013-11-30 20:04:54 +0100
commitbf848b6613813faa488b259228b62f24eb8655fd (patch)
treec3b6104e977f9125fd4a84c56a609c66169f288b /lib/diameter/doc/standard/rfc7075.txt
parentfce38d77ec95261ec7ae3694d0b5db91f1cb39c2 (diff)
downloadotp-bf848b6613813faa488b259228b62f24eb8655fd.tar.gz
otp-bf848b6613813faa488b259228b62f24eb8655fd.tar.bz2
otp-bf848b6613813faa488b259228b62f24eb8655fd.zip
Add recent Diameter-related RFCs
Diffstat (limited to 'lib/diameter/doc/standard/rfc7075.txt')
-rw-r--r--lib/diameter/doc/standard/rfc7075.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/lib/diameter/doc/standard/rfc7075.txt b/lib/diameter/doc/standard/rfc7075.txt
new file mode 100644
index 0000000000..f5fd905e72
--- /dev/null
+++ b/lib/diameter/doc/standard/rfc7075.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) T. Tsou
+Request for Comments: 7075 Huawei Technologies (USA)
+Updates: 6733 R. Hao
+Category: Standards Track Comcast Cable
+ISSN: 2070-1721 T. Taylor, Ed.
+ Huawei Technologies
+ November 2013
+
+
+ Realm-Based Redirection In Diameter
+
+Abstract
+
+ The Diameter protocol includes a capability for message redirection,
+ controlled by an application-independent "redirect agent". In some
+ circumstances, an operator may wish to redirect messages to an
+ alternate domain without specifying individual hosts. This document
+ specifies an application-specific mechanism by which a Diameter
+ server or proxy (node) can perform such a redirection when the
+ Straightforward-Naming Authority Pointer (S-NAPTR) is not used for
+ dynamic peer discovery. A node performing this new function is
+ referred to as a "Realm-based Redirect Server".
+
+ This memo updates Sections 6.13 and 6.14 of RFC 6733 with respect to
+ the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time
+ Attribute-Value Pairs (AVPs).
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7075.
+
+
+
+
+
+
+
+
+
+
+
+Tsou, et al. Standards Track [Page 1]
+
+RFC 7075 Realm-Based Redirection In Diameter November 2013
+
+
+Copyright Notice
+
+ Copyright (c) 2013 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 Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Support of Realm-Based Redirection Within Applications . . . 4
+ 3. Realm-Based Redirection . . . . . . . . . . . . . . . . . . . 5
+ 3.1. Configuration of the Realm-Based Redirect Server . . . . 5
+ 3.2. Behavior of Diameter Nodes . . . . . . . . . . . . . . . 6
+ 3.2.1. Behavior at the Realm-Based Redirect Server . . . . . 6
+ 3.2.2. Proxy Behavior . . . . . . . . . . . . . . . . . . . 6
+ 3.2.3. Client Behavior . . . . . . . . . . . . . . . . . . . 7
+ 3.3. The Redirect-Realm AVP . . . . . . . . . . . . . . . . . 7
+ 3.4. DIAMETER_REALM_REDIRECT_INDICATION Protocol Error Code . 7
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
+ 7.2. Informative References . . . . . . . . . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsou, et al. Standards Track [Page 2]
+
+RFC 7075 Realm-Based Redirection In Diameter November 2013
+
+
+1. Introduction
+
+ The Diameter base protocol [RFC6733] specifies a basic redirection
+ service provided by a redirect agent. The redirect indication
+ returned by the redirect agent is described in Section 6.1.8 and
+ Sections 6.12 through 6.14 of [RFC6733]. It provides one or more
+ individual hosts to the message sender as the destination of the
+ redirected message.
+
+ However, consider the case where an operator has offered a specific
+ service but no longer wishes to do so. The operator has arranged for
+ an alternative domain to provide the service. To aid in the
+ transition to the new arrangement, the original operator maintains a
+ redirect server to indicate to the message sender the alternative
+ domain to which the redirect the request should be sent. However,
+ the original operator should not have to configure the redirect
+ server with a list of hosts to contact in the alternative operator's
+ domain; the original operator should simply be able to provide
+ redirect indications to the domain as a whole.
+
+1.1. Terminology
+
+ 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].
+
+ Within this specification, the term "realm-based redirection" is used
+ to refer to a mode of operation where a realm, rather than an
+ individual host, is returned as the redirect indication.
+
+ The term "Realm-based Redirect Server" denotes the Diameter node
+ (Diameter server or proxy) that returns the realm-based redirection.
+ The behavior of the Realm-based Redirect Server itself is a slight
+ modification to the behavior of a basic redirect agent as described
+ in Section 6.1.8 of [RFC6733].
+
+ The use of a number of terms in this document is consistent with the
+ usage in [RFC6733]: "Diameter client", "Diameter node", "Diameter
+ peer", "Diameter server", "proxy", "realm" or "domain", "redirect
+ agent", and "session" as defined in Section 1.2, and "application" as
+ defined implicitly by Sections 1.3.4, 2.3, and 2.4.
+
+
+
+
+
+
+
+
+
+
+Tsou, et al. Standards Track [Page 3]
+
+RFC 7075 Realm-Based Redirection In Diameter November 2013
+
+
+2. Support of Realm-Based Redirection Within Applications
+
+ The DNS-based dynamic peer discovery mechanism defined in the
+ Diameter base protocol [RFC6733] provides a simple mechanism for
+ realm-based redirection using the S-NAPTR DDDS application [RFC3958].
+ When S-NAPTR is used for peer discovery, redirection of Diameter
+ requests from the original realm to a new realm may be performed by
+ updating the existing NAPTR resource records (RRs) for the original
+ realm as follows: the NAPTR RR for the desired application(s) and
+ supported application protocol(s) provided by the new realm will have
+ an empty FLAG field and the REPLACEMENT field will contain the new
+ realm to use for the next DNS lookup. The new realm can be
+ arbitrary; the restriction in [RFC6733] that the NAPTR replacement
+ field match the domain of the original query does not apply for
+ realm-based redirect purposes.
+
+ However, the use of DNS-based dynamic peer discovery is optional for
+ Diameter implementations. For deployments that do not make use of
+ S-NAPTR peer discovery, support of realm-based redirection needs to
+ be specified as part of the functionality supported by a Diameter
+ application. In this way, support of the considered Diameter
+ application (discovered during capabilities exchange phase as defined
+ in Diameter base protocol [RFC6733]) indicates implicit support of
+ the realm-based redirection mechanism. A new application
+ specification can incorporate the mechanism specified here by making
+ it mandatory to implement for the application and referencing this
+ specification normatively.
+
+ The result of making realm-based redirection an application-specific
+ behavior is that it cannot be performed by a redirect agent as
+ defined in [RFC6733], but MUST be performed instead by an
+ application-aware Diameter node (Diameter server or proxy) (hereafter
+ called a "Realm-based Redirect Server").
+
+ An application can specify that realm-based redirection operates only
+ on complete sessions beginning with the initial message or on every
+ message within the application, even if earlier messages of the same
+ session were not redirected. This distinction matters only when
+ realm-based redirection is first initiated. In the former case,
+ existing sessions will not be disrupted by the deployment of realm-
+ based redirection. In the latter case, existing sessions will be
+ disrupted if they are stateful.
+
+
+
+
+
+
+
+
+
+Tsou, et al. Standards Track [Page 4]
+
+RFC 7075 Realm-Based Redirection In Diameter November 2013
+
+
+3. Realm-Based Redirection
+
+ This section specifies an extension of the Diameter base protocol
+ [RFC6733] to achieve realm-based redirection. The elements of this
+ solution are:
+
+ o a new result code, DIAMETER_REALM_REDIRECT_INDICATION (3011);
+
+ o a new attribute-value pair (AVP), Redirect-Realm (620); and
+
+ o associated behavior at Diameter nodes implementing this
+ specification.
+
+ This behavior includes the optional use of the Redirect-Host-Usage
+ and Redirect-Max-Cache-Time AVPs. In this document, these AVPs apply
+ to the peer discovered by a node acting on the redirect server's
+ response, an extension to their normal usage as described in Sections
+ 6.13 and 6.14 of [RFC6733].
+
+ Section 3.2.2 and Section 3.2.3 describe how a proxy or client may
+ update its routing table for the application and initial realm as a
+ result of selecting a peer in the new realm after realm-based
+ redirection. Note that as a result, the proxy or client will
+ automatically route subsequent requests for that application to the
+ new realm (with the possible exception of requests within sessions
+ already established with the initial realm) until the cached routing
+ entry expires. This should be borne in mind if the rerouting is
+ intended to be temporary.
+
+3.1. Configuration of the Realm-Based Redirect Server
+
+ A Diameter node (Diameter server or proxy) acting as a Realm-based
+ Redirect Server MUST be configured as follows to execute realm-based
+ redirection:
+
+ o configured with an application that incorporates realm-based
+ redirection;
+
+ o the Local Action field of the routing table described in
+ Section 2.7 of [RFC6733] is set to LOCAL;
+
+ o an application-specific field is set to indicate that the required
+ local action is to perform realm-based redirection;
+
+ o an associated application-specific field is configured with the
+ identities of one or more realms to which the request should be
+ redirected.
+
+
+
+
+Tsou, et al. Standards Track [Page 5]
+
+RFC 7075 Realm-Based Redirection In Diameter November 2013
+
+
+3.2. Behavior of Diameter Nodes
+
+3.2.1. Behavior at the Realm-Based Redirect Server
+
+ As mentioned in Section 2, an application can specify that realm-
+ based redirection operates only on complete sessions beginning with
+ the initial message (i.e., to prevent disruption of established
+ sessions) or on every message within the application, even if earlier
+ messages of the same session were not redirected.
+
+ If a Realm-based Redirect Server configured as described in
+ Section 3.1 receives a request to which realm-based redirection
+ applies, the Realm-based Redirect Server MUST reply with an answer
+ message with the 'E' bit set, while maintaining the Hop-by-Hop
+ Identifier in the header. The Realm-based Redirect Server MUST
+ include the Result-Code AVP set to
+ DIAMETER_REALM_REDIRECT_INDICATION. The Realm-based Redirect Server
+ MUST also include the alternate realm identifier(s) with which it has
+ been configured, each in a separate Redirect-Realm AVP instance.
+
+ The Realm-based Redirect Server MAY include a copy of the Redirect-
+ Host-Usage AVP, which SHOULD be set to REALM_AND_APPLICATION. If
+ this AVP is added, the Redirect-Max-Cache-Time AVP MUST also be
+ included. Note that these AVPs apply to the peer discovered by a
+ node acting on the Realm-based Redirect Server's response as
+ described in the next section. This is an extension of their normal
+ usage as described by Sections 6.13 and 6.14 of [RFC6733].
+
+ Realm-based redirection MAY be applied even if a Destination-Host
+ AVP is present in the request, depending on the operator-based
+ policy.
+
+3.2.2. Proxy Behavior
+
+ A proxy conforming to this specification that receives an answer
+ message with the Result-Code AVP set to
+ DIAMETER_REALM_REDIRECT_INDICATION MUST attempt to reroute the
+ original request to a server in a realm identified by a Redirect-
+ Realm AVP instance in the answer message, and if it fails MUST
+ forward the indication toward the client. To reroute the request, it
+ MUST take the following actions:
+
+ 1. Select a specific realm from amongst those identified in
+ instances of the Redirect-Realm AVP in the answer message.
+
+ 2. If successful, locate and establish a route to a peer in the
+ realm given by the Redirect-Realm AVP, using normal discovery
+ procedures as described in Section 5.2 of [RFC6733].
+
+
+
+Tsou, et al. Standards Track [Page 6]
+
+RFC 7075 Realm-Based Redirection In Diameter November 2013
+
+
+ 3. If again successful:
+
+ A. update its cache of routing entries for the realm and
+ application to which the original request was directed,
+ taking into account the Redirect-Host-Usage and Redirect-Max-
+ Cache-Time AVPs, if present in the answer.
+
+ B. Remove the Destination-Host (if present) and Destination-
+ Realm AVPs from the original request and add a new
+ Destination-Realm AVP containing the realm selected in the
+ initial step.
+
+ C. Forward the modified request.
+
+ 4. If either of the preceding steps 2-3 fail and additional realms
+ have been identified in the original answer, select another
+ instance of the Redirect-Realm AVP in that answer and repeat
+ steps 2-3 for the realm that it identifies.
+
+3.2.3. Client Behavior
+
+ A client conforming to this specification MUST be prepared to receive
+ either an answer message containing a Result-Code AVP set to
+ DIAMETER_REALM_REDIRECT_INDICATION, or, as the result of proxy
+ action, some other result from a realm differing from the one to
+ which it sent the original request. In the case where it receives
+ DIAMETER_REALM_REDIRECT_INDICATION, the client SHOULD follow the same
+ steps prescribed in the previous section for a proxy, in order to
+ both update its routing table and obtain service for the original
+ request.
+
+3.3. The Redirect-Realm AVP
+
+ The Redirect-Realm AVP (620) is of type DiameterIdentity. It
+ specifies a realm to which a node receiving a redirect indication
+ containing the result code value DIAMETER_REALM_REDIRECT_INDICATION
+ and the Redirect-Realm AVP SHOULD route the original request.
+
+3.4. DIAMETER_REALM_REDIRECT_INDICATION Protocol Error Code
+
+ The DIAMETER_REALM_REDIRECT_INDICATION (3011) Protocol error code
+ indicates that a server has determined that the request within an
+ application supporting realm-based redirection could not be satisfied
+ locally, and the initiator of the request SHOULD direct the request
+ directly to a peer within a realm that has been identified in the
+ response. When set, the Redirect-Realm AVP MUST be present.
+
+
+
+
+
+Tsou, et al. Standards Track [Page 7]
+
+RFC 7075 Realm-Based Redirection In Diameter November 2013
+
+
+4. Security Considerations
+
+ The general recommendations given in Section 13 of the Diameter base
+ protocol [RFC6733] apply. Specific security recommendations related
+ to the realm-based redirection defined in this document are described
+ below.
+
+ Realm-based redirection implies a change in the business relationship
+ between organizations. Before redirecting a request towards a realm
+ different from the initial realm, the client or proxy MUST ensure
+ that the authorization checks have been performed at each connection
+ along the path toward the realm identified in the realm-based
+ redirect indication. Details on Diameter authorization path set-up
+ are given in Section 2.9 of [RFC6733]. Section 13 of [RFC6733]
+ provides recommendations on how to authenticate and secure each peer-
+ to-peer connection (using TLS, DTLS, or IPsec) along the way, thus
+ permitting the necessary hop-by-hop authorization checks.
+
+ Although it is assumed that the administrative domains are secure, a
+ compromised Diameter node acting as a Realm-based Redirect Server
+ would be able to redirect a large number of Diameter requests towards
+ a victim domain that would then be flooded with undesired Diameter
+ requests. Such an attack is nevertheless discouraged by the use of
+ secure Diameter peer-to-peer connections and authorization checks,
+ since these would enable a potential victim domain to discover from
+ where an attack is coming. That in itself, however, does not prevent
+ such a DoS attack.
+
+ Because realm-based redirection defined in this document implies that
+ the Destination-Realm AVP in a client-initiated request can be
+ changed by a Diameter proxy in the path between the client and the
+ server, any cryptographic algorithm that would use the Destination-
+ Realm AVP as input to the calculation performed by the client and the
+ server would be broken by this form of redirection. Application
+ specifications that would rely on such cryptographic algorithms
+ SHOULD NOT incorporate this realm-based redirection.
+
+5. IANA Considerations
+
+ This specification allocates a new AVP code Redirect-Realm (620) in
+ the "AVP Codes" registry under "Authentication, Authorization, and
+ Accounting (AAA) Parameters".
+
+ This specification allocates a new Result-Code value
+ DIAMETER_REALM_REDIRECT_INDICATION (3011) in the "Result-Code AVP
+ Values (code 268) - Protocol Errors" registry under "Authentication,
+ Authorization, and Accounting (AAA) Parameters".
+
+
+
+
+Tsou, et al. Standards Track [Page 8]
+
+RFC 7075 Realm-Based Redirection In Diameter November 2013
+
+
+6. Acknowledgements
+
+ Glen Zorn, Sebastien Decugis, Wolfgang Steigerwald, Mark Jones,
+ Victor Fajardo, Jouni Korhonen, Avi Lior, and Lionel Morand
+ contributed comments that helped to shape this document. As
+ shepherd, Lionel contributed a second set of comments that added
+ polish to the document before it was submitted to the IESG. Benoit
+ Claise picked up additional points that were quickly resolved with
+ Lionel's help. During IETF Last Call Review, Enrico Marocco picked
+ up some important editorial corrections. Stefan Winter contributed
+ text on the use of S-NAPTR as an alternative method of realm-based
+ redirection already specified in [RFC6733]. Derek Atkins performed a
+ review on behalf of the Security Directorate. Lionel noted one more
+ correction.
+
+ Finally, this document benefited from comments and discussion raised
+ by IESG members Stewart Bryant, Stephen Farrell, Barry Leiba, Pete
+ Resnick, Jari Arkko, and Sean Turner during IESG review.
+
+ The authors are very grateful to Lionel Morand for his active role as
+ document shepherd. At each stage, he worked to summarize and resolve
+ comments, making the editor's role easy. Thank you.
+
+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.
+
+ [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
+ "Diameter Base Protocol", RFC 6733, October 2012.
+
+7.2. Informative References
+
+ [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
+ Service Location Using SRV RRs and the Dynamic Delegation
+ Discovery Service (DDDS)", RFC 3958, January 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsou, et al. Standards Track [Page 9]
+
+RFC 7075 Realm-Based Redirection In Diameter November 2013
+
+
+Authors' Addresses
+
+ Tina Tsou
+ Huawei Technologies (USA)
+ 2330 Central Expressway
+ Santa Clara, CA 95050
+ USA
+
+ Phone: +1 408 330 4424
+ URI: http://tinatsou.weebly.com/contact.html
+
+
+ Ruibing Hao
+ Comcast Cable
+ One Comcast Center
+ Philadelphia, PA 19103
+ USA
+
+ Phone: +1 215 286 3991(O)
+
+
+ Tom Taylor (editor)
+ Huawei Technologies
+ Ottawa
+ Canada
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsou, et al. Standards Track [Page 10]
+