RFC 7075 - Realm-Based Redirection In Diameter 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7075
タイトル : RFC 7075 - 直径の領域ベースのリダイレクト
翻訳編集 : 自動生成

[要約] RFC 7075は、Diameterプロトコルにおける領域ベースのリダイレクションに関する仕様です。このRFCの目的は、Diameterネットワーク内でのリダイレクションの効率化と柔軟性の向上です。

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".

Diameterプロトコルには、アプリケーションに依存しない「リダイレクトエージェント」によって制御されるメッセージリダイレクト機能が含まれています。状況によっては、オペレーターは個々のホストを指定せずにメッセージを代替ドメインにリダイレクトしたい場合があります。このドキュメントでは、Diameterサーバーまたはプロキシ（ノード）がストレートネーミング認証局ポインタ（S-NAPTR）を動的ピア検出に使用しない場合に、このようなリダイレクトを実行できるアプリケーション固有のメカニズムを指定します。この新しい機能を実行するノードは、「レルムベースのリダイレクトサーバー」と呼ばれます。

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).

このメモは、Redirect-Host-UsageおよびRedirect-Max-Cache-Time Attribute-Value Pairs（AVP）の使用に関して、RFC 6733のセクション6.13および6.14を更新します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

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.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

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.

このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7075で入手できます。

著作権表示

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.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、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

1. Introduction

1. はじめに

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.

Diameter基本プロトコル[RFC6733]は、リダイレクトエージェントによって提供される基本的なリダイレクトサービスを指定します。リダイレクトエージェントによって返されるリダイレクト指示は、[RFC6733]のセクション6.1.8およびセクション6.12から6.14で説明されています。リダイレクトされたメッセージの宛先として、メッセージ送信者に1つ以上の個別のホストを提供します。

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

1.1. 用語

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].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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].

「レルムベースのリダイレクトサーバー」という用語は、レルムベースのリダイレクトを返すDiameterノード（Diameterサーバーまたはプロキシ）を意味します。 [RFC6733]のセクション6.1.8で説明されているように、レルムベースのリダイレクトサーバー自体の動作は、基本的なリダイレクトエージェントの動作にわずかな変更を加えたものです。

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.

このドキュメントでのいくつかの用語の使用は、[RFC6733]の使用法と一致しています：「Diameterクライアント」、「Diameterノード」、「Diameterピア」、「Diameterサーバー」、「プロキシ」、「レルム」または「ドメインセクション1.2で定義されている「」、「リダイレクトエージェント」、「セッション」、およびセクション1.3.4、2.3、2.4で暗黙的に定義されている「アプリケーション」。

2. Support of Realm-Based Redirection Within Applications

2. アプリケーション内でのレルムベースのリダイレクトのサポート

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.

Diameterベースプロトコル[RFC6733]で定義されているDNSベースの動的ピア検出メカニズムは、S-NAPTR DDDSアプリケーション[RFC3958]を使用したレルムベースのリダイレクトのためのシンプルなメカニズムを提供します。 S-NAPTRがピアディスカバリに使用される場合、Diameterリクエストの元のレルムから新しいレルムへのリダイレクトは、次のように元のレルムの既存のNAPTRリソースレコード（RR）を更新することで実行できます。目的のアプリケーションのNAPTR RR（ s）および新しいレルムによって提供されるサポートされるアプリケーションプロトコルには空のFLAGフィールドがあり、REPLACEMENTフィールドには次のDNSルックアップに使用する新しいレルムが含まれます。新しいレルムは任意にすることができます。 NAPTR置換フィールドが元のクエリのドメインと一致するという[RFC6733]の制限は、レルムベースのリダイレクトには適用されません。

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.

ただし、Diameter実装では、DNSベースの動的ピア検出の使用はオプションです。 S-NAPTRピアディスカバリを利用しない展開では、Diameterアプリケーションでサポートされる機能の一部として、レルムベースのリダイレクトのサポートを指定する必要があります。このように、検討されているDiameterアプリケーションのサポート（Diameter基本プロトコル[RFC6733]で定義されている機能交換フェーズで発見された）は、領域ベースのリダイレクトメカニズムの暗黙的なサポートを示しています。新しいアプリケーション仕様は、アプリケーションの実装を必須にし、この仕様を規範的に参照することにより、ここで指定されたメカニズムを組み込むことができます。

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").

レルムベースのリダイレクトをアプリケーション固有の動作にすると、[RFC6733]で定義されているリダイレクトエージェントでは実行できませんが、アプリケーション対応のDiameterノード（Diameterサーバーまたはプロキシ）では実行する必要があります（以下）。「レルムベースのリダイレクトサーバー」と呼ばれます）。

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.

