Internet Engineering Task Force T. Tsou
Internet-Draft Huawei Technologies (USA)
Updates: 6733 (if approved) R. Hao
Intended status: Standards Track Comcast Cable
Expires: December 21, 2013 T. Taylor, Ed.
Huawei Technologies
June 19, 2013
Realm-Based Redirection In Diameter
draft-ietf-dime-realm-based-redirect-09
Abstract
The Diameter protocol allows a Diameter redirect agent to return to
the message sender one or more individual hosts as destinations of
the redirected message. However, in some circumstances an operator
may wish to redirect messages to an alternate domain without
specifying individual hosts. This document specifies a mechanism by
which this can be achieved. New applications may incorporate this
capability by reference to the present document.
This memo updates Sections 6.13 and 6.14 of RFC6733 with respect to
the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time
AVPs.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 21, 2013.
Tsou, et al. Expires December 21, 2013 [Page 1]
Internet-Draft Realm-Based Redirection In Diameter June 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Support of Realm-Based Redirection Within
Applications . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Realm-Based Redirection . . . . . . . . . . . . . . . . . . . 3
3.1. Configuration of the Redirecting Server . . . . . . . . . 4
3.2. Behaviour of Diameter Nodes . . . . . . . . . . . . . . . 4
3.2.1. Behaviour at the Redirecting Server . . . . . . . . . 4
3.2.2. Proxy Behaviour . . . . . . . . . . . . . . . . . . . 5
3.2.3. Client Behaviour . . . . . . . . . . . . . . . . . . 6
3.3. The Redirect-Realm AVP . . . . . . . . . . . . . . . . . 6
3.4. DIAMETER_REDIRECT_INDICATION Protocol Error Code . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The usual redirect indication, as described in Section 6.1.8 and
Sections 6.12-6.14 of [RFC6733], returns to the message sender one or
more individual hosts as 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 redirect the request. However, the original operator
should be relieved from configuring in the redirect server a list of
hosts to contact in the alternative operator's domain, and should
Tsou, et al. Expires December 21, 2013 [Page 2]
Internet-Draft Realm-Based Redirection In Diameter June 2013
simply be able to provide redirect indications to the domain as a
whole.
Within this specification, the term "realm-based redirection" is used
to refer to a mode of operation where the redirect agent returns a
realm rather than an individual host as redirect indication.
1.1. Requirements Language
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].
2. Support of Realm-Based Redirection Within Applications
Because realm-based redirection is not part of the Diameter base
protocol [RFC6733], support of realm-based redirection by a Redirect
agent MUST be specified as part of functionality supported by a
Diameter application. In this way, support of the considered
Diameter application (discovered during capabilities exhange
procedures as defined in Diameter base protocol [RFC6733]) indicates
implicit support of the realm-based redirection mechanism. Designers
of new applications can incorporate the mechanism specified here into
their application by normative reference to this document.
The result of making realm-based redirection an application-specific
behaviour is that it cannot be performed by a redirect agent, but
instead must be performed by a redirect agent as defined in
[RFC6733], but instead by an application-aware Diameter node
(Diameter server or proxy). However, despite the change in executing
role, the behaviour itself is a slight modification of the behaviour
of a redirect agent as described in Section 2.8.3 of [RFC6733].
An application can specify that realm-based redirection operates only
on the initial message of a session, or on any message of a session.
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.
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 (3xxx TBD1);
o a new attribute-value pair (AVP), Redirect-Realm (code TBD2); and
Tsou, et al. Expires December 21, 2013 [Page 3]
Internet-Draft Realm-Based Redirection In Diameter June 2013
o associated behaviour at Diameter nodes implementing this
specification.
This behaviour 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 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 Redirecting Server
A Diameter node (Diameter server or proxy) acting as 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.
3.2. Behaviour of Diameter Nodes
3.2.1. Behaviour at the Redirecting Server
As mentioned in Section 2, an application incorporating realm-based
redirection may specify that redirection applies for any request or
only for the initial request of a session (i.e., to prevent
disruption of established sessions).
Tsou, et al. Expires December 21, 2013 [Page 4]
Internet-Draft Realm-Based Redirection In Diameter June 2013
If a redirecting server configured as described in Section 3.1
receives a request to which realm-based redirection applies, the
redirecting server MUST reply with an answer message with the 'E' bit
set, while maintaining the Hop-by-Hop Identifier in the header. The
redirecting server MUST include the Result-Code AVP set to
DIAMETER_REALM_REDIRECT_INDICATION. The redirecting server MUST also
include the alternate realm identifier(s) with which it has been
configured, each in a separate Redirect-Realm AVP instance.
The redirecting 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
redirecting 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].
If the redirected request contained a Destination-Host AVP, that
AVP is ignored by the redirecting server.
3.2.2. Proxy Behaviour
A proxy conforming to this specification that receives an answer
message with the Result-Code AVP set to
DIAMETER_REALM_REDIRECT_INDICATION MAY attempt to reroute the
original request to a server in a realm identified by a Redirect-
Realm AVP instance in the answer message, or MAY simply forward the
message toward the client. If it chooses 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].
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.
Tsou, et al. Expires December 21, 2013 [Page 5]
Internet-Draft Realm-Based Redirection In Diameter June 2013
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 Behaviour
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 both
to update its routing table and to obtain service for the original
request.
3.3. The Redirect-Realm AVP
The Redirect-Realm AVP (code TBD2) 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. The M
flag for the Redirect-Realm AVP MUST be set, and the V flag MUST NOT
be set.
3.4. DIAMETER_REDIRECT_INDICATION Protocol Error Code
The DIAMETER_REDIRECT_INDICATION (3xxx TBD1) 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.
4. Security Considerations
Realm-based redirection implies a change of the business
relationships between organizations. Before redirecting a request
towards a realm different to 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. To perform these authorization checks,
recommendations given in section 13 of the Diameter base protocol
[RFC6733] apply.
Tsou, et al. Expires December 21, 2013 [Page 6]
Internet-Draft Realm-Based Redirection In Diameter June 2013
5. IANA Considerations
This specification adds a new AVP code [TBD2] Redirect-Realm in the
AVP Code registry under Authentication, Authorization, and Accounting
(AAA) Parameters.
This specification allocates a new Result-Code value
DIAMETER_REALM_REDIRECT_INDICATION (3xxx TBD1) in the Result-Code AVP
Values (code 268) - Protocol Errors registry under Authentication,
Authorization, and Accounting (AAA) Parameters.
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.
7. 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.
Authors' Addresses
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
Email: Tina.Tsou.Zouting@huawei.com
URI: http://tinatsou.weebly.com/contact.html
Ruibing Hao
Comcast Cable
One Comcast Center
Philadelphia, PA 19103
USA
Phone: +1 215 286 3991(O)
Email: Ruibing_Hao@cable.comcast.com
Tsou, et al. Expires December 21, 2013 [Page 7]
Internet-Draft Realm-Based Redirection In Diameter June 2013
Tom Taylor (editor)
Huawei Technologies
Ottawa
Canada
Email: tom.taylor.stds@gmail.com
Tsou, et al. Expires December 21, 2013 [Page 8]