[要約] RFC 5729は、ユーザ名とレルムに基づいてダイアメータリクエストのルーティングを明確化するための要約です。目的は、ダイアメータプロトコルの実装者に対して、正確なルーティング方法を提供することです。
Network Working Group J. Korhonen, Ed.
Request for Comments: 5729 Nokia Siemens Networks
Updates: 3588 M. Jones
Category: Standards Track Bridgewater Systems
L. Morand
Orange Labs
T. Tsou
Huawei
December 2009
Clarifications on the Routing of Diameter Requests Based on the Username and the Realm
ユーザー名とレルムに基づいた直径要求のルーティングに関する説明
Abstract
概要
This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains a Network Access Identifier formatted with multiple realms. These multi-realm, or "Decorated", Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms.
この仕様では、ユーザー名属性値ペアに複数のレアムでフォーマットされたネットワークアクセス識別子が含まれている場合に、直径エージェントがリクエストをルーティングするために必要な動作を定義します。これらのマルチリアルム、または「装飾された」ネットワークアクセス識別子は、媒介領域の事前定義されたリストを介して要求メッセージのルーティングを強制するために使用されます。
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology and Abbreviations ...................................2
3. Problem Overview ................................................3
4. Solution Overview ...............................................5
4.1. Interpretation of Decorated NAIs ...........................5
4.2. Internationalization of Decorated NAIs .....................5
4.3. Ensuring Backwards Compatibility ...........................6
4.4. Enhanced Request Routing Solution ..........................7
5. Security Considerations .........................................8
6. Acknowledgements ................................................8
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair (AVP) contains a Network Access Identifier (NAI) formatted with multiple realms (hereafter referred to as a Decorated NAI). Decorated NAIs are used in order to force the routing of request messages through a predefined list of mediating realms. This specification does not define a new Diameter application but instead defines behaviour that would be common across all new Diameter applications that require request routing based on Decorated NAI.
この仕様は、ユーザー名属性値ペア（AVP）に複数のレルムでフォーマットされたネットワークアクセス識別子（NAI）が含まれている場合に、直径エージェントがリクエストをルーティングするために必要な動作を定義します（以下、装飾されたNAIと呼ばれる）。装飾されたNAIは、媒介領域の事前定義されたリストを介して要求メッセージのルーティングを強制するために使用されます。この仕様は、新しい直径アプリケーションを定義するのではなく、装飾されたNAIに基づいてリクエストルーティングを必要とするすべての新しい直径アプリケーションで一般的な動作を定義します。
The Diameter Base Protocol [RFC3588] NAI usage is originally based on [RFC2486], which has since been revised to [RFC4282]. While the use of multiple realms is generally discouraged, RFC 4282 does allow multiple realms. The use of this facility appears in, for instance, [RFC4284]. However, RFC 4282 does not define how the Decorated NAIs should be handled by Diameter agents, so this specification was written to capture those requirements.
直径ベースプロトコル[RFC3588] NAIの使用は、元々[RFC2486]に基づいており、その後[RFC4282]に改訂されました。複数の領域の使用は一般的に落胆しますが、RFC 4282は複数のレルムを許可します。この施設の使用は、たとえば[RFC4284]に表示されます。ただし、RFC 4282は、装飾されたNAIを直径エージェントによってどのように処理するかを定義していないため、この仕様はこれらの要件をキャプチャするために書き込まれました。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Network Access Identifier (NAI):
ネットワークアクセス識別子（NAI）：
The user identity submitted by the client during access authentication. In roaming, the purpose of the NAI is to identify the user as well as to assist in the routing of the authentication request.
アクセス認証中にクライアントが提出したユーザーID。ローミングでは、NAIの目的は、ユーザーを特定するだけでなく、認証要求のルーティングを支援することです。
Decorated NAI:
装飾されたnai：
An NAI containing multiple realms used to specify a source route and formatted according to Section 2.7 in RFC 4282.
ソースルートの指定に使用され、RFC 4282のセクション2.7に従ってフォーマットされた複数のレルを含むNAI。
Network Access Provider (NAP):
ネットワークアクセスプロバイダー（NAP）：
A business entity that provides network access infrastructure to one or more realms. A NAP infrastructure comprises one or more network access servers.
1つ以上の領域にネットワークアクセスインフラストラクチャを提供するビジネスエンティティ。NAPインフラストラクチャは、1つ以上のネットワークアクセスサーバーで構成されています。
Network Access Server (NAS):
ネットワークアクセスサーバー（NAS）：
The device to which peers connect in order to obtain access to the network.
ネットワークへのアクセスを取得するためにピアが接続するデバイス。
Section 6.1 of "The Diameter Base Protocol" (RFC 3588) defines the request routing in detail. That specification concerns only the cases where a Destination-Realm AVP is included in a Diameter request message. As described in RFC 3588 Section 6.1, a Diameter peer originating a request message MAY retrieve the realm information from the User-Name AVP and use that realm to populate the Destination-Realm AVP. In that case, the User-Name AVP is in form of an NAI including the realm part.
「直径ベースプロトコル」（RFC 3588）のセクション6.1は、リクエストルーティングを詳細に定義しています。その仕様は、Destination-RealM AVPが直径リクエストメッセージに含まれる場合のみに関係しています。RFC 3588セクション6.1で説明されているように、リクエストメッセージを発信する直径ピアは、ユーザー名AVPからレルム情報を取得し、そのレルムを使用して宛先-RealM AVPに入力する場合があります。その場合、ユーザー名AVPは、レルム部分を含むNAIの形式です。
Decorated NAIs are used to force routing of messages through a predefined list of realms and, in that way, force certain inter-realm roaming arrangements; see Section 2.7 of RFC 4282. For example, a terminal (e.g., a mobile host) may learn, based on some application-or implementation-specific manner, that its network access authentication signaling must traverse certain realms in order to reach the home realm. In this case, the terminal would decorate its NAI during the network access authentication with the list of intermediating realms and the home realm. As a result, the network access server (NAS) and intermediating Diameter agents would make sure that all Diameter request messages traverse through the desired realms as long as the request messages contain the User-Name AVP with a Decorated NAI.
装飾されたNAIは、事前定義されたレルムのリストを介してメッセージのルーティングを強制するために使用され、そのようにして、特定のリアルム間ローミングの配置を強制します。RFC 4282のセクション2.7を参照してください。たとえば、端末（モバイルホストなど）は、アプリケーションまたは実装固有の方法に基づいて、そのネットワークアクセス認証シグナリングがホーム領域に到達するために特定の領域を通過する必要があることを学習できます。。この場合、端末は、中間化レルムとホームレルムのリストを使用して、ネットワークアクセス認証中にNAIを飾ります。その結果、ネットワークアクセスサーバー（NAS）と中間直径エージェントは、リクエストメッセージに装飾されたNAIを含むユーザー名AVPが含まれている限り、すべての直径要求メッセージが目的のレルを通過することを確認します。
NAI decoration has previously been used in RADIUS-based [RFC2865] roaming networks, using RFC 2486 NAIs in a proprietary manner. There is a need to replicate the same NAI-based routing enforcement functionality in Diameter-based roaming networks. Moreover, there are publicly available specifications (e.g., see [3GPP.23.234], [3GPP.24.234], [3GPP.23.003], [3GPP.29.273], and [WiMAX]) that assume NAI-decoration-based request routing enforcement is fully supported by RFC 3588. The same assumption is carried over to Network Server Application Requirements (NASREQ) [RFC4005] and Extensible Authentication Protocol (EAP) [RFC4072] Diameter applications.
NAI装飾は、RFC 2486 NAISを独自の方法で使用して、RADIUSベースの[RFC2865]ローミングネットワークで以前に使用されてきました。直径ベースのローミングネットワークで、同じNAIベースのルーティング執行機能を複製する必要があります。さらに、公開されている仕様があります（例：[3GPP.23.234]、[3GPP.24.234]、[3GPP.23.003]、[3GPP.29.273]、および[Wimax]）は、NAI-Decorationベースの要求ルーティングエンゲルメントを想定しています。RFC 3588によって完全にサポートされています。同じ仮定がネットワークサーバーアプリケーション要件（NASREQ）[RFC4005]および拡張可能な認証プロトコル（EAP）[RFC4072]直径アプリケーションに引き継がれます。
Figure 1 illustrates an example deployment scenario where Decorated NAIs would be used to force a certain route through desired realms. A roaming terminal (e.g., a mobile host) discovers a number of Network Access Providers (NAP): NAP A and NAP B. None of the NAPs are able to provide direct connectivity to the roaming terminal's home realm (i.e., h.example.com). However, the roaming terminal learns, somehow, that NAP B is able to provide connectivity to h.example.com through x.example.com (i.e., the visited realm from the roaming terminal point of view). During the network access authentication, the roaming terminal would decorate its NAI as h.example.com!username@x.example.com. The roaming terminal has also an alternative route to its home realm through NAP A: z.example.com and x.example.com. If the roaming terminal were to choose to use NAP A, then it would decorate its NAI as x.example.com!h.example.com!username@z.example.com. Diameter agents would now be able to route the request message through desired realms using the Decorated NAI originally found in the User-Name AVP.
図1は、装飾されたNAIを使用して、目的の領域を介して特定のルートを強制するために使用される展開シナリオの例を示しています。ローミング端末（モバイルホストなど）は、多くのネットワークアクセスプロバイダー（NAP）を発見します。NAPAとNAPB。NAPは、ローミングターミナルのホームレルム（つまり、H.Exampleに直接接続することはできません。com）。ただし、ローミング端末は、どういうわけか、NAP BがX.example.com（つまり、ローミング端末の視点から訪問された領域）を介してh.example.comに接続できることを学習します。ネットワークアクセス認証中、ローミングターミナルはh.example.com！username@x.example.comとしてNAIを飾ります。ローミングターミナルには、NAP A：Z.Example.comおよびX.Example.comを介して、ホームレルムへの代替ルートもあります。ローミング端末がNAP Aを使用することを選択した場合、naiをX.example.com !h.example.com！username@z.example.comとして飾ります。直径エージェントは、ユーザー名AVPで最初に見つかった装飾されたNAIを使用して、目的の領域を介して要求メッセージをルーティングできるようになりました。
.--. .--. .--.
_(. `) _(. `) _(. `)
_( Visited`)_ _( Visited`)_ _( Home `)_
(z.example.com`)<---->(x.example.com`)<------>(h.example.com`)
( ` . ) ) ( ` . ) ) ( ` . ) )
`--(_______)---' `--(_______)---' `--(_______)---'
| __ /
| /
.--. .--.
_( `. _( `.
( NAP A ) ( NAP B )
( ` . ) ) ( ` . ) )
`--(___.-' `--(___.-'
)
( ( )
( |
+-+
|M|
+-+
Figure 1: Example roaming scenario with intermediating realms. The mobile host authenticates to the home realm through one or more visited realms.
図1：中間の領域でのローミングシナリオの例。モバイルホストは、1つ以上の訪問された領域を通じてホームレルムに認証されます。
NAI decoration is not limited to the network access authentication and authorization procedures. It can be used with any Diameter application whose commands are proxiable and include the User-Name AVP with an NAI. Generally, the NAI decoration can be used to force a certain route for all Diameter request messages at a realm granularity.
NAIの装飾は、ネットワークアクセス認証と承認手順に限定されません。コマンドがプロキシ可能である任意の直径アプリケーションで使用でき、NAIでユーザー名AVPを含めることができます。一般に、NAIの装飾は、領域の粒度ですべての直径要求メッセージの特定のルートを強制するために使用できます。
As a problem summary, we have two main issues:
問題の要約として、2つの主な問題があります。
o Updating both Destination-Realm and User-Name AVPs based on the Decorated NAI extracted from the User-Name AVP. The update would be done by intermediating Diameter agents that participate in realm-based request routing. Specifically, this would concern Diameter proxies.
o ユーザー名AVPから抽出された装飾されたNAIに基づいて、Destination-RealMとUser-Name AVPの両方を更新します。この更新は、レルムベースのリクエストルーティングに参加する中間直径エージェントによって行われます。具体的には、これは直径のプロキシに関係します。
o How Diameter agents could implement the handling of the NAI-decoration-based routing enforcement in a way that is still backwards compatible with RFC 3588.
o 直径エージェントが、RFC 3588とまだ逆方向に互換性のある方法で、NAI廃棄物ベースのルーティング施行の取り扱いをどのように実装できるか。
Section 2.3 of [RFC5113] also discusses NAI-decoration-related issues with EAP [RFC3748] in general.
[RFC5113]のセクション2.3は、一般的にEAP [RFC3748]に関するNAI-decoration関連の問題についても説明しています。
This specification defines a solution for Diameter realm-based request routing with routing enforcement using the User-Name AVP NAI decoration. Diameter proxy agent implementations can claim compliance using the solution described in this specification. The Diameter answer processing is left unmodified and follows the procedures described in Section 6.2 of RFC 3588.
この仕様は、ユーザー名AVP NAI装飾を使用したルーティング施行を備えた直径レルムベースの要求ルーティングのソリューションを定義します。直径プロキシエージェントの実装は、この仕様に記載されているソリューションを使用してコンプライアンスを請求できます。直径の回答処理は修正されておらず、RFC 3588のセクション6.2で説明されている手順に従います。
Implementations compliant to this specification MUST have a uniform way of interpreting decorated NAIs. That is, in the case of decoration, the character '!' (hexadecimal 0x21) is used to separate realms in the list of decorated realms in the NAI (as shown in examples in [RFC4282]).
この仕様に準拠した実装には、装飾されたNAIを解釈する均一な方法が必要です。つまり、装飾の場合、キャラクター「！」（Hexadecimal 0x21）は、NAIの装飾された領域のリストの領域を分離するために使用されます（[RFC4282]の例に示すように）。
RFC 3588, Section 1.3 states that NAI realm names are required to be unique and are piggybacked on the administration of the Domain Name System (DNS) ([RFC1034], [RFC1035]) namespace. However, an NAI, with or without decoration, may contain international characters as allowed by RFC 4282. This causes problems, as international characters as such are not supported by RFC 1034 and RFC 1035. The conversion of International Domain Names (IDN), which in this document's scope are NAI realms, are discussed in [RFC3490] and are further to be revised in [IDNA].
RFC 3588、セクション1.3では、NAIレルム名は一意であり、ドメイン名システム（DNS）の管理（[RFC1034]、[RFC1035]）の名前空間の投与にピギーバックされていると述べています。ただし、装飾の有無にかかわらず、NAIにはRFC 4282で許可されている国際的なキャラクターが含まれている場合があります。これは、RFC 1034およびRFC 1035でサポートされていないため、問題を引き起こします。このドキュメントの範囲では、NAIレルムがあり、[RFC3490]で説明されており、[IDNA]でさらに改訂されます。
The general guidance for handling NAI realms with international characters is described in Section 2.4 of RFC 4282 and discussed more in [NAI] based on recent operational experiences. This specification does not attempt to fix the issue with the internationalization of NAIs, as the problem space is large and concerns much more than just NAI realms and NAI decoration. However, this specification has the following assumptions:
NAIレルムを国際的なキャラクターで処理するための一般的なガイダンスは、RFC 4282のセクション2.4で説明されており、最近の運用経験に基づいて[NAI]で詳しく説明しています。この仕様は、問題のスペースが大きく、Nai RealmsやNaiの装飾だけでなく、はるかに関心があるため、NAISの国際化に関する問題を修正しようとはしません。ただし、この仕様には次の仮定があります。
o The conversion from a realm name that includes international characters to ASCII-compatible encoding should only take place when DNS infrastructure needs to be queried and not, for example, during the realm-placement processing of Decorated NAIs. The conversion is normally handled by a DNS resolver library on the local Diameter agent or, when not available in the resolver library, by the Diameter agent. In both cases, the realm in the NAI remains unchanged.
o 国際的なキャラクターを含む領域名からASCII互換のエンコードへの変換は、DNSインフラストラクチャを照会する必要がある場合にのみ行われるべきであり、たとえば、装飾されたNAIの領域配置処理中には行われません。コンバージョンは通常、ローカル直径エージェントのDNSリゾルバーライブラリによって処理されます。また、リゾルバーライブラリで利用できない場合は、直径エージェントによって処理されます。どちらの場合も、NAIの領域は変わらないままです。
o It is the responsibility of the operators administrating their realm and domain name spaces to ensure that the DNS is provisioned properly for all realms that may appear in Decorated NAIs. This implicitly requires that the conversion from any realm with international characters to a domain name cannot fail (i.e., the realms conform to the preconditions for internationalized domain names).
o DNSが装飾されたNAIに表示される可能性のあるすべての領域に対して適切にプロビジョニングされることを保証するために、領域とドメイン名スペースを管理するオペレーターの責任です。これは、国際的な文字を持つ領域からドメイン名への領域からの変換が失敗することがないことを暗黙的に必要とします（つまり、領域は国際化されたドメイン名の前提条件に適合します）。
From the above discussion, it can be concluded that avoiding international characters in realms contained in NAIs is the best way to avoid problems with internationalized domain names and Decorated NAI handling in general.
上記の議論から、NAISに含まれる領域での国際的なキャラクターを避けることは、国際化されたドメイン名と装飾されたNAIハンドリングの問題を避けるための最良の方法であると結論付けることができます。
The handling of the NAI-decoration-based routing enforcement as described in this specification will be supported by any new Diameter application. Therefore, backwards compatibility with existing Diameter implementations, applications, and deployments will be guaranteed. Existing Diameter agents not compliant with this specification will not advertise support for these new applications that implement the enhanced routing solution based on Decorated NAIs, and will therefore be bypassed.
この仕様で説明されているNAI-Decorationベースのルーティング施行の取り扱いは、新しい直径アプリケーションによってサポートされます。したがって、既存の直径の実装、アプリケーション、および展開との逆方向の互換性が保証されます。この仕様に準拠していない既存の直径エージェントは、装飾されたNAISに基づいて拡張されたルーティングソリューションを実装するこれらの新しいアプリケーションのサポートを宣伝しないため、バイパスされます。
When a Diameter client originates a request message, the Destination-Realm AVP is populated with the realm part of the NAI available in the User-Name AVP (the realm given after the '@' character of the NAI). The NAI in the User-Name AVP may or may not be decorated.
直径クライアントがリクエストメッセージを発信すると、宛先-RealM AVPには、ユーザー名AVP（NAIの@'文字の後に与えられたレルム）で利用可能なNAIのレルム部分が入力されます。ユーザー名AVPのNAIは、装飾されている場合とそうでない場合があります。
When a Diameter agent receives a request message containing the Destination-Realm AVP with a realm that the agent is configured to process locally (and, in the case of proxies, the Diameter application is locally supported), it MUST do the following further processing before handling the message locally:
直径エージェントが、エージェントがローカルで処理するように構成されているという領域を備えた宛先RealM AVPを含む要求メッセージを受信する場合（そして、プロキシの場合、直径アプリケーションはローカルでサポートされています）、以前に次の処理を行う必要がありますメッセージをローカルで処理する：
o If the User-Name AVP is available in the request message, then the Diameter agent MUST inspect whether the User-Name AVP contains a Decorated NAI. If the NAI is not decorated, then the Diameter agent proceeds with a normal RFC 3588 message processing.
o ユーザー名AVPがリクエストメッセージで利用可能である場合、Diameterエージェントは、ユーザー名AVPに装飾されたNAIが含まれているかどうかを検査する必要があります。NAIが装飾されていない場合、直径エージェントは通常のRFC 3588メッセージ処理で進行します。
o If the User-Name AVP contains a Decorated NAI, then the Diameter agent MUST process the NAI as defined in RFC 4282 and update the value of the User-Name AVP accordingly. Furthermore, the Diameter agent MUST update the Destination-Realm AVP to match the new realm in the User-Name AVP.
o ユーザー名AVPに装飾されたNAIが含まれている場合、直径エージェントはRFC 4282で定義されているようにNAIを処理し、それに応じてユーザー名AVPの値を更新する必要があります。さらに、直径エージェントは、ユーザー名AVPの新しいレルムと一致するように、Destination-RealM AVPを更新する必要があります。
o The request message is then sent to the next hop using the normal request routing rules as defined in RFC 3588.
o リクエストメッセージは、RFC 3588で定義されている通常の要求ルーティングルールを使用して、次のホップに送信されます。
Figure 2 illustrates an example of a roaming terminal that originates signaling with the home realm (h.example.com), through a NAP and two intermediating realms (z.example.com, x.example.com) before reaching the home realm (h.example.com). The example shows how the User-Name AVP and the Destination-Realm AVP change at each realm before reaching the final destination. If the signaling were originated from the NAS/NAP only, then step 1 can be omitted.
図2は、ホームレルムに到達する前に、昼寝と2つの中間領域（z.example.com、x.example.com）を介して、ホームレルム（h.example.com）とのシグナル伝達を発信するローミング端末の例を示しています（h.example.com）h.example.com）。この例は、最終目的地に到達する前に、各領域でユーザー名のAVPと宛先-RealM AVPがどのように変化するかを示しています。信号がNAS/NAPからのみ発生した場合、ステップ1は省略できます。
1) Roaming Terminal -> NAS/NAP
Identity/NAI = x.example.com!h.example.com!username@z.example.com
2) NAS/NAP -> z.example.com
User-Name = x.example.com!h.example.com!username@z.example.com
Destination-Realm = z.example.com
3) Realm-Z -> x.example.com
User-Name = h.example.com!username@x.example.com
Destination-Realm = x.example.com
4) Realm-X -> h.example.com
User-Name = username@h.example.com
Destination-Realm = h.example.com
Figure 2: The roaming terminal decides that the Diameter messages must be routed via z.example.com and x.example.com to h.example.com.
図2：ローミング端末は、直径メッセージをz.example.comおよびx.example.comを介してh.example.comにルーティングする必要があることを決定します。
A malicious node initiating (or indirectly causing initiation of) a Diameter request may purposely create a malformed list of realms in the NAI. This may cause the routing of requests through realms that would normally have nothing to do with the initiated Diameter message exchange. Furthermore, a malformed list of realms may contain non-existing realms, causing the routing of Diameter messages that cannot ultimately be routed anywhere. However, the request message might get routed several hops before such non-existent realms are discovered, thus creating unnecessary overhead to the routing system in general.
直径リクエストを開始する（または間接的に開始を引き起こす）悪意のあるノードは、NAIの領域の不正なリストを意図的に作成する場合があります。これにより、通常、開始された直径メッセージ交換とは何の関係もないレルムを介した要求のルーティングが発生する可能性があります。さらに、領域の奇形のリストには存在しない領域が含まれている可能性があり、最終的にはどこにもルーティングできない直径メッセージのルーティングを引き起こす可能性があります。ただし、リクエストメッセージは、このような存在しない領域が発見される前にいくつかのホップをルーティングする可能性があり、したがって、一般的なルーティングシステムに不必要なオーバーヘッドを作成します。
The NAI decoration is used in Authentication, Authorization, and Accounting (AAA) infrastructures where the Diameter messages are transported between the NAS and the Diameter server via one or more AAA brokers or Diameter proxies. In this case, the NAS to Diameter server AAA communication relies on the security properties of the intermediate AAA brokers and Diameter proxies.
NAIの装飾は、1つ以上のAAAブローカーまたは直径プロキシを介して、NASと直径サーバーの間で直径メッセージが輸送される認証、承認、および会計（AAA）インフラストラクチャで使用されます。この場合、NASからDiameter Server AAA通信は、中間AAAブローカーと直径プロキシのセキュリティプロパティに依存しています。
The authors would like to thank Victor Fajardo, Stefan Winter, Jari Arkko, and Avi Lior for their detailed comments on this document.
著者は、この文書に関する詳細なコメントについて、Victor Fajardo、Stefan Winter、Jari Arkko、Avi Liorに感謝したいと思います。
Jouni Korhonen would like to thank the TEKES WISEciti project for providing funding to work on this document while he was at TeliaSonera's employ.
Jouni Korhonenは、Tekes Wisecitiプロジェクトに、Teliasoneraの雇用中にこの文書に取り組むための資金提供を提供してくれたことに感謝したいと思います。
[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月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J。、およびP. Eronen、「ネットワークアクセス識別子」、RFC 4282、2005年12月。
[3GPP.23.003] 3GPP, "Numbering, addressing and identification", 3GPP TS 23.003 8.5.0, June 2009.
[3GPP.23.003] 3GPP、「番号付け、アドレス指定、識別」、3GPP TS 23.003 8.5.0、2009年6月。
[3GPP.23.234] 3GPP, "3GPP system to Wireless Local Area Network (WLAN) interworking; System description", 3GPP TS 23.234 6.10.0, October 2006.
[3GPP.23.234] 3GPP、「3GPPシステムからワイヤレスローカルエリアネットワーク（WLAN）インターワーキング、システム説明」、3GPP TS 23.234 6.10.0、2006年10月。
[3GPP.24.234] 3GPP, "3GPP system to Wireless Local Area Network (WLAN) interworking; WLAN User Equipment (WLAN UE) to network protocols; Stage 3", 3GPP TS 24.234 6.7.0, October 2006.
[3GPP.24.234] 3GPP、「3GPPシステムからワイヤレスローカルエリアネットワーク（WLAN）インターワーキング、WLANユーザー機器（WLAN UE）へのネットワークプロトコル、ステージ3 "、3GPP TS 24.234 6.7.0、2006年10月。
[3GPP.29.273] 3GPP, "Evolved Packet System (EPS); 3GPP EPS AAA interfaces", 3GPP TS 29.273 8.3.0, September 2009.
[3GPP.29.273] 3GPP、「Evolved Packet System（EPS）; 3GPP EPS AAAインターフェイス」、3GPP TS 29.273 8.3.0、2009年9月。
[NAI] DeKok, A., "The Network Access Identifier", Work in Progress, September 2009.
[Nai] Dekok、A。、「ネットワークアクセス識別子」、2009年9月、進行中の作業。
[IDNA] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", Work in Progress, October 2009.
[IDNA] Klensin、J。、「アプリケーションの国際化されたドメイン名（IDNA）：プロトコル」、2009年10月の作業。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[RFC2486] Aboba、B。およびM. Beadles、「ネットワークアクセス識別子」、RFC 2486、1999年1月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、ed。、「Extensible認証プロトコル（EAP）」、RFC 3748、2004年6月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005] Calhoun、P.、Zorn、G.、Spence、D。、およびD. Mitton、「Diameter Network Access Server Application」、RFC 4005、2005年8月。
[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072] Eronen、P.、Ed。、Hiller、T。、およびG. Zorn、「直径拡張可能な認証プロトコル（EAP）アプリケーション」、RFC 4072、2005年8月。
[RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity Selection Hints for the Extensible Authentication Protocol (EAP)", RFC 4284, January 2006.
[RFC4284] Adrangi、F.、Lortz、V.、Bari、F。、およびP. Eronen、「拡張可能な認証プロトコル（EAP）のアイデンティティ選択ヒント」、RFC 4284、2006年1月。
[RFC5113] Arkko, J., Aboba, B., Korhonen, J., Ed., and F. Bari, "Network Discovery and Selection Problem", RFC 5113, January 2008.
[RFC5113] Arkko、J.、Aboba、B.、Korhonen、J.、Ed。、およびF. Bari、「ネットワーク発見と選択問題」、RFC 5113、2008年1月。
[WiMAX] WiMAX Forum, "WiMAX Forum Network Architecture (Stage 2: Architecture Tenets, Reference Model and Reference Points)", Release 1 Version 1.2, January 2008.
[Wimax] Wimax Forum、「Wimax Forum Network Architecture（ステージ2：アーキテクチャの教義、参照モデルおよび参照ポイント）」、リリース1バージョン1.2、2008年1月。
Authors' Addresses
著者のアドレス
Jouni Korhonen (editor) Nokia Siemens Networks Linnoitustie 6 Espoo FIN-02600 Finland
Jouni Korhonen（編集者）Nokia Siemens Networks Linnoitustie 6 Espoo Fin-02600フィンランド
EMail: jouni.nospam@gmail.com
Mark Jones Bridgewater Systems 303 Terry Fox Drive Ottawa, Ontario K2K 3J1 Canada
マークジョーンズブリッジウォーターシステム303テリーフォックスドライブオンタリオ州K2K 3J1カナダ
EMail: Mark.Jones@bridgewatersystems.com
Lionel Morand Orange Labs 38-40 rue du general Leclerc Issy-moulineaux Cedex 9, 92794 France
Lionel Morand Orange Labs 38-40 Rue du General Leclerc Issy-Moulineaux Cedex 9、92794 France
EMail: Lionel.morand@orange-ftgroup.com
Tina Tsou (Ting ZOU) Huawei R&D Center, Huawei Technologies Co., Ltd Bantian, Shenzhen P.R. China
Tina Tsou（Ting Zou）Huawei R＆D Center、Huawei Technologies Co.、Ltd Bantian、Shenzhen P.R. China
EMail: tena@huawei.com