RFC5113 日本語訳
5113 Network Discovery and Selection Problem. J. Arkko, B. Aboba, J.Korhonen, Ed., F. Bari. January 2008. (Format: TXT=93250 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Arkkoがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5113年のエリクソンカテゴリ: 情報のB.AbobaマイクロソフトJ.Korhonen、エドTeliaSonera F.バリAT&T2008年1月
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.
複数のアクセスネットワークが利用可能であるときに、どのネットワークに接続するか、そして、それでどのようにネットワークを認証するかを選択する際にユーザは苦労するかもしれません。 このドキュメントはネットワーク発見と選択問題を定義します、それを複数のサブ問題に分割して。潜在的ソリューションにおけるいくつかの規制が概説されています、そして、いくつかのソリューション(既存のものを含んでいる)の制限について議論します。
Arkko, et al. Informational [Page 1] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[1ページ]のRFC5113ネットワーク発見とSP2008年1月
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 用語は本書では.4 2を使用しました。 問題定義. . . . . . . . . . . . . . . . . . . . . . 7 2.1。 ポイントの付属. . . . . . . . . . . . 8 2.2の発見。 アイデンティティ選択. . . . . . . . . . . . . . . . . . . . 9 2.3。 AAAルート設定. . . . . . . . . . . . . . . . . . . . . . . 11 2.3.1。 デフォルト自由地帯. . . . . . . . . . . . . . . . 13 2.3.2。 選択と方針. . . . . . . . . . . . . . 14 2.3.3を発送してください。 ソースルート設定. . . . . . . . . . . . . . . . . . . . 15 2.4。 .173に能力発見をネットワークでつないでください。 問題. . . . . . . . . . . . . . . . . . . . . . . . 18 3.1を設計してください。 AAAルート設定. . . . . . . . . . . . . . . . . . . . . . . 18 3.2。 後方の互換性. . . . . . . . . . . . . . . . . . 18 3.3。 効率規制. . . . . . . . . . . . . . . . . . 19 3.4。 スケーラビリティ. . . . . . . . . . . . . . . . . . . . . . . 19 3.5。 ダイナミックな発見. . . . . . . . . . . . . 21 3.6に対して静的です。 セキュリティ. . . . . . . . . . . . . . . . . . . . . . . . . 21 3.7。 管理. . . . . . . . . . . . . . . . . . . . . . . . 22 4。 結論. . . . . . . . . . . . . . . . . . . . . . . . . 23 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 25 6。 有益な参照. . . . . . . . . . . . . . . . . . . . 26付録A.存在仕事. . . . . . . . . . . . . . . . . . . . 32A.1。 IETF. . . . . . . . . . . . . . . . . . . . . . . . . . . 32A.2。 IEEE802.33A.3。 3GPP. . . . . . . . . . . . . . . . . . . . . . . . . . . 35A.4。 他の.36の付録B.承認. . . . . . . . . . . . . . . . . . 37
Arkko, et al. Informational [Page 2] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[2ページ]のRFC5113ネットワーク発見とSP2008年1月
1. Introduction
1. 序論
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 ただ一つのネットワークの中では、1つ以上のネットワーク付着点が利用可能です、そして、付着点は彼らのローミングアレンジメント、またはサービスへのアクセスにおいて異なります。 接着点のリンクレイヤ能力が広告に掲載されているかもしれない間、ローミングアレンジメントなどの、より高い層の能力(終わりから終わりへのサービスの質、またはインターネット・アクセス制限)は、ないかもしれません。 その結果、それぞれのネットワーク付着点とそれが首尾よくどの付着点を認証できるかでサービスがどれに利用可能であるかを決定するのにユーザは苦労するかもしれません。 例えば、ローミング協定が他のものではなく、付属の諸点からホーム分野に認証するユーザを可能にするだけであるのは、可能です。 同様に、インターネットへのアクセスが他のものではなく、付属の諸点で制限されるかもしれないか、または終わりから終わりへのサービスの質がすべての位置で利用可能でないことが、可能です。 これらの状況で、ネットワークアクセスクライアントは、ネットワークの中のすべてのポイントの付属が同じ能力を提供すると仮定できません。
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 複数のネットワークがユーザが構成プレ対応するようにしないものに利用可能です。 ユーザは使用のためにネットワークでアイデンティティと関連資格証明書をあらかじめ構成していないかもしれません、しかし、ユーザのホーム分野がそのネットワークから届いていて、可能にするのが首尾よく認証するユーザであることは可能です。 しかしながら、ローミングアレンジメントが広告に掲載されない場合、ネットワークアクセスクライアントは、うまくいっている認証がありそうであるかどうかと先験的に決心できません。 この状況で、ユーザが、それが首尾よく認証できるものに1つを見つけるのに複数のネットワークを試みる必要がないか、またはユーザが全くアクセスを得ることができるのが、可能でないことが、可能です、うまくいっている認証は可能ですが。
Arkko, et al. Informational [Page 3] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[3ページ]のRFC5113ネットワーク発見とSP2008年1月
o The user has multiple sets of credentials. Where no pre-
configuration exists, it is possible that the user will not be
able to determine which credentials to use with which attachment
point, or even whether any credentials it possesses will allow it
to authenticate successfully. An identity and associated
credentials can be usable for authentication with multiple
networks, and not all of these networks will be pre-configured.
For example, the user could have one set of credentials from a
public service provider and another set from an employer, and a
network might enable authentication with one or more of these
credentials. Yet, without pre-configuration, multiple
unsuccessful authentication attempts could be needed for each
attachment point in order to determine what credentials are
usable, wasting valuable time and resulting in user frustration.
In order to choose between multiple attachment points, it can be
helpful to provide additional information to enable the correct
credentials to be determined.
o ユーザには、複数のセットの資格証明書があります。 プレ構成が全く存在していないところでは、それは、首尾よく認証するのにおいてユーザが、どの付着点と共にどの資格証明書を使用するか、そして、または何かそれが持っている資格証明書がそれを許容さえするかどうか決定できないのが可能です。 認証に、アイデンティティと関連資格証明書は複数のネットワークと共に使用可能である場合があります、そして、これらのネットワークのすべてがあらかじめ設定されるというわけではないでしょう。 例えば、ユーザは雇い主から社会奉仕プロバイダーともう1セットからの1セットの資格証明書を持つことができました、そして、ネットワークはこれらの資格証明書の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 訪問された分野と、ユーザのホーム分野と、サービスパラメタの間には、複数の潜在的ローミング経路があるか、または価格設定はそれらの間で異なります。 この状況に、ユーザが首尾よく同じアイデンティティを使用して、資格証明書を認証する複数の方法があるかもしれません、しかし、それぞれのアプローチの費用は異なるかもしれません。 この場合、アクセスネットワークはユーザの好みに最もよく合っているローミング経路を決定できないかもしれません。 これは十二分に必要な状態で請求されるか、または必要なサービスを得ないことであるユーザに通じることができます。 例えば、訪問されたアクセス分野はローミング共同体を通してホーム分野との直接の因果関係と間接的な関係の両方を持つことができました。 現在のAuthentication、Authorization、およびAccounting(AAA)プロトコルはホームAAAへのアクセス要求がNetwork Access Identifier(NAI)[RFC4282]の中の分野に基づいて純粋に断ち切るルートにできないかもしれません。 さらに、ローミング関係経路に基づいてペイロードパケットに異なって発送するか、またはトンネルを堀ることができます。 これは営業品目か彼らの価格設定に影響を与えるかもしれません。
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は問題の部分と既存のソリューションについて議論します。
1.1. Terminology Used in This Document
1.1. 本書では使用される用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Arkko, et al. Informational [Page 4] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[4ページ]のRFC5113ネットワーク発見とSP2008年1月
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プロトコルは中のRemote Authentication Dial User Service(RADIUS)[RFC3579]とDiameter[RFC4072]を含んでいます。
Access Point (AP)
アクセスポイント(AP)
An entity that has station functionality and provides access to
distribution services via the wireless medium (WM) for associated
stations.
関連ステーションへのワイヤレスの媒体(WM)で、ステーションの機能性を持って、配布サービスへのアクセスを提供する実体。
Access Technology Selection
アクセス技術選択
This refers to the selection between access technologies, e.g.,
802.11, Universal Mobile Telecommunications System (UMTS), WiMAX.
The selection will be dependent upon the access technologies
supported by the device and the availability of networks
supporting those technologies.
WiMAX、これは例えば、アクセス技術、802.11、UniversalのモバイルTelecommunications System(UMTS)の間の選択を示します。 選択はデバイスによってサポートされたアクセス技術とそれらの技術をサポートするネットワークの有用性に依存するようになるでしょう。
Bearer Selection
運搬人選択
For some access technologies (e.g., UMTS), there can be a
possibility for delivery of a service (e.g., voice) by using
either a circuit-switched or packet-switched bearer. Bearer
selection refers to selecting one of the bearer types for service
delivery. The decision can be based on support of the bearer type
by the device and the network as well as user subscription and
operator preferences.
いくつかのアクセス技術(例えば、UMTS)のために、回路で切り換えられたかパケットで切り換えられた運搬人を使用するのによるサービス(例えば、声)の配送のための可能性があることができます。 運搬人選択はサービス配送のための運搬人タイプのひとりを選択するのを示します。 決定はユーザ購読とオペレータ好みと同様にデバイスとネットワークによる運搬人タイプのサポートに基づくことができます。
Basic Service Set (BSS)
基本サービスはセットしました。(BSS)
A set of stations controlled by a single coordination function.
1セットのステーションはただ一つのコーディネート機能によって制御されました。
Decorated NAI
飾り付けをされたNAI
A NAI specifying a source route. See Section 2.7 of RFC 4282
[RFC4282] for more information.
送信元経路を指定するNAI。 詳しい情報に関してRFC4282[RFC4282]のセクション2.7を見てください。
Extended Service Set (ESS)
拡張サービスはセットしました。(ESS)
A set of one or more interconnected basic service sets (BSSs) with
the same Service Set Identifier (SSID) and integrated local area
networks (LANs), which appears as a single BSS to the logical link
control layer at any station associated with one of those BSSs.
This refers to a mechanism that a node uses to discover the
networks that are reachable from a given access network.
1つ以上のインタコネクトされた基本サービスのセットは同じService Set Identifier(SSID)と統合ローカル・エリア・ネットワーク(LAN)がある(BSSs)を設定します。(どんなステーションの論理的なリンク制御層への独身のBSSもそれらのBSSsの1つと交際したので、それは、現れます)。 これはノードが与えられたアクセスネットワークから届いているネットワークを発見するのに使用するメカニズムを示します。
Arkko, et al. Informational [Page 5] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[5ページ]のRFC5113ネットワーク発見とSP2008年1月
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 Identifier(NAI)[RFC4282]はネットワークアクセス認証の間にクライアントによって提出されたユーザアイデンティティです。 ローミングでは、NAIの目的は、ユーザを特定して、認証要求のルーティングを助けることです。 ユーザのEメールアドレスかユーザアイデンティティが応用層認証で提出したようにNAIは必ず同じであるかもしれないというわけではありません。
Network Access Server (NAS)
ネットワークアクセス・サーバー(NAS)
The device that peers connect to in order to obtain access to the
network. In Point-to-Point Tunneling Protocol (PPTP) terminology,
this is referred to as the PPTP Access Concentrator (PAC), and in
Layer 2 Tunneling Protocol (L2TP) terminology, it is referred to
as the L2TP Access Concentrator (LAC). In IEEE 802.11, it is
referred to as an Access Point (AP).
同輩がネットワークへのアクセスを得るために接続するデバイス。 PointからポイントへのTunnelingプロトコル(PPTP)用語で、これはPPTP Access Concentrator(PAC)と呼ばれます、そして、Layer2Tunnelingプロトコル(L2TP)用語で、それはL2TP Access Concentrator(LAC)と呼ばれます。 IEEE802.11では、それはAccess Point(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)の選択は以前はよくネットワークにアクセスしていました。 分野は1つ以上のアクセスネットワークタイプから届く場合があります、そして、分野の選択はネットワーク能力を可能にしないかもしれません。
Arkko, et al. Informational [Page 6] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[6ページ]のRFC5113ネットワーク発見とSP2008年1月
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.
1だけとの正式な顧客ベンダー関係を維持している間、緩く複数のインターネットサービスプロバイダ(ISP)のどれかを使用する能力とローミング能力を定義できます。 ローミング能力が必要であるかもしれないケースに関する例はISP「同盟者」とISPに提供された企業ネットワークアクセスサポートを含んでいます。
Station (STA)
駅(STA)
A device that contains an IEEE 802.11 conformant medium access
control (MAC) and physical layer (PHY) interface to the wireless
medium (WM).
IEEE802.11conformant媒体アクセス制御(MAC)を含むデバイスと物理的な層(PHY)はワイヤレスの媒体(WM)に連結します。
2. Problem Definition
2. 問題定義
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ルーティング。 これはAAAの会話のルーティングにホームAAAサーバにかかわって戻します、選択されたNAIの分野に基づいて。
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ルーティング問題はすべてのコンポーネントにかかわります: 発見(その仲介ネットワークは利用可能である)、決定(1つを「最もよく」選ぶ)、および選択(どの仲介ネットワークを使用したらよいかを選択する)コンポーネント。
Arkko, et al. Informational [Page 7] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[7ページ]のRFC5113ネットワーク発見とSP2008年1月
2.1. Discovery of Points of Attachment
2.1. ポイントの付属の発見
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.
RFC2194[RFC2194]はダイヤルアップローミングクライアントのプレの食糧を供給することについて説明します。(そのクライアントは、クライアントが契約上の関係を持っていたプロバイダーによってアップデートされた潜在的電話番号のリストを通常含んでいました)。 RFC3017[RFC3017]はRoaming Access eXtensible Markup Language(XML)ドキュメントType Definition(DTD)のためにIETF Proposed Standardについて説明します。 これは、特定のPoPと共に使用されるためにPresence(PoP)とインターネットサービスプロバイダ(ISP)のPointsの属性だけではなく、ヒントも適切な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.
アクセスネットワークと付属のポイントが増殖するのに従って、バンドの外では、プレ構成はいよいよ困難になりました。 多くのポイントの付属のネットワークにおいて、ポイントの付属のaを完全に保って、日付までのリストは難しい場合があります。 その結果、ワイヤレス・ネットワークのアクセスクライアントは、個々のポイントの付属よりむしろアクセスネットワークに関連する情報をあらかじめ構成するのを通常試みるだけです。
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.
IEEE802.11Wirelessローカル・エリア・ネットワーク(WLAN)に、BeaconとProbe Request/反応機構は駅がAccess Points(AP)を発見する方法とそれらのAPsの能力を提供します。 IEEE802.11仕様[IEEE.802.11-2003]は受動態(標識)とアクティブな(Request/応答を調べる)発見メカニズムの両方のサポートを提供します。 [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.
情報の中では、BeaconとProbe Responseの中にElements(IE)を含むのは、Service Set Identifier(SSID)です、APが付けているネットワークの非ユニークな識別子。 したがって、Beacon/徹底的調査施設はネットワーク発見を可能にします、ポイントの付属の発見とそれらのポイントの付属の能力と同様に。
The Global System for Mobile Communications (GSM) specifications also provide for discovery of points of attachment, as does the Candidate Access Router Discovery (CARD) [RFC4066] protocol developed by the IETF SEAMOBY Working Group (WG).
また、汎欧州デジタルセルラーシステム(GSM)仕様はポイントの付属の発見に備えます、IETF SEAMOBY作業部会(WG)によって開発されたCandidate Access Routerディスカバリー(CARD)[RFC4066]プロトコルのように。
Along with discovery of points of attachment, the capabilities of access networks are also typically discovered. These may include:
また、ポイントの付属の発見と共に、アクセスネットワークの能力は通常発見されます。 これらは以下を含むかもしれません。
Arkko, et al. Informational [Page 8] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[8ページ]のRFC5113ネットワーク発見とSP2008年1月
o Access network name (e.g., IEEE 802.11 SSID)
o アクセスネットワーク名(例えば、IEEE802.11SSID)
o Lower layer security mechanism (e.g., IEEE 802.11 Wired Equivalent
Privacy (WEP) vs. Wi-Fi Protected Access 2 (WPA2))
o 下層セキュリティー対策(例えば、IEEE802.11WEP(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つの方法は、アクセスネットワークが、「仮想のAccess Points」が(仮想のAPs)であるとサポートして、各接着点がそれぞれの届いているホーム分野に対応する仮想のAPsをサポートすることです。
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.
独身のIEEE802.11ネットワークが独身のSSIDを利用しているだけであるかもしれない間、広い地理的な領域をカバーするかもしれません、そして、その結果、区分されるかもしれません、複数の接頭語を利用して。 独身のSSIDが、複数のチャンネルの上に広告を出すかもしれなくて、複数のアクセスが付属のポイントの間で異なるかもしれないメカニズム(Universal Access Method(UAM)とIEEE 802.1X[IEEE.8021X-2004]を含んでいる)であるとサポートするのは、可能です。 独身のSSIDはまた、[RFC3580]で説明されるようにダイナミックなVLANがアクセスであるとサポートするか、または異なった分野をサポートする複数のホームAAAサーバに認証をサポートするかもしれません。その結果、同じSSIDに接続して、1接着点のユーザには同じセットの利用可能なサービスがないかもしれません。
2.2. Identity Selection
2.2. アイデンティティ選択
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つ以上のPublic 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
通常、ユーザは選択されたネットワークに基づくアイデンティティと対応する資格証明セットを選ぶでしょう、選ばれた認証機構で恐らく追加援助を提供していて。 例えば、拡張認証プロトコル--Layer Security(EAP-TLS)を輸送するのが、特定のネットワークと共に使用される認証機構であるなら、ユーザは適切なEAP-TLSを選択するでしょう。
Arkko, et al. Informational [Page 9] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[9ページ]のRFC5113ネットワーク発見とSP2008年1月
client certificate based, in part, on the list of trust anchors provided by the EAP-TLS server.
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.
しかしながら、ローミングが可能にされるアクセスネットワークでは、アクセスネットワークとアイデンティティ/資格証明のセットの間のマッピングは、1〜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はユーザアイデンティティが潜在的アクセスネットワークで使用可能でないかもしれない状況を例証します。 この場合、アクセスネットワーク1は分野"isp1.example.com"の中でユーザへのアクセスを可能にしますが、アクセスネットワーク3は分野"corp2.example.com"の中でユーザへのアクセスを可能にします。 アクセスネットワーク2は両方の分野の中でユーザへのアクセスを可能にします。
? ? +---------+ +------------------+
? | Access | | |
O_/ _-->| Network |------>|"isp1.example.com"|
/| / | 1 | _->| |
| | +---------+ / +------------------+
_/ \_ | /
| +---------+ /
User "subscriber@isp1. | | Access |/
example.com" -- ? -->| Network |
also known as | | 2 |\
"employee123@corp2. | +---------+ \
example.com" | \
| +---------+ \_ +-------------------+
\_ | Access | ->| |
-->| Network |------>|"corp2.example.com"|
| 3 | | |
+---------+ +-------------------+
? ? +---------+ +------------------+ ? | アクセス| | | ○ _/_-->| ネットワーク|、-、-、-、-、--、>|"isp1.example.com"| /| / | 1 | _->|、|、|、| +---------+ / +------------------+ _/ \_ | / | +---------ユーザ+/" subscriber@isp1 "。 | | アクセス|「/example.com」--、--、-->| ネットワーク| また、知られています。| | 2 |\" employee123@corp2 "。 | +---------「+ \example.com」| \ | +---------+ \_ +-------------------+ \_ | アクセス| ->|、| -->| ネットワーク|、-、-、-、-、--、>|"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"分野の中にアイデンティティを持っているユーザは首尾よくネットワーク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
伝統的に、アイデンティティ選択で役に立つヒントをバンドの外に提供しました。 例えば、中[RFC3017]で説明されたXML DTDは付属の潜在的ポイントの間で選ぶクライアントを可能にします。
Arkko, et al. Informational [Page 10] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[10ページ]のRFC5113ネットワーク発見とSP2008年1月
well as to select the NAI and credentials to use in authenticating with it.
それがある認証における使用に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.
すべてが指すところでは、アクセスネットワークの中の付属では、1セットの分野を利用する認証を可能にしてください、とアクセスネットワークの選択は首尾よく認証するためにクライアントが使用できるアイデンティティに関する知識を前提とします。 例えば、アクセスネットワークでは、ネットワーク名に対応するサポートしている分野のセットはあらかじめ構成できます。
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の有線ネットワークをサポートしません、同輩が、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]に、ワイヤレスの認証に使用される証明書の中に用法ヒントを提供します。 これは、証明書を使用できるSSIDsを含むようにクライアントの証明書を広げることを伴います。
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.
これはRFC4284[RFC4284]が解決するのを試みる問題です、サポートしている分野のリストを伝えるのにEAP-要求/アイデンティティを使用して。しかしながら、このアプローチの固有である問題は多いです、Appendix 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でこれらについて徹底的に議論します。
2.3. AAA Routing
2.3. AAAルート設定
Once the identity has been selected, the AAA infrastructure needs to route the access request back to the home AAA server. Typically, the routing is based on the Network Access Identifier (NAI) defined in [RFC4282].
アイデンティティがいったん選択されると、AAAインフラストラクチャは、ホームAAAサーバにアクセス要求を発送して戻す必要があります。通常、ルーティングは[RFC4282]で定義されたNetwork Access Identifier(NAI)に基づいています。
Arkko, et al. Informational [Page 11] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[11ページ]のRFC5113ネットワーク発見とSP2008年1月
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]で説明されるように、ほとんどのローミング実装が比較的簡単です、Access要求の中のUser-名前属性にNAI分野を含んでいることに基づいて次のホップを決定する静的な分野経路指定テーブルを当てにして。 RADIUSの中では、ホームAAAサーバのIPアドレスはRADIUSプロキシの中で維持されたIPアドレスへの分野の静的なマッピングに基づいて通常決定しています。
Diameter [RFC3588] supports mechanisms for intra- and inter-domain service discovery, including support for DNS as well as service discovery protocols such as Service Location Protocol version 2 (SLPv2) [RFC2608]. As a result, it may not be necessary to configure static tables mapping realms to the IP addresses of Diameter agents. However, while this simplifies maintenance of the AAA routing infrastructure, it does not necessarily simplify roaming-relationship path selection.
直径[RFC3588]はイントラと相互ドメインサービス発見のためにメカニズムをサポートします、Service Locationプロトコルバージョン2など(SLPv2)[RFC2608]のサービス発見プロトコルと同様にDNSのサポートを含んでいて。 その結果、DiameterエージェントのIPアドレスに分野を写像する静的なテーブルを構成するのは必要でないかもしれません。 しかしながら、これがAAAルーティングインフラストラクチャのメインテナンスを簡素化している間、それは必ずローミング関係経路選択を簡素化するというわけではありません。
As noted in RFC 2607 [RFC2607], RADIUS proxies are deployed not only for routing purposes, but also to mask a number of inadequacies in the RADIUS protocol design, such as the lack of standardized retransmission behavior and the need for shared secret provisioning between each AAA client and server.
RFC2607[RFC2607]に述べられるように、RADIUSプロキシはルーティング目的に配布されるだけではなく、RADIUSプロトコルの多くの不適当が標準化された「再-トランスミッション」の振舞いの不足や各AAAのクライアントとサーバの間の共有秘密キーの食糧を供給することの必要性のように設計するマスクにも配布されます。
Diameter [RFC3588] supports certificate-based authentication (using either TLS or IPsec) as well as Redirect functionality, enabling a Diameter client to obtain a referral to the home server from a Diameter redirect server, so that the client can contact the home server directly. In situations in which a trust model can be established, these Diameter capabilities can enable a reduction in the length of the roaming relationship path.
直径[RFC3588]はRedirectの機能性と同様に証明書ベースの認証をサポートします(TLSかIPsecのどちらかを使用します)、DiameterクライアントがDiameterの再直接のサーバから紹介をホームサーバに得るのを可能にして、クライアントが直接ホームサーバに連絡できるように。 信頼モデルを確立できる状況で、これらのDiameter能力はローミング関係経路の長さの減少を可能にすることができます。
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
しかしながら、実際には、多くの落とし穴があります。 証明書ベースの認証がNetwork Access Server(NAS)か地元のプロキシとホームAAAサーバとのコミュニケーションを可能にするように、信頼アンカーは、構成される必要があります、そして、証明書は選択される必要があります。 AAAサーバ証明書は、AAAのクライアントの上で構成された信頼アンカーに鎖を作る必要があります、そして、AAAクライアント証明書はAAAサーバで構成された信頼アンカーに鎖を作る必要があります。複数の潜在的ローミング関係経路が利用可能であるところでこれは複数の証明書選択にそれ自体を反映するでしょう、経路選択問題を証明書選択問題に変えて。 証明書選択実装の中でサポートされた機能性によって、これは、問題を解決するのをより簡単にしないかもしれません。 例えば、ローミング経路の必要なコントロールを提供するために、税関証明書選択が論理であると実装するのが必要であるかもしれません。(論理はaの中で導入するのは難しいかもしれません)。
Arkko, et al. Informational [Page 12] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[12ページ]のRFC5113ネットワーク発見とSP2008年1月
certificate handling implementation designed for general-purpose usage.
汎用用法のために設計された取り扱い実装を証明してください。
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-応答/アイデンティティ、[RFC3579](EAP-応答/アイデンティティでアクセス要求の中にUser-名前属性を含んでいるのに飾り付けをされたNAIを含めるNASコピー)で説明されるように飾り付けをされたNAIを提供します。 アクセス要求がローミング関係経路を通過するとき、User-名前属性の中に分野を含んでいることに基づいてAAAプロキシは次のホップを決定します、プロセスで、デコレーションがUser-名前属性にNAIを含んでいるので相次ぐ取り外して。 対照的に、アクセス要求でカプセル化されたEAP-応答/アイデンティティの中に含まれていた飾り付けをされたNAIは触れないままで残っています。 アクセス要求がAAAホームサーバに到着するときEAP-応答/アイデンティティにその結果飾り付けをされたNAIを含んでいるのはUser-名前属性(デコレーションのいくつかかすべてを取り除かせるかもしれない)に含まれていたNAIと異なるかもしれません。 アイデンティティ検証の目的のために、EAPサーバはNAIよりむしろUser-名前属性でNAIをEAP-応答/アイデンティティで利用します。
Over the long term, it is expected that the need for NAI "decoration" and source routing will disappear. This is somewhat analogous to the evolution of email delivery. Prior to the widespread proliferation of the Internet, it was necessary to gateway between SMTP-based mail systems and alternative delivery technologies, such as Unix-to-Unix CoPy Protocol (UUCP) and FidoNet. Prior to the implementation of email gateways utilizing MX RR routing, email address-based source- routing was used extensively. However, over time the need for email source-routing disappeared.
長期的に見ると、NAI「デコレーション」とソースルーティングの必要性が見えなくなると予想されます。 これはメール配送の発展にいくらか類似しています。 インターネットの広範囲の増殖の前に、それがSMTPベースのメールシステムと代替の配送技術の間のゲートウェイに必要でした、UnixからunixへのCoPyプロトコル(UUCP)やFidoNetのように。 MX RRルーティングを利用するメールゲートウェイの実装の前に、Eメールアドレスベースのソースルーティングは手広く使用されました。 しかしながら、時間がたつにつれて、メールソースルーティングの必要性は見えなくなりました。
2.3.1. The Default Free Zone
2.3.1. デフォルト自由地帯
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プロキシは「デフォルトから自由な」分野テーブルで維持されるかもしれません、すべての知られている分野に次のホップを記載しますが、デフォルト分野ルートを提供しないで。
Arkko, et al. Informational [Page 13] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[13ページ]のRFC5113ネットワーク発見とSP2008年1月
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.
ユーザがNAIをNASに供給するとき、同様に、NASは、NAIでコード化された分野に届いているかどうかを先験的に知りません。 それは単にローミング関係経路の次のホップにアクセス要求を転送します。 結局、アクセス要求は「デフォルトから自由な」ゾーンに達します。そこでは、コアAAAプロキシが分野が届いているかどうかと決心しています。 EAP認証が使用中である[RFC4284]で説明されるように、コアAAAプロキシがAccess-廃棄物を送ることができますか、またはAccess-挑戦はそれで「デフォルトから自由な」分野経路指定テーブルの内容に基づく「分野ヒント」を含むEAP-要求/アイデンティティをカプセル化することができます。
There are a number of intrinsic problems with this approach. Where the "default free" routing table is large, it may not fit within a single EAP packet, and the core AAA proxy may not have a mechanism for selecting the most promising entries to include. Even where the "default free" realm routing table would fit within a single EAP- Request/Identity packet, the core AAA router may not choose to include all entries, since the list of realm routes could be considered confidential information not appropriate for disclosure to hosts seeking network access. Therefore, it cannot be assumed that the list of "realm hints" included within the EAP-Request/Identity is complete. Given this, a NAS or local AAA proxy snooping the EAP- Request/Identity cannot rely on it to provide a complete list of reachable realms. The "realm hint" mechanism described in [RFC4284] is not a dynamic routing protocol.
このアプローチに関する多くの本質的な問題があります。 「デフォルトから自由な」経路指定テーブルが大きいところでは、単一のEAPパケットの中で合わないかもしれません、そして、コアAAAプロキシには、選択している大部分有望なエントリーが含むメカニズムがないかもしれません。 「デフォルトから自由な」分野経路指定テーブルがただ一つのEAPの要求/アイデンティティパケットの中で合いさえするだろうところで、コアAAAルータは、すべてのエントリーを含んでいるのを選ばないかもしれません、公開には、ネットワークアクセサリーを探しているホストに適切でない秘密情報であると分野ルートのリストを考えることができたので したがって、EAP-要求/アイデンティティの中に「分野ヒント」を含むリストが完全であると思うことができません。 これを考えて、EAPの要求/アイデンティティについて詮索するNASか地元のAAAプロキシが、届いている分野に関する全リストを提供するためにそれを当てにすることができません。[RFC4284]で説明された「分野ヒント」メカニズムはダイナミックルーティングプロトコルではありません。
2.3.2. Route Selection and Policy
2.3.2. ルート選択と方針
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インフラストラクチャはルート選択と方針のためのメカニズムを欠いています。 その結果、複数のルートが目的地分野に存在するかもしれません、都合のよいルートの選択のためのメカニズムなしで。
Arkko, et al. Informational [Page 14] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[14ページ]のRFC5113ネットワーク発見とSP2008年1月
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では、Roaming Groups1と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"
+---------+
+---------+ | |---->「a.example.com」| ローミング| +---------+ | グループ1| | |、-、-、-、--、>| プロキシ|---->「b.example.com」ユーザ"joe"@| アクセス| +---------「+ a.example.com」--->| プロバイダー| | NAS| +---------+ | |、-、-、-、--、>| |---->「a.example.com」+---------+ | ローミング| | グループ2| | プロキシ|---->「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の例では、Roaming Group1を通したアクセスはRoaming Group2を通したアクセスほど高価でないかもしれません、そして、その結果、「a.example.com」の分野があるNAIのために次のホップとしてRoaming Group1を好むのは望ましいでしょう。 しかしながら、この結果を得る唯一の方法は手動で以下のエントリーがあるNAS分野経路指定テーブルを構成するだろうことです:
Realm Next Hop
----- --------
b.example.com Roaming Group 1
c.example.com Roaming Group 2
Default Roaming Group 1
次の分野は跳びます。----- -------- b. example.com Roaming Group1c.example.com Roaming Group2Default Roaming Group1
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.
手動の構成が分野経路指定テーブルが小さいところで状況で実用的であるかもしれなく、エントリーが静的である間、サポートしている分野のリストが頻繁に変化するか、または好みがダイナミックに変化するところでは、手動の構成は処理しやすくならないでしょう。
2.3.3. Source Routing
2.3.3. ソースルート設定
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ベースのソースルーティングは古典的な意味で掘るソースではありません。
Arkko, et al. Informational [Page 15] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[15ページ]のRFC5113ネットワーク発見とSP2008年1月
it merely suggests preferences that the AAA proxy can choose not to accommodate.
それは単に、AAAプロキシが収容しないのを選ぶことができる好みを示します。
Where realm routes are set up as the result of pre-configuration and dynamic route establishment is not supported, if a realm route does not exist, then NAI-based source routing cannot establish it. Even where dynamic route establishment is possible, such as where the AAA client and server support certificate-based authentication, and AAA servers are discoverable (such as via the mechanisms described in [RFC3588]), an AAA proxy may choose not to establish a realm route by initiating the discovery process based on a suggestion in an NAI- based source route.
プレ構成とダイナミックなルート設立の結果がサポートされないとき分野ルートがセットアップされるところでは、分野ルートが存在していないなら、NAIベースのソースルーティングはそれを設立できません。 ダイナミックなルート設立が可能でさえあるところで、AAAのクライアントとサーバが証明書ベースの認証をサポートして、AAAサーバが発見可能である([RFC3588]で説明されたメカニズムを通したなど)ところのようなAAAプロキシは、NAIのベースの送信元経路で提案に基づく発見プロセスを開始することによって分野ルートを確立しないのを選ぶかもしれません。
Where the realm route does exist, or the AAA proxy is capable of establishing it dynamically, the AAA proxy may choose not to authorize the client to use it.
分野ルートが存在しているか、またはAAAプロキシがダイナミックにそれを設立できるところでは、AAAプロキシは、クライアントがそれを使用するのを認可しないのを選ぶかもしれません。
While, in principle, source routing can provide users with better control over AAA routing decisions, there are a number of practical problems to be overcome. In order to enable the client to construct optimal source routes, it is necessary for it to be provided with a complete and up-to-date realm routing table. However, if a solution to this problem were readily available, then it could be applied to the AAA routing infrastructure, enabling the selection of routes without the need for user intervention.
ソースルーティングは原則としてAAAルーティング決定の、より良いコントロールをユーザに提供できますが、打ち勝たれるために、多くの実用的な問題があります。 クライアントが最適の送信元経路を構成するのを可能にするために、完全で最新の分野経路指定テーブルをそれに提供するのが必要です。 しかしながら、この問題への解決が容易に利用可能であるなら、AAAルーティングインフラストラクチャにそれを適用できるでしょうに、ユーザ介入の必要性なしでルートの品揃えを可能にして。
As noted in [Eronen04], only a limited number of parameters can be updated dynamically. For example, quality of service or pricing information typically will be pre-provisioned or made available on the web rather than being updated on a continuous basis. Where realm names are communicated dynamically, the "default free" realm list is unlikely to be provided in full since this table could be quite large. Given the constraints on the availability of information, the construction of source routes typically needs to occur in the face of incomplete knowledge.
[Eronen04]に述べられるように、ダイナミックに限られた数のパラメタしかアップデートできません。 例えば、随時でアップデートするよりむしろサービスの質か情報に値を付けるのを通常あらかじめ食糧を供給するか、またはウェブで利用可能にするでしょう。 分野名がダイナミックに伝えられるところでは、このテーブルがかなり大きいかもしれないので、「デフォルトから自由な」分野リストはすべて提供されそうにはありません。 情報の有用性における規制を考えて、送信元経路の構造は、通常不完全な知識に直面して起こる必要があります。
In addition, there are few mechanisms available to audit whether the requested source route is honored by the AAA infrastructure. For example, an access network could advertise a realm route to "costsless.example.com", while instead routing the access-request through "costsmore.example.com". While the decorated NAI would be made available to the home AAA server in the EAP-Response/Identity, the home AAA server might have a difficult time verifying that the source route requested in the decorated NAI was actually honored by the AAA infrastructure. Similarly, it could be difficult to determine whether quality of service (QoS) or other routing requests were actually provided as requested. To some extent, this problem
さらに、AAAインフラストラクチャによる要求された送信元経路が光栄に思っているか否かに関係なく、監査するために利用可能なメカニズムがわずかしかありません。 例えば、アクセスネットワークは代わりに"costsmore.example.com"を通してアクセス要求を発送している間、"costsless.example.com"に分野ルートの広告を出すことができました。 EAP-応答/アイデンティティにおけるホームAAAサーバが飾り付けをされたNAIを入手するだろうという間、ホームAAAサーバは、飾り付けをされたNAIで要求された送信元経路が実際にAAAインフラストラクチャによって光栄に思われたことを確かめるのに苦労するかもしれません。 同様に、サービスの質(QoS)か他のルーティング要求が実際に要求された通り提供されたかどうか決定するのは難しいかもしれません。 ある程度この問題
Arkko, et al. Informational [Page 16] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[16ページ]のRFC5113ネットワーク発見とSP2008年1月
may be addressed as part of the business arrangements between roaming partners, which may provide minimum service-level guarantees.
ローミングパートナーの間のビジネスアレンジメントの一部として扱われるかもしれません。そのパートナーは、最小のサービスレベル保証を提供するかもしれません。
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]「分野ヒント」を提供できます。 しかしながら、このアプローチには、厳しいスケーラビリティ制限がAppendix A.1に概説されているようにあります。
2.4. Network Capabilities Discovery
2.4. ネットワーク能力発見
Network capability discovery focuses on discovery of the services offered by networks, not just the capabilities of individual points of attachment. By acquiring additional information on access network characteristics, it is possible for users to make a more informed access decision. These characteristics may include:
ネットワーク能力発見は個々のポイントの付属の能力だけではなく、ネットワークによって提供されたサービスの発見に焦点を合わせます。 アクセスネットワークの特性に関する追加情報を取得することによって、ユーザが、より知識があるアクセス決定をするのは、可能です。 これらの特性は以下を含むかもしれません。
o Roaming relationships between the access network provider and
other network providers and associated costs. Where the network
access client is not pre-configured with an identity and
credentials corresponding to a local access network, it will need
to be able to determine whether one or more home realms are
reachable from an access network so that successful authentication
can be possible.
o アクセスネットワーク内の提供者と、他のネットワーク内の提供者と関連コストとの関係に移動します。 ネットワークアクセスクライアントがローカルのアクセスネットワークに対応するアイデンティティと資格証明書であらかじめ設定されないところでは、それは、1つ以上のホーム分野にうまくいっている認証が可能になるようにアクセスネットワークから届いているかどうか決定できる必要があるでしょう。
o EAP authentication methods. While the EAP authentication methods
supported by a home realm can only be determined by contacting the
home AAA server, it is possible that the local realm will also
support one or more EAP methods. For example, a user may be able
to utilize EAP-SIM (Extensible Authentication Protocol -
Subscriber Identity Module) to authenticate to the access network
directly, rather than having to authenticate to the home network.
o EAP認証方法。 ホーム分野によってサポートされたEAP認証方法はホームAAAサーバに連絡することによって、決定できるだけですが、また、地方の分野が1つ以上のEAPメソッドをサポートするのは、可能です。 例えば、ユーザはホームネットワークに認証する有より直接と、むしろアクセスネットワークに認証するEAP-SIM(拡張認証プロトコル--加入者識別モジュール)を利用できるかもしれません。
o End-to-end quality of service capability. While local quality of
service capabilities are typically advertised by the access
network (e.g., support for Wi-Fi Multimedia (WMM)), the
availability of end-to-end QoS services may not be advertised.
o 終わりから終わりへのサービスの質能力。 地方のサービスの質能力がアクセスネットワーク(例えば、Wi-Fi Multimedia(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 middleboxesかファイアウォールの存在などのパラメタを修理してください。 ネットワークアクセスクライアントをそれが接着点に接続するとき受信されるのをインターネット・アクセスを意識するようにしないなら、ユーザが必要なサービスにアクセスできないのは、可能です。
Reference [IEEE.11-04-0624] classifies the possible steps at which IEEE 802.11 networks can acquire this information:
参照[IEEE.11-04-0624]はIEEE802.11に、ネットワークがこの情報を取得できる可能なステップを分類します:
Arkko, et al. Informational [Page 17] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[17ページ]のRFC5113ネットワーク発見とSP2008年1月
o Pre-association
o プレ協会
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つ以上を改訂する認証過程の間、情報を学ぶと、ノードは、新しいネットワーク、接着点、そして/または、アイデンティティを選択して、次に、もう一度認証過程に直面する必要があるでしょう。 そのようなプロセスは時間がかかって、かつ頼り無い傾向があります。
3. Design Issues
3. デザイン問題
The following factors should be taken into consideration while evaluating solutions to the problem of network selection and discovery.
以下の要素はネットワーク選択と発見の問題にソリューションを評価している間、考慮に入れられるべきです。
3.1. AAA Routing
3.1. AAAルート設定
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属性、アクセス型、またはパフォーマンスの最適化(速い移管サポートなどの)の開発を制限するべきではありません。
3.2. Backward Compatibility
3.2. 後方の互換性
Solutions need to maintain backward compatibility. In particular:
ソリューションは、後方の互換性を維持する必要があります。 特に:
o Selection-aware clients need to interoperate with legacy NAS
devices and AAA servers.
o 選択意識しているクライアントは、レガシーNASデバイスとAAAサーバで共同利用する必要があります。
o Selection-aware AAA infrastructure needs to interoperate with
legacy clients and NAS devices.
o 選択意識しているAAAインフラストラクチャは、レガシークライアントとNASデバイスで共同利用する必要があります。
Arkko, et al. Informational [Page 18] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[18ページ]のRFC5113ネットワーク発見とSP2008年1月
For example, selection-aware clients should not transmit packets larger than legacy NAS devices or AAA servers can handle. Where protocol extensions are required, changes should be required to as few infrastructure elements as possible. For example, extensions that require upgrades to existing NAS devices will be more difficult to deploy than proposals that are incrementally deployable based on phased upgrades of clients or AAA servers.
例えば、選択意識しているクライアントはレガシーNASデバイスかサーバが扱うことができるAAAより大きいパケットを伝えるべきではありません。 プロトコル拡大が必要であるところでは、変化はできるだけわずかしかインフラストラクチャ要素に必要であるべきではありません。 例えば、配布するのは提案がクライアントかAAAサーバの段階的なアップグレードに基づいて増加して配布可能されるより既存のNASデバイスにアップグレードを必要とする拡張子がさらに難しくなるでしょう。
3.3. Efficiency Constraints
3.3. 効率規制
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インフラストラクチャで抑制されるのは、可能です。 その結果、keepalivesか周期的な徹底的調査パケットなどの話好きなメカニズムは避けられることです。 AAAサーバによる取引高を考えて、また、ソリューションも負荷に加えるのを意識しているべきです、特にこれがサービス不能攻撃を可能にすることができた場合で。 例えば、NASが、[RFC4284]で説明されるように「分野ヒント」を得るために徹底的調査EAP-応答/アイデンティティパケットをAAAインフラストラクチャに送りながら定期的でアップデートされた分野経路指定テーブルを入手するのを試みるのは、悪い考えでしょう。 また、完全な分野経路指定テーブルをNASに提供しないでしょう、これはAAAインフラストラクチャ(その結果、特にAAAサーバが既に積みすぎられた場合ではNASで「再-トランスミッション」をもたらすパケットを下げる)にかなりの負荷を追加するだろうというだけではなくセクション2.3で説明された理由で。
Battery consumption is a significant constraint for handheld devices. Therefore, mechanisms that require significant increases in packets transmitted, or the fraction of time during which the host needs to listen (such as proposals that require continuous scanning), are to be discouraged. In addition, the solution should not significantly impact the time required to complete network attachment.
バッテリー消費はハンドヘルドデバイスの重要な規制です。 したがって、伝えられたパケットのかなりの増加、またはホストが聴く必要がある時間(連続したスキャンを必要とする提案などの)の部分を必要とするメカニズムはがっかりすることです。 さらに、ソリューションはネットワーク付属を完成するのに必要である時間にかなり影響を与えるべきではありません。
3.4. Scalability
3.4. スケーラビリティ
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]などのソリューションは分野経路指定テーブルのエントリーの数に比例して広告のサイズを増強します。 このアプローチは多くのネットワークと分野についてサポートに合わせて調整しません。
Arkko, et al. Informational [Page 19] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[19ページ]のRFC5113ネットワーク発見とSP2008年1月
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」に別々のBeaconsを利用するアプローチが広告に掲載されているネットワークの数に比例して追加Beaconsを導入します。 そのようなアプローチがネットワークアクセスクライアントに必要であるプレ構成を最小にしているかもしれない間、「仮想のAPs」の増殖はワイヤレスの媒体の高使用率をもたらすことができます。 例えば、基本料金セットの中で単にレートで802.11Beaconを送ります。セットは最も低いサポートしているレートの、または、恐らく最も低いだけのサポートしているレートから通常成ります。 その結果、各「仮想のAP」のために別々のBeaconを必要とする「仮想の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:
例えば、100Time Units(TUs)か102.4ms(9.8Beacons/秒)のBeacon間隔で、それぞれそれら自身の170の八重奏のBeaconを発表する20 802.11b「仮想のAPs」が37.9パーセントのチャンネル利用をもたらすでしょう。 以下の通り計算について確かめることができます:
1. A single 170-octet Beacon sent at 1 Mbps will utilize the channel
for 1360 us (1360 bits @ 1 Mbps);
1. Beaconが1Mbpsで送ったただ一つの170八重奏が1360年のチャンネルを利用する、私たち(@1360ビットの1Mbps)。
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. 付加144、Physical Layer Convergence Procedure(PLCP)の長い序文(@144ビットの1Mbps)、48のための私たち、10歳のPLCPヘッダー(@48ビットの1Mbps)のための私たち、Short Interframe Space(SIFS)、50のための私たち、Distributed Interframe Space(DIFS)、および320のための私たち、backoffのない平均した最小のContention Windowのための私たち、(CWmin/2*aSlotTime=32/2*20、私たち)、独身のBeaconが1932年の802.11b channelを利用するのを含意する、私たち。
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のBeaconあたりのチャンネル時にBeacons/秒を掛けてください。そうすれば、私たちが378672のチャンネル利用を得る、私たち、/は=37.9パーセントを後援します。
In addition, since Beacon/Probe Response frames are sent by each AP over the wireless medium, stations can only discover APs within range, which implies substantial coverage overlap for roaming to occur without interruption. Another issue with the Beacon and Probe Request/Response mechanism is that it is either insecure or its security can be assured only as part of authenticating to the network (e.g., verifying the advertised capabilities within the 4-way handshake).
さらに、Beacon/徹底的調査Responseフレームがワイヤレスの媒体の上の各APによって送られるので、ステーションは、APs(ローミングが間断ない起こるようにかなりの適用範囲オーバラップを含意する)が中で及ぶと発見できるだけです。 BeaconとProbe Request/反応機構の別の問題はそれが不安定であるか、または単にネットワーク(例えば、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.
多くの増進が、シナリオに移動する際にスケーラビリティと性能を向上させるためにBeacon/徹底的調査Responseメカニズムに提案されました。 これらは、APsがそれら自身[IEEE.802.11k]と同様に隣人APsの能力を発表するのを許容するのを含んでいます。 また、IEEE802.11の中の「仮想のAPs」のサポートのための、よりスケーラブルなメカニズムは提案されました[IEEE.802.11v]。 一般にこれらの提案は「仮想のAP」という複数の広告をただ一つの広告まで潰します。
Arkko, et al. Informational [Page 20] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[20ページ]のRFC5113ネットワーク発見とSP2008年1月
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をひくことによって断片化などのリンクレイヤで利用可能でないかもしれない施設は利用できるのでスケーラビリティを改良するのにより高い層のメカニズムを使用できます。 例えば、IEEE802.11では、それらがマルチキャストフレームであるので、Beaconフレームは断片化を使用できません。
3.5. Static Versus Dynamic Discovery
3.5. 静電気対ダイナミックな発見
"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はSSIDでパートナーネットワークに移動しながら区別するのを難しくするかもしれません)。 どのような場合でも、ワイヤレス・ネットワークでは、ノードが、どのAPsが範囲の中のそれが接続できる前であるかを知る必要があるので、ダイナミックな発見は実際的な要件です。
3.6. Security
3.6. セキュリティ
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経路指定テーブルが秘密情報であると考えて、したがって、RFC4284で説明されたメカニズムで非認証された同輩にそれを提供したがっていないかもしれません。 同輩は固有識別文字が1つを選んでいてそれがサポートする分野のリストを提供できましたが、このアプローチはプライバシーの問題を提起します。 アイデンティティ選択が認証の前に起こるので、cleartextで同輩のサポートしている分野を送るでしょう、攻撃者が犠牲となる可能性のある者が資格証明書を持っている分野を決定するのを可能にして。 同輩公開を制限することによって、この危険を緩和できます。 例えば、同輩は初めは選択されたアイデンティティが使用不可能であると判明した状況で追加分野を明らかにするだけであるかもしれません。
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 Channel Bindingsを通して確認可能であるかもしれません。 他のものはその後のSecure Associationプロトコル握手で確認されるかもしれません。
Arkko, et al. Informational [Page 21] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[21ページ]のRFC5113ネットワーク発見とSP2008年1月
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.
中、各固有識別文字に関連していて、特定の名前付の同輩はメソッドのサポートa選択がそうすると予期されません。 これで、同輩はセットから最も安全でないメソッドを交渉する攻撃に被害を受け易くなるでしょう。 代わりに、指定されたそれぞれに関してそこをじっと見てください、SHOULD、まさにその同輩名を認証するのに使用される1つのメソッドのしるしになってください。 異なった事情の、そして、次に、異なったアイデンティティSHOULDの下で異なった認証方法の使用を使わせる同輩の必要性であるなら。それはそれぞれまさに1つの認証方法を特定します。
In practice, where the authenticator operates in "pass-through" mode, the EAP method negotiation will occur between the EAP peer and server, and therefore the peer will need to associate a single EAP method with a given EAP server. Where multiple EAP servers and corresponding identities may be reachable from the same selected network, the EAP peer may have difficulty determining which identity (and corresponding EAP method) should be used. Unlike network selection, which may be securely confirmed within a Secure Association Protocol handshake, identity selection hints provided within the EAP-Request/Identity are not secured.
(そこでは、固有識別文字が「通じて、通り」モードで作動します)。実際には、EAPメソッド交渉はEAP同輩とサーバの間に起こるでしょう、そして、したがって、同輩はただ一つのEAPメソッドを与えられたEAPサーバに関連づける必要があるでしょう。複数のEAPサーバと対応するアイデンティティが同じ選択されたネットワークから届くかもしれないところでは、どのアイデンティティ(そして、対応するEAPメソッド)が使用されるべきであるかを決定するのにEAP同輩は苦労するかもしれません。 ネットワーク選択と異なって、EAP-要求/アイデンティティの中で提供されたアイデンティティ選択ヒントは保証されません。選択はSecure Associationプロトコル握手の中でしっかりと確認されるかもしれません。
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.
その結果、RFC4284で説明されたアイデンティティ選択メカニズムが使用されているところでは、攻撃者は、より少ないセキュリティ(例えば、EAP MD5-挑戦)を提供するEAPメソッドに対応するアイデンティティを選択するように犠牲者を説得するのに提供された「ヒント」を使用できました。 この危険を緩和する1つの方法は、同輩が[RFC4017]セキュリティ要件を満たしながらEAPメソッドを利用するだけであり、同輩が選択が利用可能である最も強い認証方法に対応するアイデンティティを選択することです。
3.7. Management
3.7. 管理
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.
操作上の観点と、ネットワーク広告のコントロールにおけるネットワークデバイスと「分野ヒント」をネットワーク発見と選択を誘導するのに提供するのから、状態情報をオペレータに提供できる管理インタフェースを少なくとも提供するべきです。 それぞれの選択されたネットワークと中古の分野のカウンタであるのやRFC4284がいつ使用されているかなどの状態情報、提供された「分野ヒント」のカウントはオペレータに興味を持たせるかもしれません。 関連されて、「デフォルト自由地帯」になる分野か「AAAはルートに行き詰まること」が興味があるという特に情報。
Larger deployments would benefit from a management interface that allow full remote configuration capabilities, for example, of "realm
より大きい展開は例えば「分野」について完全なリモート構成能力を許容する管理インタフェースの利益を得るでしょう。
Arkko, et al. Informational [Page 22] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[22ページ]のRFC5113ネットワーク発見とSP2008年1月
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.
4284を従わせているRFCネットワークデバイスの場合の「ヒント。」 「分野ヒント」と分野ルーティング情報への変化が頻繁でないと予想されますが、集結されたリモート管理は、misconfiguredデバイスの頻度を下げる傾向があります。
4. Conclusions
4. 結論
This document describes the network selection and discovery problem. In the opinion of the authors, the major findings are as follows:
このドキュメントはネットワーク選択と発見問題について説明します。 作者の意見では、主な発見は以下の通りです:
o There is a need for additional work on access network discovery,
identifier selection, AAA routing, and payload routing.
o アクセスネットワーク発見、識別子選択、AAAルーティング、およびペイロードルーティングに対する追加仕事の必要があります。
o Credential selection and AAA routing are aspects of the same
problem, namely identity selection.
o 資格証明選択とAAAルーティングは同じ問題の局面、すなわち、アイデンティティ選択です。
o When considering selection among a large number of potential
access networks and points of attachment, the issues described in
the document become much harder to solve in an automated way,
particularly if there are constraints on handoff latency.
o 多くの潜在的アクセスネットワークとポイントの付属の中で選択を考えるとき、ドキュメントで説明された問題は自動化された方法ではるかに解決しにくいようになります、特に規制が移管潜在にあれば。
o The proliferation of network discovery technologies within IEEE
802, IETF, and 3rd Generation Partnership Project (3GPP) has the
potential to become a significant problem going forward. Without
a unified approach, multiple non-interoperable solutions may be
deployed.
o IEEE802、IETF、および第3Generation Partnership Project(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 既存のリンクレイヤのレガシー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で説明された計算は、IEEE802.11Beacon/徹底的調査Responseメカニズムには新しいBeaconが各「仮想のAP」に使用される状況におけるかなりのスケーリング問題があるのを示します。 その結果、単独のチャンネルは実際にはIEEE 802.11bとの20未満のBeacon発表に制限されます。
Arkko, et al. Informational [Page 23] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[23ページ]のRFC5113ネットワーク発見とSP2008年1月
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などの後継者と共に実質的に改良されます、その結果、潜在的に、潜在的仮想のAPsの数を増強します。
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.
その結果、IEEE802.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 IEEE802.21、仕事はIEEE802.1で進行中です、そして、提供する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]はNeighbor Reportのサポートを提供しますが、これは他のリンクが層であるとサポートするポイントの付属ではなく、隣接している802.11APsにおける情報の集会に備えるだけです。 この問題の解決はIEEE802と標準化団体の間のコーディネートを必要とするように見えるでしょう。
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-要求/アイデンティティパケットの断片化をサポートしないなら、これらのパケットと合うことができる「分野ヒント」のボリュームは限られます。 さらに、州3(関連づけられて、認証されます)の中でIEEE802.11の中では、EAPパケットを交換できるだけです。 その結果、EAPの分野発見の使用は重要な遅れをもたらすかもしれません。 分野能力情報(QoSの食糧を供給することなどの)の広告を扱うために[RFC4284]で定義された分野広告メカニズムの拡大は意味とパケットサイズ制限[GROETING]のため推薦されません。 その結果、私たちは、分野能力の発見のために[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 リンクレイヤアプローチが利用可能でないところでは、より高い層のアプローチを考えることができます。 より高い層の溶液の限界は既に接続されたホストの動きを最適化できるだけですが、ネットワーク発見がうまくいっている付属に必要であるシナリオを扱うことができないということです。
Arkko, et al. Informational [Page 24] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[24ページ]のRFC5113ネットワーク発見とSP2008年1月
Higher-layer alternatives worth considering include the SEAMOBY
CARD protocol [RFC4066], which enables advertisement of network
device capabilities over IP, and Device Discovery Protocol (DDP)
[MARQUES], which provides functionality equivalent to IEEE 802.1AB
using ASN.1 encoded advertisements sent to a link-local scope
multicast address.
考える価値があるより高い層の代替手段はSEAMOBY CARDプロトコル[RFC4066]を含んでいます、そして、Deviceディスカバリープロトコル(DDP)[マルケス](ASN.1を使用することでIEEE 802.1ABに同等な機能性を提供する)はリンクローカルの範囲マルチキャストアドレスに送られた広告をコード化しました。(プロトコルはIPの上でネットワークデバイス能力の広告を可能にします)。
5. Security Considerations
5. セキュリティ問題
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メソッドで、そのようなパラメタの検証はいつも可能になるというわけではありません。 しかしながら、Protected EAP(PEAP)[JOSEFSSON]やEAP-IKEv2などのEAPメソッド[IKEV2]で、これは可能になるかもしれません。古くからある方法[ARKKO]に後方コンパチブル拡大を提供する試みさえあります。
The security requirements for network selection depend on whether the selection is considered a mandate or a hint. In general, treating network advertisements as a hint is a more secure approach, since it reduces access client vulnerability to forged network advertisements. For example, "realm hints" may be ignored by an EAP peer if they are incompatible with the security policy corresponding to a selected access network.
ネットワーク選択のためのセキュリティ要件は選択が命令かヒントであると考えられるかどうかによります。 一般に、ネットワーク広告をヒントとして扱うのは、より安全なアプローチです、アクセスクライアント脆弱性を偽造ネットワーク広告に減少させるので。 例えば、それらが選択されたアクセスネットワークに対応する安全保障政策と非互換であるなら、「分野ヒント」はEAP同輩によって無視されるかもしれません。
Similarly, network access clients may refuse to connect to a point of attachment if the advertised security capabilities do not match those that have been pre-configured. For example, if an IEEE 802.11 access client has been pre-configured to require WPA2 enterprise support within an access network, it may refuse to connect to access points advertising support for WEP.
同様に、広告を出しているセキュリティ能力があらかじめ設定されたものに合っていないなら、ネットワークアクセスクライアントは、接着点に接続するのを拒否するかもしれません。 例えば、IEEE802.11アクセスクライアントがアクセスネットワークの中でWPA2企業サポートを必要とするようにあらかじめ設定されたなら、それは、WEPのアクセスポイント広告サポートに接続するのを拒否するかもしれません。
Where the use of methods that do not satisfy the security requirements of [RFC4017] is allowed, it may be possible for an attacker to trick a peer into using an insecure EAP method, leading to the compromise of long-term credentials. This can occur either where a network is pre-configured to allow use of an insecure EAP method, or where connection without pre-configuration is permitted using such methods.
[RFC4017]のセキュリティ要件を満たさないメソッドの使用が許されているところでは、攻撃者が、同輩が不安定なEAPメソッドを使用するようにだますのは、可能であるかもしれません、長期の資格証明書の感染に通じて。 これは、不安定なEAPメソッドがネットワークが使用を許すためにあらかじめ設定されるところに起こるか、またはそのようなメソッドを使用して、プレ構成のない接続が受入れられるところに起こることができます。
For example, an attacker can spoof a network advertisement, possibly downgrading the advertised security capabilities. The rogue access point would then attempt to negotiate an insecure EAP method. Such
例えば、ことによると広告を出しているセキュリティ能力を格下げして、攻撃者は、ネットワークが広告であると偽造することができます。 そして、凶暴なアクセスポイントは、不安定なEAPメソッドを交渉するのを試みるでしょう。 そのようなもの
Arkko, et al. Informational [Page 25] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[25ページ]のRFC5113ネットワーク発見とSP2008年1月
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.
同輩が、[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.
発見が認証のための前提条件であるので、認証過程で引き出されたダイナミックなキーを使用する初期の発見を保護するのは可能ではありません。 他方では、対称鍵かデジタル署名を利用するネットワーク広告の保全保護はプレ構成を必要とするでしょう。
6. Informative References
6. 有益な参照
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、2003年9月。
[RFC3017] Riegel, M. and G. Zorn, "XML DTD for Roaming Access Phone
Book", RFC 3017, December 2000.
[RFC3017] リーゲルとM.とG.ゾルン、「ローミングアクセス電話帳のためのXML DTD」、RFC3017、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.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、2004年6月。
[RFC4334] Housley, R. and T. Moore, "Certificate Extensions and
Attributes Supporting Authentication in Point-to-Point
Protocol (PPP) and Wireless Local Area Networks (WLAN)",
RFC 4334, February 2006.
[RFC4334]Housley(R.とT.ムーア)は「認証が指すポイントのプロトコル(ppp)とワイヤレスのローカル・エリア・ネットワーク(WLAN)であるとサポートする拡大と属性を証明します」、RFC4334、2006年2月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
2005年12月の[RFC4282]AbobaとB.と用務員とM.とArkko、J.とP.Eronen、「ネットワークアクセス識別子」RFC4282。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3280] Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
Arkko, et al. Informational [Page 26] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[26ページ]のRFC5113ネットワーク発見とSP2008年1月
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072,
August 2005.
[RFC4072] Eronen、P.、ヒラー、T.、およびG.ゾルン、「直径拡張認証プロトコル(EAP)アプリケーション」、RFC4072、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.カルフーン、「拡張認証プロトコル(EAP)の半径(ユーザサービスにおけるリモート認証ダイヤル)サポート」RFC3579(2003年9月)。
[RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang,
"Review of Roaming Implementations", RFC 2194,
September 1997.
1997年9月の[RFC2194]AbobaとB.とLuとJ.とAlsopとJ.と鐘の音、J.とW.ワング、「ローミング実装のレビュー」RFC2194。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[RFC2607] Aboba、B.、J.Vollbrecht、および「ローミングにおけるプロキシ推論と政策の実施」、RFC2607、6月1999日
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2", RFC 2608,
June 1999.
[RFC2608] GuttmanとE.とパーキンスとC.とVeizades、J.とM.日、「サービス位置のプロトコル、バージョン2インチ、RFC2608、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] コングドン、P.、Aboba、B.、スミス、A.、ゾルン、G.、およびJ.Roese、「ユーザサービス(半径)用法ガイドラインのIEEE 802.1Xのリモート認証ダイヤル」、RFC3580(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.、ロルツ、V.、バリ、F.、およびP.Eronen、「アイデンティティ選択は拡張認証プロトコル(EAP)のために暗示します」、RFC4284、2006年1月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
[RFC4017] スタンリー、D.、ウォーカー、J.、およびB.Aboba、「ワイヤレスのLANのための拡張認証プロトコル(EAP)メソッド要件」、RFC4017(2005年3月)。
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[RFC2486] AbobaとB.とM.用務員、「ネットワークアクセス識別子」、RFC2486、1999年1月。
[RFC4066] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E.
Shim, "Candidate Access Router Discovery (CARD)",
RFC 4066, July 2005.
[RFC4066]Liebsch(M.、シン、A.、Chaskar、H.、船渡、D.、およびE.詰め物、「候補アクセスルータディスカバリー(カード)」(RFC4066)2005年7月)。
[IKEV2] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y.,
and F. Bersani, "EAP-IKEv2 Method", Work in Progress,
September 2007.
[IKEV2] Tschofenig、H.、Kroeselberg、D.、Pashalidis、A.、オオバ、Y.、およびF.ベルサニ、「EAP-IKEv2メソッド」は進歩、2007年9月に働いています。
[ARKKO] Arkko, J. and P. Eronen, "Authenticated Service
Information for the Extensible Authentication Protocol
(EAP)", Work in Progress, October 2005.
[ARKKO] 「拡張認証プロトコル(EAP)のための認証されたサービス情報」というArkko、J.、およびP.Eronenは進歩、2005年10月に働いています。
Arkko, et al. Informational [Page 27] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[27ページ]のRFC5113ネットワーク発見とSP2008年1月
[GROETING] Groeting, W., Berg, S., Tschofenig, H., and M. Ness,
"Network Selection Implementation Results", Work
in Progress, July 2004.
W.とバーグとS.とTschofenig、H.とM.ネス湖、「ネットワーク選択実装結果」という[GROETING]Groetingは進歩、2004年7月に働いています。
[JOSEFSSON]
Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G.,
and S. Josefsson, "Protected EAP Protocol (PEAP) Version
2", Work in Progress, October 2004.
[JOSEFSSON] Palekar、A.、サイモン、D.、Salowey、J.、周、H.、ゾルン、G.、およびS.Josefsson、「保護されたEAPプロトコル(PEAP)バージョン2インチ、進歩、2004年10月に働いてください。」
[MARQUES] Enns, R., Marques, P., and D. Morrell, "Device Discovery
Protocol (DDP)", Work in Progress, May 2003.
マルケス、P.とD.マレル、「デバイス発見プロトコル(DDP)」という[捕獲許可]エンス、R.は、進歩、2003年5月に働いています。
[OHBA] Taniuchi, K., Ohba, Y., and D. Subir, "IEEE 802.21 Basic
Schema", Work in Progress, October 2007.
[オオバ] Taniuchi、K.、オオバ、Y.、およびD.Subir、「IEEE802.21の基本的な図式」が進歩、2007年10月に働いています。
[IEEE.802.11-2003]
IEEE, "Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications", IEEE Standard
802.11, 2003.
[IEEE.802.11-2003]IEEE、「ワイヤレスのLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様」、IEEE規格802.11、2003。
[Fixingapsel]
Judd, G. and P. Steenkiste, "Fixing 802.11 Access Point
Selection", Sigcomm Poster Session 2002.
[Fixingapsel] ジャドとG.とP.Steenkiste、「802.11アクセスポイント選択を修理します」、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/男性決められた一定の要求--パート11の規格にAmmendmentを作成してください」 ワイヤレスの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、2007年1月。
Arkko, et al. Informational [Page 28] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[28ページ]のRFC5113ネットワーク発見とSP2008年1月
[IEEE.802.11v]
IEEE, "Draft Amemdment to Standard for Information
Technology - Telecommunications and Information Exchange
Between Systems - LAN/MAN Specific Requirements - Part 11:
Wireless Medium Access Control (MAC) and physical layer
(PHY) specifications: Wireless Network Management",
IEEE 802.11v, D0.09, March 2007.
[IEEE.802.11v]IEEE、「Amemdmentを情報技術--テレコミュニケーションの規格とシステムの間の情報交換--LAN/男性決められた一定の要求--パート11まで作成してください」 ワイヤレスのMedium Access Control(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、「ワイヤレス・ネットワークセキュリティにおける承認の役割」とExtended要約は、DIMACSワークショップ(2004年11月)に提示しました。
[IEEE.11-04-0624]
Berg, S., "Information to Support Network Selection", IEEE
Contribution 11-04-0624 2004.
[IEEE.11-04-0624] バーグ、S.、「サポートネットワーク選択への情報」、IEEE貢献11-04-0624 2004。
[Priest04]
Priest, J., "The State of Wireless London", July 2004.
J.、「ワイヤレスのロンドン州」2004年7月の[Priest04]聖職者。
[MACScale]
Heusse, M., "Performance Anomaly of 802.11b", LSR-IMAG
Laboratory, Grenoble, France, IEEE Infocom 2003.
[MACScale] Heusse、M.、「802.11bのパフォーマンス異常」、LSR-IMAG研究所、グルノーブル(フランス)IEEE Infocom2003。
[Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE
802.11b MAC Layer Handover Time", Laboratory for
Communication Networks, KTH, Royal Institute of
Technology, Stockholm, Sweden, TRITA-IMIT-LCN R 03:02,
April 2003.
通信ネットワーク、KTH、王立の工科大学、ストックホルム(スウェーデン)TRITA-IMIT-LCN R03:02、2003年4月の[Velayos]Velayos、H.とG.カールソン、「IEEE 802.11b MAC層の引き渡し時間を短縮するテクニック」研究所。
[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/男性決められた一定の要求)は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がそうするかもしれません。
[IEEE-11-03-0827]
Hepworth, E., "Co-existence of Different Authentication
Models", IEEE Contribution 11-03-0827 2003.
[IEEE-11-03-0827] ヘップウォース、E.、「異なった認証モデルの共存」、IEEE貢献11-03-0827 2003。
Arkko, et al. Informational [Page 29] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[29ページ]のRFC5113ネットワーク発見とSP2008年1月
[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-000のu-tgu-要件]モートン、M.、「TGu要件」、IEEE貢献11-05- 0822-03-000u-tgu-要件、2005年8月。
[3GPPSA2WLANTS]
3GPP, "3GPP System to Wireless Local Area Network (WLAN)
interworking; System De scription; Release 6; Stage 2",
3GPP Technical Specification 23.234, September 2005.
[3GPPSA2WLANTS]3GPP、「Wirelessローカル・エリア・ネットワーク(WLAN)の織り込むことへの3GPP System」。 システムDe scription。 リリース6。 2005年9月に2インチ、3GPP仕様書23.234を上演してください。
[3GPP-SA3-030736]
Ericsson, "Security of EAP and SSID based network
advertisements", 3GPP Contribution S3-030736,
November 2003.
[3GPP-SA3-030736]エリクソン、「EAPとSSIDのセキュリティはネットワーク広告を基礎づけた」3GPP Contribution 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、10月2005日
[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環境と役割におけるネットワーク選択にアクセスします」、第10WWRF、ニューヨーク2003年10月。
[WLAN3G] Ahmavaara, K., Haverinen, H., and R. Pichna, "Interworking
Architecture between WLAN and 3G Systems", IEEE
Communications Magazine, November 2003.
[WLAN3G] Ahmavaara、K.、Haverinen、H.、およびR.Pichna、「WLANと3Gの間のアーキテクチャにシステムを織り込みます」、IEEEコミュニケーション雑誌、2003年11月。
[INTELe2e]
Intel, "Wireless LAN (WLAN) End to End Guidelines for
Enterprises and Public Hotspot Service Providers",
November 2003.
[INTELe2e]インテル、「ワイヤレスのラン(WLAN)はエンタープライズのためのガイドラインと公立のホットスポットサービスプロバイダーを終わらせるために終わる」2003年11月。
[Eronen03]
Eronen, P., "Network Selection Issues", presentation to
EAP WG at IETF 58, November 2003.
[Eronen03] Eronen、P.、「ネットワーク選択問題」、IETF58、2003年11月のEAP WGへのプレゼンテーション。
[3GPPSA3WLANTS]
3GPP, "3GPP Technical Specification Group Service and
System Aspects; 3G Security; Wireless Local Area Network
(WLAN) interworking security (Release 6); Stage 2",
3GPP Technical Specification 33.234 v 6.6.0, October 2005.
[3GPPSA3WLANTS]3GPPと、「3GPP仕様書グループサービスとシステム局面」。 3Gセキュリティ。 セキュリティが(リリース6)であると織り込むワイヤレスのローカル・エリア・ネットワーク(WLAN)。 2005年10月に2インチ、3GPP仕様書33.234v6.6.0を上演してください。
Arkko, et al. Informational [Page 30] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[30ページ]のRFC5113ネットワーク発見とSP2008年1月
[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、「Wirelessローカル・エリア・ネットワーク(WLAN)の織り込むことへの3GPP System」。 ネットワーク・プロトコルへのユーザEquipment(UE)。 「ステージ3(リリース6)」、3GPP仕様書24.234v6.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規格を作成してください」 「独立している引き渡しが修理するメディア」、IEEE802.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、「Wirelessローカル・エリア・ネットワーク(WLAN)の織り込むことへの3GPPシステム」。 「ステージ3(リリース6)」、3GPP仕様書29.234v6.4.0、2005年10月。
[IEEE.8021X-2004]
IEEE, "Local and Metropolitan Area Networks: Port-Based
Network Access Control", IEEE Standard 802.1X, July 2004.
[IEEE.8021X-2004]IEEE、「地方とメトロポリタンエリアネットワーク:」 「ポートベースのネットワークアクセスコントロール」、IEEEの標準の802.1X、2004年7月。
Arkko, et al. Informational [Page 31] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[31ページ]のRFC5113ネットワーク発見とSP2008年1月
Appendix A. Existing Work
付録A.存在仕事
A.1. IETF
A.1。 IETF
Several IETF WGs have dealt with aspects of the network selection problem, including the AAA, EAP, PPP, RADIUS, ROAMOPS, and RADEXT WGs.
数個のIETF WGsがネットワーク選択問題の局面に対処しました、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].
元々[RFC2486]で定義して、次に[RFC4282]でアップデートして、ROAMOPS WGはNAIを開発しました。 初期のローミング実装は[RFC2194]で説明されます、そして、ローミングにおけるプロキシの使用は[RFC2607]で扱われます。 SEAMOBY WGはCARD[RFC4066]を開発しました。(CARDは適当な基地局の発見を助けます)。 PKIX WGは[RFC3280]を生産しました。(それは、証明書選択の問題を扱います)。 AAA WGはDiameter[RFC3588]の中で、より精巧なアクセスルーティング、認証、およびサービス発見メカニズムを開発しました。
Adrangi et al. [RFC4284] defines the use of the EAP-Request/Identity to provide "realm hints" useful for identity selection. The NAI syntax described in [RFC4282] enables the construction of source routes. Together, these mechanisms enable the user to determine whether it possesses an identity and corresponding credential suitable for use with an EAP-capable NAS. This is particularly useful in situations where the lower layer provides limited information (such as in wired IEEE 802 networks where IEEE 802.1X currently does not provide for advertisement of networks and their capabilities).
Adrangi他 [RFC4284]は、アイデンティティ選択の役に立つ「分野ヒント」を提供するためにEAP-要求/アイデンティティの使用を定義します。 [RFC4282]で説明されたNAI構文は送信元経路の構造を可能にします。 これらのメカニズムは、ユーザが、それにはEAPできるNASとの使用に適したアイデンティティと対応する資格証明書があるかどうかと決心しているのを一緒に、可能にします。 これは下層が限られた情報(IEEE 802.1Xが現在ネットワークと彼らの能力の広告に備えないワイヤードなIEEE802ネットワークなどの)を提供するところで状況で特に役に立ちます。
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の要求/アイデンティティの使用に基づく広告メカニズムはスケーラビリティ問題を持っています。最小のEAP Maximum Transmission Unit(MTU)は[RFC3748]セクション3.1に述べられるように1020の八重奏です、EAP-要求/アイデンティティがType-データ・フィールドの中の1015の八重奏を含むことができるように保証されるだけであるように。 RFC1035[RFC1035]が、Fully Qualified Domain Names(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
[Eronen03]に述べられるように、EAP-要求/アイデンティティの分野発見の使用は移管潜在にかなりの負の衝撃を持っています、これがどの分野がサポートされるかを説明するEAP-要求/アイデンティティを受けるために各Access PointとのEAPの会話を開始する必要があるステーションをもたらすかもしれないので。 IEEE802.11-2003がExtended Service Set(ESS)の中の(非認証されて、非連想される)の州1におけるClass1データフレームの使用をサポートしないので、これは、APsが、802.1Xがプレ認証(IEEE 802.11i-2004で任意の)であるとサポートしなければならないか、またはステーションがそれぞれと交際しなければならないのを含意します。
Arkko, et al. Informational [Page 32] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[32ページ]のRFC5113ネットワーク発見とSP2008年1月
AP prior to sending an EAPOL-Start to initiate EAP (here, EAPOL refers to EAP over LAN). This will dramatically increase handoff latency.
EAP(ここと、EAPOLはLANの上にEAPを呼ぶ)を開始するためにEAPOL-始めを送る前のAP。 これは移管潜在を劇的に増強するでしょう。
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プロキシによって送られるのを可能にするのはたぶん最も良いです。 この道、NASesが彼らが完全で最新の分野経路指定テーブルを維持するのを必要とするだろう「分野ヒント」を送るのは必要でないでしょう、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-アイデンティティ交換をもたらすかもしれません、「分野ヒント」の始発が次にコアAAAプロキシによって提供された「分野ヒント」でアップデートされたNASによって供給されている状態で。 一般に、コアAAAプロキシの上で「分野ヒント」を溯源するのは、より健全なアプローチであるように見えます、「運命共有」に備えるので--結局ヒントに基づく要求を発送する必要がある同じ実体(コアAAAプロキシ)による「分野ヒント」の世代。 コアAAAプロキシだけが、アップデートする必要があるでしょう、また、したがって、このアプローチは経営的視点から好まれます。 アップデートは全くNASデバイスに必要でないでしょう。
A.2. IEEE 802
A.2。 IEEE802
There has been work in several IEEE 802 working groups relating to network discovery:
ネットワーク発見に関連するいくつかのIEEE802ワーキンググループには仕事がありました:
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]はIEEE802.11の中でBeaconとProbe Responseメカニズムを定義します。 残念ながら、単に基本レートセットの中のレートか次の最も低いレートでBeaconsを送るかもしれません。セットは最も低いサポートしているレートから通常成ります。 [MACScale]などの研究はMAC層の性能問題を特定しました、そして、[Velayos]はBeacon間隔の低下からのスケーリング問題を特定しました。
o [IEEE-11-03-0827] discusses the evolution of authentication models
in WLANs and the need for the network to migrate from existing
o [IEEE-11-03-0827]はWLANsでの認証モデルの発展とネットワークが存在するので移行する必要性について議論します。
Arkko, et al. Informational [Page 33] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[33ページ]のRFC5113ネットワーク発見とSP2008年1月
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.
新しいものへのモデル、どちらかに基づいて、EAPは企業内情報通信網以上を表すために指摘かSSIDsの使用で層にします。 それはSSIDスペースの管理か構造の潜在的必要性に注意します。
The paper also notes that virtual APs have scalability issues. It
does not compare these scalability issues to those of alternative
solutions, however.
また、紙は、仮想のAPsにはスケーラビリティ問題があることに注意します。 しかしながら、それはこれらのスケーラビリティ問題を代替のソリューションのものと比較しません。
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になるように層にされます。 紙に述べられるように、各「仮想のAP」がBeaconsとProbe Responsesにおける使用に、異なったMACアドレス(BSSID)を使用する場合にだけ、802.11の既存のステーション実装との完全な互換性を維持できます。 この紙は、詳細に問題をスケーリングするとは議論しませんが、「仮想のAPs」の限られた数だけが単一の物理的なアクセスポイントによってサポートされることを勧めます。
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-000 u-tgu-要件][IEEE.802.11u]に取り組んでいます。 これはそれが使用できるアイデンティティがアクセスネットワークに認証することを決定するステーションを可能にするためのメカニズムを含んでいます、そのネットワークと交際する前に。 より早く注意されるように、この問題を解決するのは、APが最新の、そして、「デフォルトから自由な」分野経路指定テーブルを維持するのを必要とします。(経路指定テーブルはAAAインフラストラクチャの中でダイナミックルーティングサポートなしで可能ではありません)。 同様に、また、ホーム分野(登録などの)の中でサポートされた特徴の先験的な発見はダイナミックルーティングのスケーラブルな方法で実装する難しくて、欠けているサポートです。 ネットワーク能力(QoSサポートなどの)の決断はかなり簡単です、これらが唯一APの中に含まれたハードウェアとソフトウェアによるので。 しかしながら、802.11uはGeneric Advertisement Service(GAS)メカニズムに取り組んでいます。(802.21情報Service(ある)メッセージを伝えて、そのようにネットワーク側から情報を配布するより高度な方法を許容するのにそれを使用できます)。
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
o IEEE802.21、[IEEE、.802、.21、]、規格を開発すると、IEEE802と非IEEE802のネットワークの両方を含む異種のリンクレイヤの間の引き渡しは可能にされることになっています。 これを可能にするために、能力広告のための一般的機構(多分ネットワーク選択問題の局面のためになることができた)は開発されています、分野発見などのように。 例えば、IEEE802.21はネットワーク選択を助けるかもしれない成長しているInformation Elements(IEs)です、ともに2と層3を層にするために関連している情報を含んでいて。 また、質問メカニズム(XMLとTLVサポートの両方を含んでいる)も開発中です。 また、IEEE802.21は、質問の使用を許すためにResource記述Framework(リモート・データ・ファシリティ)図式を定義します。
Arkko, et al. Informational [Page 34] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[34ページ]のRFC5113ネットワーク発見とSP2008年1月
language (i.e., SPARQL). The schema is a normative part of IEEE
802.21 and also defined in [OHBA].
言語(すなわち、SPARQL)。 図式はIEEE802.21であってまた、[オオバ]で定義されていることの標準の部分です。
A.3. 3GPP
A.3。 3GPP
The 3GPP stage 2 technical specification [3GPPSA2WLANTS] covers the architecture of 3GPP Interworking WLAN (I-WLAN) with 2G and 3G networks. This specification also discusses realm discovery and network selection issues. The I-WLAN realm discovery procedure borrows ideas from the cellular Public Land-based Mobile Network (PLMN) selection principles, known as "PLMN Selection".
3GPPステージ2技術仕様書[3GPPSA2WLANTS]は2Gと3Gネットワークで3GPP Interworking WLAN(I-WLAN)のアーキテクチャをカバーしています。 また、この仕様は分野発見とネットワーク選択問題について議論します。 I-WLAN分野発見手順は「PLMN選択」として知られているセルPublic Landベースのモバイル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、Registered PLMN、またはVisited PLMNsの許容セットのものセルを選択するかもしれません。 PLMNリストは、加入者識別モジュール(SIM)で最優先して、保存されます。 手動のPLMN選択の場合では、モバイルノードは、それが周囲のセルから学ぶPLMNsを記載して、ユーザが必要な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]は手動の選択だけではなく、I-WLANローミングによって導入された新しい分野(PLMN)選択要件について議論します。(要件は自動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では、仲介者ネットワークはPLMNsです、そして、アクセスネットワークには1PLMNとのローミング協定があるかもしれないと思われます。 PLMNはホームPLMN(HPLMN)かVisited PLMNであるかもしれません(VPLMN)。(そこでは、ローミングがサポートされます)。 GSM/UMTSローミング原則は、VPLMNからPublic LandベースのモバイルホームNetwork(HPLMN)までのルーティングAAA要求にRADIUSかDiameterのどちらかを使用することで使われます。 仲介者ネットワークを選択するための手順は段階3つの技術仕様書[3GPPCT1WLANTS]と[3GPPCT4WLANTS]で指定されました。
Arkko, et al. Informational [Page 35] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[35ページ]のRFC5113ネットワーク発見とSP2008年1月
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 User Equipment(WLAN UE)にPLMNを自動的に選ばせるかもしれません、ユーザとオペレータの定義された好みに基づいて。
o AAA messages are routed based on the decorated or undecorated NAI.
o AAAメッセージは飾り付けかundecorated 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-応答/アイデンティティの中に未知の分野(Alternative 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]で説明されます。 3GPP貢献[3GPP-SA3-030736]でPLMN選択のためのセキュリティ要件について議論します。(それは、SSIDとEAPベースのメカニズムの両方には同様のセキュリティ弱点があると結論を下します)。 その結果、それは、PLMN広告がヒントであるとみなされるべきであることを勧めます。
A.4. Other
A.4。 他
[INTELe2e] discusses the need for realm selection where an access network may have more than one roaming relationship path to a home realm. It also describes solutions to the realm selection problem based on EAP, SSID and Protected EAP (PEAP) based mechanisms.
アクセスネットワークが1つ以上のローミング関係経路をホーム分野に持っているかもしれないところで[INTELe2e]は分野選択の必要性について議論します。 また、それはEAP、SSID、およびProtected EAPの(PEAP)ベースのメカニズムに基づく分野選択問題にソリューションについて説明します。
Eijk et al. [WWRF-ANS] discusses the realm and network selection problem. The authors concentrate primarily on discovery of access networks meeting a set of criteria, noting that information on the realm capabilities and reachability inherently resides in home AAA servers, and therefore it is not readily available in a central location, and may not be easily obtained by NAS devices.
Eijk他 [WWRF-ANS]は分野とネットワーク選択問題について議論します。 作者は主として1セットの評価基準を満たすアクセスネットワークの発見に集中します、分野能力と可到達性の情報が本来ホームAAAサーバであって、したがって、それが中心の位置で容易に利用可能でなく、またNASデバイスによって容易に得られないかもしれないことに注意して。
Arkko, et al. Informational [Page 36] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[36ページ]のRFC5113ネットワーク発見とSP2008年1月
Appendix B. Acknowledgements
付録B.承認
The authors of this document would like to especially acknowledge the contributions of Farid Adrangi, Michael Richardson, Pasi Eronen, Mark Watson, Mark Grayson, Johan Rune, and Tomas Goldbeck-Lowe.
このドキュメントの作者はファリドAdrangi、マイケル・リチャードソン、パシEronen、マーク・ワトソン、マーク・グレーソン、ジョハンRune、およびトマス・ゴールドベック-ロウの貢献を特に承諾したがっています。
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、ビクタのロルツ、スティーブン・ヘイズ、およびデヴィッド・ジョンストンに感謝申し上げます。
Jouni Korhonen would like to thank the Academy of Finland for providing funding to work on this document.
Jouni Korhonenは、基金を提供するためのフィンランドのAcademyがこのドキュメントに取り組むのに感謝したがっています。
Arkko, et al. Informational [Page 37] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[37ページ]のRFC5113ネットワーク発見とSP2008年1月
Authors' Addresses
作者のアドレス
Jari Arkko Ericsson Jorvas 02420 Finland
ヤリArkkoエリクソンJorvas02420フィンランド
EMail: jari.arkko@ericsson.com
メール: jari.arkko@ericsson.com
Bernard Aboba Microsoft One Microsoft Way Redmond, WA 98052 USA
バーナードAbobaマイクロソフト1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: bernarda@microsoft.com
メール: bernarda@microsoft.com
Jouni Korhonen TeliaSonera Teollisuuskatu 13 Sonera FIN-00051 Finland
Jouni Korhonen TeliaSonera Teollisuuskatu13ソネラフィン-00051フィンランド
EMail: jouni.korhonen@teliasonera.com
メール: jouni.korhonen@teliasonera.com
Farooq Bari AT&T 7277 164th Avenue N.E. Redmond WA 98052 USA
ファルークバリAT&T7277第164アベニューの東北レッドモンドワシントン98052米国
EMail: farooq.bari@att.com
メール: farooq.bari@att.com
Arkko, et al. Informational [Page 38] RFC 5113 Network Discovery and SP January 2008
Arkko、他 情報[38ページ]のRFC5113ネットワーク発見とSP2008年1月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Arkko, et al. Informational [Page 39]
Arkko、他 情報[39ページ]
一覧
スポンサーリンク