同じセッションの以前のメッセージがリダイレクトされなかった場合でも、アプリケーションは、レルムベースのリダイレクトが最初のメッセージで始まる完全なセッションまたはアプリケーション内のすべてのメッセージでのみ動作するように指定できます。この区別は、領域ベースのリダイレクトが最初に開始されるときにのみ重要です。前者の場合、レルムベースのリダイレクトの展開によって既存のセッションが中断されることはありません。後者の場合、既存のセッションは、ステートフルであると中断されます。

3. Realm-Based Redirection

3. レルムベースのリダイレクト

This section specifies an extension of the Diameter base protocol [RFC6733] to achieve realm-based redirection. The elements of this solution are:

このセクションでは、Diameter基本プロトコル[RFC6733]の拡張を指定して、領域ベースのリダイレクトを実現します。このソリューションの要素は次のとおりです。

o a new result code, DIAMETER_REALM_REDIRECT_INDICATION (3011);

o 新しい結果コード、DIAMETER_REALM_REDIRECT_INDICATION（3011）;

o a new attribute-value pair (AVP), Redirect-Realm (620); and

o 新しい属性と値のペア（AVP）、Redirect-Realm（620）。そして

o associated behavior at Diameter nodes implementing this specification.

o この仕様を実装するDiameterノードでの関連する動作。

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].

この動作には、Redirect-Host-UsageおよびRedirect-Max-Cache-Time AVPのオプションの使用が含まれます。このドキュメントでは、これらのAVPは、[RFC6733]のセクション6.13および6.14で説明されている通常の使用法の拡張である、リダイレクトサーバーの応答で動作するノードによって検出されたピアに適用されます。

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.2.2およびセクション3.2.3では、レルムベースのリダイレクト後に新しいレルムでピアを選択した結果として、プロキシまたはクライアントがアプリケーションと初期レルムのルーティングテーブルを更新する方法について説明します。その結果、キャッシュまたはルーティングエントリが期限切れになるまで、プロキシまたはクライアントは、そのアプリケーションの後続のリクエストを新しいレルムに自動的にルーティングします（初期レルムですでに確立されているセッション内のリクエストは例外です）。再ルーティングが一時的なものである場合は、これに注意する必要があります。

3.1. Configuration of the Realm-Based Redirect Server

3.1. レルムベースのリダイレクトサーバーの構成

A Diameter node (Diameter server or proxy) acting as a Realm-based Redirect Server MUST be configured as follows to execute realm-based redirection:

レルムベースのリダイレクトサーバーとして機能するDiameterノード（Diameterサーバーまたはプロキシ）は、レルムベースのリダイレクトを実行するために次のように構成する必要があります。

o configured with an application that incorporates realm-based redirection;

o レルムベースのリダイレクトを組み込むアプリケーションで構成されます。

o the Local Action field of the routing table described in Section 2.7 of [RFC6733] is set to LOCAL;

o [RFC6733]のセクション2.7で説明されているルーティングテーブルのローカルアクションフィールドはローカルに設定されています。

o an application-specific field is set to indicate that the required local action is to perform realm-based redirection;

o アプリケーション固有のフィールドは、必要なローカルアクションがレルムベースのリダイレクトの実行であることを示すために設定されます。

o an associated application-specific field is configured with the identities of one or more realms to which the request should be redirected.

o 関連するアプリケーション固有のフィールドには、リクエストのリダイレクト先となる1つ以上のレルムのIDが設定されています。

3.2. Behavior of Diameter Nodes

3.2. Diameterノードの動作

3.2.1. Behavior at the Realm-Based Redirect Server

3.2.1. レルムベースのリダイレクトサーバーでの動作

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.

セクション2で述べたように、アプリケーションは、レルムベースのリダイレクトが最初のメッセージで始まる完全なセッションでのみ動作するように指定できます（つまり、確立されたセッションの中断を防ぐため）、または同じ内の以前のメッセージであっても、アプリケーション内のすべてのメッセージでセッションはリダイレクトされませんでした。

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.

セクション3.1で説明されているように構成されたレルムベースのリダイレクトサーバーが、レルムベースのリダイレクトが適用される要求を受信した場合、レルムベースのリダイレクトサーバーは、ホップバイを維持しながら、「E」ビットが設定された応答メッセージで応答する必要があります。ヘッダーの-Hop識別子。レルムベースのリダイレクトサーバーには、DIAMETER_REALM_REDIRECT_INDICATIONに設定されたResult-Code AVPを含める必要があります。レルムベースのリダイレクトサーバーには、別のリダイレクトレルムAVPインスタンスに構成されている代替レルム識別子も含める必要があります。

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].

