Independent Submission T. Tsou
Request for Comments: 6159 Huawei Technologies (USA)
Category: Informational G. Zorn
ISSN: 2070-1721 Network Zen
T. Taylor, Ed.
Huawei Technologies
April 2011
Session-Specific Explicit Diameter Request Routing
Abstract
抽象
This document describes a mechanism to enable specific Diameter proxies to remain in the path of all message exchanges constituting a Diameter session.
この文書は、Diameterセッションを構成する全てのメッセージ交換の経路内に残留する特定のDiameterプロキシを有効にするメカニズムを説明しています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 RFC編集者によって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 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/rfc6159.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6159で取得することができます。
IESG Note
IESG注意
Techniques similar to those discussed in this document were discussed in the IETF Diameter Maintenance and Extensions (DIME) Working Group. The group had no consensus that the problems addressed by such work are a real concern in Diameter deployments. Furthermore, there was no consensus that the proposed solutions are in line with the architectural principles of the Diameter protocol. As a result, the working group decided not to undertake the work. There has also not been a formal request for this functionality from any standards body. This RFC represents a continuation of the abandoned work. Readers of this specification should be aware that the IETF has not reviewed this specification and cannot say anything about suitability for a particular purpose or compatibility with the Diameter architecture and other extensions.
この文書で説明したものと同様の技術は、IETF直径メンテナンスと拡張機能（DIME）ワーキンググループで議論されました。グループは、このような作業によって対処問題は直径展開で現実的な懸念であることはコンセンサスがありませんでした。さらに、提案された解決策は、Diameterプロトコルのアーキテクチャの原則に沿ったものであるというコンセンサスは存在しませんでした。その結果、ワーキンググループが作業に着手しないことを決定しました。また、任意の標準化団体から、この機能のための正式な要請がなかったです。このRFCは放棄され、作業の継続を表します。この仕様書の読者は、IETFは、この仕様を検討していないと直径アーキテクチャと他の拡張子を持つ特定の目的や互換性のための適合性については何も言うことができないことに注意する必要があります。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. The 3GPP Wireless LAN (WLAN) Access Architecture ................4
3.1. Maintaining the Routing Path ...............................5
4. Diameter Explicit Routing (ER) ..................................6
4.1. Originating a Request (ER-Originator) ......................6
4.2. Relaying and Proxying Requests (ER-Proxy) ..................8
4.3. Receiving Requests (ER-Destination) .......................10
4.4. Diameter Answer Processing ................................11
4.5. Failover and Failback Considerations ......................12
4.6. Attribute-Value Pairs .....................................12
4.6.1. Explicit-Path-Record AVP ...........................12
4.6.1.1. Proxy-Host AVP ............................13
4.6.1.2. Proxy-Realm AVP ...........................13
4.6.2. Explicit-Path AVP ..................................13
4.7. Error Handling ............................................13
5. Example Message Flow ...........................................14
6. RADIUS/Diameter Protocol Interactions ..........................16
7. Security Considerations ........................................17
8. Acknowledgements ...............................................17
9. References .....................................................18
9.1. Normative References ......................................18
9.2. Informative References ....................................18
In the Diameter base protocol [RFC3588], the routing of request messages is based solely on the routing decisions made separately by each node along the path. [RFC5729] has added the ability to force messages to pass through a specified set of realms through the use of Network Access Identifier (NAI) decoration. However, no other specification provides the ability to force routing through a specific set of agents. Therefore, in a topology where multiple paths exist from source to destination, there is no guarantee that all messages relating to a given session will take the same path. In general, this has not caused problems, but some architectures (e.g., WLAN Third Generation Partnership Project (3GPP) IP access [TS23.234]) require that once certain agents become engaged in a session, they be able to process all subsequent messages for that session.
直径ベースプロトコル[RFC3588]において、要求メッセージのルーティングは、経路に沿った各ノードが別々に作られたルーティングの決定のみに基づいています。 [RFC5729]は、ネットワークアクセス識別子（NAI）の装飾を使用することによってレルムの指定されたセットを通過するメッセージを強制する機能を追加しました。しかしながら、他の仕様では、薬剤の特定のセットを介してルーティングを強制する能力を提供しません。したがって、複数のパスがソースから宛先に存在するトポロジでは、所与のセッションに関連するすべてのメッセージが同じ経路をとるという保証はありません。一般的には、これが問題を引き起こしたが、いなかったいくつかのアーキテクチャ（例えば、WLAN、第3世代パートナーシップ・プロジェクト（3GPP）IPアクセス[TS23.234]）を1回、特定のエージェントがセッションに従事なって、彼らはそれ以降のすべてのメッセージを処理できることが必要ですそのセッションのために。
While the solution presented in this document is valid, it violates one of the basic premises of Diameter -- the robustness of its architecture. With normal Diameter routing, sessions will survive failures of agents along the routing path. With the proposals in this document, routing becomes pinned to specific agents whose failure will terminate the session.
そのアーキテクチャの堅牢性 - この文書のソリューションが有効であるが、それは、Diameterの基本的な前提の一つに違反します。通常の直径ルーティングでは、セッションがルーティングパスに沿って薬の失敗を存続します。この文書の提案に、ルーティングは、その失敗のセッションを終了します特定のエージェントに固定となります。
The authors see no interaction between explicit routing and the specific applications with which it is employed. Hence, in principle it can be added to existing applications if they support the necessary extensibility, and equally can be used with new applications.
著者は、明示的なルーティングと、それが採用している特定のアプリケーション間の相互作用を参照してくださいません。彼らは、必要な拡張性をサポートしている場合そのため、原理的には、既存のアプリケーションに追加することができ、かつ均等に新しいアプリケーションで使用することができます。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The following terms are used to define the functionality and participants in the routing extensions described in this document.
以下の用語は、この文書で説明するルーティング機能拡張における機能性と参加者を定義するために使用されています。
ER Explicit routing -- the mechanism provided by this specification to allow proxies traversed by the initial message of a session to ensure that they remain on the messaging path for all subsequent request messages of a session.
ER明示的なルーティング - 彼らはセッションのすべての後続の要求メッセージのメッセージ・パス上に残ることを保証するために、セッションの最初のメッセージが通過するプロキシを許可するには、この仕様によって提供メカニズム。
ER-Proxy A proxy that implements the ER mechanism and can therefore use it to remain in the path for subsequent messages of a session.
ER-プロキシER機構を実装し、したがって、セッションの後続のメッセージのパスのままにそれを使用することができ、プロキシ。
ER-Destination A Diameter node that is capable of participating in ER and that will ultimately consume the request sent by an ER-Originator.
ER-宛先ERに参加することが可能であり、それが最終的にER-オリジネータによって送信された要求を消費するDiameterノード。
ER-Originator A Diameter node initiating a session and sending the requests. The ER-Originator can be any Diameter node sending a request, i.e., a client, server or proxy capable of initiating sessions and participating in ER.
ER-発信Diameterノードセッションを開始し、要求を送信します。 ER-発信要求を送信する任意の直径のノード、即ち、クライアント、サーバまたはセッションを開始し、ERに参加することが可能なプロキシであることができます。
Authentication, Authorization, and Accounting (AAA) Relays Other Diameter nodes interspersed between the ER-Originator, ER-Proxies, and the ER-Destination. These nodes represent existing Diameter agents and proxies that do not participate in ER and do not recognize Explicit-Path Attribute Value Pairs (AVPs).
認証、許可、アカウンティング（AAA）は、ER-発信、ER-プロキシ、およびER-宛先間に散在他Diameterノードを中継します。これらのノードは、ERに参加しないと明示的なパス属性値ペア（AVPを）認識しない既存の直径エージェントとプロキシを表します。
The 3GPP WLAN IP access architecture [TS23.234] is one example of a system requiring that certain agents (stateful proxies, in this case) remain in the forwarding path of all session messages. The 3GPP WLAN interworking architecture extends 3GPP services to the WLAN access side, enabling a 3GPP subscriber to use a WLAN to access 3GPP services.
3GPP WLAN IPアクセスアーキテクチャ[TS23.234]特定の薬剤（この場合、ステートフルプロキシは、）すべてのセッションメッセージの転送パスに留まることを必要とするシステムの一例です。 3GPP WLANインターワーキングアーキテクチャは、3GPPサービスにアクセスするためにWLANを使用する3GPP加入者を有効に、WLANアクセス側への3GPPサービスを拡張します。
WLAN AAA provides access to the WLAN to be authenticated and authorized through the 3GPP system. This access control can permit or deny a subscriber access to the WLAN system and/or the 3GPP system.
WLANのAAAは、3GPPシステムを介して認証され、許可されるWLANへのアクセスを提供します。このアクセス制御は、WLANシステム及び/又は3GPPシステムへの加入者アクセスを許可または拒否することができます。
There are two 3GPP WLAN interworking reference models:
2つの3GPP WLANインターワーキングの参照モデルがあります。
1. In the non-roaming case, the model includes the WLAN access network and the 3GPP AAA server in the home network. The 3GPP AAA server is responsible for access control as well as charging.
非ローミングの場合において、モデルは、WLANアクセスネットワークとホームネットワーク内の3GPP AAAサーバを含みます。 3GPP AAAサーバは、アクセス制御だけでなく、充電する責任があります。
2. In the roaming case, the model includes the WLAN access network, the 3GPP AAA proxy in the visited network, and the 3GPP AAA server in the home network. The 3GPP AAA server is responsible for access control. Charging records may be generated by the AAA proxy and/or the AAA server. The AAA proxy relays access control and charging messages to the AAA server. The AAA proxy will also do offline charging, if required.
ローミングの場合には2、モデルは、WLANアクセスネットワーク、訪問先ネットワークにおける3GPP AAAプロキシ、およびホームネットワーク内の3GPP AAAサーバが含まれています。 3GPP AAAサーバは、アクセス制御を担当しています。充電レコードは、AAAプロキシおよび/またはAAAサーバによって生成することができます。 AAAプロキシは、アクセス制御を中継し、AAAサーバにメッセージを充電します。必要に応じて、AAAプロキシはまた、オフライン課金を行います。
The roaming case presents two problems for which the Diameter routing mechanism described in [RFC3588] does not offer any unambiguous and standard solution.
ローミングの場合は、[RFC3588]に記載のダイアメータルーティングメカニズムは、任意の明確な標準ソリューションを提供しないための2つの問題を提起します。
Network Selection Selecting an initial message path for the Diameter session through (possibly many) alternative visited network(s) to the home network.
代替（おそらく多くの）を通じて直径セッションの最初のメッセージのパスを選択するネットワーク選択は、ホームネットワークにネットワーク（複数可）を訪問しました。
Explicit Routing (ER) Maintaining the selected message path for all messages in the Diameter session.
直径セッション内のすべてのメッセージのために選択されたメッセージ経路を維持する明示的ルーティング（ER）。
Selecting an initial message path is outside the scope of this document. A mechanism for maintaining the selected message path is described in detail below.
最初のメッセージのパスを選択すると、この文書の範囲外です。選択されたメッセージ経路を維持するための機構は、以下に詳細に記載されています。
After a successful authentication, a Diameter session is established involving (at least) the following stateful entities:
認証が成功した後、直径セッションは、（少なくとも）以下のステートフル実体を伴う確立されています。
o the Diameter client in the WLAN access node (e.g., the 3GPP AAA client in the terminal visited network),
、WLANアクセスノードの直径クライアントO（例えば、端末における3GPP AAAクライアントがネットワークを訪問）
o a Diameter proxy in the visited mobile network (e.g., the 3GPP AAA proxy in the terminal visited network), and
訪問先モバイルネットワークの直径プロキシO（例えば、端末内の3GPP AAAプロキシがネットワークを訪問）、および
o a Diameter server in the user's home realm (e.g., the destination 3GPP AAA server in the terminal home network).
Oユーザーのホーム領域の直径サーバ（例えば、端末のホームネットワーク内の宛先3GPP AAAサーバ）。
Message routing for the initial session request uses the normal Diameter routing tables (Section 2.7 of [RFC3588]) in the 3GPP AAA client, the 3GPP AAA proxy in the visited network, and any intermediate proxies after that. The 3GPP AAA client sends the initial session request to the 3GPP AAA proxy in the visited network. The 3GPP AAA proxy processes the request, then forwards it towards the destination 3GPP AAA server, through an intermediate proxy if necessary. The request may be forwarded through other intermediate proxies in the same way, until it reaches the destination 3GPP AAA server in the terminal home network.
最初のセッション要求のルーティングメッセージは、3GPP AAAクライアントに正常直径ルーティングテーブル（セクション2.7 [RFC3588]）を使用して、訪問先ネットワーク内の3GPP AAAプロキシ、及びその後任意の中間プロキシ。 3GPP AAAクライアントが訪問先ネットワークにおける3GPP AAAプロキシに最初のセッション要求を送信します。 3GPP AAAプロキシは、次に、要求を処理し、必要に応じて中間プロキシを介して、送信先の3GPP AAAサーバに向けて転送します。それは、端末のホームネットワーク内の宛先3GPP AAAサーバに到達するまで、要求は、同様に他の中間プロキシを介して転送されてもよいです。
The functions assigned to the 3GPP AAA proxy include:
3GPP AAAプロキシに割り当てられた機能は次のとおり
o Reporting charging information to the offline charging system in the visited network,
O訪問先ネットワークにオフライン課金システムへの課金情報を報告、
o Policy enforcement based on roaming agreements, and
Oポリシーの適用ローミング契約に基づいて、
o Service termination initiated by the visited network's operator.
訪問先ネットワークのオペレータによって開始Oサービス終了。
These functions all require that state be maintained within the visited network. The 3GPP's choice is to maintain that state at the 3GPP AAA proxy. This means that the latter must remain in the messaging path for all subsequent messages relating to the same session.
これらの機能はすべて、状態が訪問先ネットワーク内に維持することを要求しています。 3GPPの選択は、3GPP AAAプロキシでその状態を維持することです。これは、後者は同じセッションに関連する後続のすべてのメッセージに対して、メッセージング・パスに留まらなければならないことを意味します。
This section outlines a Diameter ER mechanism by which Diameter nodes participating in ER can remain in the path of all request messages for a specific session. A new Explicit-Path AVP is defined to enable ER participants to manipulate the Destination-Host and/or Destination-Realm AVPs of request messages in order to ensure the correct routing behavior. The following sections describe the extensions to the request routing in [RFC3588] to implement the ER mechanism. The proposed extensions utilize existing routing strategies in [RFC3588] and do not mandate modifications to it. The mechanism imposes loose rather than strict source routing, in that subsequent messages of a session are forced through the participating nodes, but not through any individual non-participating nodes. In summary, only Diameter nodes interested in participating in the ER scheme will be involved in it.
このセクションでは、ERに参加Diameterノードは、特定のセッションのためのすべての要求メッセージの経路内に残ることが可能な直径ER機構を概説します。新しい明示的なパスAVPは正しいルーティング動作を保証するために要求メッセージの宛先ホストおよび/または宛先領域AVPを操作するために、ERの参加を可能にするために定義されています。以下のセクションでは、ER機構を実装するために、[RFC3588]にルーティング要求への拡張を記述しています。提案されている拡張子は[RFC3588]で既存のルーティング戦略を活用し、それに変更を強制しません。セッションの後続のメッセージがなく、任意の個々の非参加ノードを介して、参加ノードを介して強制される機構は、厳密なソースルーティングではなくルーズ課します。要約すると、ER方式で参加することに関心のみDiameterノードは、それに関与することになります。
A Diameter node acting as an ER-Originator for a particular session MUST maintain a local cache that enumerates all the Diameter identities of the ER-Proxies that the request messages must traverse along the path to the ER-Destination. The identity of a Diameter node is defined in [RFC3588]. The local cache MAY also include the node's realm. The data structure of the cache is left up to the implementation and SHOULD persist as part of the session attributes or properties.
特定のセッションのためのER-オリジネーターとして動作するDiameterノードは、ER-プロキシ要求メッセージは、ER-先へのパスに沿って移動しなければならないことのすべての直径のアイデンティティを列挙し、ローカルキャッシュを維持しなければなりません。 Diameterノードのアイデンティティは、[RFC3588]で定義されています。ローカルキャッシュは、ノードのレルムを含むかもしれません。キャッシュのデータ構造は、実装に任され、セッション属性またはプロパティの一部として存続すべきです。
An ER-Originator sending request messages MUST add an Explicit-Path AVP to these requests. The contents of the cache SHOULD be used to populate the Explicit-Path AVP, with each cached entry represented by a corresponding instance of the Explicit-Path-Record AVP. ER-Proxies along the path of the request message MUST examine the contents of the Explicit-Path AVP and make routing adjustments based on records it contains. An example of the message flow is shown in Section 5. Note that the ER-Originator can be any Diameter node, i.e., a client, server, or proxy.
リクエスト・メッセージを送信ER-オリジネーターは、これらの要求に明示的なパスのAVPを追加しなければなりません。キャッシュの内容は、明示的なパス・レコードAVPの対応するインスタンスによって表される各キャッシュエントリに、明示的なパスのAVPを取り込むために使用されるべきです。 ER-プロキシ要求メッセージのパスに沿っは、明示的なパスのAVPの内容を検討し、それが含まれているレコードに基づいてルーティング調整を行う必要があります。メッセージ・フローの例は、セクション内のER-発信者が任意の直径のノード、即ち、クライアント、サーバ、またはプロキシとすることができる。5.注示されています。
The ER-Originator can populate the cache either by pre-configuring its contents or by using the first request message of the session to gather identities of participating ER-Proxies along the routing path. The latter scheme is known as Explicit-Path discovery. The contents of the cache can be pre-configured if the ER-Originator has explicit knowledge of the ER-Proxies the request messages must traverse; otherwise, the ER-Originator can use Explicit-Path discovery. It is RECOMMENDED that Explicit-Path discovery be used whenever possible since pre-configuration is less flexible by nature.
ER-オリジネーターは、その内容を事前に設定することにより、またはルーティングパスに沿ってER-プロキシの参加の識別情報を収集するために、セッションの最初の要求メッセージのいずれかを使用してキャッシュを読み込むことができます。後者の方式は、明示的なパスの発見として知られています。 ER-発信要求メッセージが通過しなければならないER-プロキシの明示的な知識を持っている場合は、キャッシュの内容は、事前に設定することができます。それ以外の場合は、ER-オリジネーターは、明示的なパスの検出を使用することができます。事前設定が本来より少なく柔軟であるため、明示的なパス検出が可能な限り使用することを推奨されています。
Explicit-Path discovery is useful if the identities of the ER-Proxies are not known or if there are several ER-capable proxies (a cluster of proxies) that can be dynamically chosen based on other routing policies. In Explicit-Path discovery, the cache of the ER-Originator is initially empty. To initiate discovery, when the ER-Originator sends the first request message of a session, it MUST include the Explicit-Path AVP containing a single Explicit-Path-Record AVP with the identity and/or the realm of the ER-Originator. The ER-Originator MUST set the Destination-Host and/or Destination-Realm AVP of the request message to the identity and/or the realm of the ER-Destination, respectively, as specified in [RFC3588].
明示的なパスの発見は、ER-プロキシの身元が知られていない場合に有用であるか、動的に他のルーティングポリシーに基づいて選択することができるいくつかのER-対応プロキシ（プロキシのクラスタ）がある場合。明示的なパスの発見では、ER-オリジネーターのキャッシュは最初は空です。 ER-発信者がセッションの最初の要求メッセージを送信するときに、発見を開始するには、それがアイデンティティおよび/またはER-オリジネータのレルムにシングル明示的なパス・レコードのAVPを含む明示的なパスのAVPを含まなければなりません。 [RFC3588]で指定されるようにER-発信者は、それぞれ、同一性および/またはER-先の領域に要求メッセージの宛先ホストおよび/または宛先領域AVPを設定しなければなりません。
Note that ER-Originator initial request message routing procedures and the process of population of the Destination-Realm may be affected by the User-Name AVP NAI decoration [RFC5729]. NAI decoration is a form of request message source routing and defines realms that the request message must traverse through before routing towards the ER-Destination. Diameter nodes participating in request message routing must examine and process the User-Name AVP, and modify the Destination-Realm AVP accordingly as long as there are realms left in the decorated NAI. Source routing based upon NAI decoration does not affect Explicit-Path discovery as defined in this document.
そのER-発信初期要求メッセージルーティング手順を注意と宛先レルムの集団の処理は、ユーザ名AVP NAIデコレーション[RFC5729]の影響を受けることができます。 NAIデコレーションは、要求メッセージ・ソース・ルーティングの形態であり、要求メッセージは、ER-宛先に向けてルーティングする前に介して通過しなければならないレルムを定義します。要求メッセージのルーティングに参加直径ノードは、検査及びユーザ名AVPを処理し、それに応じ限りデコレーションされたNAIに残っレルムが存在するように宛先レルムAVPを変更する必要があります。この文書で定義されているNAIのデコレーションに基づいてソース・ルーティングは、明示的なパスの検出には影響を与えません。
If the path taken by the initial request encounters one or more participating ER-Proxies and a participating ER-Destination, the procedures described in Section 4.2 and Section 4.3 ensure that a successful response to that request will contain an Explicit-Path AVP that includes one or more Explicit-Path-Records containing the ER-Originator's identity, the identities of all participating ER-Proxies, and the identity of the ER-Destination. The ER-Originator SHOULD populate its local cache with the contents of the Explicit-Path AVP received in this initial answer message.
最初のリクエストで撮影したパスは、1つまたは複数の参加ER-プロキシと参加ER-先に遭遇した場合、4.2節と4.3節で説明した手順は、その要求に成功した応答が一つを含む明示的なパスのAVPが含まれますことを確認してください以上の明示的なパス・レコードは、ER-発信者の身元、すべての参加ER-プロキシのアイデンティティ、およびER-先のアイデンティティを含みます。 ER-オリジネーターは、AVPは、この最初の応答メッセージで受信明示的なパスの内容にローカルキャッシュを移植すべきです。
If the answer message does not contain an Explicit-Path AVP or the Result-Code AVP is set to DIAMETER_ER_NOT_AVAILABLE (Section 4.7), it is an indication to the ER-Originator that the destination of the request does not support ER and that the ER-Originator SHOULD avoid sending an Explicit-Path AVP in subsequent request messages.
応答メッセージは、明示的なパスのAVPまたは結果 - コードAVPがDIAMETER_ER_NOT_AVAILABLE（4.7節）に設定されているが含まれていない場合、それはER要求の宛先がERをサポートしていないER-オリジネーターへとその表示があります-Originator後続の要求メッセージに明示的なパスのAVPを送ることは避けるべきです。
If the initial request message initiated Explicit-Path discovery, but the Explicit-Path AVP in the answer message contains Explicit-Path-Records for the ER-Originator and ER-Destination only, it is an indication to the ER-Originator that there are no Diameter proxies capable of participating in ER along the path and that the ER-Originator SHOULD NOT send an Explicit-Path AVP in subsequent request messages of this session. See Section 4.5 for more discussion. In such cases, the situation may be transient, and
初期要求メッセージは、明示的なパスの発見を開始したが、応答メッセージで明示的なパスAVPのみER-オリジネーターおよびER-先の明示的パス・レコードが含まれ、それがあることをER-オリジネーターへの指示である場合パスに沿ってER-発信者がこのセッションの後続の要求メッセージに明示的なパスのAVPを送ってはならないことをERに参加することができるいかなる直径プロキシません。より多くの議論については、セクション4.5を参照してください。このような場合には、状況は一時的であってもよく、
Explicit-Path discovery may find participating proxies in succeeding sessions. It is left up to the ER-Originator to decide if Explicit-Path discovery should be attempted in succeeding sessions.
明示的なパスの発見は、セッション後続にプロキシを参加見つけることがあります。明示的なパスの発見は、セッション後続に試みるべきかどうかを判断するためにER-発信者に任されています。
Once the ER-Originator's local cache has been populated, whether by pre-configuration or through Explicit-Path discovery, all request messages for the session MUST include the Explicit-Path AVP using the contents of the local cache. The Explicit-Path AVP MUST contain the Explicit-Path-Records of all the nodes enumerated in the cache except that of the ER-Originator itself. The identities enumerated in the Explicit-Path AVP MUST appear in the order they will be traversed in the routing path. The last entry in the Explicit-Path AVP MUST be the Explicit-Path-Record of the ER-Destination. In addition, the value of the Destination-Host and possibly the Destination-Realm in the request message MUST be copied from the values of the Proxy-Host AVP and, if present, the Proxy-Realm AVP of the first Explicit-Path-Record AVP present in the Explicit-Path AVP.
ER-オリジネーターのローカルキャッシュが読み込まれた後、事前に設定するか、または明示的なパスの発見を通じてか、セッションのすべての要求メッセージは、ローカルキャッシュの内容を使用して明示的なパスAVPを含まなければなりません。明示的なパスAVPは、ER-オリジネーター自身のことを除いて、キャッシュに列挙すべてのノードの明示的なパス・レコードを含まなければなりません。明示的なパスAVPに列挙アイデンティティは、彼らがルーティングパスに横断される順序で表示されなければなりません。明示的なパスAVPの最後のエントリは、ER-先の明示的なパス・レコードでなければなりません。また、要求メッセージにおける宛先ホストとおそらく宛先レルムの値は、プロキシホストAVPの値からコピーされなければならない存在する場合、最初の明示的なパス・レコードのプロキシレルムAVP明示的なパスのAVPでAVP存在。
This ensures that the ER-Originator as well as any AAA relays between the ER-Originator and the first ER-Proxy will route the message towards the first ER-Proxy as specified in RFC 3588 [RFC3588].
RFC 3588 [RFC3588]で指定されるように、これはER-発信及び第ER-プロキシとの間のER-発信ならびに任意AAAリレーは第ER-プロキシに向かってルートメッセージをことを保証します。
Subsequent actions taken by the first ER-Proxy upon receipt of the message are described in Section 4.2 and will mimic those of the ER-Originator.
メッセージの受信時に最初のER-プロキシによって取られる後続のアクションは、セクション4.2に記載されており、ER-発信者のものを模倣します。
Answer messages received by the ER-Originator to subsequent request messages after the Explicit-Path has been established SHOULD NOT have an Explicit-Path AVP. If they do, this SHOULD be considered a suspect condition that may be caused by a misbehaving ER participant. It is left up to the ER-Originator whether to continue using the ER scheme when such a condition arises or to attempt another Explicit-Path discovery for subsequent sessions.
明示的なパスが確立された後、後続の要求メッセージへのER-オリジネーターが受信したメッセージは、明示的なパスのAVPを持つべきではない答え。彼らが行う場合は、この動作不良ERの参加者によって引き起こされる可能性が疑わしい状態を考慮すべきです。このような状況が発生した場合ERスキームを使用して続行するか、その後のセッションのための別の明示的なパスの発見を試行するかどうかER-発信者に任されています。
The basic action taken by an ER-Proxy upon receiving a request is to check whether explicit routing is supported in the request and if so, check whether it is already a participant in explicit routing for the said request. If it is not an existing participant, if Explicit-Path discovery is in progress, and if it wishes to participate, it appends an Explicit-Path-Record AVP identifying itself to the end of the Explicit-Path AVP. If it is an existing participant, the ER-Proxy pops/removes the Explicit-Path-Record AVP pertaining to itself from the Explicit-Path AVP and then uses the next Explicit-Path-Record AVP for subsequent routing. Details of this operation follow.
要求を受信するとER-プロキシで撮影した基本的な動作は、明示的なルーティングはリクエストでサポートされており、もしそうなら、それはすでに述べた要求の明示的なルーティングの参加であるかどうかをチェックされているかどうかを確認することです。明示的なパスディスカバリが進行中であり、それが参加することを希望する場合、それは明示的なパスのAVPの終わりに自分自身を特定する明示的なパス・レコードのAVPを追加します。場合には、既存の参加者ではない場合それは、既存の参加者である場合は、ER-プロキシポップは/明示的なパスのAVPから自分自身に関する明示的なパス・レコードのAVPを削除し、その後のルーティングのために次の明示的なパス・レコードのAVPを使用しています。この動作の詳細は以下の通り。
An ER-Proxy is not required to keep local state or cache state regarding the explicit routing procedure. However, it MUST check whether an incoming request contains an Explicit-Path AVP. The following cases can occur.
ER-プロキシは、明示的なルーティング手順に関するローカル状態またはキャッシュの状態を維持するために必要とされていません。しかし、それは、着信要求が明示的なパスのAVPが含まれているかどうかをチェックしなければなりません。以下のケースが発生する可能性があります。
1. If an incoming request does not contain an Explicit-Path AVP, then the ER-Proxy takes no action beyond processing and forwarding the request as specified in [RFC3588].
1.着信要求が明示的なパスのAVPが含まれていない場合、その後、ER-Proxyは、処理を超えて何のアクションも取らず、[RFC3588]で指定されるように要求を転送します。
2. If the incoming request contains an Explicit-Path AVP, the ER-Proxy MUST check whether its identity is present in the Explicit-Path AVP. Determining whether its identity is present can be done by matching its identity to the Proxy-Host AVP contained in each Explicit-Path-Record. If its identity is not present, then:
2.着信要求は、明示的なパスのAVPが含まれている場合は、ER-プロキシは、そのアイデンティティが明示的なパスのAVPに存在しているかどうかをチェックしなければなりません。その識別情報が存在するかどうかを決定することは、それぞれ明示的なパス・レコードに含まれるプロキシホストAVPにその身元を照合することによって行うことができます。そして、その識別情報が存在しない場合：
A. If it wishes to participate in explicit routing, the ER-Proxy
MUST verify that Explicit-Path discovery is in progress by
verifying that the Proxy-Host AVP in the first Explicit-Path-
Record AVP in the Explicit-Path AVP does not match the
Destination-Host AVP (if present). If this verification
succeeds or the Destination-Host AVP is absent, the ER-Proxy
MAY append a new Explicit-Path-Record as the last AVP in the
Explicit-Path AVP prior to forwarding the request. The new
Explicit-Path-Record MUST contain a Proxy-Host AVP set to the
proxy's identity, and MAY contain a Proxy-Realm AVP giving
the proxy's realm. If, however, the Destination-Host AVP is
present and matches the Proxy-Host AVP of the first Explicit-
Path-Record AVP, then the Explicit-Path contains an already-
defined source route that does not include the ER-Proxy. The
ER-Proxy SHOULD process the request as if the ER-Path AVP
were absent.
B. If the ER-Proxy does not wish to participate in the ER, it SHOULD NOT modify the Explicit-Path AVP and SHOULD simply process and forward the request as specified in [RFC3588] using the existing values of the Destination-Host and/or Destination-Realm AVPs. Non-ER-Proxies and relays that do not support ER and do not recognize Explicit-Path AVP will take the same action.
B. ER-プロキシは、ERへの参加を希望しない場合は、それが明示的なパスのAVPを変更すべきではなく、[RFC3588]で指定されているだけで宛先ホストの既存の値を使用して要求を処理し、転送すべきであると/または宛先レルムのAVP。非ER-プロキシおよびERをサポートしていないと同じ行動を取るだろう明示的なパスAVPを認識しないリレー。
3. If the identity of the ER-Proxy is present in the Explicit-Path AVP, then:
3. ER-プロキシのアイデンティティは、その後、明示的なパスのAVPに存在する場合：
A. If it is not the first Explicit-Path-Record in the AVP, this
MUST be considered an error, and an answer message with the
'E' bit set and the Result-Code set to
DIAMETER_INVALID_PROXY_PATH_STACK MUST be sent back to the
ER-Originator (Section 4.7).
B. If the identity of the ER-Proxy matches the first Explicit-Path-Record, the ER-Proxy MUST remove this record from the Explicit-Path AVP and repopulate the Destination-Host and possibly the Destination-Realm AVP from the next Explicit-Path-Record present in the Explicit-Path AVP. Setting the Destination-Host and possibly the Destination-Realm AVP will ensure that the ER-Proxy as well as all AAA relays between the current ER-Proxy and the next ER-Proxy enumerated in the Explicit-Path AVP will route the message towards the next ER-Proxy. The process of removing the ER-Proxy's record is analogous to popping an entry from a stack represented by the Explicit-Path AVP.
B. ER-プロキシのアイデンティティは最初の明示的なパス・レコードと一致した場合、ER-プロキシが明示的なパスのAVPからこのレコードを削除し、次の明示から宛先ホストおよびおそらく宛先レルムAVPを再投入しなければなりません。明示的なパスのAVPで-path-録音存在。宛先ホストおよびおそらく宛先領域を設定するAVPは現在のER-Proxyと明示的なパスAVPをルーティングに向けたメッセージで列挙次のER-プロキシ間のER-プロキシだけでなく、すべてのAAAのリレーを保証します次のER-プロキシ。 ER-プロキシのレコードを除去する工程は、明示的なパスのAVPが表すスタックからエントリをポップに似ています。
The behavior specified above also applies to a Diameter node that acts as a relay agent and participates in the ER scheme.
また、上記で指定された動作は、リレーエージェントとして機能し、ER方式に関与Diameterノードに適用されます。
A Diameter node that locally processes requests sent by the ER-Originator (Section 4.1) and is able to support ER (an ER-Destination) MUST check for the presence of an Explicit-Path AVP in the request message.
ローカルER-オリジネータ（セクション4.1）によって送られたリクエストを処理し、ER（ER-先）をサポートすることができるDiameterノードは、要求メッセージ内の明示的なパスのAVPの存在をチェックしなければなりません。
1. If an incoming request does not contain an Explicit-Path AVP, then it is an indication that messages belonging to this session will not use ER. The ER-Destination MUST simply process the request for local consumption and formulate an answer message as specified in [RFC3588].
1.着信要求は、明示的なパスのAVPが含まれていない場合、このセッションに属するメッセージがERを使用しないことを示しています。 ER-先は、単に地元消費のための要求を処理し、[RFC3588]で指定された応答メッセージを策定しなければなりません。
2. If the incoming request contains an Explicit-Path AVP, the ER-Destination MUST check whether its identity is present in the Explicit-Path AVP. If its identity is not present, indicating that Explicit-Path discovery is in progress, then:
2.着信要求は、明示的なパスのAVPが含まれている場合は、ER-先は、そのアイデンティティが明示的なパスのAVPに存在しているかどうかをチェックしなければなりません。その正体は存在しない場合は、明示的なパスディスカバリが進行中であることを示す、次のようになります。
A. If it wishes to participate in the ER, and subject to
paragraph B below, the ER-Destination MUST append a new
Explicit-Path-Record to the Explicit-Path AVP in the received
message. The new Explicit-Path-Record MUST contain at the
least a Proxy-Host AVP set to the ER-Destination's identity.
The ER-Destination MUST then copy the resulting Explicit-Path
AVP to the subsequent answer message.
B. If there is only one Explicit-Path-Record in the incoming Explicit-Path AVP, then this is an indication of a successful Explicit-Path discovery, but with no participating ER-Proxies. The ER-Destination SHOULD NOT copy the Explicit-Path AVP into the subsequent answer message.
入ってくる明示的なパスのAVPで唯一の明示的なパス・レコードがある場合B.が、これは成功した明示的なパスの発見の指標である、ない参加ER-プロキシと。 ER-先は、後続の応答メッセージの中に明示的なパスのAVPをコピーすべきではありません。
C. If the ER-Destination supports ER but does not wish to or cannot participate, it MAY send a Result-Code AVP set to DIAMETER_ER_NOT_AVAILABLE as defined in Section 4.7. The ER-Destination MUST NOT include any Explicit-Path AVP in the subsequent answer. Diameter servers that do not support ER and do not recognize the Explicit-Path AVP will also omit the Explicit-Path AVP from the answer message.
C. ER-先がERをサポートしていますが、したくないか、参加できない場合は、セクション4.7で定義されているAVP DIAMETER_ER_NOT_AVAILABLEに設定し、コードの結果を送信することができます。 ER-先は、後続の答えのいずれかの明示的なパスのAVPを含んではいけません。 ERをサポートしていないとAVPも応答メッセージからの明示的なパスのAVPを省略する明示的なパスを認識しない直径サーバ。
3. If the identity of the ER-Destination matches a record in the Explicit-Path AVP, then it MUST be the only Explicit-Path-Record present in the Explicit-Path AVP. Otherwise, this MUST be considered an error, and an answer message with the 'E' bit set and containing an Experimental-Result-Code AVP set to DIAMETER_INVALID_PROXY_PATH_STACK MUST be sent back to the ER-Originator (Section 4.7). If the identity of the ER-Destination does match the only existing Explicit-Path-Record, then this is an indication that the request reached the ER-Destination by way of a successfully executed explicit route. The ER-Destination MUST NOT include the Explicit-Path AVP in the subsequent answer message.
3. ER-先のアイデンティティが明示的なパスAVP内のレコードと一致した場合、それは明示的なパスAVPで唯一の明示的なパス・レコード存在しなければなりません。そうでなければ、これはエラーとみなされなければならない、と「E」と応答メッセージは、設定および実験結果 - コードAVPがバックER-オリジネーター（4.7節）に送らなければなりませんDIAMETER_INVALID_PROXY_PATH_STACKに設定含むビット。 ER-先のアイデンティティが唯一の既存の明示的なパス・レコードと一致した場合、これは、要求が正常に実行され、明示的なルートを経由してER-先に到達したことを示すものです。 ER-先は、後続の応答メッセージで明示的なパスのAVPを含んではいけません。
There is no requirement on Diameter nodes participating in ER to provide special handling or routing of answer messages. Answer messages SHOULD be processed normally as specified in [RFC3588]. However, a Diameter node acting as an ER-Destination MUST formulate a proper Explicit-Path AVP in answer messages as described in Section 4.3.
特別な取り扱いや回答メッセージのルーティングを提供するために、ERに参加Diameterノード上の要件はありません。 [RFC3588]で指定された回答メッセージは、通常、処理されるべきです。 4.3節で説明したようにしかし、ER-先として動作するDiameterノードは、応答メッセージに適切な明示的なパスのAVPを策定しなければなりません。
If there is no ER-Proxy along the selected path, the answer message MAY contain an Explicit-Path AVP that contains only the Explicit-Route-Records of the ER-Originator and the ER-Destination, indicating that there is no ER support found in Diameter nodes along the path. It is left to the ER-Originator to continue with processing of the request without ER support or terminate the session. The ER-Originator SHOULD NOT attempt to perform Explicit-Path discovery in subsequent request messages of this session in such cases, to protect against failback conditions where an ER-Proxy suddenly appears in the path and attempts to add a new Explicit-Path-Record for request messages other than the initial request.
選択されたパスに沿ったER-プロキシが存在しない場合は、応答メッセージが見つかりませERのサポートがないことを示し、ER-オリジネーターおよびER-先の唯一の明示的な-ルートレコードを含む明示的なパスAVPを含むかもしれ経路に沿ったDiameterノードです。 ERのサポートなしで要求の処理を続行するか、セッションを終了するためにER-オリジネーターに委ねられています。 ER-オリジネーターは、ER-プロキシが突然パスに表示され、新しい明示的なパス・レコードを追加しようとしたフェイルバックの条件から保護するために、そのような場合には、このセッションの後続の要求メッセージで明示的パスの検出を実行しないでください最初の要求以外の要求メッセージのため。
Allowing an ER-Proxy to join the session after the initial request makes sense only if the application requirements do not mandate that every participating ER-Proxy receive all of the messages of a session.
最初のリクエストは、アプリケーションの要件は、すべての参加ER-プロキシは、セッションのすべてのメッセージを受信することを義務付けていない場合にのみ意味を成した後、ER-プロキシがセッションに参加することができます。
However, depending on local policy, the ER-Originator MAY attempt ER path discovery in subsequent sessions despite the lack of proxy participants in the earlier attempt.
しかし、ローカルポリシーに応じて、ER-オリジネーターは、以前の試みで、代理参加者の不足にもかかわらず、その後のセッションでERパスの発見を試みるかもしれません。
If a failover occurs in a Diameter node preceding an ER-Proxy when the Explicit-Path is already established, it is possible that a DIAMETER_UNABLE_TO_DELIVER error will be received by the ER-Originator if there are no alternative paths towards the ER-Proxy. In such a case, it is left to the ER-Originator to handle the error as specified in the Diameter application or in [RFC3588].
フェイルオーバーが明示的なパスが既に確立されたときにER-Proxyの先行Diameterノードで発生した場合、ER-プロキシ向かっない代替パスが存在しない場合DIAMETER_UNABLE_TO_DELIVERエラーがER-発信者によって受信されることが可能です。 Diameterアプリケーションまたは[RFC3588]で指定されるように、このような場合には、エラーを処理するためにER-発信者に残されます。
The following sections define the AVPs used in the ER process. All of these AVPs MUST have the 'V' bit set and the 'M' bit cleared, with the Vendor-ID field set to 2011 (as assigned by IANA in "Private Enterprise Numbers" registry; see http://www.iana.org/).
次のセクションでは、ERのプロセスで使用されるAVPを定義します。 //www.iana：HTTPを参照してください。これらのAVPのすべてが（「民間企業番号」レジストリにIANAによって割り当てられている2011年に「V」はビットセットと「M」ビットをクリア、ベンダーIDフィールドのセットを持っていなければなりません。 .ORG /）。
The Explicit-Path-Record AVP (AVP Code 35001) is of type Group. The identity added in the Proxy-Host [RFC3588] element of this AVP MUST be the same as the one advertised by the Diameter node in the Origin-Host AVP during the Capabilities Exchange messages.
明示的なパス-録音AVP（AVPコード35001）は、タイプグループです。このAVPのプロキシホストで添加アイデンティティ[RFC3588]の要素は、機能交換メッセージ中原点ホストAVPの直径ノードによってアドバタイズさと同じでなければなりません。
Explicit-Path-Record ::= < AVP Header: 35001 >
{ Proxy-Host }
[ Proxy-Realm ]
The Proxy-Host AVP (AVP Code 35004) is of type DiameterIdentity. It identifies the ER node that is inserting the record. The Proxy-Host AVP MUST be present.
プロキシホストAVP（AVPコード35004）はタイプDiameterIdentityにです。これは、レコードを挿入しているERノードを識別します。プロキシホストAVPが存在しなければなりません。
The Proxy-Realm AVP (AVP Code 35002) is of type DiameterIdentity, and contains the realm of the ER node inserting the record. The Proxy-Realm AVP MAY be present in the Explicit-Path-Record. If it is present, the realm name included in the value of the Proxy-Host AVP MUST match the value of the Proxy-Realm AVP.
プロキシレルムAVP（AVPコード35002）はタイプDiameterIdentityにであり、そしてレコードを挿入ERノードの領域を含んでいます。プロキシ・レルムAVPは、明示的なパス・録音中に存在することができます。それが存在する場合は、プロキシホストAVPの値に含まレルム名は、プロキシ・レルムAVPの値と一致する必要があります。
The Explicit-Path AVP (AVP Code 35003) is of type Grouped. This AVP MUST be present in all request messages performing ER. It MAY be present in the answer to the initial session request message if Explicit-Path discovery was successfully executed for the request.
明示的なパスAVP（AVPコード35003）がグループ化されたタイプです。このAVPは、ERを実行するすべての要求メッセージ中に存在しなければなりません。明示的なパスの発見に成功リクエストに対して実行された場合は、最初のセッション要求メッセージへの答えで存在することができます。
Explicit-Path ::= < AVP Header: 35003 >
1* [ Explicit-Path-Record ]
* [ AVP ]
The following error conditions may occur during ER processing. All error indications MUST be encapsulated in an instance of the Experimental-Result AVP [RFC3588] with the Vendor-ID AVP set to 2011 and the Experimental-Result-Code set as specified below.
以下のエラー条件は、ERの処理中に発生する可能性があります。すべてのエラー表示は、ベンダーID AVPを用いた実験結果AVP [RFC3588]のインスタンスにカプセル化されなければならない2011年に設定され、以下に指定されるように実験結果コードがセット。
DIAMETER_INVALID_PROXY_PATH_STACK 3501
DIAMETER_INVALID_PROXY_PATH_STACK 3501
A request message received by an ER-Proxy or ER-Destination after an Explicit-Path has been established has the first or only Explicit-Path-Record AVP not matching the ER-Proxy's or the ER-Destination's identity. The same error applies to ER-Destinations receiving an Explicit-Path-AVP containing more than one Explicit-Path-Record or an Explicit-Path-AVP with only one Explicit-Path-Record not matching its own identity.
明示的なパスが確立された後、ER-プロキシまたはER-先で受信した要求メッセージは、最初または唯一の明示的なパス-録音AVPは、ER-プロキシのか、ER-先のIDを一致していません。同じエラーが唯一の明示的なパス-録音は、独自のアイデンティティと一致しないと、複数の明示的なパス・レコードまたは明示的なパス-AVPを含む明示的なパス-AVPを受けER-先に適用されます。
This error SHOULD be considered a protocol failure and SHOULD be treated on a per-hop basis; Diameter proxies may attempt to correct the error, if possible. Diameter answer messages containing this error indication MUST have the 'E' bit set and MUST conform to Section 7.2 of [RFC3588].
このエラーは、プロトコルの失敗とみなされるべきであり、ホップごとのベースで処理されるべきです。直径プロキシが可能な場合は、エラーを修正しようとすることができます。このエラー表示を含む直径応答メッセージは、「E」ビットが設定されていなければなりません、そして、[RFC3588]のセクション7.2に従わなければなりません。
DIAMETER_ER_NOT_AVAILABLE 4501
4501 DIAMETER_ER_NOT_AVAILABLE
An ER-Destination that supports ER routing but is unable to comply for unknown reasons MAY send an answer message with the Result-Code AVP set to this error code. This error value SHOULD be considered a transient failure indicating that subsequent ER attempts may succeed.
ERルーティングをサポートしていますが、このエラーコードの結果、コードAVPセットで応答メッセージを送るかもしれ未知の理由のために遵守することができないER-先。このエラー値は、後続のERの試みが成功する可能性があることを示す過渡故障考慮されるべきです。
The example presented here illustrates the flow of Diameter messages with the typical attributes present in the ER scenario.
ここで紹介する例は、ERのシナリオに存在する典型的な属性を持つDiameterメッセージの流れを示しています。
The ER-Originator in the example below shows the use of Explicit-Path discovery with the first request. However, the ER-Originator could also use a pre-configured cache. The ER-Originator can be any Diameter node sending a request, i.e., a client, server, or proxy. In this scenario, the local cache of the ER-Originator is initially empty.
以下の例ではER-オリジネーターは、最初のリクエストで明示的なパス発見の使用を示しています。しかし、ER-オリジネーターも、事前に設定されたキャッシュを使用することができます。 ER-発信要求、すなわち、クライアント、サーバ、またはプロキシを送信する任意のDiameterノードとすることができます。このシナリオでは、ER-オリジネーターのローカルキャッシュは最初は空です。
The AAA relays between the ER-Proxies, ER-Originator, and ER-Destination may or may not be present and are shown here to depict routing paths that the requests may take prior to being processed by nodes participating in the ER scheme. The AAA relays also depict existing Diameter relays or proxies that do not recognize Explicit-Path AVPs and therefore do not participate in ER.
ER-プロキシ、ER-発信、およびER-宛先との間のAAAのリレーが存在してもしなくてもよく、要求はER方式に参加するノードによって処理される前に取ることができるルーティング経路を示すためにここで示されています。 AAAリレーはまた、明示的なパスのAVPを認識しないため、ERに参加していない既存の直径リレーやプロキシを示しています。
ER- ER- ER- ER-
Originator AAA relays Proxy1 AAA relays Proxy2 Destination
(o.r1 (p.r1 (p.r2 (d.r2
.example) .example) .example) .example)
| | | | |
cache=(empty) | | | | |
------------->|--------->| | | |
(1st request of the session)| | | |
Explicit-Path= | | | |
o.r1.example,r1.example | | |
dest-host=d.r2.example | | | |
dest-realm=r2.example | | | |
| | | | |
| |--------->|--------->| |
| | (forwarded request)| |
| | Explicit-Path= | |
| | record1=o.r1.example,r1.example
| | record2=p.r1.example,r1.example
| | dest-host=d.r2.example |
| | dest-realm=r2.example |
| | | | |
| | | |--------->|
| | | (forwarded request)
| | | Explicit-Path=
| | | record1=o.r1.example,
| | | r1.example
| | | record2=p.r1.example,
| | | r1.example
| | | record3=p.r2.example,
| | | r2.example
| | | dest-host=d.r2.example
| | | dest-realm=r2.example
| | | | |
cache= |<---------|<---------|<---------|<---------|
record1=o.r1.example,r1.example (answer) |
record2=p.r1.example,r1.example Explicit-Path=
record3=p.r2.example,r2.example record1=o.r1.example,r1.example
record4=d.r2.example,r2.example record2=p.r1.example,r1.example
| | record3=p.r2.example,r2.example
| | record4=d.r2.example,r2.example
Note: An originator pre-configuring | | |
its local cache can skip the | | |
exchange above and send the | | |
initial request as shown below. | | |
| | | | |
------------->|--------->| | | |
(subsequent request of the session) | | |
Explicit-Path= | | | |
record1=p.r1.example,r1.example | | |
record2=p.r2.example,r2.example | | |
record3=d.r2.example,r2.example | | |
dest-host=p.r1.example | | | |
dest-realm=r1.example | | | |
| |--------->|--------->| |
| | (forwarded request)| |
| | Explicit-Path= | |
| | record1=p.r2.example,r2.example
| | record2=d.r2.example,r2.example
| | dest-host=p.r2.example |
| | dest-realm=r2.example |
| | | | |
| | | |--------->|
| | | (forwarded request)
| | | Explicit-Path
| | | record1=d.r2.example,
| | | r2.example
| | | dest-host=d.r2.example
| | | dest-realm=r2.example
| | | | |
cache= |<---------|<---------|<---------|<---------|
record1=o.r1.example,r1.example (answer) | |
record2=p.r1.example,r1.example * no Explicit-Path-AVP present
record3=p.r2.example,r2.example | | |
record4=d.r2.example,r2.example | | |
| | | | |
| | | | |
(subsequent request of the session will repeat the process above)
| | | | |
| | | | |
Figure 1: Example ER Message Flow
図1：例ERメッセージフロー
No actions need to be taken with regards to RADIUS/Diameter interaction. The routing extension described in this document is transparent to any translation gateway and relevant only to Diameter routing. The assumption is that if there is a RADIUS proxy chain between Diameter translation agents, the route between translation agents remains stable during the session and does not cause an invalidation of the proxy path stack.
何のアクションは、RADIUS /直径の相互作用に関して取られる必要がありません。本書では説明ルーティング拡張は、任意の変換ゲートウェイに透明でのみ直径ルーティングに関連します。仮定は、Diameter翻訳エージェント間のRADIUSプロキシチェーンがある場合、翻訳エージェント間のルートは、セッション中に安定したままとプロキシ経路スタックの無効化を引き起こさないことです。
The security considerations in [RFC3588] apply to this extension. In addition, this extension raises questions of authorization and can potentially allow a new denial-of-service attack.
[RFC3588]のセキュリティの考慮事項は、この拡張機能に適用されます。また、この拡張は、許可の問題を提起し、潜在的に新サービス拒否攻撃を許可することができます。
The authorization issue comes about because the proxies that participate in ER are self-selected. An ER-Proxy is able, through the operation of ER, to guarantee that it can monitor every message of a session. This is in contrast to ordinary Diameter routing, where some messages may pass by an alternate route. The question is whether the originating party is prepared to extend this additional degree of trust to arbitrary parties along the path. If not, the ER-Originator requires a mechanism to determine whether an ER-Proxy listed in the returned Explicit-Path AVP can be trusted. If it has such a mechanism, then an unwanted ER-Proxy can be deleted from its cache and thus not appear in the ER-Path AVP in subsequent requests. This specification assumes that either the originating party is prepared to allow arbitrary Diameter nodes along the path to attach themselves to the session as ER-Proxies, or the ER-Originator maintains a pre-configured list of ER-Proxies in its cache.
ERに参加プロキシが自己選択されるため、認可問題が約きます。 ER-プロキシは、セッションのすべてのメッセージを監視することができることを保証するために、ERを操作して、ことができます。これは、いくつかのメッセージが別の経路を通過することができる通常のDiameterルーティングとは対照的です。質問は、発信側がパスに沿って任意の当事者に信頼のこの追加度を拡張するために準備されているかどうかです。ない場合は、ER-オリジネーターが返さ明示的なパスのAVPに記載されているER-プロキシが信頼できるかどうかを判断するためのメカニズムが必要です。それは、このような仕組みを持っている場合は、不要なER-プロキシは、そのキャッシュから削除することができますので、その後の要求でER-パスAVPには表示されません。この仕様は、発信側のどちらかがパスに沿って任意のDiameterノードは、ER-プロキシ、またはER-オリジネーターとしてのセッションに自分自身を添付できるようにするために用意されてそのキャッシュにER-プロキシの事前設定されたリストを維持することを前提としています。
The potential denial-of-service attack is not a serious one because the same result can be obtained more directly. An attacker with control of a Diameter node along the path of the original request could insert an Explicit-Path-Record containing the identity of another node or a non-existent node, rather than its own identity. Routing subsequent messages of the session through another node could result in violation of the trust assumptions made upstream. Routing subsequent messages to a non-existent node causes them to be lost and terminates the session. It would seem simpler to perpetrate whatever harm the attacker intends at the subverted Diameter node itself. The advantage of using ER to accomplish either of the attacks is that it makes it more difficult to determine which node misbehaved, but the extra effort involved to implement the attack does not seem to be worth the potential gain.
潜在的なDoS攻撃は、同じ結果がより直接的に得ることができるので、深刻なものではありません。元の要求の経路に沿ってDiameterノードの制御を持つ攻撃者は、別のノードまたは存在しないノードではなく、独自のアイデンティティの識別を含む明示的なパス・レコードを挿入することができました。別のノードを介してセッションの後続のメッセージをルーティングすることは、上流からなる信頼の仮定に違反が生じる可能性があります。存在しないノードに後続のメッセージをルーティングすることは、それらが失われ、セッションを終了します。攻撃者が覆さDiameterノード自体の意向どんな害犯すが簡単と思われます。攻撃のいずれかを達成するためにERを使用する利点は、より困難misbehavedどのノードが決定することができるが、攻撃を実装するのに関与して余分な労力が潜在的な利益の価値があるようには見えないということです。
The authors gratefully acknowledge the contributions of Tony Zhang, Fortune Huang, Rajith R., Victor Fajardo, Jouni Korhonen, Tolga Asveren, Mark Jones, Avi Lior, Steve Norreys, Lionel Morand, Dave Frascone, and Hannes Tschofenig.
作者は感謝トニー・チャン、フォーチュン黄、Rajith R.、ビクターファハルド、Jouni Korhonen、トルガAsveren、マーク・ジョーンズ、アビLIOR、スティーブNorreys、ライオネル・モラン、デイブFrascone、およびハンネスTschofenigの貢献を認めます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。
[RFC5729] Korhonen, J., Ed., Jones, M., Morand, L., and T. Tsou, "Clarifications on the Routing of Diameter Requests Based on the Username and the Realm", RFC 5729, December 2009.
[RFC5729] Korhonen、J.、編、ジョーンズ、M.、モラン、L.、及びT.ツオウ、RFC 5729 "ユーザ名とレルムに基づく直径要求のルーティングに明確化" 2009年12月。
[TS23.234] 3GPP, "3GPP system to Wireless Local Area Network (WLAN) interworking; System description", TS 23.234 Version 7.4.0, 2006.
"ワイヤレスローカルエリアネットワーク（WLAN）インターワーキングへの3GPPシステム、システムの説明" [TS23.234] 3GPP、TS 23.234バージョン7.4.0、2006年。
Authors' Addresses
著者のアドレス
Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA
ティナツオウ華為技術（USA）2330セントラルエクスプレスサンタクララ、CA 95050 USA
Phone: +1 408 330 4424 EMail: tena@huawei.com URI: http://tinatsou.weebly.com/contact.html
電話：+1 408 330 4424 Eメール：tena@huawei.com URI：http://tinatsou.weebly.com/contact.html
Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand
グレンツォルンネットワーク禅358分の227タノンSanphawutバンナー、バンコク10260タイ
Phone: +66 (0) 87-040-4617 EMail: gwz@net-zen.net
電話：+66（0）87-040-4617 Eメール：gwz@net-zen.net
Tom Taylor (editor) Huawei Technologies 1852 Lorraine Ave. Ottawa Canada
トム・テイラー（エディタ）華為技術1852ロレーヌアベニュー。オタワカナダ
EMail: tom111.taylor@bell.net
メールアドレス：tom111.taylor@bell.net