Network Working Group J. Arkko
Request for Comments: 5113 Ericsson
Category: Informational B. Aboba
Microsoft
J. Korhonen, Ed.
TeliaSonera
F. Bari
AT&T
January 2008
Network Discovery and Selection Problem
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
When multiple access networks are available, users may have difficulty in selecting which network to connect to and how to authenticate with that network. This document defines the network discovery and selection problem, dividing it into multiple sub-problems. Some constraints on potential solutions are outlined, and the limitations of several solutions (including existing ones) are discussed.
複数のアクセスネットワークが利用可能な場合、ユーザーは、接続先のネットワークおよびそのネットワークで認証する方法を選択することが困難であってもよいです。この文書は、複数のサブ問題に分割し、ネットワーク発見と選択の問題を定義します。潜在的な解決策のいくつかの制約が概説されており、（既存のものを含む）いくつかのソリューションの限界が議論されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology Used in This Document . . . . . . . . . . . . 4
2. Problem Definition . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Discovery of Points of Attachment . . . . . . . . . . . . 8
2.2. Identity Selection . . . . . . . . . . . . . . . . . . . . 9
2.3. AAA Routing . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1. The Default Free Zone . . . . . . . . . . . . . . . . 13
2.3.2. Route Selection and Policy . . . . . . . . . . . . . . 14
2.3.3. Source Routing . . . . . . . . . . . . . . . . . . . . 15
2.4. Network Capabilities Discovery . . . . . . . . . . . . . . 17
3. Design Issues . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1. AAA Routing . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Backward Compatibility . . . . . . . . . . . . . . . . . . 18
3.3. Efficiency Constraints . . . . . . . . . . . . . . . . . . 19
3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 19
3.5. Static Versus Dynamic Discovery . . . . . . . . . . . . . 21
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.7. Management . . . . . . . . . . . . . . . . . . . . . . . . 22
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. Informative References . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Existing Work . . . . . . . . . . . . . . . . . . . . 32
A.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.2. IEEE 802 . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.3. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.4. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 37
Today, network access clients are typically pre-configured with a list of access networks and corresponding identities and credentials. However, as network access mechanisms and operators have proliferated, it has become increasingly likely that users will encounter networks for which no pre-configured settings are available, yet which offer desired services and the ability to successfully authenticate with the user's home realm. It is also possible that pre-configured settings will not be adequate in some situations. In such a situation, users can have difficulty in determining which network to connect to, and how to authenticate to that network.
今日では、ネットワーク・アクセス・クライアントは通常、アクセスネットワークとそれに対応する識別情報と資格情報のリストを事前に設定されています。ネットワークアクセスメカニズムとオペレータが増殖してきたようにしかし、それは、ユーザーが何も事前に構成された設定が用意されていない、まだ必要なサービスと、正常ユーザのホームレルムで認証する機能を提供しているためネットワークに遭遇することがますますそうなってきました。事前に構成された設定は、いくつかの状況では十分ではないということも可能です。このような状況では、ユーザーは、接続するネットワークを決定することが困難であることができ、およびそのネットワークへの認証方法。
The problem arises when any of the following conditions are true:
以下の条件のいずれかに該当する場合、問題が発生します：
o Within a single network, more than one network attachment point is available, and the attachment points differ in their roaming arrangements, or access to services. While the link layer capabilities of a point of attachment may be advertised, higher-layer capabilities, such as roaming arrangements, end-to-end quality of service, or Internet access restrictions, may not be. As a result, a user may have difficulty determining which services are available at each network attachment point, and which attachment points it can successfully authenticate to. For example, it is possible that a roaming agreement will only enable a user to authenticate to the home realm from some points of attachment, but not others. Similarly, it is possible that access to the Internet may be restricted at some points of attachment, but not others, or that end-to-end quality of service may not be available in all locations. In these situations, the network access client cannot assume that all points of attachment within a network offer identical capabilities.
単一ネットワーク内のO、複数のネットワーク接続ポイントが利用可能であり、結合点は、そのローミング配置が異なる、またはサービスへのアクセス。結合点のリンク層の機能を宣伝することができるが、このようなローミング契約、サービスのエンドツーエンドの品質、またはインターネットへのアクセス制限など、上位層の機能は、ないかもしれません。その結果、ユーザは難易度のサービスは、各ネットワーク接続ポイントで利用可能である決定を有していてもよく、及びその添付ファイルのポイントは、正常に認証を受けることができます。例えば、ローミング契約が唯一のいくつかの結合点ではなく、他の人からホームレルムに認証することを可能にすることが可能です。同様に、インターネットへのアクセスが添付ファイルのいくつかの点で制限はない他の人、またはサービスのエンドツーエンドの品質は、すべての場所で利用できない場合がされる可能性があります。このような状況では、ネットワーク・アクセス・クライアントは、ネットワーク内の添付ファイルのすべての点は、同一の機能を提供することを仮定することはできません。
o Multiple networks are available for which the user has no corresponding pre-configuration. The user may not have pre-configured an identity and associated credentials for use with a network, yet it is possible that the user's home realm is reachable from that network, enabling the user to successfully authenticate. However, unless the roaming arrangements are advertised, the network access client cannot determine a priori whether successful authentication is likely. In this situation, it is possible that the user will need to try multiple networks in order to find one to which it can successfully authenticate, or it is possible that the user will not be able to obtain access at all, even though successful authentication is feasible.
O複数のネットワークは、ユーザが該当する事前設定を持たないために利用可能です。ユーザーは、事前に構成されたネットワークで使用するためのアイデンティティと関連する資格情報を持っていない可能性があり、まだユーザのホーム領域が正常に認証するユーザーを有効にすると、そのネットワークから到達可能であることも可能です。ローミング契約が公示されている場合を除きしかし、ネットワーク・アクセス・クライアントは、認証の成功の可能性があるかどうかを演繹的に決定することはできません。このような状況では、ユーザーは、それが正常に認証できたものを見つけるために複数のネットワークを試してみる必要があるだろうことは可能である、またはユーザーが認証の成功があるにもかかわらず、全くのアクセスを得ることができない可能性があり実現可能。
o The user has multiple sets of credentials. Where no pre-configuration exists, it is possible that the user will not be able to determine which credentials to use with which attachment point, or even whether any credentials it possesses will allow it to authenticate successfully. An identity and associated credentials can be usable for authentication with multiple networks, and not all of these networks will be pre-configured. For example, the user could have one set of credentials from a public service provider and another set from an employer, and a network might enable authentication with one or more of these credentials. Yet, without pre-configuration, multiple unsuccessful authentication attempts could be needed for each attachment point in order to determine what credentials are usable, wasting valuable time and resulting in user frustration. In order to choose between multiple attachment points, it can be helpful to provide additional information to enable the correct credentials to be determined.
Oユーザーは、資格情報の複数のセットを持っています。何ら事前設定が存在しない場合、ユーザがどの接続ポイントで使用する資格情報、又はそれが有する任意の資格情報が、それが正常に認証することを可能にするかどうかをも決定することができないことが可能です。アイデンティティと関連した資格情報は、複数のネットワークでの認証のために使用可能とすることができ、これらのネットワークのすべては、事前に構成されるわけではありません。例えば、ユーザは、1つの公共サービスプロバイダから資格情報のセットと、雇用主からの別のセットを持つことができ、およびネットワークは、これらの資格情報のうちの1つまたは複数と認証を有効かもしれません。しかし、事前設定することなく、複数の不成功の認証試行は、貴重な時間を浪費し、ユーザのフラストレーションをもたらす、資格情報が使用可能であるかを決定するために、各接続ポイントのために必要とされ得ます。複数の取り付け点の間で選択するためには、測定すべき適切な資格情報を有効にするために追加情報を提供するために有用であることができます。
o There are multiple potential roaming paths between the visited realm and the user's home realm, and service parameters or pricing differs between them. In this situation, there could be multiple ways for the user to successfully authenticate using the same identity and credentials, yet the cost of each approach might differ. In this case, the access network may not be able to determine the roaming path that best matches the user's preferences. This can lead to the user being charged more than necessary, or not obtaining the desired services. For example, the visited access realm could have both a direct relationship with the home realm and an indirect relationship through a roaming consortium. Current Authentication, Authorization, and Accounting (AAA) protocols may not be able to route the access request to the home AAA sever purely based on the realm within the Network Access Identifier (NAI) [RFC4282]. In addition, payload packets can be routed or tunneled differently, based on the roaming relationship path. This may have an impact on the available services or their pricing.
O訪れた領域とユーザのホームレルム、およびサービスパラメータや価格設定、それらの間に異なるとの間に複数の潜在的なローミングパスがあります。このような状況では、成功した同じIDと認証情報を使用して、まだそれぞれのアプローチのコストは異なる場合がありますを認証するユーザーのための複数の方法があるかもしれません。この場合、アクセスネットワークは、最高のユーザーの好みにマッチするローミングパスを決定することができないかもしれません。ユーザーにつながることができますこれは、必要以上に充電し、又は所望のサービスを取得していないされています。例えば、訪問先のアクセスレルムはホーム領域とローミングコンソーシアムによる間接的な関係との直接的な関係の両方を持つことができます。現在の認証、許可、アカウンティング（AAA）プロトコルは、ルート純粋にネットワークアクセス識別子（NAI）[RFC4282]内の領域に基づいて、ホームAAAサーバへアクセス要求にできないかもしれません。また、ペイロードパケットは、ローミング関係のパスに基づいて、ルーティングまたは別々にトンネリングすることができます。これは、利用可能なサービスやその価格設定に影響を与える可能性があります。
In Section 2, the network discovery and selection problem is defined and divided into sub-problems. Some solution constraints are outlined in Section 3. Section 4 provides conclusions and suggestions for future work. Appendix A discusses existing solutions to portions of the problem.
第2節では、ネットワーク発見と選択の問題が定義され、副問題に分割されます。いくつかのソリューション制約は第4節は、将来の仕事のために結論や提案を提供して3章で概説されています。付録Aは、問題の部分に既存のソリューションについて説明します。
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]に記載されているように解釈されます。
Authentication, Authorization, and Accounting (AAA)
認証、許可、アカウンティング（AAA）
AAA protocols with EAP support include Remote Authentication Dial-In User Service (RADIUS) [RFC3579] and Diameter [RFC4072].
EAPサポートを持つAAAプロトコルは、リモート認証ダイヤルインユーザーサービス（RADIUS）[RFC3579]とDiameter [RFC4072]を含みます。
Access Point (AP)
アクセスポイント（AP）
An entity that has station functionality and provides access to distribution services via the wireless medium (WM) for associated stations.
ステーションの機能を有し、関連する局のための無線媒体（WM）を介して配信サービスへのアクセスを提供するエンティティ。
Access Technology Selection
アクセス技術の選択
This refers to the selection between access technologies, e.g., 802.11, Universal Mobile Telecommunications System (UMTS), WiMAX. The selection will be dependent upon the access technologies supported by the device and the availability of networks supporting those technologies.
これは、アクセス技術、例えば、802.11、ユニバーサル・モバイル・テレコミュニケーション・システム（UMTS）、WiMAXの間の選択を指します。選択は、デバイスおよびそれらの技術をサポートするネットワークの可用性によってサポートされるアクセス技術に依存するであろう。
Bearer Selection
ベアラ選択
For some access technologies (e.g., UMTS), there can be a possibility for delivery of a service (e.g., voice) by using either a circuit-switched or packet-switched bearer. Bearer selection refers to selecting one of the bearer types for service delivery. The decision can be based on support of the bearer type by the device and the network as well as user subscription and operator preferences.
いくつかのアクセス技術（例えば、UMTS）のために、回線交換またはパケット交換ベアラのいずれかを使用してサービス（例えば、音声）を送達するための可能性が存在することができます。ベアラ選択は、サービス提供のためのベアラタイプのいずれかを選択することを意味します。決定は、デバイスとネットワークによるベアラタイプのサポート、ならびにユーザー・サブスクリプションおよびオペレータの嗜好に基づくことができます。
Basic Service Set (BSS)
基本サービスセット（BSS）
A set of stations controlled by a single coordination function.
単一調整機能によって制御局のセット。
Decorated NAI
Dekoreted犬
A NAI specifying a source route. See Section 2.7 of RFC 4282 [RFC4282] for more information.
NAIは、ソースルートを指定します。詳細については、RFC 4282 [RFC4282]のセクション2.7を参照してください。
Extended Service Set (ESS)
拡張サービスセット（ESS）
A set of one or more interconnected basic service sets (BSSs) with the same Service Set Identifier (SSID) and integrated local area networks (LANs), which appears as a single BSS to the logical link control layer at any station associated with one of those BSSs. This refers to a mechanism that a node uses to discover the networks that are reachable from a given access network.
のうちの1つに関連する任意のステーションの論理リンク制御層に単一のBSSとして現れる同じサービスセット識別子（SSID）と統合されたローカルエリアネットワーク（LAN）を有する1つまたは複数の相互接続された基本サービスセット（BSSの）のセットこれらのBSS。これは、ノードが所与のアクセスネットワークから到達可能なネットワークを発見するために使用する機構を指します。
Network Access Identifier (NAI)
ネットワークアクセス識別子（NAI）
The Network Access Identifier (NAI) [RFC4282] is the user identity submitted by the client during network 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. Please note that the NAI may not necessarily be the same as the user's e-mail address or the user identity submitted in an application layer authentication.
ネットワークアクセス識別子（NAI）[RFC4282]はネットワークアクセス認証の際に、クライアントによって送信されたユーザーIDです。ローミングでは、NAIの目的は、ユーザを識別するために、ならびに認証要求のルーティングを補助することです。 NAIは、必ずしもユーザーの電子メールアドレスまたはアプリケーション層認証に提出し、ユーザーIDと同じではないかもしれないことに注意してください。
Network Access Server (NAS)
ネットワークアクセスサーバー（NAS）
The device that peers connect to in order to obtain access to the network. In Point-to-Point Tunneling Protocol (PPTP) terminology, this is referred to as the PPTP Access Concentrator (PAC), and in Layer 2 Tunneling Protocol (L2TP) terminology, it is referred to as the L2TP Access Concentrator (LAC). In IEEE 802.11, it is referred to as an Access Point (AP).
ネットワークへのアクセスを得るためにに接続ピアデバイス。ポイントツーポイントトンネリングプロトコル（PPTP）の用語では、これは、PPTPアクセスコンセントレータ（PAC）と呼ばれ、レイヤ2トンネリングプロトコル（L2TP）用語で、これは、L2TPアクセスコンセントレータ（LAC）と呼ばれています。 IEEE 802.11では、アクセスポイント（AP）と呼ばれます。
Network Discovery
ネットワーク探索
The mechanism used to discover available networks. The discovery mechanism may be passive or active, and depends on the access technology. In passive network discovery, the node listens for network announcements; in active network discovery, the node solicits network announcements. It is possible for an access technology to utilize both passive and active network discovery mechanisms.
メカニズムは、利用可能なネットワークを発見するために使用されます。検出メカニズムは、受動的または能動的であること、およびアクセス技術に依存します。パッシブネットワークディスカバリでは、ノードは、ネットワークアナウンスをリッスン。アクティブなネットワークの発見で、ノードがネットワークアナウンスを要求します。アクセス技術は、パッシブとアクティブの両方のネットワーク検出機構を利用することが可能です。
Network Selection
ネットワーク選択
Selection of an operator/ISP for network access. Network selection occurs prior to network access authentication.
ネットワークアクセスのためのオペレータ/ ISPの選択。ネットワークの選択は、アクセス認証をネットワーク化する前に発生します。
Realm
分野
The realm portion of an NAI [RFC4282].
NAI [RFC4282]のレルム部分。
Realm Selection
レルムの選択
The selection of the realm (and corresponding NAI) used to access the network. A realm can be reachable from more than one access network type, and selection of a realm may not enable network capabilities.
レルム（および対応するNAI）の選択は、ネットワークにアクセスするために使用されます。レルムは、複数のアクセス・ネットワーク・タイプから到達することができ、領域の選択は、ネットワーク機能を有効にしなくてもよいです。
Roaming Capability
ローミング機能
Roaming capability can be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support.
一つだけとの正式な顧客ベンダー関係を維持しながら、ローミング機能が緩く、複数のインターネットサービスプロバイダ（ISP）のいずれかを使用する能力として定義することができます。ローミング機能が必要になる場合があります例例としては、ISP「コンフェデレーションズ」とISPが提供する企業ネットワークへのアクセスのサポートが含まれています。
Station (STA)
詩人スタティウス（STA）
A device that contains an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM).
無線媒体（WM）にIEEE 802.11準拠の媒体アクセス制御（MAC）及び物理層（PHY）インターフェースを含むデバイス。
The network discovery and selection problem can be broken down into multiple sub-problems. These include:
ネットワーク発見と選択の問題は、複数のサブ問題に分解することができます。これらは、次のとおりです。
o Discovery of points of attachment. This involves the discovery of points of attachment in the vicinity, as well as their capabilities.
Oの結合点の発見。これは、近傍での結合点の発見、並びにそれらの能力を必要とします。
o Identifier selection. This involves selection of the NAI (and credentials) used to authenticate to the selected point of attachment.
O識別子の選択。これは、アタッチメントの選択したポイントに認証するために使用されるNAI（および資格証明）の選択を含みます。
o AAA routing. This involves routing of the AAA conversation back to the home AAA server, based on the realm of the selected NAI.
O AAAルーティング。これは、選択されたNAIの領域に基づいて、バックホームAAAサーバにAAAの会話のルーティングを必要とします。
o Payload routing. This involves the routing of data packets, in the situation where mechanisms more advanced than destination-based routing are required. While this problem is interesting, it is not discussed further in this document.
Oペイロードルーティング。これは、宛先ベースのルーティングより高度な機構が必要とされる状況では、データ・パケットのルーティングを伴います。この問題は興味深いですが、それは本書で詳しく説明されていません。
o Network capability discovery. This involves discovering the capabilities of an access network, such as whether certain services are reachable through the access network and the charging policy.
Oネットワーク機能の発見。これは、このような特定のサービスは、アクセスネットワークと課金政策を通じて到達可能であるかどうかなど、アクセスネットワークの能力を発見含まれます。
Alternatively, the problem can be divided into discovery, decision, and selection components. The AAA routing problem, for instance, involves all components: discovery (which mediating networks are available), decision (choosing the "best" one), and selection (selecting which mediating network to use) components.
また、問題が発見、決定、および選択コンポーネントに分けることができます。発見（仲介ネットワークが利用可能である）、決定（1の「最高」を選択）、および選択（使用するネットワークを仲介する選択）コンポーネント：AAAルーティングの問題は、例えば、すべてのコンポーネントが含まれます。
Traditionally, the discovery of points of attachment has been handled by out-of-band mechanisms or link or network layer advertisements.
伝統的に、結合点の発見は、アウトオブバンド機構またはリンクまたはネットワーク層広告によって処理されています。
RFC 2194 [RFC2194] describes the pre-provisioning of dial-up roaming clients, which typically included a list of potential phone numbers updated by the provider(s) with which the client had a contractual relationship. RFC 3017 [RFC3017] describes the IETF Proposed Standard for the Roaming Access eXtensible Markup Language (XML) Document Type Definition (DTD). This covers not only the attributes of the Points of Presence (PoP) and Internet Service Providers (ISPs), but also hints on the appropriate NAI to be used with a particular PoP. The XML DTD supports dial-in and X.25 access, but has extensible address and media type fields.
RFC 2194 [RFC2194]は、通常、クライアントが契約関係を持っていたとプロバイダ（複数可）によって更新可能性のある電話番号のリストを含むダイヤルアップローミングクライアントの事前準備について説明します。 RFC 3017 [RFC3017]はIETFは、ローミングアクセス拡張マークアップ言語（XML）文書型定義（DTD）のための標準を提案について説明します。これは、プレゼンス（POP）およびインターネットサービスプロバイダ（ISP）のポイントの属性だけでなくをカバーするだけでなく、特定のPoPで使用するために適切なNAIのヒント。 XML DTDは、ダイヤルインおよびX.25のアクセスをサポートしていますが、拡張可能なアドレスとメディアタイプのフィールドがあります。
As access networks and the points of attachment have proliferated, out-of-band pre-configuration has become increasingly difficult. For networks with many points of attachment, keeping a complete and up-to-date list of points of attachment can be difficult. As a result, wireless network access clients typically only attempt to pre-configure information relating to access networks, rather than individual points of attachment.
アクセスネットワークとの結合点は増殖してきたように、アウトオブバンド事前設定は、ますます困難になってきています。添付ファイルの多くのポイントがあるネットワークでは、付着点の完全かつ最新のリストを維持することが困難な場合があります。結果として、ワイヤレス・ネットワーク・アクセス・クライアントは、典型的にだけではなく添付の個々の点より、アクセスネットワークに関連する事前構成情報を試みます。
In IEEE 802.11 Wireless Local Area Networks (WLAN), the Beacon and Probe Request/Response mechanism provides a way for Stations to discover Access Points (AP) and the capabilities of those APs. The IEEE 802.11 specification [IEEE.802.11-2003] provides support for both passive (Beacon) and active (Probe Request/Response) discovery mechanisms; [Fixingapsel] studied the effectiveness of these mechanisms.
IEEE 802.11ワイヤレスローカルエリアネットワーク（WLAN）、ビーコンおよびプローブではリクエスト/レスポンスメカニズムは、ステーションは、アクセスポイント（AP）とそれらのAPの能力を発見するための方法を提供します。 IEEE 802.11仕様[IEEE.802.11-2003]パッシブ（ビーコン）とアクティブ（プローブリクエスト/レスポンス）検出メカニズムの両方のサポートを提供します。 【Fixingapsel】これらのメカニズムの有効性を検討しました。
Among the Information Elements (IE) included within the Beacon and Probe Response is the Service Set Identifier (SSID), a non-unique identifier of the network to which an AP is attached. The Beacon/ Probe facility therefore enables network discovery, as well as the discovery of points of attachment and the capabilities of those points of attachment.
情報要素（IE）は、ビーコン及びプローブ応答内に含まれる中でも、サービスセット識別子（SSID）、APが接続されているネットワークの非一意な識別子です。ビーコン/プローブの機能は、従って、ネットワーク発見、ならびにアタッチメントとアタッチメントのそれらのポイントの能力の点の発見を可能にします。
The Global System for Mobile Communications (GSM) specifications also provide for discovery of points of attachment, as does the Candidate Access Router Discovery (CARD) [RFC4066] protocol developed by the IETF SEAMOBY Working Group (WG).
移動体通信用グローバルシステム（GSM）規格はまた、結合点の発見を提供するIETF SEAMOBYワーキンググループ（WG）によって開発された候補アクセスルータ発見（CARD）[RFC4066]プロトコルと同様に。
Along with discovery of points of attachment, the capabilities of access networks are also typically discovered. These may include: o Access network name (e.g., IEEE 802.11 SSID)
結合点の発見に伴い、アクセス網の機能はまた、一般的に発見されています。これらとしては：Oアクセスネットワーク名（例えば、IEEE 802.11 SSID）
o Lower layer security mechanism (e.g., IEEE 802.11 Wired Equivalent Privacy (WEP) vs. Wi-Fi Protected Access 2 (WPA2))
O下層セキュリティメカニズム（例えば、IEEE 802.11は有線等価プライバシー（WEP）のWi-Fi保護アクセス対2（WPA2））
o Quality of service capabilities (e.g., IEEE 802.11e support)
サービス機能のO品質（例えば、IEEE 802.11eのサポート）
o Bearer capabilities (e.g., circuit-switched, packet-switched, or both)
Oベアラ機能（例えば、回路交換、パケット交換、または両方）
Even though pre-configuration of access networks scales better than pre-configuration of points of attachment, where many access networks can be used to authenticate to a home realm, providing complete and up-to-date information on each access network can be challenging.
アクセスネットワークの事前設定は、多くのアクセスネットワークが挑戦することができ、各アクセスネットワークに関する完全かつ最新の情報を提供し、家庭レルムへの認証に使用することができます添付ファイルのポイントの事前設定よりも優れスケールにもかかわらず。
In such a situation, network access client configuration can be minimized by providing information relating to each home realm, rather than each access network. One way to enable this is for an access network to support "virtual Access Points" (virtual APs), and for each point of attachment to support virtual APs corresponding to each reachable home realm.
このような状況では、ネットワークアクセスクライアントの構成では、各家庭レルムではなく、各アクセスネットワークに関連する情報を提供することにより、最小限に抑えることができます。これを可能にする1つの方法は、「仮想アクセスポイント」（仮想のAP）をサポートするために、アクセスネットワークのためのものであり、添付の各点について、各到達可能なホーム領域に対応する仮想APをサポートすること。
While a single IEEE 802.11 network may only utilize a single SSID, it may cover a wide geographical area, and as a result, may be segmented, utilizing multiple prefixes. It is possible that a single SSID may be advertised on multiple channels, and may support multiple access mechanisms (including Universal Access Method (UAM) and IEEE 802.1X [IEEE.8021X-2004]) which may differ between points of attachment. A single SSID may also support dynamic VLAN access as described in [RFC3580], or may support authentication to multiple home AAA servers supporting different realms. As a result, users of a single point of attachment, connecting to the same SSID, may not have the same set of services available.
単一のIEEE 802.11ネットワークは、単一のSSIDを利用することができるが、それは広い地理的領域をカバーすることができる、その結果、複数のプレフィックスを利用して、セグメント化されてもよいです。単一のSSIDは、複数のチャンネルで宣伝することができ、結合点間で異なることができる（ユニバーサル・アクセス・メソッド（UAM）とIEEE 802.1X [IEEE.8021X-2004]を含む）複数のアクセスメカニズムをサポートすることが可能です。単一のSSIDは、[RFC3580]に記載されているように、動的VLANへのアクセスをサポートすることができる、または異なるレルムを支持する複数のホームAAAサーバに認証をサポートすることができます。結果として、単一の結合点のユーザは、同一のSSIDに接続し、利用可能なサービスの同一のセットを有していなくてもよいです。
As networks proliferate, it becomes more and more likely that a user may have multiple identities and credential sets, available for use in different situations. For example, the user may have an account with one or more Public WLAN providers, a corporate WLAN, and one or more wireless Wide Area Network (WAN) providers.
ネットワークが増殖すると、ユーザが異なる状況で使用するために利用可能な複数のIDと資格証明セットを、持っていることが、ますますやすくなります。例えば、ユーザは、1つのまたは複数の公衆無線LANプロバイダ、企業のWLAN、および1つまたは複数のワイヤレスワイドエリアネットワーク（WAN）プロバイダとのアカウントを持っていることがあります。
Typically, the user will choose an identity and corresponding credential set based on the selected network, perhaps with additional assistance provided by the chosen authentication mechanism. For example, if Extensible Authentication Protocol - Transport Layer Security (EAP-TLS) is the authentication mechanism used with a particular network, then the user will select the appropriate EAP-TLS client certificate based, in part, on the list of trust anchors provided by the EAP-TLS server.
典型的には、ユーザは、おそらく選択された認証メカニズムによって提供される追加の助けを借りて、同一性及び選択されたネットワークに基づいて、対応するクレデンシャルセットを選択します。拡張認証プロトコルたとえば、 - トランスポート層セキュリティ（EAP-TLS）は、特定のネットワークで使用される認証メカニズムは、ユーザが提供するトラストアンカーのリストには、部分的に基づいて、適切なEAP-TLSクライアント証明書を選択しますEAP-TLSサーバーによって。
However, in access networks where roaming is enabled, the mapping between an access network and an identity/credential set may not be one to one. For example, it is possible for multiple identities to be usable on an access network, or for a given identity to be usable on a single access network, which may or may not be available.
しかしながら、ローミングが有効になっているアクセスネットワークにおいて、アクセスネットワークと識別/認証情報セット間のマッピングは、一から一でなくてもよいです。例えば、所与のアイデンティティがまたは利用可能であってもなくてもよい単一のアクセスネットワーク上で使用できるように、アクセスネットワーク上で、またはのために複数のIDが使用可能であることが可能です。
Figure 1 illustrates a situation where a user identity may not be usable on a potential access network. In this case, access network 1 enables access to users within the realm "isp1.example.com", whereas access network 3 enables access to users within the realm "corp2.example.com"; access network 2 enables access to users within both realms.
図1は、ユーザIDが潜在的なアクセスネットワーク上で利用可能ではないかもしれない状況を示しています。この場合には、アクセスネットワーク1は、アクセスネットワーク3はレルム「corp2.example.com」内のユーザへのアクセスを可能にする一方、レルム「isp1.example.com」内のユーザへのアクセスを可能にします。アクセスネットワーク2は、両方のレルム内のユーザーへのアクセスを可能にします。
? ? +---------+ +------------------+
? | Access | | |
O_/ _-->| Network |------>|"isp1.example.com"|
/| / | 1 | _->| |
| | +---------+ / +------------------+
_/ \_ | /
| +---------+ /
User "subscriber@isp1. | | Access |/
example.com" -- ? -->| Network |
also known as | | 2 |\
"employee123@corp2. | +---------+ \
example.com" | \
| +---------+ \_ +-------------------+
\_ | Access | ->| |
-->| Network |------>|"corp2.example.com"|
| 3 | | |
+---------+ +-------------------+
Figure 1: Two credentials, three possible access networks
図1：二つの資格情報、三つの可能なアクセスネットワーク
In this situation, a user only possessing an identity within the "corp2.example.com" realm can only successfully authenticate to access networks 2 or 3; a user possessing an identity within the "isp1.example.com" realm can only successfully authenticate to access networks 1 or 2; a user possessing identities within both realms can connect to any of the access networks. The question is: how does the user figure out which access networks it can successfully authenticate to, preferably prior to choosing a point of attachment?
このような状況では、唯一の「corp2.example.com」領域内のアイデンティティを持つユーザーのみが成功したネットワーク2または3にアクセスすることを認証することができます。 「isp1.example.com」領域内のアイデンティティを持つユーザーのみが成功したネットワーク1または2にアクセスすることを認証することができます。両方のレルム内のアイデンティティを持つユーザーは、アクセスネットワークのいずれかに接続することができます。質問は：どのようにネットワークにアクセスするからユーザーの図は、それが成功した結合点を選択する前に好ましく、に認証できるのでしょうか？
Traditionally, hints useful in identity selection have been provided out-of-band. For example, the XML DTD, described in [RFC3017], enables a client to select between potential points of attachment as well as to select the NAI and credentials to use in authenticating with it.
伝統的に、アウトオブバンド提供されているアイデンティティの選択に有用ヒント。例えば、[RFC3017]に記述されたXML DTDは、アタッチメントの電位点との間で選択するだけでなく、それを認証する際に使用するためにNAIと資格情報を選択するためにクライアントを可能にします。
Where all points of attachment within an access network enable authentication utilizing a set of realms, selection of an access network provides knowledge of the identities that a client can use to successfully authenticate. For example, in an access network, the set of supported realms corresponding to network name can be pre-configured.
アクセスネットワーク内の添付ファイルのすべての点は、レルムのセットを利用した認証を有効にする場合は、アクセスネットワークの選択は、クライアントが正常に認証するために使用できるアイデンティティの知識を提供しています。例えば、アクセスネットワークでは、ネットワーク名に対応するサポートされているレルムのセットが事前に構成することができます。
In some cases, it may not be possible to determine the available access networks prior to authentication. For example, [IEEE.8021X-2004] does not support network discovery on IEEE 802 wired networks, so that the peer cannot determine which access network it has connected to prior to the initiation of the EAP exchange.
いくつかのケースでは、前の認証に利用可能なアクセスネットワークを決定することが可能ではないかもしれません。ピアは、それがEAP交換を開始する前に接続されたアクセスネットワークを決定することができないように、例えば、[IEEE.8021X-2004]、IEEE 802有線ネットワーク上のネットワークディスカバリをサポートしていません。
It is also possible for hints to be embedded within credentials. In [RFC4334], usage hints are provided within certificates used for wireless authentication. This involves extending the client's certificate to include the SSIDs with which the certificate can be used.
ヒントは資格証明書内に埋め込まれることも可能です。 [RFC4334]で、使用ヒントは、無線認証に使用する証明書の中に設けられています。これは、証明書を使用することが可能なSSIDを含めるように、クライアントの証明書を拡張が含まれます。
However, there may be situations in which an access network may not accept a static set of realms at every point of attachment. For example, as part of a roaming agreement, only points of attachment within a given region or country may be made available. In these situations, mechanisms such as hints embedded within credentials or pre-configuration of access network to realm mappings may not be sufficient. Instead, it is necessary for the client to discover usable identities dynamically.
しかし、アクセスネットワークは、アタッチメントの全ての点においてレルムの静的なセットを受け入れないかもしれない状況があるかもしれません。例えば、ローミング契約の一部として、指定された地域または国内の付着の点のみを利用可能にすることができます。これらの状況では、そのような領域のマッピングに資格情報またはアクセスネットワークの事前構成内に埋め込まれたヒントのようなメカニズムは十分ではないかもしれません。クライアントが動的に使用可能なアイデンティティを発見するために代わりに、それは必要です。
This is the problem that RFC 4284 [RFC4284] attempts to solve, using the EAP-Request/Identity to communicate a list of supported realms. However, the problems inherent in this approach are many, as discussed in Appendix A.1.
これは、RFC 4284 [RFC4284]はサポートされているレルムのリストを通信するために、EAP-Request / Identityを使用して、解決しようとする問題です。付録A.1で説明したようにしかし、このアプローチに固有の問題は、多くのです。
Note that identity selection also implies selection of different credentials, and potentially, selection of different EAP authentication methods. In some situations this may imply serious security vulnerabilities. These are discussed in depth in Section 5.
そのIDの選択はまた、別の資格情報の選択を意味注意、および潜在的に、異なるEAP認証方法の選択。いくつかの状況では、これは深刻なセキュリティ上の脆弱性を意味し得ます。これらは、第5節で詳しく説明されています。
Once the identity has been selected, the AAA infrastructure needs to route the access request back to the home AAA server. Typically, the routing is based on the Network Access Identifier (NAI) defined in [RFC4282].
アイデンティティが選択されると、AAAインフラストラクチャは、バックホームAAAサーバへのルートへのアクセス要求を必要とします。典型的には、ルーティングはネットワークアクセス識別子（NAI）[RFC4282]で定義さに基づいています。
Where the NAI does not encode a source route, the routing of requests is determined by the AAA infrastructure. As described in [RFC2194], most roaming implementations are relatively simple, relying on a static realm routing table that determines the next hop based on the NAI realm included in the User-Name attribute within the Access-Request. Within RADIUS, the IP address of the home AAA server is typically determined based on static mappings of realms to IP addresses maintained within RADIUS proxies.
NAIは、ソースルートをコードしない場合、要求のルーティングは、AAAインフラストラクチャによって決定されます。 [RFC2194]に記載されているように、ほとんどのローミング実装はNAIのレルムに基づいて、次ホップがアクセス要求内のUser-Name属性に含まれる判断テーブルルーティング静的領域に依存する、比較的単純です。 RADIUS内では、ホームAAAサーバのIPアドレスは通常、RADIUSプロキシ内に維持IPアドレスへのレルムの静的マッピングに基づいて決定されます。
Diameter [RFC3588] supports mechanisms for intra- and inter-domain service discovery, including support for DNS as well as service discovery protocols such as Service Location Protocol version 2 (SLPv2) [RFC2608]. As a result, it may not be necessary to configure static tables mapping realms to the IP addresses of Diameter agents. However, while this simplifies maintenance of the AAA routing infrastructure, it does not necessarily simplify roaming-relationship path selection.
直径[RFC3588]はDNSのためのサポート、ならびにそのようなサービスロケーションプロトコルバージョン2（SLPv2の）[RFC2608]などのサービス発見プロトコルを含む内およびドメイン間サービス発見のためのメカニズムをサポートします。結果として、DiameterエージェントのIPアドレスに静的テーブルマッピングレルムを設定する必要はないかもしれません。これはAAAルーティングインフラストラクチャのメンテナンスを簡素化しながら、しかし、それは必ずしもローミング関係経路選択を簡素化しません。
As noted in RFC 2607 [RFC2607], RADIUS proxies are deployed not only for routing purposes, but also to mask a number of inadequacies in the RADIUS protocol design, such as the lack of standardized retransmission behavior and the need for shared secret provisioning between each AAA client and server.
RFC 2607に[RFC2607]を述べたように、RADIUSプロキシは、ルーティング目的のためだけでなく、展開されているだけでなく、そのような標準化された再送行動の欠如とそれぞれの間の共有秘密の準備の必要性として、RADIUSプロトコルの設計に不備の数をマスクしますAAAクライアントとサーバ。
Diameter [RFC3588] supports certificate-based authentication (using either TLS or IPsec) as well as Redirect functionality, enabling a Diameter client to obtain a referral to the home server from a Diameter redirect server, so that the client can contact the home server directly. In situations in which a trust model can be established, these Diameter capabilities can enable a reduction in the length of the roaming relationship path.
直径[RFC3588]は、クライアントが直接ホームサーバに連絡できるように、直径リダイレクトサーバからホームサーバーへの参照を得るために、直径のクライアントを有効に、証明書ベース（TLSやIPsecのいずれかを使用して）認証ならびにリダイレクト機能をサポート。信頼モデルを確立することができる状況では、これらの直径機能は、ローミング関係経路の長さの減少を可能にすることができます。
However, in practice there are a number of pitfalls. In order for certificate-based authentication to enable communication between a Network Access Server (NAS) or local proxy and the home AAA server, trust anchors need to be configured, and certificates need to be selected. The AAA server certificate needs to chain to a trust anchor configured on the AAA client, and the AAA client certificate needs to chain to a trust anchor configured on the AAA server. Where multiple potential roaming relationship paths are available, this will reflect itself in multiple certificate choices, transforming the path selection problem into a certificate selection problem. Depending on the functionality supported within the certificate selection implementation, this may not make the problem easier to solve. For example, in order to provide the desired control over the roaming path, it may be necessary to implement custom certificate selection logic, which may be difficult to introduce within a certificate handling implementation designed for general-purpose usage.
しかし、実際には落とし穴がいくつかあります。ネットワークアクセスサーバー（NAS）またはローカルプロキシとホームAAAサーバ間の通信を可能にするために証明書ベースの認証のためには、信頼アンカーを設定する必要があり、証明書は、選択する必要があります。 AAAクライアント上に設定されている信頼アンカーにチェーンへAAAサーバ証明書の必要性、およびAAAサーバ上に設定されている信頼アンカーにチェーンへのAAAクライアント証明書が必要。複数の潜在的なローミング関係経路が利用可能である場合、これは、証明書の選択問題に経路選択の問題を変換、複数の証明書の選択自体を反映します。証明書の選択実装内でサポートされる機能に応じて、これは解決する問題を容易にしないことがあります。例えば、ローミング経路上に所望の制御を提供するためには、汎用の使用のために設計された実装を処理する証明書内に導入することは困難であり得る、カスタム証明書の選択ロジックを実装する必要があるかもしれません。
As noted in [RFC4284], it is also possible to utilize an NAI for the purposes of source routing. In this case, the client provides guidance to the AAA infrastructure as to how it would like the access request to be routed. An NAI including source-routing information is said to be "decorated"; the decoration format is defined in [RFC4282].
[RFC4284]で述べたように、ソースルーティングのためにNAIを利用することも可能です。この場合、クライアントはそれをルーティングするためのアクセス要求を希望方法についてのAAAインフラストラクチャへのガイダンスを提供します。 NAIを含むソースルーティング情報を「装飾される」と言われています。装飾形式は[RFC4282]で定義されています。
When decoration is utilized, the EAP peer provides the decorated NAI within the EAP-Response/Identity, and as described in [RFC3579], the NAS copies the decorated NAI included in the EAP-Response/Identity into the User-Name attribute included within the access request. As the access request transits the roaming relationship path, AAA proxies determine the next hop based on the realm included within the User-Name attribute, in the process, successively removing decoration from the NAI included in the User-Name attribute. In contrast, the decorated NAI included within the EAP-Response/Identity encapsulated in the access request remains untouched. As a result, when the access request arrives at the AAA home server, the decorated NAI included in the EAP-Response/Identity may differ from the NAI included in the User-Name attribute (which may have some or all of the decoration removed). For the purpose of identity verification, the EAP server utilizes the NAI in the User-Name attribute, rather than the NAI in the EAP-Response/Identity.
装飾を利用する場合、EAPピアはEAP応答/アイデンティティ内デコレーションされたNAIを提供し、[RFC3579]に記載されているように、NASコピーがデコレーションされたNAIは、User-Name属性は、内に含まにEAP応答/アイデンティティに含まアクセス要求。アクセス要求がローミング関係経路を通過するように、AAAプロキシは、レルムに基づいて、次のホップは、User-Name属性内に含まれる決定プロセスにおいて、NAIから順次除去装飾はUser-Name属性に含まれます。これとは対照的に、装飾されたNAIは、アクセス要求にカプセル化されたEAP応答/アイデンティティが手つかずのままに含まれます。アクセス要求がAAAのホームサーバーに到着したときにその結果、装飾されたNAIは、EAP応答/アイデンティティに含まNAIと異なる場合があります（削除装飾の一部または全部を有していてもよい）User-Name属性に含ま。身元確認のために、EAPサーバではなく、EAP応答/アイデンティティにおけるNAIよりも、User-Name属性にNAIを利用しています。
Over the long term, it is expected that the need for NAI "decoration" and source routing will disappear. This is somewhat analogous to the evolution of email delivery. Prior to the widespread proliferation of the Internet, it was necessary to gateway between SMTP-based mail systems and alternative delivery technologies, such as Unix-to-Unix CoPy Protocol (UUCP) and FidoNet. Prior to the implementation of email gateways utilizing MX RR routing, email address-based source-routing was used extensively. However, over time the need for email source-routing disappeared.
長期的には、NAI「装飾」とソースルーティングの必要性が消滅することが期待されます。これは、電子メールの配信の進化にやや似ています。インターネットの広範な普及に先立って、SMTPベースのメールシステムとそのようなUNIXからのUnixコピープロトコル（UUCP）とFidoNetのような別の送達技術、の間のゲートウェイする必要がありました。 MX RRルーティングを利用する電子メールゲートウェイの実装に先立って、電子メールアドレスベースのソース・ルーティングが広範囲に使用されました。しかし、時間をかけて電子メール・ソース・ルーティングの必要性が消えました。
AAA clients on the edge of the network, such as NAS devices and local AAA proxies, typically maintain a default realm route, providing a default next hop for realms not otherwise taken into account within the realm routing table. This permits devices with limited resources to maintain a small realm routing table. Deeper within the AAA infrastructure, AAA proxies may be maintained with a "default free" realm table, listing next hops for all known realms, but not providing a default realm route.
そのようなNASデバイスとローカルAAAプロキシとして、ネットワークのエッジ上のAAAクライアントは、典型的にはそうでない領域のルーティングテーブル内に考慮されていないレルムのデフォルトのネクストホップを提供し、デフォルトのレルムのルートを維持します。これは、小さなレルムルーティングテーブルを維持するために、限られたリソースでデバイスを許可します。 AAAインフラストラクチャ内のより深い、AAAプロキシは、すべての既知のレルムのためのネクストホップをリストが、デフォルトのレルムのルートを提供していない、「デフォルトの自由」レルムテーブルを維持することができます。
While dynamic realm routing protocols are not in use within AAA infrastructure today, even if such protocols were to be introduced, it is likely that they would be deployed solely within the core AAA infrastructure, but not on NAS devices, which are typically resource constrained.
ダイナミックレルム・ルーティング・プロトコルは、AAAインフラストラクチャ内で使用されていないものの、今日は、そのようなプロトコルを導入するたとしても、彼らがではなく、一般的に制約資源であるNASデバイス上で、単にコアAAAインフラストラクチャ内に展開されるだろうと思われます。
Since NAS devices do not maintain a full realm routing table, they do not have knowledge of all the realms reachable from the local network. The situation is analogous to that of Internet hosts or edge routers that do not participate in the BGP mesh. In order for an Internet host to determine whether it can reach a destination on the Internet, it is necessary to send a packet to the destination.
NASデバイスは、完全なレルムルーティングテーブルを維持していないので、彼らは、ローカルネットワークから到達可能なすべてのレルムの知識を持っていません。状況はBGPメッシュに参加していないインターネットホストまたはエッジルータのそれに似ています。それは、インターネット上で目的地に到達できるかどうかを判断するには、インターネットホストのためには、宛先にパケットを送信する必要があります。
Similarly, when a user provides an NAI to the NAS, the NAS does not know a priori whether or not the realm encoded in the NAI is reachable; it simply forwards the access request to the next hop on the roaming relationship path. Eventually, the access request reaches the "default free" zone, where a core AAA proxy determines whether or not the realm is reachable. As described in [RFC4284], where EAP authentication is in use, the core AAA proxy can send an Access-Reject, or it can send an Access-Challenge encapsulating an EAP-Request/Identity containing "realm hints" based on the content of the "default free" realm routing table.
ユーザがNASにNAIを提供する場合も同様に、NASは、NAIでエンコード領域が到達可能であるか否かを事前に知りません。それは単にローミング関係パス上の次のホップへのアクセス要求を転送します。最終的には、アクセス要求は、コアAAAプロキシはレルムが到達可能であるか否かを判断する「デフォルトフリー」ゾーンに達します。 [RFC4284]に記載されているように、EAP認証が使用中である場合、コアAAAプロキシは拒否アクセスを送信することができ、またはそれはの内容に基づいて、「レルムヒント」を含むEAP要求/アイデンティティを封入アクセスチャレンジを送信することができ「デフォルトの自由」レルムルーティングテーブル。
There are a number of intrinsic problems with this approach. Where the "default free" routing table is large, it may not fit within a single EAP packet, and the core AAA proxy may not have a mechanism for selecting the most promising entries to include. Even where the "default free" realm routing table would fit within a single EAP-Request/Identity packet, the core AAA router may not choose to include all entries, since the list of realm routes could be considered confidential information not appropriate for disclosure to hosts seeking network access. Therefore, it cannot be assumed that the list of "realm hints" included within the EAP-Request/Identity is complete. Given this, a NAS or local AAA proxy snooping the EAP-Request/Identity cannot rely on it to provide a complete list of reachable realms. The "realm hint" mechanism described in [RFC4284] is not a dynamic routing protocol.
このアプローチに固有の問題がいくつかあります。 「デフォルトの自由」、ルーティングテーブルが大きい場合、それは、単一のEAPパケット内に収まらない場合があり、コアAAAプロキシが含まれるように、最も有望なエントリを選択するためのメカニズムを持っていないかもしれません。ルーティングテーブル「自由デフォルト」レルムが、単一のEAP要求/アイデンティティパケット内に収まるようにしてもどこレルムルートのリストがへの開示のために機密情報が適切でないと考えられることから、コアAAAルータは、すべてのエントリを含めることを選択しない場合がありますネットワークへのアクセスを求めているホスト。したがって、EAP要求/アイデンティティの中に含まれる「レルムヒント」のリストが完全であることを仮定することはできません。この与えられた、EAP要求/アイデンティティをスヌーピングNASまたはローカルAAAプロキシは、到達可能な、レルムの完全なリストを提供するために、それに頼ることはできません。 [RFC4284]に記載された「レルムヒント」機構は、動的ルーティングプロトコルではありません。
Along with lack of a dynamic AAA routing protocol, today's AAA infrastructure lacks mechanisms for route selection and policy. As a result, multiple routes may exist to a destination realm, without a mechanism for the selection of a preferred route.
ダイナミックAAAルーティングプロトコルの欠如とともに、今日のAAAインフラストラクチャは、ルート選択と政策のためのメカニズムを欠いています。その結果、複数の経路は、好ましい経路を選択するための機構なしに、宛先領域に存在してもよいです。
In Figure 2, Roaming Groups 1 and 2 both include a route to the realm "a.example.com". However, these realm routes are not disseminated to the NAS along with associated metrics, and, as a result, there is no mechanism for implementation of dynamic routing policies (such as selection of realm routes by shortest path, or preference for routes originating at a given proxy).
図2では、ローミンググループ1及び2の両方は、レルム「a.example.com」への経路を含みます。しかしながら、これらのレルムのルートは、関連する指標と共にNASに配布されていない、そして、結果として、動的ルーティングのような最短経路によってレルムルートの選択などのポリシー（またはAから発信ルートの嗜好の実施のためのメカニズムはありません指定されたプロキシ）。
+---------+
| |----> "a.example.com"
| Roaming |
+---------+ | Group 1 |
| |----->| Proxy |----> "b.example.com"
user "joe@ | Access | +---------+
a.example.com"--->| Provider|
| NAS | +---------+
| |----->| |----> "a.example.com"
+---------+ | Roaming |
| Group 2 |
| Proxy |----> "c.example.com"
+---------+
Figure 2: Multiple routes to a destination realm
図2：先のレルムに複数のルート
In the example in Figure 2, access through Roaming Group 1 may be less expensive than access through Roaming Group 2, and as a result it would be desirable to prefer Roaming Group 1 as a next hop for an NAI with a realm of "a.example.com". However, the only way to obtain this result would be to manually configure the NAS realm routing table with the following entries:
図2の例では、ローミンググループ1を介してアクセスがローミンググループ2を介したアクセスよりも安価であってもよく、結果として、「の領域とNAIのための次のホップとしてローミンググループ1を優先することが望ましいです。 example.com」。しかし、この結果を得るための唯一の方法は、手動で次のエントリを持つテーブルをルーティングNASレルムを設定することであろう。
Realm Next Hop
----- --------
b.example.com Roaming Group 1
c.example.com Roaming Group 2
Default Roaming Group 1
While manual configuration may be practical in situations where the realm routing table is small and entries are static, where the list of supported realms change frequently, or the preferences change dynamically, manual configuration will not be manageable.
サポートされているレルムのリストは頻繁に変更、または嗜好が動的に変化する場合、レルム・ルーティング・テーブルが小さく、エントリが静的である場合、手動設定が状況において実用的かもしれないが、手動設定は管理できません。
Due to the limitations of current AAA routing mechanisms, there are situations in which NAI-based source routing is used to influence the roaming relationship path. However, since the AAA proxies on the roaming relationship path are constrained by existing relationships, NAI-based source routing is not source routing in the classic sense;
電流によるAAAルーティング機構の制限のため、NAIベースのソースルーティングがローミング関係経路に影響を与えるために使用されている状況があります。ローミング関係経路上のAAAプロキシは、既存の関係によって拘束されているので、NAIベースのソースルーティングは、古典的な意味でのソースルーティングではありません。
it merely suggests preferences that the AAA proxy can choose not to accommodate.
それは単にAAAプロキシが対応しないことを選択することができ嗜好を示唆しています。
Where realm routes are set up as the result of pre-configuration and dynamic route establishment is not supported, if a realm route does not exist, then NAI-based source routing cannot establish it. Even where dynamic route establishment is possible, such as where the AAA client and server support certificate-based authentication, and AAA servers are discoverable (such as via the mechanisms described in [RFC3588]), an AAA proxy may choose not to establish a realm route by initiating the discovery process based on a suggestion in an NAI-based source route.
レルムルートが事前設定および動的ルート確立の結果として設定される領域ルートが次にNAIベースのソースルーティングがそれを確立できない、存在しない場合、サポートされていません。動的ルートの確立は、AAAクライアントとサーバのサポート証明書ベースの認証場合など、可能であり、AAAサーバは、（例えば、[RFC3588]で説明されたメカニズムを介して）発見され、AAAプロキシはレルムを確立しないことを選択することができる場合であってもNAIベースのソースルートで提案に基づいてディスカバリプロセスを開始することによって経路。
Where the realm route does exist, or the AAA proxy is capable of establishing it dynamically, the AAA proxy may choose not to authorize the client to use it.
レルムのルートが存在しない、またはAAAプロキシがそれを動的に確立することができる場合は、AAAプロキシはそれを使用するクライアントを許可しないこともできます。
While, in principle, source routing can provide users with better control over AAA routing decisions, there are a number of practical problems to be overcome. In order to enable the client to construct optimal source routes, it is necessary for it to be provided with a complete and up-to-date realm routing table. However, if a solution to this problem were readily available, then it could be applied to the AAA routing infrastructure, enabling the selection of routes without the need for user intervention.
原理的には、ソースルーティングは、AAAルーティングの決定をより良くコントロールをユーザーに提供することができるが、実用上の多くの問題を克服することがあります。それはルーティングテーブル完全かつ最新の領域で提供されるため、最適なソースルートを構築するクライアントを可能にするために、それが必要です。この問題に対する解決策は、容易に利用可能であった場合は、それは、ユーザの介入を必要とせずにルートの選択を可能にする、AAAルーティングインフラストラクチャに適用することができます。
As noted in [Eronen04], only a limited number of parameters can be updated dynamically. For example, quality of service or pricing information typically will be pre-provisioned or made available on the web rather than being updated on a continuous basis. Where realm names are communicated dynamically, the "default free" realm list is unlikely to be provided in full since this table could be quite large. Given the constraints on the availability of information, the construction of source routes typically needs to occur in the face of incomplete knowledge.
【Eronen04]で述べたように、パラメータの限られた数は、動的に更新することができます。例えば、サービスや価格情報の品質は、一般的に事前プロビジョニングまたは利用できるように、ウェブ上ではなく、継続的に更新されます。レルム名が動的に伝達される場合は、「デフォルトの自由」レルムのリストは、このテーブルは非常に大きくなる可能性があるため、フルで提供されにくいです。情報の可用性の制約を考えると、ソースルートの構造は、典型的には、不完全な知識の面で発生する必要があります。
In addition, there are few mechanisms available to audit whether the requested source route is honored by the AAA infrastructure. For example, an access network could advertise a realm route to "costsless.example.com", while instead routing the access-request through "costsmore.example.com". While the decorated NAI would be made available to the home AAA server in the EAP-Response/Identity, the home AAA server might have a difficult time verifying that the source route requested in the decorated NAI was actually honored by the AAA infrastructure. Similarly, it could be difficult to determine whether quality of service (QoS) or other routing requests were actually provided as requested. To some extent, this problem may be addressed as part of the business arrangements between roaming partners, which may provide minimum service-level guarantees.
また、要求されたソース経路がAAAインフラストラクチャによって表彰されたか否かを監査するために利用可能ないくつかの機構があります。代わりに「costsmore.example.com」を介してアクセス要求をルーティングしながら、例えば、アクセスネットワークは、「costsless.example.com」にレルムのルートをアドバタイズすることができました。装飾されたNAIは、EAP応答/アイデンティティでホームAAAサーバが利用できるようになりますが、ホームAAAサーバは、困難な時期に装飾NAIに要求されたソースルートが実際にAAAインフラストラクチャで受賞したことを確認することがあるかもしれません。同様に、要求されたサービス品質（QoS）、または他のルーティング要求が実際に提供されたかどうかを決定することは困難かもしれません。ある程度まで、この問題は、最低限のサービスレベルの保証を提供することができるローミングパートナー間のビジネス契約の一部として対処することができます。
Given the potential issues with source routing, conventional AAA routing mechanisms are to be preferred wherever possible. Where an error is encountered, such as an attempt to authenticate to an unreachable realm, "realm hints" can be provided as described [RFC4284]. However, this approach has severe scalability limitations, as outlined in Appendix A.1.
ソースルーティングの潜在的な問題を考えると、従来のAAAルーティングメカニズムは、可能な限り好ましいことがあります。エラーが発生した場合には、到達不可能な領域への認証しようとする試みなど、記述[RFC4284]として提供することができる「レルムはヒント」。付録A.1に概説されているようしかし、このアプローチは、深刻なスケーラビリティの制限があります。
Network capability discovery focuses on discovery of the services offered by networks, not just the capabilities of individual points of attachment. By acquiring additional information on access network characteristics, it is possible for users to make a more informed access decision. These characteristics may include:
ネットワーク機能の発見はネットワーク、添付ファイルの個々の点だけではなく機能によって提供されるサービスの発見に焦点を当てています。アクセスネットワークの特性に関する追加情報を取得することで、ユーザーはより多くの情報にアクセス決定を行うことが可能です。これらの特性は含まれます。
o Roaming relationships between the access network provider and other network providers and associated costs. Where the network access client is not pre-configured with an identity and credentials corresponding to a local access network, it will need to be able to determine whether one or more home realms are reachable from an access network so that successful authentication can be possible.
Oアクセスネットワークプロバイダや他のネットワークプロバイダと関連コストの関係をローミング。ネットワークアクセスクライアントは、ローカル・アクセス・ネットワークに対応する識別情報と資格情報を使用して事前に設定されていない場合は、それが成功した認証が可能になるように1つの以上のホームレルムがアクセスネットワークから到達可能であるかどうかを判断できるようにする必要があります。
o EAP authentication methods. While the EAP authentication methods supported by a home realm can only be determined by contacting the home AAA server, it is possible that the local realm will also support one or more EAP methods. For example, a user may be able to utilize EAP-SIM (Extensible Authentication Protocol - Subscriber Identity Module) to authenticate to the access network directly, rather than having to authenticate to the home network.
O EAP認証方法。ホームレルムでサポートされているEAP認証方式のみホームAAAサーバに連絡することによって決定することができるが、地元の領域は、1つのまたは複数のEAP方式をサポートすることも可能です。むしろ、ホームネットワークに認証することよりも、直接アクセスネットワークに認証するために - 例えば、ユーザは、EAP-SIM（加入者識別モジュール拡張認証プロトコル）を利用することができるかもしれません。
o End-to-end quality of service capability. While local quality of service capabilities are typically advertised by the access network (e.g., support for Wi-Fi Multimedia (WMM)), the availability of end-to-end QoS services may not be advertised.
サービス機能のOエンドツーエンドの品質。サービス機能の局所的な品質は、通常、アクセスネットワーク（のWi-Fiマルチメディア（WMM）のために、例えば、サポート）によってアドバタイズされていますが、エンド・ツー・エンドのQoSサービスの可用性を宣伝することはできません。
o Service parameters, such as the existence of middleboxes or firewalls. If the network access client is not made aware of the Internet access that it will receive on connecting to a point of attachment, it is possible that the user may not be able to access the desired services.
そのようなミドルボックスやファイアウォールの存在としてOサービスパラメータ。ネットワーク・アクセス・クライアントは、それが結合点に接続する上で受信しますインターネットアクセスを知らされていない場合、ユーザが所望のサービスにアクセスすることができない可能性があります。
Reference [IEEE.11-04-0624] classifies the possible steps at which IEEE 802.11 networks can acquire this information: o Pre-association
プレ関連○：参考文献[IEEE.11-04-0624] IEEE 802.11ネットワークは、この情報を取得することができるれる可能なステップを分類します
o Post-association (or pre-authentication)
Oポスト協会（または事前認証）
o Post-authentication
O認証後
In the interest of minimizing connectivity delays, all of the information required for network selection (including both access network capabilities and global characteristics) needs to be provided prior to authentication.
接続遅延を最小化する利益のために、（アクセス・ネットワーク機能とグローバル特性の両方を含む）は、ネットワーク選択のために必要な情報の全ては、従来の認証を提供する必要があります。
By the time authentication occurs, the node has typically selected the access network, the NAI to be used to authenticate, as well as the point of attachment. Should it learn information during the authentication process that would cause it to revise one or more of those decisions, the node will need to select a new network, point of attachment, and/or identity, and then go through the authentication process all over again. Such a process is likely to be both time consuming and unreliable.
認証が発生する時間によって、ノードは、典型的には、アクセス・ネットワーク、認証、ならびに結合点ために使用されるNAIを選択しました。それはこれらの決定の一つ以上を修正する原因となる認証プロセス中に情報を学ぶ必要があり、ノードは新しいネットワーク、結合点、および/またはIDを選択する必要があり、その後、もう一度、認証プロセスを通過します。そのようなプロセスは時間がかかり、信頼できないの両方である可能性が高いです。
The following factors should be taken into consideration while evaluating solutions to the problem of network selection and discovery.
ネットワーク選択と発見の問題に対する解決策を評価しながら、以下の要因を考慮する必要があります。
Solutions to the AAA routing issues discussed in Section 2.3 need to apply to a wide range of AAA messages, and should not restrict the introduction of new AAA or access network functionality. For example, AAA routing mechanisms should work for access requests and responses as well as accounting requests and responses and server-initiated messages. Solutions should not restrict the development of new AAA attributes, access types, or performance optimizations (such as fast handoff support).
2.3節で述べたAAAのルーティングの問題への解決策は、AAAメッセージの広い範囲に適用する必要があり、新しいAAAまたはアクセスネットワーク機能の導入を制限するべきではありません。例えば、AAAのルーティングメカニズムは、アクセス要求と応答だけでなく、会計上の要求と応答と、サーバ起動メッセージのために働く必要があります。ソリューションは、新しいAAA属性、アクセス・タイプ、または（例えば高速ハンドオフのサポートなど）のパフォーマンスの最適化の開発を制限するべきではありません。
Solutions need to maintain backward compatibility. In particular:
ソリューションは、下位互換性を維持する必要があります。特に：
o Selection-aware clients need to interoperate with legacy NAS devices and AAA servers.
O選択対応クライアントは、レガシーNASデバイスとAAAサーバと相互運用する必要があります。
o Selection-aware AAA infrastructure needs to interoperate with legacy clients and NAS devices.
Oの選択を意識したAAAインフラストラクチャは、レガシークライアントとNASデバイスと相互運用する必要があります。
For example, selection-aware clients should not transmit packets larger than legacy NAS devices or AAA servers can handle. Where protocol extensions are required, changes should be required to as few infrastructure elements as possible. For example, extensions that require upgrades to existing NAS devices will be more difficult to deploy than proposals that are incrementally deployable based on phased upgrades of clients or AAA servers.
例えば、選択対応クライアントは、NASデバイスまたはAAAサーバが処理することができ、従来よりも大きなパケットを送信するべきではありません。プロトコルの拡張が必要な場合は、変更が可能な限り少ないインフラストラクチャ要素に必要とされるべきです。例えば、既存のNASデバイスへのアップグレードが必要な機能拡張は、クライアントまたはAAAサーバの段階的なアップグレードに基づいて漸増的に展開しているの提案よりも展開することがより困難になります。
Solutions should be efficient as measured by channel utilization, bandwidth consumption, handoff delay, and energy utilization. Mechanisms that depend on multicast frames need to be designed with care since multicast frames are often sent at the lowest supported rate and therefore consume considerable channel time as well as energy on the part of listening nodes. Depending on the deployment, it is possible for bandwidth to be constrained both on the link, as well as in the backend AAA infrastructure. As a result, chatty mechanisms such as keepalives or periodic probe packets are to be avoided. Given the volume handled by AAA servers, solutions should also be conscious of adding to the load, particularly in cases where this could enable denial-of-service attacks. For example, it would be a bad idea for a NAS to attempt to obtain an updated realm routing table by periodically sending probe EAP-Response/Identity packets to the AAA infrastructure in order to obtain "realm hints" as described in [RFC4284]. Not only would this add significant load to the AAA infrastructure (particularly in cases where the AAA server was already overloaded, thereby dropping packets resulting in retransmission by the NAS), but it would also not provide the NAS with a complete realm routing table, for reasons described in Section 2.3.
チャネル利用率、帯域幅の消費、ハンドオフ遅延、およびエネルギー利用により測定されたソリューションは、効率的でなければなりません。マルチキャストフレームに依存メカニズムは、マルチキャストフレームは、多くの場合、サポートされる最低レートで送信されるため、かなりのチャネル時間だけでなく、ノードをリスニングの部分にエネルギーを消費しているので注意して設計する必要があります。帯域幅がリンク上だけでなく、バックエンドのAAAインフラストラクチャの両方に制約されるため、展開によっては、それが可能です。結果として、そのようなキープアライブまたは周期的プローブパケットとしておしゃべりメカニズムは避けるべきです。 AAAサーバによって処理量を考えると、解決策は、特に、これは、サービス拒否攻撃を可能にすることができる場合には、負荷への追加を意識する必要があります。 NASは、定期的に[RFC4284]に記載されているように、「レルムヒント」を得るために、AAAインフラストラクチャにプローブEAP応答/アイデンティティパケットを送信することによって、ルーティングテーブル更新領域を取得しようとするため、例えば、それは悪い考えであろう。この（それにより、NASによって再送信を生じるパケットをドロップ特にAAAサーバが既に過負荷にした場合には、）AAAインフラストラクチャに大きな負荷を加えることになるが、それは他にも、完全なレルムルーティングテーブルとNASを提供しないだけでなく、 2.3節で述べた理由から。
Battery consumption is a significant constraint for handheld devices. Therefore, mechanisms that require significant increases in packets transmitted, or the fraction of time during which the host needs to listen (such as proposals that require continuous scanning), are to be discouraged. In addition, the solution should not significantly impact the time required to complete network attachment.
バッテリーの消費は、ハンドヘルドデバイスのための重要な制約です。したがって、有意な送信パケットの増加、又は（例えば、連続的な走査を必要とする提案として）ホストが待機する必要のある時間の割合を必要とするメカニズムが推奨されます。また、ソリューションが大幅にネットワーク接続を完了するのに必要な時間に影響を与えるべきではありません。
Given limitations on frame sizes and channel utilization, it is important that solutions scale less than linearly in terms of the number of networks and realms supported. For example, solutions such as [RFC4284] increase the size of advertisements in proportion to the number of entries in the realm routing table. This approach does not scale to support a large number of networks and realms.
フレームサイズとチャネル使用率の制限を考えると、ソリューションがサポートされたネットワークと、レルムの数の点で直線未満をスケーリングすることが重要です。例えば、このような[RFC4284]などの溶液レルムルーティングテーブルのエントリの数に比例して広告のサイズを大きくします。このアプローチは、ネットワークと、レルムの多数をサポートするために拡張できません。
Similarly, approaches that utilize separate Beacons for each "virtual AP" introduce additional Beacons in proportion to the number of networks being advertised. While such an approach may minimize the pre-configuration required for network access clients, the proliferation of "virtual APs" can result in high utilization of the wireless medium. For example, the 802.11 Beacon is sent only at a rate within the basic rate set, which typically consists of the lowest supported rates, or perhaps only the lowest supported rate. As a result, "virtual AP" mechanisms that require a separate Beacon for each "virtual AP" do not scale well.
同様に、各「仮想AP」のための別個のビーコンを利用するアプローチは、広告されているネットワークの数に比例して、追加のビーコンを導入します。そのようなアプローチは、ネットワーク・アクセス・クライアントに必要な事前設定を最小限に抑えることができるが、「仮想アクセスポイント」の増殖は、無線媒体の高い利用をもたらすことができます。例えば、802.11ビーコンのみ、典型的には最低サポートされるレート、またはおそらく唯一の最も低いサポートされたレートで構成され、基本的なレートセット内の速度で送信されます。結果として、各「仮想AP」のための別個のビーコンを必要とする「仮想AP」メカニズムは十分にスケーリングしません。
For example, with a Beacon interval of 100 Time Units (TUs) or 102.4 ms (9.8 Beacons/second), twenty 802.11b "virtual APs" each announcing their own Beacon of 170 octets would result in a channel utilization of 37.9 percent. The calculation can be verified as follows:
例えば、100時間単位（TUの）または102.4 MS（第9.8ビーコン/）、20の802.11b「仮想アクセスポイント」のビーコン間隔でそれぞれ37.9パーセントのチャネル利用をもたらす170オクテットの独自のビーコンを発表。次のように計算を検証することができます。
1. A single 170-octet Beacon sent at 1 Mbps will utilize the channel for 1360 us (1360 bits @ 1 Mbps);
1ビーコンは1 Mbpsで送信される単一の170オクテット1360のために、米国（1 Mbpsの@ 1360ビット）チャネルを利用します。
2. Adding 144 us for the Physical Layer Convergence Procedure (PLCP) long preamble (144 bits @ 1 Mbps), 48 us for the PLCP header (48 bits @ 1 Mbps), 10 us for the Short Interframe Space (SIFS), 50 us for the Distributed Interframe Space (DIFS), and 320 us for the average minimum Contention Window without backoff (CWmin/2 * aSlotTime = 32/2 * 20 us) implies that a single Beacon will utilize an 802.11b channel for 1932 us;
2.米国では米国ショートフレーム間スペース（SIFS）、50のために、PLCPヘッダ（1 Mbpsの@ 48ビット）が10物理層コンバージェンスプロシージャの144米国の追加（PLCP）ロングプリアンブル（1 Mbpsの@ 144ビット）、48バックオフなしの平均最小コンテンションウィンドウの分散フレーム間スペース（DIFS）、および320 US米国（のCWmin / 2×aSlotTime = 32/2 * 20米国）単一のビーコンは、1932私達のための802.11bチャネルを利用することを意味します。
3. Multiply the channel time per Beacon by 196 Beacons/second, and we obtain a channel utilization of 378672 us/second = 37.9 percent.
3.乗算196のビーコン/秒によってビーコンあたりのチャネル時間、そして我々は378672のチャネル利用たち/秒を取得= 37.9パーセント。
In addition, since Beacon/Probe Response frames are sent by each AP over the wireless medium, stations can only discover APs within range, which implies substantial coverage overlap for roaming to occur without interruption. Another issue with the Beacon and Probe Request/Response mechanism is that it is either insecure or its security can be assured only as part of authenticating to the network (e.g., verifying the advertised capabilities within the 4-way handshake).
ビーコン/プローブ応答フレームを無線媒体上に各APによって送信されるので、また、ステーションは、中断することなく発生するローミングのための実質的なカバレッジオーバーラップを意味しており、範囲内のAPを発見することができます。ビーコンおよびプローブ要求/応答機構の別の問題は、それが安全でないか、そのセキュリティのみ（例えば、4ウェイハンドシェイク内アドバタイズ機能を検証する）ネットワークへの認証の一部として確保することができるいずれかであることです。
A number of enhancements have been proposed to the Beacon/Probe Response mechanism in order to improve scalability and performance in roaming scenarios. These include allowing APs to announce capabilities of neighbor APs as well as their own [IEEE.802.11k]. More scalable mechanisms for support of "virtual APs" within IEEE 802.11 have also been proposed [IEEE.802.11v]; generally these proposals collapse multiple "virtual AP" advertisements into a single advertisement.
拡張の数は、シナリオをローミングにスケーラビリティとパフォーマンスを改善するために、ビーコン/プローブ応答機構が提案されています。これらは、近隣のAPの能力だけでなく、[IEEE.802.11k]自分自身を発表できるようにAPを含んでいます。 IEEE 802.11内の「仮想のAP」のサポートのためのよりスケーラブルなメカニズムも[IEEE.802.11v]提案されています。一般的にこれらの提案は、単一の広告に複数の「仮想AP」の広告を折りたたみます。
Higher-layer mechanisms can also be used to improve scalability since, by running over IP, they can utilize facilities, such as fragmentation, that may not be available at the link layer. For example, in IEEE 802.11, Beacon frames cannot use fragmentation because they are multicast frames.
上位レイヤの機構はまた、IP上で実行することによって、それらはリンクレイヤで使用できない場合があり、このような断片のような施設を利用することができるので、拡張性を改善するために使用することができます。彼らはマルチキャストフレームであるため、例えば、IEEE 802.11で、ビーコンフレームは、フラグメンテーションを使用することはできません。
"Phone-book" based approaches such as [RFC3017] can provide information for automatic selection decisions. While this approach has been applied to wireless access, it typically can only be used successfully within a single operator or limited roaming partner deployment. For example, were a "Phone-Book" approach to attempt to incorporate information from a large number of roaming partners, it could become quite difficult to keep the information simultaneously comprehensive and up to date. As noted in [Priest04] and [GROETING], a large fraction of current WLAN access points operate on the default SSID, which may make it difficult to distinguish roaming partner networks by SSID. In any case, in wireless networks, dynamic discovery is a practical requirement since a node needs to know which APs are within range before it can connect.
「電話帳」など[RFC3017]のようにベースのアプローチは、自動選択の意思決定のための情報を提供することができます。このアプローチは、ワイヤレスアクセスに適用されてきたが、それは一般的にのみ成功し、単一のオペレータまたは制限されたローミングパートナーの展開内で使用することができます。例えば、同時に包括的かつ最新の情報を維持するために、それは非常に困難になる可能性があり、ローミングパートナーの大多数からの情報を組み込むしようとする「電話帳」のアプローチでした。 【Priest04]で述べたようにして[GROETING]、現在のWLANアクセスポイントの大部分は、それが困難SSIDによってパートナーネットワークをローミング区別することがあり、デフォルトのSSID、上で動作します。ノードは、それが接続する前に範囲内にあるAPを知る必要があるので、いずれの場合においても、無線ネットワークでは、動的検出は、実用的な要件です。
Network discovery and selection mechanisms may introduce new security vulnerabilities. As noted in Section 2.3.1, network operators may consider the AAA routing table to be confidential information, and therefore may not wish to provide it to unauthenticated peers via the mechanism described in RFC 4284. While the peer could provide a list of the realms it supports, with the authenticator choosing one, this approach raises privacy concerns. Since identity selection occurs prior to authentication, the peer's supported realms would be sent in cleartext, enabling an attacker to determine the realms for which a potential victim has credentials. This risk can be mitigated by restricting peer disclosure. For example, a peer may only disclose additional realms in situations where an initially selected identity has proved unusable.
ネットワーク発見と選択のメカニズムは、新たなセキュリティの脆弱性を導入することができます。 2.3.1項で述べたように、ネットワークオペレータは、機密情報であるとAAAルーティングテーブルを考慮することができるので、ピアがレルムのリストを提供できるがRFC 4284.に記載の機構を介して認証されていないピアにそれを提供したくないかもしれませんそれは、このアプローチは、プライバシーの問題を提起し、オーセンティケータは、いずれかを選択して、サポートしています。アイデンティティの選択は、認証する前に発生するため、ピアがサポートしている領域は、潜在的な被害者が資格情報を持っているレルムを決定するために、攻撃者を有効にする、クリアテキストで送信されます。このリスクは、ピア開示を制限することによって緩和することができます。例えば、ピアは、最初に選択されたアイデンティティが使用不可能であることが判明した状況では、追加のレルムを開示することができます。
Since network selection occurs prior to authentication, it is typically not possible to secure mechanisms for network discovery or identity selection, although it may be possible to provide for secure confirmation after authentication is complete. As an example, some parameters discovered during network discovery may be confirmable via EAP Channel Bindings; others may be confirmed in a subsequent Secure Association Protocol handshake.
ネットワーク選択が認証される前に発生するので、認証が完了した後、安全な確認を提供することが可能かもしれないが、ネットワーク発見または識別を選択するためのメカニズムを確保するために、典型的には不可能です。例として、ネットワーク探索中に発見されたいくつかのパラメータは、EAPチャネルバインディング経由で確認可能であってもよく、他の人は、その後のセキュア協会プロトコルハンドシェイクで確認することができます。
However, there are situations in which advertised parameters may not be confirmable. This could lead to "bidding down" vulnerabilities. Section 7.8 of [RFC3748] states:
しかし、パラメータが確認できないかもしれません公示されている状況があります。これは、脆弱性を「競り下げ」につながる可能性があります。 [RFC3748]のセクション7.8の状態：
Within or associated with each authenticator, it is not anticipated that a particular named peer will support a choice of methods. This would make the peer vulnerable to attacks that negotiate the least secure method from among a set. Instead, for each named peer, there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method.
または各オーセンティケータに関連した中では、特定の名前のピアがメソッドの選択をサポートすることが予想されていません。これは、セットの中から、最も安全な方法を交渉する攻撃にピアが脆弱になるだろう。代わりに、それぞれの名前のピアのために、そのピア名を認証するために使用される、正確に1つの方法の兆候があるはずです。ピアが、異なる状況下で異なる認証方法を利用する必要がある場合、別個のアイデンティティは、1つの認証方式を識別するそれぞれが、使用されるべきです。
In practice, where the authenticator operates in "pass-through" mode, the EAP method negotiation will occur between the EAP peer and server, and therefore the peer will need to associate a single EAP method with a given EAP server. Where multiple EAP servers and corresponding identities may be reachable from the same selected network, the EAP peer may have difficulty determining which identity (and corresponding EAP method) should be used. Unlike network selection, which may be securely confirmed within a Secure Association Protocol handshake, identity selection hints provided within the EAP-Request/Identity are not secured.
オーセンティケータが「パススルー」モードで動作する場合、実際には、EAPメソッドのネゴシエーションは、EAPピアとサーバとの間で発生するので、ピアは、所与のEAPサーバと単一のEAPメソッドを関連付ける必要があります。複数のEAPサーバ及び対応する識別情報が同一の選択されたネットワークから到達可能であってもよい場合、EAPピアは同一（および対応するEAPメソッド）を使用しなければならない難しさを決定していてもよいです。しっかりセキュア協会プロトコルハンドシェイク中に確認することができるネットワークの選択とは異なり、EAP要求/アイデンティティ内部に設けられたアイデンティティ選択のヒントが確保されていません。
As a result, where the identity selection mechanism described in RFC 4284 is used, the "hints" provided could be used by an attacker to convince the victim to select an identity corresponding to an EAP method offering lesser security (e.g., EAP MD5-Challenge). One way to mitigate this risk is for the peer to only utilize EAP methods satisfying the [RFC4017] security requirements, and for the peer to select the identity corresponding to the strongest authentication method where a choice is available.
RFC 4284に記載のアイデンティティ選択機構が使用されている結果として、被害者を説得するために攻撃者によって使用され得る設け「ヒント」が少ないセキュリティを提供するEAPメソッド（例えば、EAP MD5チャレンジに対応する識別情報を選択します）。このリスクを軽減する一つの方法は、[RFC4017]のセキュリティ要件を満たすEAPメソッドを利用するピアのためであり、ピアの選択が利用可能である最も強力な認証方式に対応するIDを選択します。
From an operational point of view, a network device in control of network advertisement and providing "realm hints" for guiding the network discovery and selection, should at least offer a management interface capable of providing status information for operators. Status information, such as counters of each selected network and used realm, and when RFC 4284 is used, the count of delivered "realm hints" might interest operators. Especially the information related to realms that fall into the "default free zone" or the "AAA fails to route" are of interest.
ビューの動作点、ネットワーク広告の制御におけるネットワーク装置及びネットワーク発見と選択を案内する「レルムヒント」を提供するから、少なくともオペレータのステータス情報を提供することが可能な管理インターフェースを提供しなければなりません。こうした各選択したネットワークのカウンタと使用領域、およびなどのステータス情報、RFC 4284を使用する場合、配信「レルムヒント」かもしれないの関心演算子の数。特に、「デフォルトフリーゾーン」または「AAAルートに失敗した」に分類され、レルムに関連した情報が重要です。
Larger deployments would benefit from a management interface that allow full remote configuration capabilities, for example, of "realm hints" in case of RFC 4284-conforming network devices. While changes to "realm hints" and realm routing information are not expected to be frequent, centralized remote management tends to lower the frequency of misconfigured devices.
大規模な導入は、例えば、RFC 4284準拠のネットワークデバイスの場合は、「レルムヒント」の完全なリモート構成機能を許可する管理インターフェイス、恩恵を受けるだろう。 「レルムヒント」とレルムルーティング情報の変更が頻繁にあることが期待されていないが、集中遠隔管理は、設定ミスデバイスの頻度を低下させる傾向があります。
This document describes the network selection and discovery problem. In the opinion of the authors, the major findings are as follows:
この文書では、ネットワーク選択と発見の問題について説明します。次のように著者の意見では、主要な調査結果は以下のとおりです。
o There is a need for additional work on access network discovery, identifier selection, AAA routing, and payload routing.
Oアクセスネットワークの発見、識別子の選択、AAAルーティング、およびペイロード・ルーティングの追加作業が必要です。
o Credential selection and AAA routing are aspects of the same problem, namely identity selection.
O資格選択およびAAAルーティングは、同じ問題、すなわち、同一の選択の態様です。
o When considering selection among a large number of potential access networks and points of attachment, the issues described in the document become much harder to solve in an automated way, particularly if there are constraints on handoff latency.
潜在的なアクセスネットワークとの結合点の多数の間で選択を考慮すると、O、文書で説明した問題は、ハンドオフの待ち時間上の制約がある場合は特に、自動化された方法で解決するためにはるかに困難になります。
o The proliferation of network discovery technologies within IEEE 802, IETF, and 3rd Generation Partnership Project (3GPP) has the potential to become a significant problem going forward. Without a unified approach, multiple non-interoperable solutions may be deployed.
IEEE 802、IETF、および第3世代パートナーシッププロジェクト（3GPP）内のネットワーク検出技術の普及は今後重要な問題になる可能性がありますoを。統一されたアプローチがなければ、複数の非相互運用可能ソリューションを展開することができます。
o New link-layer designs should include efficient distribution of network and realm information as a design requirement.
O新しいリンク層の設計は、設計要件として、効率的なネットワークの分布とレルム情報を含める必要があります。
o It may not be possible to solve all aspects of the problem for legacy NAS devices on existing link layers. Therefore, a phased approach may be more realistic. For example, a partial solution could be made available for existing link layers, with a more complete solution requiring support for link layer extensions.
O既存のリンクレイヤ上でレガシーNASデバイスのための問題のすべての側面を解決することはできないかもしれません。そのため、段階的なアプローチは、より現実的かもしれません。例えば、部分的な解決策は、リンク層の機能拡張のためのサポートを必要とする、より完全なソリューションで、既存のリンク層のために利用可能作ることができます。
With respect to specific mechanisms for access network discovery and selection:
アクセスネットワーク発見と選択のための特定のメカニズムに関しては：
o Studies such as [MACScale] and [Velayos], as well as the calculations described in Section 2.1, demonstrate that the IEEE 802.11 Beacon/Probe Response mechanism has substantial scaling issues in situations where a new Beacon is used for each "virtual AP". As a result, a single channel is, in practice, limited to less than twenty Beacon announcements with IEEE 802.11b.
Oのような[MACScale]として研究及び[ベラヨス]、ならびに2.1項に記載された計算は、IEEE 802.11ビーコン/プローブ応答機構は、新しいビーコンが各「仮想AP」のために使用される状況において、実質的なスケーリングの問題を有していることを実証しています。結果として、単一のチャネルが、実際には、IEEE 802.11bのと20の未満ビーコンアナウンスに限定されます。
The situation is improved substantially with successors, such as IEEE 802.11a, that enable additional channels, thus potentially increasing the number of potential virtual APs.
状況は、このように潜在的に可能性のある仮想APの数を増加させる、追加のチャネルを有効にこのようなIEEE 802.11aのような後継、と実質的に改善されます。
However, even with these enhancements, it is not feasible to advertise more than 50 different networks, and probably less in most circumstances.
しかし、これらの機能強化と、ほとんどの状況では、おそらく少ない50の以上の異なるネットワーク、およびを宣伝することは不可能です。
As a result, there appears to be a need to enhance the scalability of IEEE 802.11 network advertisements.
その結果、IEEE 802.11ネットワーク広告のスケーラビリティを強化する必要があるように見えます。
o Work is underway in IEEE 802.1, IEEE 802.21, and IEEE 802.11u [IEEE.802.11u] to provide enhanced discovery functionality. Similarly, IEEE 802.1af [IEEE.802.1af] has discussed the addition of network discovery functionality to IEEE 802.1X [IEEE.8021X-2004]. However, neither IEEE 802.1AB [IEEE.802.1ab] nor IEEE 802.1af is likely to support fragmentation of network advertisement frames so that the amount of data that can be transported will be limited.
O作業が強化され、発見機能を提供するためにIEEE 802.1、IEEE 802.21、およびIEEE 802.11u [IEEE.802.11u]で進行中です。同様に、IEEE 802.1afは[IEEE.802.1af] IEEE 802.1X [IEEE.8021X-2004]にネットワーク発見機能の追加を議論しています。しかし、IEEE 802.1AB [IEEE.802.1ab]やIEEE 802.1afどちらも輸送することができるデータの量が制限されるように、ネットワーク広告枠の断片化をサポートする可能性があります。
o While IEEE 802.11k [IEEE.802.11k] provides support for the Neighbor Report, this only provides for gathering of information on neighboring 802.11 APs, not points of attachment supporting other link layers. Solution to this problem would appear to require coordination across IEEE 802 as well as between standards bodies.
IEEE 802.11kは[IEEE.802.11k]近隣レポートのためのサポートを提供するが、O、これは802.11アクセスポイントではなく、他のリンク層を支持する結合点に隣接する情報の収集を提供します。この問題を解決するには、IEEE 802を越えなどの標準化団体間の調整を必要とするように思われます。
o Given that EAP does not support fragmentation of EAP-Request/ Identity packets, the volume of "realm hints" that can be fit with these packets is limited. In addition, within IEEE 802.11, EAP packets can only be exchanged within State 3 (associated and authenticated). As a result, use of EAP for realm discovery may result in significant delays. The extension of the realm advertisement mechanism defined in [RFC4284] to handle advertisement of realm capability information (such as QoS provisioning) is not recommended due to semantic and packet size limitations [GROETING]. As a result, we believe that extending the mechanism described in [RFC4284] for discovery of realm capabilities is inappropriate. Instead, we believe it is more appropriate for this functionality to be handled within the link layer so that the information can be available early in the handoff process.
O EAPがEAP要求/アイデンティティパケットの断片化をサポートしていないことを考えると、これらのパケットにフィットすることができ、「レルムヒント」の量が限られています。また、IEEE 802.11内、EAPパケットは、（関連すると認証された）状態3内で交換することができます。その結果、領域の検出のためのEAPを使用することは、重大な遅延をもたらすことができます。 [RFC4284]で定義されたレルム広告機構の拡張は、意味及びパケットサイズの制限[GROETING]のため推奨されない（例えば、QoSがプロビジョニングなど）レルム能力情報の広告を処理します。その結果、我々は、レルムの機能の発見のために[RFC4284]で説明したメカニズムを拡張することが不適切であると信じています。代わりに、私たちは、情報が早いハンドオフプロセスで利用できるようにすることができるように、この機能は、リンク層内で処理されることがより適切であると考えています。
o Where link-layer approaches are not available, higher-layer approaches can be considered. A limitation of higher-layer solutions is that they can only optimize the movement of already connected hosts, but cannot address scenarios where network discovery is required for successful attachment.
リンク層のアプローチが利用できない場合は、O、上位層のアプローチが考えられます。上位層ソリューションの制限は、それらが、すでに接続されたホストの移動を最適化することができるが、ネットワーク発見は成功取り付けるために必要とされるシナリオに対処できないことです。
Higher-layer alternatives worth considering include the SEAMOBY CARD protocol [RFC4066], which enables advertisement of network device capabilities over IP, and Device Discovery Protocol (DDP) [MARQUES], which provides functionality equivalent to IEEE 802.1AB using ASN.1 encoded advertisements sent to a link-local scope multicast address.
検討に値する上位選択肢がSEAMOBYのCARDプロトコル[RFC4066]、IP上のネットワーク・デバイス能力の広告を可能にし、ASN.1符号化された広告を使用して、IEEE 802.1ABに相当する機能を提供するデバイスディスカバリプロトコル（DDP）MARQUES]を含みますリンクローカルスコープのマルチキャストアドレスに送信されました。
All aspects of the network discovery and selection problem are security related. The security issues and requirements have been discussed in the previous sections.
ネットワーク発見と選択問題のすべての側面では、セキュリティ関連のあります。セキュリティ上の問題や要件は、前のセクションで説明されています。
The security requirements for network discovery depend on the type of information being discovered. Some of the parameters may have a security impact, such as the claimed name of the network to which the user tries to attach. Unfortunately, current EAP methods do not always make the verification of such parameters possible. EAP methods, such as Protected EAP (PEAP) [JOSEFSSON] and EAP-IKEv2 [IKEV2], may make this possible, however. There is even an attempt to provide a backward-compatible extension to older methods [ARKKO].
ネットワーク検出のためのセキュリティ要件が発見されている情報の種類によって異なります。パラメータの一部は、このようなユーザーが添付しようとしているネットワークの主張名などのセキュリティへの影響を有していてもよいです。残念ながら、現在のEAPメソッドは常に可能なパラメータの検証を行いません。そのような保護されたEAP（PEAP）[Josefsson氏]及びEAP-IKEv2のようなEAPメソッド、[のIKEv2]は、しかし、これを可能にすることができます。古い方法[ARKKO]への下位互換性の拡張を提供する試みでもあります。
The security requirements for network selection depend on whether the selection is considered a mandate or a hint. In general, treating network advertisements as a hint is a more secure approach, since it reduces access client vulnerability to forged network advertisements. For example, "realm hints" may be ignored by an EAP peer if they are incompatible with the security policy corresponding to a selected access network.
ネットワーク選択のためのセキュリティ要件は、選択が任務やヒントと見なされているかどうかによって異なります。それが偽造ネットワーク広告へのアクセスクライアントの脆弱性を減らすため、一般的には、ヒントとしてネットワーク広告を処理することは、より安全なアプローチです。彼らは、選択したアクセスネットワークに対応したセキュリティポリシーに互換性がない場合たとえば、「レルムはヒント」EAPピアによって無視することができます。
Similarly, network access clients may refuse to connect to a point of attachment if the advertised security capabilities do not match those that have been pre-configured. For example, if an IEEE 802.11 access client has been pre-configured to require WPA2 enterprise support within an access network, it may refuse to connect to access points advertising support for WEP.
同様に、ネットワーク・アクセス・クライアントは、アドバタイズされたセキュリティ機能があらかじめ設定されたものと一致しない場合、結合点に接続するために拒否することができます。 IEEE 802.11アクセスクライアントがアクセスネットワーク内WPA2エンタープライズサポートを必要とするように事前に設定されている場合、それはWEPのサポートを広告するアクセスポイントへの接続を拒否することができます。
Where the use of methods that do not satisfy the security requirements of [RFC4017] is allowed, it may be possible for an attacker to trick a peer into using an insecure EAP method, leading to the compromise of long-term credentials. This can occur either where a network is pre-configured to allow use of an insecure EAP method, or where connection without pre-configuration is permitted using such methods.
[RFC4017]のセキュリティ要件を満たしていない方法での使用が許可されている場合、攻撃者が長期の資格情報の妥協につながる、安全でないEAPメソッドを使用してに相手をだましすることが可能です。ネットワークは、安全でないEAPメソッド、またはここで事前構成することなく接続は、このような方法を使用して、許可されているの使用を可能にするように事前に構成されているところでも発生することができます。
For example, an attacker can spoof a network advertisement, possibly downgrading the advertised security capabilities. The rogue access point would then attempt to negotiate an insecure EAP method. Such an attack can be prevented if the peer refuses to connect to access points not meeting its security requirements, which would include requiring use of EAP methods satisfying the [RFC4017] requirements.
例えば、攻撃者は、おそらく広告を出してセキュリティ機能をダウングレード、ネットワーク広告を偽装することができます。不正なアクセスポイントは、安全でないEAPメソッドを交渉しようとしていました。ピアがアクセスポイントは[RFC4017]の要件を満足するEAPメソッドの使用を必要含まれるそのセキュリティ要件を満たしていないとの接続を拒否した場合、このような攻撃を防ぐことができます。
Support for secure discovery could potentially protect against spoofing of network advertisements, enabling verifiable information to guide connection decisions. However, development of these mechanisms requires solving several difficult engineering and deployment problems.
安全な発見のためのサポートは、潜在的な接続の意思決定を導くために検証可能な情報を有効にする、ネットワーク広告のなりすましから守ることができました。しかし、これらのメカニズムの開発には、いくつかの困難なエンジニアリングと展開の問題を解決する必要があり。
Since discovery is a prerequisite for authentication, it is not possible to protect initial discovery using dynamic keys derived in the authentication process. On the other hand, integrity protection of network advertisements utilizing symmetric keys or digital signatures would require pre-configuration.
発見は認証のための前提条件であるので、認証プロセスで得られた動的なキーを使用して最初の発見を保護することはできません。一方、対称鍵またはデジタル署名を利用したネットワーク広告の完全性保護は、事前の設定が必要になります。
[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月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[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月。
[RFC3017] Riegel, M. and G. Zorn, "XML DTD for Roaming Access Phone Book", RFC 3017, December 2000.
[RFC3017]リーゲル、M.およびG.ツォルン、 "ローミングアクセス電話帳用のXML DTD"、RFC 3017、2000年12月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[RFC4334] Housley, R. and T. Moore, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)", RFC 4334, February 2006.
[RFC4334] Housley氏、R.とT.ムーア、「証明書の拡張機能と属性で認証のサポートポイントツーポイントプロトコル（PPP）とワイヤレスローカルエリアネットワーク（WLAN）」、RFC 4334、2006年2月。
[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月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[RFC4072] Eronen, P., 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月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579] Aboba、B.およびP.カルフーン、 "RADIUS（ユーザサービスにおけるリモート認証ダイヤル）拡張認証プロトコル（EAP）のサポート"、RFC 3579、2003年9月。
[RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997.
[RFC2194] Aboba、B.、陸、J.、オールソップ、J.、鼎、J.、およびW.ワング、 "ローミング実装のレビュー"、RFC 2194、1997年9月。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607] Aboba、B.、およびJ. Vollbrecht、 "ローミング中のプロキシ連鎖とポリシー実装"、RFC 2607、1999年6月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608]ガットマン、E.、パーキンス、C.、Veizades、J.、およびM.日、 "サービスロケーションプロトコル、バージョン2"、RFC 2608、1999年6月。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3580] Congdon氏、P.、Aboba、B.、スミス、A.、ゾルン、G.、およびJ.レーゼ、 "IEEE 802.1Xのリモート認証ダイヤルインユーザーサービス（RADIUS）使用上のガイドライン"、RFC 3580、2003年9月。
[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）のためのヒント"。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]スタンレー、D.、ウォーカー、J.、およびB. Aboba、 "無線LANのための拡張認証プロトコル（EAP）メソッド要件"、RFC 4017、2005年3月。
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[RFC2486] Aboba、B.及びM. Beadles、 "ネットワークアクセス識別子"、RFC 2486、1999年1月。
[RFC4066] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, "Candidate Access Router Discovery (CARD)", RFC 4066, July 2005.
[RFC4066] Liebsch、M.、シン、A.、Chaskar、H.、船戸、D.、およびE.シム、 "候補アクセスルータ発見（CARD）"、RFC 4066、2005年7月。
[IKEV2] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and F. Bersani, "EAP-IKEv2 Method", Work in Progress, September 2007.
【のIKEv2] Tschofenig、H.、Kroeselberg、D.、Pashalidis、A.、オオバ、Y.、およびF. Bersani、 "EAP-IKEv2の方法"、進歩、2007年9月ワーク。
[ARKKO] Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", Work in Progress, October 2005.
[ARKKO] Arkko、J.、およびP. Eronen、 "拡張認証プロトコル（EAP）のための認証サービスの情報"、進歩、2005年10月に作業。
[GROETING] Groeting, W., Berg, S., Tschofenig, H., and M. Ness, "Network Selection Implementation Results", Work in Progress, July 2004.
[GROETING] Groeting、W.、ベルク、S.、Tschofenig、H.、およびM.ネス、 "ネットワーク選択のインプリメンテーション結果"、進歩、2004年7月に作業。
[JOSEFSSON] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G., and S. Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.
【Josefsson氏] Palekar、A.、サイモン、D.、Salowey、J.、周、H.、ゾルン、G.、およびS. Josefsson氏、 "保護されたEAPプロトコル（PEAP）バージョン2"、進歩、2004年10月ワーク。
[MARQUES] Enns, R., Marques, P., and D. Morrell, "Device Discovery Protocol (DDP)", Work in Progress, May 2003.
[MARQUES]エンス、R.、マルケス、P.、およびD.モレル、 "デバイスディスカバリプロトコル（DDP）"、進歩、2003年5月での作業。
[OHBA] Taniuchi, K., Ohba, Y., and D. Subir, "IEEE 802.21 Basic Schema", Work in Progress, October 2007.
[OHBA]谷内、K.、大場、Y.、およびD. Subir、 "IEEE 802.21基本スキーマ"、進歩、2007年10月の作業。
[IEEE.802.11-2003] IEEE, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 2003.
[IEEE.802.11-2003] IEEE、 "無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様"、IEEE規格802.11、2003年。
[Fixingapsel] Judd, G. and P. Steenkiste, "Fixing 802.11 Access Point Selection", Sigcomm Poster Session 2002.
[Fixingapsel]ジャッド、G.とP. Steenkiste、 "802.11アクセスポイント選択の修正"、2002 SIGCOMMポスターセッション。
[IEEE.802.11k] IEEE, "Draft Ammendment to Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Radio Resource Management", IEEE 802.11k, D7.0, January 2007.
[IEEE.802.11k] IEEE、「電気通信及びシステム間情報交換のための標準のドラフトAmmendment - LAN / MAN具体的な要件 - パート11：無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様：無線リソース管理」 、IEEE 802.11k、D7.0、2007年1月。
[IEEE.802.1ab] IEEE, "Draft Standard for Local and Metropolitan Area Networks - Station and Media Access Control Connectivity Discovery", IEEE 802.1AB, D1.0, April 2007.
[IEEE.802.1ab] IEEE、「地方とメトロポリタンエリアネットワークの規格案 - 駅やメディアアクセス制御接続ディスカバリー」、IEEE 802.1AB、D1.0、2007年4月。
[IEEE.802.1af] IEEE, "Draft Standard for Local and Metropolitan Area Networks - Port-Based Network Access Control - Amendment 1: Authenticated Key Agreement for Media Access Control (MAC) Security", IEEE 802.1af, D1.2, January 2007.
[IEEE.802.1af] IEEE、「 - ポートベースのネットワークアクセス制御 - ローカルおよびメトロポリタンエリアネットワークのドラフト規格改正1：メディアアクセス制御（MAC）セキュリティのための認証されたキー契約」、IEEE 802.1af、D1.2、1月2007。
[IEEE.802.11v] IEEE, "Draft Amemdment to Standard for Information Technology - Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Wireless Network Management", IEEE 802.11v, D0.09, March 2007.
[IEEE.802.11v] IEEE、「ドラフトAmemdment情報技術のための標準に - 電気通信及びシステム間情報交換 - LAN / MAN具体的な要件 - パート11：無線媒体アクセス制御（MAC）および物理層（PHY）仕様：ワイヤレスネットワーク管理」、IEEE 802.11v、D0.09、2007年3月。
[Eronen04] Eronen, P. and J. Arkko, "Role of authorization in wireless network security", Extended abstract presented in the DIMACS workshop, November 2004.
[Eronen04] Eronen、P.およびJ. Arkko、「ワイヤレスネットワークのセキュリティにおける認証の役割」、DIMACSワークショップ、2004年11月に発表抽象拡張。
[IEEE.11-04-0624] Berg, S., "Information to Support Network Selection", IEEE Contribution 11-04-0624 2004.
[IEEE.11-04-0624]ベルク、S.、IEEE貢献11-04-0624 2004 "ネットワーク選択をサポートするための情報"。
[Priest04] Priest, J., "The State of Wireless London", July 2004.
[プリースト04]プリースト、インチ、「ワイヤレスロンドンの状態」、2004年7月。
[MACScale] Heusse, M., "Performance Anomaly of 802.11b", LSR-IMAG Laboratory, Grenoble, France, IEEE Infocom 2003.
[MACScale] Heusse、M.、 "802.11のパフォーマンス異常"、LSR-IMAG研究所、グルノーブル、フランス、2003 IEEEインフォコム。
[Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b MAC Layer Handover Time", Laboratory for Communication Networks, KTH, Royal Institute of Technology, Stockholm, Sweden, TRITA-IMIT-LCN R 03:02, April 2003.
通信ネットワーク、KTH、王立工科大学、ストックホルム、スウェーデン、TRITA-IMIT-LCN R午前3時02ために、研究室[ベラヨス]ベラヨス、H.およびG.カールソン、 "IEEE 802.11bのMACレイヤハンドオーバ時間を短縮する技術" 、2003年4月。
[IEEE.802.11u] IEEE, "Draft Amendment to STANDARD FOR Information Technology - LAN/MAN Specific Requirements - Part 11: Interworking with External Networks; Draft Amendment to Standard; IEEE P802.11u/D0.04", IEEE 802.11u, D0.04, April 2007.
[IEEE.802.11u] IEEE、 "情報技術のための標準への改正案 - LAN / MAN具体的な要件 - パート11：外部ネットワークとのインターワーキング;スタンダードへの改正案、IEEE P802.11u / D0.04"、IEEE 802.11u、 D0.04、2007年4月。
[IEEE-11-03-154r1] Aboba, B., "Virtual Access Points", IEEE Contribution 11- 03-154r1, May 2003.
[IEEE-11-03-154r1] Aboba、B.、 "仮想アクセスポイント"、IEEE貢献の11- 03-154r1、2003年5月。
[IEEE-11-03-0827] Hepworth, E., "Co-existence of Different Authentication Models", IEEE Contribution 11-03-0827 2003.
[IEEE-11-03-0827]ヘップワース、E.、 "異なる認証モデルの共存"、IEEE貢献11-03-0827 2003。
[11-05-0822-03-000u-tgu-requirements] Moreton, M., "TGu Requirements", IEEE Contribution 11-05- 0822-03-000u-tgu-requirements, August 2005.
[11-05-0822-03-000u-TGU-要件]モートン、M.、 "TGU要件"、IEEE貢献11-05- 0822-03-000u-TGU-要件、2005年8月。
[3GPPSA2WLANTS] 3GPP, "3GPP System to Wireless Local Area Network (WLAN) interworking; System De scription; Release 6; Stage 2", 3GPP Technical Specification 23.234, September 2005.
[3GPPSA2WLANTS] 3GPPは、 "ワイヤレスローカルエリアネットワーク（WLAN）インターワーキングへの3GPPシステム、システムのデscriptionは、リリース6;ステージ2"、3GPP技術仕様23.234、2005年9月。
[3GPP-SA3-030736] Ericsson, "Security of EAP and SSID based network advertisements", 3GPP Contribution S3-030736, November 2003.
[3GPP-SA3-030736]エリクソン、 "EAPおよびSSIDのセキュリティベースのネットワーク広告"、3GPP貢献S3-030736、2003年11月。
[3GPP.23.122] 3GPP, "Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode", 3GPP TS 23.122 6.5.0, October 2005.
【3GPP.23.122] 3GPP、 "アイドルモード移動局（MS）に関連する非アクセス・ストラタム（NAS）機能"、3GPP TS 23.122 6.5.0 2005年10月。
[WWRF-ANS] Eijk, R., Brok, J., Bemmel, J., and B. Busropan, "Access Network Selection in a 4G Environment and the Role of Terminal and Service Platform", 10th WWRF, New York, October 2003.
[WWRF-ANS] Eijk、R.、Brok、J.、Bemmel、J.、およびB. Busropan、 "アクセスネットワーク選択4G環境で端末とサービスプラットフォームの役割"、第10回WWRF、ニューヨーク州10月2003。
[WLAN3G] Ahmavaara, K., Haverinen, H., and R. Pichna, "Interworking Architecture between WLAN and 3G Systems", IEEE Communications Magazine, November 2003.
[WLAN3G] Ahmavaara、K.、Haverinen、H.、およびR. Pichna、 "WLANと3Gシステム間のインターワーキング・アーキテクチャ"、IEEE通信誌、2003年11月。
[INTELe2e] Intel, "Wireless LAN (WLAN) End to End Guidelines for Enterprises and Public Hotspot Service Providers", November 2003.
[INTELe2e]インテル、2003年11月「ワイヤレスLAN（WLAN）の終了は、企業や公共のホットスポットサービスプロバイダのためのガイドラインを終了します」。
[Eronen03] Eronen, P., "Network Selection Issues", presentation to EAP WG at IETF 58, November 2003.
[Eronen03] Eronen、P.、 "ネットワークの選択の問題"、IETF 58、2003年11月のEAP WGへのプレゼンテーション。
[3GPPSA3WLANTS] 3GPP, "3GPP Technical Specification Group Service and System Aspects; 3G Security; Wireless Local Area Network (WLAN) interworking security (Release 6); Stage 2", 3GPP Technical Specification 33.234 v 6.6.0, October 2005.
[3GPPSA3WLANTS] 3GPP、 "3GPP技術仕様グループサービスおよびシステムアスペクト; 3Gセキュリティ;ワイヤレスローカルエリアネットワーク（WLAN）インターワーキングセキュリティ（6）リリース;ステージ2"、3GPP技術仕様33.234 V 6.6.0、2005年10月。
[3GPPCT1WLANTS] 3GPP, "3GPP System to Wireless Local Area Network (WLAN) interworking; User Equipment (UE) to network protocols; Stage 3 (Release 6)", 3GPP Technical Specification 24.234 v 6.4.0, October 2005.
[3GPPCT1WLANTS] 3GPP、 "ワイヤレスローカルエリアネットワーク（WLAN）インターワーキングへの3GPPシステム、ネットワークプロトコルへのユーザ機器（UE）;第3段階（リリース6）"、3GPP技術仕様24.234 V 6.4.0、2005年10月。
[IEEE.802.21] IEEE, "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE 802.21, D05.00, April 2007.
[IEEE.802.21] IEEEは、 "ローカルおよびメトロポリタンエリアネットワークのためのIEEE規格のドラフト：メディア独立ハンドオーバサービス"、IEEE 802.21、D05.00、2007年4月。
[3GPPCT4WLANTS] 3GPP, "3GPP system to Wireless Local Area Network (WLAN) interworking; Stage 3 (Release 6)", 3GPP Technical Specification 29.234 v 6.4.0, October 2005.
"インターワーキングワイヤレスローカルエリアネットワーク（WLAN）への3GPPシステム;ステージ3（リリース6）" [3GPPCT4WLANTS] 3GPP、3GPP技術仕様29.234 V 6.4.0、2005年10月。
[IEEE.8021X-2004] IEEE, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, July 2004.
[IEEE.8021X-2004] IEEE、 "地方とメトロポリタンエリアネットワーク：ポートベースのネットワークアクセス制御"、IEEE標準802.1X、2004年7月。
Appendix A. Existing Work
付録A.既存の作業
A.1. IETF
A.1。 IETF
Several IETF WGs have dealt with aspects of the network selection problem, including the AAA, EAP, PPP, RADIUS, ROAMOPS, and RADEXT WGs.
いくつかのIETFのWGはAAA、EAP、PPP、RADIUS、ROAMOPS、およびRADEXTのWGを含む、ネットワーク選択問題の側面を扱っています。
ROAMOPS WG developed the NAI, originally defined in [RFC2486], and subsequently updated in [RFC4282]. Initial roaming implementations are described in [RFC2194], and the use of proxies in roaming is addressed in [RFC2607]. The SEAMOBY WG developed CARD [RFC4066], which assists in discovery of suitable base stations. PKIX WG produced [RFC3280], which addresses issues of certificate selection. The AAA WG developed more sophisticated access routing, authentication, and service discovery mechanisms within Diameter [RFC3588].
ROAMOPS WGは元々[RFC2486]で定義され、NAIを開発し、その後、[RFC4282]で更新します。初期ローミング実装は、[RFC2194]に記載されており、ローミング中のプロキシの使用は[RFC2607]でアドレス指定されます。適切な基地局の発見に役立つSEAMOBY WG開発CARD [RFC4066]。証明書の選択の問題に対処PKIX WG生成[RFC3280]。 AAA WGは、Diameter [RFC3588]内でより洗練されたアクセス・ルーティング、認証、及びサービス発見メカニズムを開発しました。
Adrangi et al. [RFC4284] defines the use of the EAP-Request/Identity to provide "realm hints" useful for identity selection. The NAI syntax described in [RFC4282] enables the construction of source routes. Together, these mechanisms enable the user to determine whether it possesses an identity and corresponding credential suitable for use with an EAP-capable NAS. This is particularly useful in situations where the lower layer provides limited information (such as in wired IEEE 802 networks where IEEE 802.1X currently does not provide for advertisement of networks and their capabilities).
Adrangiら。 [RFC4284]はアイデンティティの選択のために有用な「レルムがヒント」を提供するためにEAP要求/アイデンティティの使用を定義します。 [RFC4282]で説明NAI構文はソースルートの構築を可能にします。一緒に、これらのメカニズムは、EAP対応NASと共に使用するのに適したアイデンティティおよび対応する資格を有するかどうかを決定するためにユーザを可能にします。これは、下位層（例えばIEEE 802.1Xは、現在のネットワークおよびそれらの能力の広告を提供しない有線IEEE 802ネットワークにおけるように）制限された情報を提供する状況において特に有用です。
However, advertisement mechanisms based on the use of the EAP-Request/Identity have scalability problems. As noted in [RFC3748] Section 3.1, the minimum EAP Maximum Transmission Unit (MTU) is 1020 octets, so that an EAP-Request/Identity is only guaranteed to be able to include 1015 octets within the Type-Data field. Since RFC 1035 [RFC1035] enables Fully Qualified Domain Names (FQDN) to be up to 255 octets in length, this may not enable the announcement of many realms. The use of network identifiers other than domain names is also possible.
しかし、EAP要求/アイデンティティの使用に基づいて広告のメカニズムは、スケーラビリティの問題を抱えています。 [RFC3748]セクション3.1で述べたように、EAP-Request / Identityのみタイプデータフィールド内の1015個のオクテットを含めることができることが保証されるように、最小EAP最大伝送単位（MTU）は1020オクテットです。 RFC 1035 [RFC1035]は、最大長さが255個のオクテットになるように完全修飾ドメイン名（FQDN）を可能にするので、これは多くのレルムのアナウンスを有効にしないことができます。ドメイン名以外のネットワーク識別子の使用も可能です。
As noted in [Eronen03], the use of the EAP-Request/Identity for realm discovery has substantial negative impact on handoff latency, since this may result in a station needing to initiate an EAP conversation with each Access Point in order to receive an EAP-Request/Identity describing which realms are supported. Since IEEE 802.11-2003 does not support use of Class 1 data frames in State 1 (unauthenticated, unassociated) within an Extended Service Set (ESS), this implies either that the APs must support 802.1X pre-authentication (optional in IEEE 802.11i-2004), or that the station must associate with each
【Eronen03]で述べたように、これはEAPを受信するために、各アクセスポイントとのEAPの会話を開始するために必要ステーションをもたらすことができるので、領域の発見のためのEAP要求/アイデンティティの使用は、ハンドオフの待ち時間に相当な負の影響を有していますレルムもサポートされている記述-request /アイデンティティ。 IEEE 802.11から2003は、拡張サービスセット（ESS）内の状態1（認証されていない、関連付けられていない）のクラス1データフレームの使用をサポートしていませんので、これは意味のいずれかのAPは、IEEE 802.11i規格ではオプション802.1X事前認証を（サポートしなければなりません-2004）、または局は、各関連付ける必要があることを
AP prior to sending an EAPOL-Start to initiate EAP (here, EAPOL refers to EAP over LAN). This will dramatically increase handoff latency.
AP（ここで、EAPOLがLAN上にEAPを指す）EAPを開始するためにEAPOL-Start]を送信する前に。これは劇的にハンドオフ遅延が増加します。
Thus, rather than thinking of [RFC4284] as an effective network discovery mechanism, it is perhaps better to consider the use of "realm hints" as an error recovery technique to be used to inform the EAP peer that AAA routing has failed, and perhaps to enable selection of an alternate identity that can enable successful authentication. Where "realm hints" are only provided in event of a problem, rather than as a staple network discovery technique, it is probably best to enable "realm hints" to be sent by core AAA proxies in the "default free" zone. This way, it will not be necessary for NASes to send "realm hints", which would require them to maintain a complete and up-to-date realm routing table, something that cannot be easily accomplished given the existing state of AAA routing technology.
このように、かなり効果的なネットワークディスカバリメカニズムとして[RFC4284]のことを考えよりも、AAAルーティングが失敗したEAPピアに通知するために使用されるエラー回復技術として「レルムヒント」の使用を考慮することが、おそらく優れている、そしておそらく成功した認証を有効にすることができます別のアイデンティティの選択を可能にします。どこで「レルムがヒント」のみ問題が発生した場合に提供されている、というよりもステープルネットワーク検出技術としては、「デフォルトの自由」ゾーンでコアAAAプロキシによって送信される「レルムヒント」を有効にするためにおそらく最高です。 NASを簡単にAAAのルーティング技術の現状与え達成することはできませんテーブル、何かをルーティング完全かつ最新のレルムを維持するためにそれらを必要とする「レルムヒント」を、送信するためにこの方法では、それが必要ではないでしょう。
If realm routing tables are manually configured on the NAS, then changes in the "default free" realm routing table will not automatically be reflected in the realm list advertised by the NAS. As a result, a realm advertised by the NAS might not, in fact, be reachable, or the NAS might neglect to advertise one or more realms that were reachable. This could result in multiple EAP-Identity exchanges, with the initial set of "realm hints" supplied by the NAS subsequently updated by "realm hints" provided by a core AAA proxy. In general, originating "realm hints" on core AAA proxies appears to be a more sound approach, since it provides for "fate sharing" -- generation of "realm hints" by the same entity (the core AAA proxy) that will eventually need to route the request based on the hints. This approach is also preferred from a management perspective, since only core AAA proxies would need to be updated; no updates would be required to NAS devices.
レルム・ルーティング・テーブルを手動でNAS上に設定されている場合は、自動的にNASによって広告領域のリストには反映されません「DEFAULT自由」レルム・ルーティング・テーブルに変更します。その結果、NASによってアドバタイズレルムは、実際には、到達可能ではないかもしれない、あるいはNASが到達可能だった一つ以上のレルムを宣伝するために無視することがあります。 NASによって供給される「レルムヒント」の初期セットは、その後、コアAAAプロキシによって提供される「レルムヒント」によって更新して、これは、複数のEAPアイデンティティ交換が生じる可能性があります。最終的に必要となる同一のエンティティ（コアAAAプロキシ）で、「レルムヒント」の世代 - それは「運命の共有」を提供するので、一般的には、コアAAAプロキシの発信元「レルムヒント」には、より健全なアプローチであるように思われますルートへの要求がヒントに基づきます。コアのみAAAプロキシを更新する必要があるので、このアプローチはまた、管理の観点から好ましいです。更新がNASデバイスに必要とされないであろう。
A.2. IEEE 802
A.2。 IEEE 802
There has been work in several IEEE 802 working groups relating to network discovery:
ネットワークディスカバリに関するいくつかのIEEE 802のワーキンググループでの作業がありました：
o [IEEE.802.11-2003] defines the Beacon and Probe Response mechanisms within IEEE 802.11. Unfortunately, Beacons may be sent only at a rate within the base rate set, which typically consists of the lowest supported rate, or perhaps the next lowest rate. Studies such as [MACScale] have identified MAC layer performance problems, and [Velayos] has identified scaling issues from a lowering of the Beacon interval.
O [IEEE.802.11-2003] IEEE 802.11内のビーコンとプローブ応答メカニズムを定義しています。残念ながら、ビーコンは、典型的には、最も低いサポートされたレート、または恐らく次の最低レートから成るベースレートセット内のレートで送信することができます。こうした[MACScale]などの研究は、MACレイヤのパフォーマンスの問題を特定している、と[ベラヨス]ビーコン間隔の低下から、スケーリングの問題を特定しました。
o [IEEE-11-03-0827] discusses the evolution of authentication models in WLANs and the need for the network to migrate from existing models to new ones, based on either EAP layer indications or through the use of SSIDs to represent more than the local network. It notes the potential need for management or structuring of the SSID space.
O [IEEE-11-03-0827]はEAP層の適応症のいずれかまたは以上のものを表現するためのSSIDを使用してベース、無線LANでの認証モデルの進化と新しいものに既存のモデルから移行するためのネットワークの必要性を論じローカルネットワーク。これは、SSIDのスペースの管理や構造化のための潜在的な必要性を指摘しています。
The paper also notes that virtual APs have scalability issues. It does not compare these scalability issues to those of alternative solutions, however.
論文は、仮想APはスケーラビリティの問題を持っていることを指摘します。しかし、代替ソリューションのものにこれらのスケーラビリティの問題を比較しません。
o [IEEE-11-03-154r1] discusses mechanisms currently used to provide "virtual AP" capabilities within a single physical access point. A "virtual AP" appears at the MAC and IP layers to be a distinct physical AP. As noted in the paper, full compatibility with existing 802.11 station implementations can only be maintained if each "virtual AP" uses a distinct MAC address (BSSID) for use in Beacons and Probe Responses. This paper does not discuss scaling issues in detail, but recommends that only a limited number of "virtual APs" be supported by a single physical access point.
O [IEEEは-11-03-154r1]現在、単一の物理アクセスポイント内の「仮想AP」機能を提供するために使用されるメカニズムを説明します。 「仮想APは、」個別の物理的なAPであることをMACおよびIPレイヤで表示されます。論文に述べたように、各「仮想AP」は、ビーコンとプローブ応答で使用するために別個のMACアドレス（BSSID）を使用する場合、既存の802.11ステーションの実装との完全な互換性のみを維持することができます。このホワイトペーパーでは、詳細に問題をスケーリング議論が、「仮想のAP」の数が限られ、単一の物理的なアクセスポイントによってサポートされることをお勧めしません。
o IEEE 802.11u is working on realm discovery and network selection [11-05-0822-03-000u-tgu-requirements] [IEEE.802.11u]. This includes a mechanism for enabling a station to determine the identities it can use to authenticate to an access network, prior to associating with that network. As noted earlier, solving this problem requires the AP to maintain an up-to-date, "default free" realm routing table, which is not feasible without dynamic routing support within the AAA infrastructure. Similarly, a priori discovery of features supported within home realms (such as enrollment) is also difficult to implement in a scalable way, absent support for dynamic routing. Determination of network capabilities (such as QoS support) is considerably simpler, since these depend solely on the hardware and software contained within the AP. However, 802.11u is working on Generic Advertisement Service (GAS) mechanism, which can be used to carry 802.21 Information Service (IS) messages and, in that way, allow a more sophisticated way of delivering information from the network side.
O IEEE 802.11u [11-05-0822-03-000u-TGU-要件] [IEEE.802.11u]領域の検出およびネットワーク選択に取り組んでいます。これは、前にそのネットワークと関連付けるために、アクセスネットワークへの認証に使用できるアイデンティティを決定するためにステーションを可能にするための機構を含みます。先に述べたように、この問題を解決することはAAAインフラストラクチャ内の動的ルーティングのサポートなしでは不可能である最新の、「デフォルトの自由」レルム・ルーティング・テーブルを維持するためにAPが必要です。同様に、（例えば、登録など）ホームレルム内でサポートされる機能の先験的な発見は、スケーラブルな方法で動的ルーティングのために存在しないサポートを実装することも困難です。これらは、AP内に含まれるハードウェアとソフトウェアだけに依存するので（例えばQoSサポートなど）ネットワーク機能の決意は、かなり簡単です。しかし、802.21情報サービスを運ぶために使用することができ、汎用広告サービス（GAS）のメカニズム、上802.11u取り組んでいるそのように、ネットワーク側からの情報を提供する、より高度な方法を許可し、メッセージ（IS）と。
o IEEE 802.21 [IEEE.802.21] is developing standards to enable handover between heterogeneous link layers, including both IEEE 802 and non-IEEE 802 networks. To enable this, a general mechanism for capability advertisement is being developed, which could conceivably benefit aspects of the network selection problem, such as realm discovery. For example, IEEE 802.21 is developing Information Elements (IEs) that may assist with network selection, including information relevant to both layer 2 and layer 3. Query mechanisms (including both XML and TLV support) are also under development. IEEE 802.21 also defines a Resource Description Framework (RDF) schema to allow use of a query language (i.e., SPARQL). The schema is a normative part of IEEE 802.21 and also defined in [OHBA].
O IEEE 802.21は、[IEEE.802.21] IEEE 802と非IEEE 802のネットワークの両方を含むヘテロジニアスリンク層との間のハンドオーバを可能にするための基準を開発しています。これを有効にするには、能力の広告のための一般的なメカニズムが考えられる、このような領域の検出などのネットワーク選択問題の側面を、恩恵を受ける可能性がある、開発されています。例えば、IEEE 802.21は、層2及び層（XML及びTLVのサポートの両方を含む）3.クエリメカニズムの両方に関連する情報を含む、ネットワーク選択を支援することができるという情報要素（IE）を開発している開発中でもあります。 IEEE 802.21はまた、クエリ言語（即ち、SPARQL）の使用を可能にするために、リソース記述フレームワーク（RDF）スキーマを定義します。スキーマは、IEEE 802.21の規範的部分であり、また[大場]で定義されます。
A.3. 3GPP
A.3。 3GPP
The 3GPP stage 2 technical specification [3GPPSA2WLANTS] covers the architecture of 3GPP Interworking WLAN (I-WLAN) with 2G and 3G networks. This specification also discusses realm discovery and network selection issues. The I-WLAN realm discovery procedure borrows ideas from the cellular Public Land-based Mobile Network (PLMN) selection principles, known as "PLMN Selection".
3GPPステージ2技術仕様は、[3GPPSA2WLANTS] 2Gおよび3Gネットワークと3GPPインターワーキングWLAN（I-WLAN）のアーキテクチャをカバーします。また、この仕様は領域の検出およびネットワーク選択の問題について説明します。 I-WLANレルム発見手順は、「PLMN選択」として知られている細胞の公衆陸上モバイルネットワーク（PLMN）の選択の原則からアイデアを借用します。
In 3GPP PLMN selection [3GPP.23.122], the mobile node monitors surrounding cells and prioritizes them based on signal strength before selecting a new potential target cell. Each cell broadcasts its PLMN. A mobile node may automatically select cells that belong to its Home PLMN, Registered PLMN, or an allowed set of Visited PLMNs. The PLMN lists are prioritized and stored in the Subscriber Identity Module (SIM). In the case of manual PLMN selection, the mobile node lists the PLMNs it learns about from surrounding cells and enables the user to choose the desired PLMN. After the PLMN has been selected, cell prioritization takes place in order to select the appropriate target cell.
3GPP PLMN選択[3GPP.23.122]において、細胞周囲のモバイルノードを監視し、新しい潜在的なターゲットセルを選択する前に信号強度に基づいてそれらに優先順位を付けます。各セルは、そのPLMNをブロードキャストします。モバイルノードは、自動的にそのホームPLMN、登録PLMN、または訪問PLMNの許可セットに属するセルを選択することができます。 PLMNリストは、優先順位付けし、加入者識別モジュール（SIM）に格納されています。手動PLMN選択の場合には、モバイルノードは、周囲のセルからについて学習のPLMNをリストし、所望のPLMNを選択することを可能にします。 PLMNが選択された後、セルの優先順位付けは、適切な標的細胞を選択するために行われます。
[WLAN3G] discusses the new realm (PLMN) selection requirements introduced by I-WLAN roaming, which support automatic PLMN selection, not just manual selection. Multiple network levels may be present, and the hotspot owner may have a contract with a provider who, in turn, has a contract with a 3G network, which may have a roaming agreement with other networks.
[WLAN3G]自動PLMNの選択だけではなく、手動選択をサポートするI-WLANのローミングにより導入された新しい領域（PLMN）の選択要件を、説明します。複数のネットワークレベルが存在してもよく、およびホットスポットの所有者は、順番に、他のネットワークとのローミング契約を有していても良い3Gネットワークと契約しているプロバイダーとの契約を有していても良いです。
The I-WLAN specification requires that network discovery be performed as specified in the relevant WLAN link layer standards. In addition to network discovery, it is necessary to select intermediary realms to enable construction of source routes. In 3GPP, the intermediary networks are PLMNs, and it is assumed that an access network may have a roaming agreement with more than one PLMN. The PLMN may be a Home PLMN (HPLMN) or a Visited PLMN (VPLMN), where roaming is supported. GSM/UMTS roaming principles are employed for routing AAA requests from the VPLMN to the Home Public Land-based Mobile Network (HPLMN) using either RADIUS or Diameter. The procedure for selecting the intermediary network has been specified in the stage 3 technical specifications [3GPPCT1WLANTS] and [3GPPCT4WLANTS].
I-WLAN仕様は、関連するWLANリンク層規格で指定されたネットワーク検出が実行されている必要があります。ネットワーク発見に加えて、ソースルートの構築を可能にするために、中間レルムを選択する必要があります。 3GPPでは、仲介ネットワークはPLMNのであり、アクセスネットワークが複数のPLMNとのローミング契約を有していてもよいことが想定されます。 PLMNは、ローミングがサポートされているホームPLMN（HPLMN）又は訪問PLMN（VPLMN）であってもよいです。原則ローミングGSM / UMTSは、RADIUSまたはDIAMETERのいずれかを使用して、ホーム公衆陸上モバイルネットワーク（HPLMN）にVPLMNからAAA要求をルーティングするために使用されます。仲介ネットワークを選択するための手順は、ステージ3の技術仕様[3GPPCT1WLANTS]と[3GPPCT4WLANTS]で指定されています。
In order to select the PLMN, the following procedure is required:
PLMNを選択するために、以下の手順が必要です。
o The user may choose the desired HPLMN or VPLMN manually or let the WLAN User Equipment (WLAN UE) choose the PLMN automatically, based on user and operator defined preferences.
Oユーザは、所望のHPLMNまたはVPLMNを手動で選択するか、WLANユーザ機器（WLAN UE）は、ユーザとオペレータ定義のプリファレンスに基づいて、自動的にPLMNを選択できてもよいです。
o AAA messages are routed based on the decorated or undecorated NAI.
O AAAメッセージが飾らや装飾のないNAIに基づいてルーティングされます。
o EAP is utilized as defined in [RFC3748] and [RFC3579].
[RFC3748]及び[RFC3579]で定義されるように、O EAPが利用されます。
o PLMN advertisement and selection is based on [RFC4284], which defines only realm advertisement. The document refers to the potential need for extensibility, though EAP MTU restrictions make this difficult.
O PLMN広告選択のみレルム広告を定義し、[RFC4284]に基づいています。 EAP MTUの制限が、これは困難にかかわらず文書は、拡張性のための潜在的な必要性を指します。
The I-WLAN specification states that "realm hints" are only provided when an unreachable realm is encountered. Where VPLMN control is required, this is handled via NAI decoration. The station may manually trigger PLMN advertisement by including an unknown realm (known as the Alternative NAI) within the EAP-Response/Identity. A realm guaranteed not to be reachable within 3GPP networks is utilized for this purpose.
I-WLAN仕様は、到達不能領域が検出されたときにのみ提供されている「レルムがヒント」と述べています。 VPLMN制御が必要とされる場合、これはNAIデコレーションを経由して処理されます。ステーションは、手動でEAP応答/アイデンティティ以内（代替NAIとして知られる）未知の領域を含むことによってPLMN広告をトリガすることができます。 3GPPネットワーク内到達しないことが保証レルムは、この目的のために利用されます。
The I-WLAN security requirements are described in the 3GPP stage 3 technical specification [3GPPSA3WLANTS]. The security requirements for PLMN selection are discussed in 3GPP contribution [3GPP-SA3-030736], which concludes that both SSID and EAP-based mechanisms have similar security weaknesses. As a result, it recommends that PLMN advertisements should be considered as hints.
I-WLANのセキュリティ要件は、3GPPステージ3技術仕様[3GPPSA3WLANTS]に記載されています。 PLMN選択のためのセキュリティ要件は、SSIDとEAPベースのメカニズムの両方が同様のセキュリティの弱点を持っていると結論3GPP寄与[3GPP-SA3-030736]に記載されています。その結果、それはPLMN広告がヒントとして考慮されるべきであることをお勧めします。
A.4. Other
A.4。他の
[INTELe2e] discusses the need for realm selection where an access network may have more than one roaming relationship path to a home realm. It also describes solutions to the realm selection problem based on EAP, SSID and Protected EAP (PEAP) based mechanisms.
[INTELe2e]アクセスネットワークはホーム領域に複数のローミング関係のパスを持っているかもしれレルム選択の必要性を論じています。また、EAP、SSIDおよび保護されたEAP（PEAP）ベースのメカニズムに基づいて、領域選択の問題に対する解決策を記載しています。
Eijk et al. [WWRF-ANS] discusses the realm and network selection problem. The authors concentrate primarily on discovery of access networks meeting a set of criteria, noting that information on the realm capabilities and reachability inherently resides in home AAA servers, and therefore it is not readily available in a central location, and may not be easily obtained by NAS devices.
Eijkら。 [WWRF-ANS]はレルムとネットワーク選択の問題を論じています。著者は、レルム能力と到達可能性に関する情報は、本質的にホームAAAサーバに存在することを指摘し、一連の基準を満たすアクセスネットワークの発見に主に集中し、そのためには、中央の場所で容易に入手できない、と簡単に得られないことがありNASデバイス。
Appendix B. Acknowledgements
付録B.謝辞
The authors of this document would like to especially acknowledge the contributions of Farid Adrangi, Michael Richardson, Pasi Eronen, Mark Watson, Mark Grayson, Johan Rune, and Tomas Goldbeck-Lowe.
本書の著者は、特にファリドAdrangi、マイケル・リチャードソン、パシEronen、マーク・ワトソン、マーク・グレイソン、ヨハン・ルーン、およびトマスGoldbeck-ロウの貢献を認めたいと思います。
Input for the early versions of this document has been gathered from many sources, including the above persons as well as 3GPP and IEEE developments. We would also like to thank Alper Yegin, Victor Lortz, Stephen Hayes, and David Johnston for comments.
このドキュメントの初期バージョンの入力は、上記の者だけでなく、3GPPおよびIEEE動向を含め、多くの情報源から収集されました。また、コメントをアルパースYegin、ビクターLortz、スティーブン・ヘイズ、およびデビッドジョンストンに感謝したいと思います。
Jouni Korhonen would like to thank the Academy of Finland for providing funding to work on this document.
Jouni Korhonenは、この文書で作業するために資金を提供するためのフィンランドのアカデミーに感謝したいと思います。
Authors' Addresses
著者のアドレス
Jari Arkko Ericsson Jorvas 02420 Finland
ヤリArkkoエリクソン02420 Jorvasフィンランド
EMail: jari.arkko@ericsson.com
メールアドレス：jari.arkko@ericsson.com
Bernard Aboba Microsoft One Microsoft Way Redmond, WA 98052 USA
バーナードAbobaマイクロソフト1マイクロソフト道、レッドモンド、ワシントン98052 USA
EMail: bernarda@microsoft.com
メールアドレス：bernarda@microsoft.com
Jouni Korhonen TeliaSonera Teollisuuskatu 13 Sonera FIN-00051 Finland
Jouni KorhonenテリアソネラSonera産業・ストリート13、FIN-00051、フィンランド
EMail: jouni.korhonen@teliasonera.com
メールアドレス：jouni.korhonen@teliasonera.com
Farooq Bari AT&T 7277 164th Avenue N.E. Redmond WA 98052 USA
ファルークバーリAT＆T 7277第164アベニューN.E.レドモンドWA 98052 USA
EMail: farooq.bari@att.com
メールアドレス：farooq.bari@att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。