[要約] RFC 5637は、モバイルIPv6における認証、認可、会計（AAA）の目標について述べています。このRFCの目的は、モバイルIPv6ネットワークでのセキュリティとアクセス制御の向上を促進することです。
Network Working Group G. Giaretta
Request for Comments: 5637 Qualcomm
Category: Informational I. Guardini
E. Demaria
Telecom Italia
J. Bournelle
Orange Labs
R. Lopez
University of Murcia
September 2009
Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6
モバイルIPv6の認証、承認、会計（AAA）目標
Abstract
概要
In commercial and enterprise deployments, Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case, all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the Authentication, Authorization, and Accounting (AAA) infrastructure (e.g., Network Access Server and AAA server) also offers a solution component for Mobile IPv6 bootstrapping. This document describes various scenarios where a AAA interface for Mobile IPv6 is required. Additionally, it lists design goals and requirements for such an interface.
商業およびエンタープライズの展開では、モバイルIPv6は、Mobility Services Provider（MSP）が提供するサービスになります。この場合、すべてのプロトコル操作を明示的に承認および追跡する必要がある場合があり、モバイルIPv6とAAAインフラストラクチャ間の相互作用が必要です。認証、承認、および会計（AAA）インフラストラクチャ（Network Access ServerやAAA Serverなど）を統合することで、モバイルIPv6ブートストラップのソリューションコンポーネントも提供します。このドキュメントでは、モバイルIPv6のAAAインターフェイスが必要なさまざまなシナリオについて説明します。さらに、このようなインターフェイスの設計目標と要件をリストします。
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Motivation ......................................................4
4. Bootstrapping Scenarios .........................................4
4.1. Split Scenario .............................................5
4.2. Integrated Scenario ........................................6
5. Goals for AAA-HA Interface ......................................6
5.1. General Goals ..............................................6
5.2. Service Authorization ......................................7
5.3. Accounting .................................................8
5.4. Mobile Node Authentication .................................8
5.5. Provisioning of Configuration Parameters ...................8
6. Goals for the AAA-NAS Interface .................................9
7. Security Considerations .........................................9
8. Acknowledgements ................................................9
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
Mobile IPv6 [1] provides the basic IP mobility functionality for IPv6. When Mobile IPv6 is used in tightly managed environments with the use of the AAA (Authentication, Authorization, and Accounting) infrastructure, an interface between Mobile IPv6 and AAA protocols needs to be defined. Also, two scenarios for bootstrapping Mobile IPv6 service [2], i.e., split [3] and integrated [6] scenarios, require the specification of a message exchange between the Home Agent (HA) and AAA infrastructure for authentication and authorization purposes and a message exchange between the AAA server and the NAS in order to provide the visited network with the necessary configuration information (e.g., Home Agent address).
モバイルIPv6 [1]は、IPv6の基本的なIPモビリティ機能を提供します。AAA（認証、承認、および会計）インフラストラクチャを使用して、緊密に管理された環境でモバイルIPv6が使用されている場合、モバイルIPv6とAAAプロトコルの間のインターフェイスを定義する必要があります。また、モバイルIPv6サービスをブートストラップするための2つのシナリオ[2]、つまり分割[3]および統合[6]シナリオには、認証と承認の目的とAのためのホームエージェント（HA）とAAAインフラストラクチャの間のメッセージ交換の指定が必要です。訪問されたネットワークに必要な構成情報（ホームエージェントアドレスなど）を提供するために、AAAサーバーとNASの間のメッセージ交換。
This document describes various scenarios where a AAA interface is required. Additionally, it lists design goals and requirements for the communication between the HA and the AAA server and between the NAS and the AAA server needed in the split and integrated scenarios. Requirements are listed in case either IPsec or RFC 4285 [4] is used for Mobile IPv6 authentication.
このドキュメントでは、AAAインターフェイスが必要なさまざまなシナリオについて説明します。さらに、HAとAAAサーバーの間、およびSPLITおよび統合シナリオで必要なNASとAAAサーバー間の通信の設計目標と要件をリストします。IPSECまたはRFC 4285 [4]のいずれかがモバイルIPv6認証に使用される場合に要件がリストされています。
This document only describes requirements, goals, and scenarios. It does not provide solutions.
このドキュメントは、要件、目標、シナリオのみを説明しています。解決策は提供されません。
Notice that this document builds on the security model of the AAA infrastructure. As such, the end host/user shares credentials with the home AAA server and the communication between the AAA server and the AAA client may be protected. If the AAA server and the AAA client are not part of the same administrative domain, then some sort of contractual relationship between the involved administrative domains is typically in place in the form of roaming agreements.
このドキュメントは、AAAインフラストラクチャのセキュリティモデルに基づいていることに注意してください。そのため、エンドホスト/ユーザーはホームAAAサーバーと資格情報を共有し、AAAサーバーとAAAクライアント間の通信を保護することができます。AAAサーバーとAAAクライアントが同じ管理ドメインの一部ではない場合、関係する管理ドメイン間の何らかの契約上の関係は、通常、ローミング契約の形で整っています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5], with the qualification that, unless otherwise stated, these words apply to the design of the AAA protocol extension, not its implementation or its usage.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [5]に記載されているように解釈されるために、特に明記しない限り、これらの単語は、その実装や使用法ではなく、AAAプロトコル拡張の設計に適用されるという資格とともに。
The following terms are extracted from [2].
次の用語は[2]から抽出されます。
o Access Service Authorizer (ASA). A network operator that authenticates a Mobile Node and establishes the Mobile Node's authorization to receive Internet service.
o アクセスサービス承認者（ASA）。モバイルノードを認証し、インターネットサービスを受信するモバイルノードの承認を確立するネットワークオペレーター。
o Access Service Provider (ASP). A network operator that provides direct IP packet forwarding to and from the end host.
o アクセスサービスプロバイダー（ASP）。エンドホストとの間で直接IPパケット転送を提供するネットワークオペレーター。
o Mobility Service Authorizer (MSA). A service provider that authorizes Mobile IPv6 service.
o モビリティサービスオーサイザー（MSA）。モバイルIPv6サービスを承認するサービスプロバイダー。
o Mobility Service Provider (MSP). A service provider that provides Mobile IPv6 service. In order to obtain such service, the Mobile Node must be authenticated and prove authorization to obtain the service.
o モビリティサービスプロバイダー（MSP）。モバイルIPv6サービスを提供するサービスプロバイダー。このようなサービスを取得するには、モバイルノードを認証し、サービスを取得するための許可を証明する必要があります。
Mobile IPv6 specification [1] requires that Mobile Nodes (MNs) are provisioned with a set of configuration parameters -- namely, the Home Address and the Home Agent Address, in order to accomplish a home registration. Moreover, MNs and Home Agents (HAs) must share the cryptographic material needed in order to set up IPsec security associations to protect Mobile IPv6 signaling (e.g., shared keys or certificates). This is referred as the bootstrapping problem: as described in [2], the AAA infrastructure can be used as the central element to enable dynamic Mobile IPv6 bootstrapping. In this case, the AAA infrastructure can be exploited to offload the end host's authentication to the AAA server as well as to deliver the necessary configuration parameters to the visited network (e.g., Home Agent address as specified in [6]).
モバイルIPv6仕様[1]では、モバイルノード（MNS）には、ホーム登録を達成するために、モバイルノード（MNS）に一連の構成パラメーター、つまりホームアドレスとホームエージェントアドレスをプロビジョニングする必要があります。さらに、MNSおよびホームエージェント（HAS）は、モバイルIPv6シグナル伝達（共有キーや証明書など）を保護するためにIPSECセキュリティ協会を設定するために必要な暗号化資料を共有する必要があります。これはブートストラップの問題と呼ばれます。[2]で説明されているように、AAAインフラストラクチャは、動的なモバイルIPv6ブートストラップを可能にするための中心要素として使用できます。この場合、AAAインフラストラクチャは、ENDホストの認証をAAAサーバーにオフロードし、必要な構成パラメーターを訪問ネットワークに配信するために活用できます（例：[6]で指定されているホームエージェントアドレス）。
Moreover, in case Mobile IPv6 is a service offered by a Mobility Service Provider (MSP), all protocol operations (e.g., home registrations) may need to be explicitly authorized and monitored (e.g., for accounting purposes). This can be accomplished relying on the AAA infrastructure of the Mobility Service Authorizer (MSA) that stores user profiles and credentials.
さらに、モバイルIPv6がモビリティサービスプロバイダー（MSP）が提供するサービスである場合、すべてのプロトコル操作（家庭登録など）を明示的に承認および監視する必要がある場合があります（例：会計目的など）。これは、ユーザープロファイルと資格情報を保存するMobility Service Authrizer（MSA）のAAAインフラストラクチャに依存して達成できます。
This section describes some bootstrapping scenarios in which communication between the AAA infrastructure of the Mobility Service Provider and the Home Agent is needed. The need of MIPv6-aware communication between the AAA server and the Network Access Server (NAS) is also described. The purpose of this section is only to explain the situation where bootstrapping is required. The actual mechanisms and additional details are specified elsewhere or are left for future work (see, e.g., [2], [3], and [6]).
このセクションでは、モビリティサービスプロバイダーのAAAインフラストラクチャとホームエージェントの間の通信が必要なブートストラップシナリオについて説明します。AAAサーバーとネットワークアクセスサーバー（NAS）の間のMIPV6対応通信の必要性についても説明します。このセクションの目的は、ブートストラップが必要な状況を説明することだけです。実際のメカニズムと追加の詳細は、他の場所で指定されているか、将来の作業に残されています（例えば[2]、[3]、[6]を参照）。
In the split scenario [3], there is the assumption that the mobility service and network access service are not provided by the same administrative entity. This implies that the mobility service is authorized by the MSA that is a different entity from the ASA.
分割シナリオ[3]では、モビリティサービスとネットワークアクセスサービスが同じ管理エンティティによって提供されていないという仮定があります。これは、モビリティサービスがASAとは異なるエンティティであるMSAによって承認されていることを意味します。
In this scenario, the Mobile Node discovers the Home Agent Address using the Domain Name Service (DNS). It queries the address based on the Home Agent name or by service name. In the former case, the Mobile Node is configured with the Fully Qualified Domain Name (FDQN) of the Home Agent. In the latter case, [3] defines a new service resource record (SRV RR).
このシナリオでは、モバイルノードは、ドメイン名サービス（DNS）を使用してホームエージェントアドレスを発見します。ホームエージェント名またはサービス名に基づいてアドレスをクエリします。前者の場合、モバイルノードは、ホームエージェントの完全資格のドメイン名（FDQN）で構成されています。後者の場合、[3]は新しいサービスリソースレコード（SRV RR）を定義します。
Then the Mobile Node performs an IKEv2 [7] exchange with the HA to set up IPsec Security Associations (SAs) to protect Mobile IPv6 signaling and to configure its Home Address (HoA). Mutual authentication for IKEv2 between Mobile Node and Home Agent can be done with or without use of the Extensible Authentication Protocol (EAP).
次に、モバイルノードはIKEV2 [7] ExchangeをHAと実行して、IPSECセキュリティアソシエーション（SAS）をセットアップしてモバイルIPv6シグナル伝達を保護し、ホームアドレス（HOA）を構成します。モバイルノードとホームエージェント間のIKEV2の相互認証は、拡張可能な認証プロトコル（EAP）の使用の有無にかかわらず実行できます。
If EAP is used for authentication, the operator can choose any available EAP methods. Use of EAP with the AAA infrastructure allows the HA to check the validity of each MN's credentials with the AAA infrastructure, rather than having to maintain credentials for each MN itself. It also allows roaming in terms of Mobile IPv6 service where the MSP and MSA belong to different administrative domains. In this case, the HA in the MSP can check the validity of the credentials provided by the MN with the AAA infrastructure of MSA, receiving the relevant authorization information.
EAPが認証に使用される場合、オペレーターは利用可能なEAPメソッドを選択できます。AAAインフラストラクチャでEAPを使用すると、各MN自体の資格情報を維持する必要があるのではなく、HAが各MNの資格情報の有効性をAAAインフラストラクチャで確認できます。また、MSPとMSAが異なる管理ドメインに属しているモバイルIPv6サービスの観点からローミングを許可します。この場合、MSPのHAは、MSAのAAAインフラストラクチャでMNが提供する資格情報の有効性を確認し、関連する認可情報を受け取ることができます。
The Mobile Node may also want to update its FQDN in the DNS with the newly allocated Home Address. [3] recommends that the HA performs the DNS entry update on behalf of the Mobile Node. For that purpose, the Mobile Node indicates its FDQN in the IKEv2 exchange (in the IDi field in IKE_AUTH) and adds a DNS Update Option in the Binding Update message sent to the HA.
モバイルノードは、新しく割り当てられたホームアドレスを使用して、DNSでFQDNを更新することもできます。[3]は、HAがモバイルノードに代わってDNSエントリアップデートを実行することを推奨しています。そのために、モバイルノードはIKEV2 Exchange（IKE_AUTHのIDIフィールド）のFDQNを示し、HAに送信されたバインディングアップデートメッセージにDNS更新オプションを追加します。
When the Mobile Node uses a Home Agent belonging to a different administrative domain (MSP != MSA), the local HA may not share a security association with the home DNS server. In this case, [3] suggests that the home AAA server is responsible for the update. Thus, the HA should send to the home AAA server the (FDQN, HoA) pair.
モバイルノードが異なる管理ドメイン（MSP！= MSA）に属するホームエージェントを使用する場合、ローカルHAはホームDNSサーバーとセキュリティ協会を共有できない場合があります。この場合、[3]は、Home AAAサーバーが更新の責任を負うことを示唆しています。したがって、HAはHome AAAサーバーに（FDQN、HOA）ペアを送信する必要があります。
In the integrated scenario, the assumption is that the Access Service Authorizer (ASA) is the same as the Mobility Service Authorizer (MSA). Further details of this type of a scenario are being worked on separately [6].
統合されたシナリオでは、Access Service Authorizer（ASA）がMobility Service Authorizer（MSA）と同じであると仮定しています。このタイプのシナリオの詳細は、個別に作業されています[6]。
The Home Agent can be assigned either in the Access Service Provider's network or in the separate network. In the former case, the MSP is the same entity as the ASP, whereas in the latter case the MSP and ASP are different entities.
ホームエージェントは、アクセスサービスプロバイダーのネットワークまたは別々のネットワークのいずれかに割り当てることができます。前者の場合、MSPはASPと同じエンティティですが、後者の場合はMSPとASPは異なるエンティティです。
In this scenario, the Mobile Node discovers the Home Agent Address using DHCPv6. If the user is authorized for Mobile IPv6 service, during the network access authentication the AAAH (the AAA server in the home network) sends the information about the assigned Home Agent to the NAS where the Mobile Node is currently attached. To request Home Agent data, the Mobile Node sends a DHCPv6 Information Request to the All_DHCP_Relay_Agents_and_Servers multicast address. With this request, the Mobile Node can specify if it wants a Home Agent provided by the visited domain (ASP/MSP) or by the home domain (ASA/MSA). In both cases, the NAS acts a DHCPv6 relay. When the NAS receives the DHCPv6 Information Request, it passes Home Agent information received from the AAAH server to the DHCP server, for instance using mechanisms defined in [6].
このシナリオでは、モバイルノードはDHCPV6を使用してホームエージェントアドレスを発見します。ユーザーがモバイルIPv6サービスを許可されている場合、ネットワークアクセス認証中に、AAAH（ホームネットワークのAAAサーバー）は、モバイルノードが現在添付されているNASに割り当てられたホームエージェントに関する情報を送信します。ホームエージェントのデータを要求するために、モバイルノードはdhcpv6情報要求をall_dhcp_relay_agents_and_serversマルチキャストアドレスに送信します。このリクエストにより、モバイルノードは、訪問ドメイン（ASP/MSP）またはホームドメイン（ASA/MSA）によって提供されるホームエージェントが必要かどうかを指定できます。どちらの場合も、NASはDHCPV6リレーに作用します。NASがDHCPV6情報リクエストを受信すると、たとえば[6]で定義されたメカニズムを使用して、AAAHサーバーからDHCPサーバーに受け取ったホームエージェント情報を渡します。
In case the Mobile Node cannot acquire Home Agent information via DHCPv6, it can try the default mechanism based on DNS described in [3]. After the Mobile Node has acquired the Home Agent information, the mechanisms used to bootstrap the HoA, the IPsec Security Association, and the authentication and authorization with the MSA are the same as described in the bootstrapping solution for the split scenario [3].
モバイルノードがDHCPV6を介してホームエージェント情報を取得できない場合、[3]で説明されているDNSに基づいてデフォルトのメカニズムを試すことができます。モバイルノードがホームエージェント情報を取得した後、HOA、IPSECセキュリティ協会のブートストラップに使用されるメカニズム、およびMSAの認証と認証は、分割シナリオのブートストラップソリューションで説明されているものと同じです[3]。
Section 4 raises the need to define extensions for the AAA protocol used between the AAA server of the MSA and the HA. The following sections list the goals for such an interface. This communication is needed for both the split and integrated scenarios.
セクション4では、MSAのAAAサーバーとHAの間で使用されるAAAプロトコルの拡張機能を定義する必要性を提起します。次のセクションには、このようなインターフェイスの目標がリストされています。この通信は、分割シナリオと統合シナリオの両方に必要です。
G1.1 The communication between the AAAH server and the HA MUST reuse existing AAA security mechanisms with regard to authentication, replay, integrity, and confidentiality protection. These communication security mechanisms prevent a number of classical threats, including the alteration of exchanged data (e.g., Mobile IPv6 configuration parameters) and the installation of unauthorized state.
G1.1 AAAHサーバーとHA間の通信は、認証、リプレイ、整合性、および機密保護に関する既存のAAAセキュリティメカニズムを再利用する必要があります。これらの通信セキュリティメカニズムは、交換データの変更（モバイルIPv6構成パラメーターなど）や不正な状態のインストールなど、多くの古典的な脅威を防ぎます。
G2.1 The AAA-HA interface MUST allow the use of a Network Access Identifier (NAI) to identify the user.
G2.1 AAA-HAインターフェイスは、ユーザーを識別するためにネットワークアクセス識別子（NAI）を使用することを許可する必要があります。
G2.2 The HA MUST be able to query the AAAH server to verify Mobile IPv6 service authorization for the Mobile Node.
G2.2 HAは、モバイルノードのモバイルIPv6サービス認証を確認するためにAAAHサーバーを照会できる必要があります。
G2.3 The AAAH server MAY assign explicit operational limitations and authorization restrictions on the HA (e.g., packet filters, QoS parameters).
G2.3 AAAHサーバーは、HAに明示的な運用制限と承認制限を割り当てることができます（パケットフィルター、QoSパラメーターなど）。
G2.4 The AAAH server MUST be able to send an authorization lifetime to the HA to limit Mobile IPv6 session duration for the MN.
G2.4 AAAHサーバーは、MNのモバイルIPv6セッション期間を制限するために、承認寿命をHAに送信できる必要があります。
G2.5 The HA MUST be able to request that the AAAH server grant an extension of the authorization lifetime to the MN.
G2.5 HAは、AAAHサーバーが認証寿命の延長をMNに付与することを要求できる必要があります。
G2.6 The AAAH server MUST be able to force the HA to terminate an active Mobile IPv6 session for authorization policy reasons (e.g., credit exhaustion).
G2.6 AAAHサーバーは、承認ポリシーの理由（クレジットの疲労など）のために、HAにアクティブなモバイルIPv6セッションを終了させることができなければなりません。
G2.7 The HA MUST be able to indicate to the AAAH server the IPv6 HoA that will be assigned to the MN.
G2.7 HAは、MNに割り当てられるIPv6 HOAをAAAHサーバーに示すことができなければなりません。
G2.8 The AAAH server MUST be able to authorize the MN to use an IPv6 HoA and MUST indicate that to the HA.
G2.8 AAAHサーバーは、MNがIPv6HOAを使用するようにMNを承認できる必要があり、HAにそれを示す必要があります。
G2.9 The AAAH server MUST be able to indicate to the HA whether or not the return routability test (HoT (Home Test) and HoTi (Home Test Init)) shall be permitted via the HA for a given MN.
G2.9 AAAHサーバーは、特定のMNに対してHAを介して許可されるかどうかにかかわらず、HAの返品可能性テスト（HOT（ホームテスト）とHOTI（ホームテストINIT））が許可されるかどうかをHAに示すことができなければなりません。
G2.10 The AAAH server MUST be able to support different levels of Mobile IPv6 authorization. For example, the AAAH server may authorize the MN to use MIPv6 (as defined in [1]) or may authorize the MN to utilize an IPv4 HoA assigned for Dual Stack MIPv6 [8].
G2.10 AAAHサーバーは、さまざまなレベルのモバイルIPv6認証をサポートできる必要があります。たとえば、AAAHサーバーは、MNにMIPv6を使用することを許可することができます（[1]で定義されている）またはMNがデュアルスタックMIPv6に割り当てられたIPv4HOAを使用することを許可することができます[8]。
G2.11 The AAAH server MUST be able to indicate to the HA whether the bearer traffic for the MN needs to receive IPsec Encapsulating Security Payload (ESP) protection.
G2.11 AAAHサーバーは、MNのベアラートラフィックがセキュリティペイロード（ESP）保護をカプセル化するIPSECを受信する必要があるかどうかをHAに示すことができなければなりません。
G2.12 The HA MUST be able to authenticate the MN through the AAAH server in case a pre-shared key is used in IKEv2 for user authentication. The exact procedure is part of the solution space.
G2.12は、ユーザー認証のためにIKEV2で事前に共有キーが使用されている場合に、AAAHサーバーを介してMNを認証できる必要があります。正確な手順は、ソリューション空間の一部です。
G3.1 The AAA-HA interface MUST support the transfer of accounting records needed for service control and charging. These include (but may not be limited to): time of binding cache entry creation and deletion, octets sent and received by the Mobile Node in bi-directional tunneling, etc.
G3.1 AAA-HAインターフェイスは、サービス制御と充電に必要な会計記録の転送をサポートする必要があります。これらには、キャッシュの作成と削除の結合時間、双方向トンネルのモバイルノードによって送信および受信される時間などが含まれます。
G4.1 The AAA-HA interface MUST allow the HA to act as a pass-through EAP authenticator.
G4.1 AAA-HAインターフェイスは、HAがパススルーEAP Authenticatorとして機能することを許可する必要があります。
G4.2 The AAA-HA interface MUST support authentication based on the Mobility Message Authentication Options defined in [4].
G4.2 AAA-HAインターフェイスは、[4]で定義されているモビリティメッセージ認証オプションに基づいて認証をサポートする必要があります。
G4.3 The AAAH server MUST be able to provide a MN-HA key (or data used for subsequent key derivation of the MN-HA key by the HA) to the HA if requested. Additional data, such as the Security Parameter Index (SPI) or lifetime parameters, are sent along with the keying material.
G4.3 AAAHサーバーは、要求された場合にHAにMN-HAキー（またはHAによるMN-HAキーの後続のキー派生に使用されるデータ）を提供できる必要があります。セキュリティパラメーターインデックス（SPI）やライフタイムパラメーターなどの追加データは、キーイングマテリアルとともに送信されます。
G4.4 The HA supporting the Authentication Protocol MUST be able to request that the AAAH server authenticate the MN with the value in the MN-AAA Mobility Message Authentication Option.
G4.4認証プロトコルをサポートするHAは、AAAHサーバーがMN-AAAモビリティメッセージ認証オプションの値でMNを認証することを要求できる必要があります。
G4.5 The HA MUST include an identifier of the Mobile Node in the AAA transactions with the AAAH server.
G4.5 HAには、AAAHサーバーを使用したAAAトランザクションにモバイルノードの識別子を含める必要があります。
o The HA SHOULD be able to communicate to the AAAH server the Home Address allocated to the MN and the FQDN of the MN (e.g., for allowing the AAAH server to perform a DNS update on behalf of the MN).
o HAは、AAAHサーバーにMNとMNのFQDNに割り当てられたホームアドレスを通信できるはずです（たとえば、AAAHサーバーがMNに代わってDNSアップデートを実行できるようにするため）。
o The AAAH server SHOULD be able to indicate to the HA if the MN is authorized to autoconfigure its Home Address. If the AAAH does not indicate to the HA if a MN is authorized to autoconfigure its address, the MN is not authorized.
o AAAHサーバーは、MNが自宅の住所を自動構成する権限がある場合、HAに示すことができるはずです。AAAHがHAを示していない場合、MNがそのアドレスを自動構成することを許可されている場合、MNは許可されていません。
In the integrated scenario, the AAA server provides the HA information to the NAS as part of the whole AAA operation for network access.
統合されたシナリオでは、AAAサーバーは、ネットワークアクセスのためのAAA操作全体の一部としてNASにHA情報を提供します。
G6.1 The AAAH server MUST be able to communicate the Home Agent Information (IP address or FQDN) to the NAS.
G6.1 AAAHサーバーは、ホームエージェント情報（IPアドレスまたはFQDN）をNASに通信できる必要があります。
G6.2 The NAS MUST be able to notify the AAAH server if it supports the AAA extensions designed to receive the HA assignment information.
G6.2 HA割り当て情報を受信するように設計されたAAA拡張機能をサポートする場合、NASはAAAHサーバーに通知できる必要があります。
G6.3 The ASP/MSP supporting the allocation of a Home Agent MUST be able to indicate to the MSA if it can allocate a Home Agent to the MN. Therefore, the NAS MUST be able to include a suggested HA address in the ASP in the AAA-NAS interaction.
G6.3ホームエージェントの割り当てをサポートするASP/MSPは、MNにホームエージェントを割り当てることができる場合、MSAに示すことができなければなりません。したがって、NASは、AAA-NAS相互作用のASPに提案されたHAアドレスを含めることができなければなりません。
G6.4 The AAA server of the MSA MUST be able to indicate to the NAS whether the MN is authorized to use a local Home Agent (i.e., a Home Agent in the ASP/MSP).
G6.4 MSAのAAAサーバーは、MNがローカルホームエージェント（つまり、ASP/MSPのホームエージェント）を使用することを許可されているかどうかをNASに示すことができなければなりません。
G6.5 The overall AAA solution for the integrated scenario MUST support the scenario where the AAA server of the ASA/MSA used for network access authentication is different from the AAA server used for mobility service authentication and authorization.
G6.5統合シナリオの全体的なAAAソリューションは、ネットワークアクセス認証に使用されるASA/MSAのAAAサーバーがモビリティサービス認証と承認に使用されるAAAサーバーとは異なるシナリオをサポートする必要があります。
As stated in Section 5.1, the AAA-HA interface must provide mutual authentication, integrity, and replay protection. Furthermore, if security parameters (e.g., IKE pre-shared key) are transferred through this interface, confidentiality is strongly recommended to be supported. In this case, the links between the HA and the AAA server of the MSA and between the NAS and the AAA server MUST be secure.
セクション5.1で述べたように、AAA-HAインターフェイスは相互認証、完全性、およびリプレイ保護を提供する必要があります。さらに、このインターフェイスを介してセキュリティパラメーター（IKE Pre-Sharedキーなど）が転送される場合、機密性をサポートすることを強くお勧めします。この場合、MSAのHAとAAAサーバーとNASとAAAサーバー間のリンクは安全でなければなりません。
The authors would like to thank James Kempf, Alper Yegin, Vijay Devarapalli, Basavaraj Patil, Gopal Dommety, Marcelo Bagnulo, and Madjid Nakhjiri for their comments and feedback. Moreover, the authors would like to thank Hannes Tschofenig for his deep technical and editorial review of the document. Finally the authors would like to thank Kuntal Chowdhury who contributed by identifying the goals related to RFC 4285 authentication.
著者は、ジェームズ・ケンプフ、アルパー・イギン、ヴィジェイ・デヴァラパリ、バサヴァラジ・パティル、ゴパル・ドメティ、マルセロ・バグヌロ、マジッド・ナクジリのコメントとフィードバックに感謝したいと思います。さらに、著者は、文書の深い技術的および編集レビューについてHannes Tschofenigに感謝したいと思います。最後に、著者は、RFC 4285認証に関連する目標を特定して貢献したKuntal Chowdhuryに感謝したいと思います。
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[2] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
[2] Patel、A。およびG. Giaretta、「モバイルIPv6（MIPV6）のブートストラップの問題声明」、RFC 4640、2006年9月。
[3] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[3] Giaretta、G.、Kempf、J。、およびV. Devarapalli、「分割シナリオでのモバイルIPv6ブートストラップ」、RFC 5026、2007年10月。
[4] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006.
[4] Patel、A.、Leung、K.、Khalil、M.、Akhtar、H。、およびK. Chowdhury、「モバイルIPv6の認証プロトコル」、RFC 4285、2006年1月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[6] Chowdhury, K., Ed., and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", Work in Progress, April 2008.
[6] Chowdhury、K.、ed。、およびA. Yegin、「統合シナリオのMIP6-Bootstrapping」、2008年4月、進行中の作業。
[7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[7] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[8] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[8] Soliman、H.、ed。、「デュアルスタックホストとルーターのモバイルIPv6サポート」、RFC 5555、2009年6月。
Authors' Addresses
著者のアドレス
Gerardo Giaretta Qualcomm 5775 Morehouse Drive San Diego, CA 92109 USA
ジェラルドジアレッタクアルコム5775モアハウスドライブサンディエゴ、カリフォルニア92109 USA
EMail: gerardo@qualcomm.com
Ivano Guardini Telecom Italia Lab via G. Reiss Romoli, 274 TORINO 10148 Italy
Ivano Guardini Telecom Italia Lab経由のG. Reiss Romoli、274 Torino 10148 Italy
EMail: ivano.guardini@telecomitalia.it
Elena Demaria Telecom Italia Lab via G. Reiss Romoli, 274 TORINO 10148 Italy
G. Reiss Romoli経由のElena Demaria Telecom Italia Lab、274 Torino 10148 Italy
EMail: elena.demaria@telecomitalia.it
Julien Bournelle Orange Labs
Julien Bournelle Orange Labs
EMail: julien.bournelle@gmail.com
Rafa Marin Lopez University of Murcia 30071 Murcia Spain
ラファマリンロペスムルシア大学30071ムルシアスペイン
EMail: rafa@dif.um.es