RFC2977 日本語訳
2977 Mobile IP Authentication, Authorization, and AccountingRequirements. S. Glass, T. Hiller, S. Jacobs, C. Perkins. October 2000. (Format: TXT=63520 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Glass
Request for Comments: 2977 Sun Microsystems
Category: Informational T. Hiller
Lucent Technologies
S. Jacobs
GTE Laboratories
C. Perkins
Nokia Research Center
October 2000
コメントを求めるワーキンググループS.ガラス要求をネットワークでつないでください: 2977年のサン・マイクロシステムズカテゴリ: 情報のT.の研究所C.パーキンスノキアリサーチセンター培土板ルーセントテクノロジーズS.ジェイコブズGTE2000年10月
Mobile IP Authentication, Authorization, and Accounting Requirements
モバイルIP認証、承認、および会計要件
Status of this Memo
この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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
The Mobile IP and Authentication, Authorization, Accounting (AAA) working groups are currently looking at defining the requirements for Authentication, Authorization, and Accounting. This document contains the requirements which would have to be supported by a AAA service to aid in providing Mobile IP services.
モバイルIPとAuthentication、Authorization、Accounting(AAA)ワーキンググループは現在、Authentication、Authorization、およびAccountingのための要件を定義するのを検討しています。 このドキュメントはモバイルIPサービスを提供する際に支援するためにAAAサービスでサポートされなければならない要件を含んでいます。
1. Introduction
1. 序論
Clients obtain Internet services by negotiating a point of attachment to a "home domain", generally from an ISP, or other organization from which service requests are made, and fulfilled. With the increasing popularity of mobile devices, a need has been generated to allow users to attach to any domain convenient to their current location. In this way, a client needs access to resources being provided by an administrative domain different than their home domain (called a "foreign domain"). The need for service from a foreign domain requires, in many models, Authorization, which leads directly to Authentication, and of course Accounting (whence, "AAA"). There is some argument which of these leads to, or is derived from the others, but there is common agreement that the three AAA functions are closely interdependent.
クライアントは「ホームドメイン」と接着点を交渉することによって、インターネットのサービスを得ます、一般にサービスのリクエストが作られていて、実現するISP、または他の組織から。 モバイル機器の増加する人気で、必要性は、ユーザが彼らの現在の位置に便利などんなドメインにも付くのを許容するために生まれました。 このように、クライアントはそれらのホームドメイン(「外国ドメイン」と呼ばれる)と異なった管理ドメインによって提供されるリソースへのアクセスを必要とします。 外国ドメインからのサービスの必要性は多くのモデルでAuthorizationともちろんAccounting(起源、「AAA」)を必要とします。(Authorizationは直接Authenticationに通じます)。 これらの先導のどれが何らかの議論にあるか、他のものから派生しますが、3つのAAA機能が密接に互いに依存しているという一般的な協定があります。
Glass, et al. Informational [Page 1] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[1ページ]のRFC2977
An agent in a foreign domain, being called on to provide access to a resource by a mobile user, is likely to request or require the client to provide credentials which can be authenticated before access to resources is permitted. The resource may be as simple as a conduit to the Internet, or may be as complex as access to specific private resources within the foreign domain. Credentials can be exchanged in many different ways, all of which are beyond the scope of this document. Once authenticated, the mobile user may be authorized to access services within the foreign domain. An accounting of the actual resources may then be assembled.
モバイルユーザでリソースへのアクセスを提供するよう呼びかけられた外国ドメインのエージェントが、クライアントがリソースへのアクセスが受入れられる前に認証できる資格証明書を提供するのが要求しそうであるか、または必要でありそうです。 リソースは、インターネットに経路と同じくらい簡単であるかもしれないか、外国ドメインの中の特定の個人的なリソースへのアクセスとまたは同じくらい複雑であるかもしれません。 多くの異なった方法で資格証明書を交換できます。そのすべてがこのドキュメントの範囲にあります。 いったん認証されると、モバイルユーザが外国ドメインの中でサービスにアクセスするのに権限を与えられるかもしれません。 そして、実際のリソースの会計は組み立てられるかもしれません。
Mobile IP is a technology that allows a network node ("mobile node")
to migrate from its "home" network to other networks, either within
the same administrative domain, or to other administrative domains.
The possibility of movement between domains which require AAA
services has created an immediate demand to design and specify AAA
protocols. Once available, the AAA protocols and infrastructure will
provide the economic incentive for a wide-ranging deployment of
Mobile IP. This document will identify, describe, and discuss the
functional and performance requirements that Mobile IP places on AAA
protocols.
モバイルIPはネットワーク・ノード(「モバイルノード」)が「ホーム」ネットワークから他のネットワークまで同じ管理ドメイン以内か他の管理ドメインに移行することができる技術です。 AAAサービスを必要とするドメインの間の動きの可能性はAAAプロトコルを設計して、指定するという速急の需要を作成しました。 かつて利用可能であることで、AAAプロトコルとインフラストラクチャはモバイルIPの広範囲の展開に経済的誘因を提供するでしょう。 このドキュメントは、モバイルIPがAAAプロトコルで入賞するという機能的、そして、性能要件を特定して、説明して、議論するでしょう。
The formal description of Mobile IP can be found in [13,12,14,17].
[13、12、14、17]でモバイルIPの形式的記述を見つけることができます。
In this document, we have attempted to exhibit requirements in a progressive fashion. After showing the basic AAA model for Mobile IP, we derive requirements as follows:
本書では、私たちは、進歩的なやり方による要件を示すのを試みました。 モバイルIPの基本的なAAAモデルを見せていた後に、私たちは以下の要件を引き出します:
- requirements based on the general model - requirements based on providing IP service for mobile nodes - requirements derived from specific Mobile IP protocol needs
- 一般的なモデルに基づく要件--モバイルノードのためのIPサービスを提供することに基づいた要件--特定のモバイルIPプロトコルの必要性から得られた要件
Then, we exhibit some related AAA models and describe requirements derived from the related models.
次に、私たちは、何人かの関連するAAAモデルを示して、関連するモデルから得られた要件について説明します。
2. Terminology
2. 用語
This document frequently uses the following terms in addition to those defined in RFC 2002 [13]:
このドキュメントは頻繁にRFC2002[13]で定義されたものに加えて次の用語を使用します:
Accounting The act of collecting information on resource usage
for the purpose of trend analysis, auditing, billing,
or cost allocation.
傾向変動分析、監査、支払い、または費用配分の目的のためにリソース用法における情報集めの行為を説明します。
Glass, et al. Informational [Page 2] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[2ページ]のRFC2977
Administrative Domain
An intranet, or a collection of networks, computers,
and databases under a common administration.
Computer entities operating in a common
administration may be assumed to share
administratively created security associations.
管理Domain Anイントラネット、または一般的な管理の下におけるネットワーク、コンピュータ、およびデータベースの収集。 一般的な管理で作動するコンピュータ実体が行政上作成されたセキュリティ協会を共有すると思われるかもしれません。
Attendant A node designed to provide the service interface
between a client and the local domain.
クライアントと局所領域とのサービスインタフェースを提供するように設計された付き添いのAノード。
Authentication
The act of verifying a claimed identity, in the form
of a pre-existing label from a mutually known name
space, as the originator of a message (message
authentication) or as the end-point of a channel
(entity authentication).
認証はアイデンティティであると主張されたaについて確かめる行為(互いに知られている名前からの先在のラベルのフォームがメッセージの創始者(通報認証)として、または、チャンネルのエンドポイント(実体認証)として区切るコネ)です。
Authorization
The act of determining if a particular right, such as
access to some resource, can be granted to the
presenter of a particular credential.
決定するのにもかかわらずの、a特定の行為が何らかのリソースへのアクセスなどのように正す承認を特定の資格証明書のプレゼンターに与えることができます。
Billing The act of preparing an invoice.
準備の行為にインボイスを請求します。
Broker An intermediary agent, trusted by two other AAA
servers, able to obtain and provide security services
from those AAA servers. For instance, a broker may
obtain and provide authorizations, or assurances that
credentials are valid.
他の2つのAAAサーバによって信じられたそれらのAAAサーバからセキュリティー・サービスを得て、提供するのにおいて有能なAn仲介業者を仲介してください。 例えば、ブローカーは、資格証明書が有効であるという承認、または保証を得て、提供するかもしれません。
Client A node wishing to obtain service from an attendant
within an administrative domain.
管理ドメインの中の付添人からサービスを得たがっているクライアントAノード。
Foreign Domain
An administrative domain, visited by a Mobile IP
client, and containing the AAA infrastructure needed
to carry out the necessary operations enabling Mobile
IP registrations. From the point of view of the
foreign agent, the foreign domain is the local
domain.
モバイルIPクライアントによって訪問されて、モバイルIP登録証明書を可能にする必要な操作を行うのに必要であるAAAインフラストラクチャを含む外国Domain An管理ドメイン。 外国人のエージェントの観点から、外国ドメインは局所領域です。
Inter-domain Accounting
Inter-domain accounting is the collection of
information on resource usage of an entity with an
administrative domain, for use within another
administrative domain. In inter-domain accounting,
accounting packets and session records will typically
cross administrative boundaries.
相互ドメインAccounting Inter-ドメイン会計は実体のリソース用法における管理ドメインがある情報の収集です、別の管理ドメインの中の使用のために。 相互ドメイン会計では、会計パケットとセッション記録は管理境界を通常越えるでしょう。
Glass, et al. Informational [Page 3] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[3ページ]のRFC2977
Intra-domain Accounting
Intra-domain accounting is the collection of
information on resource within an administrative
domain, for use within that domain. In intra-domain
accounting, accounting packets and session records
typically do not cross administrative boundaries.
イントラドメインAccounting Intra-ドメイン会計はそのドメインの中の使用のための管理ドメインの中のリソースにおける情報の収集です。 イントラドメイン会計では、会計パケットとセッション記録は管理境界を通常越えません。
Local Domain
An administrative domain containing the AAA
infrastructure of immediate interest to a Mobile IP
client when it is away from home.
それが家にいないときに即座にモバイルIPクライアントへの関心のAAAインフラストラクチャを含む地方のDomain An管理ドメイン。
Real-time Accounting
Real-time accounting involves the processing of
information on resource usage within a defined time
window. Time constraints are typically imposed in
order to limit financial risk.
リアルタイムのAccountingレアル-時間会計は定義されたタイムウィンドウの中のリソース用法で情報の処理にかかわります。 時間規制は、財政危機を制限するために通常課されます。
Session record
A session record represents a summary of the resource
consumption of a user over the entire session.
Accounting gateways creating the session record may
do so by processing interim accounting events.
セッション記録Aセッション記録は全体のセッションの間、ユーザのリソース消費の概要を表します。 セッション記録を作成する会計ゲートウェイは処理でそう当座の会計イベントをするかもしれません。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [4].
そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、[4]で説明されるように解釈されることになっていてください、」であるべきです
3. Basic Model
3. 基本型
In this section, we attempt to capture the main features of a basic model for operation of AAA servers that seems to have good support within the Mobile IP working group. Within the Internet, a client belonging to one administrative domain (called the home domain) often needs to use resources provided by another administrative domain (called the foreign domain). An agent in the foreign domain that attends to the client's request (call the agent the "attendant") is likely to require that the client provide some credentials that can be authenticated before access to the resources is permitted. These credentials may be something the foreign domain understands, but in most cases they are assigned by, and understood only by the home domain, and may be used for setting up secure channels with the mobile node.
このセクションでは、私たちは、モバイルIPワーキンググループの中に良いサポートを持っているように思えるAAAサーバの操作のために基本型の主な出し物を得るのを試みます。 インターネットの中では、1つの管理ドメイン(ホームドメインと呼ばれる)に属すクライアントは、しばしば別の管理ドメイン(外国ドメインと呼ばれる)のそばで調達資金を使用する必要があります。 クライアントの要求(エージェントを「付添人」と呼ぶ)に気を配る外国ドメインのエージェントがクライアントがリソースへのアクセスが受入れられる前に認証できるいくつかの資格証明書を提供するのが必要でありそうです。 これらの資格証明書が外国ドメインが理解している何かであるかもしれませんが、多くの場合、それらは、ホームドメインだけによって割り当てられて理解されていて、モバイルノードの安全なチャンネルをセットアップするのに使用されるかもしれません。
Glass, et al. Informational [Page 4] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[4ページ]のRFC2977
Local Domain Home Domain
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| | AAAL | | | | AAAH | |
| | +-------------------+ | |
| +---+--+ | | +------+ |
| | | | |
| | | +----------------------+
+------+ | +---+--+ |
| | | | | | C = client
| C |- -|- -| A | | A = attendant
| | | | | | AAAL = local authority
+------+ | +------+ | AAAH = home authority
| |
+--------------+
局所領域ホームドメイン+--------------+ +----------------------+ | +------+ | | +------+ | | | | | | | | | | | AAAL| | | | AAAH| | | | +-------------------+ | | | +---+--+ | | +------+ | | | | | | | | | +----------------------+ +------+ | +---+--+ | | | | | | | Cはクライアントと等しいです。| C|- -|- -| A| | =付添人| | | | | | AAALは地方公共団体+と等しいです。------+ | +------+ | AAAHはホーム権威と等しいです。| | +--------------+
Figure 1: AAA Servers in Home and Local Domains
図1: ホームにおけるAAAサーバと局所領域
The attendant often does not have direct access to the data needed to complete the transaction. Instead, the attendant is expected to consult an authority (typically in the same foreign domain) in order to request proof that the client has acceptable credentials. Since the attendant and the local authority are part of the same administrative domain, they are expected to have established, or be able to establish for the necessary lifetime, a secure channel for the purposes of exchanging sensitive (access) information, and keeping it private from (at least) the visiting mobile node.
付添人はしばしば取引を完了するのに必要であるデータにダイレクトに近づく手段を持っているというわけではありません。 代わりに、付添人がクライアントには許容できる資格証明書があるという証拠を要求するために、権威(通常同じ外国ドメインの)に相談すると予想されます。 付添人と地方公共団体が同じ管理ドメインの一部であるので、彼らは、設立したか、または必要な生涯、機密の(アクセス)情報を交換する目的のための安全なチャンネルのために設立できるように予想されていて、(少なくとも)訪問のモバイルノードから個人的にそれを保っています。
The local authority (AAAL) itself may not have enough information stored locally to carry out the verification for the credentials of the client. In contrast to the attendant, however, the AAAL is expected to be configured with enough information to negotiate the verification of client credentials with external authorities. The local and the external authorities should be configured with sufficient security relationships and access controls so that they, possibly without the need for any other AAA agents, can negotiate the authorization that may enable the client to have access to any/all requested resources. In many typical cases, the authorization depends only upon secure authentication of the client's credentials.
地方公共団体(AAAL)自体で、クライアントの資格証明書のための検証を行うために局所的に十分な情報を保存しないかもしれません。 しかしながら、付添人と対照して、外部の当局とのクライアント資格証明書の検証を交渉できるくらいの情報によってAAALが構成されると予想されます。 地方の当局と外部の当局が十分なセキュリティ関係とアクセス制御によって構成されるべきであるので、ことによるといかなる他のAAAのエージェントの必要性なしでもクライアントがどんな/にも近づく手段を持っているのを可能にするかもしれない承認は交渉できるのがリソースをすべて要求しました。 多くの典型的な場合では、承認はクライアントの資格証明書の安全な認証だけによります。
Once the authorization has been obtained by the local authority, and the authority has notified the attendant about the successful negotiation, the attendant can provide the requested resources to the client.
いったん地方公共団体で承認を得て、権威がうまくいっている交渉に関して付添人に通知すると、付添人は要求されたリソースをクライアントに提供できます。
Glass, et al. Informational [Page 5] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[5ページ]のRFC2977
In the picture, there might be many attendants for each AAAL, and there might be many clients from many different Home Domains. Each Home Domain provides a AAAH that can check credentials originating from clients administered by that Home Domain.
画像には、それぞれのAAALの多くの付添人がいるかもしれません、そして、多くの異なったホームDomainsからの多くのクライアントがいるかもしれません。 それぞれのホームDomainはそのホームDomainによって管理されたクライアントから発する資格証明書をチェックできるAAAHを提供します。
There is a security model implicit in the above figure, and it is crucial to identify the specific security associations assumed in the security model.
上図で内在している機密保護モデルがいます、そして、機密保護モデルで想定された特定のセキュリティ協会を特定するのは重要です。
First, it is natural to assume that the client has a security association with the AAAH, since that is roughly what it means for the client to belong to the home domain.
まず最初に、クライアントにはAAAHとのセキュリティ協会があると仮定するのは当然です、それがおよそクライアントがホームドメインに属すそれが意味することであるので。
Second, from the model illustrated in figure 1 it is clear that AAAL and AAAH have to share a security association, because otherwise they could not rely on the authentication results, authorizations, nor even the accounting data which might be transacted between them. Requiring such bilateral security relationships is, however, in the end not scalable; the AAA framework MUST provide for more scalable mechanisms, as suggested below in section 6.
2番目に、1図で例証されたモデルからAAALとAAAHがセキュリティ協会を共有しなければならないのは、明確です、さもなければ、彼らが認証結果、承認、およびそれらの間で商取引されるかもしれない会計データさえ当てにすることができなかったので。 しかしながら、そのような双方のセキュリティ関係を必要とするのは結局、スケーラブルではありません。 AAAフレームワークは以下にセクション6で示されるように、よりスケーラブルなメカニズムに備えなければなりません。
Finally, in the figure, it is clear that the attendant can naturally share a security association with the AAAL. This is necessary in order for the model to work because the attendant has to know that it is permissible to allocate the local resources to the client.
最終的に、図では、付添人が自然にAAALとのセキュリティ協会を共有できるのは、明確です。 付添人が、ローカル資源をクライアントに割り当てるのが許されているのを知らなければならないのでモデルが働くのにこれが必要です。
As an example in today's Internet, we can cite the deployment of RADIUS [16] to allow mobile computer clients to have access to the Internet by way of a local ISP. The ISP wants to make sure that the mobile client can pay for the connection. Once the client has provided credentials (e.g., identification, unique data, and an unforgeable signature), the ISP checks with the client's home authority to verify the signature, and to obtain assurance that the client will pay for the connection. Here, the attendant function can be carried out by the NAS, and the local and home authorities can use RADIUS servers. Credentials allowing authorization at one attendant SHOULD be unusable in any future negotiations at the same or any other attendant.
今日のインターネットの例として、私たちは、モーバイルコンピュータクライアントが地方のISPを通してインターネットに近づく手段を持っているのを許容するためにRADIUS[16]の展開を引用できます。 確実にモバイルクライアントにそれを作るISP必需品は接続のために支払われることができます。 ISPは、一度、クライアントが資格証明書(例えば、識別、ユニークなデータ、および非鍛造可能署名)を提供したことがあると署名について確かめて、クライアントが接続の対価を支払うという保証を得るクライアントのホーム権威に問い合わせます。 ここと、NASは付き添いの機能を行うことができます、そして、地方とホーム当局はRADIUSサーバを使用できます。 使用不可能なコネが同じくらいかいかなる他の付添人のあらゆる今後の交渉であったならもある付添人SHOULDに承認を許容する資格証明書。
From the description and example above, we can identify several requirements.
記述と例から、上では、私たちがいくつかの要件を特定できます。
- Each local attendant has to have a security relationship with the
local AAA server (AAAL)
- The local authority has to share, or dynamically establish,
security relationships with external authorities that are able to
check client credentials
- それぞれの地元の付添人には、ローカルのAAAサーバ(AAAL)がある安全保障関係がなければなりません--地方公共団体は、クライアント資格証明書をチェックできる外部の当局とのセキュリティ関係を共有しなければならないか、またはダイナミックに確立しなければなりません。
Glass, et al. Informational [Page 6] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[6ページ]のRFC2977
- The attendant has to keep state for pending client requests while
the local authority contacts the appropriate external authority
- Since the mobile node may not necessarily initiate network
connectivity from within its home domain, it MUST be able to
provide complete, yet unforgeable credentials without ever having
been in touch with its home domain.
- Since the mobile node's credentials have to remain unforgeable,
intervening nodes (e.g., neither the attendant or the local
authority (AAAL) or any other intermediate nodes) MUST NOT be able
to learn any (secret) information which may enable them to
reconstruct and reuse the credentials.
- 地方公共団体が適切な外部の権威に連絡している間、付添人は未定のクライアント要求のために状態を維持しなければなりません--モバイルノードが必ずホームドメインからネットワークの接続性を開始するかもしれないというわけではないので、今までにホームドメインと接触していたことがなくて、それは完全で、しかし、非鍛造可能な資格証明書を提供できなければなりません。 - モバイルノードの資格証明書が非鍛造可能なままで残らなければならないので、介入しているノード(例えば、付添人か地方公共団体(AAAL)もいかなる他の中間的でないノードも)は資格証明書を再建して、再利用するのを可能にするかもしれないどんな(秘密)の情報も学ぶことができるはずがありません。
From this last requirement, we can see the reasons for the natural requirement that the client has to share, or dynamically establish, a security relationship with the external authority in the Home Domain. Otherwise, it is technically infeasible (given the implied network topology) for the client to produce unforgeable signatures that can be checked by the AAAH. Figure 2 illustrates the natural security associations we understand from our proposed model. Note that, according to the discussion in section 6, there may, by mutual agreement between AAAL and AAAH, be a third party inserted between AAAL and AAAH to help them arbitrate secure transactions in a more scalable fashion.
この最後の要件から、私たちはクライアントが安全保障関係を共有しなければならないか、または外部の権威がホームDomainにある状態でダイナミックに確立しなければならないという自然な要件の理由をわかることができます。 さもなければ、クライアントがAAAHがチェックできる非鍛造可能署名を起こすのは、技術的に実行不可能です(暗示しているネットワーク形態を与えます)。 図2は私たちが私たちの提案されたモデルから理解した自然なセキュリティ協会を例証します。 セクション6での議論に従って彼らが、よりスケーラブルなファッションで安全なトランザクションを仲裁するのを助けるためにAAALとAAAHの間に挿入された第三者がAAALとAAAHの間の合意でいるかもしれないことに注意してください。
+------+ +------+
| | | |
| AAAL +--------------+ AAAH |
| | | |
+---+--+ +--+---+
| |
| |
+---+--+ +--+---+
C = client | | | |
A = attendant | A | | C |
AAAL = local authority | | | |
AAAH = home authority +------+ +------+
+------+ +------+ | | | | | AAAL+--------------+ AAAH| | | | | +---+--+ +--+---+ | | | | +---+--+ +--+---+ C=クライアント| | | | =付添人| A| | C| AAALは地方公共団体と等しいです。| | | | AAAHはホーム権威+と等しいです。------+ +------+
Figure 2: Security Associations
図2: セキュリティ協会
In addition to the requirements listed above, we specify the following requirements which derive from operational experience with today's roaming protocols.
上にリストアップされた要件に加えて、私たちは今日のローミングプロトコルの運用経験に由来している以下の要件を指定します。
- There are scenarios in which an attendant will have to manage
requests for many clients at the same time.
- The attendant MUST protect against replay attacks.
- 付添人が同時に多くのクライアントを求める要求を管理しなければならないシナリオがあります。 - 付添人は反射攻撃から守らなければなりません。
Glass, et al. Informational [Page 7] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[7ページ]のRFC2977
- The attendant equipment should be as inexpensive as possible,
since it will be replicated as many times as possible to handle as
many clients as possible in the foreign domain.
- Attendants SHOULD be configured to obtain authorization, from a
trusted local AAA server (AAAL) for Quality of Service
requirements placed by the client.
- それが扱うのにおいて可能であるとしての可能の多くの倍のクライアントとして模写されるので、付き添いの設備はできるだけ外国ドメインで安価であるべきです。 - 付添人SHOULDが承認を得るために構成されて、信じられた地方のAAAから、Service要件のQualityのためのサーバ(AAAL)はクライアントで入賞しました。
Nodes in two separate administrative domains (for instance, AAAH and AAAL) often must take additional steps to verify the identity of their communication partners, or alternatively to guarantee the privacy of the data making up the communication. While these considerations lead to important security requirements, as mentioned above in the context of security between servers, we consider the exact choice of security associations between the AAA servers to be beyond the scope of this document. The choices are unlikely even to depend upon any specific features of the general model illustrated in figure 1. On the other hand, the security associations needed between Mobile IP entities will be of central importance in the design of a suitable AAA infrastructure for Mobile IP. The general model shown above is generally compatible with the needs of Mobile IP. However, some basic changes are needed in the security model of Mobile IP, as detailed in section 5.
2つの別々の管理ドメイン(例えば、AAAHとAAAL)のノードは、彼らのコミュニケーションパートナーのアイデンティティについて確かめるか、または代わりにコミュニケーションを作るデータのプライバシーを保証するためにしばしば追加方法を採らなければなりません。 これらの問題が重要なセキュリティ要件につながっている間、サーバの間のセキュリティの文脈で上に言及されるように、私たちは、AAAサーバの間のセキュリティ協会の正確な選択がこのドキュメントの範囲を超えていると考えます。 選択は図1で例証された一般的なモデルのどんな特定の特徴にも依存さえしそうにはありません。 他方では、モバイルIP実体の間で必要であるセキュリティ協会はモバイルIPに、適当なAAAインフラストラクチャのデザインで中央に重要性になるでしょう。 一般に、上で見せられた一般的なモデルはモバイルIPの必要性と互換性があります。 しかしながら、いくつかの基本的な変化がセクション5で詳しく述べられるようにモバイルIPの機密保護モデルで必要です。
Lastly, recent discussion in the mobile-ip working group has indicated that the attendant MUST be able to terminate service to the client based on policy determination by either AAAH or AAAL server.
最後に、モバイル-ipワーキンググループにおける最近の議論は、付添人がAAAHかAAALサーバのどちらかで方針決断に基づくクライアントに対するサービスを終えることができなければならないのを示しました。
3.1. AAA Protocol Roaming Requirements
3.1. AAAプロトコルローミング要件
In this section we will detail additional requirements based on issues discovered through operational experience of existing roaming RADIUS networks. The AAA protocol MUST satisfy these requirements in order for providers to offer a robust service. These requirements have been identified by TR45.6 as part of their involvement with the Mobile IP working group.
このセクションで、私たちはRADIUSネットワークに移動しながら存在する運用経験で発見された問題に基づく追加要件を詳しく述べるつもりです。 プロバイダーが体力を要しているサービスを提供するように、AAAプロトコルはこれらの要件を満たさなければなりません。 これらの要件はモバイルIPワーキンググループへのそれらのかかわり合いの一部としてTR45.6によって特定されました。
- Support a reliable AAA transport mechanism.
* There must be an effective hop-by-hop retransmission and
failover mechanism so that reliability does not solely depend
on end-to-end retransmission
* This transport mechanism will be able indicate to an AAA
application that a message was delivered to the next peer AAA
application or that a time out occurred.
* Retransmission is controlled by the reliable AAA transport
mechanism, and not by lower layer protocols such as TCP.
- 信頼できるAAAが移送機構であるとサポートしてください。 * *この移送機構はできるでしょう。ホップごとの有効な「再-トランスミッション」とフェイルオーバーメカニズムがあるに違いないので信頼性が唯一終わらせる終わりであることでよらない、「再-トランスミッション」、メッセージが次の同輩AAAアプリケーションに提供されたか、またはタイムアウトが起こったのをAAAアプリケーションに示してください。 * RetransmissionはTCPなどの下位層プロトコルによって制御されるのではなく、信頼できるAAA移送機構によって制御されます。
Glass, et al. Informational [Page 8] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[8ページ]のRFC2977
* Even if the AAA message is to be forwarded, or the message's
options or semantics do not conform with the AAA protocol, the
transport mechanism will acknowledge that the peer received the
AAA message.
* Acknowledgements SHOULD be allowed to be piggybacked in AAA
messages
* AAA responses have to be delivered in a timely fashion so that
Mobile IP does not timeout and retransmit
- Transport a digital certificate in an AAA message, in order to
minimize the number of round trips associated with AAA
transactions. Note: This requirement applies to AAA applications
and not mobile stations. The certificates could be used by
foreign and home agents to establish an IPSec security association
to secure the mobile node's tunneled data. In this case, the AAA
infrastructure could assist by obtaining the revocation status of
such a certificate (either by performing online checks or
otherwise validating the certificate) so that home and foreign
agents could avoid a costly online certificate status check.
- Provide message integrity and identity authentication on a hop-
by-hop (AAA node) basis.
- Support replay protection and optional non-repudiation
capabilities for all authorization and accounting messages. The
AAA protocol must provide the capability for accounting messages
to be matched with prior authorization messages.
- Support accounting via both bilateral arrangements and via broker
AAA servers providing accounting clearinghouse and reconciliation
between serving and home networks. There is an explicit agreement
that if the private network or home ISP authenticates the mobile
station requesting service, then the private network or home ISP
network also agrees to reconcile charges with the home service
provider or broker. Real time accounting must be supported.
Timestamps must be included in all accounting packets.
* AAAメッセージが進めることであるまたはメッセージのオプションか意味論がAAAプロトコルに従わないでも、移送機構は、同輩がAAAメッセージを受け取ったと認めるでしょう。 * 承認SHOULDは直ちにモバイルIPがどんなタイムアウトもしないように応答が提供されなければならないAAAメッセージ*AAAで背負われるのが許容されていて、再送します--AAAメッセージのデジタル証明書を輸送してください、AAAトランザクションに関連している周遊旅行の数を最小にするために。 以下に注意してください。 この要件は移動局ではなく、AAAアプリケーションに適用されます。 外国とホームのエージェントは、モバイルノードのトンネルを堀られたデータを保証するIPSecセキュリティ協会を証明するのに証明書を使用できました。 この場合、AAAインフラストラクチャは、ホームと外国人のエージェントが高価なオンライン証明書状態チェックを避けることができるようにそのような証明書(オンラインチェックを実行するか、またはそうでなければ、証明書を有効にするのによる)の取消し状態を得ることによって、補助されることができるでしょう。 - ホップによる(AAAノード)基礎をホップにおけるメッセージの保全とアイデンティティ認証に提供してください。 - すべての承認と会計メッセージのために反復操作による保護と任意の非拒否が能力であるとサポートしてください。 AAAプロトコルは先の承認メッセージに合わせられるべき会計メッセージに能力を提供しなければなりません。 - 会計情報センターと和解を給仕とホームネットワークの間に提供して、両方の双方のアレンジメントを通してブローカーAAAサーバで会計をサポートしてください。 また、私設のネットワークかホームISPがサービスを要求する移動局を認証するなら私設のネットワークかホームISPネットワークが、ホームサービスプロバイダーかブローカーと充電を仲直りさせるのに同意するという明白な協定があります。 リアルタイムの会計をサポートしなければなりません。 すべての会計パケットにタイムスタンプを含まなければなりません。
4. Requirements related to basic IP connectivity
4. 基本のIPの接続性に関連する要件
The requirements listed in the previous section pertain to the relationships between the functional units, and don't depend on the underlying network addressing. On the other hand, many nodes (mobile or merely portable) are programmed to receive some IP-specific resources during the initialization phase of their attempt to connect to the Internet.
前項でリストアップされた要件は、機能的なユニットの間の関係に関係して、基本的なネットワークアドレシングによりません。 他方では、多くのノード(モバイルの、または、単に携帯用の)がインターネットに接続する彼らの試みの初期設定段階の間、いくつかのIP特有のリソースを受け取るようにプログラムされます。
We place the following additional requirements on the AAA services in order to satisfy such clients.
私たちは、そのようなクライアントを満たすために以下の追加要件をAAAサービスに置きます。
- Either AAA server MUST be able to obtain, or to coordinate the
allocation of, a suitable IP address for the customer, upon
request by the customer.
- AAAサーバが得なければならないか、または配分を調整できなければならないどちらか(顧客にとって、適当なIPアドレス)が顧客を要求します。
Glass, et al. Informational [Page 9] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[9ページ]のRFC2977
- AAA servers MUST be able to identify the client by some means
other than its IP address.
- IPアドレスを除いて、AAAサーバはどうでもクライアントを特定できなければなりません。
Policy in the home domain may dictate that the home agent instead of the AAAH manages the allocation of an IP address for the mobile node. AAA servers MUST be able to coordinate the allocation of an IP address for the mobile node at least in this way.
ホームドメインの方針は、AAAHの代わりにホームのエージェントがモバイルノードのためのIPアドレスの配分を管理すると決めるかもしれません。 AAAサーバは少なくともこのようにモバイルノードのためのIPアドレスの配分を調整できなければなりません。
AAA servers today identify clients by using the Network Access Identifier (NAI) [1]. A mobile node can identify itself by including the NAI along with the Mobile IP Registration Request [6]. The NAI is of the form "user@realm"; it is unique and well suited for use in the AAA model illustrated in figure 1. Using a NAI (e.g., "user@realm") allows AAAL to easily determine the home domain (e.g., "realm") for the client. Both the AAAL and the AAAH can use the NAI to keep records indexed by the client's specific identity.
AAAサーバは、今日、Network Access Identifier(NAI)[1]を使用することによって、クライアントを特定します。 モバイルノードは、モバイルIP Registration Request[6]と共にNAIを含んでいることによって、それ自体を特定できます。 NAIはフォーム" user@realm "のものです。 それはユニークです、そして、使用によく合って、1は図でAAAモデルでは、例証していました。 NAI(例えば、" user@realm ")を使用するのに、AAALはクライアントのために、容易に、ホームドメイン(例えば、「分野」)を決定できます。 AAALとAAAHの両方が、クライアントの特定のアイデンティティで記録に索引をつけ続けるのにNAIを使用できます。
5. AAA for Mobile IP
5. モバイルIPのためのAAA
Clients using Mobile IP require specific features from the AAA services, in addition to the requirements already mentioned in connection with the basic AAA functionality and what is needed for IP connectivity. To understand the application of the general model for Mobile IP, we consider the mobile node (MN) to be the client in figure 1, and the attendant to be the foreign agent (FA). If a situation arises that there is no foreign agent present, e.g., in the case of an IPv4 mobile node with a co-located care of address or an IPv6 mobile node, the equivalent attendant functionality is to be provided by the address allocation entity, e.g., a DHCP server. Such an attendant functionality is outside the scope of this document. The home agent, while important to Mobile IP, is allowed to play a role during the initial registration that is subordinate to the role played by the AAAH. For application to Mobile IP, we modify the general model (as illustrated in figure 3). After the initial registration, the mobile node is authorized to continue using Mobile IP at the foreign domain without requiring further involvement by the AAA servers. Thus, the initial registration will probably take longer than subsequent Mobile IP registrations.
モバイルIPを使用しているクライアントがAAAサービスから特定の特徴を必要とします、基本のAAAの機能性に関して既に言及された要件とIPの接続性に必要であるものに加えて。 モバイルIPの一般的なモデルの応用を理解するために、私たちは、モバイルノード(ミネソタ)が1図というクライアントと、外国人のエージェント(FA)である付添人であると考えます。 例えば、IPv4のモバイルノードの場合で出席しているどんな外国人のエージェントもアドレスの共同見つけられた注意かIPv6のモバイルノードと共にいない状況が起こるなら、同等な付き添いの機能性はアドレス配分実体で提供することです、例えば、DHCPサーバ。このドキュメントの範囲の外にそのような付き添いの機能性はあります。 ホームのエージェントはAAAHによって果たされた役割に下位であることの新規登録の間、役割を果たすことができますモバイルIPに重要である間。 モバイルIPへのアプリケーションのために、私たちは一般的なモデルを変更します(例証されるように、3は中で計算します)。 新規登録の後に、モバイルノードが、外国ドメインでAAAサーバでさらなるかかわり合いを必要としないでモバイルIPを使用し続けているのが認可されます。 したがって、新規登録はたぶんその後のモバイルIP登録証明書より長い間、かかるでしょう。
In order to reduce this extra time overhead as much as possible, it is important to reduce the time taken for communications between the AAA servers. A major component of this communications latency is the time taken to traverse the wide-area Internet that is likely to separate the AAAL and the AAAH. This leads to a further strong motivation for integration of the AAA functions themselves, as well as integration of AAA functions with the initial Mobile IP registration. In order to reduce the number of messages that traverse the network for initial registration of a Mobile Node, the
この延長時間オーバーヘッドをできるだけ下げるために、AAAサーバのコミュニケーションにかかる時間を短縮するのは重要です。 このコミュニケーション潜在の主要なコンポーネントはわざわざですAAALとAAAHを切り離しそうな広い領域インターネットが横断された。 これはAAA機能自体の統合に関するさらなる強い動機に通じます、初期のモバイルIP登録によるAAA機能の統合と同様に。 メッセージの数を減少させて、それはaモバイルNodeの新規登録のためにネットワークを横断します。
Glass, et al. Informational [Page 10] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[10ページ]のRFC2977
AAA functions in the visited network (AAAL) and the home network (AAAH) need to interface with the foreign agent and the home agent to handle the registration message. Latency would be reduced as a result of initial registration being handled in conjunction with AAA and the mobile IP mobility agents. Subsequent registrations, however, would be handled according to RFC 2002 [13]. Another way to reduce latency as to accounting would be the exchange of small records.
訪問されたネットワークにおけるAAA機能(AAAL)とホームネットワーク(AAAH)は、登録メッセージを扱うために外国人のエージェントとホームのエージェントに連結する必要があります。 レイテンシはAAAに関連して扱われる新規登録とモバイルIP移動性エージェントの結果、減少するでしょう。 しかしながら、RFC2002[13]によると、その後の登録証明書は扱われるでしょう。 会計に関してレイテンシを減少させる別の方法は小さい記録の交換でしょう。
As there are many different types of sub-services attendants may provide to mobile clients, there MUST be extensible accounting formats. In this way, the specific services being provided can be identified, as well as accounting support should more services be identified in the future.
多くの異なった付添人がモバイルクライアントに提供するかもしれないサブサービスのタイプがあるので、広げることができる会計形式があるに違いありません。 このように、より多くのサービスが将来特定されるならサポートを説明することと同様に提供される特定のサービスは特定できます。
The AAA home domain and the HA home domain of the mobile node need not be part of the same administrative domain. Such an situation can occur if the home address of the mobile node is provided by one domain, e.g., an ISP that the mobile user uses while at home, and the authorization and accounting by another (specialized) domain, e.g., a credit card company. The foreign agent sends only the authentication information of the mobile node to the AAAL, which interfaces to the AAAH. After a successful authorization of the mobile node, the foreign agent is able to continue with the mobile IP registration procedure. Such a scheme introduces more delay if the access to the AAA functionality and the mobile IP protocol is sequentialized. Subsequent registrations would be handled according to RFC 2002 [13] without further interaction with the AAA. Whether to combine or separate the Mobile IP protocol data with/from the AAA messages is ultimately a policy decision. A separation of the Mobile IP protocol data and the AAA messages can be successfully accomplished only if the IP address of the mobile node's home agent is provided to the foreign agent performing the attendant function.
AAAホームドメインとモバイルノードのHAホームドメインは同じ管理ドメインの一部である必要はありません。 別の(専門化する)のドメイン(例えば、クレジットカード会社)で1つのドメイン、例えばモバイルユーザがホームにいる間に使用するISP、承認、および会計でモバイルノードに関するホームアドレスを提供するなら、そのような状況は起こることができます。 外国人のエージェントはモバイルノードに関する認証情報だけをAAALに送ります。(AAALはAAAHに連結します)。 モバイルノードのうまくいっている承認の後に、外国人のエージェントはモバイルIP登録手順を続行できます。 AAAの機能性とモバイルIPプロトコルへのアクセスがsequentializedされるなら、そのような体系は、より多くの遅れを導入します。 RFC2002[13]によると、その後の登録証明書はAAAとの一層の相互作用なしで扱われるでしょう。 結局、AAAメッセージからの/でモバイルIPプロトコルデータを結合するか、または切り離すかが、政策決定です。 モバイルノードのホームのエージェントのIPアドレスを付き添いの機能を実行している外国人のエージェントに提供する場合にだけ、首尾よくモバイルIPプロトコルデータとAAAメッセージの分離を実行できます。
All needed AAA and Mobile IP functions SHOULD be processed during a single Internet traversal. This MUST be done without requiring AAA servers to process protocol messages sent to Mobile IP agents. The AAA servers MUST identify the Mobile IP agents and security associations necessary to process the Mobile IP registration, pass the necessary registration data to those Mobile IP agents, and remain uninvolved in the routing and authentication processing steps particular to Mobile IP registration.
すべてがAAAとモバイルIP機能SHOULDを必要としました。ただ一つのインターネット縦断の間、処理されます。 モバイルIPエージェントに送られたプロトコルメッセージを処理するためにAAAサーバを必要としないで、これをしなければなりません。 AAAサーバはモバイルIP登録を処理して、それらのモバイルIPエージェントに必要な登録データを渡して、モバイルIP登録に特定のルーティングと認証処理ステップに無関心なままで残るのに必要なモバイルIPエージェントとセキュリティ協会を特定しなければなりません。
For Mobile IP, the AAAL and the AAAH servers have the following additional general tasks:
モバイルIPに関しては、AAALとAAAHサーバには、以下の追加一般的なタスクがあります:
- enable [re]authentication for Mobile IP registration
- モバイルIP登録のための[re]認証を可能にしてください。
Glass, et al. Informational [Page 11] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[11ページ]のRFC2977
- authorize the mobile node (once its identity has been established)
to use at least the set of resources for minimal Mobile IP
functionality, plus potentially other services requested by the
mobile node
- initiate accounting for service utilization
- use AAA protocol extensions specifically for including Mobile IP
registration messages as part of the initial registration sequence
to be handled by the AAA servers.
- モバイルノード(アイデンティティがいったん確立されると)が最小量のモバイルIPの機能性、およびモバイルノードによって要求された潜在的に他のサービスに少なくともリソースのセットを使用するのを認可してください--サービス利用のための会計を開始してください--特にAAAサーバによって扱われるために新規登録系列の一部としてモバイルIP登録メッセージを含むのにAAAプロトコル拡張子を使用してください。
These tasks, and the resulting more specific tasks to be listed later in this section, are beneficially handled and expedited by the AAA servers shown in figure 1 because the tasks often happen together, and task processing needs access to the same data at the same time.
これらのタスク、および後でこのセクションで記載されるべきより特定の結果として起こるタスクは、タスクがしばしば一緒に起こって、タスク処理が同時に同じデータへのアクセスを必要とするので1図に示されたAAAサーバによって、有益に扱われて、速められます。
Local Domain Home Domain
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| | AAAL | | | | AAAH | |
| | +-------------------+ | |
| +---+--+ | | +--+---+ |
| | | | | |
| | | | | |
+------+ | +---+--+ | | +--+---+ |
| | | | | | | | | |
| MN +- -|- -+ FA + -- -- -- -- - + HA | |
| | | | | | | | | |
+------+ | +------+ | | +------+ |
| | | |
+--------------+ +----------------------+
局所領域ホームドメイン+--------------+ +----------------------+ | +------+ | | +------+ | | | | | | | | | | | AAAL| | | | AAAH| | | | +-------------------+ | | | +---+--+ | | +--+---+ | | | | | | | | | | | | | +------+ | +---+--+ | | +--+---+ | | | | | | | | | | | | ミネソタ+、-|- -+ ファ+--、--、--、--、--、+、ハ。| | | | | | | | | | | | +------+ | +------+ | | +------+ | | | | | +--------------+ +----------------------+
Figure 3: AAA Servers with Mobile IP agents
図3: モバイルIPエージェントがいるAAA Servers
In the model in figure 1, the initial AAA transactions are handled without needing the home agent, but Mobile IP requires every registration to be handled between the home agent (HA) and the foreign agent (FA), as shown by the sparse dashed (lower) line in figure 3. This means that during the initial registration, something has to happen that enables the home agent and foreign agent to perform subsequent Mobile IP registrations. After the initial registration, the AAAH and AAAL in figure 3 would not be needed, and subsequent Mobile IP registrations would only follow the lower control path between the foreign agent and the home agent.
図というモデルでは、ホームのエージェントを必要としないで、1、初期のAAAトランザクションは扱われますが、モバイルIPは、あらゆる登録がホームのエージェント(HA)と外国人のエージェント(FA)の間で扱われるのを必要とします、まばらな投げつけられた(下側の)系列によって3が中で計算するのが示されるように。 これは、新規登録の間ホームのエージェントと外国人のエージェントがその後のモバイルIP登録証明書を実行するのを可能にする何かが起きるべくして起きることを意味します。 図の新規登録、AAAH、およびAAALの後に、3は必要でないでしょう、そして、その後のモバイルIP登録証明書は外国人のエージェントとホームのエージェントの間の下側のコントロール経路に続くだけでしょう。
Any Mobile IP data that is sent by FA through the AAAL to AAAH MUST be considered opaque to the AAA servers. Authorization data needed by the AAA servers then MUST be delivered to them by the foreign
AAAサーバに不透明な状態で考えられて、AAALを通してFAによってAAAH MUSTに送られるどんなモバイルIPデータ。 外国でその時AAAサーバによって必要とされた承認データをそれらに提供しなければなりません。
Glass, et al. Informational [Page 12] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[12ページ]のRFC2977
agent from the data supplied by the mobile node. The foreign agent becomes a translation agent between the Mobile IP registration protocol and AAA.
モバイルノードによって提供されたデータからのエージェント。 外国人のエージェントはモバイルIP登録プロトコルとAAAの間の翻訳エージェントになります。
As mentioned in section 3, nodes in two separate administrative domains often must take additional steps to guarantee their security and privacy,, as well as the security and privacy of the data they are exchanging. In today's Internet, such security measures may be provided by using several different algorithms. Some algorithms rely on the existence of a public-key infrastructure [8]; others rely on distribution of symmetric keys to the communicating nodes [9]. AAA servers SHOULD be able to verify credentials using either style in their interactions with Mobile IP entities.
セクション3、それらが交換しているデータのセキュリティとプライバシーと同様に別々の管理ドメインがそれらのセキュリティとプライバシーを保証するためにしばしば追加ステップ取らなければならない2におけるノードで言及されるように。 今日のインターネットに、いくつかの異なったアルゴリズムを使用することによって、そのような安全策を提供するかもしれません。いくつかのアルゴリズムが公開鍵インフラストラクチャ[8]の存在を当てにします。 他のものは交信ノード[9]の対称鍵の分配に依存します。 AAAサーバSHOULD、モバイルIP実体とのそれらの相互作用にスタイルを使用することで資格証明書について確かめることができてください。
In order to enable subsequent registrations, the AAA servers MUST be able to perform some key distribution during the initial Mobile IP registration process from any particular administrative domain.
その後の登録証明書を可能にするために、AAAサーバはどんな特定の管理ドメインからの初期のモバイルIP登録手続の間も、何らかの主要な分配を実行できなければなりません。
This key distribution MUST be able to provide the following security functions:
この主要な分配は以下のセキュリティ機能を提供できなければなりません:
- identify or create a security association between MN and home
agent (HA); this is required for the MN to produce the
[re]authentication data for the MN--HA authentication extension,
which is mandatory on Mobile IP registrations.
- identify or create a security association between mobile node and
foreign agent, for use with subsequent registrations at the same
foreign agent, so that the foreign agent can continue to obtain
assurance that the same mobile node has requested the continued
authorization for Mobile IP services.
- identify or create a security association between home agent and
foreign agent, for use with subsequent registrations at the same
foreign agent, so that the foreign agent can continue to obtain
assurance that the same home agent has continued the authorization
for Mobile IP services for the mobile node.
- participate in the distribution of the security association (and
Security Parameter Index, or SPI) to the Mobile IP entities
- The AAA server MUST also be able to validate certificates provided
by the mobile node and provide reliable indication to the foreign
agent.
- The AAAL SHOULD accept an indication from the foreign agent about
the acceptable lifetime for its security associations with the
mobile node and/or the mobile node's home agent. This lifetime
for those security associations SHOULD be an integer multiple of
registration lifetime offered by the foreign agent to the mobile
node. This MAY allow for Mobile IP reauthentication to take place
- ミネソタとホームのエージェント(HA)とのセキュリティ協会を特定するか、または創設してください。 ミネソタがミネソタのための[re]認証データを作り出すのにこれが必要です--HA認証拡張子。(その拡張子はモバイルIP登録証明書のときに義務的です)。 - モバイルノードと外国人のエージェントとのセキュリティ仲間を特定するか、または創造してください、その後の登録証明書が同じ外国人のエージェントにある使用のために、外国人のエージェントが、同じモバイルノードがモバイルIPサービスのために継続的な承認を要求したという保証を得続けることができるように。 - ホームのエージェントと外国人のエージェントとのセキュリティ仲間を特定するか、または創造してください、その後の登録証明書が同じ外国人のエージェントにある使用のために、外国人のエージェントが、同じホームのエージェントが承認を続けていたという保証をモバイルノードのためのモバイルIPサービスに得続けることができるように。 - セキュリティ協会(そして、Security Parameter Index、またはSPI)の分配にモバイルIP実体に参加してください--AAAサーバは、モバイルノードによって提供された証明書を有効にして、また、信頼できる指示を外国人のエージェントに提供できなければなりません。 - AAAL SHOULDはモバイルノードとのセキュリティ協会、そして/または、モバイルノードのホームのエージェントのために許容できるおよそ生涯外国人のエージェントから指示を受け入れます。 この生涯、それらのセキュリティ協会SHOULDのために、外国人のエージェントによってモバイルノードに提供された登録生涯の整数倍数はそうです。 これは、モバイルIP再認証が行われるのを許容するかもしれません。
Glass, et al. Informational [Page 13] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[13ページ]のRFC2977
without the need for reauthentication to take place on the AAA
level, thereby shortenning the time required for mobile node
reregistration.
- The AAA servers SHOULD be able to condition their acceptance of a
Mobile IP registration authorization depending upon whether the
registration requires broadcast or multicast service to the mobile
node tunneled through the foreign agent.
- In addition, reverse tunneling may also be a necessary requirement
for mobile node connectivity. Therefore, AAA servers SHOULD also
be able to condition their acceptance of Mobile IP registration
authorization depending upon whether the registration requires
reverse tunnelling support to the home domain through the foreign
agent.
再認証がAAAレベルで行われる必要性がなければ、その結果、時間をshortenningするのがモバイルノード再登録に必要です。 - AAAサーバSHOULD、彼らの登録が放送を必要とするかどうかによるモバイルIP登録承認の、または、外国人のエージェントを通してトンネルを堀られたモバイルノードに対するマルチキャストサービスの承認を条件とさせることができてください。 - また、さらに、逆のトンネリングはモバイルノードの接続性のための必要な要件であるかもしれません。 したがって、AAAサーバSHOULD、また、登録が外国人のエージェントを通して逆のトンネルサポートをホームドメインに必要とするかどうかを彼らのモバイルIP登録承認依存の承認を条件とさせることができてください。
The lifetime of any security associations distributed by the AAA server for use with Mobile IP SHOULD be great enough to avoid too- frequent initiation of the AAA key distribution, since each invocation of this process is likely to cause lengthy delays between [re]registrations [5]. Registration delays in Mobile IP cause dropped packets and noticeable disruptions in service. Note that any key distributed by AAAH to the foreign agent and home agent MAY be used to initiate Internet Key Exchange (IKE) [7].
大物がこのプロセスの各実施以来また、AAAの主要な分配の頻繁な開始を避けるために十分であったならモバイルIP SHOULDとの使用のためのAAAサーバによって分配されたどんなセキュリティ協会の寿命も[re]登録証明書[5]の間の長い遅れを引き起こしそうです。 モバイルIP原因の登録遅れは使用中の状態でパケットとめぼしい分裂を下げました。 AAAHによって外国人のエージェントとホームのエージェントに分配されたどんなキーもインターネット・キー・エクスチェンジ(IKE)[7]を開始するのに使用されるかもしれないことに注意してください。
Note further that the mobile node and home agent may well have a security association established that does not depend upon any action by the AAAH.
モバイルノードとホームのエージェントにはAAAHによるどんな動作にもよらない設立されたセキュリティ協会がたぶんあるだろうことにさらに注意してください。
5.1. Mobile IP with Dynamic IP Addresses
5.1. ダイナミックなIPアドレスがあるモバイルIP
According to section 4, many people would like their mobile nodes to be identified by their NAI, and to obtain a dynamically allocated home address for use in the foreign domain. These people may often be unconcerned with details about how their computers implement Mobile IP, and indeed may not have any knowledge of their home agent or any security association except that between themselves and the AAAH (see figure 2). In this case the Mobile IP registration data has to be carried along with the AAA messages. The AAA home domain and the HA home domain have to be part of the same administrative domain.
セクション4によると、多くの人々が、彼らのモバイルノードに外国ドメインでの使用のためのダイナミックに割り当てられたホームアドレスをそれらのNAIによって特定されて、得て欲しいです。 これらの人々は、しばしばそれらのコンピュータがどうモバイルIPを実装するかに関する詳細に無関心であるかもしれなく、本当に、自分たちとAAAHの間のそれ以外の彼らのホームのエージェントかどんなセキュリティ協会に関する少しの知識も持っていないかもしれません(2が計算するのを確実にしてください)。 この場合、モバイルIP登録データはAAAメッセージと共に運ばれなければなりません。 AAAホームドメインとHAホームドメインは同じ管理ドメインの一部でなければなりません。
Mobile IP requires the home address assigned to the mobile node belong to the same subnet as the Home Agent providing service to the mobile node. For effective use of IP home addresses, the home AAA (AAAH) SHOULD be able to select a home agent for use with the newly allocated home address. In many cases, the mobile node will already know the address of its home agent, even if the mobile node does not already have an existing home address. Therefore, the home AAA (AAAH) MUST be able to coordinate the allocation of a home address
モバイルノードに割り当てられて、モバイルIPはホームアドレスを必要とします。モバイルノードに対するサービスを提供しながら、ホームのエージェントと同じサブネットに属してください。 IPホームアドレスの有効な使用、ホームAAA(AAAH)SHOULD、使用のために新たに割り当てられたホームアドレスでホームのエージェントを選ぶことができてください。 多くの場合、モバイルノードは既にホームのエージェントのアドレスを知るでしょう、モバイルノードに中古住宅アドレスが既になくても。 したがって、ホームAAA(AAAH)はホームアドレスの配分を調整できなければなりません。
Glass, et al. Informational [Page 14] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[14ページ]のRFC2977
with a home agent that might be designated by the mobile node.
ホームのエージェントと共に、それはモバイルノードによって指定されるかもしれません。
Allocating a home address and a home agent for the mobile would provide a further simplification in the configuration needs for the client's mobile node. Currently, in the Proposed Standard Mobile IP specification [13] a mobile node has to be configured with a home address and the address of a home agent, as well as with a security association with that home agent. In contrast, the proposed AAA features would only require the mobile node to be configured with its NAI and a secure shared secret for use by the AAAH. The mobile node's home address, the address of its home agent, the security association between the mobile node and the home agent, and even the identity (DNS name or IP address) of the AAAH can all be dynamically determined as part of Mobile IP initial registration with the mobility agent in the foreign domain (i.e., a foreign agent with AAA interface features). Nevertheless, the mobile node may choose to include the MN-HA security extension as well as AAA credentials, and the proposed Mobile IP and AAA server model MUST work when both are present.
モバイルのためにホームアドレスとホームのエージェントを割り当てると、さらなる簡素化はクライアントのモバイルノードの構成の必要性に提供されるでしょう。 現在、Proposed StandardのモバイルIP仕様[13]では、モバイルノードはホームのエージェントのホームアドレスとアドレス、およびそのホームのエージェントとのセキュリティ仲間に構成されなければなりません。 対照的に、提案されたAAAの特徴は、モバイルノードが使用のためのNAIと安全な共有秘密キーによってAAAHによって構成されるのを必要とするだけでしょう。 モバイルノードのホームアドレス、ホームのエージェントのアドレス、モバイルノードとホームのエージェントとのセキュリティ仲間、およびAAAHのアイデンティティ(DNS名かIPアドレス)さえ外国ドメイン(すなわち、AAAインタフェースの特徴をもっている外国人のエージェント)の移動性エージェントと共にモバイルIP新規登録の一部としてすべてダイナミックに決定できます。 それにもかかわらず、モバイルノードは、AAA資格証明書と同様にミネソタ-HAセキュリティ拡張子を含んでいるのを選ぶかもしれません、そして、両方が存在しているとき、提案されたモバイルIPとAAAサーバモデルは働かなければなりません。
The reason for all this simplification is that the NAI encodes the client's identity as well as the name of the client's home domain; this follows existing industry practice for the way NAIs are used today (see section 4). The home domain name is then available for use by the local AAA (AAAL) to locate the home AAA serving the client's home domain. In the general model, the AAAL would also have to identify the appropriate security association for use with that AAAH. Section 6 discusses a way to reduce the number of security associations that have to be maintained between pairs of AAA servers such as the AAAL and AAAH just described.
このすべての簡素化の理由はNAIがクライアントのホームドメインの名前と同様にクライアントのアイデンティティをコード化するということです。 これはNAIsが今日使用される(セクション4を見てください)方法のための既存の産業習慣に続きます。 地方のAAA(AAAL)による使用がクライアントのホームドメインに役立つホームAAAの場所を見つけるように、ホームドメイン名はその時、利用可能です。 また、一般的なモデルでは、AAALは使用のための適切なセキュリティ協会をそのAAAHと同一視しなければならないでしょう。 セクション6はただ説明されたAAALやAAAHなどの組のAAAサーバの間で維持されなければならないセキュリティ協会の数を減少させる方法を論じます。
5.2. Firewalls and AAA
5.2. ファイアウォールとAAA
Mobile IP has encountered some deployment difficulties related to firewall traversal; see for instance [11]. Since the firewall and AAA server can be part of the same administrative domain, we propose that the AAA server SHOULD be able to issue control messages and keys to the firewall at the boundary of its administrative domain that will configure the firewall to be permeable to Mobile IP registration and data traffic from the mobile node.
モバイルIPはファイアウォール縦断に関連するいくつかの展開困難に遭遇しました。 例えば、[11]を見てください。 ファイアウォールとAAAサーバが同じ管理ドメインの一部であるかもしれないので、私たちは、AAAサーバSHOULDがファイアウォールがモバイルノードからのモバイルIP登録とデータ通信量に透過性であることを構成する管理ドメインの境界のファイアウォールのコントロールメッセージとキーを支給できるよう提案します。
Glass, et al. Informational [Page 15] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[15ページ]のRFC2977
5.3. Mobile IP with Local Home Agents
5.3. 地元のホームのエージェントがいるモバイルIP
+-------------------------+ +--------------+
| +------+ +------+ | | +------+ |
| | | | | | | | | |
| | HA +----+ AAAL | | | | AAAH | |
| | | | +-------------------+ | |
| +-+----+ +---+--+ | | +------+ |
| | | | | Home Domain |
| | +- - - - - + | +--------------+
+------+ | +-+--+-+ |
| | | | | |
| MN +------+ FA | |
| | | | | Local Domain |
+------+ | +------+ |
+-------------------------+
+-------------------------+ +--------------+ | +------+ +------+ | | +------+ | | | | | | | | | | | | | ハ、+----+ AAAL| | | | AAAH| | | | | | +-------------------+ | | | +-+----+ +---+--+ | | +------+ | | | | | | ホームドメイン| | | +- - - - - + | +--------------+ +------+ | +-+--+-+ | | | | | | | | ミネソタ+------+ ファ| | | | | | | 局所領域| +------+ | +------+ | +-------------------------+
Figure 4: Home Agent Allocated by AAAL
図4: AAALによって割り当てられたホームのエージェント
In some Mobile IP models, mobile nodes boot on subnets which are technically foreign subnets, but the services they need are local, and hence communication with the home subnet as if they were residing on the home is not necessary. As long as the mobile node can get an address routable from within the current domain (be it publicly, or privately addressed) it can use mobile IP to roam around that domain, calling the subnet on which it booted its temporary home. This address is likely to be dynamically allocated upon request by the mobile node.
彼らが必要とするサービスは地方です、そして、いくつかでは、モバイルIPはモデル化されます、とモバイルノードが技術的に外国のサブネットであるサブネットでブートしますが、したがって、ホームサブネットとのコミュニケーションはまるでホームの上に住むかのように必要ではありません。 モバイルノードでアドレスが現在のドメインから発送可能になる場合がある(公的、または個人的に扱われるか否かに関係なく)限り、そのドメインをぶらつくのにモバイルIPを使用できます、それが仮設住宅をブートしたサブネットを呼んで。 このアドレスは要求のときにモバイルノードによってダイナミックに割り当てられそうです。
In such situations, when the client is willing to use a dynamically allocated IP address and does not have any preference for the location of the home network (either geographical or topological), the local AAA server (AAAL) may be able to offer this additional allocation service to the client. Then, the home agent will be located in the local domain, which is likely to be offer smaller delays for new Mobile IP registrations.
そのような状況で、クライアントがダイナミックに割り当てられたIPアドレスを使用することを望んでいて、(地理的であるか位相的)であるのにホームネットワークの位置のための少しの好みも持っていないとき、ローカルのAAAサーバ(AAAL)はクライアントに対するこの追加配分サービスを提供できるかもしれません。 そして、ホームのエージェントは局所領域に位置するでしょう。(それは、より小さく申し出であることが新しいモバイルIP登録証明書のために延着する傾向があります)。
In figure 4, AAAL has received a request from the mobile node to allocate a home agent in the local domain. The new home agent receives keys from AAAL to enable future Mobile IP registrations. From the picture, it is evident that such a configuration avoids problems with firewall protection at the domain boundaries, such as were described briefly in section 5.2. On the other hand, this configuration makes it difficult for the mobile node to receive data from any communications partners in the mobile node's home administrative domain. Note that, in this model, the mobile node's home address is affiliated with the foreign domain for routing purposes. Thus, any dynamic update to DNS, to associate the mobile
4図では、AAALは、局所領域にホームのエージェントを割り当てるためにモバイルノードから要求を受け取りました。 新しいホームのエージェントは、将来のモバイルIP登録証明書を可能にするためにAAALからキーを受け取ります。 画像から、そのような構成がセクション5.2で簡潔に説明されたようなドメイン境界でのファイアウォール保護に関する問題を避けるのは、明白です。 他方では、この構成で、モバイルノードがどんなコミュニケーションパートナーからもデータを受け取るのがモバイルノードのホームの管理ドメインで難しくなります。 モバイルノードのホームアドレスがルーティング目的のためにこのモデルで外国ドメインに加わられることに注意してください。 したがって、どんな動力もDNS、仲間にモバイルをアップデートします。
Glass, et al. Informational [Page 16] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[16ページ]のRFC2977
node's home FQDN (Fully Qualified Domain Name [10]) with its new IP address, will require insertion of a foreign IP address into the home DNS server database.
ノードのホームFQDN、(完全に、新しいIPアドレス、意志があるQualified Domain Name[10])はホームDNSサーバデータベースに外国IPアドレスの挿入を必要とします。
5.4. Mobile IP with Local Payments
5.4. 地方の支払いがあるモバイルIP
Since the AAAL is expected to be enabled to allocate a local home agent upon demand, we can make a further simplification. In cases where the AAAL can manage any necessary authorization function locally (e.g., if the client pays with cash or a credit card), then there is no need for an AAA protocol or infrastructure to interact with the AAAH. The resulting simple configuration is illustrated in figure 5.
要求に応じて地元のホームのエージェントを割り当てるのがAAALが可能にされると予想されて、私たちはさらなる簡素化をすることができます。 そして、AAALが局所的にどんな必要な承認機能にも対処できる(例えば、クライアントが現金かクレジットカードで支払うなら)場合には、AAAプロトコルかインフラストラクチャがAAAHと対話する必要は全くありません。 結果として起こる簡単な構成は例証されて、5が中で計算するということです。
In this simplified model, we may consider that the role of the AAAH is taken over either by a national government (in the case of a cash payment), or by a card authorization service if payment is by credit card, or some such authority acceptable to all parties. Then, the AAAL expects those external authorities to guarantee the value represented by the client's payment credentials (cash or credit). There are likely to be other cases where clients are granted access to local resources, or access to the Internet, without any charges at all. Such configurations may be found in airports and other common
この簡易型のモデルでは、私たちは、支払いがクレジットカードによって引き継がれるならAAAHの役割が中央政府(現金払いの場合における)、またはカード承認サービスで引き継がれるか、またはすべてに許容できるそのような何らかの権威がパーティーへ行くと考えるかもしれません。 そして、AAALは、それらの外部の当局がクライアントの支払い資格証明書(現金かクレジット)によって表された値を保証すると予想します。 ローカル資源へのクライアントのアクセスが承諾される他のケース、またはインターネットへのアクセスがありそうです、全く少しも充電なしで。 そのような構成は、一般的に空港で見つけられて、他であるかもしれません。
+-------------------------+
| +------+ +------+ |
| | | | | |
| | HA +----+ AAAL | |
| | | | | |
| +--+---+ +----+-+ |
| | | |
| +- - - - - + | |
+------+ | +-+--+-+ |
| | | | | |
| MN +- -|- - - - - - - + FA | |
| | | Local Domain | | |
+------+ | +------+ |
+-------------------------+
+-------------------------+ | +------+ +------+ | | | | | | | | | ハ、+----+ AAAL| | | | | | | | | +--+---+ +----+-+ | | | | | | +- - - - - + | | +------+ | +-+--+-+ | | | | | | | | ミネソタ+、-|- - - - - - - + ファ| | | | | 局所領域| | | +------+ | +------+ | +-------------------------+
Figure 5: Local Payment for Local Mobile IP services
図5: LocalのモバイルIPサービスのための地方のPayment
areas where business clients are likely to spend time. The service provider may find sufficient reward in the goodwill of the clients, or from advertisements displayed on Internet portals that are to be used by the clients. In such situations, the AAAL SHOULD still allocate a home agent, appropriate keys, and the mobile node's home address.
ビジネスクライアントが時間を過ごしそうである領域。 サービスプロバイダーはクライアントの好意、または、クライアントによって使用されることになっているインターネットポータルに示された広告から十分な報酬を見つけるかもしれません。 そのような状況で、AAAL SHOULDはまだホームのエージェント、適切なキー、およびモバイルノードのホームアドレスを割り当てています。
Glass, et al. Informational [Page 17] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[17ページ]のRFC2977
5.5. Fast Handover
5.5. 速い引き渡し
Since the movement from coverage area to coverage area may be frequent in Mobile IP networks, it is imperative that the latency involved in the handoff process be minimized. See, for instance, the Route Optimization document [15] for one way to do this using Binding Updates. When the mobile node enters a new visited subnet, it would be desirable for it to provide the previous foreign agent's NAI. The new FA can use this information to either contact the previous FA to retrieve the KDC session key information, or it can attempt to retrieve the keys from the AAAL. If the AAAL cannot provide the necessary keying information, the request will have to be sent to the mobile node's AAAH to retrieve new keying information. After initial authorization, further authorizations SHOULD be done locally within the Local Domain.
適用範囲の地域から適用範囲の地域までの運動はモバイルIPネットワークが頻繁であるかもしれないので、移管プロセスにかかわる潜在が最小にされるのは、必須です。 見てください、そして、例えば、Route OptimizationはBinding Updatesを使用することでこれをする1つの方法のための[15]を記録します。 モバイルノードが新しい訪問されたサブネットに入るとき、前の外国人のエージェントのNAIを提供するのは、望ましいでしょう。 新しいFAがKDCのセッションの主要な情報を検索するために前のFAに連絡するのにこの情報を使用できますか、またはそれは、AAALからキーを検索するのを試みることができます。 AAALが必要な合わせる情報を提供できないと、新しい合わせる情報を検索するためにモバイルノードのAAAHに要求を送らなければならないでしょう。 一層の承認SHOULD、後に承認に頭文字をつけてください。局所的に、Local Domainの中でします。
When a MN moves into a new foreign subnet as a result of a handover and is now served by a different FA, the AAAL in this domain may contact the AAAL in the domain that the MN has just been handed off from to verify the authenticity of the MN and/or to obtain the session keys. The new serving AAAL may determine the address of the AAAL in the previously visited domain from the previous FA NAI information supplied by the MN.
Whenミネソタは、引き渡しの結果、新しい外国サブネットに移行して、現在異なったFAによって役立たれています、とこのドメインのAAALはミネソタの信憑性について確かめて、セッションキーを入手するためにミネソタがちょうど手渡されたドメインのAAALに連絡するかもしれません。 新しい給仕AAALは以前に訪問されたドメインでミネソタによって提供された前のFA NAI情報からAAALのアドレスを決定するかもしれません。
6. Broker Model
6. ブローカーモデル
The picture in Figure 1 shows a configuration in which the local and the home authority have to share trust. Depending on the security model used, this configuration can cause a quadratic growth in the number of trust relationships, as the number of AAA authorities (AAAL and AAAH) increases. This has been identified as a problem by the roamops working group [3], and any AAA proposal MUST solve this problem. Using brokers solves many of the scalability problems associated with requiring direct business/roaming relationships between every two administrative domains. In order to provide scalable networks in highly diverse service provider networks in which there are many domains (e.g., many service providers and large numbers of private networks), multiple layers of brokers MUST be supported for both of the broker models described.
図1の画像は地方とホーム権威が信頼を共有しなければならない構成を示しています。 使用される機密保護モデルに頼っていて、この構成は信頼関係の数における二次の成長を引き起こす場合があります、AAA当局(AAALとAAAH)の数が増加するのに従って。 これは問題としてroamopsワーキンググループ[3]によって特定されました、そして、どんなAAA提案もこの問題を解決しなければなりません。 ブローカーを使用すると、2つの管理ドメイン毎の間の直接売買/ローミング関係を必要とすると関連しているスケーラビリティ問題の多くが解決されます。 多くのドメイン(例えば、多くのサービスプロバイダーと多くの私設のネットワーク)がある非常に多様なサービスプロバイダーネットワークにおけるスケーラブルなネットワークを提供して、モデルが説明したブローカーの両方のために複数の層のブローカーをサポートしなければなりません。
Integrity or privacy of information between the home and serving domains may be achieved by either hop-by-hop security associations or end-to-end security associations established with the help of the broker infrastructure. A broker may play the role of a proxy between two administrative domains which have security associations with the broker, and relay AAA messages back and forth securely.
ホームとドメインに役立つことの間の情報の保全かプライバシーがブローカーインフラストラクチャの助けで設立されたホップごとのセキュリティ協会か終わりから終わりへのセキュリティ協会のどちらかによって達成されるかもしれません。 ブローカーは前後にしっかりとブローカーとのセキュリティ仲間がいる2つの管理ドメインと、リレーAAAメッセージの間のプロキシの役割をふるまうかもしれません。
Glass, et al. Informational [Page 18] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[18ページ]のRFC2977
Alternatively, a broker may also enable the two domains with which it has associations, but the domains themselves do not have a direct association, in establishing a security association, thereby bypassing the broker for carrying the messages between the domains. This may be established by virtue of having the broker relay a shared secret key to both the domains that are trying to establish secure communication and then have the domains use the keys supplied by the broker in setting up a security association.
ドメイン自体には、あるいはまた、また、ブローカーはそれが協会を持っている2つのドメインを可能にするかもしれませんが、ダイレクト協会がありません、セキュリティ協会を設立する際に、その結果、メッセージをドメインに伝えるためにブローカーを迂回させます。 セキュリティ協会を設立する際にドメインが安全なコミュニケーションを確立して、次にキーを使用しようとしている両方のドメインに主要な共有秘密キーがブローカーから供給したブローカーリレーを持っていることによってこれは設立されるかもしれません。
Assuming that AAAB accepts responsibility for payment to the serving domain on behalf of the home domain, the serving domain is assured of receiving payments for services offered. However, the redirection broker will usually require a copy of authorization messages from the home domain and accounting messages from the serving domain, in order for the broker to determine if it is willing to accept responsibility for the services being authorized and utilized. If the broker does not accept such responsibility for any reason, then it must be able to terminate service to a mobile node in the serving network. In the event that multiple brokers are involved, in most situations all brokers must be so copied. This may represent an additional burden on foreign agents and AAALs.
AAABがホームドメインを代表して給仕ドメインに支払いへの責任を引き受けると仮定して、給仕ドメインはサービスのための支払いが提供した受信を保証されます。 しかしながら、通常、リダイレクションブローカーはホームドメインからの承認メッセージと給仕ドメインからの会計メッセージのコピーを必要とするでしょう、ブローカーが、それが、認可されて、利用されるサービスへの責任を引き受けても構わないと思っているかどうかと決心するように。 ブローカーがどんな理由へのそのような責任も引き受けないなら、給仕ネットワークでモバイルノードに対するサービスを終えることができなければなりません。 複数のブローカーがかかわる場合、ほとんどの状況で、すべてのブローカーを非常にコピーしなければなりません。 これは外国人のエージェントとAAALsに追加負担を表すかもしれません。
Though this mechanism may reduce latency in the transit of messages between the domains after the broker has completed its involvement, there may be many more messages involved as a result of additional copies of authorization and accounting messages to the brokers involved. There may also be additional latency for initial access to the network, especially when a new security association needs to be created between AAAL and AAAH (for example, from the use of ISAKMP). These delays may become important factors for latency-critical applications.
ブローカーがかかわり合いを完成した後にこのメカニズムはドメインの間のメッセージのトランジットにおけるレイテンシを減少させるかもしれませんが、複本の承認の結果、かかわるずっと多くのメッセージとブローカーへのメッセージがかかわった会計があるかもしれません。 また、ネットワークへの初期のアクセスのための追加潜在があるかもしれません、特に新しいセキュリティ協会が、AAALとAAAH(例えばISAKMPの使用から)の間で作成される必要があると。 これらの遅れは潜在重要なアプリケーションのための重要な要素になるかもしれません。
Glass, et al. Informational [Page 19] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[19ページ]のRFC2977
Local Domain Home Domain
+--------------+ +----------------------+
| +------+ | +------+ | +------+ |
| | | | | | | | | |
| | AAAL +-------+ AAAB +--------+ AAAH | |
| | | | | | | | | |
| +------+ | +------+ | +------+ |
| | | | |
| | | +----------------------+
+------+ | +---+--+ |
| | | | | | C = client
| C +- -|- -+ A | | A = attendant
| | | | | | AAAL = local authority
+------+ | +------+ | AAAH = home authority
| | AAAB = broker authority
+--------------+
局所領域ホームドメイン+--------------+ +----------------------+ | +------+ | +------+ | +------+ | | | | | | | | | | | | | AAAL+-------+ AAAB+--------+ AAAH| | | | | | | | | | | | | +------+ | +------+ | +------+ | | | | | | | | | +----------------------+ +------+ | +---+--+ | | | | | | | Cはクライアントと等しいです。| C+、-|- -+ A| | =付添人| | | | | | AAALは地方公共団体+と等しいです。------+ | +------+ | AAAHはホーム権威と等しいです。| | AAABはブローカー権威+と等しいです。--------------+
Figure 6: AAA Servers Using a Broker
図6: ブローカーを使用するAAAサーバ
The AAAB in figure 6 is the broker's authority server. The broker acts as a settlement agent, providing security and a central point of contact for many service providers and enterprises.
6図のAAABはブローカーの権威サーバです。ブローカーは解決エージェントとして務めます、セキュリティと中央の連絡先を多くのサービスプロバイダーと企業に提供して。
The AAAB enables the local and home domains to cooperate without requiring each of the networks to have a direct business or security relationship with all the other networks. Thus, brokers offer the needed scalability for managing trust relationships between otherwise independent network domains. Use of the broker does not preclude managing separate trust relationships between domains, but it does offer an alternative to doing so. Just as with the AAAH and AAAL (see section 5), data specific to Mobile IP control messages MUST NOT be processed by the AAAB. Any credentials or accounting data to be processed by the AAAB must be present in AAA message units, not extracted from Mobile IP protocol extensions.
AAABは、地方とホームドメインがそれぞれのネットワークを必要としながら協力する他のすべてのネットワークがある直接売買か安全保障関係を持っているのを可能にします。 したがって、ブローカーは、そうでなければ、独立しているネットワークドメインの間の信頼関係を管理するために必要なスケーラビリティを提供します。 ブローカーの使用は、ドメインの間の別々の信頼関係を管理するのを排除しませんが、それはそうすることへの代替手段を提供します。 モバイルIPコントロールメッセージに特定のデータがAAAHとAAAL(セクション5を見る)と共にAAABによって処理されるだけでよくないように。 どんな資格証明書かAAABによって処理されるようにデータを説明するもモバイルIPプロトコル拡大から抽出されるのではなく、AAAメッセージ部隊に存在していなければなりません。
The following requirements come mostly from [2], which discusses use of brokers in the particular case of authorization for roaming dial- up users.
以下の要件はほとんど[2](承認の特定の場合における、ブローカーのローミングダイヤルの使用についてユーザと議論するもの)から来ます。
- allowing management of trust with external domains by way of
brokered AAA.
- accounting reliability. Accounting data that traverses the
Internet may suffer substantial packet loss. Since accounting
packets may traverse one or more intermediate authorization points
(e.g., brokers), retransmission is needed from intermediate points
to avoid long end-to-end delays.
- 仲介されたAAAを通して外部のドメインがある信頼の管理を許します。 - 信頼性を説明します。 インターネットを横断する会計データはかなりのパケット損失を受けるかもしれません。 会計パケットが中間的1承認ポイント(例えば、ブローカー)以上を横断するかもしれないので、中間的ポイントから、「再-トランスミッション」が終わりから終わりへの長い遅れを避けるのが必要です。
Glass, et al. Informational [Page 20] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[20ページ]のRFC2977
- End to End security. The Local Domain and Home Domain must be
able to verify signatures within the message, even though the
message is passed through an intermediate authority server.
- Since the AAAH in the home domain MAY be sending sensitive
information, such as registration keys, the broker MUST be able to
pass encrypted data between the AAA servers.
- Endセキュリティの終わり。 Local DomainとホームDomainはメッセージの中で署名について確かめることができなければなりません、メッセージが中間的権威サーバを通り抜けますが。. --ホームドメインのAAAHが発信するかもしれないので、ブローカーが登録キーなどのように通ることができなければならない機密情報はAAAサーバの間のデータを暗号化しました。
The need for End-to-End security results from the following attacks which were identified when brokered operation uses RADIUS [16] (see [2] for more information on the individual attacks):
Endから終わりへのセキュリティの必要性は仲介された操作がRADIUS[16](個々の攻撃に関する詳しい情報のための[2]を見ます)を使用するときの特定された以下の攻撃から生じます:
+ Message editing
+ Attribute editing
+ Theft of shared secrets
+ Theft and modification of accounting data
+ Replay attacks
+ Connection hijacking
+ Fraudulent accounting
+ 共有秘密キー+窃盗のメッセージ編集+属性編集+窃盗と会計データ+反射攻撃+接続ハイジャック+詐欺的な会計の変更
These are serious problems which cannot be allowed to persist in any acceptable AAA protocol and infrastructure.
これらはどんな許容できるAAAプロトコルとインフラストラクチャにも固執できない深刻な問題です。
7. Security Considerations
7. セキュリティ問題
This is a requirements document for AAA based on Mobile IP. Because AAA is security driven, most of this document addresses the security considerations AAA MUST make on behalf of Mobile IP. As with any security proposal, adding more entities that interact using security protocols creates new administrative requirements for maintaining the appropriate security associations between the entities. In the case of the AAA services proposed however, these administrative requirements are natural, and already well understood in today's Internet because of experience with dial up network access.
これはモバイルIPに基づくAAAのための要件ドキュメントです。 AAAが追い立てられたセキュリティであるので、この大部分はセキュリティ問題AAAがモバイルIPを代表して作らなければならないアドレスを記録します。 どんなセキュリティ提案のようにも、セキュリティプロトコルを使用することで相互作用するより多くの実体を加えると、実体の間の適切なセキュリティ協会を維持するための新しい管理要件は作成されます。 しかしながら、提案されたAAAサービスの場合では、これらの管理要件は、当然で、ダイヤルアップネットワークアクセサリーの経験のために今日のインターネットで既によく理解されています。
8. IPv6 Considerations
8. IPv6問題
The main difference between Mobile IP for IPv4 and Mobile IPv6 is that in IPv6 there is no foreign agent. The attendant function, therefore, has to be located elsewhere. Logical repositories for that function are either at the local router, for stateless address autoconfiguration, or else at the nearest DHCPv6 server, for stateful address autoconfiguration. In the latter case, it is possible that there would be a close relationship between the DHCPv6 server and the AAALv6, but we believe that the protocol functions should still be maintained separately.
IPv4のためのモバイルIPとモバイルIPv6の主な違いはどんな外国人のエージェントもIPv6では、いないということです。 したがって、付き添いの機能はほかの場所に位置しなければなりません。 ローカルルータにおいて、または、状態がないアドレス自動構成か、最も近いDHCPv6サーバにおいてその機能のための論理的な倉庫があります、statefulアドレス自動構成のために。 後者の場合では、DHCPv6サーバとAAALv6との密接な関係があるのが、可能ですが、私たちは、プロトコル機能が別々にまだ維持されているべきであると信じています。
The MN-NAI would be equally useful for identifying the mobile node to the AAALv6 as is described in earlier sections of this document.
ミネソタ-NAIは等しくこのドキュメントの以前のセクションで説明されるAAALv6にモバイルノードを特定することの役に立つでしょう。
Glass, et al. Informational [Page 21] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[21ページ]のRFC2977
9. Acknowledgements
9. 承認
Thanks to Gopal Dommety and Basavaraj Patil for participating in the Mobile IP subcommittee of the aaa-wg which was charged with formulating the requirements detailed in this document. Thanks to N. Asokan for perceptive comments to the mobile-ip mailing list. Some of the text of this document was taken from a draft co-authored by Pat Calhoun. Patrik Flykt suggested text about allowing AAA home domain functions to be separated from the domain managing the home address of the mobile computer.
このドキュメントで詳細な要件を定式化することで告発されたaaa-wgのモバイルIP小委員会にゴパルDommetyとBasavarajパティルに参加してくださってありがとうございます。 モバイル-ipメーリングリストへの鋭敏な言葉をN.Asokanをありがとうございます。 パットCalhounによって共同執筆された草稿からこのドキュメントの原本のいくつかを取りました。 パトリクFlyktはAAAホームドメイン機能がモーバイルコンピュータに関するホームアドレスを管理するドメインと切り離されるのを許容することに関するテキストを勧めました。
The requirements in section 5.5 and section 3.1 were taken from a draft submitted by members of the TIA's TR45.6 Working Group. We would like to acknowledge the work done by the authors of that draft: Tom Hiller, Pat Walsh, Xing Chen, Mark Munson, Gopal Dommety, Sanjeevan Sivalingham, Byng-Keun Lim, Pete McCann, Brent Hirschman, Serge Manning, Ray Hsu, Hang Koo, Mark Lipford, Pat Calhoun, Eric Jaques, Ed Campbell, and Yingchun Xu.
TIAのTR45.6作業部会のメンバーによって提出された草稿からセクション5.5とセクション3.1の要件を取りました。 その草稿の作者によって行われた仕事を承諾したいと思います: トム・ヒラー、パット・ウォルシュ、Xingチェン、マークムンソン、ゴパルDommety、Sanjeevan Sivalingham、Byng-コイン・リム、ピートマッキャン、ブレント・ヒルシュマン、Sergeマニング、レイ・シューはクー、マークLipford、パットCalhoun、エリック・ジャキュース、エド・キャンベル、およびYingchunシューを絞首刑にします。
References
参照
[1] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999.
[1]AbobaとB.とM.用務員、「ネットワークアクセス識別子」、RFC2486、1999年1月。
[2] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[2]Aboba、B.、J.Vollbrecht、および「ローミングにおけるプロキシ推論と政策の実施」、RFC2607、6月1999日
[3] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming
Protocols", RFC 2477, December 1998.
[3]AbobaとB.とG.ゾルン、「ローミングプロトコルを評価する評価基準」、RFC2477、1998年12月。
4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[5] Ramon Caceres and Liviu Iftode. Improving the Performance of
Reliable Transport Protocols in Mobile Computing Environments.
IEEE Journal on Selected Areas in Communications, 13(5):850--
857, June 1995.
[5] ラモン・カセレスとLiviu Iftode。 モバイル・コンピューティング環境における、信頼できるトランスポート・プロトコルの性能を向上させます。 コミュニケーションの選択された領域に関するIEEEジャーナル、13(5): 850-- 857と、1995年6月。
[6] Calhoun, P. and C. Perkins, "Mobile IP Network Address
Identifier Extension, RFC 2794, March 2000.
[6] カルフーンとP.とC.パーキンス、「モバイルIPネットワーク・アドレス識別子拡張子、RFC2794、2000年3月。」
[7] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[7] ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[8] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and CRL Profile", RFC
2459, January 1999.
[8]HousleyとR.とフォードとW.とポークとT.と一人で生活して、「インターネットX.509公開鍵基盤の証明書とCRLは輪郭を描く」D.、RFC2459、1999年1月。
Glass, et al. Informational [Page 22] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[22ページ]のRFC2977
[9] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993.
[9] コールとJ.とC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。
[10] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[10]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[11] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for
Mobile IP", RFC 2356, June 1998.
[11] モンテネグロ、G.、および「モバイルIPのためのSunのスキップファイアウォール縦断」、RFC2356、1998年6月対グプタ
[12] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[12] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、1996年10月。
[13] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[13] パーキンス、C.、「IP移動性サポート」、RFC2002、1996年10月。
[14] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[14] パーキンス、C.、「IPの中の最小量のカプセル化」、RFC2004、1996年10月。
[15] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP",
Work in Progress.
[15] 「モバイルIPにおける経路最適化」というパーキンス、C.、およびD.ジョンソンは進行中で働いています。
[16] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April
1997.
[16]RigneyとC.とルーベンとA.とシンプソン、W.とS.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2138(1997年4月)。
[17] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for
PPP IPCP", RFC 2290, February 1998.
[17] RFC2290、ソロモン、J.、およびS.は「ppp IPCPのためのモバイルIPv4設定オプション」とガラスで覆って、2月は1998です。
Glass, et al. Informational [Page 23] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[23ページ]のRFC2977
Addresses
アドレス
The working group can be contacted via the current chairs:
現在のいすを通してワーキンググループに連絡できます:
Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA
Basavarajパティルノキア6000の接続Driveテキサス75039アービング(米国)
Phone: +1 972-894-6709 EMail: Basavaraj.Patil@nokia.com
以下に電話をしてください。 +1 972-894-6709 メールしてください: Basavaraj.Patil@nokia.com
Phil Roberts Motorola 1501 West Shure Drive Arlington Heights, IL 60004 USA
西シュアー・Driveフィル・ロバーツ・モトローラ1501IL60004アーリントンハイツ(米国)
Phone: +1 847-632-3148 EMail: QA3445@email.mot.com
以下に電話をしてください。 +1 847-632-3148 メールしてください: QA3445@email.mot.com
Glass, et al. Informational [Page 24] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[24ページ]のRFC2977
Questions about this memo can be directed to:
このメモに関する質問による以下のことよう指示できます。
Pat R. Calhoun Network and Security Center Sun Microsystems Laboratories 15 Network Circle Menlo Park, California 94025 USA
パットR.カルフーンネットワークとセキュリティセンターサン・マイクロシステムズ研究所15ネットワーク円のカリフォルニア94025メンローパーク(米国)
Phone: +1 650-786-7733 Fax: +1 650-786-6445 EMail: pcalhoun@eng.sun.com
以下に電話をしてください。 +1 650-786-7733Fax: +1 650-786-6445 メールしてください: pcalhoun@eng.sun.com
Gopal Dommety IOS Network Protocols Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
ゴパルDommety IOSネットワーク・プロトコルInc.170の西タスマン・Driveシスコシステムズカリフォルニア95134-1706サンノゼ(米国)
Phone: +1-408-525-1404 Fax: +1 408-526-4952 EMail: gdommety@cisco.com
以下に電話をしてください。 +1-408-525-1404 Fax: +1 408-526-4952 メールしてください: gdommety@cisco.com
Steven M. Glass Sun Microsystems 1 Network Drive Burlington, MA 01803 USA
スティーブンM.ガラスサン・マイクロシステムズ1ネットワークドライブバーリントン、MA01803米国
Phone: +1-781-442-0504 EMail: steven.glass@sun.com
以下に電話をしてください。 +1-781-442-0504 メールしてください: steven.glass@sun.com
Stuart Jacobs Secure Systems Department GTE Laboratories 40 Sylvan Road Waltham, MA 02451-1128 USA
スチュアートジェイコブズ安全なシステム部のGTE研究所40の森のRoadウォルサム、MA02451-1128米国
Phone: +1 781-466-3076 Fax: +1 781-466-2838 EMail: sjacobs@gte.com
以下に電話をしてください。 +1 781-466-3076Fax: +1 781-466-2838 メールしてください: sjacobs@gte.com
Glass, et al. Informational [Page 25] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[25ページ]のRFC2977
Tom Hiller Lucent Technologies Rm 2F-218 263 Shuman Blvd Naperville, IL 60566 USA
トム・HillerルーセントテクノロジーズRm2F-218 263シューマン・Blvd IL60566ナパービル(米国)
Phone: +1 630 979 7673 Fax: +1 630 713 3663 EMail: tomhiller@lucent.com
以下に電話をしてください。 +1 630 979、7673Fax: +1 3663年の630 713メール: tomhiller@lucent.com
Peter J. McCann Lucent Technologies Rm 2Z-305 263 Shuman Blvd Naperville, IL 60566 USA
ピーター・J.マッキャン・ルーセントテクノロジーズRm 2Z-305 263シューマン・Blvd IL60566ナパービル(米国)
Phone: +1 630 713 9359 Fax: +1 630 713 4982 EMail: mccap@lucent.com
以下に電話をしてください。 +1 630 713、9359Fax: +1 4982年の630 713メール: mccap@lucent.com
Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA
Basavarajパティルノキア6000の接続Driveテキサス75039アービング(米国)
Phone: +1 972-894-6709 Fax : +1 972-894-5349 EMail: Basavaraj.Patil@nokia.com
以下に電話をしてください。 +1 972-894-6709 ファックスで以下を送ってください。 +1 972-894-5349 メールしてください: Basavaraj.Patil@nokia.com
Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
チャールズE.パーキンス通信網研究室ノキアリサーチセンター313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
Phone: +1-650 625-2986 Fax: +1 650 625-2502 EMail: charliep@iprg.nokia.com
以下に電話をしてください。 +1-650 625-2986Fax: +1 650 625-2502 メールしてください: charliep@iprg.nokia.com
Glass, et al. Informational [Page 26] RFC 2977 Mobile IP AAA Requirements October 2000
ガラス、他 IP AAA要件2000年10月のモバイルの情報[26ページ]のRFC2977
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Glass, et al. Informational [Page 27]
ガラス、他 情報[27ページ]
一覧
スポンサーリンク
