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
Mobile IP Authentication, Authorization, and Accounting Requirements
モバイルIP認証、認可、アカウンティングの要件
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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および認証、許可、アカウンティング（AAA）のワーキンググループは、現在、認証、認可、アカウンティングのための要件の定義を見ています。この文書では、モバイルIPサービスを提供するのを助けるためにAAAサービスでサポートされなければならない要件が含まれています。
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から「ホームドメイン」、または他の組織への結合点を交渉することによってインターネットサービスを得ます。モバイルデバイスの普及によって、必要性は、ユーザーが現在の場所に便利な任意のドメインに接続できるようにするために生成されています。このように、クライアントが自分のホームドメインとは異なる管理ドメインによって提供されているリソースへのアクセスを必要とします（「外部ドメイン」と呼ばれます）。外部ドメインからのサービスの必要性が認証に直接つながる、多くのモデルでは、認可が必要であり、当然の会計（どこから、「AAA」）。そここれらのリードのにはいくつかの引数がある、または他の人に由来しているが、3つのAAA機能が密接に相互依存している一般的な合意があります。
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の幅広い展開のための経済的インセンティブを提供します。この文書は、特定記述、およびAAAプロトコル上の機能や性能要件モバイルIPの場所を説明します。
The formal description of Mobile IP can be found in [13,12,14,17].
モバイルIPの正式な説明は[13,12,14,17]で見つけることができます。
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モデルを示し、関連するモデルから派生要件について説明します。
This document frequently uses the following terms in addition to those defined in RFC 2002 [13]:
このドキュメントは、頻繁にRFC 2002 [13]で定義されたものに加えて、次の用語を使用しています：
Accounting The act of collecting information on resource usage for the purpose of trend analysis, auditing, billing, or cost allocation.
トレンド分析、監査、請求、または費用配分の目的のために、リソースの使用状況に関する情報を収集する行為を占めています。
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.
イントラネット、または共通の管理下にあるネットワーク、コンピュータ、およびデータベースの収集管理ドメイン。一般的な管理で動作しているコンピュータのエンティティは管理上作成されたセキュリティアソシエーションを共有すると仮定することができます。
Attendant A node designed to provide the service interface between a client and the local domain.
クライアントとローカルドメインとの間のサービス・インターフェースを提供するように設計ノードアテンダント。
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).
メッセージ（メッセージ認証）の発信元として、またはチャネル（エンティティ認証）のエンドポイントとして、互いに既知の名前空間から既存のラベルの形で、要求されたアイデンティティを検証する行為を認証。
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.
認可の場合、このようないくつかのリソースへのアクセスなど、特定の権利を、決定の行為は、特定の資格のプレゼンターに付与することができます。
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.
取得し、それらのAAAサーバからセキュリティサービスを提供することが他の二つのAAAサーバによって信頼できる仲介エージェントを、ブローカー。たとえば、ブローカーは取得と承認、または資格情報が有効な保証を提供することができます。
Client A node wishing to obtain service from an attendant within an administrative domain.
クライアントは、ノードは、管理ドメイン内の係員からサービスを得たいです。
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インフラストラクチャを含みます。外国人のエージェントの観点から、外部ドメインはローカルドメインです。
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.
ドメイン間会計ドメイン間の会計処理は、別の管理ドメイン内で使用するために、管理ドメインを持つエンティティのリソース使用状況に関する情報を集めたものです。ドメイン間の会計では、会計パケットとセッション記録は、一般的に管理境界を横切ることになります。
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.
イントラドメイン会計イントラドメイン会計は、そのドメイン内で使用するために、管理ドメイン内のリソースに関する情報を集めたものです。ドメイン内の会計では、会計パケットとセッション記録は、一般的に管理境界を越えることはありません。
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インフラストラクチャを含むローカルドメインアン管理ドメイン。
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.
リアルタイム会計リアルタイムの会計処理は、定義された時間ウィンドウ内のリソースの使用状況に関する情報の処理を必要とします。時間の制約は、一般的に金融リスクを制限するために課されます。
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.
セッション記録セッションレコードは、セッション全体にわたるユーザーのリソース消費の要約を表しています。セッション・レコードを作成する会計ゲートウェイは、中間会計イベントを処理することによってそれを行うことができます。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [4].
この文書に記載されている、キーワード "MAY"、「MUST、 "MUST NOT"、 "オプション"、 "推奨"、 "SHOULD"、および "the" はならない、[4]で説明されるように解釈されるべきです。
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つの管理ドメインに属するクライアントは、多くの場合、（外部ドメインと呼ばれる）、別の管理ドメインによって提供されるリソースを使用する必要があります。クライアントの要求に出席外部ドメイン内のエージェントは、（「アテンダント」エージェントを呼び出す）、クライアントがリソースへのアクセスが許可される前に認証することができますいくつかの資格情報を提供することを要求する可能性があります。これらの資格情報は外部ドメインが理解何かかもしれないが、ほとんどの場合、彼らは唯一のホームドメインによってによって割り当てられた、と理解しており、モバイルノードとの安全なチャンネルを設定するために使用することができます。
Local Domain Home Domain
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| | AAAL | | | | AAAH | |
| | +-------------------+ | |
| +---+--+ | | +------+ |
| | | | |
| | | +----------------------+
+------+ | +---+--+ |
| | | | | | C = client
| C |- -|- -| A | | A = attendant
| | | | | | AAAL = local authority
+------+ | +------+ | AAAH = home authority
| |
+--------------+
Figure 1: AAA Servers in Home and Local Domains
図1：ホームとローカルドメインのAAA Servers
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.
認可が地方自治体によって得られた、と当局が成功交渉について係員に通知した後は、係員がクライアントに要求されたリソースを提供することができます。
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のための多くの参加者があるかもしれない、と多くの異なるホームドメインから多数のクライアントがあるかもしれません。各ホーム・ドメインは、そのホーム・ドメインによって管理クライアントから発信資格情報を確認することができます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.
第二に、図1に示したモデルから、そうでない場合は、認証結果、権限、またそれらの間で取引されるかもしれないとしても、会計データに頼ることができなかったので、AAALとAAAHは、セキュリティアソシエーションを共有する必要があることは明らかです。スケーラブルではない最後に、しかし、そのような二国間の安全保障関係をされる必要。セクション6において以下に示唆されるようにAAAフレームワークでは、よりスケーラブルなメカニズムを提供しなければなりません。
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サーバを使用することができます。 1つのアテンダントの許可を許可する資格情報は、同じまたは他のアテンダントの任意の今後の交渉で使用不可能であるべきです。
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）との安全保障関係を持たなければならない - 地元当局は、クライアントの資格情報をチェックすることができ、外部機関とのセキュリティ関係を共有する、または動的に確立することがあります
- 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.
この最後の要件から、我々は、クライアントが共有する、または動的に、ホーム・ドメイン内の外部機関とのセキュリティ関係を確立するために持っている自然な要件の理由を見ることができます。それ以外の場合は、AAAHにより確認することができ偽造署名を生成するために、クライアントのために（暗黙のネットワークトポロジを与えられた）技術的に実行不可能です。図2は、我々の提案したモデルから理解し、自然のセキュリティアソシエーションを示しています。セクション6での議論によると、AAALとAAAH間の相互の合意によって、それらをよりスケーラブルでセキュアなトランザクションを調停支援するAAALとAAAH間に挿入された第三者があるかもしれない、ということに注意してください。
+------+ +------+
| | | |
| AAAL +--------------+ AAAH |
| | | |
+---+--+ +--+---+
| |
| |
+---+--+ +--+---+
C = client | | | |
A = attendant | A | | C |
AAAL = local authority | | | |
AAAH = home authority +------+ +------+
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.
- アテンダントが、同時に多くのクライアントのための要求を管理する必要がありますするシナリオがあります。 - アテンダントは、リプレイ攻撃から保護しなければなりません。
- 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.
- 外部ドメインに、できるだけ多くのクライアントを処理するために、できるだけ多くの回複製されますので、係員の機器は、できるだけ安価でなければなりません。 - 出席者は、クライアントが置かサービス品質要件のために、信頼できるローカルAAAサーバ（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.
二つの別々の管理ドメイン（例えば、AAAHとAAAL）内のノードは、多くの場合、その通信相手の身元を確認するための追加手順を実行する必要があり、あるいは通信を構成するデータのプライバシーを保証します。サーバ間の安全保障の文脈で前述したように、これらの考慮事項は、重要なセキュリティ要件につながる一方で、我々はこの文書の範囲外であることをAAAサーバ間のセキュリティアソシエーションの正確な選択を検討してください。選択肢はさえ一方、図1に示した一般的なモデルのいずれかの特定の機能に依存するため、モバイルIPエンティティ間で必要なセキュリティアソシエーションがモバイルIPに適したAAAインフラストラクチャの設計で中心的な重要性になりそうです。上に示した一般的なモデルは、Mobile 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サーバのいずれかによって政策決意に基づいてクライアントにサービスを終了することができなければならないことを示しています。
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アプリケーションまたはタイムアウトが発生しました。 *再送が信頼AAA搬送機構によってではなく、TCPのような下位層プロトコルによって制御されます。
* 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メッセージを受け取ったことを認めるだろう。 AAAメッセージにデジタル証明書を輸送、ラウンドトリップの数を最小限に抑えるために - *謝辞モバイルIPがタイムアウトして再送しないように* AAA応答がタイムリーに配信する必要がAAAメッセージにピギーバックすることが許されるべきですAAAの取引に関連します。注：この要件は、AAAのアプリケーションではなく、移動局に適用されます。証明書は、モバイルノードのトンネリングされたデータを保護するためのIPSecセキュリティアソシエーションを確立するために、外国人や家庭のエージェントによって使用することができます。家と外国人のエージェントは、高価なオンライン証明書ステータスチェックを避けることができるように、この場合、AAAインフラストラクチャは、（いずれかのオンラインチェックを実行またはその他の証明書を検証することによって）、このような証明書の失効ステータスを取得することで支援できます。 - ホップバイホップ（AAAノード）に基づいて、メッセージの完全性と識別認証を提供します。 - サポートリプレイ保護し、すべての許可およびアカウンティングメッセージ用のオプションの否認防止機能を提供します。 AAAプロトコルは、事前の許可メッセージと照合するアカウンティングメッセージのための機能を提供しなければなりません。 - サービス提供とホームネットワーク間の会計クリアリングハウスとの和解を提供する二国間の取り決めやブローカーのAAAサーバを経由しての両方を経由して会計処理をサポート。プライベートネットワークやホームISPがサービスを要求する移動局を認証する場合は、プライベートネットワークやホームISPネットワークはまた、ホームサービスプロバイダまたはブローカーとの電荷を調整することに同意することを明示的な合意があります。リアルタイム会計はサポートされなければなりません。タイムスタンプは、すべてのアカウンティングパケットに含まれている必要があります。
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アドレスの割り当てを調整することができなければなりません。
- AAA servers MUST be able to identify the client by some means other than its IP address.
- AAAサーバは、そのIPアドレス以外の手段でクライアントを特定できなければなりません。
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サーバ今日は、ネットワークアクセス識別子（NAI）を使用してクライアントを識別し、[1]。モバイルノードは、モバイルIP登録要求[6]と共にNAIを含むことによって自身を識別することができます。 NAIの形式は、「ユーザー@レルム」です。それはユニークとNAIを使用して、図1に示したAAAモデルでの使用に適しています（例えば、「ユーザー@レルムは」）AAALが簡単にクライアントのホームドメイン（例えば、「領域」）を決定することができます。 AAALとAAAHの両方が、クライアントの特定のIDでインデックス化記録を保持するためにNAIを使用することができます。
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の機能とどのようなIP接続のために必要とされているとの関連で述べた要件に加えて、AAAサービスから特定の機能を必要とします。モバイルIPのための一般的なモデルの適用を理解するために、我々は、モバイルノード（MN）は、図1、および外部エージェント（FA）なるようにアテンダントに、クライアントであると考えています。状況は、アドレスの同一位置気付またはIPv6モバイルノードとIPv4の移動ノードの場合には、例えば、何フォーリンエージェントが存在しないことが発生した場合、同等の付随機能は、アドレス割当てエンティティによって提供されます、例えば、DHCPサーバ。そのような付随機能は、この文書の範囲外です。ホームエージェントは、モバイルIPに重要ながら、AAAHが果たした役割に従属する初期登録時の役割を担うことが許可されています。 （図3に示すように）、モバイルIPへの適用のために、我々は一般的なモデルを変更します。初期登録後、モバイルノードは、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を分離する可能性がある広域インターネットを横断するのに要する時間です。これは最初のモバイルIP登録して、さらに強力なAAAの統合関数自身の動機だけでなく、AAA機能の統合につながります。移動ノードの初期登録のためのネットワークを通過するメッセージの数を減らすために、
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.
訪問先ネットワーク（AAAL）とホームネットワーク（AAAH）におけるAAA機能は、登録メッセージを処理するために、外国人のエージェントとホームエージェントとのインターフェースにする必要があります。待ち時間は、AAAとモバイルIPモビリティエージェントと一緒に処理される初期登録の結果として減少するであろう。後続の登録は、しかしながら、RFC 2002 [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、および他の（専門の）ドメインによる許可およびアカウンティング、例えば、クレジットカード会社によって提供されている場合、このような事態が発生する可能性があります。外部エージェントは、AAAHにインタフェースAAAL、モバイルノードの唯一の認証情報を送信します。モバイルノードの許可に成功した後、外国人のエージェントは、モバイルIP登録手順を続行することができます。そのようなスキームは、AAA機能とモバイルIPプロトコルへのアクセスがsequentializedれる場合より遅延を導入します。後続の登録は、AAAとのさらなる対話なしRFC 2002 [13]に従って処理されるであろう。結合またはAAAメッセージから/でモバイルIPプロトコルのデータを分離するかどうかを最終的に政策決定です。モバイルIPプロトコルのデータおよびAAAメッセージの分離に成功し、モバイルノードのホームエージェントのIPアドレスが付随する機能を実行する外国人のエージェントに提供されている場合にのみ行うことができます。
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機能は、単一のインターネット・トラバーサルの間に処理されるべきです。これは、モバイル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登録のための[再]認証を有効にします
- 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プロトコル拡張機能を使用AAAサーバによって処理される初期登録シーケンスの一部として、モバイルIP登録メッセージ。
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 | |
| | | | | | | | | |
+------+ | +------+ | | +------+ |
| | | |
+--------------+ +----------------------+
Figure 3: AAA Servers with Mobile IP agents
図3：モバイルIP剤とAAAサーバ
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登録を実行するために、ホームエージェントと外部エージェントを有効に起こることがあることを意味します。初期登録後は、図3のAAAHとAAALは必要ではないだろう、とその後のモバイル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 agent from the data supplied by the mobile node. The foreign agent becomes a translation agent between the Mobile IP registration protocol and AAA.
AAAHにAAALを通してFAによって送信された任意のモバイルIPデータは、AAAサーバへの不透明考えなければなりません。 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サーバは、モバイル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 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.
- MNとホームエージェント（HA）との間にセキュリティアソシエーションを識別または作成します。モバイルIP登録に必須であるHA認証拡張、 - これは、MNのための[再]認証データを生成するためにMNのために必要とされます。 - 外国人のエージェントが同じモバイルノードがモバイルIPサービスのための継続的な許可を要求しているという保証を得るために続けることができるように、同じ外国人のエージェントで、後続の登録で使用するために、モバイルノードと外部エージェント間のセキュリティアソシエーションを識別または作成。 - 外国人のエージェントが同じホームエージェントは、モバイルIPサービスのための承認を続けているという保証を得るために続けることができるように、同じ外国人のエージェントで、後続の登録で使用するために、ホームエージェントと外部エージェント間のセキュリティアソシエーションを識別または作成モバイルノード。 - モバイルIPエンティティにセキュリティアソシエーション（およびセキュリティパラメータインデックス、またはSPI）の分布に参加 - AAAサーバは、モバイルノードが提供する証明書を検証し、外国人のエージェントに信頼性の高い指標を提供できなければなりません。 - AAALは、モバイルノードおよび/またはモバイルノードのホームエージェントとのセキュリティアソシエーションの許容寿命について外国人のエージェントからの指示を受け入れる必要があります。これらのセキュリティアソシエーションのために、この寿命は、移動ノードにフォーリンエージェントが提供する登録の有効期間の整数倍であるべきです。これにより、移動ノードの再登録に必要な時間をshortenning、AAAレベルで場所を取るための再認証を必要とせずに場所を取るために、モバイルIPの再認証を可能にしてもよいです。 - AAAサーバは、登録が外部エージェントを介してトンネルモバイルノードにブロードキャストやマルチキャストサービスを必要とするかどうかに応じて、モバイルIP登録の承認の彼らの受け入れを調整することができるべきです。 - また、リバーストンネリングはまた、モバイル・ノードの接続に必要な要件であってもよいです。したがって、AAAサーバも登録が外国人のエージェントを介してホームドメインにリバーストンネリングのサポートを必要とするかどうかに応じて、モバイル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].
このプロセスの各呼び出しは、[再]登録の間に長い遅延が発生する可能性があるため、モバイルIPで使用するためにAAAサーバから配布任意のセキュリティアソシエーションのライフタイムは、[、AAAキー配布の頻発開始を避けるために十分な大きさですべきです5]。モバイルIPの原因で登録遅延は、パケットおよびサービスの著しい混乱を落としました。外国人のエージェントとホームエージェントにAAAHが配布任意のキーはIKE（Internet Key Exchange）を開始するために使用されるかもしれないことに注意してください[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によるいかなる行動に依存しないセキュリティアソシエーション確立を有することができること、さらに注意してください。
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で識別することを希望し、外部ドメインでの使用のために動的に割り当てられたホームアドレスを取得します。これらの人々は（図2を参照）、多くの場合、自分のコンピュータがモバイルIPを実装する方法についての詳細は無関心であってもよく、実際に自分自身とAAAH間のことを除いて彼らのホームエージェントのいずれかの知識や任意のセキュリティ関連性を持っていないかもしれません。この場合には、モバイル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 with a home agent that might be designated by the mobile node.
モバイルIPは、モバイルノードに割り当てられたホームアドレスは、ホームエージェントは、モバイルノードにサービスを提供するのと同じサブネットに属している必要があり。 IPのホームアドレスの有効利用のために、ホームAAA（AAAH）は、新たに割り当てられたホームアドレスで使用するためにホームエージェントを選択することができるべきです。多くの場合、モバイルノードは、すでにモバイルノードは、既存のホームアドレスを持っていない場合でも、そのホームエージェントのアドレスを知っているだろう。したがって、ホームAAA（AAAH）は、移動ノードによって指定されるかもしれないホームエージェントにホームアドレスの割り当てを調整することができなければなりません。
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.
ホームアドレスとモバイルのホームエージェントを割り当てると、クライアントのモバイルノード用の構成ニーズの更なる簡素化を提供します。現在、提案された標準のモバイルIP仕様で[13]モバイルノードはホームアドレスおよびホームエージェントのアドレス、並びにとそのホームエージェントとのセキュリティアソシエーションを使用して構成されなければなりません。対照的に、提案されたAAA機能は、そのNAIとAAAHで使用するための安全な共有シークレットを使用して構成するモバイルノードを必要とするだけであろう。 AAAHのモバイルノードのホームアドレス、ホームエージェントのアドレス、モバイルノードとホームエージェント間のセキュリティアソシエーション、さらにはアイデンティティ（DNS名またはIPアドレス）は、すべての動的モバイルIPの初期の一部として決定することができます外部ドメイン（すなわち、AAAのインタフェース機能を持つ外国人のエージェント）におけるモビリティエージェントへの登録。それにもかかわらず、モバイルノードは、MN-HAのセキュリティ拡張機能だけでなく、AAAの資格情報を含めるように選択することができ、かつ両方が存在するときに提案モバイル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がクライアントのホームドメインの名前だけでなく、クライアントの識別情報をコードしていることです。これは、のNAIが（セクション4を参照）は、今日使用されている方法のための既存の業界の慣行に従っています。ホームドメイン名がクライアントのホームドメインにサービスを提供するホームAAAを検索するローカルAAA（AAAL）によって使用できるようになります。一般的なモデルでは、AAALはまた、そのAAAHで使用するために、適切なセキュリティアソシエーションを識別しなければなりません。第6節は、今述べたようにAAALとAAAHとして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サーバは、モバイルに透過性であるように、ファイアウォールを設定しますその管理ドメインの境界にファイアウォールに制御メッセージとキーを発行することができるべきであると提案していますモバイルノードからIP登録およびデータトラフィック。
+-------------------------+ +--------------+
| +------+ +------+ | | +------+ |
| | | | | | | | | |
| | HA +----+ AAAL | | | | AAAH | |
| | | | +-------------------+ | |
| +-+----+ +---+--+ | | +------+ |
| | | | | Home Domain |
| | +- - - - - + | +--------------+
+------+ | +-+--+-+ |
| | | | | |
| MN +------+ FA | |
| | | | | Local Domain |
+------+ | +------+ |
+-------------------------+
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 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.
図4において、AAALは、ローカルドメイン内のホームエージェントを割り当てるモバイルノードから要求を受信しました。新しいホームエージェントは、将来のモバイルIP登録を有効にするAAALから鍵を受け取ります。絵からは、このような構成は、このようなセクション5.2で簡単に説明したようにドメインの境界にファイアウォール保護の問題を回避することは明らかです。一方、この構成では、それが困難なモバイルノードは、モバイルノードのホーム管理ドメイン内の任意の通信相手からのデータを受信できるようになります。なお、このモデルでは、モバイルノードのホームアドレスは、ルーティングの目的のために外部ドメインに所属しています。したがって、その新しいIPアドレスを使用して、モバイルノードのホームFQDN（完全修飾ドメイン名[10]）を関連付けるDNSへの動的更新、ホームDNSサーバのデータベースに外国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がローカルに必要なすべての認証機能を管理することができる場合には、その後、AAAHと対話するためのAAAプロトコルやインフラは必要ありません。得られた簡単な構成は、図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 | | |
+------+ | +------+ |
+-------------------------+
Figure 5: Local Payment for Local Mobile IP services
図5：ローカルモバイルIPサービスのための現地支払い
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はまだホームエージェント、適切なキー、およびモバイルノードのホームアドレスを割り当てる必要があります。
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ネットワークにおいて頻繁にあってもよいので、ハンドオフプロセスに関与する待ち時間を最小限に抑えることが不可欠です。バインディングアップデートを使用して、これを行うための一つの方法のために[15]ルート最適化のドキュメントに、例えば、参照してください。モバイルノードが新たな訪問サブネットに入ると、それは前の外国人のエージェントのNAIを提供することが望ましいであろう。新FAは、KDCセッションキー情報を取得するために、以前のFAに連絡するか、この情報を使用することができ、またはそれはAAALから鍵を取得しようとすることができます。 AAALが必要なキーイング情報を提供することができない場合、要求は新しいキー情報を取得するために、モバイルノードのAAAHに送信する必要があります。最初の承認後、さらに権限は、ローカルドメイン内でローカルに実行する必要があります。
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.
MNがハンドオーバの結果として、新しい外国のサブネットに移動し、今で異なるFAによって提供されている場合、このドメインのAAALは、MNはただの信憑性を検証するためにから手渡されたことをドメインにAAALに接触してもよいですMNおよび/またはセッションキーを取得します。新しいサービス提供AAALは、MNから供給される前のFA NAI情報から、以前に訪問したドメインのAAALのアドレスを決定することができます。
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）の数が増加するにつれて、使用するセキュリティモデルによっては、この構成では、信頼関係の数の二次成長を引き起こす可能性があります。これは、[3]、及び任意AAA提案、この問題を解決しなければならないROAMOPSワーキンググループによって問題として同定されています。ブローカーを使用すると、/ダイレクトビジネスを必要とするすべての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メッセージを中継することができます。
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.
けれども、このメカニズムは、ブローカーはその関与を完了した後、関係ブローカーに許可およびアカウンティングメッセージの追加コピーの結果として関与がより多くのメッセージがあるかもしれないドメイン間でのメッセージの転送中の待ち時間を減らすことができます。また、新しいセキュリティアソシエーションは、（例えば、ISAKMPの使用から）AAALとAAAH間で作成する必要がある場合は特に、ネットワークへの初期アクセスのための追加の待ち時間があるかもしれません。これらの遅延は、待ち時間クリティカルなアプリケーションのための重要な要素になることがあります。
Local Domain Home Domain
+--------------+ +----------------------+
| +------+ | +------+ | +------+ |
| | | | | | | | | |
| | AAAL +-------+ AAAB +--------+ AAAH | |
| | | | | | | | | |
| +------+ | +------+ | +------+ |
| | | | |
| | | +----------------------+
+------+ | +---+--+ |
| | | | | | C = client
| C +- -|- -+ A | | A = attendant
| | | | | | AAAL = local authority
+------+ | +------+ | AAAH = home authority
| | AAAB = broker authority
+--------------+
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は、他のすべてのネットワークと直接ビジネスやセキュリティ関係を持つようにネットワークのそれぞれを必要とせずに協力する地元や家のドメインを可能にします。したがって、ブローカーはそれ以外の独立したネットワークドメイン間の信頼関係を管理するために必要なスケーラビリティを提供します。ブローカーを使用すると、ドメイン間の独立した信頼関係を管理妨げるものではないが、それはそうすることに代替を提供しません。ただ、AAAHとAAAL（セクション5を参照）と同様に、モバイルIP制御メッセージに固有のデータは、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つのまたは複数の中間承認ポイント（例えば、ブローカー）を横断することができるので、再送は長いエンド・ツー・エンドの遅延を回避するために、中間点から必要とされます。
- 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.
- セキュリティをエンドツーエンド。ローカル・ドメインとホーム・ドメインは、メッセージは、中間権威サーバを通過したとしても、メッセージ内の署名を検証できなければなりません。 - ホームドメイン内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):
仲介動作は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プロトコルおよびインフラストラクチャに存続させることができない重大な問題です。
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サービスの場合には、これらの管理要件は、自然、そしてすでによくあるため、ダイヤルアップネットワークアクセスの経験を今日のインターネットで理解されています。
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およびモバイルIPv6のためのモバイルIPとの間の主な違いは、IPv6でない外国人のエージェントが存在しないことです。付随する機能は、したがって、他の場所に配置されなければなりません。その関数の論理リポジトリは、ステートフルアドレス自動設定のために、ステートレスアドレス自動設定のため、または他の最寄りのDHCPv6サーバで、ローカルルータのいずれかです。後者の場合は、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.
MN-NAIは、この文書の以前のセクションで説明されているようAAALv6にモバイルノードを識別するために等しく有用であろう。
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に感謝します。この文書のテキストの一部はパットカルフーン共著ドラフトから取られました。パトリック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.
セクション5.5および3.1節での要件は、TIAのTR45.6ワーキンググループのメンバーが提出した案から採取しました。私たちは、そのドラフトの著者によってなされた作業を承認したいと思います：トム・ヒラー、パット・ウォルシュ、興チェン、マーク・マンソン、ゴパルDommety、Sanjeevan Sivalingham、Byng-グン・リム、ピートマッキャン、ブレントハーシュマン、セルジュ・マニング、レイ・ス、ハン・クー、マーク・Lipford、パットカルフーン、エリック・ジャック、エド・キャンベル、そしてYingchun徐。
References
リファレンス
[1] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[1] Aboba、B.及びM. Beadles、 "ネットワークアクセス識別子"、RFC 2486、1999年1月。
[2] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[2] Aboba、B.、およびJ. Vollbrecht、 "ローミング中のプロキシ連鎖とポリシー実装"、RFC 2607、1999年6月。
[3] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, December 1998.
[3] Aboba、B.およびG.ゾルン、 "ローミングプロトコルを評価するための基準"、RFC 2477、1998年12月します。
4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
4]ブラドナーの、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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ネットワーク識別子拡張、RFC 2794、2000年3月住所。
[7] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[7]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、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.およびD.ソロ、 "インターネットX.509公開鍵基盤証明書とCRLプロファイル"、RFC 2459、1999年1月。
[9] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[9]コールズ、J.及びC.ノイマン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 1510、1993年9月。
[10] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[10] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[11] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998.
[11]モンテネグロ、G.およびV.グプタ、 "モバイルIPのための日のSKIPファイアウォール越え"、RFC 2356、1998年6月。
[12] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[12]パーキンス、C.、 "IP内IPカプセル化"、RFC 2003、1996年10月。
[13] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[13]パーキンス、C.、 "IPモビリティサポート"、RFC 2002、1996年10月。
[14] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[14]パーキンス、C.、 "IP内の最小カプセル化"、RFC 2004、1996年10月。
[15] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress.
[15]パーキンス、C.およびD.ジョンソン、「モバイルIPにおける経路最適化」が進行中で働いています。
[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. Willens、RFC 2138、1997年4月 "ユーザーサービス（RADIUS）においてリモート認証ダイヤル"。
[17] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for PPP IPCP", RFC 2290, February 1998.
[17]ソロモン、J.及びS.ガラス、 "PPP IPCPのためのモバイルIPv4の設定オプション"、RFC 2290、1998年2月。
Addresses
アドレス
The working group can be contacted via the current chairs:
ワーキンググループは、現在の椅子を介して接触させることができます。
Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA
Basavarajパティルノキア6000接続のドライブアーヴィング、TX 75039 USA
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
フィル・ロバーツモトローラ1501西シュアードライブアーリントンハイツ、IL 60004 USA
Phone: +1 847-632-3148 EMail: QA3445@email.mot.com
電話：+1 847-632-3148電子メール：QA3445@email.mot.com
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 USA
Phone: +1 650-786-7733 Fax: +1 650-786-6445 EMail: pcalhoun@eng.sun.com
電話：+1 650-786-7733ファックス：+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ネットワークプロトコルシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134-1706 USA
Phone: +1-408-525-1404 Fax: +1 408-526-4952 EMail: gdommety@cisco.com
電話：+ 1-408-525-1404ファックス：+1 408-526-4952電子メール：gdommety@cisco.com
Steven M. Glass Sun Microsystems 1 Network Drive Burlington, MA 01803 USA
スティーブンM.ガラスSun Microsystemsの1ネットワークドライブバーリントン、MA 01803 USA
Phone: +1-781-442-0504 EMail: steven.glass@sun.com
電話：+ 1-781-442-0504 Eメール：steven.glass@sun.com
Stuart Jacobs Secure Systems Department GTE Laboratories 40 Sylvan Road Waltham, MA 02451-1128 USA
スチュアート・ジェイコブスセキュアシステム部GTE研究所40シルバンロードウォルサム、マサチューセッツ州02451から1128 USA
Phone: +1 781-466-3076 Fax: +1 781-466-2838 EMail: sjacobs@gte.com
電話：+1 781-466-3076ファックス：+1 781-466-2838電子メール：sjacobs@gte.com
Tom Hiller Lucent Technologies Rm 2F-218 263 Shuman Blvd Naperville, IL 60566 USA
トム・ヒラールーセント・テクノロジーズRmの2F-218 263シューマンブルバードネーパーヴィル、IL 60566 USA
Phone: +1 630 979 7673 Fax: +1 630 713 3663 EMail: tomhiller@lucent.com
電話：+1 630 979 7673ファックス：+1 630 713 3663 Eメール：tomhiller@lucent.com
Peter J. McCann Lucent Technologies Rm 2Z-305 263 Shuman Blvd Naperville, IL 60566 USA
ピーター・J.マッキャンルーセント・テクノロジーズRmの2Z-305 263シューマンブルバードネーパーヴィル、IL 60566 USA
Phone: +1 630 713 9359 Fax: +1 630 713 4982 EMail: mccap@lucent.com
電話：+1 630 713 9359ファックス：+1 630 713 4982 Eメール：mccap@lucent.com
Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA
Basavarajパティルノキア6000接続のドライブアーヴィング、TX 75039 USA
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フェアチャイルドドライブマウンテンビュー、カリフォルニア94043 USA
Phone: +1-650 625-2986 Fax: +1 650 625-2502 EMail: charliep@iprg.nokia.com
電話：+ 1-650 625-2986ファックス：+1 650 625-2502 Eメール：charliep@iprg.nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。