[要約] 要約：RFC 2977は、モバイルIPの認証、認可、および会計要件に関するガイドラインです。 目的：このRFCの目的は、モバイルIPネットワークでのセキュリティとアカウンティングの要件を定義し、モバイルユーザーの認証と認可を確保することです。
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.
Copyright（c）The Internet Society（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の幅広い展開の経済的インセンティブが提供されます。このドキュメントでは、モバイルIPがAAAプロトコルに配置する機能およびパフォーマンスの要件を特定、説明、議論します。
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.
ブローカー他の2つの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].
このドキュメントでは、キーワード「可能性がある」、「必要はない」、「オプション」、「推奨」、「必要」、「必要はない」は、[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サーバー
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はセキュリティ協会を共有しなければならないことは明らかです。そうしないと、認証結果、認可、さらにはそれらの間で取引される可能性のある会計データに依存できないためです。ただし、このような二国間セキュリティ関係を必要とすることは、最終的にはスケーラブルではありません。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サーバーを使用できます。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.
2つの別々の管理ドメイン（たとえば、AAAHとAAAL）のノードは、多くの場合、コミュニケーションパートナーのIDを検証するために追加の手順を実行する必要があります。これらの考慮事項は、サーバー間のセキュリティのコンテキストで上記のように重要なセキュリティ要件につながりますが、AAAサーバー間のセキュリティ関連の正確な選択は、このドキュメントの範囲を超えていると考えています。一方、モバイルIPエンティティ間で必要なセキュリティ関連は、モバイルIPに適したAAAインフラストラクチャの設計において、図1に示す一般的なモデルの特定の機能に依存することさえありそうにありません。上記の一般的なモデルは、一般にモバイル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.
このセクションでは、既存のローミング半径ネットワークの運用経験を通じて発見された問題に基づいて追加の要件を詳しく説明します。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アプリケーションまたはタイムアウトが発生したこと。*再送信は、TCPなどの下層プロトコルではなく、信頼できるAAA輸送メカニズムによって制御されます。
* 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メッセージでピギーバックすることを許可する必要があります * AAA応答はタイムリーに配信する必要があります。これにより、モバイルIPがタイムアウトや再送信を行う必要があります。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]を使用してクライアントを識別します。モバイルノードは、NAIをモバイルIP登録リクエスト[6]とともに含めることで自らを識別できます。NAIは「user@realm」という形式です。図1に示すAAAモデルでの使用にユニークで適しています。NAI（「ユーザー@Realm」など）を使用すると、AAALはクライアントのホームドメイン（「Realm」など）を簡単に決定できます。AAALとAAAHの両方は、NAIを使用して、クライアントの特定のIDによってレコードをインデックス付けすることができます。
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が果たす役割に従属する最初の登録中に役割を果たすことができます。モバイル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 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関数自体を統合するためのさらに強力な動機と、AAA関数と最初のモバイルIP登録と統合が統合されます。モバイルノードの初期登録のためにネットワークを横断するメッセージの数を減らすために、訪問ネットワーク（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に送信します。これはAAAHにインターフェイスします。モバイルノードの承認が成功した後、外国人エージェントはモバイルIP登録手順を継続することができます。このようなスキームは、AAA機能へのアクセスとモバイルIPプロトコルへのアクセスが順調になっている場合、より多くの遅延を導入します。後続の登録は、AAAとのさらなる相互作用なしに、RFC 2002 [13]に従って処理されます。モバイルIPプロトコルデータをAAAメッセージとまたはfromと組み合わせるか分離するかは、最終的にはポリシー決定です。モバイル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関数は、単一のインターネットトラバーサル中に処理する必要があります。これは、AAAサーバーがモバイルIPエージェントに送信されるプロトコルメッセージを処理することを要求することなく行う必要があります。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では、スパースダッシュ（Soparse）が示すように、ホームエージェント（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.
AAALからAAAHに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）の間のセキュリティ協会を特定または作成します。これは、MNがMN-HA認証拡張機能の[再]認証データを生成するために必要です。これは、モバイルIP登録で必須です。 - 同じ外国人エージェントでの後続の登録で使用するために、モバイルノードと外国人エージェントの間のセキュリティ協会を特定または作成し、外国人エージェントが同じモバイルノードがモバイルIPサービスの継続的な許可を要求したという保証を引き続き取得できるようにします。 - 同じ外国人エージェントでの後続の登録で使用するために、ホームエージェントと外国人エージェントの間のセキュリティ協会を特定または作成します。そのため、外国人エージェントは、同じホームエージェントがモバイルIPサービスの許可を継続しているという保証を引き続き取得できます。モバイルノード。 - モバイルIPエンティティへのセキュリティ協会（およびセキュリティパラメーターインデックス、またはSPI）の配布に参加する-AAAサーバーは、モバイルノードが提供する証明書を検証し、外国人エージェントに信頼できる表示を提供することもできなければなりません。-AAALは、モバイルノードおよび/またはモバイルノードのホームエージェントとのセキュリティ関連について、許容可能な寿命について外国人エージェントからの兆候を受け入れる必要があります。これらのセキュリティ協会にとってのこの寿命は、外国人エージェントがモバイルノードに提供する登録寿命の整数である必要があります。これにより、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）を開始するために使用できることに注意してください[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によって識別し、外国ドメインで使用する動的に割り当てられたホームアドレスを取得したいと考えています。これらの人々は、多くの場合、コンピューターがモバイル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 with a home agent that might be designated by the mobile node.
モバイルIPには、モバイルノードにサービスを提供するホームエージェントと同じサブネットに属するモバイルノードに割り当てられたホームアドレスが必要です。IPホームアドレスを効果的に使用するために、Home 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のID（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（AAAL）が使用して、クライアントのホームドメインにサービスを提供するホームAAAを見つけることができます。一般的なモデルでは、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で簡単に説明したようなドメイン境界でのファイアウォール保護の問題を回避することが明らかです。一方、この構成により、モバイルノードがモバイルノードのホーム管理ドメインのコミュニケーションパートナーからデータを受信することが困難になります。このモデルでは、モバイルノードのホームアドレスはルーティングのために外国ドメインと提携していることに注意してください。したがって、モバイルノードのホームFQDN（完全資格のドメイン名[10]）を新しいIPアドレスに関連付けるためのDNSの動的な更新には、外国のIPアドレスをHome DNSサーバーデータベースに挿入する必要があります。
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と対話するために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ネットワークで頻繁に発生する可能性があるため、ハンドオフプロセスに伴う遅延を最小限に抑えることが不可欠です。たとえば、バインディングアップデートを使用してこれを行う1つの方法については、ルート最適化ドキュメント[15]を参照してください。モバイルノードが新しい訪問されたサブネットに入ると、以前の外国人エージェントのNAIを提供することが望ましいでしょう。新しいFAは、この情報を使用して、以前のFAに連絡してKDCセッションのキー情報を取得するか、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）の数が増加するため、信頼関係の数の2次成長を引き起こす可能性があります。これは、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メッセージを安全に前後にリレーする場合があります。
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がホームドメインに代わってサービングドメインへの支払い責任を受け入れると仮定すると、サービスドメインは提供されるサービスの支払いを受け取ることが保証されています。ただし、リダイレクトブローカーは通常、ブローカーが許可および利用されているサービスに対する責任を受け入れる意思があるかどうかを判断するために、ホームドメインからの認証メッセージのコピーとサービングドメインからの会計メッセージのコピーを必要とします。ブローカーが何らかの理由でそのような責任を受け入れない場合、サービングネットワークのモバイルノードへのサービスを終了できる必要があります。複数のブローカーが関与している場合、ほとんどの状況では、すべてのブローカーを非常にコピーする必要があります。これは、外国人エージェントとアーサールの追加の負担を表している可能性があります。
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の使用から）、ネットワークへの初期アクセスのための追加のレイテンシもあります。これらの遅延は、潜在的なクリティカルなアプリケーションの重要な要因になる可能性があります。
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):
ブローカー操作が半径[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.
Gopal DommetyとBasavaraj Patilに感謝します。AAA-WGのモバイルIP小委員会に参加してくれたことは、この文書で詳述されている要件の策定で告発されました。モバイルIPメーリングリストへの知覚的なコメントをしてくれたN. Asokanに感謝します。このドキュメントのテキストの一部は、Pat Calhounが共同執筆したドラフトから取得しました。Patrik 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ワーキンググループのメンバーによって提出されたドラフトから取得されました。トム・ヒラー、パット・ウォルシュ、シン・チェン、マーク・マンソン、ゴパル・ドメティ、サンジーヴァン・シバリンガム、ビン・ケウン・リム、ピート・マッキャン、ブレント・ヒルシュマン、セルジュ・マニング、レイ・ホスー、ハング・クー、マーク・リプフォード、パット・カルホーン、エリック・ジャケス、エド・キャンベル、Yingchun Xu。
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. Zorn、「ローミングプロトコルを評価するための基準」、RFC 2477、1998年12月。
4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、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。モバイルコンピューティング環境での信頼できる輸送プロトコルのパフォーマンスを向上させます。Communicationsの選択された領域に関するIEEEジャーナル、13（5）：850--857、1995年6月。
[6] Calhoun, P. and C. Perkins, "Mobile IP Network Address Identifier Extension, RFC 2794, March 2000.
[6] Calhoun、P。およびC. Perkins、「モバイルIPネットワークアドレス識別子拡張機能、RFC 2794、2000年3月。
[7] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[7] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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.、Ford、W.、Polk、T。、およびD. Solo、「Internet X.509公開キーインフラストラクチャ証明書とCRLプロファイル」、RFC 2459、1999年1月。
[9] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[9] Kohl、J。およびC. Neuman、「The Kerberos Network Authentication Service（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のSun's Skip Firewalversal」、RFC 2356、1998年6月。
[12] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[12] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[13] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[13] Perkins、C。、「IP Mobility Support」、RFC 2002、1996年10月。
[14] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[14] Perkins、C。、「IP内の最小カプセル化」、RFC 2004、1996年10月。
[15] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress.
[15] Perkins、C。およびD. Johnson、「モバイル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.、Rubens、A.、Simpson、W。and S. Willens、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2138、1997年4月。
[17] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for PPP IPCP", RFC 2290, February 1998.
[17] Solomon、J。およびS. Glass、「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 Patil Nokia 6000 Connection Drive Irving、TX 75039 USA
Phone: +1 972-894-6709
EMail: Basavaraj.Patil@nokia.com
Phil Roberts Motorola 1501 West Shure Drive Arlington Heights, IL 60004 USA
フィルロバーツモトローラ1501ウェストシュアードライブアーリントンハイツ、イリノイ60004 USA
Phone: +1 847-632-3148 EMail: QA3445@email.mot.com Questions about this memo can be directed to:
電話：1 847-632-3148電子メール：QA3445@email.mot.comこのメモに関する質問は、次のように向けることができます。
Pat R. Calhoun Network and Security Center Sun Microsystems Laboratories 15 Network Circle Menlo Park, California 94025 USA
PAT R. Calhoun Network and Security Center Sun Microsystems Laboratories 15 Network Circle Menlo Park、California 94025 USA
Phone: +1 650-786-7733
Fax: +1 650-786-6445
EMail: pcalhoun@eng.sun.com
Gopal Dommety IOS Network Protocols Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
GOPAL DOMMETY IOS Network Protocols Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134-1706 USA
Phone: +1-408-525-1404
Fax: +1 408-526-4952
EMail: gdommety@cisco.com
Steven M. Glass Sun Microsystems 1 Network Drive Burlington, MA 01803 USA
Steven M. Glass Sun Microsystems 1ネットワークドライブバーリントン、マサチューセッツ州01803 USA
Phone: +1-781-442-0504
EMail: steven.glass@sun.com
Stuart Jacobs Secure Systems Department GTE Laboratories 40 Sylvan Road Waltham, MA 02451-1128 USA
Stuart Jacobs Secure Systems Department Gte Laboratories 40 Sylvan Road Waltham、MA 02451-1128 USA
Phone: +1 781-466-3076 Fax: +1 781-466-2838 EMail: sjacobs@gte.com Tom Hiller Lucent Technologies Rm 2F-218 263 Shuman Blvd Naperville, IL 60566 USA
電話：1 781-466-3076 FAX：1 781-466-2838メール：sjacobs@gte.com Tom Hiller Lucent Technologies RM 2F-218 263 Shuman Blvd Naperville、IL 60566 USA
Phone: +1 630 979 7673
Fax: +1 630 713 3663
EMail: tomhiller@lucent.com
Peter J. McCann Lucent Technologies Rm 2Z-305 263 Shuman Blvd Naperville, IL 60566 USA
Peter J. McCann Lucent Technologies RM 2Z-305 263 Shuman Blvd Naperville、IL 60566 USA
Phone: +1 630 713 9359
Fax: +1 630 713 4982
EMail: mccap@lucent.com
Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA
Basavaraj Patil Nokia 6000 Connection Drive Irving、TX 75039 USA
Phone: +1 972-894-6709
Fax : +1 972-894-5349
EMail: 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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。