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.
著作権（C）2009 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. 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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション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を媒介レルムの事前定義されたリストをリクエストメッセージのルーティングを強制するために使用されています。この仕様は、新しいDiameterアプリケーションを定義する代わりにデコレーションされたNAIに基づいて要求ルーティングを必要とするすべての新しいDiameterアプリケーション間で共通になり動作を定義していません。
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.
Diameter基本プロトコル[RFC3588] NAIの使用は、もともとので、[RFC4282]に修正されている[RFC2486]に基づいています。複数のレルムの使用は、一般的に推奨されますが、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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:
Dekoreted犬：
An NAI containing multiple realms used to specify a source route and formatted according to Section 2.7 in RFC 4282.
複数のレルムを含むNAIは、ソースルートを指定するために使用され、RFC 4282で、セクション2.7に従ってフォーマット。
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.
一の以上のレルムへのネットワークアクセスインフラストラクチャを提供する事業体。 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で詳細にルーティング要求を定義します。だけで仕様の問題宛先レルムAVPは直径要求メッセージに含まれている場合。 RFC 3588のセクション6.1で説明したように、要求メッセージを発信するDiameterピアは、ユーザー名AVPからのレルム情報を取得し、宛先レルム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件のNAIを使用して、RADIUSベース[RFC2865]ローミングネットワークで使用されてきました。直径ベースのローミングネットワークに同じNAIベースのルーティング執行機能を複製する必要があります。また、NAIの装飾ベースのリクエストルーティング適用を想定公的に利用可能な仕様（例えば、参照[3GPP.23.234]、[3GPP.24.234]、[3GPP.23.003]、[3GPP.29.273]、および[WiMAXは]）が存在します完全RFC 3588.同じ仮定によって支持されているが、ネットワークサーバアプリケーション要件（NASREQ）[RFC4005]および拡張認証プロトコル（EAP）[RFC4072] Diameterアプリケーションに引き継がれます。
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）の数を発見：のNAPのNAP AとNAP B.なしローミング端末のホーム領域（すなわち、h.exampleへの直接接続性を提供することができません。 comなど）。しかしながら、ローミング端末はNAP Bはx.example.com介しh.example.comへの接続を提供することができることを、何らかの方法で、学習する（すなわち、ビューのローミング端末点から訪問レルム）。ネットワークアクセス認証時には、ローミング端末はh.example.com!username@x.example.comとしてのNAIを飾るでしょう。 z.example.comとx.example.com：ローミング端末はNAP Aを通じたホーム領域への代替ルートを持っています。ローミング端末がNAP Aを使用することを選択した場合、それはx.example.com!h.example.com!username@z.example.comとしてのNAIを飾るでしょう。直径剤は、現在、もともとユーザ名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：例レルムを仲介してシナリオをローミング。モバイルホストは、一つ以上の訪問のレルムを通じてホームレルムに認証します。
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の装飾は、ネットワークアクセスの認証と承認手続きに限定されるものではありません。それは、そのコマンドプロキシ可能であり、ユーザ名AVP NAIとを含む任意のDiameterアプリケーションで使用することができます。一般に、NAIデコレーションはレルム単位で全てのDiameter要求メッセージの特定の経路を強制するために使用することができます。
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.
装飾NAIに基づいて宛先領域とユーザー名のAVPの両方を更新oをユーザー名AVPから抽出しました。更新は、レルムベースの要求のルーティングに参加直径剤を仲介することによって行われるであろう。具体的には、これは、Diameterプロキシを懸念ます。
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-装飾関連の問題について説明します。
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を解釈する統一的な方法を持たなければなりません。これは、装飾、文字の場合には、「！」 （16進数0x21では）（[RFC4282]の例に示されるように）NAIで装飾レルムのリストにレルムを分離するために使用されます。
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
RFC 3588、NAIレルム名が一意であることが必要であり、ドメインネームシステム（DNS）（[RFC1034]、[RFC1035]）名前空間の管理に背負わされている第1.3節の状態。以下のような国際的な文字がRFC 1034およびRFC 1035ザ・によってサポートされていないとして許可しかし、NAIは、または装飾なし、RFC 4282.で国際文字が含まれていることがありますが、これは、問題が発生します
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].
この文書の範囲内のNAIのレルムである国際化ドメイン名（IDN）の変換は、[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レルムとNAIの装飾よりもはるかに多くの懸念事項として、この仕様は、のNAIの国際化の問題を解決しようとしません。しかし、この仕様は、以下の仮定があります。
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.
DNSインフラストラクチャは、装飾のNAIのレルム配置処理中に、例えば、照会する必要があり、ない場合にのみ行われるべきであるASCII互換エンコーディングに国際的な文字を含むレルム名からの変換、O。変換は、通常、直径エージェントによって、リゾルバライブラリで利用できないローカル直径剤や、上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.
上記の議論から、のNAIに含まれるレルムで国際文字を回避することは一般的に取り扱う国際化ドメイン名や装飾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の装飾ベースのルーティング施行の取り扱いは、新しいDiameterアプリケーションによってサポートされます。したがって、既存のDiameter実装、アプリケーション、および展開との下位互換性が保証されます。この仕様に準拠していない既存の直径エージェントは、装飾のNAIに基づいて強化されたルーティングソリューションを実装し、これらの新しいアプリケーションのサポートをアドバタイズしませんので、バイパスされます。
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.
Diameterクライアントが要求メッセージを発信する場合、宛先領域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:
直径エージェントは、エージェントがローカルに処理するように構成されている（そして、プロキシの場合には、Diameterアプリケーションがローカルにサポートされている）ことをレルムと宛先レルム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.
ユーザ名AVPは、要求メッセージに利用可能である場合、O、次いで直径エージェントは、ユーザ名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.
ユーザ名AVPがデコレーションされたNAIが含まれている場合は、O、RFC 4282で定義されるように、次いで直径エージェントはNAIを処理しなければならないし、それに応じてユーザ名AVPの値を更新します。さらに、直径エージェントは、ユーザー名AVPに新しいレルムに一致するように宛先レルムAVPを更新する必要があります。
o The request message is then sent to the next hop using the normal request routing rules as defined in RFC 3588.
RFC 3588で定義されているO要求メッセージは、通常のリクエストルーティングルールを使用して、次のホップに送信されます。
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は、（ホーム領域に到達する前にNAP二仲介レルム（z.example.com、x.example.com）を介して、ホーム領域（h.example.com）とシグナリング発信ローミング端末の一例を示す図h.example.com）。例では、どのようにユーザー名AVPと最終目的地に到達する前に各レルムでの宛先領域AVP変化を示しています。シグナリングのみNAS / NAPから発信された場合、ステップ1を省略することができます。
1) Roaming Terminal -> NAS/NAP Identity/NAI = x.example.com!h.example.com!username@z.example.com
1）ローミング端子 - > NAS / NAPアイデンティティ/ 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
2）NAS / NAP - > z.example.comユーザー名= x.example.com!h.example.com!username@z.example.com宛先レルム= z.example.com
3) Realm-Z -> x.example.com User-Name = h.example.com!username@x.example.com Destination-Realm = x.example.com
3）レルム-Z - > x.example.comユーザー名= h.example.com!username@x.example.com宛先レルム= x.example.com
4) Realm-X -> h.example.com User-Name = username@h.example.com Destination-Realm = h.example.com
4）レルム-X - > h.example.comユーザー名= username@h.example.com宛先レルム= 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：ローミング端末はDiameterメッセージがh.example.comにz.example.comとx.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におけるレルムの不正な形式のリストを作成してもよいです。これは、通常、開始Diameterメッセージ交換とは何の関係もないだろう、レルムを通じて要求のルーティングを引き起こす可能性があります。また、レルムの不正な形式のリストは、最終的にどこにルーティングすることができないDiameterメッセージのルーティングを引き起こし、非既存のレルムを含んでいてもよいです。このような非実在のレルムが発見される前に、しかし、要求メッセージは、このように一般的なルーティングシステムに不要なオーバーヘッドを作成し、いくつかのホップをルーティングされてしまうかもしれません。
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デコレーションは、Diameterメッセージは、1つまたは複数のAAAブローカーまたは直径プロキシを介してNASとDiameterサーバとの間で輸送される認証、許可、アカウンティング（AAA）インフラストラクチャで使用されています。この場合、NASダイアメータサーバにAAAの通信は、中間AAAブローカーとDiameterプロキシのセキュリティ特性に依存しています。
The authors would like to thank Victor Fajardo, Stefan Winter, Jari Arkko, and Avi Lior for their detailed comments on this document.
著者は、この文書にその詳細なコメントをビクターファハルド、ステファン・ウィンター、ヤリArkko、およびアビ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プロジェクトに感謝したいと思います。
[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月。
[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、 "ワイヤレスローカルエリアネットワーク（WLAN）への3GPPシステムインターワーキング、システムの説明"、3GPP TS 23.234 6.10、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.
"ワイヤレスローカルエリアネットワーク（WLAN）インターワーキングへの3GPPシステム、WLANユーザ機器（WLAN UE）ネットワークプロトコルに、ステージ3" [3GPP.24.234] 3GPP、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、 "進化型パケットシステム（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] "アプリケーションにおける国際化ドメイン名（IDNA）：プロトコル" Klensin、J.、進歩、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.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（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.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、編、 "拡張認証プロトコル（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]カルフーン、P.、ツォルン、G.、スペンス、D.、およびD.ミトン、 "直径ネットワークアクセスサーバーアプリケーション"、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.編、ヒラー、T.、およびG.ゾルン、 "直径拡張認証プロトコル（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.、バーリ、F.、およびP. Eronen、2006年1月、RFC 4284 "アイデンティティの選択は、拡張認証プロトコル（EAP）のためのヒント"。
[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.、エド。、およびF.バーリ、 "ネットワーク探索と選択問題"、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フォーラム、 "WiMAXフォーラムネットワークアーキテクチャ（ステージ2：建築理念、参照モデルと参照ポイント）"、リリース1バージョン1.2、2008年1月。
Authors' Addresses
著者のアドレス
Jouni Korhonen (editor) Nokia Siemens Networks Linnoitustie 6 Espoo FIN-02600 Finland
Jouni Korhonen（編集）、ノキアシーメンスネットワークスLinnoitustie 6 FIN-02600エスポーフィンランド
EMail: jouni.nospam@gmail.com
メールアドレス：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
メールアドレス：Mark.Jones@bridgewatersystems.com
Lionel Morand Orange Labs 38-40 rue du general Leclerc Issy-moulineaux Cedex 9, 92794 France
38-40 RUEの一般ルクレールイシムリノーセデックス9、フランス92794のライオネル・モランオレンジ研究所
EMail: Lionel.morand@orange-ftgroup.com
メールアドレス：Lionel.morand@orange-ftgroup.com
Tina Tsou (Ting ZOU) Huawei R&D Center, Huawei Technologies Co., Ltd Bantian, Shenzhen P.R. China
ティナT検索（ティンZ OU）HU A、R＆DセンターであるHU Aは、技術の共同で、株式会社の禁止の日、彼女N中華人民共和国の町
EMail: tena@huawei.com
メールアドレス：tena@huawei.com