レルムベースのリダイレクトサーバーには、リダイレクトホストの使用AVPのコピーを含めることができます。これは、REALM_AND_APPLICATIONに設定する必要があります（SHOULD）。このAVPを追加する場合は、Redirect-Max-Cache-Time AVPも含める必要があります。これらのAVPは、次のセクションで説明するように、レルムベースのリダイレクトサーバーの応答で動作するノードによって検出されたピアに適用されることに注意してください。これは、[RFC6733]のセクション6.13および6.14で説明されている通常の使用法の拡張です。

Realm-based redirection MAY be applied even if a Destination-Host AVP is present in the request, depending on the operator-based policy.

オペレーターベースのポリシーに応じて、要求に宛先ホストAVPが存在する場合でも、レルムベースのリダイレクトが適用される場合があります。

3.2.2. Proxy Behavior

3.2.2. プロキシの動作

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:

Result-Code AVPがDIAMETER_REALM_REDIRECT_INDICATIONに設定された応答メッセージを受信するこの仕様に準拠するプロキシは、元の要求を、応答メッセージのRedirect-Realm AVPインスタンスによって識別されるレルム内のサーバーに再ルーティングする必要があり、失敗した場合インジケーションをクライアントに転送する必要があります。リクエストを再ルーティングするには、次のアクションを実行する必要があります。

1. Select a specific realm from amongst those identified in instances of the Redirect-Realm AVP in the answer message.

1. 応答メッセージのリダイレクトレルムAVPのインスタンスで識別されたレルムの中から特定のレルムを選択します。

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].

2. 成功した場合は、[RFC6733]のセクション5.2で説明されている通常の検出手順を使用して、リダイレクトレルムAVPによって指定されたレルム内のピアへのルートを見つけて確立します。

3. If again successful:

3. 再び成功した場合：

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.

A.応答に存在する場合はRedirect-Host-UsageおよびRedirect-Max-Cache-Time AVPを考慮に入れて、元の要求が向けられたレルムおよびアプリケーションのルーティングエントリのキャッシュを更新します。

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.

B. Destination-Host（存在する場合）とDestination-Realm AVPを元のリクエストから削除し、最初のステップで選択したレルムを含む新しいDestination-Realm AVPを追加します。

C. Forward the modified request.

C.変更された要求を転送します。

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.

4. 上記の手順2〜3のいずれかが失敗し、元の回答で追加のレルムが特定されている場合は、その回答でリダイレクトレルムAVPの別のインスタンスを選択し、特定されたレルムに対して手順2〜3を繰り返します。

3.2.3. Client Behavior

3.2.3. クライアントの動作

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.

この仕様に準拠するクライアントは、DIAMETER_REALM_REDIRECT_INDICATIONに設定されたResult-Code AVPを含む応答メッセージ、またはプロキシアクションの結果として、元の送信先とは異なるレルムからの他の結果を受信する準備ができていなければなりません（MUST）。リクエスト。 DIAMETER_REALM_REDIRECT_INDICATIONを受信する場合、クライアントは、ルーティングテーブルを更新し、元の要求のサービスを取得するために、プロキシについて前のセクションで規定されたのと同じ手順に従う必要があります（SHOULD）。

3.3. The Redirect-Realm AVP

3.3. リダイレクトレルム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.

Redirect-Realm AVP（620）のタイプはDiameterIdentityです。これは、結果コード値DIAMETER_REALM_REDIRECT_INDICATIONとリダイレクトレルムAVPを含むリダイレクト指示を受信するノードが元のリクエストをルーティングするレルムを指定します。

3.4. DIAMETER_REALM_REDIRECT_INDICATION Protocol Error Code

3.4. DIAMETER_REALM_REDIRECT_INDICATIONプロトコルエラーコード

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.

DIAMETER_REALM_REDIRECT_INDICATION（3011）プロトコルエラーコードは、レルムベースのリダイレクトをサポートするアプリケーション内の要求がローカルで満たされなかったとサーバーが判断したことを示し、要求のイニシエーターは、要求をレルム内のピアに直接送信する必要があります（SHOULD）。応答で識別されました。設定されると、リダイレクトレルムAVPが存在する必要があります。

4. Security Considerations

4. セキュリティに関する考慮事項

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.

Diameter基本プロトコル[RFC6733]のセクション13に記載されている一般的な推奨事項が適用されます。このドキュメントで定義されているレルムベースのリダイレクトに関連する特定のセキュリティ推奨事項を以下に説明します。

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.

