[要約] RFC 5113は、ネットワークの発見と選択の問題に関する標準化ドキュメントであり、モバイルデバイスのネットワーク接続の最適化を目的としています。
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つ以上で認証を有効にすることができます。しかし、事前構成がなければ、資格情報が使用可能であるかどうかを判断し、貴重な時間を無駄にし、ユーザーのフラストレーションをもたらすために、各添付ファイルで複数の失敗した認証試行が必要になる可能性があります。複数の添付ファイルポイントを選択するために、正しい資格情報を決定できるように追加情報を提供することが役立ちます。
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 訪問された領域とユーザーのホーム領域の間には複数の潜在的なローミングパスがあり、サービスパラメーターまたは価格設定はそれらの間で異なります。この状況では、ユーザーが同じアイデンティティと資格情報を使用して正常に認証する方法がある可能性がありますが、各アプローチのコストは異なる場合があります。この場合、アクセスネットワークは、ユーザーの好みに最適なローミングパスを決定できない場合があります。これにより、ユーザーが必要以上に請求されるか、目的のサービスを取得しないことになります。たとえば、訪問されたアクセスの領域は、ホームレルムとの直接的な関係と、ローミングコンソーシアムを通じて間接的な関係の両方を持つ可能性があります。現在の認証、承認、および会計（AAA）プロトコルは、ネットワークアクセス識別子（NAI）[RFC4282]内の領域に基づいて純粋に純粋にAAA Severにアクセス要求をルーティングできない場合があります。さらに、ローロードパケットは、ローミング関係パスに基づいて、異なる方法でルーティングまたはトンネルを整えることができます。これは、利用可能なサービスまたはその価格に影響を与える可能性があります。
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では、ネットワークの発見と選択の問題が定義され、サブ問題に分かれています。いくつかのソリューションの制約は、セクション3で概説されています。セクション4では、将来の作業の結論と提案を示します。付録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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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]および直径[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、Universal Mobile Telecommunications System（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.
一部のアクセステクノロジー（UMTなど）の場合、サーキットスイッチまたはパケットスイッチのベアラーのいずれかを使用して、サービス（音声など）を配信する可能性があります。ベアラーの選択とは、サービス提供のためにベアラータイプの1つを選択することを指します。この決定は、デバイスとネットワークによるベアラータイプのサポート、およびユーザーのサブスクリプションとオペレーターの好みに基づいています。
Basic Service Set (BSS)
基本サービスセット（BSS）
A set of stations controlled by a single coordination function.
単一の調整関数によって制御されるステーションのセット。
Decorated NAI
装飾されたnai
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.
同じサービスセット識別子（SSID）と統合ローカルエリアネットワーク（LANS）を備えた1つ以上の相互接続された基本サービスセット（BSSS）のセット。それらのBSSS。これは、ノードが特定のアクセスネットワークから到達可能なネットワークを発見するために使用するメカニズムを指します。
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.
Network Access Server (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）のいずれかを使用する能力としてゆるく定義できますが、1つだけの正式な顧客とベンダーの関係を維持できます。ローミング機能が必要になる場合がある場合の例には、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).
IEEE 802.11を含むデバイスは、ワイヤレス媒体（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.
あるいは、問題を発見、決定、および選択コンポーネントに分けることができます。たとえば、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]は、ローミングアクセス拡張マークアップ言語（XML）ドキュメントタイプ定義（DTD）のIETF提案標準について説明しています。これは、プレゼンスポイント（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.
ビーコンおよびプローブ応答に含まれる情報要素（つまり）の中には、APが接続されているネットワークの非ユニーク識別子であるサービスセット識別子（SSID）があります。したがって、ビーコン/プローブ施設は、ネットワークの発見、アタッチメントポイントの発見とそれらの添付ポイントの能力を可能にします。
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 Working Group（WG）によって開発された候補アクセスルーター発見（カード）[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つの方法は、アクセスネットワークが「仮想アクセスポイント」（仮想APS）をサポートすることです。また、各到達可能なホーム領域に対応する仮想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が複数のチャネルで宣伝され、複数のアクセスメカニズム（Universal Access Method（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.
ネットワークが増殖するにつれて、ユーザーが複数のアイデンティティと資格情報を持っている可能性が高くなり、さまざまな状況で使用できます。たとえば、ユーザーは、1つまたは複数のパブリックWLANプロバイダー、企業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.
通常、ユーザーは、選択された認証メカニズムによって提供される追加の支援を受けて、選択されたネットワークに基づいてIDと対応する資格情報を選択します。たとえば、拡張可能な認証プロトコル - トランスポートレイヤーセキュリティ（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/資格情報セットの間のマッピングは1対1ではない場合があります。たとえば、複数のIDがアクセスネットワークで使用可能であること、または特定のIDが1つのアクセスネットワークで使用可能である可能性があります。
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が使用できない状況を示しています。この場合、Access Network 1は、「ISP1.example.com」の領域内のユーザーへのアクセスを有効にしますが、Access Network 3は、「corp2.example.com」内のユーザーへのアクセスを有効にします。Access Network 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：2つの資格情報、3つの可能なアクセスネットワーク
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」内にIDを所有するユーザーは、ネットワーク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.
場合によっては、認証前に利用可能なアクセスネットワークを決定することはできない場合があります。たとえば、[IEEE.8021X-2004]は、IEEE 802 Wiredネットワークでのネットワーク発見をサポートしていないため、PeerはEAP交換の開始前に接続したアクセスネットワークを決定できません。
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/IDを使用して、サポートされている領域のリストを伝えるために解決しようとする問題です。ただし、付録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.
アイデンティティの選択は、異なる資格情報の選択、および潜在的に異なる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].
IDが選択されたら、AAAインフラストラクチャは、アクセス要求をホームAAAサーバーに戻す必要があります。通常、ルーティングは[RFC4282]で定義されているネットワークアクセス識別子（NAI）に基づいています。
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レルムに基づいて次のホップを決定する静的レルムルーティングテーブルに依存しています。半径内では、Home 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]などのサービス発見プロトコルを含む、ドメイン内およびドメイン間のサービス発見のメカニズムをサポートしています。その結果、直径エージェントの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]に記載されているように、半径プロキシはルーティングの目的でだけでなく、標準化された再送信挙動の欠如やそれぞれの共有秘密のプロビジョニングの必要性など、半径プロトコル設計の多くの不備をマスクするために展開されます。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.
Diameter [RFC3588]は、証明書ベースの認証（TLSまたはIPSECのいずれかを使用）とリダイレクト機能をサポートし、Diameter Clientが直径リダイレクトサーバーからホームサーバーへの紹介を取得できるようにし、クライアントがホームサーバーに直接連絡できるようにすることができます。。信頼モデルを確立できる状況では、これらの直径機能により、ローミング関係パスの長さを減らすことができます。
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は、EAP応答/アイデンティティに含まれる装飾されたNAIをコピーします。アクセスリクエスト。アクセス要求がローミングリレーションシップパスを通過すると、AAAプロキシは、ユーザー名属性内に含まれるレルムに基づいて次のホップを決定し、その過程で、ユーザー名属性に含まれるNAIから装飾を連続的に削除します。対照的に、アクセス要求にカプセル化されたEAP応答/アイデンティティ内に含まれる装飾されたNAIは、触れられないままです。その結果、アクセス要求がAAAホームサーバーに到着すると、EAP応答/IDに含まれる装飾されたNAIは、ユーザー名属性に含まれるNAIとは異なる場合があります（装飾の一部またはすべてが削除されている場合があります）。IDの検証を目的として、EAPサーバーは、EAP応答/IDのNAIではなく、ユーザー名属性で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-to-Unixコピープロトコル（UUCP）やフィドネットなどの代替配信技術との間のゲートウェイが必要でした。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インフラストラクチャ内では使用されていませんが、そのようなプロトコルが導入されたとしても、コアAAAインフラストラクチャ内でのみ展開される可能性がありますが、通常はリソースが制約されるNASデバイスでは展開されません。
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でエンコードされた領域に到達可能かどうかアプリオリを知りません。Accessリクエストを次のホップでローミング関係パスに転送するだけです。最終的に、アクセス要求は「デフォルトのフリー」ゾーンに到達します。このゾーンでは、コアAAAプロキシが領域に到達可能かどうかを決定します。EAP認証が使用されている[RFC4284]で説明されているように、コアAAAプロキシはアクセス拒否を送信するか、「レルムヒント」を含むEAP-Request/IDをカプセル化するアクセスチャレンジを送信することができます。「デフォルトの無料」レルムルーティングテーブル。
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-Request/IDパケット内に収まる場合でも、コアAAAルーターはすべてのエントリを含めることを選択できない場合があります。ネットワークアクセスを求めているホスト。したがって、EAP-Request/Identityに含まれる「レルムヒント」のリストが完全であるとは想定していません。これを考えると、NASまたはローカルAAAプロキシをスヌーピングしているEAP-Request/IDは、到達可能な領域の完全なリストを提供するためにそれに依存することはできません。[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.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を介したアクセスよりも安価になる可能性があり、その結果、「A」の領域を持つ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.
Realm Routeが存在する場合、または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]で述べたように、動的に更新できるパラメーターの数は限られています。たとえば、サービスの品質または価格設定情報は通常、継続的に更新されるのではなく、Webで事前に生成または利用可能になります。レルム名が動的に伝達される場合、このテーブルが非常に大きくなる可能性があるため、「デフォルトの無料」レルムリストが完全に提供される可能性は低いです。情報の可用性に対する制約を考えると、通常、ソースルートの構築は、不完全な知識に直面して発生する必要があります。
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インフラストラクチャによって尊重されているかどうかを監査するメカニズムはほとんどありません。たとえば、アクセスネットワークは「Costless.example.com」へのレルムルートを宣伝することができ、代わりに「Costmore.example.com」を介してアクセスリケストをルーティングします。装飾されたNAIは、EAP応答/アイデンティティでホームAAAサーバーで利用可能になりますが、ホームAAAサーバーは、装飾されたNAIで要求されたソースルートが実際にAAAインフラストラクチャによって表彰されたことを確認するのに苦労するかもしれません。同様に、サービス品質（QO）または他のルーティングリクエストが実際に要求されているように提供されたかどうかを判断することは困難です。ある程度、この問題は、ローミングパートナー間のビジネスアレンジメントの一部として対処される場合があり、最小限のサービスレベルの保証を提供する可能性があります。
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（拡張可能な認証プロトコル - サブスクライバーIDモジュール）を使用して、ホームネットワークに認証するのではなく、アクセスネットワークに直接認証できる場合があります。
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、および添付ファイルのポイントを選択しました。認証プロセス中にそれらの決定の1つ以上を改訂する原因となる情報を学習する場合、ノードは新しいネットワーク、添付ポイント、および/または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 選択認識クライアントは、Legacy 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.
たとえば、選択対象のクライアントは、Legacy 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インフラストラクチャの両方に帯域幅を制約することができます。その結果、Keepaliveや定期的なプローブパケットなどのチャットメカニズムを避けます。AAAサーバーが処理するボリュームを考えると、ソリューションは、特にこれがサービス拒否攻撃を可能にする場合に、負荷に追加することを意識する必要があります。たとえば、NASが[RFC4284]に記載されているように「レルムヒント」を取得するために、Probe-Response/IdentityパケットをAAAインフラストラクチャに定期的に送信することにより、更新されたレルムルーティングテーブルを取得しようとすることは悪い考えです。これにより、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」ごとに個別のビーコンを使用するアプローチは、宣伝されているネットワークの数に比例して追加のビーコンを導入します。このようなアプローチは、ネットワークアクセスクライアントに必要な事前構成を最小限に抑える可能性がありますが、「仮想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ビーコン/秒）のビーコン間隔では、170オクテットの独自のビーコンを発表する2082.11b「仮想AP」の結果、37.9％のチャネル利用が得られます。計算は次のように検証できます。
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 US（1 Mbps @ 1 Mbps @ 1 Mbps）にチャネルを利用します。
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. 物理層収束手順（PLCP）の長いプリアンブル（144ビット @ 1 Mbps）、PLCPヘッダー（48ビット @ 1 Mbps）の48 US、短いフレーム間スペース（SIF）の10米、50米国の米国を追加してください。バックオフなしの平均最小競合ウィンドウ（CWMIN/2 * ASLOTTIME = 32/2 * 20 US）の分散インターフレームスペース（DIFS）および320 USは、単一のビーコンが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 US/second = 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が近隣APの機能と独自の[IEEE.802.11K]の機能を発表できるようにすることが含まれます。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で説明されているメカニズムを介して無慈悲なピアにそれを提供することを望まないかもしれません。これは、認証者が1つを選択することで、このアプローチがプライバシーの懸念を引き起こすことをサポートします。認証の前にアイデンティティの選択が発生するため、ピアのサポートされている領域はクリアテキストで送信され、攻撃者が潜在的な被害者が資格情報を持っている領域を決定できるようになります。このリスクは、ピアの開示を制限することにより緩和できます。たとえば、ピアは、最初に選択されたアイデンティティが使用できない状況で追加の領域を開示する場合があります。
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.
実際には、Authenticatorが「パススルー」モードで動作する場合、EAPメソッドネゴシエーションはEAPピアとサーバーの間で発生するため、ピアは単一のEAPメソッドを特定のEAPサーバーに関連付ける必要があります。複数のEAPサーバーと対応するアイデンティティが同じ選択したネットワークから到達可能になる場合がある場合、EAPピアは、どのID（および対応するEAPメソッド）を使用するかを決定するのが困難な場合があります。安全なアソシエーションプロトコルハンドシェイク内で安全に確認される可能性のあるネットワーク選択とは異なり、EAP-Request/Identity内で提供されるID選択のヒントは確保されていません。
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メソッドに対応するIDを選択するよう説得することができます（例えば、EAP MD5-Challenge）。このリスクを軽減する1つの方法は、ピアが[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ルーティングは、同じ問題の側面、つまりID選択です。
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.
o IEEE 802、IETF、および第3世代パートナーシッププロジェクト（3GPP）内のネットワークディスカバリーテクノロジーの拡散は、今後重要な問題になる可能性があります。統一されたアプローチがなければ、複数の非挿入性溶液を展開することができます。
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 既存のリンクレイヤー上のLegacy 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]や[Velayos]などの研究、およびセクション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.
IEEE 802.11aなどの後継者により、追加のチャネルを可能にする状況により、状況は大幅に改善され、潜在的な仮想APの数が増加する可能性があります。
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.
o IEEE 802.11k [IEEE.802.11K]は近隣レポートのサポートを提供しますが、これは他のリンクレイヤーをサポートする添付ファイルのポイントではなく、近隣の802.11 APの情報の収集のみを提供します。この問題の解決策は、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-Request/ Identityパケットの断片化をサポートしていないことを考えると、これらのパケットに適合できる「レルムヒント」のボリュームは限られています。さらに、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.
検討する価値のある高層の代替品には、IPよりもネットワークデバイス機能の広告を可能にするSeamoby Card Protocol [RFC4066]、および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-kikev2 [IKEV2]などのEAPメソッドは、これを可能にする可能性があります。古いメソッド[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.
ネットワーク選択のセキュリティ要件は、選択がマンデートまたはヒントと見なされるかどうかによって異なります。一般に、ネットワーク広告をヒントとして扱うことは、Forgedネットワーク広告に対するアクセスクライアントの脆弱性を減らすため、より安全なアプローチです。たとえば、「Realm Hints」は、選択したアクセスネットワークに対応するセキュリティポリシーと互換性がない場合、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 Accessクライアントがアクセスネットワーク内で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.
たとえば、攻撃者はネットワーク広告を吹き込み、広告されたセキュリティ機能を格下げする可能性があります。Rogueアクセスポイントは、安全でない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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、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] Riegel、M。およびG. Zorn、「Roaming Access Phone Bookの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.、Blunk、L.、Vollbrecht、J.、Carlson、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. Moore、「ポイントツーポイントプロトコル（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.、Polk、W.、Ford、W.、およびD. Solo、「インターネット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.、Hiller、T。、およびG. Zorn、「直径拡張可能な認証プロトコル（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. Calhoun、「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.、Lu、J.、Alsop、J.、Ding、J.、およびW. Wang、「Review of Roaming Exprentations」、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] Guttman、E.、Perkins、C.、Veizades、J。、およびM. Day、「サービスロケーションプロトコル、バージョン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.、Smith、A.、Zorn、G。、およびJ. Roese、「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.、Bari、F.、およびP. Eronen、「拡張可能な認証プロトコル（EAP）のアイデンティティ選択ヒント」、RFC 4284、2006年1月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017] Stanley、D.、Walker、J。、およびB. Aboba、「ワイヤレスLANSの拡張可能な認証プロトコル（EAP）メソッド要件」、RFC 4017、2005年3月。
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[RFC4066] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, "Candidate Access Router Discovery (CARD)", RFC 4066, July 2005.
[RFC4066] Liebsch、M.、Singh、A.、Chaskar、H.、Funato、D。、およびE. Shim、「候補アクセスルーター発見（カード）」、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.、Ohba、Y.、およびF. Bersani、「EAP-kikev2 Method」、Progress、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.、Berg、S.、Tschofenig、H。、およびM. Ness、「ネットワーク選択実装の結果」、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.、Simon、D.、Salowey、J.、Zhou、H.、Zorn、G。、およびS. Josefsson、 "Protected EAP Protocol（PEAP）バージョン2"、2004年10月の作業。
[MARQUES] Enns, R., Marques, P., and D. Morrell, "Device Discovery Protocol (DDP)", Work in Progress, May 2003.
[Marques] Enns、R.、Marques、P。、およびD. Morrell、「Device Discovery Protocol（DDP）」、2003年5月の作業。
[OHBA] Taniuchi, K., Ohba, Y., and D. Subir, "IEEE 802.21 Basic Schema", Work in Progress, October 2007.
[Ohba] Taniuchi、K.、Ohba、Y。、およびD. Subir、「IEEE 802.21 Basic Schema」、2007年10月の作業。
[IEEE.802.11-2003] IEEE, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 2003.
[Fixingapsel] Judd, G. and P. Steenkiste, "Fixing 802.11 Access Point Selection", Sigcomm Poster Session 2002.
[Fixingapsel] Judd、G。およびP. Steenkiste、「Fixing 802.11アクセスポイント選択」、Sigcommポスターセッション2002。
[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、「システム間の電気通信および情報交換のための標準の草案 - 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、「情報技術の標準へのアメムメントのドラフト - システム間の通信と情報交換 - 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、「ワイヤレスネットワークセキュリティにおける認可の役割」、2004年11月のDiMacsワークショップで提示された拡張要約。
[IEEE.11-04-0624] Berg, S., "Information to Support Network Selection", IEEE Contribution 11-04-0624 2004.
[IEEE.11-04-0624] Berg、S。、「ネットワーク選択をサポートするための情報」、IEEE貢献11-04-0624 2004。
[Priest04] Priest, J., "The State of Wireless London", July 2004.
[司祭04]司祭J。、「ワイヤレスロンドンの状態」、2004年7月。
[MACScale] Heusse, M., "Performance Anomaly of 802.11b", LSR-IMAG Laboratory, Grenoble, France, IEEE Infocom 2003.
[MacScale] Heusse、M。、「802.11bのパフォーマンス異常」、LSR-IMAG Laboratory、Grenoble、France、IEEE Infocom 2003。
[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.
[Velayos] Velayos、H。and G. Karlsson、「IEEE 802.11b MACレイヤーハンドオーバータイムを削減する技術」、通信ネットワーク研究所、KTH、ロイヤルインスティテュート、ストックホルム、スウェーデン、TRITA-IMIT-LCN R 03:02、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] Hepworth、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-Requirements] Moreton、M。、「TGU要件」、IEEE貢献11-05- 0822-03-000U-TGU-Requirements、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、「3GPPシステムからワイヤレスローカルエリアネットワーク（WLAN）インターワーキング、System De 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環境でのアクセスネットワーク選択とターミナルおよびサービスプラットフォームの役割」、10th 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 Communications Magazine、2003年11月。
[INTELe2e] Intel, "Wireless LAN (WLAN) End to End Guidelines for Enterprises and Public Hotspot Service Providers", November 2003.
[Intele2e] Intel、「ワイヤレスLAN（WLAN）エンドツーエンドツーエンドガイドラインおよびエンタープライズおよびパブリックホットスポットサービスプロバイダーのガイドライン」、2003年11月。
[Eronen03] Eronen, P., "Network Selection Issues", presentation to EAP WG at IETF 58, November 2003.
[Eronen03] Eronen、P。、「ネットワーク選択の問題」、2003年11月、IETF 58での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、「3GPPシステムからワイヤレスローカルエリアネットワーク（WLAN）インターワーキング、ユーザー機器（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.
[3GPPCT4WLANTS] 3GPP、「3GPPシステムからワイヤレスローカルエリアネットワーク（WLAN）インターワーキング、ステージ3（リリース6）」、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 Standard 802.1x、2004年7月。
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 WGSなど、ネットワーク選択問題の側面を扱っています。
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は、適切なベースステーションの発見を支援するカード[RFC4066]を開発しました。PKIX WGは[RFC3280]を生成し、証明書の選択の問題に対処します。AAA WGは、直径内でより洗練されたアクセスルーティング、認証、およびサービス発見メカニズムを開発しました[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 et al。[RFC4284]は、EAP-Request/IDの使用を定義して、アイデンティティ選択に役立つ「レルムヒント」を提供します。[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-Request/IDの使用に基づく広告メカニズムには、スケーラビリティの問題があります。[RFC3748]セクション3.1に記載されているように、最小EAP最大透過ユニット（MTU）は1020オクテットであるため、EAP-Request/IDは、タイプデータフィールドに1015オクテットを含めることができるように保証されます。RFC 1035 [RFC1035]により、完全に認定されたドメイン名（FQDN）が最大255オクテットの長さであるため、多くの領域の発表を可能にしない可能性があります。ドメイン名以外のネットワーク識別子の使用も可能です。
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 AP prior to sending an EAPOL-Start to initiate EAP (here, EAPOL refers to EAP over LAN). This will dramatically increase handoff latency.
[Eronen03]で述べたように、領域発見のためにEAP-Request/IDの使用は、ハンドオフレイテンシに大きな悪影響を及ぼします。 - どの領域がサポートされているかを説明するレクエスト/アイデンティティ。IEEE 802.11-2003は、拡張サービスセット（ESS）内の状態1（認可されていない、それに関連しない）でのクラス1データフレームの使用をサポートしていないため、これはAPSが802.1xの事前認証をサポートする必要があることを意味します（IEEE 802.11iでオプション-2004）、またはEAPを開始するためにEapol-Startを送信する前に、ステーションが各APに関連付けなければならないこと（ここでは、EapolはLANを超えるEAPを参照します）。これにより、ハンドオフの遅延が劇的に増加します。
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プロキシによって「レルムヒント」を送信できるようにすることがおそらく最善です。このようにして、Naseが「レルムヒント」を送信する必要はありません。これには、既存の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が宣伝したレルムリストに自動的に反映されません。その結果、NASによって宣伝されている領域は、実際には到達可能ではないかもしれません。または、NASが到達可能な1つ以上の領域を宣伝することを怠るかもしれません。これにより、複数のEAPアイデンティティ交換が行われる可能性があり、NASが提供する「レルムヒント」の最初のセットは、その後、コアAAAプロキシによって提供される「レルムヒント」によって更新されます。一般に、コアAAAプロキシでの「レルムヒント」は、「運命共有」を提供するため、より健全なアプローチであるように見えます。ヒントに基づいてリクエストをルーティングします。このアプローチは、コアAAAプロキシのみを更新する必要があるため、管理の観点からも優先されます。NASデバイスには更新は必要ありません。
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レイヤーのパフォーマンスの問題が特定されており、[Velayos]は、ビーコン間隔の低下によるスケーリングの問題を特定しました。
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] WLANの認証モデルの進化と、EAP層の適応症に基づいて、またはSSIDを使用してローカル以上のものを表すために、ネットワークが既存のモデルから新しいモデルに移行する必要性について説明します。通信網。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」がMACおよびIPレイヤーに異なる物理APに表示されます。論文で述べたように、既存の802.11ステーションの実装との完全な互換性は、各「仮想AP」がビーコンおよびプローブ応答で使用するために異なるMacアドレス（BSSID）を使用している場合にのみ維持できます。このホワイトペーパーでは、スケーリングの問題について詳しく説明していませんが、限られた数の「仮想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-Requirements] [IEEE.802.11U]。これには、ステーションがそのネットワークに関連する前に、アクセスネットワークへの認証に使用できるアイデンティティを決定できるようにするメカニズムが含まれます。前述のように、この問題を解決するには、APが最新の「デフォルトの無料」レルムルーティングテーブルを維持する必要があります。同様に、ホームレルム（登録など）でサポートされている機能の先験的な発見も、動的ルーティングをサポートしないスケーラブルな方法で実装することも困難です。ネットワーク機能（QoSサポートなど）の決定は、AP内に含まれるハードウェアとソフトウェアのみに依存するため、非常に簡単です。ただし、802.11Uはジェネリック広告サービス（GAS）メカニズムに取り組んでおり、802.21情報サービス（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とレイヤー3の両方に関連する情報を含むネットワーク選択を支援する情報要素（IES）を開発しています。クエリメカニズム（XMLとTLVの両方のサポートを含む）も開発中です。IEEE 802.21は、クエリ言語（つまり、SPARQL）の使用を許可するリソース説明フレームワーク（RDF）スキーマも定義しています。スキーマはIEEE 802.21の規範的な部分であり、[OHBA]でも定義されています。
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]は、3GPPインターワーキングWLAN（I-WLAN）のアーキテクチャを2Gおよび3Gネットワークとカバーしています。この仕様では、レルムの発見とネットワークの選択の問題についても説明しています。I-Wlan Realm Discovery Procedureは、「PLMN選択」として知られるCellular Public Land Mobile Network（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リストは、サブスクライバーIDモジュール（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 Roamingによって導入された新しい領域（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ローミング原則は、半径または直径を使用して、VPLMNから自宅の公共陸上モバイルネットワーク（HPLMN）への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].
o EAPは、[RFC3748]および[RFC3579]で定義されているように使用されます。
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選択のセキュリティ要件は、3GPP貢献[3GPP-SA3-030736]で議論されており、SSIDベースのメカニズムとEAPベースのメカニズムの両方が同様のセキュリティの弱点を持っていると結論付けています。その結果、PLMN広告をヒントと見なす必要があることを推奨しています。
[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 et al。[WWRF-ANS]領域とネットワークの選択の問題について説明します。著者は、主に一連の基準を満たすアクセスネットワークの発見に集中しており、レルムの能力と到達可能性に関する情報は本質的にホームAAAサーバーに存在するため、中央の場所で容易に入手できず、簡単に取得できない場合があります。NASデバイス。
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.
この文書の著者は、ファリド・アドランギ、マイケル・リチャードソン、パシ・エロネン、マーク・ワトソン、マーク・グレイソン、ヨハン・ルーン、トマス・ゴールドベック・ローの貢献を特に認めたいと考えています。
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開発など、多くのソースから収集されています。また、コメントについては、Alper Yegin、Victor Lortz、Stephen Hayes、David Johnstonに感謝します。
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
Jari Arkko Ericsson Jorvas 02420フィンランド
EMail: jari.arkko@ericsson.com
Bernard Aboba Microsoft One Microsoft Way Redmond, WA 98052 USA
バーナード・アボバ・マイクロソフト・ワン・マイクロソフト・ウェイ・レドモンド、ワシントン州98052 USA
EMail: bernarda@microsoft.com
Jouni Korhonen TeliaSonera Teollisuuskatu 13 Sonera FIN-00051 Finland
Jouni Korhonen Teliasonera Teollisuuskatu 13 Sonera Fin-00051 Finland
EMail: jouni.korhonen@teliasonera.com
Farooq Bari AT&T 7277 164th Avenue N.E. Redmond WA 98052 USA
FAROOQ BARI AT＆T 7277 164th Avenue N.E.レドモンドWA 98052 USA
EMail: farooq.bari@att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。