Network Working Group
Request for Comments: 4004 P. Calhoun
Category: Standards Track Cisco Systems, Inc.
T. Johansson
Bytemobile Inc
C. Perkins
Nokia Research Center
T. Hiller, Ed.
P. McCann
Lucent Technologies
August 2005
Diameter Mobile IPv4 Application
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントでは、インターネットコミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めています。 このプロトコルの標準化状態とステータスについては、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document specifies a Diameter application that allows a Diameter server to authenticate, authorize and collect accounting information for Mobile IPv4 services rendered to a mobile node. Combined with the Inter-Realm capability of the base protocol, this application allows mobile nodes to receive service from foreign service providers. Diameter Accounting messages will be used by the foreign and home agents to transfer usage information to the Diameter servers.
このドキュメントでは、DiameterサーバーがモバイルノードにレンダリングされるモバイルIPv4サービスのアカウンティング情報を認証、承認、および収集できるようにするDiameterアプリケーションを指定します。 基本アプリケーションのInter-Realm機能と組み合わせることで、このアプリケーションはモバイルノードが外国のサービスプロバイダーからサービスを受けることができます。 Diameterアカウンティングメッセージは、外部およびホームエージェントによって使用情報をDiameterサーバーに転送するために使用されます。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Entities and Relationships. . . . . . . . . . . . . . . . 4
1.2. Mobility Security Associations. . . . . . . . . . . . . . 4
1.3. Handoff . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Structure of the Document . . . . . . . . . . . . . . . . 7
2. Acronyms. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Scenarios and Message Flows . . . . . . . . . . . . . . . . . . 7
3.1. Inter-Realm Mobile IPv4 . . . . . . . . . . . . . . . . . 8
3.2. Allocation of Home Agent in Foreign Network . . . . . . .13
3.3. Co-located Mobile Node. . . . . . . . . . . . . . . . . .16
3.4. Key Distribution. . . . . . . . . . . . . . . . . . . . .18
4. Diameter Protocol Considerations. . . . . . . . . . . . . . . .20
4.1. Diameter Session Management . . . . . . . . . . . . . . .20
5. Command-Code Values . . . . . . . . . . . . . . . . . . . . . .23
5.1. AA-Mobile-Node-Request. . . . . . . . . . . . . . . . . .23
5.2. AA-Mobile-Node-Answer . . . . . . . . . . . . . . . . . .25
5.3. Home-Agent-MIP-Request. . . . . . . . . . . . . . . . . .26
5.4. Home-Agent-MIP-Answer . . . . . . . . . . . . . . . . . .27
6. Result-Code AVP Values. . . . . . . . . . . . . . . . . . . . .27
6.1. Transient Failures. . . . . . . . . . . . . . . . . . . .28
6.2. Permanent Failures. . . . . . . . . . . . . . . . . . . .28
7. Mandatory AVPs. . . . . . . . . . . . . . . . . . . . . . . . .28
7.1. MIP-Reg-Request AVP . . . . . . . . . . . . . . . . . . .29
7.2. MIP-Reg-Reply AVP . . . . . . . . . . . . . . . . . . . .29
7.3. MIP-Mobile-Node-Address AVP . . . . . . . . . . . . . . .30
7.4. MIP-Home-Agent-Address AVP. . . . . . . . . . . . . . . .30
7.5. MIP-Feature-Vector AVP. . . . . . . . . . . . . . . . . .30
7.6. MIP-MN-AAA-Auth AVP . . . . . . . . . . . . . . . . . . .32
7.7. MIP-FA-Challenge AVP. . . . . . . . . . . . . . . . . . .33
7.8. MIP-Filter-Rule AVP . . . . . . . . . . . . . . . . . . .33
7.9. MIP-Candidate-Home-Agent-Host . . . . . . . . . . . . . .33
7.10. MIP-Originating-Foreign-AAA AVP . . . . . . . . . . . . .33
7.11. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . . .33
8. Key Distribution . . . . . . . . . . . . . . . . . . . . . . .34
8.1. Authorization Lifetime vs. MIP Key Lifetime. . . . . . . .34
8.2. Nonce vs. Session Key. . . . . . . . . . . . . . . . . . .35
8.3. Distributing the Mobile-Home Session Key . . . . . . . . .35
8.4. Distributing the Mobile-Foreign Session Key. . . . . . . .36
8.5. Distributing the Foreign-Home Session Key. . . . . . . . .37
9. Key Distribution AVPs . . . . . . . . . . . . . . . . . . . . .38
9.1. MIP-FA-to-MN-MSA AVP. . . . . . . . . . . . . . . . . . .39
9.2. MIP-FA-to-HA-MSA AVP. . . . . . . . . . . . . . . . . . .39
9.3. MIP-HA-to-FA-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.4. MIP-HA-to-MN-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.5. MIP-MN-to-FA-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.6. MIP-MN-to-HA-MSA AVP. . . . . . . . . . . . . . . . . . .41
9.7. MIP-Session-Key AVP . . . . . . . . . . . . . . . . . . .41
9.8. MIP-Algorithm-Type AVP. . . . . . . . . . . . . . . . . .41
9.9. MIP-Replay-Mode AVP . . . . . . . . . . . . . . . . . . .42
9.10. MIP-FA-to-MN-SPI AVP. . . . . . . . . . . . . . . . . . .42
9.11. MIP-FA-to-HA-SPI AVP. . . . . . . . . . . . . . . . . . .42
9.12. MIP-Nonce AVP. . . . . . . . . . . . . . . . . . .. . . .42
9.13. MIP-MSA-Lifetime AVP . . . . . . . . . . . . . . .. . . .42
9.14. MIP-HA-to-FA-SPI AVP . . . . . . . . . . . . . . .. . . .43
10. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . . . .43
10.1. Accounting-Input-Octets AVP . . . . . . . . . . . . . . .43
10.2. Accounting-Output-Octets AVP. . . . . . . . . . . . . . .43
10.3. Acct-Session-Time AVP . . . . . . . . . . . . . . . . . .43
10.4. Accounting-Input-Packets AVP. . . . . . . . . . . . . . .43
10.5. Accounting-Output-Packets AVP . . . . . . . . . . . . . .43
10.6. Event-Timestamp AVP . . . . . . . . . . . . . . . . . . .44
11. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . .44
11.1. Mobile IP Command AVP Table . . . . . . . . . . . . . . .44
11.2. Accounting AVP Table. . . . . . . . . . . . . . . . . . .46
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .46
12.1. Command Codes . . . . . . . . . . . . . . . . . . . . . .46
12.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . .46
12.3. Result-Code AVP Values. . . . . . . . . . . . . . . . . .46
12.4. MIP-Feature-Vector AVP Values . . . . . . . . . . . . . .47
12.5. MIP-Algorithm-Type AVP Values . . . . . . . . . . . . . .47
12.6. MIP-Replay-Mode AVP Values. . . . . . . . . . . . . . . .47
12.7. Application Identifier . . . . . . . . . . . . . . . . .47
13. Security Considerations . . . . . . . . . . . . . . . . . . . .47
14. References. . . . . . . . . . . . . . . . . . . . . . . . . . .49
14.1. Normative References. . . . . . . . . . . . . . . . . . .49
14.2. Informative References. . . . . . . . . . . . . . . . . .50
15. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .51
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . .51
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . .53
Mobile IPv4 [MOBILEIP] allows a Mobile Node (MN) to change its point of attachment to the Internet while maintaining its fixed home address. Packets directed to the home address are intercepted by a Home Agent (HA), encapsulated in a tunnel, and forwarded to the MN at its current point of attachment. Optionally, a Foreign Agent (FA) may be deployed at this point of attachment, which can serve as the tunnel endpoint and may also provide access control for the visited network link. In this role, the FA has to authenticate each MN that may attach to it, whether the MN is from the same or a different administrative domain. The FA has to verify that the MN is authorized to attach and use resources in the foreign domain. Also, the FA must provide information to the home administrative domain about the resources used by the MN while it is attached in the foreign domain.
モバイルIPv4 [MOBILEIP]を使用すると、モバイルノード（MN）は、固定ホームアドレスを維持しながら、インターネットへの接続ポイントを変更できます。 ホームアドレス宛のパケットは、ホームエージェント（HA）によってインターセプトされ、トンネルにカプセル化され、現在の接続点でMNに転送されます。 オプションで、この接続点に外部エージェント（FA）を展開できます。これはトンネルエンドポイントとして機能し、訪問先ネットワークリンクのアクセス制御も提供します。 この役割では、MNが同じまたは異なる管理ドメインからのものであるかどうかに関係なく、FAはそれに接続する各MNを認証する必要があります。 FAは、MNが外部ドメインのリソースを接続および使用する権限を持っていることを確認する必要があります。 また、FAは、MNが外部ドメインに接続されている間に使用されるリソースに関する情報をホーム管理ドメインに提供する必要があります。
The Authentication, Authorization, and Accounting (AAA) requirements for Mobile IPv4 are described in detail in other documents [MIPREQ, CDMA2000]. This document specifies a Diameter application to meet these requirements. This application is not applicable to the Mobile IPv6 protocol.
モバイルIPv4の認証、承認、およびアカウンティング（AAA）要件は、他のドキュメント[MIPREQ、CDMA2000]で詳細に説明されています。 このドキュメントでは、これらの要件を満たすDiameterアプリケーションを指定します。 このアプリケーションは、モバイルIPv6プロトコルには適用されません。
Message formats (e.g., as in section 5.1) are specified as lists of Attribute-Value Pairs (AVPs) using the syntax as described in RFC 2234 [ABNF]. This includes the use of the "*" symbol to denote zero or more occurrences of an AVP.
RFC 2234 [ABNF]に記述されている構文を使用して、メッセージ形式（たとえば、セクション5.1のように）は、属性値ペア（AVP）のリストとして指定されます。 これには、AVPのゼロ個以上の出現を示す「*」記号の使用が含まれます。
Conventions Used in This Document
このドキュメントで使用される規則
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 [KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は RFC 2119 [KEYWORDS]で説明されているように解釈されます。
The Diameter Mobile IPv4 Application supports the HA and FA in providing Mobile IPv4 service to MNs. Both the HA and FA act as Diameter clients. The MNs interact with the HA and FA by using only Mobile IPv4 and therefore do not implement Diameter.
DiameterモバイルIPv4アプリケーションは、モバイルIPv4サービスをMNに提供する際にHAおよびFAをサポートします。 HAとFAの両方がDiameterクライアントとして機能します。 MNは、モバイルIPv4のみを使用してHAおよびFAと対話するため、Diameterを実装しません。
The FA, when present, is always assumed to exist in the visited administrative domain. The HA may be statically or dynamically allocated to the MN in the home administrative domain or may be dynamically allocated to the MN in a visited administrative domain. The home domain contains a home AAA server (AAAH), and the visited domain contains a foreign AAA server (AAAF). When the MN is "at home" (present on its home network), the AAAH and AAAF may be the same.
FAは、存在する場合、常に訪問先の管理ドメインに存在すると想定されます。 HAは、ホーム管理ドメイン内のMNに静的または動的に割り当てられるか、訪問先管理ドメイン内のMNに動的に割り当てられます。 ホームドメインにはホームAAAサーバー（AAAH）が含まれ、訪問先ドメインには外部AAAサーバー（AAAF）が含まれます。 MNが「ホーム」にある場合（ホームネットワーク上に存在する場合）、AAAHとAAAFは同じである可能性があります。
The base Mobile IPv4 protocol [MOBILEIP] assumes the existence of a Mobility Security Association (MSA) between the MN and HA (MN-HA MSA). The MN-HA MSA is used to authenticate, by using a keyed hash-style algorithm, the Mobile IP Registration Request that is sent from the MN to the HA. It is important to authenticate Registration Requests, as they inform the HA about the MN's current Care-of-Address, which is the destination for tunneled packets from the home network. Without authentication, malicious attackers would be able to redirect packets to anywhere on the Internet. The MSA comprises an agreement on a Security Parameters Index (SPI, a 32-bit number) that will be used to refer to the MSA, an algorithm that will be used to compute keyed hashes over messages, and a shared secret key. To enable authentication of a message, the sender appends a Mobile IP Authentication Extension that contains the SPI and the result of running the keyed hash over the entire previous contents of the message. The recipient checks the Authentication Extension by looking up the MSA based on the SPI, re-computing the keyed hash, and verifying that the result is equal to the contents of the received Authentication Extension.
ベースモバイルIPv4プロトコル[MOBILEIP]は、MNとHA（MN-HA MSA）間にMobility Security Association（MSA）が存在することを前提としています。 MN-HA MSAは、キー付きハッシュスタイルアルゴリズムを使用して、MNからHAに送信されるモバイルIP登録要求を認証するために使用されます。登録要求を認証することが重要です。これは、ホームネットワークからのトンネルパケットの宛先であるMNの現在の気付アドレスについてHAに通知するためです。認証がなければ、悪意のある攻撃者はパケットをインターネット上のどこにでもリダイレクトできます。 MSAは、MSAの参照に使用されるセキュリティパラメータインデックス（SPI、32ビット数）、メッセージのキー付きハッシュの計算に使用されるアルゴリズム、および共有秘密キーに関する合意で構成されます。メッセージの認証を有効にするために、送信者はSPIを含むモバイルIP認証拡張機能と、メッセージの以前のコンテンツ全体に対してキー付きハッシュを実行した結果を追加します。受信者は、SPIに基づいてMSAを検索し、キー付きハッシュを再計算し、結果が受信した認証拡張機能の内容と等しいことを確認することにより、認証拡張機能をチェックします。
The base Mobile IPv4 protocol also supports an optional MSA between the MN and FA (MN-FA MSA). If available, the MN-FA MSA is used by the FA to authenticate each Registration Request passing through it on the way to the HA. Although not critical to the operation of the base protocol, the MN-FA MSA is useful when the FA has to know the authenticity of a Registration Request; e.g., when it will be generating accounting records for a session. The MN-FA MSA may also be useful in future work related to handoff optimization.
ベースモバイルIPv4プロトコルは、MNとFA間のオプションのMSA（MN-FA MSA）もサポートします。 利用可能な場合、MN-FA MSAはFAによって使用され、HAに向かう途中で通過する各登録要求を認証します。 基本プロトコルの動作にとって重要ではありませんが、MN-FA MSAは、FAが登録要求の信頼性を知る必要がある場合に役立ちます。 たとえば、セッションのアカウンティングレコードを生成するとき。 MN-FA MSAは、ハンドオフの最適化に関連する今後の作業でも役立つ可能性があります。
Similarly, Mobile IPv4 supports an optional MSA between the FA and HA (FA-HA MSA). The FA-HA MSA is useful for authenticating messages between the FA and HA, such as when the HA seeks to inform the FA that it has revoked a Mobile IP registration.
同様に、モバイルIPv4は、FAとHAの間のオプションのMSA（FA-HA MSA）をサポートします。 FA-HA MSAは、HAがモバイルIP登録を取り消したことをFAに通知しようとする場合など、FAとHA間のメッセージの認証に役立ちます。
Note that configuration of MSAs that involve FAs is substantially more difficult than configuring the one between the MN and HA, because the MN and HA are often in the same administrative domain and the MN will retain the same HA for long periods of time. In contrast, the MN is likely to encounter many FAs over time and may often find itself in foreign administrative domains.
MNとHAは同じ管理ドメインにあることが多く、MNは同じHAを長期間保持するため、FAを含むMSAの構成は、MNとHAの間の構成よりもかなり難しいことに注意してください。 対照的に、MNは時間の経過とともに多くのFAに遭遇する可能性が高く、多くの場合、外部の管理ドメインで自分自身を見つけることがあります。
The base Mobile IPv4 protocol assumes that MNs are identified by their static home IP addresses and that all MSAs are statically preconfigured. The Diameter Mobile IPv4 application, together with extensions [MIPNAI, MIPCHAL, MIPKEYS, AAANAI] to the base Mobile IPv4 protocol, allows an MN to be dynamically assigned a home address and/or home agent when it attaches to the Internet. This set of specifications also supports the dynamic configuration of the MN-HA, MN-FA, and FA-HA MSAs. The dynamic configuration of these relationships is important to support deployments in which the MN can attach to a visited network without having a pre-established relationship with it.
ベースモバイルIPv4プロトコルは、MNが静的ホームIPアドレスによって識別され、すべてのMSAが静的に事前構成されていることを前提としています。 DiameterモバイルIPv4アプリケーションは、ベースモバイルIPv4プロトコルへの拡張機能[MIPNAI、MIPCHAL、MIPKEYS、AAANAI]と共に、MNがインターネットに接続するときにホームアドレスやホームエージェントを動的に割り当てることができます。 この仕様のセットは、MN-HA、MN-FA、およびFA-HA MSAの動的構成もサポートしています。 これらの関係の動的構成は、MNが事前に確立された関係を持たずに訪問先ネットワークに接続できる展開をサポートするために重要です。
Initially, the MN is assumed to have a long-term AAA security association only with the AAAH. This security association is indexed by the MN's NAI, and, like the MSAs, comprises an agreement on a SPI, an algorithm, and a shared secret key. The MN enters a visited network and requests service from some FA by sending a Mobile IPv4 Registration Request. The FA contacts an AAAF in its own administrative domain to authenticate and authorize the request for service. The AAAF and AAAH may establish a Diameter session directly with each other, such as via a Diameter Redirect, or may pass messages via a network of Diameter proxies. Where the AAAF and AAAH route messages to each other through proxies, rather than a direct connection, transitive trust is assumed. MNs can include their Network Access Identifier (NAI) in a Mobile IPv4 Registration Request [MIPNAI], which serves in place of the home address to identify the MN. The NAI is used to route Diameter messages toward the correct
最初に、MNはAAAHとのみ長期AAAセキュリティアソシエーションを持つと想定されます。 このセキュリティアソシエーションは、MNのNAIによってインデックス化され、MSAと同様に、SPI、アルゴリズム、および共有秘密キーに関する合意を構成します。 MNは訪問先のネットワークに入り、モバイルIPv4登録要求を送信することにより、FAにサービスを要求します。 FAは、自身の管理ドメイン内のAAAFに連絡して、サービスの要求を認証および承認します。 AAAFとAAAHは、Diameter Redirectなどを介して互いに直接Diameterセッションを確立するか、Diameterプロキシのネットワークを介してメッセージを渡すことができます。 AAAFとAAAHが直接接続ではなくプロキシを介してメッセージを相互にルーティングする場合、推移的な信頼が想定されます。 MNは、ホームアドレスの代わりにMNを識別するモバイルIPv4登録要求[MIPNAI]にネットワークアクセス識別子（NAI）を含めることができます。 NAIは、Diameterメッセージを正しい方向にルーティングするために使用されます
AAAH. This use of the NAI is consistent with the roaming model defined by the ROAMOPS Working Group [EVALROAM, RFC2607].
AAAH。 このNAIの使用は、ROAMOPSワーキンググループ[EVALROAM、RFC2607]で定義されているローミングモデルと一致しています。
The AAAH can authenticate the Registration Request with the use of the MN-AAA security association [MIPCHAL]. If authentication is successful, the AAAH then generates and distributes MSAs to the MN, HA, and FA. For each of the MSA pairs that involve the MN (i.e., MN-HA/HA-MN MSAs and MN-FA/FA-MN MSAs), the AAAH generates a nonce and then hashes it together with the MN-AAA shared key to derive the session key for the MSA pair. The nonces are sent to the HA that includes them in the Registration Reply, which enables the MN to derive the same keys [MIPKEYS]. At the same time, the AAAH must distribute the MN-HA/HA-MN MSAs and the FA-HA/HA-FA MSAs to the HA and must distribute the MN-FA/FA-MN MSAs and the FA-HA/HA-FA MSAs to the FA. These are sent in Diameter AVPs and must be independently secured by using IPSec or TLS between the AAAH and the FA and between the AAAH and the HA. See section 8 for more information on key derivation and distribution.
AAAHは、MN-AAAセキュリティアソシエーション[MIPCHAL]を使用して登録要求を認証できます。 認証が成功すると、AAAHはMSAを生成し、MN、HA、およびFAに配布します。 MNに関係するMSAペア（MN-HA / HA-MN MSAおよびMN-FA / FA-MN MSA）ごとに、AAAHはnonceを生成し、MN-AAA共有キーと一緒にハッシュします。 MSAペアのセッションキーを導出します。 ナンスは、登録応答にそれらを含むHAに送信されます。これにより、MNは同じキー[MIPKEYS]を導出できます。 同時に、AAAHはMN-HA / HA-MN MSAとFA-HA / HA-FA MSAをHAに配布し、MN-FA / FA-MN MSAとFA-HA / HAを配布する必要があります -FAへのFA MSA。 これらはDiameter AVPで送信され、AAAHとFAの間およびAAAHとHAの間でIPSecまたはTLSを使用して個別に保護する必要があります。 キーの導出と配布の詳細については、セクション8を参照してください。
Note that MSAs in Mobile IP are unidirectional in that, for example, the MN-HA MSA (used to protect traffic from the MN to the HA) and the HA-MN MSA (used to protect traffic from the HA to the MN) can use different SPIs, algorithms, and shared secrets. This is true of the base Mobile IP protocol despite common existing practice during manual configuration of MSAs in which all parameters are set to the same value in both directions. This document supports the use of different SPIs in each direction; however, it only supports the distribution of a single session key for each pair of MSAs between two nodes. The security implications of this are discussed in section 13. This document sometimes names only one of the two unidirectional MSAs when referring to the distribution of the single shared secret and the pair of SPIs for the pair of MSAs between two entities.
モバイルIPのMSAは単方向であることに注意してください。たとえば、MN-HA MSA（MNからHAへのトラフィックを保護するために使用）とHA-MN MSA（HAからMNへのトラフィックを保護するために使用）は 異なるSPI、アルゴリズム、および共有シークレットを使用します。 これは、すべてのパラメーターが両方向で同じ値に設定されるMSAの手動構成中の一般的な既存の慣行にもかかわらず、基本モバイルIPプロトコルに当てはまります。 このドキュメントは、各方向で異なるSPIの使用をサポートしています。 ただし、2つのノード間のMSAのペアごとに1つのセッションキーの配布のみをサポートします。 このセキュリティへの影響については、セクション13で説明します。このドキュメントでは、2つのエンティティ間のMSAペアの単一共有シークレットとSPIのペアの配布について言及する場合、2つの単方向MSAの1つのみを指定することがあります。
In addition to supporting the derivation and transport of the MN-HA, MN-FA, and FA-HA MSAs, this application also supports MIPv4 handoff. When an MN moves from one point of attachment to another, the MN can continue the same Mobile IPv4 session by using its existing HA and home address.
MN-HA、MN-FA、およびFA-HA MSAの派生とトランスポートをサポートすることに加えて、このアプリケーションはMIPv4ハンドオフもサポートします。 MNが1つの接続点から別の接続点に移動すると、MNは既存のHAとホームアドレスを使用して同じモバイルIPv4セッションを継続できます。
The MN accomplishes this by sending a Mobile IPv4 Registration Request from its new point of attachment. To enable a single set of accounting records to be maintained for the entire session, including handoffs, it is necessary to allow the AAAH to bind the new registration to the pre-existing session. To enable the Mobile IPv4 Registration Request to be routed to the same AAAH, the MN SHOULD include the AAAH NAI [AAANAI] in such re-registrations. Also, to assist the AAAH in routing the messages to the MN's existing HA the mobile node SHOULD include the HA NAI [AAANAI] in such re-registrations. If the mobile node does not support the Mobile IPv4 AAA NAI extension [AAANAI], this functionality is not available.
MNは、新しい接続点からモバイルIPv4登録要求を送信することでこれを実現します。 ハンドオフを含むセッション全体でアカウンティングレコードの単一セットを維持できるようにするには、AAAHが新しいセッションを既存のセッションにバインドできるようにする必要があります。 モバイルIPv4登録要求を同じAAAHにルーティングできるようにするには、MNはそのような再登録にAAAH NAI [AAANAI]を含める必要があります。 また、AAAHがMNの既存のHAにメッセージをルーティングするのを支援するために、モバイルノードはそのような再登録にHA NAI [AAANAI]を含める必要があります。 モバイルノードがモバイルIPv4 AAA NAI拡張[AAANAI]をサポートしていない場合、この機能は利用できません。
The remainder of this document is structured as follows. Section 2 provides acronym definitions. Section 3 provides some examples and message flows illustrating both the Mobile IPv4 and Diameter messages that occur when a mobile node attaches to the Internet. Section 4 defines the relationship of this application to the Diameter Base Protocol. Section 5 defines the new command codes. Section 6 defines the new result codes used by this application. Section 7 defines the set of mandatory Attribute-Value-Pairs (AVPs). Section 8 gives an overview of the key distribution capability, and Section 9 defines the key distribution AVPs. Section 10 defines the accounting AVPs, and section 11 contains a listing of all AVPs and their occurrence in Diameter commands. Finally, sections 12 and 13 give IANA and security considerations, respectively.
このドキュメントの残りの部分は次のように構成されています。 セクション2では、頭字語の定義を示します。 セクション3は、モバイルノードがインターネットに接続するときに発生するモバイルIPv4とDiameterメッセージの両方を示すいくつかの例とメッセージフローを提供します。 セクション4は、Diameter Base Protocolとこのアプリケーションの関係を定義します。 セクション5では、新しいコマンドコードを定義します。 セクション6では、このアプリケーションで使用される新しい結果コードを定義しています。 セクション7は、必須のAttribute-Value-Pairs（AVP）のセットを定義します。 セクション8ではキー配布機能の概要を示し、セクション9ではキー配布AVPを定義します。 セクション10はアカウンティングAVPを定義し、セクション11には、DiameterコマンドでのすべてのAVPとその出現のリストが含まれています。 最後に、セクション12と13では、それぞれIANAとセキュリティに関する考慮事項を示します。
AAAH Authentication, Authorization, and Accounting Home AAAF Authentication, Authorization, and Accounting Foreign AMA AA-Mobile-Node-Answer AMR AA-Mobile-Node-Request ASR Abort-Session-Request AVP Attribute Value Pair CoA Care-of-Address FA Foreign Agent FQDN Fully Qualified Domain Name HA Home Agent HAA Home-Agent-MIP-Answer HAR Home-Agent-MIP-Request MN Mobile Node MSA Mobility Security Association NAI Network Access Identifier RRQ Registration Request SPI Security Parameters Index STR Session-Termination-Request
AAAH認証、許可、およびアカウンティングホームAAAF認証、許可、およびアカウンティング外部AMA AA-モバイルノード応答AMR AAモバイルノード要求ASR Abortセッション要求AVP属性値ペアCoA気付アドレスFA外部 Agent FQDN完全修飾ドメイン名HA Home Agent HAA Home-Agent-MIP-Answer HAR Home-Agent-MIP-Request MN Mobile Node MSA Mobility Security Association NAI Network Access Identifier RRQ Registration Request SPI Security Parameters Index STR Session-Termination-Request
This section presents four scenarios illustrating Diameter Mobile IPv4 application and describes the operation of key distribution.
このセクションでは、Diameter Mobile IPv4アプリケーションを示す4つのシナリオを示し、キー配布の操作について説明します。
In this document, the role of the "attendant" [MIPREQ] is performed by either the FA (when it is present in a visited network) or the HA (for co-located mobile nodes not registering via an FA), and these terms will be used interchangeably in the following scenarios.
このドキュメントでは、「アテンダント」[MIPREQ]の役割は、FA（訪問先ネットワークに存在する場合）またはHA（FA経由で登録されていない共存モバイルノード）のいずれかによって実行されます。 次のシナリオで同じ意味で使用されます。
When a mobile node requests service by issuing a Registration Request to the foreign agent, the foreign agent creates the AA-Mobile-Node-Request (AMR) message, which includes the AVPs defined in section 7. The Home Address, Home Agent, Mobile Node NAI, and other important fields are extracted from the registration messages for possible inclusion as Diameter AVPs. The AMR message is then forwarded to the local Diameter server, known as the AAA-Foreign, or AAAF.
モバイルノードが外部エージェントに登録要求を発行してサービスを要求すると、外部エージェントは、セクション7で定義されたAVPを含むAA-Mobile-Node-Request（AMR）メッセージを作成します。ホームアドレス、ホームエージェント、モバイル ノードNAIおよびその他の重要なフィールドは、Diameter AVPとして含めるために登録メッセージから抽出されます。 次に、AMRメッセージは、AAA-ForeignまたはAAAFとして知られるローカルDiameterサーバーに転送されます。
Visited Realm Home Realm
+-----------+ +-----------+
|example.net| AMR/AMA |example.org|
| AAAF |<------------------->| AAAH |
+->| server | server-server | server |
| +-----------+ communication +-----------+
| ^ ^
| AMR/AMA | client-server | HAR/HAA
| | communication |
v v v
+---------+ +---------+ +---------+
| Foreign | | Foreign | | Home |
| Agent | | Agent | | Agent |
+---------+ +---------+ +---------+
^
| Mobile IP
|
v
+--------+
| Mobile |
| Node | mn@example.org
+--------+
Figure 1. Inter-realm Mobility
図1.レルム間モビリティ
Upon receiving the AMR, the AAAF follows the procedures outlined in [DIAMBASE] to determine whether the AMR should be processed locally or forwarded to another Diameter server known as the AAA-Home, or AAAH. Figure 1 shows an example in which a mobile node (mn@example.org) requests service from a foreign provider (example.net). The request received by the AAAF is forwarded to example.org's AAAH server.
AMRを受信すると、AAAFは[DIAMBASE]で概説されている手順に従って、AMRをローカルで処理するか、AAA-HomeまたはAAAHとして知られる別のDiameterサーバーに転送するかを決定します。 図1は、モバイルノード（mn@example.org）が外部プロバイダー（example.net）にサービスを要求する例を示しています。 AAAFが受信したリクエストは、example.orgのAAAHサーバーに転送されます。
Figure 2 shows the message flows involved when the foreign agent invokes the AAA infrastructure to request that a mobile node be authenticated and authorized. Note that it is not required that the foreign agent invoke AAA services every time a Registration Request is received from the mobile, but rather only when the prior authorization from the AAAH expires. The expiration time of the authorization is communicated through the Authorization-Lifetime AVP in the AA-Mobile-Node-Answer (AMA; see section 5.2) from the AAAH.
図2は、外部エージェントがAAAインフラストラクチャを呼び出して、モバイルノードの認証と承認を要求する場合に関係するメッセージフローを示しています。 外部エージェントは、モバイルから登録要求を受信するたびにAAAサービスを呼び出す必要はなく、AAAHからの事前承認が期限切れになった場合にのみ必要であることに注意してください。 認可の有効期限は、AAAAからAA-Mobile-Node-Answer（AMA;セクション5.2を参照）のAuthorization-Lifetime AVPを介して通知されます。
Mobile Node Foreign Agent AAAF AAAH Home
Agent
----------- ------------- ------------ ---------- -------
Advertisement &
<--------- Challenge
Reg-Req&MN-AAA ---->
AMR------------>
Session-Id = foo
AMR------------>
Session-Id = foo
HAR----------->
Session-Id = bar
<----------HAA
Session-Id = bar
Session-Id = bar
<-----------AMA
Session-Id = foo
<------------AMA
Session-Id = foo
<-------Reg-Reply
Figure 2. Mobile IPv4/Diameter Message Exchange
図2.モバイルIPv4 /直径メッセージ交換
The foreign agent (as shown in Figure 2) MAY provide a challenge, which would give it direct control over the replay protection in the Mobile IPv4 registration process, as described in [MIPCHAL]. The mobile node includes the Challenge and MN-AAA authentication extension to enable authorization by the AAAH. If the authentication data supplied in the MN-AAA extension is invalid, the AAAH returns the response (AMA) with the Result-Code AVP set to DIAMETER_AUTHENTICATION_REJECTED.
（図2に示すように）外部エージェントは、[MIPCHAL]で説明されているように、モバイルIPv4登録プロセスでリプレイ保護を直接制御できるチャレンジを提供する場合があります。 モバイルノードには、チャレンジとMN-AAA認証拡張機能が含まれており、AAAHによる許可を有効にします。 MN-AAA拡張で提供された認証データが無効である場合、AAAAHは、結果コードAVPをDIAMETER_AUTHENTICATION_REJECTEDに設定した応答（AMA）を返します。
The above scenario causes the MN-FA and MN-HA keys to be exposed to Diameter agents all along the Diameter route. If this is a concern, a more secure approach is to eliminate the AAAF and other Diameter agents, as shown in Figure 3.
上記のシナリオにより、MN-FAキーとMN-HAキーはDiameterルート全体でDiameterエージェントに公開されます。 これが懸念される場合は、図3に示すように、AAAFおよび他のDiameterエージェントを削除するのがより安全なアプローチです。
Redirect FA AAAF Agent AAAH
FA AAAFエージェントAAAHのリダイレクト
AMR
---------------->
AMR
---------------->
AMA (Redirect)
<----------------
AMA (Redirect)
<----------------
Setup Security Association
<-------------------------------------------------->
AMR
AMR
-------------------------------------------------->
AMA (MN-FA key)
<---------------------------------------------------
Figure 3. Use of a Redirect Server with AMR/AMA
図3. AMR / AMAでのリダイレクトサーバーの使用
In Figure 3, the FA sets up a TLS [TLS] or IPSec [IPSEC]-based security association with the AAAH directly and runs the AMR/AMA exchange over it. This provides end-to-end security for secret keys that may have to be distributed.
図3では、FAはAAAHと直接TLS [TLS]またはIPSec [IPSEC]ベースのセキュリティアソシエーションをセットアップし、AMR / AMA交換を実行します。 これにより、配布が必要な秘密鍵のエンドツーエンドのセキュリティが提供されます。
Figure 4 shows the interaction between the AAAH and HA with the help of a redirect agent. When the AAAH and HA are in the same network, it is likely that the AAAH knows the IP address of the HA, so the redirect server would therefore not be needed; however, it is shown anyway for completeness. The redirect server will most likely be used in the case where the HA is allocated in a foreign network (see section 3.2 for more details of HA allocation in foreign networks).
図4は、リダイレクトエージェントを使用したAAAHとHAの相互作用を示しています。 AAAHとHAが同じネットワークにある場合、AAAHはHAのIPアドレスを知っている可能性が高いため、リダイレクトサーバーは必要ありません。 ただし、完全を期すためにとにかく示しています。 リダイレクトサーバーは、HAが外部ネットワークに割り当てられている場合に使用される可能性が最も高くなります（外部ネットワークでのHA割り当ての詳細については、セクション3.2を参照してください）。
Redirect
HA Agent AAAH
HAR
<--------------------
HAA (Redirect)
-------------------->
Setup Security Association
<---------------------------------------->
HAR (MN-HA key)
<-----------------------------------------
HAA
----------------------------------------->
Figure 4. Use of a Redirect Server with HAR/HAA
図4. HAR / HAAでのリダイレクトサーバーの使用
As in Figure 2, the FA of Figure 3 would still provide the challenge and the mobile sends the RRQ, etc.; however, these steps were eliminated from Figure 3 to reduce clutter. The redirect server eliminates the AAAF and any other Diameter agents from seeing the keys as they are transported to the FA and HA. Note that the message flows in Figures 3 and 4 apply only to the initial authentication and key exchange. Accounting messages would still be sent via Diameter agents, not via the direct connection, unless network policies dictate otherwise.
図2のように、図3のFAは引き続きチャレンジを提供し、モバイルはRRQなどを送信します。 ただし、これらの手順は、混乱を減らすために図3から削除されました。 リダイレクトサーバーは、AAAFおよび他のDiameterエージェントが、FAおよびHAに転送されるときにキーを見ることを排除します。 図3および4のメッセージフローは、初期認証とキー交換にのみ適用されることに注意してください。 ネットワークポリシーで別途指示されない限り、アカウンティングメッセージは、直接接続ではなく、Diameterエージェントを介して送信されます。
A mobile node that supports the AAA NAI extension [AAANAI], which has been previously authenticated and authorized, MUST always include the assigned home agent in the HA Identity subtype of the AAA NAI extension, and the authorizing Home AAA server in the AAAH Identity subtype of the AAA NAI extension, when re-authenticating. Therefore, in the event that the AMR generated by the FA is for a session that was previously authorized, it MUST include the Destination-Host AVP, with the identity of the AAAH found in the AAAH-NAI, and the MIP-Home-Agent-Host AVP with the identity and realm of the assigned HA found in the HA-NAI. If, on the other hand, the mobile node does not support the AAA NAI extension, the FA may not have the identity of the AAAH and the identity and realm of the assigned HA. This means that without support of the AAA NAI extension, the FA may not be able to guarantee that the AMR will be destined to the same AAAH, which previously authenticated and authorized the mobile node, as the FA may not know the identity of the AAAH.
以前に認証および許可されたAAA NAI拡張[AAANAI]をサポートするモバイルノードは、AAA NAI拡張のHA Identityサブタイプに割り当てられたホームエージェント、およびAAAH Identityサブタイプに許可ホームAAAサーバーを常に含めなければなりません。再認証時のAAA NAI拡張の。したがって、FAによって生成されたAMRが以前に承認されたセッション用である場合、AAAH-NAIで見つかったAAAHのIDを持つDestination-Host AVPとMIP-Home-Agentを含める必要があります。 -HA-NAIで見つかった割り当てられたHAのIDとレルムを持つホストAVP。一方、モバイルノードがAAA NAI拡張をサポートしていない場合、FAはAAAHのIDと、割り当てられたHAのIDと領域を持たない場合があります。これは、AAA NAI拡張のサポートがないと、FAはAMRが以前にモバイルノードを認証および許可した同じAAAHに宛てられることを保証できない可能性があることを意味します。 。
If the mobile node was successfully authenticated, the AAAH then determines which Home Agent to use for the session. First, the AAAH checks whether an HA has been requested by the MN by checking the MIP-Home-Agent-Address AVP and the MIP-Home-Agent-Host AVP. The administrative domain owning the HA may be determined from the realm portion of the MIP-Home-Agent-Host AVP, or by checking the
モバイルノードが正常に認証された場合、AAAHはセッションに使用するHome Agentを決定します。 最初に、AAAHは、MIP-Home-Agent-Address AVPおよびMIP-Home-Agent-Host AVPを確認することで、MNによってHAが要求されたかどうかを確認します。 HAを所有する管理ドメインは、MIP-Home-Agent-Host AVPの領域部分から、または
Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP and the value of the MIP-Originating-Foreign-AAA AVP. If the requested HA belongs to a permitted administrative domain, the AAAH SHOULD use the given HA for the session. Otherwise, the AAAH returns the response (AMA) with the Result-Code AVP set to either DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE or DIAMETER_ERROR_HA_NOT_AVAILABLE.
MIP-Feature-Vector AVPのHome-Agent-In-Foreign-NetworkフラグおよびMIP-Originating-Foreign-AAA AVPの値。 要求されたHAが許可された管理ドメインに属している場合、AAAHは指定されたHAをセッションに使用する必要があります。 それ以外の場合、AAAAHは、結果コードAVPをDIAMETER_ERROR_NO_FOREIGN_HA_SERVICEまたはDIAMETER_ERROR_HA_NOT_AVAILABLEに設定して応答（AMA）を返します。
If the MN has not requested any particular HA, then an HA MUST be dynamically allocated. In this case the MIP-Feature-Vector will have the Home-Agent-Requested flag set. If the Home-Address-Allocatable-Only-in-Home-Realm flag is not set, and if the Foreign-Home-Agent-Available flag is set, then the AAAH SHOULD allow the foreign realm to allocate the HA (see section 3.2) but MAY allocate one itself in the home realm if dictated by local policy. If the Home-Address-Allocatable-Only-in-Home-Realm flag is set, then the AAAH MUST allocate an HA in the home realm on behalf of the MN. Allocation of the HA can be done in a variety of ways, including by using a load-balancing algorithm to keep the load on all home agents equal. The actual algorithm used and the method of discovering the home agents are outside the scope of this specification.
MNが特定のHAを要求していない場合、HAを動的に割り当てる必要があります。 この場合、MIP-Feature-VectorにはHome-Agent-Requestedフラグが設定されます。 Home-Address-Allocatable-Only-in-Home-Realmフラグが設定されておらず、Foreign-Home-Agent-Availableフラグが設定されている場合、AAAHは外部レルムによるHAの割り当てを許可する必要があります（セクション3.2を参照） ）しかし、ローカルポリシーによって指示された場合、ホームレルムに自分自身を割り当てることができます。 Home-Address-Allocatable-Only-in-Home-Realmフラグが設定されている場合、AAAHはMNに代わってHAをホーム領域に割り当てる必要があります。 HAの割り当ては、ロードバランシングアルゴリズムを使用してすべてのホームエージェントの負荷を均等に保つなど、さまざまな方法で実行できます。 使用される実際のアルゴリズムおよびホームエージェントを検出する方法は、この仕様の範囲外です。
The AAAH then sends a Home-Agent-MIP-Request (HAR), which contains the Mobile IPv4 Registration Request message data encapsulated in the MIP-Reg-Request AVP, to the assigned or requested Home Agent. Refer to Figure 4 if the AAAH does not have a direct path to the HA. The AAAH MAY allocate a home address for the mobile node, and the Home Agent MUST support home address allocation. In the event that the AAAH handles address allocation, it includes the home address in a MIP-Mobile-Node-Address AVP within the HAR. The absence of this AVP informs the Home Agent that it must perform the home address allocation.
次にAAAHは、MIP-Reg-Request AVPにカプセル化されたモバイルIPv4登録要求メッセージデータを含むHome-Agent-MIP-Request（HAR）を、割り当てられた、または要求されたHome Agentに送信します。 AAAHにHAへの直接パスがない場合は、図4を参照してください。 AAAHはモバイルノードにホームアドレスを割り当てることができます。また、ホームエージェントはホームアドレスの割り当てをサポートする必要があります。 AAAHがアドレス割り当てを処理する場合、HAR内のMIP-Mobile-Node-Address AVPにホームアドレスが含まれます。 このAVPの不在は、ホームアドレスの割り当てを実行する必要があることをHAに通知します。
Upon receipt of the HAR, the home agent first processes the Diameter message. The home agent processes the MIP-Reg-Request AVP and creates the Registration Reply, encapsulating it within the MIP-Reg-Reply AVP. In the creation of the Registration Reply, the Home Agent MUST include the HA NAI and the AAAH NAI, which will be created from the Origin-Host AVP and Origin-Realm AVP of the HAR. If a home address is needed, the home agent MUST also assign one and include the address in both the Registration Reply and the MIP-Mobile-Node-Address AVP.
HARを受信すると、ホームエージェントは最初にDiameterメッセージを処理します。 ホームエージェントはMIP-Reg-Request AVPを処理し、Registration Replyを作成し、MIP-Reg-Reply AVP内にカプセル化します。 登録応答の作成では、ホームエージェントはHA NAIおよびAAAH NAIを含める必要があります。これらは、HARのOrigin-Host AVPおよびOrigin-Realm AVPから作成されます。 ホームアドレスが必要な場合、ホームエージェントも1つを割り当て、登録応答とMIPモバイルノードアドレスAVPの両方にアドレスを含める必要があります。
Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer (AMA) message, which includes the same Acct-Multi-Session-Id contained in the HAA and the MIP-Home-Agent-Address and MIP-Mobile-
HAAを受信すると、AAAHはAA-Mobile-Node-Answer（AMA）メッセージを作成します。これには、HAAに含まれる同じAcct-Multi-Session-IdとMIP-Home-Agent-AddressおよびMIP-Mobileが含まれます。 -
Node-Address AVPs in the AMA message. See Figures 3 and 4 for the use of the redirect agent for the secure transport of the HAA and AMA messages.
AMAメッセージ内のノードアドレスAVP。 HAAおよびAMAメッセージの安全な転送のためのリダイレクトエージェントの使用については、図3および4を参照してください。
See section 4.1 for information on the management of sessions and session identifiers by the Diameter Mobile IPv4 entities.
DiameterモバイルIPv4エンティティによるセッションおよびセッション識別子の管理については、セクション4.1を参照してください。
The Diameter Mobile IPv4 application allows a home agent to be allocated in a foreign network, as required in [MIPREQ, CDMA2000]. When a foreign agent detects that the mobile node has a home agent address equal to 0.0.0.0 or 255.255.255.255 in the Registration Request message, it MUST add a MIP-Feature-Vector AVP with the Home-Agent-Requested flag set to one. If the home agent address is set to 255.255.255.255, the foreign agent MUST set the Home-Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home agent address is set to 0.0.0.0, the foreign agent MUST set the Home-Address-Allocatable-Only-in-Home-Realm flag equal to zero.
Diameter Mobile IPv4アプリケーションでは、[MIPREQ、CDMA2000]で要求されているように、ホームネットワークを外部ネットワークに割り当てることができます。 外部ノードは、登録要求メッセージでモバイルノードのホームエージェントアドレスが0.0.0.0または255.255.255.255であることを検出すると、Home-Agent-Requestedフラグが1に設定されたMIP-Feature-Vector AVPを追加する必要があります。 。 ホームエージェントのアドレスが255.255.255.255に設定されている場合、外部エージェントはHome-Address-Allocatable-Only-in-Home-Realmフラグを1に設定する必要があります。 ホームエージェントアドレスが0.0.0.0に設定されている場合、外部エージェントは、Home-Address-Allocatable-Only-in-Home-Realmフラグをゼロに設定する必要があります。
When the AAAF receives an AMR message with the Home-Agent-Requested flag set to one and with the Home-Address-Allocatable-Only-in-Home-Realm flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in order to inform the AAAH that it is willing and able to assign a Home Agent for the mobile node. When doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home-Agent-Host AVP contains the identity (i.e., a DiameterIdentity, which is an FQDN) of the home agent that would be assigned to the mobile node, and the MIP-Originating-Foreign-AAA AVP contains the identity of the AAAF. The AAAF now sends the AMR to the AAAH. However, as discussed above, the use of Diameter agents between the FA and AAAH would expose the MN-FA key. If this is deemed undesirable, a redirect server approach SHOULD be utilized to communicate the AMR to the AAAH. This causes the FA to communicate the AMR directly to the AAAH via a security association.
AAAFがHome-Agent-Requestedフラグを1に設定し、Home-Address-Allocatable-Only-in-Home-Realmフラグを0に設定したAMRメッセージを受信すると、AAAFはForeign-Home-Agent- MIP-Feature-Vector AVPで使用可能なフラグは、モバイルノードにHome Agentを割り当てる意思があり、AAAHに割り当てることができることをAAAHに通知します。そうするとき、AAAFはMIP-Candidate-Home-Agent-Host AVPとMIP-Originating-Foreign-AAA-AVPを含まなければなりません。 MIP-Candidate-Home-Agent-Host AVPにはモバイルノードに割り当てられるホームエージェントのID（FQDNであるDiameterIdentity）が含まれ、MIP-Originating-Foreign-AAA AVPにはAAAFのアイデンティティ。 AAAFはAMRをAAAHに送信します。ただし、上記で説明したように、FAとAAAHの間でDiameterエージェントを使用すると、MN-FAキーが公開されます。これが望ましくないと見なされる場合、リダイレクトサーバーアプローチを利用してAMRをAAAHに通信する必要があります。これにより、FAはセキュリティアソシエーションを介してAMRをAAAHに直接通信します。
If the mobile node with AAA NAI extension support [AAANAI] has been previously authorized by the AAAH, now has to be re-authenticated, and requests to keep the assigned home agent in the foreign network, the mobile node MUST include the HA NAI and the AAAH NAI in the registration request to the FA. Upon receipt, the FA will create the AMR, including the MIP-Home-Agent-Address AVP and the Destination-Host AVP based on the AAAH NAI, and include the MIP-Home-Agent-Host AVP based on the home agent NAI. If the AAAF authorizes the use of the requested home agent, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP.
AAA NAI拡張サポート[AAANAI]を備えたモバイルノードが以前にAAAHによって承認され、現在は再認証が必要であり、割り当てられたホームエージェントを外部ネットワークに保持する要求がある場合、モバイルノードはHA NAIと FAへの登録要求のAAAH NAI。 受信すると、FAはAAAH NAIに基づくMIP-Home-Agent-Address AVPとDestination-Host AVPを含むAMRを作成し、ホームエージェントNAIに基づくMIP-Home-Agent-Host AVPを含めます。 AAAFが要求されたホームエージェントの使用を許可する場合、AAAFはMIP-Feature-Vector AVPのHome-Agent-In-Foreign-Networkビットを設定する必要があります。
If the mobile node has to be re-authenticated but does not support the AAA NAI extension, it sends a registration request without the AAA NAI and the HA NAI, even though it has previously been authorized by the AAAH and requests to keep the assigned home agent in the foreign network. Upon receipt, the FA will create the AMR, including the MIP-Home-Agent-Address AVP. If the AAAF authorizes the use of the requested home agent, and if it knows that the agent is in its own domain, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP.
モバイルノードを再認証する必要があるが、AAA NAI拡張をサポートしていない場合、以前にAAAHによって許可され、割り当てられたホームを維持するように要求している場合でも、AAA NAIおよびHA NAIなしで登録要求を送信します 外部ネットワークのエージェント。 受信すると、FAはMIP-Home-Agent-Address AVPを含むAMRを作成します。 AAAFが要求されたホームエージェントの使用を許可し、エージェントがそれ自身のドメインにあることを知っている場合、AAAFはMIP-Feature-Vector AVPのHome-Agent-In-Foreign-Networkビットを設定しなければなりません。
When the AAAH receives an AMR message, it first checks the authentication data supplied by the mobile node, according to the MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether to authorize the mobile node. If the AMR indicates that the AAAF has offered to allocate a Home Agent for the mobile node (i.e., the Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP), or if the AMR indicates that the AAAF has offered a previously allocated Home Agent for the mobile node (i.e., the Home-Agent-In-Foreign-Network is set in the MIP-Feature-Vector AVP), then the AAAH must decide whether its local policy would allow the user to have or keep a home agent in the foreign network. Assuming that the mobile node is permitted to do so, the AAAH determines the IP address of the HA based upon the FQDN of the HA by using DNS or learns it via an MIP-Home-Agent-Address AVP in a redirect response to an HAR (i.e., if the redirect server adds this AVP to the HAA). Then it sends an HAR message to Home Agent by including the Destination-Host AVP set to the value found in the AMR's MIP-Candidate-Home-Agent-Host AVP or MIP-Home-Agent-Host AVP. If DNS is used to determine the HA IP address, it is assumed that the HA has a public address and that it can be resolved by DNS.
AAAHはAMRメッセージを受信すると、最初にMIP-Reg-Request AVPおよびMIP-MN-AAA-Auth AVPに従ってモバイルノードから提供された認証データをチェックし、モバイルノードを認証するかどうかを決定します。 AMRがモバイルノードにホームエージェントを割り当てることを提案したことを示す場合（つまり、Foreign-Home-AvailableがMIP-Feature-Vector AVPに設定されている場合）、またはAMRがAAAFが持っていることを示す場合モバイルノードに以前に割り当てられたホームエージェントを提供した（つまり、Home-Agent-In-Foreign-NetworkがMIP-Feature-Vector AVPに設定されている）場合、AAAHはそのローカルポリシーでユーザーがまたは、外部ネットワークにホームエージェントを保持します。モバイルノードが許可されていると仮定すると、AAAHはDNSを使用してHAのFQDNに基づいてHAのIPアドレスを決定するか、HARへのリダイレクト応答でMIP-Home-Agent-Address AVPを介してそれを学習します（つまり、リダイレクトサーバーがこのAVPをHAAに追加する場合）。次に、AMRのMIP-Candidate-Home-Agent-Host AVPまたはMIP-Home-Agent-Host AVPで見つかった値に設定されたDestination-Host AVPを含めることにより、HARメッセージをHAに送信します。 DNSを使用してHA IPアドレスを決定する場合、HAにはパブリックアドレスがあり、DNSによって解決できると想定されます。
Security considerations may require that the HAR be sent directly from the AAAH to the HA without the use of intermediary Diameter agents. This requires that a security association between the AAAH and HA be established, as in Figure 4. If no security association can be established, the AAAH MUST return an AMA with the Result-Code AVP set to DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION.
セキュリティを考慮すると、中間のDiameterエージェントを使用せずに、HARをAAAHからHAに直接送信する必要がある場合があります。 これには、図4のように、AAAHとHAの間にセキュリティアソシエーションを確立する必要があります。セキュリティアソシエーションを確立できない場合、AAAHは、結果コードAVPをDIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTIONに設定してAMAを返さなければなりません。
If Diameter agents are being used (e.g., if there is no redirect server) the AAAH sends the HAR to the originating AAAF. In this HAR the Destination-Host AVP is set to the value found in the AMR's MIP-Originating-Foreign-AAA AVP, and the MIP-Home-Agent-Host AVP or the MIP-Candidate-Home-Agent-Host AVP found in the AMR is copied into the HAR.
Diameterエージェントが使用されている場合（リダイレクトサーバーがない場合など）、AAAHはHARを発信元AAAFに送信します。 このHARでは、Destination-Host AVPはAMRのMIP-Originating-Foreign-AAA AVPで見つかった値に設定され、MIP-Home-Agent-Host AVPまたはMIP-Candidate-Home-Agent-Host AVPは AMRはHARにコピーされます。
Therefore, the AAAH MUST always copy the MIP-Originating-Foreign-AAA AVP from the AMR message to the HAR message. In cases when another AAAF receives the HAR, this new AAAF will send the HAR to the HA.
したがって、AAAHは常にMIP-Originating-Foreign-AAA AVPをAMRメッセージからHARメッセージにコピーする必要があります。 別のAAAFがHARを受信した場合、この新しいAAAFはHARをHAに送信します。
Visited Home
Realm Realm
+--------+ ------- AMR -------> +--------+
| AAAF | <------ HAR -------- | AAAH |
| | | |
+--->| server | ------- HAA -------> | server |
| +--------+ <------ AMA -------- +--------+
| ^ |
| | |
HAR/HAA | AMR | | AMA
v | v
+---------+ +---------+
| Home | | Foreign |
| Agent | | Agent |
+---------+ +---------+
^
+--------+ |
| Mobile |<----------+
| Node | Mobile IP
+--------+
Figure 5. Home Agent Allocated in Visited Realm
図5.訪問済みレルムに割り当てられたホームエージェント
Upon receipt of an HAA from the Home Agent in the visited realm, the AAAF forwards the HAA to the AAAH in the home realm. The AMA is then constructed and issued to the AAAF and, finally, to the FA. If the Result-Code indicates success, the HAA and AMA MUST include the MIP-Home-Agent-Address and the MIP-Mobile-Node-Address AVPs.
訪問したレルムのHAからHAAを受信すると、AAAFはHAAをホームレルムのAAAHに転送します。 その後、AMAが作成され、AAAFに発行され、最後にFAに発行されます。 結果コードが成功を示す場合、HAAとAMAはMIP-Home-Agent-AddressとMIP-Mobile-Node-Address AVPを含まなければなりません。
If exposing keys to the Diameter Agents along the way represents an unacceptable security risk, then the redirect approach depicted in Figures 3 and 4 MUST be used instead.
途中でDiameter Agentにキーを公開することが許容できないセキュリティリスクを表す場合、代わりに図3および4に示すリダイレクトアプローチを使用する必要があります。
Mobile Node Foreign Agent Home Agent AAAF AAAH
----------- ------------- ------------- ---------- ----------
<---Challenge----
Reg-Req (Response)->
-------------AMR----------->
------AMR---->
<-----HAR-----
<-----HAR------
------HAA----->
------HAA---->
<-----AMA-----
<------------AMA------------
<---Reg-Reply----
Figure 6. MIP/Diameter Exchange for HA Is Allocated in
Visited Realm
If the mobile node moves to another foreign Network, it MAY either request to keep the same Home Agent within the old foreign network or request to get a new one in the new foreign network. If the AAAH is willing to provide the requested service, the AAAH will have to provide services for both visited networks; e.g., key refresh.
モバイルノードが別の外部ネットワークに移動した場合、古い外部ネットワーク内に同じホームエージェントを保持するように要求するか、新しい外部ネットワークで新しいホームエージェントを取得するように要求できます。 AAAHが要求されたサービスを提供する意思がある場合、AAAHは両方の訪問先ネットワークにサービスを提供する必要があります。 例：キーの更新。
If a mobile node registers with the Home Agent as a co-located mobile node, no foreign agent is involved. Therefore, when the Home Agent receives the Registration Request, an AMR message is sent to the local AAAH server, with the Co-Located-Mobile-Node bit set in the MIP-Feature-Vector AVP. The Home Agent also includes the Acct-Multi-Session-Id AVP (see sections 4.1.1 and 4.1.2) in the AMR sent to the AAAH, as the AAAH may find this piece of session-state or log entry information useful.
モバイルノードがホームエージェントに同じ場所にあるモバイルノードとして登録されている場合、外部エージェントは関与しません。 したがって、ホームエージェントが登録要求を受信すると、AMRメッセージがローカルAAAHサーバーに送信され、MIP-Feature-Vector AVPでCo-Located-Mobile-Nodeビットが設定されます。 また、ホームエージェントは、AAAHがこのセッション状態またはログエントリ情報の一部を有用と判断する可能性があるため、AAAHに送信されるAMRにAcct-Multi-Session-Id AVP（セクション4.1.1および4.1.2を参照）を含めます。
Home
Realm
+--------+
| AAAH |
| |
| server |
+--------+
^ |
| |
AMR | | AMA
| v
+--------+ +---------+
| Mobile | Registration | Home |
| Node |-------------->| Agent |
+--------+ Request +---------+
Figure 7. Co-located Mobile Node
図7.共存するモバイルノード
If the MN-HA-Key-Requested bit was set in the AMR message from the Home Agent, the home agent and mobile node's session keys would be present in the AMA message.
ホームエージェントからのAMRメッセージでMN-HA-Key-Requestedビットが設定されている場合、ホームエージェントとモバイルノードのセッションキーがAMAメッセージに存在します。
Figure 8 shows a signaling diagram that indicates a secure way to set up the necessary security associations when using redirect servers. The Proxy AAA represents any AAA server or servers that the HA may use. This applies to the visited or home network.
図8は、リダイレクトサーバーを使用するときに必要なセキュリティアソシエーションをセットアップする安全な方法を示すシグナリング図を示しています。 プロキシAAAは、HAが使用するAAAサーバーを表します。 これは、訪問先ネットワークまたはホームネットワークに適用されます。
Local redirect
HA Proxy AAA Agent AAAH
AMR
--------------->
AMR (Redirect)
-------------------->
AMA (Redirect)
<---------------------
AMA (Redirect)
<----------------
Setup Security Association
<------------------------------------------------------>
AMR
------------------------------------------------------->
AMA (MN-HA key)
<-------------------------------------------------------
Figure 8. Use of Redirect Server for Co-located CoA and AMR/AMA
図8. Co-located CoAおよびAMR / AMAでのリダイレクトサーバーの使用
To allow the scaling of wireless data access across administrative domains, it is necessary to minimize the number of pre-existing Mobility Security Associations (MSAs) required. This means that each Foreign Agent should not be required to have a pre-configured MSA with each Home Agent on the Internet, nor should the mobile node be required to have a pre-configured MSA (as defined in [MOBILEIP]) with any specific foreign agent. Furthermore, when the mobile node requests a dynamically allocated home agent, it is likely to receive the address of a home agent for which it has no available mobility security association.
管理ドメイン全体でワイヤレスデータアクセスのスケーリングを可能にするには、必要な既存のMobility Security Association（MSA）の数を最小限に抑える必要があります。 つまり、各外部エージェントは、インターネット上の各ホームエージェントで事前構成されたMSAを持つ必要はなく、モバイルノードは、特定の特定の事前構成されたMSA（[MOBILEIP] 外国代理店。 さらに、モバイルノードが動的に割り当てられたホームエージェントを要求すると、利用可能なモビリティセキュリティアソシエーションを持たないホームエージェントのアドレスを受信する可能性があります。
The Diameter Mobile IPv4 application solves this by including key distribution functionality, which means that after a Mobile Node is authenticated the authorization phase includes the generation of session keys and nonces. Specifically, three session keys and two nonces are generated:
DiameterモバイルIPv4アプリケーションは、キー配布機能を含めることでこれを解決します。つまり、モバイルノードが認証された後、承認フェーズにセッションキーとノンスの生成が含まれることを意味します。 具体的には、3つのセッションキーと2つのノンスが生成されます。
- K1: The MN-HA Session Key, which will be part of the MSA between the Mobile Node and the Home Agent. The MN-HA Session Key is derived from a nonce generated by AAA. The mobile node obtains that nonce in the Registration Reply and generates this key using the same formula that AAA uses.
-K1：モバイルノードとホームエージェント間のMSAの一部となるMN-HAセッションキー。 MN-HAセッションキーは、AAAによって生成されたナンスから取得されます。 モバイルノードは、登録応答でそのナンスを取得し、AAAが使用するのと同じ式を使用してこのキーを生成します。
- K2: The MN-FA Key, which will be part of the MSA between the Mobile Node and the Foreign Agent. The MN-FA Key is derived from a nonce generated by AAA. The mobile node obtains that nonce in the Registration Reply and generates the MN-FA key using the same formula that AAA uses.
-K2：MN-FAキー。モバイルノードと外部エージェント間のMSAの一部になります。 MN-FAキーは、AAAによって生成されたナンスから派生します。 モバイルノードは、Registration Replyでそのnonceを取得し、AAAが使用するのと同じ式を使用してMN-FAキーを生成します。
- K3: The FA-HA Key, which will be part of the MSA between the Foreign Agent and the Home Agent.
-K3：外部エージェントとホームエージェント間のMSAの一部となるFA-HAキー。
The same session key is used in both directions between two entities; e.g., the Mobile Node and the Foreign Agent use the same session key for the MN-FA and the FA-MN authentication extensions. The security implications of this are examined in section 13. However, the SPIs may be different for the MN-FA and the FA-MN authentication extensions. The SPI for the MN-FA MSA is used on messages sent from the MN to the FA, and the SPI for the FA-MN MSA is used on messages sent from the FA to the MN.
2つのエンティティ間の双方向で同じセッションキーが使用されます。 たとえば、モバイルノードと外部エージェントは、MN-FAおよびFA-MN認証拡張に同じセッションキーを使用します。 これのセキュリティへの影響については、セクション13で検討します。ただし、MN-FAおよびFA-MN認証拡張ではSPIが異なる場合があります。 MN-FA MSAのSPIは、MNからFAに送信されるメッセージで使用され、FA-MN MSAのSPIは、FAからMNに送信されるメッセージで使用されます。
All keys and nonces are generated by the AAAH, even if a Home Agent is dynamically allocated in the foreign network.
Home Agentが外部ネットワークに動的に割り当てられている場合でも、すべてのキーとナンスはAAAHによって生成されます。
Figure 9 depicts the MSAs used for Mobile-IPv4 message integrity using the keys created by the DIAMETER server.
図9は、DIAMETERサーバーによって作成されたキーを使用したMobile-IPv4メッセージ整合性に使用されるMSAを示しています。
+--------+ +--------+
|Foreign | K3 | Home |
|Agent |<-------------------->| Agent |
| | | |
+--------+ +--------+
^ ^
| K2 K1 |
| +--------+ |
| | Mobile | |
+------>| Node |<------+
| |
+--------+
Figure 9. Mobility Security Associations after Session Key and Nonce Distribution
図9.セッションキーとノンス配布後のモビリティセキュリティアソシエーション
The keys destined for the foreign and home agent are propagated to the mobility agents via the Diameter protocol. If exposing keys to the Diameter Agents along the way represents an unacceptable security risk, then the keys MUST be protected either by IPSec or TLS security associations that exist directly between the HA and AAAH or the FA and AAAF, as explained above.
外部およびホームエージェント宛てのキーは、Diameterプロトコルを介してモビリティエージェントに伝播されます。 途中でキーをDiameter Agentに公開することが許容できないセキュリティリスクを表す場合、上記で説明したように、HAとAAAHまたはFAとAAAFの間に直接存在するIPSecまたはTLSセキュリティアソシエーションによってキーを保護する必要があります。
The keys destined for the mobile node MUST also be propagated via the Mobile IPv4 protocol and therefore MUST follow the mechanisms described in [MIPKEYS] instead. In [MIPKEYS], the mobile node receives a nonce for each key it needs, and the mobile node will use the nonce and the long-term shared secret to create the keys (see section 8).
モバイルノード宛のキーもモバイルIPv4プロトコル経由で伝播する必要があるため、[MIPKEYS]で説明されているメカニズムに従う必要があります。 [MIPKEYS]で、モバイルノードは必要な各キーのナンスを受信し、モバイルノードはナンスと長期共有シークレットを使用してキーを作成します（セクション8を参照）。
Once the session keys have been established and propagated, the mobility devices can exchange registration information directly, as defined in [MOBILEIP], without the need of the Diameter infrastructure. However, the session keys have a lifetime, after which the Diameter infrastructure MUST be invoked again if new session keys and nonces are to be acquired.
セッションキーが確立され伝播されると、モビリティデバイスは、[MOBILEIP]で定義されているように、Diameterインフラストラクチャを必要とせずに、登録情報を直接交換できます。 ただし、セッションキーには有効期間があり、新しいセッションキーとナンスを取得する場合は、Diameterインフラストラクチャを再度呼び出す必要があります。
This section details the relationship of the Diameter Mobile IPv4 application to the Diameter base protocol.
このセクションでは、Diameterベースプロトコルに対するDiameter Mobile IPv4アプリケーションの関係について詳しく説明します。
This document specifies Diameter Application-ID 2. Diameter nodes conforming to this specification MAY advertise support by including the value of two (2) in the Auth-Application-Id or the Acct-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands [DIAMBASE]. The value of two (2) MUST be used as the Application-Id in all AMR/AMA and HAR/HAA commands. The value of two (2) MUST be used as the Application-Id in all ACR/ACA commands, as this application defines new, mandatory AVPs for accounting. The value of zero (0) SHOULD be used as the Application-Id in all STR/STA and ASR/ASA commands, as these are defined in the Diameter base protocol and no additional mandatory AVPs for those commands are defined in this document.
このドキュメントは、Diameter Application-ID 2を指定します。この仕様に準拠するDiameterノードは、Capabilities-Exchange-RequestのAuth-Application-IdまたはAcct-Application-Id AVPに2の値を含めることによってサポートをアドバタイズできます。 Capabilities-Exchange-Answerコマンド[DIAMBASE]。 2の値は、すべてのAMR / AMAおよびHAR / HAAコマンドでApplication-Idとして使用する必要があります。 このアプリケーションはアカウンティングのための新しい必須のAVPを定義するため、すべてのACR / ACAコマンドでApplication-Idとして2の値を使用する必要があります。 ゼロ（0）の値は、すべてのSTR / STAおよびASR / ASAコマンドでApplication-Idとして使用する必要があります。これらはDiameterベースプロトコルで定義されており、これらのコマンドの追加の必須AVPはこのドキュメントでは定義されていません。
Given the nature of Mobile IPv4, re-authentication can only be initiated by a mobile node, which does not participate in the Diameter message exchanges. Therefore, Diameter server initiated re-auth does not apply to this application, and RAR/RAA commands MUST NOT be sent for Diameter Mobile IPv4 sessions.
モバイルIPv4の性質を考えると、再認証は、Diameterメッセージ交換に参加しないモバイルノードによってのみ開始できます。 したがって、Diameterサーバーが開始した再認証はこのアプリケーションには適用されず、Ria / RAAコマンドをDiameterモバイルIPv4セッションに送信してはなりません。
The AAAH and AAAF MAY maintain session-state or MAY be session-stateless. AAA redirect agents and AAA relay agents MUST NOT maintain session-state. The AAAH, AAAF, proxies and relays agents MUST maintain transaction state.
AAAHおよびAAAFは、セッション状態を維持するか、セッション状態を持たない場合があります。 AAAリダイレクトエージェントとAAAリレーエージェントは、セッション状態を維持してはなりません。 AAAH、AAAF、プロキシ、およびリレーエージェントは、トランザクション状態を維持する必要があります。
A mobile node's session is identified via its identity in the User-Name AVP and the MIP-Mobile-Node-Address, and the MIP-Home-Agent-Address AVPs. This is necessary in order to allow the session state machine, defined in the base protocol [DIAMBASE], to be used without modification for this application. However, as the MN may interact with more than one FA during the life of its session, it is important for the Diameter Mobile IPv4 application to distinguish the two pieces of the session (some state at the FA, some state at the HA) and to manage them independently. The following sub-sections give further details.
モバイルノードのセッションは、User-Name AVP、MIP-Mobile-Node-Address、およびMIP-Home-Agent-Address AVPのIDを介して識別されます。 これは、ベースプロトコル[DIAMBASE]で定義されたセッションステートマシンを、このアプリケーションの変更なしで使用できるようにするために必要です。 ただし、MNはセッションの存続期間中に複数のFAと対話する可能性があるため、Diameter Mobile IPv4アプリケーションがセッションの2つの部分（FAでの状態、HAでの状態）を区別することが重要です。 それらを独立して管理します。 以下のサブセクションで詳細を説明します。
During creation of the AMR, the FA will choose a session identifier. During the creation of the HAR, the AAAH MUST use a different session identifier than that used in the AMR/AMA. If the AAAH is session-stateful, it MUST send the same session identifier for all HARs initiated on behalf of a given mobile node's session. Otherwise, if the AAAH is session-stateless, it will manufacture a unique session-id for every HAR.
AMRの作成中に、FAはセッションIDを選択します。 HARの作成中、AAAHはAMR / AMAで使用されるものとは異なるセッション識別子を使用する必要があります。 AAAHがセッションステートフルの場合、特定のモバイルノードのセッションのために開始されたすべてのHARに対して同じセッション識別子を送信する必要があります。 それ以外の場合、AAAHがセッションステートレスの場合、すべてのHARに対して一意のセッションIDを製造します。
When the HA is first allocated, it MUST create and include an Acct-Multi-Session-Id AVP in the HAA returned to the AAAH. This identifier will be kept constant for the life of the Mobile IPv4 session, as detailed in the next subsection.
HAが最初に割り当てられるとき、AAAHに返されるHAAにAcct-Multi-Session-Id AVPを作成して含める必要があります。 次のサブセクションで詳しく説明するように、この識別子はモバイルIPv4セッションの存続期間中一定に保たれます。
Given the nature of Mobile IPv4, a mobile node MAY receive service from many foreign agents during a period of time. However, the home realm should not view these handoffs as different sessions, as this could affect billing systems. Furthermore, foreign agents usually do not communicate between each other, which implies that AAA information cannot be exchanged between these entities.
モバイルIPv4の性質を考えると、モバイルノードは、一定期間中に多くの外部エージェントからサービスを受けることができます。 ただし、ホームレルムはこれらのハンドオフを異なるセッションと見なすべきではありません。これは課金システムに影響を与える可能性があるためです。 さらに、外部エージェントは通常、相互に通信しません。これは、これらのエンティティ間でAAA情報を交換できないことを意味します。
A handoff registration request from a mobile node will cause the FA to send an AMR to its AAAF. The AMR will include a new session identifier and MAY be sent to a new AAAF (i.e., a AAAF different from that used by the previous FA). However, the AMR shall be received by the AAAH to which the user is currently registered (possibly via the redirect mechanism depicted in Figure 3).
モバイルノードからのハンドオフ登録要求により、FAはAMRをAAAFに送信します。 AMRには新しいセッションIDが含まれ、新しいAAAF（つまり、以前のFAで使用されたものとは異なるAAAF）に送信される場合があります。 ただし、AMRは、ユーザーが現在登録されているAAAHによって受信されます（図3に示されているリダイレクトメカニズムを介して）。
As the AAAH may be session-stateless, it is necessary for the resulting HAR received by the HA to be identified as a continuation of an existing session. If the HA receives an HAR for a mobile node with a new session identifier and the HA can guarantee that this request is to extend an existing service, then the HA MUST be able to modify its internal session state information to reflect the new session identifier.
AAAHはセッションステートレスである可能性があるため、HAが受信した結果のHARは、既存のセッションの継続として識別される必要があります。 HAが新しいセッション識別子を持つモバイルノードのHARを受信し、この要求が既存のサービスを拡張することをHAが保証できる場合、HAは新しいセッション識別子を反映するために内部セッション状態情報を変更できる必要があります。
For correlation to occur, accounting records must have some commonality across handoffs. Therefore, the home agent MUST send the same Acct-Multi-Session-Id AVP value in all HAAs for the mobile's session. That is, the HA generates a unique Acct-Multi-Session-Id when receiving an HAR for a new session and returns this same value in every HAA for the session. This Acct-Multi-Session-Id AVP will be returned to the foreign agent by the AAAH in the AMA. Both the foreign and home agents MUST include the Acct-Multi-Session-Id in the accounting messages, as depicted in Figure 10.
相関関係が発生するためには、アカウンティングレコードにハンドオフ全体で何らかの共通性が必要です。 したがって、ホームエージェントは、モバイルのセッションのすべてのHAAで同じAcct-Multi-Session-Id AVP値を送信する必要があります。 つまり、HAは、新しいセッションのHARを受信すると一意のAcct-Multi-Session-Idを生成し、セッションのすべてのHAAでこの同じ値を返します。 このAcct-Multi-Session-Id AVPは、AMAのAAAHによって外部エージェントに返されます。 図10に示すように、外部エージェントとホームエージェントの両方がアカウンティングメッセージにAcct-Multi-Session-Idを含める必要があります。
A foreign and home agent following this specification MAY expect their respective Diameter servers to maintain session state information for each mobile node in their networks. For a Diameter Server to release any resources allocated to a specific mobile node, that server has to receive a Session-Termination-Request (STR) from a mobility agent. The mobility agents MUST issue the Session-Termination-Request (STR) if the Authorization Lifetime has expired and no subsequent MIP registration request has been received.
この仕様に従う外部およびホームエージェントは、それぞれのDiameterサーバーがネットワーク内の各モバイルノードのセッション状態情報を維持することを期待する場合があります。 Diameterサーバーが特定のモバイルノードに割り当てられたリソースを解放するには、そのサーバーはモビリティエージェントからセッション終了要求（STR）を受信する必要があります。 Authorization Lifetimeが期限切れになり、その後のMIP登録要求が受信されなかった場合、モビリティエージェントはSession-Termination-Request（STR）を発行する必要があります。
The AAAH SHOULD only deallocate all resources after the STR is received from the home agent. This ensures that a mobile node that moves from one foreign agent to another (for example, as a result of a handover) does not cause the Home Diameter Server to free all resources for the mobile node. Therefore, an STR from a foreign agent would free the session from the foreign agent, but not the session state associated with the home agent (see Figure 10).
AAAHは、STRがホームエージェントから受信された後にのみ、すべてのリソースの割り当てを解除する必要があります。 これにより、1つの外部エージェントから別のエージェントに移動するモバイルノード（たとえば、ハンドオーバーの結果）によって、ホームDiameterサーバーがモバイルノードのすべてのリソースを解放することがなくなります。 したがって、外部エージェントからのSTRはセッションを外部エージェントから解放しますが、ホームエージェントに関連付けられたセッション状態は解放しません（図10を参照）。
STR, Session-Id = foo STR, Session-Id = bar
---------------------> <--------------------
+----+ +------+ +------+ +----+
| FA | | AAAF | | AAAH | | HA |
+----+ +------+ +------+ +----+
<--------------------- --------------------->
STA, Session-Id = foo STA, Session-Id = bar
Figure 10. Session Termination and Session Identifiers
図10.セッション終了とセッション識別子
When deallocating all of the mobile node's resources, the home Diameter server (and the foreign Diameter server in the case of an HA allocated in foreign network) MUST destroy all session keys that may still be valid.
モバイルノードのすべてのリソースの割り当てを解除するとき、ホームDiameterサーバー（および外部ネットワークに割り当てられたHAの場合は外部Diameterサーバー）は、まだ有効な可能性があるすべてのセッションキーを破棄しなければなりません。
In the event that the AAAF wishes to terminate a session, its Abort-Session-Request (ASR) [DIAMBASE] message SHOULD be sent to the FA. Similarly, the AAAH SHOULD send its message to the Home Agent.
AAAFがセッションを終了したい場合、そのAbort-Session-Request（ASR）[DIAMBASE]メッセージをFAに送信する必要があります。 同様に、AAAHはそのメッセージをHAに送信する必要があります。
This section defines Command-Code [DIAMBASE] values that MUST be supported by all Diameter implementations conforming to this specification. The following Command Codes are defined in this specification:
このセクションでは、この仕様に準拠するすべてのDiameter実装でサポートする必要があるコマンドコード[DIAMBASE]値を定義します。 この仕様では、次のコマンドコードが定義されています。
Command-Name Abbreviation Code Section
-----------------------------------------------------------
AA-Mobile-Node-Request AMR 260 5.1
AA-Mobile-Node-Answer AMA 260 5.2
Home-Agent-MIP-Request HAR 262 5.3
Home-Agent-MIP-Answer HAA 262 5.4
The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field set to 260 and the 'R' bit set in the Command Flags field, is sent by an attendant (i.e., the Foreign Agent), acting as a Diameter client, to an AAAF in order to request the authentication and authorization of a mobile node. The foreign agent (or home agent in the case of a co-located Mobile Node) uses information found in the Registration Request to construct the following AVPs, to be included as part of the AMR:
260に設定されたCommand-CodeフィールドとCommand Flagsフィールドに設定された「R」ビットによって示されるAA-Mobile-Node-Request（AMR）は、アテンダント（つまり、外部エージェント）によって送信され、 Diameterノード。モバイルノードの認証と承認を要求するためのAAAFへ。 外部エージェント（または同じ場所にあるモバイルノードの場合はホームエージェント）は、Registration Requestで見つかった情報を使用して、AMRの一部として含まれる次のAVPを構築します。
Home Address (MIP-Mobile-Node-Address AVP)
Home Agent Address (MIP-Home-Agent-Address AVP)
Mobile Node NAI (User-Name AVP [DIAMBASE])
MN-HA Key Request (MIP-Feature-Vector AVP)
MN-FA Key Request (MIP-Feature-Vector AVP)
MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP)
Foreign Agent Challenge Extension (MIP-FA-Challenge AVP)
Home Agent NAI (MIP-Home-Agent-Host AVP)
Home AAA server NAI (Destination-Host AVP [DIAMBASE])
Home Agent to Foreign Agent SPI (MIP-HA-to-FA-SPI AVP)
If the mobile node's home address is zero, the foreign or home agent MUST NOT include a MIP-Mobile-Node-Address AVP in the AMR. If the home agent address is zero or all ones, the MIP-Home-Agent-Address AVP MUST NOT be present in the AMR.
モバイルノードのホームアドレスがゼロの場合、外部またはホームエージェントは、AMRにMIP-Mobile-Node-Address AVPを含めることはできません。 ホームエージェントアドレスがゼロまたはすべて1である場合、AMRにMIP-Home-Agent-Address AVPが存在してはなりません。
If a home agent is used in a visited network, the AAAF MAY set the Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in the AMR message to indicate that it is willing to assign a Home Agent in the visited realm.
ホームエージェントが訪問先ネットワークで使用されている場合、AAAFは、AMRメッセージのMIP-Feature-Vector AVPにForeign-Home-Agent-Availableフラグを設定して、訪問先にホームエージェントを割り当てる意思があることを示すことができます。 レルム。
If the mobile node's home address is all ones, the foreign or home agent MUST include a MIP-Mobile-Node-Address AVP, set to all ones.
モバイルノードのホームアドレスがすべて1である場合、外部またはホームエージェントには、すべて1に設定されたMIP-Mobile-Node-Address AVPを含める必要があります。
If the mobile node includes the home agent NAI and the home AAA server NAI [AAANAI], the foreign agent MUST include the MIP-Home-Agent-Host AVP and the Destination-Host AVP in the AMR.
モバイルノードがホームエージェントNAIとホームAAAサーバーNAI [AAANAI]を含む場合、外部エージェントはAMRにMIP-Home-Agent-Host AVPとDestination-Host AVPを含まなければなりません。
Message Format
メッセージフォーマット
<AA-Mobile-Node-Request> ::= < Diameter Header: 260, REQ, PXY >
< Session-ID >
{ Auth-Application-Id }
{ User-Name }
{ Destination-Realm }
{ Origin-Host }
{ Origin-Realm }
{ MIP-Reg-Request }
{ MIP-MN-AAA-Auth }
[ Acct-Multi-Session-Id ]
[ Destination-Host ]
[ Origin-State-Id ]
[ MIP-Mobile-Node-Address ]
[ MIP-Home-Agent-Address ]
[ MIP-Feature-Vector ]
[ MIP-Originating-Foreign-AAA ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ MIP-FA-Challenge ]
[ MIP-Candidate-Home-Agent-Host ]
[ MIP-Home-Agent-Host ]
[ MIP-HA-to-FA-SPI ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field set to 260 and the 'R' bit cleared in the Command Flags field, is sent by the AAAH in response to the AA-Mobile-Node-Request message. The User-Name MAY be included in the AMA if it is present in the AMR. The Result-Code AVP MAY contain one of the values defined in section 6, in addition to the values defined in [DIAMBASE].
260に設定されたCommand-CodeフィールドとCommand Flagsフィールドでクリアされた「R」ビットで示されるAA-Mobile-Node-Answer（AMA）は、AA-Mobile-Node- 要求メッセージ。 User-NameがAMRに存在する場合、AMAに含めることができます。 結果コードAVPは、[DIAMBASE]で定義された値に加えて、セクション6で定義された値の1つを含む場合があります。
An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST include the MIP-Home-Agent-Address AVP, MUST include the MIP-Mobile-Node-Address AVP, and includes the MIP-Reg-Reply AVP if and only if the Co-Located-Mobile-Node bit was not set in the MIP-Feature-Vector AVP. The MIP-Home-Agent-Address AVP contains the Home Agent assigned to the mobile node, while the MIP-Mobile-Node-Address AVP contains the home address that was assigned. The AMA message MUST contain the MIP-FA-to-HA-MSA and MIP-FA-to-MN-MSA if they were requested in the AMR and were present in the HAR. The MIP-MN-to-HA-MSA and MIP-HA-to-MN-MSA AVPs MUST be present if the session keys were requested in the AMR and the Co-Located-Mobile-Node bit was set in the MIP-Feature-Vector AVP.
結果コードAVPがDIAMETER_SUCCESSに設定されたAMAメッセージには、MIP-Home-Agent-Address AVPを含める必要があり、MIP-Mobile-Node-Address AVPを含める必要があり、MIP-Reg-Reply AVPが含まれるのは、 Co-Located-Mobile-NodeビットがMIP-Feature-Vector AVPで設定されていませんでした。 MIP-Home-Agent-Address AVPにはモバイルノードに割り当てられたホームエージェントが含まれ、MIP-Mobile-Node-Address AVPには割り当てられたホームアドレスが含まれます。 AMAメッセージには、AMRで要求され、HARに存在する場合、MIP-FA-to-HA-MSAおよびMIP-FA-to-MN-MSAが含まれている必要があります。 AMRでセッションキーが要求され、MIP-FeatureでCo-Located-Mobile-Nodeビットが設定された場合、MIP-MN-to-HA-MSAおよびMIP-HA-to-MN-MSA AVPが存在する必要があります -ベクターAVP。
Message Format
メッセージフォーマット
<AA-Mobile-Node-Answer> ::= < Diameter Header: 260, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Acct-Multi-Session-Id ]
[ User-Name ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Re-Auth-Request-Type ]
[ MIP-Feature-Vector ]
[ MIP-Reg-Reply ]
[ MIP-MN-to-FA-MSA ]
[ MIP-MN-to-HA-MSA ]
[ MIP-FA-to-MN-MSA ]
[ MIP-FA-to-HA-MSA ]
[ MIP-HA-to-MN-MSA ]
[ MIP-MSA-Lifetime ]
[ MIP-Home-Agent-Address ]
[ MIP-Mobile-Node-Address ]
* [ MIP-Filter-Rule ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ AVP ]
The AAA sends the Home-Agent-MIP-Request (HAR), indicated by the Command-Code field set to 262 and the 'R' bit set in the Command Flags field, to the Home Agent. If the Home Agent is to be assigned in a foreign network, the HAR is issued by the AAAH and forwarded by the AAAF to the HA if no redirect servers are involved. If any are, the HAR is sent directly to the HA via a security association. If the HAR message does not include a MIP-Mobile-Node-Address AVP, the Registration Request has 0.0.0.0 for the home address, and the HAR is successfully processed, the Home Agent MUST allocate the mobile nodes address. If, on the other hand, the home agent's local AAA server allocates the mobile node's home address, the local AAA server MUST include the assigned address in a MIP-Mobile-Node-Address AVP.
AAAは、262に設定されたCommand-CodeフィールドとCommand Flagsフィールドに設定された「R」ビットで示されるHome-Agent-MIP-Request（HAR）をHome Agentに送信します。 HAが外部ネットワークに割り当てられる場合、リダイレクトサーバーが関与しない場合、HARはAAAHによって発行され、AAAFによってHAに転送されます。 存在する場合、HARはセキュリティアソシエーションを介してHAに直接送信されます。 HARメッセージにMIP-Mobile-Node-Address AVPが含まれておらず、登録要求にホームアドレスの0.0.0.0が含まれており、HARが正常に処理された場合、ホームエージェントはモバイルノードアドレスを割り当てなければなりません。 一方、ホームエージェントのローカルAAAサーバーがモバイルノードのホームアドレスを割り当てる場合、ローカルAAAサーバーは割り当てられたアドレスをMIP-Mobile-Node-Address AVPに含める必要があります。
When session keys are requested for use by the mobile node, the AAAH MUST create them and include them in the HAR message. When a FA-HA session key is requested, it will be created and distributed by the AAAH server.
セッションキーがモバイルノードで使用するために要求されると、AAAHはそれらを作成し、HARメッセージに含める必要があります。 FA-HAセッションキーが要求されると、AAAHサーバーによって作成および配布されます。
Message Format
メッセージフォーマット
<Home-Agent-MIP-Request> ::= < Diameter Header: 262, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Authorization-Lifetime }
{ Auth-Session-State }
{ MIP-Reg-Request }
{ Origin-Host }
{ Origin-Realm }
{ User-Name }
{ Destination-Realm }
{ MIP-Feature-Vector }
[ Destination-Host ]
[ MIP-MN-to-HA-MSA ]
[ MIP-MN-to-FA-MSA ]
[ MIP-HA-to-MN-MSA ]
[ MIP-HA-to-FA-MSA ]
[ MIP-MSA-Lifetime ]
[ MIP-Originating-Foreign-AAA ]
[ MIP-Mobile-Node-Address ]
[ MIP-Home-Agent-Address ]
* [ MIP-Filter-Rule ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
In response to a Home-Agent-MIP-Request, the Home Agent sends the Home-Agent-MIP-Answer (HAA), indicated by the Command-Code field set to 262 and the 'R' bit cleared in the Command Flags field, to its local AAA server. The User-Name MAY be included in the HAA if it is present in the HAR. If the home agent allocated a home address for the mobile node, the address MUST be included in the MIP-Mobile-Node-Address AVP. The Result-Code AVP MAY contain one of the values defined in section 6 instead of the values defined in [DIAMBASE].
Home-Agent-MIP-Requestへの応答として、Home AgentはHome-Agent-MIP-Answer（HAA）を送信します。これは、262に設定されたCommand-CodeフィールドとCommand Flagsフィールドでクリアされた「R」ビットで示されます 、そのローカルAAAサーバーに。 User-NameがHARに存在する場合、HAAに含めることができます。 ホームエージェントがモバイルノードにホームアドレスを割り当てた場合、そのアドレスはMIP-Mobile-Node-Address AVPに含まれている必要があります。 結果コードAVPは[DIAMBASE]で定義された値の代わりにセクション6で定義された値の1つを含むかもしれません。
Message Format
メッセージフォーマット
<Home-Agent-MIP-Answer> ::= < Diameter Header: 262, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Acct-Multi-Session-Id ]
[ User-Name ]
[ Error-Reporting-Host ]
[ Error-Message ]
[ MIP-Reg-Reply ]
[ MIP-Home-Agent-Address ]
[ MIP-Mobile-Node-Address ]
[ MIP-FA-to-HA-SPI ]
[ MIP-FA-to-MN-SPI ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ AVP ]
This section defines new Result-Code [DIAMBASE] values that MUST be supported by all Diameter implementations that conform to this specification.
このセクションでは、この仕様に準拠するすべてのDiameter実装でサポートする必要がある新しい結果コード[DIAMBASE]値を定義します。
Errors in the transient failures category are used to inform a peer that the request could not be satisfied at the time it was received, but that it may be able to satisfy the request in the future.
一時的な障害カテゴリのエラーは、要求を受信した時点では満たせなかったが、将来的に要求を満たすことができる可能性があることをピアに通知するために使用されます。
DIAMETER_ERROR_MIP_REPLY_FAILURE 4005
This error code is used by the home agent when processing of
the Registration Request has failed.
DIAMETER_ERROR_HA_NOT_AVAILABLE 4006 This error code is used to inform the foreign agent that the requested Home Agent cannot be assigned to the mobile node at this time. The foreign agent MUST return a Mobile IPv4 Registration Reply to the mobile node with an appropriate error code.
DIAMETER_ERROR_HA_NOT_AVAILABLE 4006このエラーコードは、要求されたホームエージェントを現時点でモバイルノードに割り当てることができないことを外部エージェントに通知するために使用されます。 外部エージェントは、適切なエラーコードとともにモバイルIPv4登録応答をモバイルノードに返さなければなりません。
DIAMETER_ERROR_BAD_KEY 4007 This error code is used by the home agent to indicate to the local Diameter server that the key generated is invalid.
DIAMETER_ERROR_BAD_KEY 4007このエラーコードは、生成されたキーが無効であることをローカルDiameterサーバーに示すためにホームエージェントによって使用されます。
DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED 4008 This error code is used by a mobility agent to indicate to the home Diameter server that the requested packet filter Rules cannot be supported.
DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED 4008このエラーコードは、要求されたパケットフィルタールールをサポートできないことをホームDiameterサーバーに示すために、モビリティエージェントによって使用されます。
Errors that fall within the permanent failures category are used to inform the peer that the request failed and SHOULD NOT be attempted again.
永続的な障害のカテゴリに分類されるエラーは、要求が失敗したことをピアに通知するために使用され、再試行されるべきではありません。
DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5024
This error is used by the AAAF to inform the AAAH that
allocation of a home agent in the foreign domain is not
permitted at this time.
DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION 5025 This error is used by the AAAF/AAAH to inform the peer that the requested Mobile IPv4 session keys could not be delivered via a security association.
DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION 5025このエラーは、要求されたモバイルIPv4セッションキーをセキュリティアソシエーションを介して配信できなかったことをピアに通知するために、AAAF / AAAHによって使用されます。
The following table describes the Diameter AVPs defined in the Mobile IPv4 application; their AVP Code values, types, and possible flag values; and whether the AVP MAY be encrypted.
次の表は、モバイルIPv4アプリケーションで定義されているDiameter AVPについて説明しています。 AVPコード値、タイプ、および可能なフラグ値。 また、AVPを暗号化してもよいかどうか。
Due to space constraints, the short form IPFiltrRule is used to represent IPFilterRule, and DiamIdent is used to represent DiameterIdentity.
スペースの制約により、IPFilterRuleを表すにはIPFiltrRuleという短い形式が使用され、DiameterIdentityを表すにはDiamIdentが使用されます。
+--------------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
MIP-Reg-Request 320 7.1 OctetString| M | P | | V | Y |
MIP-Reg-Reply 321 7.2 OctetString| M | P | | V | Y |
MIP-MN-AAA-Auth 322 7.6 Grouped | M | P | | V | Y |
MIP-Mobile-Node- 333 7.3 Address | M | P | | V | Y |
Address
MIP-Home-Agent- 334 7.4 Address | M | P | | V | Y |
Address
MIP-Candidate- 336 7.9 DiamIdent | M | P | | V | N |
Home-Agent-Host
MIP-Feature- 337 7.5 Unsigned32 | M | P | | V | Y |
Vector
MIP-Auth-Input- 338 7.6.2 Unsigned32 | M | P | | V | Y |
Data-Length
MIP- 339 7.6.3 Unsigned32 | M | P | | V | Y |
Authenticator-Length
MIP- 340 7.6.4 Unsigned32 | M | P | | V | Y |
Authenticator-Offset
MIP-MN-AAA-SPI 341 7.6.1 Unsigned32 | M | P | | V | Y |
MIP-Filter-Rule 342 7.8 IPFiltrRule| M | P | | V | Y |
MIP-FA-Challenge 344 7.7 OctetString| M | P | | V | Y |
MIP-Originating- 347 7.10 Grouped | M | P | | V | Y | Foreign-AAA MIP-Home-Agent- 348 7.11 DiamIdent | M | P | | V | N | Host
MIP-Originating- 347 7.10グループ化| M | P | | V | Y | Foreign-AAA MIP-Home-Agent- 348 7.11 DiamIdent | M | P | | V | N | ホスト
The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and contains the Mobile IPv4 Registration Request [MOBILEIP] sent by the mobile node to the foreign agent.
MIP-Reg-Request AVP（AVPコード320）はOctetStringタイプで、モバイルノードから外部エージェントに送信されたモバイルIPv4登録要求[MOBILEIP]を含みます。
The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and contains the Mobile IPv4 Registration Reply [MOBILEIP] sent by the home agent to the foreign agent.
MIP-Reg-Reply AVP（AVPコード321）はOctetStringタイプで、ホームエージェントから外部エージェントに送信されたモバイルIPv4登録応答[MOBILEIP]が含まれています。
The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and contains the mobile node's home IP address.
MIP-Mobile-Node-Address AVP（AVP Code 333）はAddressタイプで、モバイルノードのホームIPアドレスが含まれています。
The MIP-Home-Agent-Address AVP (AVP Code 334) is of type Address and contains the mobile node's home agent IP address.
MIP-Home-Agent-Address AVP（AVPコード334）はAddressタイプで、モバイルノードのホームエージェントIPアドレスが含まれています。
The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and is added with flag values set by the foreign agent or by the AAAF owned by the same administrative domain as the foreign agent. The foreign agent SHOULD include MIP-Feature-Vector AVP within the AMR message it sends to the AAAF.
MIP-Feature-Vector AVP（AVPコード337）はUnsigned32タイプで、外部エージェントまたは外部エージェントと同じ管理ドメインが所有するAAAFによって設定されたフラグ値で追加されます。 外部エージェントは、AAAFに送信するAMRメッセージ内にMIP-Feature-Vector AVPを含める必要があります。
Flag values currently defined include the following:
現在定義されているフラグ値には、次のものが含まれます。
1 Mobile-Node-Home-Address-Requested
2 Home-Address-Allocatable-Only-in-Home-Realm
4 Home-Agent-Requested
8 Foreign-Home-Agent-Available
16 MN-HA-Key-Request
32 MN-FA-Key-Request
64 FA-HA-Key-Request
128 Home-Agent-In-Foreign-Network
256 Co-Located-Mobile-Node
The flags are set according to the following rules.
フラグは、次の規則に従って設定されます。
If the mobile node includes a valid home address (i.e., one not equal to 0.0.0.0 or 255.255.255.255) in its Registration Request, the foreign agent sets the Mobile-Node-Home-Address-Requested flag in the MIP-Feature-Vector AVP to zero.
モバイルノードの登録要求に有効なホームアドレス（つまり、0.0.0.0または255.255.255.255に等しくないアドレス）が含まれている場合、外部エージェントはMIP-Feature-のMobile-Node-Home-Address-Requestedフラグを設定します。 ゼロへのベクトルAVP。
If the mobile node sets the home agent field equal to 255.255.255.255 in its Registration Request, the foreign agent sets both the Home-Agent-Requested flag and the Home-Address-Allocatable-Only-in-Home-Realm flag to one in the MIP-Feature-Vector AVP.
モバイルノードがその登録要求でホームエージェントフィールドを255.255.255.255に設定した場合、外部エージェントはHome-Agent-RequestedフラグとHome-Address-Allocatable-Only-in-Home-Realmフラグの両方を1つに設定します MIP-Feature-Vector AVP。
If the mobile node sets the home agent field equal to 0.0.0.0 in its Registration Request, the foreign agent sets the Home-Agent-Requested flag to one and zeroes the Home-Address-Allocatable-Only-in-Home-Realm flag in the MIP-Feature-Vector AVP.
モバイルノードが登録要求でホームエージェントフィールドを0.0.0.0に設定した場合、外部エージェントはHome-Agent-Requestedフラグを1に設定し、Home-Address-Allocatable-Only-in-Home-Realmフラグを0に設定します MIP-Feature-Vector AVP。
Whenever the foreign agent sets either the Mobile-Node-Home-Address-Requested flag or the Home-Agent-Requested flag to one, it MUST set the MN-HA-Key-Request flag to one. The MN-HA-Key-Request flag is also set to one if the mobile node includes a "Generalized MN-HA Key Generation Nonce Request" [MIPKEYS] extension, with the subtype set to AAA.
外部エージェントがMobile-Node-Home-Address-RequestedフラグまたはHome-Agent-Requestedフラグのいずれかを1に設定するたびに、MN-HA-Key-Requestフラグを1に設定する必要があります。 モバイルノードに「一般化されたMN-HAキー生成ノンス要求」[MIPKEYS]拡張が含まれ、サブタイプがAAAに設定されている場合、MN-HA-キー要求フラグも1に設定されます。
If the mobile node includes a "Generalized MN-FA Key Generation Nonce Request" [MIPKEYS] extension with the AAA subtype (1) in its Registration Request, the foreign agent sets the MN-FA-Key-Request flag to one in the MIP-Feature-Vector AVP.
モバイルノードの登録要求にAAAサブタイプ（1）の「Generalized MN-FA Key Generation Nonce Request」[MIPKEYS]拡張が含まれている場合、外部エージェントはMN-FA-Key-RequestフラグをMIPの1に設定します。 -Feature-Vector AVP。
If the mobile node requests a home agent in the foreign network either by setting the home address field to all ones, or by specifying a home agent in the foreign network, and the AAAF authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign-Network bit to one.
モバイルノードが、ホームアドレスフィールドをすべて1に設定するか、または外部ネットワークのホームエージェントを指定することにより、外部ネットワークのホームエージェントを要求し、AAAFが要求を承認する場合、AAAFはHome-Agent- In-Foreign-Networkは1対1です。
If the AAAF is willing and able to assign a home agent in the foreign network, the AAAF sets the Foreign-Home-Agent-Available flag to one.
AAAFが外部ネットワークのホームエージェントを喜んで割り当てられる場合、AAAFはForeign-Home-Agent-Availableフラグを1に設定します。
If the Home Agent receives a Registration Request from the mobile node indicating that the MN is acting as a co-located mobile node, the home agent sets the Co-Located-Mobile-Node bit to one.
ホームエージェントが、MNが同じ場所にあるモバイルノードとして機能していることを示す登録要求をモバイルノードから受信すると、ホームエージェントはCo-Located-Mobile-Nodeビットを1に設定します。
If the foreign agent's local policy allows it to receive AAA session keys and it does not have any existing FA-HA key with the home agent, the foreign agent MAY set the FA-HA-Key-Request flag.
外部エージェントのローカルポリシーがAAAセッションキーの受信を許可し、ホームエージェントに既存のFA-HAキーがない場合、外部エージェントはFA-HA-Key-Requestフラグを設定できます。
The foreign agent MUST NOT set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network flag both to one.
外部エージェントは、Foreign-Home-Agent-AvailableおよびHome-Agent-In-Foreign-Networkフラグの両方を1に設定してはなりません。
When the AAAF receives the AMR message, it MUST first verify that the sender was an authorized foreign agent. The AAAF then takes any actions indicated by the settings of the MIP-Feature-Vector AVP flags. The AAAF then MAY set additional flags. Only the AAAF may set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network flags to one. This is done according to local administrative policy. When the AAAF has finished setting additional flags according to its local policy, then the AAAF transmits the AMR with the possibly modified MIP-Feature-Vector AVP to the AAAH.
AAAFがAMRメッセージを受信すると、送信者が許可された外部エージェントであることを最初に確認する必要があります。 AAAFは、MIP-Feature-Vector AVPフラグの設定によって示されたアクションを実行します。 その後、AAAFは追加のフラグを設定できます。 AAAFのみが、Foreign-Home-Agent-AvailableおよびHome-Agent-In-Foreign-Networkフラグを1に設定できます。 これは、ローカル管理ポリシーに従って行われます。 AAAFがローカルポリシーに従って追加のフラグの設定を完了すると、AAAFは、おそらく修正されたMIP-Feature-Vector AVPとともにAMRをAAAHに送信します。
The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains some ancillary data to simplify processing of the authentication data in the Mobile IPv4 Registration Request [MOBILEIP, MIPCHAL] by the target AAA server. Its value has the following ABNF grammar:
MN-AAA-Auth AVP（AVPコード322）はタイプがグループ化されており、ターゲットAAAサーバーによるモバイルIPv4登録要求[MOBILEIP、MIPCHAL]の認証データの処理を簡素化する補助データが含まれています。 その値には、次のABNF文法があります。
MIP-MN-AAA-Auth ::= < AVP Header: 322 >
{ MIP-MN-AAA-SPI }
{ MIP-Auth-Input-Data-Length }
{ MIP-Authenticator-Length }
{ MIP-Authenticator-Offset }
* [ AVP ]
The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and indicates the MSA by which the targeted AAA server (AAAH) should attempt to validate the Authenticator computed by the mobile node over the Registration Request data.
MIP-MN-AAA-SPI AVP（AVPコード341）は、タイプUnsigned32であり、MSAを示します。MSAは、ターゲットAAAサーバー（AAAH）が登録要求データでモバイルノードによって計算された認証子の検証を試みる必要があります。
The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is of type Unsigned32 and contains the length, in bytes, of the Registration Request data (data portion of MIP-Reg-Request AVP) that should be used as input to the algorithm, as indicated by the MN-AAA-SPI AVP, used to determine whether the Authenticator Data supplied by the mobile node is valid.
MIP-Auth-Input-Data-Length AVP（AVPコード338）は、タイプUnsigned32であり、入力として使用される登録要求データ（MIP-Reg-Request AVPのデータ部分）の長さをバイト単位で含みます MN-AAA-SPI AVPによって示されるアルゴリズムへの、モバイルノードによって提供された認証データが有効かどうかを判断するために使用されます。
The MIP-Authenticator-Length AVP (AVP Code 339) is of type Unsigned32 and contains the length of the authenticator to be validated by the targeted AAA server (i.e., AAAH).
MIP-Authenticator-Length AVP（AVP Code 339）はタイプUnsigned32であり、ターゲットAAAサーバー（つまりAAAH）によって検証される認証子の長さを含みます。
The MIP-Authenticator-Offset AVP (AVP Code 340) is of type Unsigned32 and contains the offset into the Registration Request Data, of the authenticator to be validated by the targeted AAA server (i.e., AAAH).
MIP-Authenticator-Offset AVP（AVP Code 340）はタイプUnsigned32であり、ターゲットAAAサーバー（つまりAAAH）によって検証される認証者のRegistration Request Dataへのオフセットを含みます。
The MIP-FA-Challenge AVP (AVP Code 344) is of type OctetString and contains the challenge advertised by the foreign agent to the mobile node. This AVP MUST be present in the AMR if the mobile node used the RADIUS-style MN-AAA computation algorithm [MIPCHAL].
MIP-FA-Challenge AVP（AVPコード344）はOctetStringタイプで、外部エージェントによってモバイルノードにアドバタイズされるチャレンジが含まれています。 モバイルノードがRADIUSスタイルのMN-AAA計算アルゴリズム[MIPCHAL]を使用した場合、このAVPはAMRに存在しなければなりません。
The MIP-Filter-Rule AVP (AVP Code 342) is of type IPFilterRule and provides filter rules that have to be configured on the foreign or home agent for the user. The packet filtering rules are set by the AAAH by adding one or more MIP-Filter-Rule AVPs in the HAR if destined for the home agent and/or in the AMA if destined for the foreign agent.
MIP-Filter-Rule AVP（AVPコード342）はIPFilterRuleタイプで、ユーザーの外部エージェントまたはホームエージェントで構成する必要のあるフィルター規則を提供します。 パケットフィルタリングルールは、ホームエージェント宛ての場合はHARに、または外部エージェント宛の場合はAMAに1つ以上のMIP-Filter-Rule AVPを追加することにより、AAAHによって設定されます。
The MIP-Candidate-Home-Agent-Host AVP (AVP Code 336) is of type DiameterIdentity and contains the identity of a home agent in the foreign network that the AAAF proposes to be dynamically assigned to the mobile node.
MIP-Candidate-Home-Agent-Host AVP（AVP Code 336）はDiameterIdentityタイプで、AAFがモバイルノードに動的に割り当てることを提案する外部ネットワーク内のホームエージェントのIDを含みます。
The MIP-Originating-Foreign-AAA AVP (AVP Code 347) is of type Grouped and contains the identity of the AAAF, which issues the AMR to the AAAH. The MIP-Originating-Foreign-AAA AVP MUST only be used in cases when the home agent is or may be allocated in a foreign domain. If the MIP-Originating-Foreign-AAA AVP is present in the AMR, the AAAH MUST copy it into the HAR.
MIP-Originating-Foreign-AAA AVP（AVP Code 347）はタイプがグループ化され、AAMRをAAAHに発行するAAAFのIDを含んでいます。 MIP-Originating-Foreign-AAA AVPは、ホームエージェントが外部ドメインに割り当てられている場合、または割り当てられる場合にのみ使用する必要があります。 MIP-Originating-Foreign-AAA AVPがAMRに存在する場合、AAAHはそれをHARにコピーする必要があります。
MIP-Originating-Foreign-AAA ::= < AVP Header: 347 >
{ Origin-Realm }
{ Origin-Host }
* [ AVP ]
The MIP-Home-Agent-Host AVP (AVP Code 348) is of type Grouped and contains the identity of the assigned Home Agent. If the MIP-Home-Agent-Host AVP is present in the AMR, the AAAH MUST copy it into the HAR.
MIP-Home-Agent-Host AVP（AVPコード348）はタイプがグループ化されており、割り当てられたHAのIDが含まれています。 MIP-Home-Agent-Host AVPがAMRに存在する場合、AAAHはそれをHARにコピーする必要があります。
MIP-Home-Agent-Host ::= < AVP Header: 348 >
{ Destination-Realm }
{ Destination-Host }
* [ AVP ]
The mobile node and mobility agents use session keys (i.e., the MN-FA, FA-HA, and MN-HA session keys) to compute authentication extensions applied to MIP registration messages, as defined in [MOBILEIP]. If session keys are requested, the AAAH MUST return the keys and nonces after the mobile node is successfully authenticated and authorized.
モバイルノードとモビリティエージェントは、[MOBILEIP]で定義されているように、セッションキー（MN-FA、FA-HA、およびMN-HAセッションキー）を使用して、MIP登録メッセージに適用される認証拡張機能を計算します。 セッションキーが要求された場合、モバイルノードが正常に認証および承認された後、AAAHはキーとノンスを返さなければなりません。
The SPI values are used as key identifiers, and each session key has its own SPI value; nodes that share a key can have multiple different SPIs all referring to the same key. In all cases, the entity that receives an authentication extension (i.e., that verifies the authentication extension) is providing the entity that sends the authentication extension (i.e., that computes the authentication extension) the value of the SPI to use for that computation. Note that the keys in this model are symmetric in that they are used in both directions, even though the SPIs do not have to be symmetric.
SPI値はキー識別子として使用され、各セッションキーには独自のSPI値があります。 キーを共有するノードは、同じキーをすべて参照する複数の異なるSPIを持つことができます。 すべての場合において、認証拡張を受信する（つまり、認証拡張を検証する）エンティティは、認証拡張を送信する（つまり、認証拡張を計算する）エンティティに、その計算に使用するSPIの値を提供します。 SPIが対称である必要はありませんが、このモデルのキーは両方向で使用されるという点で対称であることに注意してください。
The mobile node allocates SPIs for use in the FA-MN and HA-MN mobility security associations, via the Mobile IPv4 AAA Key Request extensions [MIPKEYS]. The home agent allocates SPIs for the MN-HA and FA-HA mobility security association. The foreign agent chooses SPIs for the MN-FA and HA-FA mobility security associations.
モバイルノードは、Mobile IPv4 AAA Key Request拡張機能[MIPKEYS]を介して、FA-MNおよびHA-MNモビリティセキュリティアソシエーションで使用するSPIを割り当てます。 ホームエージェントは、MN-HAおよびFA-HAモビリティセキュリティアソシエーションにSPIを割り当てます。 外部エージェントは、MN-FAおよびHA-FAモビリティセキュリティアソシエーション用のSPIを選択します。
Once the session keys and nonces have been distributed, subsequent Mobile IPv4 registrations need not invoke the AAA infrastructure until the keys expire. As mandated by Mobile IPv4, these registrations MUST include the MN-HA authentication extension. Likewise, subsequent registrations MUST also include MN-FA authentication extension if the MN-FA session key was generated and distributed by AAA. The same hold true for subsequent use of the FA-HA authentication extensions.
セッションキーとナンスが配布されると、その後のモバイルIPv4登録では、キーが期限切れになるまでAAAインフラストラクチャを呼び出す必要はありません。 モバイルIPv4で義務付けられているように、これらの登録にはMN-HA認証拡張を含める必要があります。 同様に、MN-FAセッションキーがAAAによって生成および配布された場合、後続の登録にもMN-FA認証拡張機能を含める必要があります。 同じことが、FA-HA認証拡張機能のその後の使用にも当てはまります。
The Diameter Mobile IPv4 application makes use of two timers: the Authorization-Lifetime AVP [DIAMBASE] and the MIP-MSA-Lifetime AVP.
DiameterモバイルIPv4アプリケーションは、Authorization-Lifetime AVP [DIAMBASE]とMIP-MSA-Lifetime AVPの2つのタイマーを使用します。
The Authorization-Lifetime contains the number of seconds before the mobile node must issue a subsequent MIP registration request. The content of the Authorization-Lifetime AVP corresponds to the Lifetime field in the MIP header [MOBILEIP].
Authorization-Lifetimeには、モバイルノードが後続のMIP登録要求を発行するまでの秒数が含まれます。 Authorization-Lifetime AVPのコンテンツは、MIPヘッダー[MOBILEIP]のLifetimeフィールドに対応しています。
The MIP-MSA-Lifetime AVP contains the number of seconds before session keys destined for the mobility agents and the mobile node expire. A value of zero indicates infinity (no timeout). If not zero, the value of the MIP-MSA-Lifetime AVP MUST be at least equal to the value in the Authorization Lifetime AVP.
MIP-MSA-Lifetime AVPには、モビリティエージェント宛てのセッションキーとモバイルノードの有効期限が切れるまでの秒数が含まれています。 値ゼロは、無限大（タイムアウトなし）を示します。 ゼロでない場合、MIP-MSA-Lifetime AVPの値は、少なくともAuthorization Lifetime AVPの値と等しくなければなりません。
As described in section 3.4, the AAAH generates session keys and transmits them to the home agent and foreign agent. The AAAH generates nonces that correspond to the same keys and transmits them to the mobile node. When it is necessary to protect the session keys and SPIs from un-trusted Diameter agents, end-to-end security mechanisms such as TLS or IPSec are required to eliminate all Diameter Agents between the FA or HA and the AAAH, as outlined above.
セクション3.4で説明したように、AAAHはセッションキーを生成し、それらをホームエージェントと外部エージェントに送信します。 AAAHは、同じキーに対応するノンスを生成し、モバイルノードに送信します。 セッションキーとSPIを信頼できないDiameterエージェントから保護する必要がある場合、TLSまたはIPSecなどのエンドツーエンドのセキュリティメカニズムが必要です。上記のように、FAまたはHAとAAAHの間のすべてのDiameterエージェントを排除します。
In [MIPKEYS], the mobility security associations are established via nonces transmitted to the mobile node via Mobile IPv4. To provide the nonces, the AAAH must generate a random [RANDOM] value of at least 128 bits [MIPKEYS]. The mobile node then uses the nonce to derive the MN-HA and MN-FA session keys.
[MIPKEYS]では、モバイルセキュリティアソシエーションは、モバイルIPv4を介してモバイルノードに送信されるノンスを介して確立されます。 一回限りを提供するには、AAAHは少なくとも128ビットのランダムな[RANDOM]値[MIPKEYS]を生成する必要があります。 モバイルノードは、ナンスを使用してMN-HAおよびMN-FAセッションキーを取得します。
More details of the MN-HA and the MN-FA session key creation procedures are found in [MIPKEYS].
MN-HAおよびMN-FAセッションキー作成手順の詳細は、[MIPKEYS]にあります。
The hashing algorithm used by the mobile node to construct the session key has to be the same as that used by the AAAH in the session key generation procedure. The AAAH therefore indicates the algorithm used along with the nonce.
セッションキーを構築するためにモバイルノードで使用されるハッシュアルゴリズムは、セッションキー生成手順でAAAHで使用されるものと同じである必要があります。 したがって、AAAHは、ナンスとともに使用されるアルゴリズムを示します。
The FA-HA and HA-FA session key is shared between the FA and HA. The AAAH generates a random [RANDOM] value of at least 128 bits for use as this session key.
FA-HAおよびHA-FAセッションキーは、FAとHAの間で共有されます。 AAAHは、このセッションキーとして使用するために、少なくとも128ビットのランダムな[RANDOM]値を生成します。
See sections 9 for details about the format of the AVPs used to transport the session keys.
セッションキーの転送に使用されるAVPの形式の詳細については、セクション9を参照してください。
If the mobile node does not have an MN-HA session key, then the AAAH is likely to be the only trusted entity that is available to the mobile node. Thus, the AAAH has to generate the MN-HA session key.
モバイルノードにMN-HAセッションキーがない場合、AAAHがモバイルノードで利用できる唯一の信頼できるエンティティである可能性があります。 したがって、AAAHはMN-HAセッションキーを生成する必要があります。
The distribution of the HA-MN (session) key to the HA is specified in sections 1.2 and 3.4. The HA and AAAH establish a security association (IPSec or TLS) and transport the key over it. If no security association exists between the AAAH and the home agent and a security association cannot be established, the AAAH MUST return a Result-Code AVP with DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION.
HAへのHA-MN（セッション）キーの配布は、セクション1.2および3.4で指定されています。 HAとAAAHはセキュリティアソシエーション（IPSecまたはTLS）を確立し、その上にキーを転送します。 AAAHとホームエージェントの間にセキュリティアソシエーションが存在せず、セキュリティアソシエーションを確立できない場合、AAAHはDIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTIONの結果コードAVPを返さなければなりません。
The AAAH also has to arrange for the key to be delivered to the mobile node. Unfortunately, the AAAH only knows about Diameter messages and AVPs, and the mobile node only knows about Mobile IPv4 messages and extensions [MOBILEIP]. For this purpose, AAAH includes the MN-HA MIP-nonce AVP into a MIP-MN-to-HA-MSA AVP, which is added to the HAR (for FA COA style Mobile IPv4) or to the AMA (for collocated COA-style Mobile IPv4 messages) and delivered either to a local home agent or a home agent in the visited network. Note that the mobile node will use the nonce to create the MN-HA session key by using the MN-AAA key it shares with the AAAH [MIPKEYS]. The AAAH has to rely on the home agent (which also understands Diameter) to transfer the nonce into a Mobile IPv4 "Generalized MN-HA Key Generation Nonce Reply" extension [MIPKEYS] in the Registration Reply message. The HA includes the SPIs proposed by the mobile node and the home agent in the "Generalized MN-HA Key Generation Nonce Request" extension. The home agent can format the Reply message and extensions correctly for eventual delivery to the mobile node. The resulting Registration Reply is added to the HAA's MIP-Reg-Reply AVP.
AAAHは、キーがモバイルノードに配信されるように手配する必要もあります。残念ながら、AAAHはDiameterメッセージとAVPのみを知っており、モバイルノードはモバイルIPv4メッセージと拡張[MOBILEIP]のみを知っています。この目的のために、AAAHは、MN-HA MIP-nonce AVPをMIP-MN-to-HA-MSA AVPに含めます。これは、HAR（FA COAスタイルモバイルIPv4の場合）またはAMA（コロケートCOA-スタイルモバイルIPv4メッセージ）、訪問先ネットワークのローカルホームエージェントまたはホームエージェントのいずれかに配信されます。モバイルノードは、AAAH [MIPKEYS]と共有するMN-AAAキーを使用して、ナンスを使用してMN-HAセッションキーを作成することに注意してください。 AAAHは、登録応答メッセージ内のモバイルIPv4「汎用MN-HAキー生成ノンス応答」拡張[MIPKEYS]にノンスを転送するために、ホームエージェント（Diameterも理解）に依存する必要があります。 HAには、「一般化されたMN-HAキー生成ノンス要求」拡張機能のモバイルノードとホームエージェントによって提案されたSPIが含まれます。ホームエージェントは、モバイルノードへの最終的な配信のために、返信メッセージと拡張機能を正しくフォーマットできます。結果の登録応答は、HAAのMIP-Reg-Reply AVPに追加されます。
The AAAH parses the HAA message, transforms it into an AMA message containing an MIP-Reg-Reply AVP, and sends the AMA message to the foreign agent. The foreign agent then uses that AVP to recreate a Registration Reply message containing the "Generalized MN-HA Key Generation Nonce Reply" extension for delivery to the mobile node.
AAAHはHAAメッセージを解析し、MIP-Reg-Reply AVPを含むAMAメッセージに変換し、AMAメッセージを外部エージェントに送信します。 次に、外部エージェントはそのAVPを使用して、モバイルノードに配信するための「Generalized MN-HA Key Generation Nonce Reply」拡張を含むRegistration Replyメッセージを再作成します。
In summary, the AAAH generates the MN-HA nonce, which is added to the MIP-MN-to-HA-MSA AVP, and a session key, which is added to the MIP-HA-to-MN-MSA AVP. These AVPs are delivered to the home agent in HAR or AMA messages. The home agent retains the session key for its own use and copies the nonce from the MIP-MN-to-HA-MSA AVP into a "Generalized MN-HA Key Generation Nonce Reply" extension, which is appended to the Mobile IPv4 Registration Reply message. This Registration Reply message MUST also include the HA-MN authentication extension, which is created by using the newly allocated HA-MN session key. The home agent then includes the Registration Reply message and extensions into a MIP-Reg-Reply AVP as part of the HAA message to be sent back to the AAA server.
要約すると、AAAHは、MIP-MN-to-HA-MSA AVPに追加されるMN-HAノンスと、MIP-HA-to-MN-MSA AVPに追加されるセッションキーを生成します。 これらのAVPは、HARまたはAMAメッセージでホームエージェントに配信されます。 ホームエージェントは独自に使用するためにセッションキーを保持し、MIP-MN-to-HA-MSA AVPからノンスを「一般化されたMN-HAキー生成ノンス応答」拡張にコピーします。これはモバイルIPv4登録応答に追加されます メッセージ。 この登録応答メッセージには、新しく割り当てられたHA-MNセッションキーを使用して作成されるHA-MN認証拡張機能も含める必要があります。 次に、ホームエージェントは、HAAメッセージの一部としてRegistration Replyメッセージと拡張機能をMIP-Reg-Reply AVPに含めて、AAAサーバーに送り返します。
The key derived by the MN from the MN-HA session nonce is identical to the HA-MN session key provided to the HA.
MNがMN-HAセッションナンスから取得したキーは、HAに提供されたHA-MNセッションキーと同一です。
The MN-FA session nonce is also generated by AAAH (upon request) and added to the MIP-MN-to-FA-MSA AVP, which is added to the HAR and copied by the home agent into a "Generalized MN-FA Key Generation Nonce Reply" extension [MIPKEYS] of the Mobile IPv4 Registration Reply message. The HA also includes the SPIs proposed by the mobile node and foreign agent in the "Generalized MN-FA Key Generation Nonce Request" extension. The AAAH includes the FA-MN session key in the MIP-FA-to-MN-MSA AVP in the AMA, to be used by the foreign agent in the computation of the FA-MN authentication extension.
MN-FAセッションナンスはAAAHによっても生成され（要求に応じて）、MIP-MN-to-FA-MSA AVPに追加されます。これは、HARに追加され、ホームエージェントによって「一般化されたMN-FAキー Mobile IPv4 Registration ReplyメッセージのGeneration Nonce Reply」拡張機能[MIPKEYS]。 HAには、「一般化されたMN-FAキー生成ノンス要求」拡張機能のモバイルノードおよび外部エージェントによって提案されたSPIも含まれます。 AAAHには、FA-MN認証拡張の計算で外部エージェントが使用するために、AMAのMIP-FA-to-MN-MSA AVPにFA-MNセッションキーが含まれています。
The key derived by the MN from the MN-FA session nonce is identical to the FA-MN session key provided to the FA.
MNがMN-FAセッションナンスから導出したキーは、FAに提供されたFA-MNセッションキーと同一です。
If the foreign agent requests an FA-HA session key, it also includes a MIP-HA-to-FA-SPI AVP in the AMR to convey the SPI to be used by the home agent for this purpose. The AAAH generates the FA-HA session key, which is identical to the HA-FA session key, and distributes that to both the HA and the FA over respective security associations by using the MIP-HA-to-FA-MSA and MIP-FA-to-HA-MSA AVPs. The HA conveys the SPI that the FA MUST use in the HAA; this is similar to the way in which the FA conveys that the SPI that the HA MUST use in the AMR. The AAAH later includes these SPIs in the MIP-FA-HA-MSA and MIP-HA-FA-MSA AVPs, respectively, along with the session key.
外部エージェントがFA-HAセッションキーを要求する場合、AMRにMIP-HA-to-FA-SPI AVPも含めて、この目的でホームエージェントが使用するSPIを伝達します。 AAAHは、HA-FAセッションキーと同一のFA-HAセッションキーを生成し、MIP-HA-to-FA-MSAおよびMIP-を使用して、それぞれのセキュリティアソシエーションを介してHAとFAの両方に配布します。 FA-to-HA-MSA AVP。 HAは、FAがHAAで使用しなければならないSPIを伝えます。 これは、HAがAMRで使用しなければならないSPIをFAが伝える方法に似ています。 AAAHは後で、セッションキーとともに、これらのSPIをそれぞれMIP-FA-HA-MSAおよびMIP-HA-FA-MSA AVPに含めます。
Refer to Figures 2, 3, 4, and 6 for the messages involved.
関連するメッセージについては、図2、3、4、および6を参照してください。
Note that if multiple MNs are registered on the same FA and HA pair, then multiple mobility security associations would be distributed. However, only one is required to protect the Mobile IP control traffic between FA and HA. This creates an unacceptable level of state (i.e., to store the two SPIs and shared key for each FA-HA mobility security association). To improve scalability, the FA and HA may discard FA-HA mobility security associations prior to the time when they actually expire. However, if a proper discard policy is not chosen, this could cause Mobile IP messages in transit or waiting in queues for transmission to fail authentication.
複数のMNが同じFAとHAのペアに登録されている場合、複数のモビリティセキュリティアソシエーションが配布されることに注意してください。 ただし、FAとHA間のモバイルIP制御トラフィックを保護するには、1つだけが必要です。 これにより、許容できないレベルの状態が作成されます（つまり、各FA-HAモビリティセキュリティアソシエーションの2つのSPIと共有キーを保存します）。 スケーラビリティを向上させるために、FAとHAは、実際に期限が切れる前にFA-HAモビリティセキュリティアソシエーションを破棄する場合があります。 ただし、適切な廃棄ポリシーが選択されていない場合、モバイルIPメッセージが送信中またはキュー内で送信を待機して認証に失敗する可能性があります。
The FA MUST always use the FA-HA security association with the latest expiry time when computing authentication extensions on outgoing messages. The FA MAY discard HA-FA mobility security associations 10 seconds after a new HA-FA mobility security association arrives with a later expiry time.
FAは、発信メッセージの認証拡張機能を計算するときに、常に最新の有効期限を持つFA-HAセキュリティアソシエーションを使用する必要があります。 FAは、新しいHA-FAモビリティセキュリティアソシエーションが後の有効期限で到着してから10秒後にHA-FAモビリティセキュリティアソシエーションを破棄する場合があります。
The HA SHOULD use the HA-FA mobility security association that has the latest expiry time when computing authentication extensions in outgoing messages. However, when the HA receives a new HA-FA mobility security association with a later expiry time, the HA SHOULD wait 4 seconds for the AMA to propagate to the FA before using the new association. Note that the HA always uses the mobility security association from the HAR when constructing the Mobile IP Registration Reply in the corresponding HAA. The HA MAY discard an FA-HA mobility security association once it receives a message authenticated by a FA-HA mobility security association with a later expiry time.
HAは、発信メッセージの認証拡張機能を計算するときに、有効期限が最も遅いHA-FAモビリティセキュリティアソシエーションを使用する必要があります。 ただし、HAは、有効期限の遅い新しいHA-FAモビリティセキュリティアソシエーションを受信すると、AMAがFAに伝播するまで4秒待ってから新しいアソシエーションを使用する必要があります。 HAは、対応するHAAでモバイルIP登録応答を構築するときに、HARからのモビリティセキュリティアソシエーションを常に使用することに注意してください。 HAは、FA-HAモビリティセキュリティアソシエーションによって認証されたメッセージを、有効期限が遅れて受信すると、FA-HAモビリティセキュリティアソシエーションを破棄する場合があります。
The Mobile-IP protocol defines a set of mobility security associations shared between the mobile node, foreign agent, and home agent. These three mobility security associations (MN-HA, MN-FA, and FA-HA) are dynamically created by the AAAH and have previously been described in sections 3.4 and 8. AAA servers supporting the Diameter Mobile IP Application MUST implement the key distribution AVPs defined in this document.
モバイルIPプロトコルは、モバイルノード、外部エージェント、およびホームエージェント間で共有されるモビリティセキュリティアソシエーションのセットを定義します。 これら3つのモビリティセキュリティアソシエーション（MN-HA、MN-FA、およびFA-HA）は、AAAHによって動的に作成され、セクション3.4および8で既に説明されています。DiameterモバイルIPアプリケーションをサポートするAAAサーバーは、キー配布AVPを実装する必要があります このドキュメントで定義されています。
The names of the key distribution AVPs indicate the two entities sharing the mobility security association. The first named entity in the AVP name will use the mobility security association to create authentication extensions using the given SPI and key. The second named entity in the AVP name will use the mobility security association to verify the authentication extensions of received Mobile IP messages.
キー配布AVPの名前は、モビリティセキュリティアソシエーションを共有する2つのエンティティを示します。 AVP名の最初の名前付きエンティティは、モビリティセキュリティアソシエーションを使用して、指定されたSPIとキーを使用して認証拡張機能を作成します。 AVP名の2番目の名前付きエンティティは、モビリティセキュリティアソシエーションを使用して、受信したモバイルIPメッセージの認証拡張機能を検証します。
For instance, the MIP-MN-to-HA-MSA AVP contains the MN-HA nonce, which the mobile node will use to derive the MN-HA Key, and the MIP-HA-to-MN-MSA AVP contains the MN-HA key for the home agent. Note that mobility security associations are unidirectional; however, this application delivers only one key that is shared between both unidirectional security associations that exist between two peers. The security considerations of using the same key in each direction are given in section 13. The SPIs are, however, unique to each unidirectional security association and are chosen by the peer that will receive the Mobile IP messages authenticated with that security association.
たとえば、MIP-MN-to-HA-MSA AVPにはMN-HAノンスが含まれ、モバイルノードはこれを使用してMN-HAキーを導出し、MIP-HA-to-MN-MSA AVPにはMNが含まれます -ホームエージェントのHAキー。 モビリティセキュリティアソシエーションは単方向であることに注意してください。 ただし、このアプリケーションは、2つのピア間に存在する両方の単方向セキュリティアソシエーション間で共有される1つのキーのみを配信します。 各方向で同じキーを使用する場合のセキュリティの考慮事項はセクション13に記載されています。ただし、SPIは各単方向セキュリティアソシエーションに固有であり、そのセキュリティアソシエーションで認証されたモバイルIPメッセージを受信するピアによって選択されます。
The following table describes the Diameter AVPs defined in the Mobile IP application and their AVP Code values, types, and possible flag values.
次の表は、モバイルIPアプリケーションで定義されているDiameter AVPと、そのAVPコード値、タイプ、および可能なフラグ値を示しています。
+--------------------------+
| AVP Flag Rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
MIP-FA-to-HA-SPI 318 9.11 Unsigned32 | M | P | | V | Y |
MIP-FA-to-MN-SPI 319 9.10 Unsigned32 | M | P | | V | Y |
MIP-HA-to-FA-SPI 323 9.14 Unsigned32 | M | P | | V | Y |
MIP-MN-to-FA-MSA 325 9.5 Grouped | M | P | | V | Y |
MIP-FA-to-MN-MSA 326 9.1 Grouped | M | P | | V | Y |
MIP-FA-to-HA-MSA 328 9.2 Grouped | M | P | | V | Y |
MIP-HA-to-FA-MSA 329 9.3 Grouped | M | P | | V | Y |
MIP-MN-to-HA-MSA 331 9.6 Grouped | M | P | | V | Y |
MIP-HA-to-MN-MSA 332 9.4 Grouped | M | P | | V | Y |
MIP-Nonce 335 9.12 OctetString| M | P | | V | Y |
MIP-Session-Key 343 9.7 OctetString| M | P | | V | Y |
MIP-Algorithm- 345 9.8 Enumerated | M | P | | V | Y |
Type
MIP-Replay-Mode 346 9.9 Enumerated | M | P | | V | Y |
MIP-MSA-Lifetime 367 9.13 Unsigned32 | M | P | | V | Y |
The MIP-FA-to-MN-MSA AVP (AVP Code 326) is of type Grouped and contains the FA-MN session key. This AVP is conveyed to the FA in an AMA message. The MN allocates the MIP-FA-to-MN-SPI. The FA creates an FA-MN authentication extension by using the session key and algorithm, and the MN verifies that extension by using the same session key and algorithm. The data field of this AVP has the following ABNF grammar:
MIP-FA-to-MN-MSA AVP（AVPコード326）はタイプがグループ化されており、FA-MNセッションキーが含まれています。 このAVPは、AMAメッセージでFAに伝えられます。 MNはMIP-FA-to-MN-SPIを割り当てます。 FAは、セッションキーとアルゴリズムを使用してFA-MN認証拡張機能を作成し、MNは同じセッションキーとアルゴリズムを使用してその拡張機能を検証します。 このAVPのデータフィールドには、次のABNF文法があります。
MIP-FA-to-MN-MSA ::= < AVP Header: 326 >
{ MIP-FA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
The MIP-FA-to-HA-MSA AVP (AVP Code 328) is of type Grouped and contains the FA-HA session key. This AVP is conveyed to the FA in an AMA message. The HA allocates the MIP-FA-to-HA-SPI. The FA creates the FA-HA authentication extension by using the session key and algorithm, and the HA verifies that extension by using the same key and algorithm. The AVP's data field has the following ABNF grammar:
MIP-FA-to-HA-MSA AVP（AVPコード328）はタイプがグループ化され、FA-HAセッションキーが含まれています。 このAVPは、AMAメッセージでFAに伝えられます。 HAはMIP-FA-to-HA-SPIを割り当てます。 FAは、セッションキーとアルゴリズムを使用してFA-HA認証拡張機能を作成し、HAは同じキーとアルゴリズムを使用してその拡張機能を検証します。 AVPのデータフィールドには、次のABNF文法があります。
MIP-FA-to-HA-MSA ::= < AVP Header: 328 >
{ MIP-FA-to-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
The MIP-HA-to-FA-MSA AVP (AVP Code 329) is of type Grouped and contains the Home Agent's session key, which it shares with the foreign agent. This AVP is conveyed to the HA in an HAR message. The FA allocates the MIP-HA-to-FA-SPI. The HA creates the HA-FA authentication extension by using the session key and algorithm, and the FA verifies that extension by using the same session key and algorithm. The AVP's data field has the following ABNF grammar:
MIP-HA-to-FA-MSA AVP（AVPコード329）はタイプがグループ化されており、ホームエージェントのセッションキーを含みます。これは外部エージェントと共有します。 このAVPは、HARメッセージでHAに伝えられます。 FAはMIP-HA-to-FA-SPIを割り当てます。 HAは、セッションキーとアルゴリズムを使用してHA-FA認証拡張機能を作成し、FAは同じセッションキーとアルゴリズムを使用してその拡張機能を検証します。 AVPのデータフィールドには、次のABNF文法があります。
MIP-HA-to-FA-MSA ::= < AVP Header: 329 >
{ MIP-HA-to-FA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
The MIP-HA-to-MN-MSA AVP (AVP Code 332) is of type Grouped, and contains the HA-MN session key. This AVP is conveyed to the HA in an HAR for FA COA Mobile IPv4 and in an AMA for collocated COA Mobile IPv4. The MN allocates the MIP-HA-to-MN-SPI. The HA creates the HA-MN authentication extension by using the session key and algorithm, and the MN verifies that extension by using the same key and algorithm. The AVP's field has the following ABNF grammar:
MIP-HA-MN-MSA AVP（AVPコード332）はタイプがグループ化されており、HA-MNセッションキーが含まれています。 このAVPは、FA COAモバイルIPv4の場合はHARで、コロケートCOAモバイルIPv4の場合はAMAでHAに伝えられます。 MNはMIP-HA-to-MN-SPIを割り当てます。 HAはセッションキーとアルゴリズムを使用してHA-MN認証拡張機能を作成し、MNは同じキーとアルゴリズムを使用してその拡張機能を検証します。 AVPのフィールドには、次のABNF文法があります。
MIP-HA-to-MN-MSA ::= < AVP Header: 332 >
{ MIP-HA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-Session-Key }
* [ AVP ]
The MIP-MN-to-FA-MSA AVP (AVP Code 325) is of type Grouped, and contains the MN-FA session nonce, which the mobile node uses to derive the MN-FA session key. This AVP is conveyed to the HA in an HAR message. The FA allocates the MIP-MN-to-FA-SPI. The MN creates the MN-FA authentication extension by using the session key and algorithm, and the FA verifies that extension using the same key and algorithm.
MIP-MNからFA-MSAへのAVP（AVPコード325）はタイプがグループ化されており、MN-FAセッションノンスが含まれています。モバイルノードはこれを使用してMN-FAセッションキーを取得します。 このAVPは、HARメッセージでHAに伝えられます。 FAはMIP-MN-to-FA-SPIを割り当てます。 MNはセッションキーとアルゴリズムを使用してMN-FA認証拡張機能を作成し、FAは同じキーとアルゴリズムを使用してその拡張機能を検証します。
The home agent uses this AVP in the construction of the Mobile IP "Generalized MN-FA Key Generation Nonce Reply" extension [MIPKEYS].
ホームエージェントは、モバイルIP「一般化されたMN-FAキー生成ノンス応答」拡張機能[MIPKEYS]の構築にこのAVPを使用します。
MIP-MN-to-FA-MSA ::= < AVP Header: 325 >
{ MIP-MN-FA-SPI }
{ MIP-Algorithm-Type }
{ MIP-nonce }
* [ AVP ]
The MIP-MN-to-HA-MSA AVP (AVP Code 331) is of type Grouped and contains the MN-HA session nonce, which the mobile node uses to derive the MN-HA session key. This AVP is conveyed to the HA in an HAR message for FA COA Mobile IPv4 and in an AMR for collocated Mobile IPv4. The HA allocates the MIP-MN-to-HA-SPI. The MN creates the MN-FA authentication extension using the session key and algorithm, and the HA verifies that extension using the same session key and algorithm.
MIP-MN-to-HA-MSA AVP（AVPコード331）はタイプがグループ化され、モバイルノードがMN-HAセッションキーを取得するために使用するMN-HAセッションノンスを含みます。 このAVPは、FA COAモバイルIPv4の場合はHARメッセージで、コロケーションモバイルIPv4の場合はAMRでHAに伝えられます。 HAはMIP-MN-to-HA-SPIを割り当てます。 MNはセッションキーとアルゴリズムを使用してMN-FA認証拡張機能を作成し、HAは同じセッションキーとアルゴリズムを使用してその拡張機能を検証します。
The Home Agent uses this AVP in the construction of the Mobile IP "Generalized MN-HA Key Generation Nonce Reply" extension [MIPKEYS].
ホームエージェントは、モバイルIP「一般化されたMN-HAキー生成ノンス応答」拡張機能[MIPKEYS]の構築にこのAVPを使用します。
MIP-MN-to-HA-MSA ::= < AVP Header: 331 >
{ MIP-MN-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-nonce }
* [ AVP ]
The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and contains the Session Key for the associated Mobile IPv4 authentication extension. The HAAA selects the session key.
MIP-Session-Key AVP（AVP Code 343）はOctetStringタイプで、関連するモバイルIPv4認証拡張機能のセッションキーが含まれています。 HAAAはセッションキーを選択します。
The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated and contains the Algorithm identifier for the associated Mobile IPv4 authentication extension. The HAAA selects the algorithm type. The following values are currently defined:
MIP-Algorithm-Type AVP（AVP Code 345）は列挙型で、関連付けられたモバイルIPv4認証拡張機能のアルゴリズム識別子が含まれています。 HAAAはアルゴリズムタイプを選択します。 現在、次の値が定義されています。
2 HMAC-SHA-1 [HMAC]
2 HMAC-SHA-1 [HMAC]
The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and contains the replay mode the Home Agent for authenticating the mobile node. The HAAA selects the replay mode.
MIP-Replay-Mode AVP（AVP Code 346）は列挙型であり、モバイルノードを認証するためのHAの再生モードが含まれています。 HAAAはリプレイモードを選択します。
The following values are supported (see [MOBILEIP] for more information):
次の値がサポートされています（詳細については、[MOBILEIP]を参照）。
1 None
2 Timestamps
3 Nonces
The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and it contains the Security Parameter Index the FA that and MN use to refer to the FA-MN mobility security association. The MN allocates the SPI, and it MUST NOT have a value between zero (0) and 255, which is the reserved namespace defined in [MOBILEIP].
MIP-FA-to-MN-SPI AVP（AVPコード319）は、タイプUnsigned32であり、FAおよびMNがFA-MNモビリティセキュリティアソシエーションを参照するために使用するセキュリティパラメータインデックスが含まれています。 MNはSPIを割り当て、ゼロ（0）から255までの値を持つことはできません。これは[MOBILEIP]で定義された予約済みの名前空間です。
The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32 and contains the Security Parameter Index the FA and HA use to refer to the FA-HA mobility security association. The HA allocates the SPI, and it MUST NOT have a value between zero (0) and 255, which is the reserved namespace defined in [MOBILEIP].
MIP-FA-to-HA-SPI AVP（AVPコード318）はタイプUnsigned32であり、FAとHAがFA-HAモビリティセキュリティアソシエーションを参照するために使用するセキュリティパラメータインデックスが含まれています。 HAはSPIを割り当てます。また、[MOBILEIP]で定義されている予約済みの名前空間であるゼロ（0）から255の間の値を持つことはできません。
The MIP-Nonce AVP (AVP Code 335) is of type OctetString and contains the nonce sent to the mobile node for the associated authentication extension. The mobile node follows the procedures in [MIPKEYS] to generate the session key used to authenticate Mobile IPv4 registration messages. The HAAA selects the nonce.
MIP-Nonce AVP（AVPコード335）はOctetStringタイプであり、関連する認証拡張のためにモバイルノードに送信されたナンスが含まれています。 モバイルノードは、[MIPKEYS]の手順に従って、モバイルIPv4登録メッセージの認証に使用されるセッションキーを生成します。 HAAAはナンスを選択します。
The MIP-MSA-Lifetime AVP (AVP Code 367) is of type Unsigned32 and represents the period of time (in seconds) for which the session key or nonce is valid. The associated session key or nonce, as the case may be, MUST NOT be used if the lifetime has expired; if the session key or nonce lifetime expires while the session to which it applies is still active, either the session key or nonce MUST be changed or the association Mobile IPv4 session MUST be terminated.
MIP-MSA-Lifetime AVP（AVPコード367）はUnsigned32タイプで、セッションキーまたはナンスが有効な期間（秒単位）を表します。 場合によっては、関連するセッションキーまたはナンスは、ライフタイムが期限切れになった場合に使用してはなりません。 適用するセッションがまだアクティブである間にセッションキーまたはナンスのライフタイムが期限切れになった場合、セッションキーまたはナンスを変更するか、アソシエーションモバイルIPv4セッションを終了する必要があります。
The MIP-HA-to-FA-SPI AVP (AVP Code 323) is of type Unsigned32 and contains the Security Parameter Index the HA and FA use to refer to the HA-FA mobility security association. The FA allocates the SPI, and it MUST NOT have a value between zero (0) and 255, which is the reserved namespace defined in [MOBILEIP].
MIP-HA-to-FA-SPI AVP（AVPコード323）は、タイプUnsigned32であり、HAおよびFAがHA-FAモビリティセキュリティアソシエーションを参照するために使用するセキュリティパラメータインデックスが含まれています。 FAはSPIを割り当てます。また、[MOBILEIP]で定義された予約済みの名前空間であるゼロ（0）から255の間の値を持つことはできません。
The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64, and contains the number of octets in IP packets received from the user. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.
Accounting-Input-Octets AVP（AVP Code 363）は、Unsigned64タイプで、ユーザーから受信したIPパケットのオクテット数を含みます。 このAVPはすべてのAccounting-Requestメッセージに含まれなければならず、対応するAccounting-Answerメッセージにも存在する場合があります。
The Accounting-Output-Octets AVP (AVP Code 364) is of type Unsigned64 and contains the number of octets in IP packets sent to the user. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.
Accounting-Output-Octets AVP（AVP Code 364）はUnsigned64タイプで、ユーザーに送信されたIPパケットのオクテット数を含みます。 このAVPはすべてのAccounting-Requestメッセージに含まれなければならず、対応するAccounting-Answerメッセージにも存在する場合があります。
The Acct-Time AVP (AVP Code 46) is of type Unsigned32 and indicates the length of the current session in seconds. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.
Acct-Time AVP（AVP Code 46）はUnsigned32タイプで、現在のセッションの長さを秒単位で示します。 このAVPはすべてのAccounting-Requestメッセージに含まれなければならず、対応するAccounting-Answerメッセージにも存在する場合があります。
The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64 and contains the number of IP packets received from the user. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.
Accounting-Input-Packets（AVP Code 365）はUnsigned64タイプで、ユーザーから受信したIPパケットの数が含まれています。 このAVPはすべてのAccounting-Requestメッセージに含まれなければならず、対応するAccounting-Answerメッセージにも存在する場合があります。
The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64 and contains the number of IP packets sent to the user. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.
Accounting-Output-Packets（AVP Code 366）はUnsigned64タイプで、ユーザーに送信されたIPパケットの数が含まれています。 このAVPはすべてのAccounting-Requestメッセージに含まれなければならず、対応するAccounting-Answerメッセージにも存在する場合があります。
The Event-Timestamp (AVP Code 55) is of type Time and MAY be included in an Accounting-Request message to record the time at which this event occurred on the mobility agent, in seconds since January 1, 1970, 00:00 UTC.
Event-Timestamp（AVP Code 55）はTime型であり、1970年1月1日00:00 UTCからの秒数で、モビリティエージェントでこのイベントが発生した時刻を記録するためにAccounting-Requestメッセージに含めることができます。
The following tables present the AVPs defined in this document and their occurrences in Diameter messages. Note that AVPs that can only be present within a Grouped AVP are not represented in this table.
次の表は、このドキュメントで定義されているAVPとDiameterメッセージでの発生を示しています。 グループ化されたAVP内にのみ存在できるAVPは、このテーブルには表されていないことに注意してください。
The table uses the following symbols:
この表では、次の記号を使用しています。
0 The AVP MUST NOT be present in the message.
0+ Zero or more instances of the AVP MAY be present in the
message.
0 - 1 Zero or one instance of the AVP MAY be present in the
message.
1 One instance of the AVP MUST be present in the message.
The table in this section is limited to the Command Codes defined in this specification.
このセクションの表は、この仕様で定義されているコマンドコードに限定されています。
+-----------------------+
| Command-Code |
|-----+-----+-----+-----+
Attribute Name | AMR | AMA | HAR | HAA |
------------------------------|-----+-----+-----+-----+
Authorization-Lifetime | 0-1 | 0-1 | 1 | 0 |
Auth-Application-Id | 1 | 1 | 1 | 1 |
Auth-Session-State | 0-1 | 0-1 | 1 | 0 |
Acct-Multi-Session-Id | 0-1 | 0-1 | 0 | 0-1 |
Destination-Host | 0-1 | 0 | 0-1 | 0 |
Destination-Realm | 1 | 0 | 1 | 0 |
Error-Message | 0 | 0-1 | 0 | 0-1 |
Error-Reporting-Host | 0 | 0-1 | 0 | 0-1 |
MIP-Candidate-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 |
MIP-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 |
MIP-Originating-Foreign-AAA | 0-1 | 0 | 0-1 | 0 |
MIP-FA-Challenge | 0-1 | 0 | 0 | 0 |
MIP-FA-to-MN-MSA | 0 | 0-1 | 0 | 0 |
MIP-FA-to-HA-MSA | 0 | 0-1 | 0 | 0 |
MIP-HA-to-FA-MSA | 0 | 0 | 0-1 | 0 |
MIP-HA-to-MN-MSA | 0 | 0-1 | 0-1 | 0 |
MIP-MN-to-FA-MSA | 0 | 0 | 0-1 | 0 | MIP-MN-to-HA-MSA | 0 | 0-1 | 0-1 | 0 | MIP-FA-to-HA-SPI | 0 | 0 | 0 | 0-1 | MIP-HA-to-FA-SPI | 0 | 0 | 0 | 0-1 |
MIP-MN-to-FA-MSA | 0 | 0 | 0-1 | 0 | MIP-MN-to-HA-MSA | 0 | 0-1 | 0-1 | 0 | MIP-FA-to-HA-SPI | 0 | 0 | 0 | 0-1 | MIP-HA-to-FA-SPI | 0 | 0 | 0 | 0-1 |
MIP-FA-to-MN-SPI | 0 | 0 | 0 | 0-1 | MIP-MN-to-FA-SPI | 0 | 0 | 0 | 0-1 |
MIP-FA-to-MN-SPI | 0 | 0 | 0 | 0-1 | MIP-MN-to-FA-SPI | 0 | 0 | 0 | 0-1 |
MIP-HA-to-MN-SPI | 0 | 0 | 0 | 0-1 |
MIP-MN-to-HA-SPI | 0 | 0 | 0 | 0-1 |
MIP-Feature-Vector | 0-1 | 0-1 | 1 | 0 |
MIP-Filter-Rule | 0 | 0+ | 0+ | 0 |
MIP-Home-Agent-Address | 0-1 | 0-1 | 0-1 | 0-1 |
MIP-MSA-Lifetime | 0 | 0-1 | 0-1 | 0 |
MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 |
MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 |
MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 |
MIP-Reg-Request | 1 | 0 | 1 | 0 |
Origin-Host | 1 | 1 | 1 | 1 |
Origin-Realm | 1 | 1 | 1 | 1 |
Origin-State-Id | 0-1 | 0-1 | 0-1 | 0-1 |
Proxy-Info | 0+ | 0+ | 0+ | 0+ |
Redirect-Host | 0 | 0+ | 0 | 0+ |
Redirect-Host-Usage | 0 | 0-1 | 0 | 0-1 |
Redirect-Max-Cache-Time | 0 | 0-1 | 0 | 0-1 |
Result-Code | 0 | 1 | 0 | 1 |
Re-Auth-Request-Type | 0 | 0-1 | 0 | 0 |
Route-Record | 0+ | 0 | 0+ | 0 |
Session-Id | 1 | 1 | 1 | 1 |
User-Name | 1 | 0-1 | 1 | 0-1 |
------------------------------|-----+-----+-----+-----|
The table in this section is used to represent which AVPs defined in this document are to be present in the Accounting messages, as defined in [DIAMBASE].
このセクションの表は、[DIAMBASE]で定義されているように、このドキュメントで定義されているどのAVPがアカウンティングメッセージに存在するかを表すために使用されます。
+-------------+
| Command-Code|
|------+------+
Attribute Name | ACR | ACA |
-------------------------------------|------+------+
Accounting-Input-Octets | 1 | 0-1 |
Accounting-Input-Packets | 1 | 0-1 |
Accounting-Output-Octets | 1 | 0-1 |
Accounting-Output-Packets | 1 | 0-1 |
Acct-Multi-Session-Id | 1 | 0-1 |
Acct-Session-Time | 1 | 0-1 |
MIP-Feature-Vector | 1 | 0-1 |
MIP-Home-Agent-Address | 1 | 0-1 |
MIP-Mobile-Node-Address | 1 | 0-1 |
Event-Timestamp | 0-1 | 0 |
-------------------------------------|------+------+
This section contains the namespaces that have either been created in this specification or had their values assigned to existing namespaces managed by IANA.
このセクションには、この仕様で作成されたネームスペース、またはIANAによって管理される既存のネームスペースに値が割り当てられたネームスペースが含まれます。
This specification assigns the values 260 and 262 from the Command Code namespace defined in [DIAMBASE]. See section 5 for the assignment of the namespace in this specification.
この仕様は、[DIAMBASE]で定義されたコマンドコード名前空間から値260および262を割り当てます。 この仕様の名前空間の割り当てについては、セクション5を参照してください。
This specification assigns the values 318 - 348 and 363 - 367 from the AVP Code namespace defined in [DIAMBASE]. See sections 7, 9, and 10 for the assignment of the namespace in this specification.
この仕様は、[DIAMBASE]で定義されたAVP Code名前空間から値318-348および363-367を割り当てます。 この仕様の名前空間の割り当てについては、セクション7、9、および10を参照してください。
This specification assigns the values 4005 - 4008 and 5024 - 5025 from the Result-Code AVP (AVP Code 268) value namespace defined in [DIAMBASE]. See section 6 for the assignment of the namespace in this specification.
この仕様は、[DIAMBASE]で定義された結果コードAVP（AVPコード268）値名前空間から値4005〜4008および5024〜5025を割り当てます。 この仕様の名前空間の割り当てについては、セクション6を参照してください。
There are 32 bits in the MIP-Feature-Vector AVP (AVP Code 337) that are available for assignment. This document assigns bits 1 - 9, as listed in section 7.5. The remaining bits should only be assigned via Standards Action [IANA].
MIP-Feature-Vector AVP（AVPコード337）には、割り当てに使用できる32ビットがあります。 このドキュメントは、セクション7.5にリストされているように、ビット1-9を割り当てます。 残りのビットは、Standards Action [IANA]を介してのみ割り当てる必要があります。
As defined in section 9.8, the MIP-Algorithm-Type AVP (AVP Code 345) defines the value 2. All remaining values, except zero, are available for assignment via Designated Expert [IANA].
セクション9.8で定義されているように、MIPアルゴリズムタイプAVP（AVPコード345）は値2を定義します。ゼロを除く残りの値はすべて、Designated Expert [IANA]を介した割り当てに使用できます。
As defined in section 9.9, the MIP-Replay-Mode AVP (AVP Code 346) defines the values 1 - 3. All remaining values, except zero, are available for assignment via Designated Expert [IANA].
セクション9.9で定義されているように、MIP-Replay-Mode AVP（AVPコード346）は1〜3の値を定義します。ゼロ以外の残りの値はすべて、Designated Expert [IANA]を介した割り当てに使用できます。
This specification uses the value two (2) to the Application Identifier namespace defined in [DIAMBASE]. See section 4 for more information.
この仕様は、[DIAMBASE]で定義されたApplication Identifier名前空間に値2を使用します。 詳細については、セクション4を参照してください。
This specification describes a Mobile IPv4 Diameter Application for authenticating and authorizing a Mobile IPv4 mobile node. The authentication algorithm used is dependent on the transforms used within the Mobile IPv4 protocol, and [MIPCHAL]. This specification, in conjunction with [MIPKEYS], also defines a method by which the home Diameter server can create and distribute session keys and nonces for use in authenticating and integrity-protecting Mobile IPv4 registration messages [MOBILEIP]. The key distribution is asymmetric, as communication with the mobile node occurs via the Mobile IPv4 protocol [MIPKEYS, MOBILEIP], where as communication to the Home Agent and Foreign Agent occurs via the Diameter protocol. Where untrusted Diameter agents are present, end-to-end security MUST be used. The end-to-end security takes the form of TLS or IPSec security associations between the AAAH and the FA and between the AAAH and the HA. These connections will be authenticated with the use of public keys and certificates; however, the identities that appear in the certificates must be authorized and bound to a particular Mobile IPv4 Diameter session before the AAAH can safely begin distribution of keys.
この仕様では、モバイルIPv4モバイルノードを認証および承認するためのモバイルIPv4 Diameterアプリケーションについて説明します。使用される認証アルゴリズムは、モバイルIPv4プロトコル内で使用される変換、および[MIPCHAL]に依存します。この仕様は、[MIPKEYS]と組み合わせて、ホームDiameterサーバーが、モバイルIPv4登録メッセージ[MOBILEIP]の認証および整合性保護に使用するセッションキーとノンスを作成および配布できる方法も定義します。モバイルノードとの通信はモバイルIPv4プロトコル[MIPKEYS、MOBILEIP]を介して行われるため、ホームエージェントおよび外部エージェントとの通信はDiameterプロトコルを介して行われるため、キーの配布は非対称です。信頼できないDiameterエージェントが存在する場合、エンドツーエンドセキュリティを使用する必要があります。エンドツーエンドセキュリティは、AAAHとFAの間、およびAAAHとHAの間のTLSまたはIPSecセキュリティアソシエーションの形式を取ります。これらの接続は、公開鍵と証明書を使用して認証されます。ただし、証明書に表示されるIDは、AAAHが安全にキーの配布を開始する前に、認証され、特定のモバイルIPv4 Diameterセッションにバインドされる必要があります。
Note that the direct connections are established as a result of Diameter redirect messages. For example, in Figure 3, the FA gets a redirect response containing the Redirect-Host AVP of the AAAH. This is the identity that should be matched against the certificate presented by the AAAH when the secure connection is established. In this case, the network of Diameter proxies and redirect agents is trusted with the task of returning the correct AAAH identity to the FA.
Diameterリダイレクトメッセージの結果として、直接接続が確立されることに注意してください。 たとえば、図3では、FAはAAAHのRedirect-Host AVPを含むリダイレクト応答を取得します。 これは、安全な接続が確立されたときにAAAHによって提示された証明書と照合する必要があるIDです。 この場合、Diameterプロキシとリダイレクトエージェントのネットワークは、正しいAAAH IDをFAに返すタスクで信頼されます。
The AAAH must also make an authorization decision when the FA establishes the connection. If the AAAH and the redirect server are one and the same, then the AAAH may have observed and noted the original AMR message that contained the identity of the FA and so may authorize the establishment of a TLS or IPSec connection from the same entity. Otherwise, the AAAH would need to maintain a list of all authorized visited domains (roaming partners) and authorize TLS or IPSec connections based on this list. Note that establishment of the connection is only the first step, and the AAAH has another opportunity to deny service upon receipt of the AMR message itself. At this step, the AAAH can check the internal AVPs of the AMR to ensure that the FA is valid; for example, it can check that the Mobile IP COA is equal to the IP address used as the endpoint of the TLS or IPSec connection. However, such a policy would prevent the FA from using different interfaces for AAA and Mobile IP tunnel packets and may not be desirable in every deployment situation.
AAAHは、FAが接続を確立するときに承認決定も行う必要があります。 AAAHとリダイレクトサーバーが同一である場合、AAAHはFAのIDを含む元のAMRメッセージを観察して記録しているため、同じエンティティからのTLSまたはIPSec接続の確立を許可する可能性があります。それ以外の場合、AAAHはすべての許可された訪問済みドメイン（ローミングパートナー）のリストを保持し、このリストに基づいてTLSまたはIPSec接続を許可する必要があります。接続の確立は最初のステップに過ぎず、AAAHにはAMRメッセージ自体の受信時にサービスを拒否する別の機会があることに注意してください。このステップで、AAAHはAMRの内部AVPをチェックして、FAが有効であることを確認できます。たとえば、モバイルIP COAがTLSまたはIPSec接続のエンドポイントとして使用されるIPアドレスと等しいことを確認できます。ただし、このようなポリシーは、FAがAAAおよびモバイルIPトンネルパケットに異なるインターフェイスを使用するのを防ぐため、すべての展開状況で望ましいとは限りません。
A similar set of considerations applies to the connection between AAAH and HA when those entities are in different administrative domains. However, here the roles are reversed because it is the AAAH that contacts the HA via the HAR. The identity of the candidate HA is given to the AAAH in the AMR, and the AAAH should expect to receive the same identity in the public key certificates during TLS or IPSec negotiation. The HA may authorize individual connections by acting as its own redirect server, or it may maintain a list of trusted roaming partners.
エンティティが異なる管理ドメインにある場合、AAAHとHA間の接続にも同様の考慮事項が適用されます。 ただし、ここでは、HARを介してHAに接続するのはAAAHであるため、役割が逆になっています。 候補HAのIDはAMRのAAAHに与えられ、AAAHはTLSまたはIPSecネゴシエーション中に公開鍵証明書で同じIDを受信することを期待する必要があります。 HAは、独自のリダイレクトサーバーとして機能することで個々の接続を許可するか、信頼できるローミングパートナーのリストを保持します。
This application creates and distributes a single session key for each pair of MSAs between two entities; e.g., the same session key is used for the MN-HA MSA and the HA-MN MSA. This is safe to do from a security perspective, as the session keys are only used with keyed hash functions to generate authenticator values that protect the integrity of each Mobile IP control message. Mobile IP messages have built-in replay protection with the use of timestamps or nonces [MOBILEIP], and, due to the nature of the protocol, requests are always different bitwise from responses, at least in the message type code. This avoids problems that might arise in other situations where an attacker could mount a replay or reflection attack if the same key were used (for example) to encrypt otherwise unprotected traffic on more than one connection leg in the network.
このアプリケーションは、2つのエンティティ間のMSAのペアごとに1つのセッションキーを作成して配布します。 たとえば、MN-HA MSAとHA-MN MSAに同じセッションキーが使用されます。 セッションキーはキー付きハッシュ関数でのみ使用され、各モバイルIP制御メッセージの整合性を保護する認証値を生成するため、これはセキュリティの観点から安全です。 モバイルIPメッセージには、タイムスタンプまたはノンス[MOBILEIP]を使用したリプレイ保護が組み込まれています。プロトコルの性質上、少なくともメッセージタイプコードでは、要求は常にビット単位で応答と異なります。 これにより、ネットワーク内の複数の接続レッグで保護されていないトラフィックを暗号化するために同じキーが使用された場合に、攻撃者がリプレイまたはリフレクション攻撃を仕掛ける可能性がある他の状況で発生する可能性のある問題を回避できます。
Nonces are sent to the mobile node, which are used to generate the session keys via the HMAC-SHA-1 one-way function. Because the nonces and authentication extensions may be observed by anyone with access to a clear-text copy of the Registration Reply, the pre-shared key between the mobile node and the home Diameter server would be vulnerable to an offline dictionary attack if it did not contain enough entropy. To prevent this, the pre-shared key between the mobile node and the home Diameter server SHOULD be a randomly chosen quantity of at least 96 bits.
ノンスはモバイルノードに送信され、HMAC-SHA-1一方向機能を介してセッションキーを生成するために使用されます。 登録応答のクリアテキストコピーにアクセスできる人は誰でもナンスと認証拡張機能を監視できるため、モバイルノードとホームDiameterサーバー間の事前共有キーはオフライン辞書攻撃に対して脆弱です。 十分なエントロピーが含まれています。 これを防ぐために、モバイルノードとホームDiameterサーバー間の事前共有キーは、少なくとも96ビットのランダムに選択された量にする必要があります。
Because the session key is determined by the long-term secret and the nonce, the nonce SHOULD be temporally and globally unique; if the nonce were to repeat, then so would the session key. To prevent this, a nonce is strongly recommended to be a random [RANDOM] value of at least 128 bits. The long-term secret between the MN and AAAH MUST be refreshed periodically, to guard against recovery of the long-term secret due to nonce reuse or other factors. This is accomplished by using out-of-band mechanisms, which are not specified in this document.
セッションキーは長期のシークレットとナンスによって決定されるため、ナンスは時間的およびグローバルに一意である必要があります。 ナンスが繰り返されると、セッションキーも繰り返されます。 これを防ぐために、ナンスは少なくとも128ビットのランダムな[RANDOM]値にすることを強くお勧めします。 一回限りの再利用または他の要因による長期的な秘密の回復を防ぐために、MNとAAAH間の長期的な秘密を定期的に更新する必要があります。 これは、このドキュメントで指定されていない帯域外メカニズムを使用して実現されます。
Note that it is not recommended to set the MIP-MSA-Lifetime AVP value to zero, as keeping session keys for a long time (no refresh) increases the level of vulnerability.
MIP-MSA-Lifetime AVP値をゼロに設定することは推奨されないことに注意してください。セッションキーを長時間保持（更新なし）すると脆弱性のレベルが高まるためです。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF] Crocker、D。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、RFC 2234、1997年11月。
[DIAMBASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[DIAMBASE] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「Diameter Base Protocol」、RFC 3588、2003年9月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA] Narten、T。、およびH. Alvestrand、「RFCでIANA考慮事項セクションを記述するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[MOBILEIP] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[MOBILEIP] Perkins、C。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[MIPCHAL] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response Extensions", RFC 3012, November 2000.
[MIPCHAL] Perkins、C.、P。Calhoun、「モバイルIPv4チャレンジ/レスポンス拡張」、RFC 3012、2000年11月。
[NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[NAI] Aboba、B。、およびM. Beadles、「ネットワークアクセス識別子」、RFC 2486、1999年1月。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキー付きハッシュ」、RFC 2104、1997年2月。
[MIPKEYS] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IP", RFC 3957, March 2005.
[MIPKEYS] Perkins、C.、P。Calhoun、「モバイルIPの認証、承認、アカウンティング（AAA）登録キー」、RFC 3957、2005年3月。
[AAANAI] Johansson, F. and T. Johansson, "Mobile IPv4 Extension for Carrying Network Access Identifiers", RFC 3846, June 2004.
[AAANAI]ヨハンソン、F。、およびT.ヨハンソン、「ネットワークアクセス識別子を運ぶためのモバイルIPv4拡張」、RFC 3846、2004年6月。
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC]ケント、S.、R。アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[TLS] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003.
[TLS] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 3546、2003年6月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[MIPREQ] Glass, S., Hiller, T., Jacobs, S., and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.
[MIPREQ] Glass、S.、Hiller、T.、Jacobs、S。、およびC. Perkins、「モバイルIP認証、許可、およびアカウンティング要件」、RFC 2977、2000年10月。
[CDMA2000] Hiller, T., Walsh, P., Chen, X., Munson, M., Dommety, G., Sivalingham, S., Lim, B., McCann, P., Shiino, H., Hirschman, B., Manning, S., Hsu, R., Koo, H., Lipford, M., Calhoun, P., Lo, C., Jaques, E., Campbell, E., Xu, Y., Baba, S., Ayaki, T., Seki, T., and A. Hameed, "CDMA2000 Wireless Data Requirements for AAA", RFC 3141, June 2001.
[CDMA2000] Hiller、T.、Walsh、P.、Chen、X.、Munson、M.、Dommety、G.、Sivalingham、S.、Lim、B.、McCann、P.、Shiino、H.、Hirschman、 B.、Manning、S.、Hsu、R.、Koo、H.、Lipford、M.、Calhoun、P.、Lo、C.、Jaques、E.、Campbell、E.、Xu、Y.、Baba、 S.、Ayaki、T.、Seki、T。、およびA. Hameed、「AAAのCDMA2000ワイヤレスデータ要件」、RFC 3141、2001年6月。
[EVALROAM] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
[EVALROAM] Aboba、B。、およびG. Zorn、「ローミングプロトコルの評価基準」、RFC 2477、1999年1月。
[MIPNAI] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[MIPNAI]カルホーン、P。およびC.パーキンス、「IPv4のモバイルIPネットワークアクセス識別子拡張」、RFC 2794、2000年3月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[ランダム] Eastlake、D.、3rd、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、June 2005。
The authors would like to thank Nenad Trifunovic, Haseeb Akhtar, and Pankaj Patel for their participation in the pre-IETF Document Reading Party; Erik Guttman for his very useful proposed text; and to Fredrik Johansson, Martin Julien, and Bob Kopacz for their very useful contributed text.
著者は、IETF以前の文書読書会への参加について、Nenad Trifunovic、Haseeb Akhtar、およびPankaj Patelに感謝します。 エリック・ガットマンは、非常に有用な提案されたテキストに対して。 そして、非常に有用な寄稿テキストについて、Fredrik Johansson、Martin Julien、およびBob Kopaczに感謝します。
The authors would also like to thank the participants of 3GPP2's TSG-X working group for their valuable feedback, and the following people for their contribution in the development of the protocol: Kevin Purser, Thomas Panagiotis, Mark Eklund, Paul Funk, Michael Chen, Henry Haverinen, and Johan Johansson. General redirect server text due to Pasi Eronen was borrowed from Diameter-EAP.
また、著者は、3GPP2のTSG-Xワーキンググループの参加者の貴重なフィードバックに感謝し、プロトコルの開発に貢献してくれた次の人々に感謝します。KevinPurser、Thomas Panagiotis、Mark Eklund、Paul Funk、Michael Chen、 ヘンリーハヴェリネン、ヨハンヨハンソン。 Pasi Eronenによる一般的なリダイレクトサーバーテキストはDiameter-EAPから借用されました。
Pat Calhoun would like to thank Sun Microsystems, as most of the effort put into this document was done while he was in their employ.
パットカルホーンは、Sun Microsystemsに感謝します。このドキュメントに費やされたほとんどの努力は、彼が雇用されている間に行われたものです。
Authors' Addresses
著者のアドレス
Questions about this memo can be directed to:
このメモに関する質問は次の宛先に送信できます。
Pat Calhoun Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Pat Calhoun Cisco Systems、Inc. 170 West Tasman Drive San Jose、CA 95134 USA
Phone: +1 408-853-5269 EMail: pcalhoun@cisco.com
電話：+1 408-853-5269電子メール：pcalhoun@cisco.com
Tony Johansson Bytemobile, Inc. 2029 Stierlin Court Mountain View, CA 94043
Tony Johansson Bytemobile、Inc. 2029 Stierlin Court Mountain View、CA 94043
Phone: +1 650-641-7817 Fax: +1 650-641-7701 EMail: tony.johansson@bytemobile.com
電話：+1 650-641-7817ファックス：+1 650-641-7701電子メール：tony.johansson@bytemobile.com
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA
チャールズE.パーキンスノキアリサーチセンター313 Fairchild Drive Mountain View、CA 94043 USA
Phone: +1 650-625-2986 Fax: +1 650-625-2502 EMail: Charles.Perkins@nokia.com
電話：+1 650-625-2986ファックス：+1 650-625-2502メール：Charles.Perkins@nokia.com
Tom Hiller Lucent Technologies 1960 Lucent Lane Naperville, IL 60566 USA
Tom Hiller Lucent Technologies 1960 Lucent Lane Naperville、IL 60566 USA
Phone: +1 630-979-7673 EMail: tomhiller@lucent.com
電話：+1 630-979-7673メール：tomhiller@lucent.com
Peter J. McCann Lucent Technologies 1960 Lucent Lane Naperville, IL 60563 USA
Peter J. McCann Lucent Technologies 1960 Lucent Lane Naperville、IL 60563アメリカ合衆国
Phone: +1 630-713-9359 Fax: +1 630-713-1921 EMail: mccap@lucent.com
電話：+1 630-713-9359ファックス：+1 630-713-1921メール：mccap@lucent.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、制限の対象となります。また、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本書および本書に含まれる情報は「現状のまま」提供され、寄稿者、代表者または代表者（もしあれば）、インターネット協会、インターネットエンジニアリングタスクフォースはすべての保証を放棄します 黙示的であるが、ここに記載されている情報の使用が商品性または特定の目的への適合性の黙示的保証を侵害しないという保証に限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書に記載されている技術の実装または使用に関連すると主張される可能性のある知的財産権またはその他の権利の有効性または範囲、またはそのような権利の下でのライセンスの有無に関して、立場をとりません。 利用可能 また、そのような権利を特定するための独立した努力を行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（http://www.ietf.org/ipr）から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この標準を実装するために必要な技術を対象とする著作権、特許、特許出願、またはその他の所有権に関心を寄せるよう、あらゆる利害関係者を招待します。 IETFのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。