レルムベースのリダイレクトは、組織間のビジネス関係の変化を意味します。最初のレルムとは異なるレルムに要求をリダイレクトする前に、クライアントまたはプロキシは、レルムベースのリダイレクト指示で識別されたレルムに向かうパスに沿った各接続で承認チェックが実行されていることを確認する必要があります。 Diameter承認パスのセットアップの詳細は、[RFC6733]のセクション2.9に記載されています。 [RFC6733]のセクション13は、途中で（TLS、DTLS、またはIPsecを使用して）各ピアツーピア接続を認証および保護し、必要なホップバイホップの承認チェックを許可する方法に関する推奨事項を提供します。

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.

管理ドメインは安全であると想定されていますが、レルムベースのリダイレクトサーバーとして機能する侵害されたDiameterノードは、多数のDiameterリクエストを被害者のドメインにリダイレクトし、望ましくないDiameterリクエストで溢れる可能性があります。それでも、このような攻撃は、セキュアなDiameterピアツーピア接続と承認チェックを使用することで推奨されません。これらの攻撃により、潜在的な被害者ドメインが攻撃の発信元を発見できるようになるためです。ただし、それ自体では、このようなDoS攻撃を防ぐことはできません。

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.

このドキュメントで定義されているレルムベースのリダイレクトは、クライアントが開始したリクエストの宛先レルムAVPが、クライアントとサーバー間のパスにあるDiameterプロキシによって変更できることを意味するため、宛先レルムAVPを使用する暗号化アルゴリズムクライアントとサーバーが実行する計算への入力は、この形式のリダイレクトによって壊れます。そのような暗号化アルゴリズムに依存するアプリケーション仕様は、このレルムベースのリダイレクトを組み込んではいけません（SHOULD NOT）。

5. IANA Considerations

5. IANAに関する考慮事項

This specification allocates a new AVP code Redirect-Realm (620) in the "AVP Codes" registry under "Authentication, Authorization, and Accounting (AAA) Parameters".

この仕様では、「AVP Codes」レジストリの「Authentication、Authorization、and Accounting（AAA）Parameters」にある新しいAVPコードRedirect-Realm（620）を割り当てます。

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".

この仕様は、新しいResult-Code値DIAMETER_REALM_REDIRECT_INDICATION（3011）を「Authentication、Authorization、and Accounting（AAA）Parameters」の「Result-Code AVP Values（code 268）-Protocol Errors」レジストリに割り当てます。

6. Acknowledgements

6. 謝辞

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.

Glen Zorn、Sebastien Decugis、Wolfgang Steigerwald、Mark Jones、Victor Fajardo、Jouni Korhonen、Avi Lior、Lionel Morandは、このドキュメントの作成に役立つコメントを寄せてくれました。羊飼いとして、ライオネルはIESGに提出される前にドキュメントに磨きをかける2番目のコメントセットを提供しました。 Benoit Claiseは、Lionelの助けを借りてすぐに解決された追加のポイントをピックアップしました。 IETFラストコールレビュー中に、エンリコマロッコはいくつかの重要な編集上の修正をピックアップしました。 Stefan Winterは、[RFC6733]ですでに指定されている領域ベースのリダイレクトの代替方法としてS-NAPTRの使用に関するテキストを寄稿しました。 Derek Atkinsがセキュリティ総局に代わってレビューを行いました。ライオネルはもう1つの訂正を指摘しました。

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.

最後に、このドキュメントは、IESGのレビュー中にIESGメンバーのスチュワートブライアント、スティーブンファレル、バリーレイバ、ピートレズニック、ジャリアルコ、ショーンターナーが提起したコメントと議論の恩恵を受けました。

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.

著者は、ドキュメントシェパードとしての積極的な役割について、Lionel Morandに非常に感謝しています。各段階で、コメントの要約と解決に取り組み、編集者の役割を容易にしました。ありがとうございました。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012.

[RFC6733] Fajardo、V.、Arkko、J.、Loughney、J。、およびG. Zorn、「Diameter Base Protocol」、RFC 6733、2012年10月。

7.2. Informative References

7.2. 参考引用

[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.

[RFC3958] Daigle、L。およびA. Newton、「SRV RRおよび動的委任検出サービス（DDDS）を使用したドメインベースのアプリケーションサービスロケーション」、RFC 3958、2005年1月。

Authors' Addresses

著者のアドレス

Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA

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

R UIおよびha O Comcastケーブル1つComcastセンターフィラデルフィア、PA 19103米国

   Phone: +1 215 286 3991(O)
   EMail: Ruibing_Hao@cable.comcast.com

Tom Taylor (editor) Huawei Technologies Ottawa Canada

Tom Taylor（編集者）Huawei Technologiesオタワカナダ

   EMail: tom.taylor.stds@gmail.com