RFC4004 日本語訳
4004 Diameter Mobile IPv4 Application. P. Calhoun, T. Johansson, C.Perkins, T. Hiller, Ed., P. McCann. August 2005. (Format: TXT=128210 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループ要求をネットワークでつないでください: 4004年のP.カルフーンカテゴリ: 規格はP.マッキャンルーセントテクノロジーズ2005年8月にシスコシステムズのInc.T.ヨハンソン・Bytemobile Inc C.パーキンス・ノキアのリサーチセンターT.ヒラー(エド)を追跡します。
Diameter Mobile IPv4 Application
直径のモバイルIPv4アプリケーション
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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サーバが課金情報を認証して、認可して、集めるDiameterアプリケーションを、可動のノードに提供されたモバイルIPv4サービスに指定します。 ベースプロトコルのInter-分野能力に結合されています、このアプリケーションで、可動のノードは外国サービスプロバイダーからサービスを受けることができます。 直径Accountingメッセージは、用法情報を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
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. 実体と関係。 . . . . . . . . . . . . . . . 4 1.2. 移動性セキュリティ協会。 . . . . . . . . . . . . . 4 1.3. 移管. . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4。 ドキュメント. . . . . . . . . . . . . . . . 7 2の構造。 頭文字語… 7 3。 シナリオとメッセージ流れ. . . . . . . . . . . . . . . . . . 7 3.1。 相互分野のモバイルIPv4. . . . . . . . . . . . . . . . . 8
Calhoun, et al. Standards Track [Page 1] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[1ページ]。
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
3.2. 外国ネットワーク. . . . . . .13 3.3における、ホームのエージェントの配分。 共同見つけられたモバイルノード。 . . . . . . . . . . . . . . . . .16 3.4. 主要な分配。 . . . . . . . . . . . . . . . . . . . .18 4. 直径プロトコル問題。 . . . . . . . . . . . . . . .20 4.1. 直径セッション管理. . . . . . . . . . . . . . .20 5。 コマンドコード値. . . . . . . . . . . . . . . . . . . . . .23 5.1。 AAのモバイルノード要求。 . . . . . . . . . . . . . . . . .23 5.2. AAのモバイルノード答え.255.3。 MIPが要求するホームのエージェント。 . . . . . . . . . . . . . . . . .26 5.4. ホームエージェントMIP答え.276。 結果コードAVP値。 . . . . . . . . . . . . . . . . . . . .27 6.1. 一時障害。 . . . . . . . . . . . . . . . . . . .28 6.2. 永久的な失敗。 . . . . . . . . . . . . . . . . . . .28 7. 義務的なAVPs。 . . . . . . . . . . . . . . . . . . . . . . . .28 7.1. MIPレッジRequest AVP. . . . . . . . . . . . . . . . . . .29 7.2。 MIPレッジReply AVP. . . . . . . . . . . . . . . . . . . .29 7.3。 MIPのモバイルノードアドレスAVP. . . . . . . . . . . . . . .30 7.4。 MIPホームエージェントアドレスAVP。 . . . . . . . . . . . . . . .30 7.5. MIP特徴ベクトルAVP。 . . . . . . . . . . . . . . . . .30 7.6. MIP Mn AAA Auth AVP.7.7。 MIPファ挑戦AVP。 . . . . . . . . . . . . . . . . . .33 7.8. MIPフィルタ規則AVP. . . . . . . . . . . . . . . . . . .33 7.9。 MIP候補ホームエージェントのホスト.7.10。 MIPの由来している外国AAA AVP. . . . . . . . . . . . .33 7.11。 MIPホームエージェントのホストAVP. . . . . . . . . . . . . . . . .33 8。 主要な分配. . . . . . . . . . . . . . . . . . . . . . .34 8.1。 認可生涯対MIPの主要な生涯 . . . . . . .34 8.2. 一回だけ対セッションキー . . . . . . . . . . . . . . . . . .35 8.3. 移動住宅セッションキー. . . . . . . . .35 8.4を分配します。 モバイルに外国のセッションキーを分配します。 . . . . . . .36 8.5. 外国ホームセッションキーを分配します。 . . . . . . . .37 9. 主要な分配AVPs. . . . . . . . . . . . . . . . . . . . .38 9.1。 MIPファからMn MSA AVP。 . . . . . . . . . . . . . . . . . .39 9.2. ハ、MSA AVPへのMIPファ。 . . . . . . . . . . . . . . . . . .39 9.3. MIP、ファMSA AVP、ハ。 . . . . . . . . . . . . . . . . . .40 9.4. MIP、Mn MSA AVP、ハ。 . . . . . . . . . . . . . . . . . .40 9.5. MIPミネソタからファMSA AVP。 . . . . . . . . . . . . . . . . . .40 9.6. ハ、MSA AVPへのMIPミネソタ。 . . . . . . . . . . . . . . . . . .41 9.7. MIPセッションキーAVP. . . . . . . . . . . . . . . . . . .41 9.8。 MIPアルゴリズムタイプAVP。 . . . . . . . . . . . . . . . . .41 9.9. MIP再生モードAVP. . . . . . . . . . . . . . . . . . .42 9.10。 MIPファからMn SPI AVP。 . . . . . . . . . . . . . . . . . .42 9.11. ハ、SPI AVPへのMIPファ。 . . . . . . . . . . . . . . . . . .42 9.12. MIP-一回だけAVP。 . . . . . . . . . . . . . . . . . .. . . .42 9.13. MIP-MSA-生涯AVP… . . .42 9.14. MIP、ファSPI AVP、ハ、… . . .43 10. AVPs. . . . . . . . . . . . . . . . . . . . . . . .43 10.1を説明します。 会計入力八重奏AVP. . . . . . . . . . . . . . .43
Calhoun, et al. Standards Track [Page 2] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[2ページ]。
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
10.2. 会計出力八重奏AVP。 . . . . . . . . . . . . . .43 10.3. Acctセッション時間AVP. . . . . . . . . . . . . . . . . .43 10.4。 会計入力パケットAVP。 . . . . . . . . . . . . . .43 10.5. 会計出力パケットAVP. . . . . . . . . . . . . .43 10.6。 イベントタイムスタンプAVP. . . . . . . . . . . . . . . . . . .44 11。 AVP発生テーブル. . . . . . . . . . . . . . . . . . . . .44 11.1。 モバイルIPコマンドAVPは.44 11.2を見送ります。 AVPがテーブルであることを説明します。 . . . . . . . . . . . . . . . . . .46 12. IANA問題. . . . . . . . . . . . . . . . . . . . . .46 12.1。 コマンドコード. . . . . . . . . . . . . . . . . . . . . .46 12.2。 AVPは.46 12.3をコード化します。 結果コードAVP値。 . . . . . . . . . . . . . . . . .46 12.4. MIP特徴ベクトルAVPは.12.5を評価します。 MIPアルゴリズムタイプAVPは.12.6を評価します。 MIP再生モードAVP値。 . . . . . . . . . . . . . . .47 12.7. アプリケーション識別子. . . . . . . . . . . . . . . . .47 13。 セキュリティ問題. . . . . . . . . . . . . . . . . . . .47 14。 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . .49 14.1. 引用規格。 . . . . . . . . . . . . . . . . . .49 14.2. 有益な参照。 . . . . . . . . . . . . . . . . .50 15. 承認。 . . . . . . . . . . . . . . . . . . . . . . .51人の作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . . .51 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . . .53
1. Introduction
1. 序論
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]はモバイルNode(ミネソタ)に接着点をインターネットに変えさせます。 ホームアドレスに向けられたパケットを、ホームエージェント(HA)が妨害して、トンネルでカプセルに入れって、現在の接着点でミネソタに送ります。 任意に、Foreignエージェント(FA)はここに付属について配備されるかもしれません。(それは、トンネル終点として機能できて、また、訪問されたネットワークリンクにアクセス管理を供給するかもしれません)。 この役割では、FAはそれに付くかもしれない各ミネソタを認証しなければなりません、ミネソタが同じくらいか異なった管理ドメインからあるか否かに関係なく。 FAは、ミネソタが外国ドメインでリソースを添付して、使用するのが認可されることを確かめなければなりません。 また、それが外国ドメインで付けられている間、FAはリソースに関する管理ドメインがミネソタで使用した家に情報を供給しなければなりません。
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.
Authentication、Authorization、およびモバイルIPv4のためのAccounting(AAA)要件は他のドキュメント[MIPREQ、CDMA2000]で詳細に説明されます。 このドキュメントは、これらの必要条件を満たすためにDiameterアプリケーションを指定します。 このアプリケーションはモバイルIPv6プロトコルに適切ではありません。
Calhoun, et al. Standards Track [Page 3] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[3ページ]。
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.
メッセージ・フォーマット(例えば、セクション5.1のように)は、Attribute-値のペア(AVPs)のリストとしてRFC2234[ABNF]で説明されるように構文を使用することで指定されます。 これは、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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[キーワード]で説明されるように本書では解釈されることであるべきですか?
1.1. Entities and Relationships
1.1. 実体と関係
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 ApplicationはMNsに対するモバイルIPv4サービスを提供する際にHAとFAを支持します。 HAとFAの両方がDiameterクライアントとして作動します。 MNsはモバイル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を静的にであるダイナミックに家の管理のミネソタにドメインを割り当てるか、またはダイナミックに訪問された管理ドメインのミネソタに割り当てるかもしれません。 家のドメインは家のAAAサーバ(AAAH)を含んでいます、そして、訪問されたドメインは外国AAAサーバ(AAAF)を含んでいます。 ミネソタが「家」にあるとき(ホームネットワークで現在の)、AAAHとAAAFは同じであるかもしれません。
1.2. Mobility Security Associations
1.2. 移動性セキュリティ協会
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]はミネソタとHA(ミネソタ-HA MSA)の間のMobility Security Association(MSA)の存在を仮定します。 ミネソタ-HA MSAは、合わせられた細切れ肉料理スタイルアルゴリズムを使用することによってミネソタからHAに送られるモバイルIP Registration Requestを認証するのに使用されます。 -Registration Requestsを認証するのは重要であり、トンネルを堀られて、目的地は彼らがミネソタの現在のCareに関してHAに知らせるようにどれのためのアドレスの、ものであるか。ホームネットワークからのパケット。 認証がなければ、悪意がある攻撃者はインターネットでどこでもパケットを向け直すことができるでしょう。 MSAはMSAについて言及するのに使用されるSecurity Parameters Index(SPI、32ビットの数)の協定を包括して、合わせられた状態で計算するのに使用されるアルゴリズムはメッセージ、および共有された秘密鍵を論じ尽くします。 メッセージの認証を可能にするために、送付者はSPIを含むモバイルIP Authentication Extensionとメッセージの前の全体のコンテンツの上で合わせられた細切れ肉料理を動かすという結果を追加します。 受取人はSPIに基づくMSAを見上げることによって、Authentication Extensionをチェックします、合わせられた細切れ肉料理を再計算して、結果が容認されたAuthentication Extensionのコンテンツと等しいことを確かめて。
Calhoun, et al. Standards Track [Page 4] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[4ページ]。
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が議定書の中で述べるベースはミネソタとFA(ミネソタ-FA MSA)の間の任意のMSAを支持します。 利用可能であるなら、ミネソタ-FA MSAは、HAへの途中にそれを通り抜ける各Registration Requestを認証するのにFAによって使用されます。 ベースプロトコルの操作に重要ではありませんが、FAがRegistration Requestの信憑性を知らなければならないとき、ミネソタ-FA MSAは役に立ちます。 それが例えば、いつ会計を発生させるかはセッションのために記録します。 また、ミネソタ-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(FA-HA MSA)の間の任意のMSAを支持します。 FA-HA MSAはFAとHAの間のメッセージを認証することの役に立ちます、HAがモバイルIP登録を取り消したことをFAに知らせようとする時のように。
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.
FAsにかかわるMSAsの構成がミネソタとHAの間のものを構成するより実質的に難しいことに注意してください、しばしば同じ管理ドメインでミネソタとHAがそうであり、ミネソタが長期間の間、同じHAを保有するので。 対照的に、ミネソタは、時間がたつにつれて、多くのFAsに遭遇しそうであって、気付くと、外国管理ドメインにしばしばいるかもしれません。
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が議定書の中で述べるベースは、MNsが彼らの静的な家のIPアドレスによって特定されて、すべてのMSAsが静的にあらかじめ設定されると仮定します。 インターネットに付くとき、DiameterのモバイルIPv4アプリケーションは、モバイルIPv4が議定書の中で述べるベースへの拡大[MIPNAI、MIPCHAL、MIPKEYS、AAANAI]と共にミネソタがダイナミックにホームアドレス、そして/または、家のエージェントに割り当てられるのを許容します。 また、このセットの仕様はミネソタ-HA、ミネソタ-FA、およびFA-HA MSAsの動的設定を支持します。 これらの関係の動的設定は、ミネソタがそれとのプレ確立した関係を持っていなくて訪問されたネットワークに付くことができる展開を支持するために重要です。
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
初めは、ミネソタにはAAAHだけとの長期のAAAセキュリティ協会があると思われます。 MSAsのように、このセキュリティ協会は、ミネソタのNAIによって索引をつけられて、SPI、アルゴリズム、および共有された秘密鍵の協定を包括します。 モバイルIPv4 Registration Requestを送ることによって、ミネソタはいくらかのFAから訪問されたネットワークと要求サービスに入ります。 FAは、サービスを求める要求を認証して、認可するためにそれ自身の管理ドメインでAAAFに連絡します。 AAAFとAAAHは直接互いとのDiameter Redirectを通したなどDiameterセッションを確立するか、またはDiameterプロキシのネットワークを通してメッセージを通過するかもしれません。 AAAFとAAAHがダイレクト接続よりむしろプロキシを通してメッセージを互いに発送するところでは、他動な信用は想定されます。 MNsは、ミネソタを特定するために、モバイルIPv4 Registration Request[MIPNAI]の彼らのNetwork Access Identifier(NAI)を含むことができます。(IPv4 Registration Requestはホームアドレスに代わって役立ちます)。 NAIは、Diameterメッセージを正しさに発送するのに使用されます。
Calhoun, et al. Standards Track [Page 5] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[5ページ]。
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はミネソタ-AAAセキュリティ協会[MIPCHAL]の使用があるRegistration Requestを認証できます。 認証がうまくいくなら、AAAHはミネソタ、HA、およびFAにMSAsを発生して、分配します。 AAAHは、MSA組に、主要なセッションを引き出すためにミネソタ-AAAの共有されたキーと共にミネソタ(すなわち、ミネソタ-HA/HAミネソタMSAsとミネソタFA/FAミネソタMSAs)にかかわるMSA組各人と同じくらい、一回だけを発生させて、次に、それを論じ尽くします。 Registration Replyにそれらを含んでいるHAに一回だけを送ります。Registration Replyは、ミネソタが同じキー[MIPKEYS]を引き出すのを可能にします。 同時に、AAAHはミネソタHA/HAミネソタMSAsとFA-HA/HA-FA MSAsをHAに分配しなければならなくて、ミネソタFA/FAミネソタMSAsとFA-HA/HA-FA MSAsをFAに分配しなければなりません。 これらをDiameter AVPsで送って、IPSecかTLSを使用することによって、独自にAAAHとFAの間と、そして、AAAHとHAの間に安全にしなければなりません。 主要な派生と分配の詳しい情報に関してセクション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.
例えば、ミネソタ-HA MSA(以前はよくミネソタからHAまでの交通を保護していた)とHA-MN MSA(以前はよくHAからミネソタまでの交通を保護していた)が異なったSPIs、アルゴリズム、および共有秘密キーを使用できるのでモバイルIPにおけるMSAsが単方向であることに注意してください。 一般的な既存の習慣にもかかわらず、これはすべてのパラメタが両方の指示に同じ値に設定されるMSAsの手動の構成の間ベースのモバイルIPプロトコルに関して本当です。 このドキュメントは各指示に基づく異なったSPIsの使用を支持します。 しかしながら、それは2つのノードの間で各組のMSAsに、主要なただ一つのセッションの分配を支持するだけです。 セクション13でこのセキュリティ含意について議論します。 2つの実体の間のMSAsの組についてただ一つの共有秘密キーの分配とSPIsの組について言及するとき、このドキュメントは時々2つのものの1つだけを単方向MSAsと命名します。
1.3. Handoff
1.3. 移管
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.
また、ミネソタ-HA、ミネソタ-FA、およびFA-HA MSAsの派生と輸送を支持することに加えて、このアプリケーションはMIPv4移管を支持します。 ミネソタが1接着点から別の接着点まで動くとき、ミネソタは、その既存の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
ミネソタは、新しい接着点からモバイルIPv4 Registration Requestを送ることによって、これを達成します。 1セットの会計帳簿がhandoffsを含む全体のセッションのために維持されるのを可能にするために、AAAHが先在のセッションまで新規登録を縛るのを許容するのが必要です。 モバイルIPv4 Registration Requestが同じAAAH、MN SHOULDに発送されるのを可能にするために
Calhoun, et al. Standards Track [Page 6] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[6ページ]。
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.
そのような再登録証明書でAAAH NAI[AAANAI]を含めてください。 また、ミネソタの既存のHAにメッセージを発送するのにAAAHを助けるために、可動のノードSHOULDはそのような再登録証明書にHA NAI[AAANAI]を含んでいます。 可動のノードがモバイルIPv4AAA NAI拡張子[AAANAI]をサポートしないなら、この機能性は利用可能ではありません。
1.4. Structure of the Document
1.4. ドキュメントの構造
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基地のプロトコルと定義します。 セクション5は新しいコマンドコードを定義します。 セクション6はこのアプリケーションで使用される新しい結果コードを定義します。 セクション7は義務的なAttribute値のペア(AVPs)のセットを定義します。 セクション8は主要な分配能力の概観を与えます、そして、セクション9は主要な分配AVPsを定義します。 セクション10は会計AVPsを定義します、そして、セクション11はDiameterコマンドにおけるすべてのAVPsと彼らの発生のリストを含みます。 最終的に、セクション12と13はそれぞれIANAとセキュリティに問題を与えます。
2. Acronyms
2. 頭文字語
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のモバイルノード答えのアドレスの注意ファ外国エージェントFQDN AMR AAのモバイルノード要求ASRアボートセッション要求AVP属性値組CoA完全修飾ドメイン名モバイルホームの登録要求SPIセキュリティパラメタエージェントHAAホームエージェントMIP答えHARホームエージェントMIP要求MnノードMSA移動性セキュリティ協会NAIネットワークアクセス識別子RRQインデックスSTRがセッション終了要求であることを説明すること。
3. Scenarios and Message Flows
3. シナリオとメッセージ流れ
This section presents four scenarios illustrating Diameter Mobile IPv4 application and describes the operation of key distribution.
このセクションは、DiameterのモバイルIPv4アプリケーションを例証する4つのシナリオを提示して、主要な分配の操作について説明します。
Calhoun, et al. Standards Track [Page 7] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[7ページ]。
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を通して登録しない共同見つけられた可動のノードのための)のどちらかによって実行されます、そして、これらの用語は以下のシナリオで互換性を持って使用されるでしょう。
3.1. Inter-Realm Mobile IPv4
3.1. 相互分野のモバイルIPv4
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.
可動のノードが外国人のエージェントにRegistration Requestを発行することによってサービスを要求するとき、外国人のエージェントはAAモバイルのノード要求(AMR)メッセージを作成します。(それは、セクション7で定義されたAVPsを含んでいます)。 ホームAddress、ホームのエージェント、モバイルNode NAI、および他の重要な野原はDiameter AVPsとして可能な包含への登録メッセージから抽出されます。 そして、AAA外国として知られている、ローカルのDiameterサーバ、またはAAAFにAMRメッセージを転送します。
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
+--------+
訪問された分野ホーム分野+-----------+ +-----------+ |example.net| AMR/海部|example.org| | AAAF| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| AAAH| +->| サーバ| サーバサーバ| サーバ| | +-----------+ コミュニケーション+-----------+ | ^ ^ | AMR/海部| クライアント/サーバ| HAR/HAA| | コミュニケーション| v対+に---------+ +---------+ +---------+ | 外国| | 外国| | ホーム| | エージェント| | エージェント| | エージェント| +---------+ +---------+ +---------+ ^ | モバイルIP| +に対して--------+ | モバイル| | ノード| 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はAMRが局所的に処理されるべきであるかどうか決定するために[DIAMBASE]に概説されているか、またはAAAホーム、またはAAAHとして知られている別のDiameterサーバに送られた手順に従います。 図1は可動のノード( mn@example.org )が外国プロバイダー(example.net)からサービスを要求する例を示しています。 AAAFによって受け取られた要求をexample.orgのAAAHサーバに転送します。
Calhoun, et al. Standards Track [Page 8] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[8ページ]。
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インフラストラクチャを呼び出すときかかわるメッセージ流れを示しています。 可動からRegistration Requestが受け取られているときはいつも、外国人のエージェントがAAAサービスを呼び出すのが必要でないことに注意しますが、AAAHからの先の認可が期限が切れたらだけ、むしろ注意してください。 Authorization-生涯AVPを通して、認可の満了時間はAAAHからAAのモバイルノード答え(AMA; セクション5.2を見る)で伝えられます。
Mobile Node Foreign Agent AAAF AAAH Home
Agent
----------- ------------- ------------ ---------- -------
Advertisement &
<--------- Challenge
モバイルノード外国人のエージェントのAAAF AAAHホームのエージェント----------- ------------- ------------ ---------- ------- 広告と<。--------- 挑戦
Reg-Req&MN-AAA ---->
レッジ-Reqとミネソタ-AAA---->。
AMR------------>
Session-Id = foo
AMR------------>セッションイド=foo
AMR------------>
Session-Id = foo
AMR------------>セッションイド=foo
HAR----------->
Session-Id = bar
HAR----------->セッションイド=バー
<----------HAA
<。----------HAA
Session-Id = bar
セッションイド=バー
<-----------AMA
Session-Id = foo
<。-----------AMA Session-イド=foo
<------------AMA
Session-Id = foo
<。------------AMA Session-イド=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
外国人のエージェント(図2に示されるように)は挑戦を提供するかもしれません、[MIPCHAL]で説明されるように。(挑戦はモバイルIPv4登録手続における反復操作による保護の上で直轄をそれに与えるでしょう)。 モバイルノードは、AAAHで承認を可能にするためにChallengeとミネソタ-AAA認証拡大を含んでいます。 ミネソタ-AAA拡大で提供された認証データが無効であるなら、AAAHは戻ります。
Calhoun, et al. Standards Track [Page 9] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[9ページ]。
the response (AMA) with the Result-Code AVP set to DIAMETER_AUTHENTICATION_REJECTED.
Result-コードAVPとの応答(AMA)はDIAMETER_AUTHENTICATION_REJECTEDにセットしました。
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.
上のシナリオで、ミネソタ-FAとミネソタ-HAキーをDiameterルートに沿ったDiameterエージェントに暴露します。 これが関心であるなら、より安全なアプローチはAAAFと他のDiameterエージェントを排除することです、図3に示されるように。
Redirect
FA AAAF Agent AAAH
ファAAAFエージェントAAAHを向け直してください。
AMR
---------------->
AMR
---------------->
AMA (Redirect)
<----------------
AMA (Redirect)
<----------------
AMR---------------->AMR---------------->AMA(向け直す)<。---------------- AMAの(再直接)の<。----------------
Setup Security Association
<-------------------------------------------------->
セットアップセキュリティ協会<。-------------------------------------------------->。
AMR
AMR
-------------------------------------------------->
AMA (MN-FA key)
<---------------------------------------------------
-------------------------------------------------->AMA(ミネソタ-FAキー)<。---------------------------------------------------
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を見てください)場合に使用されるでしょう。
Calhoun, et al. Standards Track [Page 10] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[10ページ]。
Redirect
HA Agent AAAH
HAR
<--------------------
HAA (Redirect)
-------------------->
Setup Security Association
<---------------------------------------->
HAR (MN-HA key)
<-----------------------------------------
HAA
----------------------------------------->
ハ、エージェントAAAH HAR<を向け直してください。-------------------- HAA(向け直します)-------------------->セットアップセキュリティ協会<。---------------------------------------->HAR(ミネソタ-HAキー)<。----------------------------------------- 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から根絶されました。 再直接のサーバは、それらがFAとHAに輸送されるのでキーを見るので、AAAFといかなる他のDiameterエージェントも排除します。 図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 subtype、およびAAA NAI拡張子のAAAH Identity subtypeの認可しているホームAAAサーバにいつも割り当てられたホームのエージェントを含まなければなりません。 したがって、FAによって生成されたAMRが以前に認可されたセッションの間、ある場合、それはAAAHのアイデンティティがAAAH-NAIで見つけられて、割り当てられたHAのアイデンティティと分野があるMIPホームエージェントのホストAVPがHA-NAIで見つけられているDestination-ホストAVPを含まなければなりません。 他方では、モバイルノードがAAA NAI拡張子をサポートしないなら、FAには、割り当てられたHAのAAAHのアイデンティティ、アイデンティティ、および分野がないかもしれません。 これは、AAA NAI拡張子のサポートがなければ、FAが、AMRが以前にモバイルノードを認証して、認可したのと同じAAAHに運命づけられるのを保証できないかもしれないことを意味します、FAが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は、セッションにどのホームのエージェントを使用したらよいかを決定します。 まず最初に、AAAHは、HAがMIPホームエージェントアドレスAVPとMIPホームエージェントのホストAVPをチェックすることによってミネソタによって要求されているかどうかチェックします。 HAを所有している管理ドメインはMIPホームエージェントのホストAVPの分野の部分、または照合で決定するかもしれません。
Calhoun, et al. Standards Track [Page 11] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[11ページ]。
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特徴ベクトルAVPの外国ネットワークのホームのエージェント旗と外国AAA AVPを溯源するMIPの値。 要求されたHAが受入れられた管理ドメインに属すなら、AAAH SHOULDはセッションに与えられたHAを使用します。 さもなければ、AAAHはAVPがDIAMETER_ERROR_いいえ_FOREIGN_HA_SERVICEか_AVAILABLEではなく、DIAMETER_ERROR_HA_のどちらかに設定するResult-コードとの応答(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.
ミネソタが少しの特定のHAも要求していないなら、割り当てて、HA MUSTはダイナミックにそうです。 この場合、MIP特徴ベクトルで、要求されたホームのエージェント旗を設定するでしょう。 ホームアドレス-Allocatableホーム分野だけの旗が設定されないで、Foreign-ホームエージェント利用可能な旗が設定されるなら、AAAH SHOULDは外国分野にHAを割り当てさせますが(セクション3.2を見てください)、ローカルの方針で書き取られるなら、ホーム分野の1つ自体を割り当てるかもしれません。 ホーム分野だけのホームアドレスAllocatable旗が設定されるなら、AAAH MUSTはホーム分野にミネソタを代表して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要求(HAR)を割り当てられたか要求されたホームのエージェントに送ります。(それは、MIPレッジ要求AVPでカプセル化されたモバイルIPv4 Registration Requestメッセージデータを含みます)。 AAAHがHAに直接路を持っていないなら、図4を参照してください。 AAAH MAYはモバイルノードのためのホームアドレスを割り当てます、そして、ホームのエージェントはホームアドレス配分をサポートしなければなりません。 AAAHがアドレス配分を扱う場合、それはHARの中のMIPのモバイルノードアドレスAVPのホームアドレスを含んでいます。 このAVPの不在は、ホームアドレス配分を実行しなければならないことをホームのエージェントに知らせます。
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-レッジ回答AVPの中でそれをカプセル化して、ホームのエージェントは、MIPレッジ要求AVPを処理して、Registration Replyを作成します。 Registration Replyの作成では、ホームのエージェントはHA NAIとAAAH NAIを入れなければなりません。(AAAH NAIはHARのOrigin-ホストAVPとOrigin-分野AVPから作成されるでしょう)。 ホームアドレスが必要であるなら、ホームのエージェントは、Registration ReplyとMIPモバイルのノードアドレスAVPの両方でまた、1つを割り当てて、アドレスを入れなければなりません。
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のモバイルノード答え(AMA)メッセージを作成する、-。(メッセージはHAAとMIPホームエージェントアドレスに含まれていてMIPモバイルであることで同じAcctのマルチSessionのイドを含んでいます)。
Calhoun, et al. Standards Track [Page 12] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[12ページ]。
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メッセージのノードアドレスAVPs。 再直接のエージェントの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を見てください。
3.2. Allocation of Home Agent in Foreign Network
3.2. 外国ネットワークにおける、ホームのエージェントの配分
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のモバイルIPv4アプリケーションは、ホームのエージェントが必要に応じて[MIPREQ、CDMA2000]に外国ネットワークで割り当てられるのを許容します。 または、外国人のエージェントがそれを検出するとき、モバイルノードがaホームエージェントアドレスが.0を0.0との等しさにする、.0、255.255 .255 .255 Registration Requestメッセージでは、それは、ホームのエージェントによって要求された旗があるMIP特徴ベクトルAVPが1つにセットしたと言い足さなければなりません。 アドレスはホームのエージェントであるなら設定されます。255.255 .255 .255 外国人のエージェントは1つと等しいホーム分野だけのホームアドレスAllocatable旗を設定しなければなりません。 ホームエージェントアドレスがそうなら、合わせてください.0、外国人のエージェントがホームホーム分野だけのアドレスAllocatable旗の同輩に設定しなければならないゼロ.0を0.0に設定してください。
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が1つに設定された要求されたホームのエージェント旗と中のホームアドレス-Allocatableだけホーム分野と共にAMRメッセージを受け取ったら、同輩にゼロ(エージェント家で入手できているForeignが望んでいてモバイルノードのためにホームのエージェントを選任できることをAAAHに知らせるためにMIP特徴ベクトルAVPで旗を揚げさせるAAAF MAYセット)まで旗を揚げさせてください。 そうするとき、AAAF MUSTはMIP候補ホームエージェントのホストAVPとMIPを溯源している外国AAA-AVPを含んでいます。 MIP候補ホームエージェントのホストAVPはモバイルノードを選任されるホームのエージェントのアイデンティティ(すなわち、FQDNであるDiameterIdentity)を含んでいます、そして、MIPを溯源している外国AAA AVPはAAAFのアイデンティティを含んでいます。 AAAFは現在、AMRをAAAHに送ります。 しかしながら、上で議論するように、FAとAAAHの間のDiameterエージェントの使用はミネソタ-FAキーを暴露するでしょう。 これがそうなら、好ましくない人、再直接のサーバアプローチSHOULDであると考えられて、AMRをAAAHに伝えるのに利用されてください。 これで、FAはセキュリティ協会を通して直接AAAHにAMRを伝えます。
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とAAAH NAIをFAに含まなければならないよう現在再認証されるために持って、割り当てられたホームのエージェントに閉じ込めるよう要求します。 領収書では、FAはMIPホームエージェントアドレスAVPとAAAH NAIに基づくDestinationホストAVPを含むAMRを作成して、ホームのエージェントNAIに基づくMIPホームエージェントのホストAVPを含むでしょう。 AAAFが要求されたホームのエージェントの使用を認可するなら、AAAF MUSTはMIP特徴ベクトルAVPに中のホームエージェント外国ネットワークビットを設定します。
Calhoun, et al. Standards Track [Page 13] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[13ページ]。
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拡張子をサポートしないなら、AAA NAIとHA NAIなしで登録要求を送ります、AAAHと外国ネットワークで割り当てられたホームのエージェントを保つという要求でそれは以前に、認可されましたが。 領収書に、FAはMIPホームエージェントアドレスAVPを含むAMRを作成するでしょう。 AAAFが要求されたホームのエージェントの使用を認可して、それが、エージェントがそれ自身のドメインにいるのを知っているなら、AAAF MUSTはMIP特徴ベクトルAVPに外国ネットワークのホームのエージェントビットを設定します。
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レッジ要求AVPとMIPミネソタAAA Auth AVPに応じてモバイルノードを提供して、モバイルノードを認可するかどうか決定します。 AMRが、AAAFが、モバイルノードのためにホームのエージェントを割り当てると申し出たのを示すか(すなわち、手があいているForeignホームのエージェントはMIP特徴ベクトルAVPで用意ができています)、またはAMRが、AAAFがモバイルノードのために以前に割り当てられたホームのエージェントを提供したのを示すなら(すなわち、中のホームエージェント外国ネットワークはMIP特徴ベクトルAVPに設定されます)、AAAHは、ユーザがローカルの方針で外国ネットワークでホームのエージェントを持っているか、または保つかどうか決めなければなりません。 モバイルノードがそうすることが許可されていると仮定して、AAAHはDNSを使用することによってHAのFQDNに基づくHAのIPアドレスを決定するか、またはHARへの再直接の応答におけるMIPホームエージェントアドレスAVPを通してそれを学びます(すなわち、再直接のサーバがこのAVPをHAAに加えるなら)。 そして、それは、AVPがAMRのMIP候補ホームエージェントのホストAVPかMIPホームエージェントのホストAVPで見つけられた値に設定するDestination-ホストを含んでいることによって、HARメッセージをホームのエージェントに送ります。 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.
セキュリティ問題は、HARが仲介者Diameterエージェントの使用なしで直接AAAHからHAに送られるのを必要とするかもしれません。 これは、図4のようにAAAHとHAとのセキュリティ協会が設立されるのを必要とします。 セキュリティ協会を全く設立できないなら、AAAH MUSTはAVPがDIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTIONに設定するResult-コードがある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は起因しているAAAFにHARを送ります。 このHARでは、Destination-ホストAVPは外国AAA AVPを溯源しながらAMRのMIPで見つけられた値に用意ができています、そして、MIPホームエージェントのホストAVPかAMRで見つけられたMIP候補ホームエージェントのホストAVPが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 MUSTはAMRメッセージからHARメッセージまで外国AAA AVPを溯源するMIPをいつもコピーします。 別のAAAFがHARを受けるときの場合では、この新しいAAAFはHARをHAに送るでしょう。
Calhoun, et al. Standards Track [Page 14] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[14ページ]。
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
+--------+
訪問されたホーム分野分野+--------+ ------- AMR------->+--------+ | AAAF| <、-、-、-、-、-- HAR-------- | AAAH| | | | | +--->| サーバ| ------- HAA------->| サーバ| | +--------+ <。------ 海部-------- +--------+ | ^ | | | | HAR/HAA| AMR| | AMA v| +に対して---------+ +---------+ | ホーム| | 外国| | エージェント| | エージェント| +---------+ +---------+ ^ +--------+ | | モバイル| <、-、-、-、-、-、-、-、-、--+ | ノード| モバイル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.
訪問された分野のホームのエージェントからのHAAを受け取り次第、AAAFはホーム分野のAAAHにHAAを送ります。 AMAはAAAFと、そして、最終的なFAに次に、組み立てられて、発行されます。 Result-コードが成功を示すなら、HAAと海部はMIPホームエージェントアドレスとMIPのモバイルノードアドレスAVPsを含まなければなりません。
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エージェントのキーを暴露するなら、道は容認できないセキュリティリスクを表して、次に、代わりに図3と4に表現された再直接のアプローチを使用しなければなりません。
Calhoun, et al. Standards Track [Page 15] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[15ページ]。
Mobile Node Foreign Agent Home Agent AAAF AAAH ----------- ------------- ------------- ---------- ----------
モバイルノード外国人のエージェントホームエージェントAAAF AAAH----------- ------------- ------------- ---------- ----------
<---Challenge----
Reg-Req (Response)->
-------------AMR----------->
------AMR---->
<-----HAR-----
<-----HAR------
------HAA----->
------HAA---->
<-----AMA-----
<------------AMA------------
<---Reg-Reply----
<。---挑戦---- レッジ-Req(応答)->。-------------AMR----------->。------AMR----><。-----HAR----- <、-、-、-、--HAR------ ------HAA----->。------HAA----><。-----海部----- <、-、-、-、-、-、-、-、-、-、-、--海部------------ <--レッジ-回答----
Figure 6. MIP/Diameter Exchange for HA Is Allocated in
Visited Realm
図6。 MIP/直径が交換する、ハ、訪問された分野では、割り当てます。
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.
モバイルノードが別の外国Networkに移行するなら、それは、老人の中の同じホームのエージェントを外国に保つために、新しい外国ネットワークで新しいものを得るようネットワークでつなぐか、または要求するよう要求するかもしれません。 AAAHが、要求されたサービスを提供しても構わないと思っていると、AAAHは両方の訪問されたネットワークにサービスを提供しなければならないでしょう。 例えばキーはリフレッシュします。
3.3. Co-located Mobile Node
3.3. 共同見つけられたモバイルノード
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.
モバイルノードが共同見つけられたモバイルノードとしてホームのエージェントとともに記名するなら、どんな外国人のエージェントもかかわりません。 したがって、ホームのエージェントがRegistration Requestを受け取るとき、ローカルのAAAHサーバにAMRメッセージを送ります、MIP特徴ベクトルAVPに設定されたCoがモバイルノードの場所を見つけているビットで。 また、ホームのエージェントはAcctマルチSessionのイドAVPを入れます。(セクション4.1.1とAMRの.2が)AAAHに送った4.1を見てください、AAAHが、このセッション状態かログエントリ情報が役に立つのがわかるとき。
Calhoun, et al. Standards Track [Page 16] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[16ページ]。
Home
Realm
+--------+
| AAAH |
| |
| server |
+--------+
^ |
| |
AMR | | AMA
| v
+--------+ +---------+
| Mobile | Registration | Home |
| Node |-------------->| Agent |
+--------+ Request +---------+
ホーム分野+--------+ | AAAH| | | | サーバ| +--------+ ^ | | | AMR| | 海部| +に対して--------+ +---------+ | モバイル| 登録| ホーム| | ノード|、-、-、-、-、-、-、-、-、-、-、-、-、--、>| エージェント| +--------+ 要求+---------+
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.
要求されたミネソタHAキービットがホームのエージェントからのAMRメッセージに設定されるなら、ホームのエージェントとモバイルノードのセッションキーは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.
エイト環は再直接のサーバを使用するとき必要なセキュリティ協会を設立する安全な方法を示すシグナリングダイヤグラムを見せています。 Proxy AAAはHAが使用するどんなAAAサーバやサーバも表します。 これは訪問かホームネットワークに適用されます。
Calhoun, et al. Standards Track [Page 17] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[17ページ]。
Local redirect
HA Proxy AAA Agent AAAH
地方の再直接のHA Proxy AAAエージェントAAAH
AMR
--------------->
AMR (Redirect)
-------------------->
AMA (Redirect)
<---------------------
AMA (Redirect)
<----------------
Setup Security Association
<------------------------------------------------------>
AMR
------------------------------------------------------->
AMA (MN-HA key)
<-------------------------------------------------------
AMR--------------->AMR(向け直します)-------------------->AMA(向け直す)<。--------------------- AMAの(再直接)の<。---------------- セットアップセキュリティ協会<。------------------------------------------------------>AMR------------------------------------------------------->AMA(ミネソタ-HAキー)<。-------------------------------------------------------
Figure 8. Use of Redirect Server for Co-located CoA and AMR/AMA
エイト環。 再直接のサーバの共同見つけられたCoAとAMR/AMAの使用
3.4. Key Distribution
3.4. 主要な分配
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 Associations(MSAs)が必要とした先在の数を最小にするのが必要です。 これは、インターネットのそれぞれのホームのエージェントと共にあらかじめ設定されたMSAを持つためにそれぞれのForeignエージェントを必要とするべきでなくて、モバイルノードはどんな特定の外国人のエージェントと共にもあらかじめ設定された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アプリケーションは、主要な分配の機能性を含んでいることによって、これを解決します。(機能性は、モバイルNodeが認証された後に承認フェーズがセッションキーと一回だけの世代を含んでいることを意味します)。 明確に、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: ミネソタ-HA Session Key。(そのHA Session KeyはモバイルNodeとホームのエージェントの間のMSAの一部になるでしょう)。 AAAによって生成された一回だけからミネソタ-HA Session Keyを得ます。 モバイルノードは、Registration Replyでその一回だけを得て、AAAが使用するのと同じ公式を使用することでこのキーを生成します。
Calhoun, et al. Standards Track [Page 18] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[18ページ]。
- 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.
- ケーツー: ミネソタ-FA Key。(そのFA KeyはモバイルNodeとForeignエージェントの間のMSAの一部になるでしょう)。 AAAによって生成された一回だけからミネソタ-FA Keyを得ます。 モバイルノードは、AAAが使用するのと同じ公式を使用することでRegistration Replyでその一回だけを得て、ミネソタ-FAキーを生成します。
- K3: The FA-HA Key, which will be part of the MSA between the
Foreign Agent and the Home Agent.
- K3: FA-HA Key。(そのFA-HA KeyはForeignエージェントとホームのエージェントの間のMSAの一部になるでしょう)。
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つの実体の間の両方の方向に使用されます。 例えば、モバイルNodeとForeignエージェントはミネソタ-FAに、主要な同じセッションとFA-ミネソタ認証拡張子を使用します。 このセキュリティ含意はセクション13で調べられます。 しかしながら、ミネソタ-FAとFA-ミネソタの認証拡大において、SPIsは異なっているかもしれません。 ミネソタ-FA MSAのためのSPIはミネソタからFAに送られたメッセージで使用されます、そして、FA-MN MSAのためのSPIはFAからミネソタに送られたメッセージで使用されます。
All keys and nonces are generated by the AAAH, even if a Home Agent is dynamically allocated in the foreign network.
すべてのキーと一回だけはAAAHによって生成されます、外国ネットワークでダイナミックにホームのエージェントを割り当てても。
Figure 9 depicts the MSAs used for Mobile-IPv4 message integrity using the keys created by the DIAMETER server.
図9はモバイルIPv4メッセージの保全にDIAMETERサーバによって作成されたキーを使用することで使用されるMSAsについて表現します。
+--------+ +--------+
|Foreign | K3 | Home |
|Agent |<-------------------->| Agent |
| | | |
+--------+ +--------+
^ ^
| K2 K1 |
| +--------+ |
| | Mobile | |
+------>| Node |<------+
| |
+--------+
+--------+ +--------+ |外国| K3| ホーム| |エージェント| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| エージェント| | | | | +--------+ +--------+ ^ ^ | ケーツーK1| | +--------+ | | | モバイル| | +------>| ノード| <、-、-、-、-、--+ | | +--------+
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エージェントのキーを暴露するなら、道は容認できないセキュリティリスクを表します、次に、IPSecかHAとAAAHかFAとAAAFの直接間に存在するTLSセキュリティ協会がキーを保護しなければなりません、上で説明されるように。
Calhoun, et al. Standards Track [Page 19] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[19ページ]。
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インフラストラクチャを呼び出さなければなりませんでした後)。
4. Diameter Protocol Considerations
4. 直径プロトコル問題
This section details the relationship of the Diameter Mobile IPv4 application to the Diameter base protocol.
このセクションはDiameterのモバイルIPv4アプリケーションの関係をDiameterベースプロトコルに詳しく述べます。
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-ID2を指定します。 この仕様に従う直径ノードは、Authアプリケーションイドの2(2)の値かCapabilities交換要求とCapabilities交換答え命令[DIAMBASE]のAcctアプリケーションイドAVPを含んでいることによって、サポートの広告を出すかもしれません。 すべてのAMR/AMAとHAR/HAAのApplication-イドが命令するように2(2)の値は使用されているに違いありません。 すべてのACR/ACAのApplication-イドが命令するように2(2)の値は使用されているに違いありません、このアプリケーションが会計で新しくて、義務的なAVPsを定義するとき。 すべてのSTR/STAとASR/ASAのApplication-イドが命令するようにゼロ(0)SHOULDの値が使用されて、これらがDiameterベースの中で定義されるように議定書を作ってください。そうすれば、それらのコマンドのためのどんな追加義務的なAVPsも本書では定義されません。
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サーバの開始している再authはこのアプリケーションに申し込まれません、そして、DiameterのモバイルIPv4セッションのためにRAR/RAAコマンドを送ってはいけません。
4.1. Diameter Session Management
4.1. 直径セッション管理
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 MAYはセッション状態を維持するか、またはセッション国がないかもしれません。 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
可動のノードのセッションはAVPというUser名、MIPのモバイルノードアドレス、およびMIP-ホームエージェントアドレスAVPsのアイデンティティで特定されます。 これが、セッション状態を許容するのに必要です。
Calhoun, et al. Standards Track [Page 20] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[20ページ]。
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.
このアプリケーションに変更なしで使用されるためにベースプロトコル[DIAMBASE]で定義されたマシン。 しかしながら、ミネソタがセッションの人生の間、1FAと対話するかもしれないので、DiameterのモバイルIPv4アプリケーションがセッション(FAの何らかの状態、HAの何らかの状態)の2つの断片を区別して、独自にそれらを管理するのは重要です。 以下の小区分は詳細を与えます。
4.1.1. Session Identifiers
4.1.1. セッション識別子
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はセッション識別子を選ぶでしょう。 HARの創造の間、AAAH MUSTはAMR/AMAで使用されるそれと異なったセッション識別子を使用します。 AAAHがセッションstatefulであるなら、それは与えられた可動のノードのセッションを代表して開始されたすべてのHARsのために同じセッション識別子を送らなければなりません。 さもなければ、AAAHがセッション国がないなら、それはあらゆるHARのためにユニークなセッションイドを製造するでしょう。
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マルチSessionのイドAVPを作成して、含まなければなりません。 この識別子はモバイルIPv4セッションの人生で次の小区分で詳しく述べられるように一定に保たれるでしょう。
4.1.2. Managing Sessions during Mobile IPv4 Handoffs
4.1.2. モバイルIPv4 Handoffsの間の管理セッション
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の自然を考えて、可動のノードは期間の間、多くの外国人のエージェントからサービスを受けるかもしれません。 しかしながら、家の分野はこれらのhandoffsを異なったセッションであるとみなすべきではありません、これが支払いシステムに影響できたとき。通常、外国人のエージェントは、互いの間でその上、どれが、これらの実体の間で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を新しいセッション識別子を含めて、新しいAAAF(すなわち、前のFAによって使用されたそれと異なったAAAF)に送るかもしれません。 しかしながら、AMRはユーザが現在登録される(ことによると図3に表現された再直接のメカニズムで)AAAHによって受け取られるものとします。
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が可動のノードのために新しいセッション識別子とHAと共にHARを受けるなら、次に、この要求が既存のサービスを広げることであるという保証、HA MUSTは、新しいセッション識別子を反映するように内部のセッション州の情報を変更できますか?
Calhoun, et al. Standards Track [Page 21] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[21ページ]。
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.
相関関係が起こるように、会計帳簿はhandoffsの向こう側に何らかの共通点を持たなければなりません。 したがって、家のエージェントはモバイルのセッションのためにすべてのHAAsで同じAcctのマルチSessionのイドAVP価値を送らなければなりません。 すなわち、HAは新しいセッションのためにHARを受けるとき、ユニークなAcctマルチSessionのイドを発生させて、セッションのためにあらゆるHAAでこの同じ値を返します。 このAcctのマルチSessionのイドAVPはAMAのAAAHによって外国人のエージェントに返されるでしょう。 両方の外国と家のエージェントは図10に表現されるように会計メッセージでAcctのマルチSessionのイドを入れなければなりません。
4.1.3. Diameter Session Termination
4.1.3. 直径セッション終了
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 Serverが特定の可動のノードに割り当てられたどんなリソースも発表するように、そのサーバは移動性エージェントからSession終了要求(STR)を受け取らなければなりません。 Authorization Lifetimeが期限が切れて、どんなその後のMIP登録要求も受け取っていないなら、移動性エージェントはSession終了要求(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).
家のエージェントからSTRを受け取った後にAAAH SHOULDはすべてのリソースを「反-割り当て」るだけです。 これは、ホームDiameter Serverが1人の外国人のエージェントから別のもの(例えば引き渡しの結果、)まで動く可動のノードで可動のノードのためのすべてのリソースを解放するというわけではないのを確実にします。 したがって、外国人のエージェントからのSTRはセッション状態ではなく、家のエージェントに関連している外国人のエージェントからセッションを解放するでしょう(図10を見てください)。
STR, Session-Id = foo STR, Session-Id = bar
---------------------> <--------------------
+----+ +------+ +------+ +----+
| FA | | AAAF | | AAAH | | HA |
+----+ +------+ +------+ +----+
<--------------------- --------------------->
STA, Session-Id = foo STA, Session-Id = bar
STR、Session-イド=foo STR、Session-イド=バー---------------------><。-------------------- +----+ +------+ +------+ +----+ | ファ| | AAAF| | AAAH| | ハ| +----+ +------+ +------+ +----+ <。--------------------- --------------------->STA、Session-イド=foo STA、Session-イド=バー
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セッション要求(ASR)[DIAMBASE]メッセージSHOULDを終えるには、FAに送ってください。 同様に、AAAH SHOULDはホームのエージェントにメッセージを送ります。
Calhoun, et al. Standards Track [Page 22] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[22ページ]。
5. Command-Code Values
5. コマンドコード値
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実現で支持しなければならないCommand-コード[DIAMBASE]値を定義します。 以下のCommand Codesはこの仕様に基づき定義されます:
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
コマンド名略語コード部----------------------------------------------------------- AAのモバイルノード要求AMR260 5.1AAのモバイルノード答えAMA260 5.2ホームエージェントMIP要求HAR262 5.3ホームエージェントMIP答えHAA262 5.4
5.1. AA-Mobile-Node-Request
5.1. AAのモバイルノード要求
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:
可動のノードの認証と認可を要求するためにDiameterクライアントとしてAAAFに機能して、260に設定されたCommand-コード分野とCommand Flags分野に設定された'R'ビットによって示されたAAのモバイルノード要求(AMR)は付添人(すなわち、Foreignエージェント)によって送られます。 外国人のエージェント(または、共同見つけられたモバイルNodeの場合における家のエージェント)はAMRの一部として含まれるのに以下のAVPsを組み立てるためにRegistration Requestで見つけられた情報を使用します:
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)
ForeignエージェントSPIの外国人のホームAddress(MIPのモバイルノードアドレスAVP)のホームのエージェントAddress(MIPホームエージェントアドレスAVP)のモバイルNode NAI(ユーザ名のAVP[DIAMBASE])ミネソタ-HA Key Request(MIP特徴ベクトルAVP)ミネソタ-FA Key Request(MIP特徴ベクトルAVP)ミネソタ-AAA Authentication Extension(MIPミネソタAAA Auth AVP)ホームのAAAのサーバNAI(目的地ホストAVP[DIAMBASE])ホームのエージェントChallenge Extension(MIP-FA-挑戦AVP)ホームエージェントNAI(MIPホームエージェントのホストAVP)エージェント(MIP、ファ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のモバイルノードアドレスAVPを入れてはいけません。家のエージェントであるなら、現在のコネがAMRであったなら、アドレスは、ゼロかすべて、もの、MIPホームエージェントアドレスAVP MUST NOTです。
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 MAYは訪問された分野でホームのエージェントを選任しても構わないと思っているのを示すAMRメッセージで手があいているForeignホームのエージェント旗をMIP特徴ベクトルAVPにはめ込みます。
Calhoun, et al. Standards Track [Page 23] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[23ページ]。
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.
可動のノードのホームアドレスがすべてものであるなら、外国か家のエージェントはMIPのモバイルノードアドレス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]を含んでいるなら、外国人のエージェントはMIP-ホームを入れなければなりません。-AVPとAMRのDestination-ホスト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 ]
<AAモバイルノードの要求している>:、:= <直径ヘッダー: 260 REQ; PXY><Session ID>Authアプリケーションイドユーザ名目的地分野のMIPホームエージェントアドレスのMIP特徴ベクトルのMIPの由来している外国起源ホスト起源分野MIPレッジRequest MIP Mn AAA Auth Acctマルチセッションイドあて先ホスト起源州のイドMIPのモバイルノードアドレスAAA認可生涯Authセッション州、MIPファ挑戦MIP候補ホームエージェントのホストMIPホームエージェントのホスト、MIP、ファSPI、ハ、*プロキシインフォメーション*ルート記録*[AVP]
Calhoun, et al. Standards Track [Page 24] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[24ページ]。
5.2. AA-Mobile-Node-Answer
5.2. AAのモバイルノード答え
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-コード分野とCommand Flags分野できれいにされた'R'ビットによって示されたAAのモバイルノード答え(AMA)はAAのモバイルノード要求メッセージに対応してAAAHによって送られます。 それがAMRに存在しているなら、User-名前はAMAに含まれるかもしれません。Result-コードAVP MAYはセクション6で定義された値の1つを含んでいます、[DIAMBASE]で定義された値に加えて。
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 MUSTに設定するResult-コードがあるAMAメッセージがMIPホームエージェントアドレスAVPを含んでいて、MIPモバイルのノードアドレスAVP、およびインクルードを含まなければならない、MIPレッジ回答AVP、Coがモバイルノードの場所を見つけているビットがMIP特徴ベクトルAVPに設定されなかった場合にだけ。 MIPホームエージェントアドレスAVPは可動のノードを選任されたホームのエージェントを含みます、MIPのモバイルノードアドレスAVPが割り当てられたホームアドレスを含んでいますが。 それらがAMRで要求されて、HARに存在していたなら、AMAメッセージはHA-MSAへのMIP-FAとミネソタMSAへのMIP-FAを含まなければなりません。 セッションキーがAMRで要求されて、Coがモバイルノードの場所を見つけているビットがMIP特徴ベクトルAVPに設定されたなら、MIPミネソタからHA-MSAとMIP-HAはミネソタMSA AVPsに存在していなければなりません。
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 ]
<AAモバイルノードの答えの>:、:= <直径ヘッダー: 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フィルタ規則]
Calhoun, et al. Standards Track [Page 25] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[25ページ]。
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ AVP ]
[起源州のイド] *[プロキシインフォメーション]*[AVP]
5.3. Home-Agent-MIP-Request
5.3. ホームエージェントMIP要求
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-コード分野とCommand Flags分野に設定された'R'ビットによって示されたホームエージェントMIP要求(HAR)をホームのエージェントに送ります。 ホームのエージェントが外国ネットワークで選任されるつもりであり、どんな再直接のサーバもかかわらないなら、HARはAAAHによって発行されて、AAAFによってHAに送られます。 いずれかがそうなら、セキュリティ協会を通して直接HAにHARを送ります。 ホームアドレス、およびHARのための.0はそうです。HARメッセージがa MIPのモバイルノードアドレスAVPを含んでいないなら、Registration Requestには.0が0.0にある、首尾よく、処理されています、ホームのエージェントは可動のノードアドレスを割り当てなければなりません。 他方では、家のエージェントのローカルのAAAサーバが可動のノードのホームアドレスを割り当てるなら、ローカルのAAAサーバはMIPのモバイルノードアドレス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 MUSTは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 ]
<ホームエージェントMIP-要求>:、:= <直径ヘッダー: 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 ] [起源州のイド]
Calhoun, et al. Standards Track [Page 26] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[26ページ]。
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
* [プロキシインフォメーション] *[ルート記録的な]*[AVP]
5.4. Home-Agent-MIP-Answer
5.4. ホームエージェントMIP答え
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].
ホームエージェントMIP要求に対応して、ホームのエージェントは262に設定されたCommand-コード分野とCommand Flags分野できれいにされた'R'ビットによって示されたホームエージェントMIP答え(HAA)をローカルのAAAサーバに送ります。それがHARに存在しているなら、User-名前はHAAで入れられるかもしれません。 -家のエージェントであるなら、可動のノード、アドレスがそうであるに違いないのでホームアドレスを割り当てて、MIP-モバイルに含まれていて、AVPをノードで記述してください。 Result-コードAVP MAYはの代わりにするセクション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 ]
<ホームエージェントMIP-答え>:、:= <直径ヘッダー: 262 PXY><セッションイド>Authアプリケーションイド結果コード起源ホスト起源分野[Acctマルチセッションイド][ユーザ名][エラー報告ホスト][エラーメッセージ][MIPレッジReply][MIPホームエージェントアドレス][MIPのモバイルノードアドレス][ハ、SPIへのMIPファ][MIPファからMn SPI][起源州のイド]*[プロキシインフォメーション]*[AVP]
6. Result-Code AVP Values
6. 結果コードAVP値
This section defines new Result-Code [DIAMBASE] values that MUST be supported by all Diameter implementations that conform to this specification.
このセクションはこの仕様に従うすべてのDiameter実現で支持しなければならない新しいResult-コード[DIAMBASE]値を定義します。
Calhoun, et al. Standards Track [Page 27] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[27ページ]。
6.1. Transient Failures
6.1. 一時障害
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.
Registration Requestの処理が失敗したとき、DIAMETER_ERROR_MIP_REPLY_FAILURE4005Thisエラーコードは家のエージェントによって使用されます。
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.
_AVAILABLE4006Thisエラーコードではなく、DIAMETER_ERROR_HA_が、このとき要求されたホームのエージェントを可動のノードを選任できないことを外国人のエージェントに知らせるのに使用されます。 外国人のエージェントは適切なエラーコードがある可動のノードにモバイルIPv4 Registration Replyを返さなければなりません。
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_KEY4007Thisエラーコードは、キーが発生させたサーバが無効であることを地方の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.
_SUPPORTED4008Thisエラーコードではなく、DIAMETER_ERROR_MIP_FILTER_が、要求されたパケットフィルタRulesを支持できないのを家のDiameterサーバに示すのに移動性エージェントによって使用されます。
6.2. Permanent Failures
6.2. 永久的な失敗
Errors that fall within the permanent failures category are used to inform the peer that the request failed and SHOULD NOT be attempted again.
永久的な失敗カテゴリの中に下がる誤りは、失敗された要求とSHOULD NOTが再び試みられることを同輩に知らせるのに使用されます。
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_いいえ_FOREIGN_HA_SERVICE5024This誤りは、外国ドメインでの家のエージェントの配分がこのとき受入れられないことをAAAHに知らせるのにAAAFによって使用されます。
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_ENCRYPTION5025This誤りは、セキュリティ協会を通して要求されたモバイルIPv4セッションキーを届けることができなかったことを同輩に知らせるのにAAAF/AAAHによって使用されます。
7. Mandatory AVPs
7. 義務的なAVPs
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 AVPsについて説明します。 それらのAVP Code値、タイプ、および可能な旗の値。 AVP MAYはコード化されています。
Calhoun, et al. Standards Track [Page 28] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[28ページ]。
Due to space constraints, the short form IPFiltrRule is used to represent IPFilterRule, and DiamIdent is used to represent DiameterIdentity.
宇宙規制のため、縮約形IPFiltrRuleはIPFilterRuleを表すのに使用されます、そして、DiamIdentは、DiameterIdentityを表すのに使用されます。
+--------------------------+
| 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 |
+--------------------------+ | AVP Flag規則| |----+-----+----+-----|----+ AVP部| | |SHLD| 必須|5月| 属性名前コードは値のタイプを定義しました。|必須| 5月| NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| MIPレッジRequest320 7.1OctetString| M| P| | V| Y| MIPレッジReply321 7.2OctetString| M| P| | V| Y| MIP Mn AAA Auth322 7.6は分類されました。| M| P| | V| Y| MIPモバイルのノード-333 7.3アドレス| M| P| | V| Y| アドレスMIP-ホームエージェント-334 7.4アドレス| M| P| | V| Y| MIP候補-336 7.9にDiamIdentを記述してください。| M| P| | V| N| ホームエージェントのホストMIP特徴-337 7.5Unsigned32| M| P| | V| Y| ベクトルMIP-Auth入力-338 7.6.2Unsigned32| M| P| | V| Y| データ長さのMIP339 7.6.3Unsigned32| M| P| | V| Y| 固有識別文字長さのMIP340 7.6.4Unsigned32| M| P| | V| Y| MIP Mn AAA SPI341 7.6に.1Unsigned32を固有識別文字で相殺してください。| M| P| | V| Y| MIPフィルタ規則342 7.8IPFiltrRule| M| P| | V| Y| MIPファ挑戦344 7.7OctetString| 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
7.10が分類したMIP由来-347| M| P| | V| Y| 外国AAA MIP-ホームエージェント-348 7.11DiamIdent| M| P| | V| N| ホスト
7.1. MIP-Reg-Request AVP
7.1. MIPレッジRequest AVP
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レッジRequest AVP(AVP Code320)はタイプOctetStringにはあって、可動のノードによって送られたモバイルIPv4 Registration Request[MOBILEIP]を外国人のエージェントに含んでいます。
7.2. MIP-Reg-Reply AVP
7.2. MIPレッジReply AVP
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レッジReply AVP(AVP Code321)はタイプOctetStringにはあって、家のエージェントによって外国人のエージェントに送られたモバイルIPv4 Registration Reply[MOBILEIP]を含んでいます。
Calhoun, et al. Standards Track [Page 29] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[29ページ]。
7.3. MIP-Mobile-Node-Address AVP
7.3. MIPのモバイルノードアドレスAVP
The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and contains the mobile node's home IP address.
MIPのモバイルノードアドレスAVP(AVP Code333)はタイプAddressにはあって、可動のノードの家のIPアドレスを含んでいます。
7.4. MIP-Home-Agent-Address AVP
7.4. MIPホームエージェントアドレスAVP
The MIP-Home-Agent-Address AVP (AVP Code 334) is of type Address and contains the mobile node's home agent IP address.
MIPホームエージェントアドレスAVP(AVP Code334)はタイプAddressにはあって、可動のノードの家のエージェントIPアドレスを含んでいます。
7.5. MIP-Feature-Vector AVP
7.5. MIP特徴ベクトルAVP
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特徴ベクトルAVP(AVP Code337)はタイプUnsigned32にはあって、外国人のエージェントか外国人のエージェントと同じ管理ドメインによって所有されていたAAAFによって設定された旗の値で加えられます。 外国人のエージェントSHOULDはそれがAAAFに送るAMRメッセージの中にMIP特徴ベクトル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
アドレスが要求した1つのモバイルノードホーム2ホーム分野だけのホームアドレスAllocatable手があいている要求された4ホームのエージェントの8外国人のホームのエージェント16、Mn、ハ、主要な要求、32Mnのファの主要な要求64、ファ、ハ、主要な要求、外国ネットワークの128ホームのエージェントの256の共同見つけられたモバイルノード
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.
または、モバイルノードが有効なホームアドレスを含んでいる、(すなわち、1つが0.0と.0と等しくない、.0、255.255 .255 .255) Registration Requestでは、外国人のエージェントはMIP特徴ベクトル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.
モバイルノードがセットするなら、ホームエージェント分野はRegistration Request、外国エージェントセットにおける両方のホームの.255のエージェントによって要求された旗と中のホームアドレス-Allocatableだけホーム分野がMIP特徴ベクトルAVPの1まで旗を揚げさせる.255と255.255と等しいです。
Calhoun, et al. Standards Track [Page 30] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[30ページ]。
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 Registration Requestでは、外国人のエージェントは、MIP特徴ベクトルAVPで要求されたホームのエージェント旗を1つに設定して、ホーム中のAllocatableだけホームを扱っている分野の旗のゼロに合っています。
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.
外国人のエージェントがアドレスが要求したモバイルノードホーム旗か要求されたホームのエージェント旗のどちらかを1つに設定するときはいつも、それはミネソタのHAの主要な要求旗を1つに設定しなければなりません。 また、モバイルノードがaを含んでいるならミネソタHAの主要な要求旗が1つに設定される、「総合、Mn、-、ハ、キー生成一回だけは」 [MIPKEYS]拡大を要求します、AAAへのsubtypeセットで。
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)がRegistration Requestにある「一般化されたミネソタ-ファキー生成一回だけの要求」[MIPKEYS]拡大を含んでいるなら、外国人のエージェントはMIP特徴ベクトルAVPの1つにミネソタのFAの主要な要求旗を設定します。
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.
モバイルノードがすべてのものにホームアドレス分野を設定するか、または外国ネットワークでホームのエージェントを指定することによって外国ネットワークでホームのエージェントを要求して、AAAFが要求を認可するなら、AAAF MUSTは中のホームエージェント外国のネットワークのビットを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ホームのエージェント旗を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.
ホームのエージェントがミネソタが共同見つけられたモバイルノードとして機能しているのを示すモバイルノードからRegistration Requestを受け取るなら、ホームのエージェントはCoがモバイルノードの場所を見つけているビットを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の主要な要求旗を設定するかもしれません。
The foreign agent MUST NOT set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network flag both to one.
外国人のエージェントは手があいているForeignホームのエージェントと外国ネットワークのホームのエージェント旗をともに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特徴ベクトルAVP旗の設定によって示されたどんな行動も取ります。 そして、AAAFは追加旗を設定するかもしれません。 AAAFだけが手があいているForeignホームのエージェントと中のホームエージェント外国のネットワークの旗を1つに設定するかもしれません。 ローカルの施政方針によると、これをします。 AAAFが、ローカルの方針によると、追加旗を設定し終えたなら、AAAFはことによると変更されたMIP特徴ベクトルAVPと共にAMRをAAAHに伝えます。
Calhoun, et al. Standards Track [Page 31] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[31ページ]。
7.6. MIP-MN-AAA-Auth AVP
7.6. MIP Mn AAA Auth AVP
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:
ミネソタAAA Auth AVP(AVP Code322)はタイプGroupedにはあって、目標AAAサーバでモバイルIPv4 Registration Request[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 ]
MIP Mn AAA Auth:、:= <AVPヘッダー: 322 >MIP Mn AAA SPI MIP-Auth入力データの長さのMIP固有識別文字の長さのMIP固有識別文字オフセット*[AVP]
7.6.1. MIP-MN-AAA-SPI AVP
7.6.1. MIP Mn AAA SPI 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ミネソタAAA SPI AVP(AVP Code341)はタイプUnsigned32にはあって、Registration Requestデータの上に狙っているAAAサーバ(AAAH)がモバイルノードによって計算されたAuthenticatorを有効にするのを試みるべきであるMSAを示します。
7.6.2. MIP-Auth-Input-Data-Length AVP
7.6.2. MIP-Auth入力データの長さのAVP
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入力データの長さのAVP(AVP Code338)はタイプUnsigned32にはあって、長さを含んでいて、Registration Requestデータ(MIPレッジRequest AVPのデータ部)に、バイトで、それはアルゴリズムに入力されるように使用されるべきです、ミネソタAAA SPI AVPで、モバイルノードによって供給されたAuthenticator Dataが有効であるかどうか決定することにおける中古によって示されるように。
7.6.3. MIP-Authenticator-Length AVP
7.6.3. MIP固有識別文字の長さの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固有識別文字の長さのAVP(AVP Code339)はタイプUnsigned32にはあって、狙っているAAAサーバ(すなわち、AAAH)によって有効にされるべき固有識別文字の長さを含んでいます。
7.6.4. MIP-Authenticator-Offset AVP
7.6.4. MIP固有識別文字オフセットAVP
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固有識別文字オフセットAVP(AVP Code340)は、狙っているAAAサーバ(すなわち、AAAH)によって有効にされるために固有識別文字のRegistration Request DataにタイプUnsigned32にはあって、オフセットを含んでいます。
Calhoun, et al. Standards Track [Page 32] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[32ページ]。
7.7. MIP-FA-Challenge AVP
7.7. MIPファ挑戦AVP
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-挑戦AVP(AVP Code344)はモバイルノードにタイプOctetStringにはあって、外国人のエージェントによって広告に掲載された挑戦を含んでいます。 このAVP MUST、モバイルノードがRADIUS-スタイルミネソタ-AAA計算アルゴリズム[MIPCHAL]を使用したなら、AMRに存在してください。
7.8. MIP-Filter-Rule AVP
7.8. MIPフィルタ規則AVP
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フィルタ規則AVP(AVP Code342)はタイプIPFilterRuleにはあって、外国かホームのエージェントの上で構成されなければならないフィルタ規則をユーザに提供します。 外国人のエージェントのために運命づけられているなら、パケットフィルタリング規則はホームのエージェントのために運命づけられているならHARの1MIPフィルタ規則AVPsを加えるのによるAAAH AMAのセットです。
7.9. MIP-Candidate-Home-Agent-Host
7.9. MIP候補ホームエージェントのホスト
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候補ホームエージェントのホストAVP(AVP Code336)はダイナミックに割り当てられるAAAFがモバイルノードに提案する外国ネットワークに、タイプDiameterIdentityにはあって、ホームのエージェントのアイデンティティを含んでいます。
7.10. MIP-Originating-Foreign-AAA AVP
7.10. 外国AAAを溯源するMIP AVP
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.
外国AAA AVPを溯源するMIP(AVP Code347)はタイプGroupedにはあって、AAAFのアイデンティティを含んでいます。(AAAFはAAAHにAMRを発行します)。 外国AAA AVP MUSTを溯源するMIPだけをホームのエージェントが使用するとき、場合に使用するか、または外国ドメインに割り当てるかもしれません。 外国AAA AVPを溯源するMIPがAMRに存在しているなら、AAAH MUSTはHARにそれをコピーします。
MIP-Originating-Foreign-AAA ::= < AVP Header: 347 >
{ Origin-Realm }
{ Origin-Host }
* [ AVP ]
外国AAAを溯源するMIP:、:= <AVPヘッダー: 347 >発生源分野発生源ホスト*[AVP]
7.11. MIP-Home-Agent-Host AVP
7.11. MIPホームエージェントのホスト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ホームエージェントのホストAVP(AVP Code348)はタイプGroupedにはあって、割り当てられたホームのエージェントのアイデンティティを含んでいます。 -MIP-ホームであるなら、エージェント兼ホストAVPはAMR、AAAH MUSTコピーにHARにそれを提示することです。
MIP-Home-Agent-Host ::= < AVP Header: 348 >
{ Destination-Realm }
{ Destination-Host }
* [ AVP ]
MIPホームエージェントのホスト:、:= <AVPヘッダー: 348 >目的地分野あて先ホスト*[AVP]
Calhoun, et al. Standards Track [Page 33] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[33ページ]。
8. Key Distribution
8. 主要な分配
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.
モバイルノードと移動性エージェントはMIP登録メッセージに適用された認証拡大を計算するのに、セッションキー(すなわち、ミネソタ-FA、FA-HA、およびミネソタ-HAセッションキー)を使用します、[MOBILEIP]で定義されるように。 セッションキーが要求されるなら、モバイルノードが首尾よく認証されて、認可された後にAAAH MUSTはキーと一回だけを返します。
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値があります。 キーを共有するノードで、複数の異なったSPIsがすべて、同じキーについて言及できます。 すべての場合では、認証拡大(すなわち、それは認証拡大について確かめる)を受ける実体は認証拡大(すなわち、それは認証拡大を計算する)にその計算に使用するSPIの値を送る実体を提供しています。 それらが両方の方向に使用されるのでこのモデルのキーが左右対称であることに注意してください、SPIsは左右対称である必要はありませんが。
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.
モバイルノードはFA-ミネソタとHA-ミネソタ移動性セキュリティ協会における使用のためにSPIsを割り当てます、モバイルIPv4AAA Key Request拡張子[MIPKEYS]で。 ホームのエージェントはミネソタ-HAとFA-HA移動性セキュリティ協会のためにSPIsを割り当てます。 外国人のエージェントはミネソタ-FAとHA-FA移動性セキュリティ協会のためのSPIsを選びます。
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によって強制されるように、これらの登録証明書はミネソタ-HA認証拡張子を含まなければなりません。 また、同様に、ミネソタ-FAセッションキーがAAAによって生成されて、分配されたなら、その後の登録証明書はミネソタ-FA認証拡張子を含まなければなりません。 同じくらいはFA-HA認証拡張子のその後の使用に当てはまります。
8.1. Authorization Lifetime vs. MIP Key Lifetime
8.1. 承認生涯対MIPの主要な生涯
The Diameter Mobile IPv4 application makes use of two timers: the Authorization-Lifetime AVP [DIAMBASE] and the MIP-MSA-Lifetime AVP.
DiameterのモバイルIPv4アプリケーションは2個のタイマを利用します: 承認生涯AVP[DIAMBASE]とMIP-MSA-生涯AVP。
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].
モバイルノードがその後のMIP登録要求を出さなければならない前にAuthorization-寿命は秒数を含んでいます。 Authorization-生涯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
移動性エージェントとモバイルノードのために運命づけられたセッションキーが期限が切れる前にMIP-MSA-生涯AVPは秒数を含んでいます。 ゼロの値は無限(タイムアウトがない)を示します。 そうでなければ
Calhoun, et al. Standards Track [Page 34] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[34ページ]。
zero, the value of the MIP-MSA-Lifetime AVP MUST be at least equal to the value in the Authorization Lifetime AVP.
ゼロ、MIP-MSA-生涯AVP MUSTの値は少なくともそうです。Authorization Lifetime AVPの値と等しいです。
8.2. Nonce vs. Session Key
8.2. 一回だけ対セッションキー
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は同じキーに対応する一回だけを生成して、モバイルノードにそれらを伝えます。 信頼されていないDiameterエージェントからセッションのキーとSPIsを保護するのが必要であるときに、終わりから終わりへの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は、無作為の[RANDOM]が少なくとも128ビット[MIPKEYS]の価値であると生成しなければなりません。 そして、モバイルノードは、ミネソタ-HAとミネソタ-FAセッションキーを引き出すのに一回だけを使用します。
More details of the MN-HA and the MN-FA session key creation procedures are found in [MIPKEYS].
ミネソタ-HAに関するその他の詳細とミネソタ-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は、使用のためにこのセッションキーとして無作為の[RANDOM]が少なくとも128ビットの価値であると生成します。
See sections 9 for details about the format of the AVPs used to transport the session keys.
AVPsの形式に関する詳細のためのセクション9が以前はよくセッションキーを輸送していたのを確実にしてください。
8.3. Distributing the Mobile-Home Session Key
8.3. 移動住宅セッションキーを分配します。
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.
モバイルノードにミネソタ-HAセッションキーがないなら、AAAHは唯一のモバイルノードに利用可能な信じられた実体である傾向があります。 したがって、AAAHはミネソタ-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-ミネソタ(セッション)の分配はセクション1.2と3.4で指定されます。 HAとAAAHはセキュリティ協会(IPSecかTLS)を設立して、それの上でキーを輸送します。 セキュリティ協会が全くAAAHとホームのエージェントの間に存在しないで、セキュリティ協会を設立できないなら、AAAH MUSTはDIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTIONとResult-コードAVPを返します。
Calhoun, et al. Standards Track [Page 35] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[35ページ]。
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メッセージとAVPsに関して知っているだけです、そして、モバイルノードはモバイルIPv4メッセージと拡大[MOBILEIP]に関して知っているだけです。 このために、AAAHはミネソタHA MIP一回だけAVPをMIPミネソタからHA-MSA AVPに含めます。(HA-MSA AVPはHAR(FA COAスタイルのモバイルIPv4のための)、または、AMA(並べたCOA-スタイルモバイルIPv4メッセージのための)に加えられて、訪問されたネットワークで地元のホームのエージェントかホームのエージェントに提供されます)。 モバイルノードがそれがAAAH[MIPKEYS]と共有するミネソタ-AAAキーを使用することによって主要なミネソタ-HAセッションを作成するのに一回だけを使用することに注意してください。 AAAHがモバイルIPv4に一回だけを移すために、ホームのエージェント(また、Diameterを理解している)に頼らなければならない、「総合、Mn、-、ハ、Registration Replyメッセージにおけるキー生成の一回だけの回答」 拡大[MIPKEYS。] HAがモバイルノードによって提案されたSPIsとホームのエージェントを含んでいる、「総合、Mn、-、ハ、キー生成一回だけは」 拡大を要求します。 ホームのエージェントは最後の配送のために正しくReplyメッセージと拡大をモバイルノードにフォーマットできます。 結果として起こるRegistration ReplyはHAAのMIPレッジ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レッジReply AVPを含むAMAメッセージに変えて、AMAメッセージを外国人のエージェントに送ります。 キー生成一回だけは返答します。次に、外国人のエージェントがRegistration Replyメッセージ含有を休養させるのにそのAVPを使用する、「総合、Mn、-、ハ、」 モバイルノードへの配送のための拡大。
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はミネソタ-HA一回だけとセッションキーを生成します。(一回だけはHA-MSA AVPへのMIPミネソタに追加されます)。(それは、ミネソタMSA AVPへのMIP-HAに加えられます)。 これらのAVPsはHARのホームのエージェントかAMAメッセージに提供されます。 キー生成一回だけは返答します。ホームのエージェントがそれ自身の使用に、主要なセッションを保有して、MIPミネソタからHA-MSA AVPでaに一回だけをコピーする、「総合、Mn、-、ハ、」 拡大(モバイルIPv4 Registration Replyメッセージに追加されるもの)。 また、このRegistration ReplyメッセージはHA-ミネソタの認証拡大を含まなければなりません。(それは、新たに割り当てられたHA-ミネソタセッションキーを使用することによって、作成されます)。 そして、ホームのエージェントはAAAサーバが送り返されるHAAメッセージの一部としてMIPレッジReply AVPにRegistration Replyメッセージと拡大を入れます。
The key derived by the MN from the MN-HA session nonce is identical to the HA-MN session key provided to the HA.
ミネソタによってミネソタ-HAセッション一回だけから引き出されたキーはHAに提供されたHA-ミネソタセッションキーと同じです。
8.4. Distributing the Mobile-Foreign Session Key
8.4. モバイルに外国のセッションキーを分配します。
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
ミネソタ-FAセッション一回だけは、また、AAAH(要求での)が生成されて、FA-MSA AVPへのMIPミネソタに追加されて、ホームのエージェントによってモバイルIPv4 Registration Replyメッセージの「一般化されたミネソタ-ファキー生成一回だけの回答」拡大[MIPKEYS]にコピーされます。(ミネソタは、HARに加えられます)。 また、HAはモバイルによって提案されたSPIsを含んでいます。
Calhoun, et al. Standards Track [Page 36] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[36ページ]。
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.
「一般化されたミネソタ-ファキー生成一回だけの要求」拡大でのノードの、そして、外国人のエージェント。 FA-ミネソタの認証拡大の計算に外国人のエージェントによって使用されるように、AAAHはAMAのMIP-FAからミネソタMSA AVPで主要なFA-ミネソタのセッションを含んでいます。
The key derived by the MN from the MN-FA session nonce is identical to the FA-MN session key provided to the FA.
ミネソタによってミネソタ-FAセッション一回だけから引き出されたキーはFAに提供されたFA-ミネソタセッションキーと同じです。
8.5. Distributing the Foreign-Home Session Key
8.5. 外国ホームセッションキーを分配します。
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セッションキーを要求するなら、それは、ホームのエージェントによってこのために使用されるようにSPIを運ぶためにAMRにMIP-HAからFA-SPI AVPを含んでいます。 AAAHは、FA-HAセッションキーを生成して、それぞれのセキュリティ協会の上でFA-MSAへのMIP-HAとHA-MSA AVPsへのMIP-FAを使用することによって、HAとFAの両方にそれを分配します。(キーはHA-FAセッションキーと同じです)。 HAはFA MUSTがHAAで使用するSPIを運びます。 これはFAが、HA MUSTが後で. AMR AAAHで使用するSPIがセッションキーと共にMIP-FA-HA-MSAとMIP-HA-FA-MSA AVPsにこれらのSPIsをそれぞれ含んでいるのを運ぶ方法と同様です。
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.
複数のMNsが同じFAに登録されて、HAが対にするなら複数の移動性セキュリティ協会が分配されることに注意してください。 しかしながら、1だけが、FAとHAの間のモバイルIPコントロールトラフィックを保護するのに必要です。 これは容認できないレベルの状態(すなわち、それぞれのFA-HA移動性セキュリティ協会のために2SPIsと共有されたキーを保存する)を創設します。 実際に期限が切れる前にスケーラビリティ、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 MUSTはいつも最も遅い満期時間とのFA-HAセキュリティ協会を使用します。 新しいHA-FA移動性セキュリティ協会が後の満期時間と共に到着した10秒後にFA MAYは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
HA SHOULDは送信されるメッセージで認証拡大を計算するとき最も遅い満期時間になるHA-FA移動性セキュリティ協会を使用します。 しかしながら、HAが後の満期時間との新しいHA-FA移動性セキュリティ協会を受けるとき、HA SHOULDは、新連合を使用する前にAMAがFAに伝播するのを4秒待っています。 対応するHAAでモバイルIP Registration Replyを組み立てるとき、HAがHARから移動性セキュリティ協会をいつも使用することに注意してください。 HA MAYはFA-HAの移動性を捨てます。
Calhoun, et al. Standards Track [Page 37] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[37ページ]。
security association once it receives a message authenticated by a FA-HA mobility security association with a later expiry time.
いったんメッセージを受け取ると、セキュリティ協会はFA-HAで後の満期時間との移動性セキュリティ協会を認証しました。
9. Key Distribution AVPs
9. 主要な分配AVPs
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プロトコルはモバイルノードと、外国人のエージェントと、ホームのエージェントの間で共有された1セットの移動性セキュリティ協会を定義します。 これらの3つの移動性セキュリティ協会(ミネソタ-HA、ミネソタ-FA、およびFA-HA)が、AAAHによってダイナミックに創設されて、以前に、セクション3.4と8で説明されます。 DiameterがモバイルIP ApplicationであるとサポートするAAAサーバは、主要な分配が本書では定義されたAVPsであると実装しなければなりません。
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.
主要な分配AVPsという名前は移動性セキュリティ協会を共有する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.
例えば、HA-MSA AVPへのMIPミネソタはミネソタ-HA一回だけを含んでいます、そして、MIP-HAからミネソタMSA AVPはホームのエージェントのためのミネソタ-HAキーを含んでいます。(モバイルノードは、ミネソタ-HA Keyを引き出すのに一回だけを使用するでしょう)。 移動性セキュリティ協会が単方向であることに注意してください。 しかしながら、このアプリケーションは2人の同輩の間に存在する両方の単方向のセキュリティ関係の間で共有される1個のキーだけを提供します。 セクション13で各方向に同じキーを使用するセキュリティ問題を与えます。 SPIsはしかしながら、それぞれの単方向のセキュリティ協会にユニークであり、そのセキュリティ関係と共に認証されたモバイル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アプリケーション、彼らのAVP Code値、タイプ、および可能な旗の値で定義されたDiameter AVPsについて説明します。
Calhoun, et al. Standards Track [Page 38] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[38ページ]。
+--------------------------+
| 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 |
+--------------------------+ | AVP旗の規則| |----+-----+----+-----|----+ AVP部| | |SHLD| 必須|5月| 属性名前コードは値のタイプを定義しました。|必須| 5月| NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| ハ、SPIへのMIPファ318、9.11Unsigned32| M| P| | V| Y| MIPファからMn SPIへの319、9.10Unsigned32| M| P| | V| Y| MIP、ファSPI、ハ、323、9.14Unsigned32| M| P| | V| Y| MIPミネソタからファMSAへの325 9.5は分類されました。| M| P| | V| Y| MIPファからMn MSAへの326 9.1は分類されました。| M| P| | V| Y| ハ、MSAへのMIPファ328 9.2は分類されました。| M| P| | V| Y| MIP、ファMSA、ハ、329 9.3は分類されました。| M| P| | V| Y| ハ、MSAへのMIPミネソタ331 9.6は分類されました。| M| P| | V| Y| MIP、Mn MSA、ハ、332 9.4は分類されました。| M| P| | V| Y| MIP-一回だけ335、9.12OctetString| M| P| | V| Y| MIPセッションキー343 9.7OctetString| M| P| | V| Y| 列挙されたMIPアルゴリズム-345 9.8| M| P| | V| Y| 346 9.9が列挙したMIP再生モードをタイプしてください。| M| P| | V| Y| MIP-MSA-生涯367、9.13Unsigned32| M| P| | V| Y|
9.1. MIP-FA-to-MN-MSA AVP
9.1. MIPファからMn MSA AVP
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からミネソタMSA AVP(AVP Code326)はタイプGroupedにはあって、FA-ミネソタセッションキーを含んでいます。 このAVPはAMAメッセージのFAまで運ばれます。 ミネソタはMIP-FAからミネソタSPIを割り当てます。 FAはセッションキーとアルゴリズムを使用することによって、FA-ミネソタの認証拡大を作成します、そして、ミネソタは同じセッションキーとアルゴリズムを使用することによって、その拡大について確かめます。 このAVPのデータ・フィールドには、以下のABNF文法があります:
MIP-FA-to-MN-MSA ::= < AVP Header: 326 >
{ MIP-FA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
MIPファからMn MSA:、:= <AVPヘッダー: 326 >MIPファからMn SPIへのMIPアルゴリズムタイプMIPセッションキー*[AVP]
9.2. MIP-FA-to-HA-MSA AVP
9.2. ハ、MSA AVPへのMIPファ
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からHA-MSA AVP(AVP Code328)はタイプGroupedにはあって、FA-HAセッションキーを含んでいます。 このAVPはAMAメッセージのFAまで運ばれます。 HAはMIP-FAからHA-SPIを割り当てます。 FAはセッションキーとアルゴリズムを使用することによって、FA-HA認証拡張子を作成します、そして、HAは同じキーとアルゴリズムを使用することによって、その拡大について確かめます。 AVPのデータ・フィールドには、以下のABNF文法があります:
Calhoun, et al. Standards Track [Page 39] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[39ページ]。
MIP-FA-to-HA-MSA ::= < AVP Header: 328 >
{ MIP-FA-to-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
ハ、MSAへのMIPファ:、:= <AVPヘッダー: 328 >ハ、SPIへのMIPファMIPアルゴリズムタイプMIPセッションキー*[AVP]
9.3. MIP-HA-to-FA-MSA AVP
9.3. MIP、ファMSA 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からFA-MSA AVP(AVP Code329)はタイプGroupedにはあって、ホームのエージェントのセッションキーを含んでいます。(それは外国人のエージェントとそれを共有します)。 このAVPはHARメッセージのHAまで運ばれます。 FAはMIP-HAから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 ]
MIP、ファMSA、ハ、:、:= <AVPヘッダー: 329>、MIP、ファSPI、ハ、MIPアルゴリズムタイプMIPセッションキー*[AVP]
9.4. MIP-HA-to-MN-MSA AVP
9.4. MIP、Mn MSA 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からミネソタMSA AVP(AVP Code332)はタイプGroupedにはあって、HA-ミネソタセッションキーを含んでいます。 このAVPは並べたCOAモバイルIPv4のためにFA COAのモバイルIPv4のためのHARとAMAのHAまで運ばれます。 ミネソタはMIP-HAからミネソタSPIを割り当てます。 HAはセッションキーとアルゴリズムを使用することによって、HA-ミネソタの認証拡大を作成します、そして、ミネソタは同じキーとアルゴリズムを使用することによって、その拡大について確かめます。 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 ]
MIP、Mn MSA、ハ、:、:= <AVPヘッダー: 332>、MIP、Mn SPI、ハ、MIPアルゴリズムタイプMIP再生モードMIPセッションキー*[AVP]
9.5. MIP-MN-to-FA-MSA AVP
9.5. MIPミネソタからファMSA 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ミネソタからFA-MSA AVP(AVP Code325)はタイプGroupedにはあって、ミネソタ-FAセッション一回だけを含んでいます。(モバイルノードは、ミネソタ-FAセッションキーを引き出すのにそれを使用します)。 このAVPはHARメッセージのHAまで運ばれます。 FAはFA-SPIへのMIPミネソタを割り当てます。 ミネソタはセッションキーとアルゴリズムを使用することによって、ミネソタ-FA認証拡張子を作成します、そして、FAは同じキーとアルゴリズムを使用することでその拡大について確かめます。
Calhoun, et al. Standards Track [Page 40] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[40ページ]。
The home agent uses this AVP in the construction of the Mobile IP "Generalized MN-FA Key Generation Nonce Reply" extension [MIPKEYS].
ホームのエージェントはモバイルIP「一般化されたミネソタ-ファキー生成一回だけの回答」拡大[MIPKEYS]の構造にこのAVPを使用します。
MIP-MN-to-FA-MSA ::= < AVP Header: 325 >
{ MIP-MN-FA-SPI }
{ MIP-Algorithm-Type }
{ MIP-nonce }
* [ AVP ]
MIPミネソタからファMSA:、:= <AVPヘッダー: 325 >MIP MnファSPI MIPアルゴリズムタイプMIP-一回だけ*[AVP]
9.6. MIP-MN-to-HA-MSA AVP
9.6. ハ、MSA AVPへのMIPミネソタ
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ミネソタからHA-MSA AVP(AVP Code331)はタイプGroupedにはあって、ミネソタ-HAセッション一回だけを含んでいます。(モバイルノードは、ミネソタ-HAセッションキーを引き出すのにそれを使用します)。 このAVPは並べたモバイルIPv4のためにFA COAのモバイルIPv4へのHARメッセージとAMRのHAまで運ばれます。 HAはHA-SPIへのMIPミネソタを割り当てます。 ミネソタはセッションキーとアルゴリズムを使用することでミネソタ-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の構造にこのAVPを使用する、「総合、Mn、-、ハ、キー生成の一回だけの回答」 拡大[MIPKEYS。]
MIP-MN-to-HA-MSA ::= < AVP Header: 331 >
{ MIP-MN-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-nonce }
* [ AVP ]
ハ、MSAへのMIPミネソタ:、:= <AVPヘッダー: 331>、ハ、MIPミネソタSPI、MIPアルゴリズムタイプMIP再生モードMIP-一回だけ*[AVP]
9.7. MIP-Session-Key AVP
9.7. MIPセッションキー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セッションキーAVP(AVP Code343)は関連モバイルIPv4認証拡張子のためにタイプOctetStringにはあって、Session Keyを含んでいます。 HAAAはセッションキーを選択します。
9.8. MIP-Algorithm-Type AVP
9.8. MIPアルゴリズムタイプAVP
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アルゴリズムタイプAVP(AVP Code345)は関連モバイルIPv4認証拡張子のためにタイプEnumeratedにはあって、Algorithm識別子を含んでいます。 HAAAはアルゴリズムタイプを選びます。 以下の値は現在、定義されます:
2 HMAC-SHA-1 [HMAC]
2 HMAC-SHA-1[HMAC]
Calhoun, et al. Standards Track [Page 41] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[41ページ]。
9.9. MIP-Replay-Mode AVP
9.9. MIP再生モードAVP
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再生モードAVP(AVP Code346)はタイプEnumeratedにはあって、再生モードを含んでいます。モバイルノードを認証するためのホームのエージェント。 HAAAは再生モードを選択します。
The following values are supported (see [MOBILEIP] for more information):
以下の値はサポートされます(詳しい情報に関して[MOBILEIP]を見てください):
1 None
2 Timestamps
3 Nonces
1、なにも、2つのタイムスタンプ3の一回だけ
9.10. MIP-FA-to-MN-SPI AVP
9.10. MIPファからMn SPI AVP
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].
タイプUnsigned32にはMIP-FAからミネソタSPI AVP(AVP Code319)があります、そして、それはそれとミネソタがFA-ミネソタ移動性セキュリティ協会について言及するのに使用するSecurity Parameter Index FAを含んでいます。 ミネソタはSPIを割り当てます、そして、それは(0)がなくて255の間に値を持ってはいけません。255は[MOBILEIP]で定義された予約された名前空間です。
9.11. MIP-FA-to-HA-SPI AVP
9.11. ハ、SPI AVPへのMIPファ
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からHA-SPI AVP(AVP Code318)はタイプUnsigned32にはあって、FAとHAがFA-HA移動性セキュリティ協会について言及するのに使用するSecurity Parameter Indexを含んでいます。 HAはSPIを割り当てます、そして、それは(0)がなくて255の間に値を持ってはいけません。255は[MOBILEIP]で定義された予約された名前空間です。
9.12. MIP-Nonce AVP
9.12. MIP-一回だけAVP
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-一回だけAVP(AVP Code335)は関連認証拡大のためにタイプOctetStringにはあって、モバイルノードに送られた一回だけを含んでいます。 モバイルノードは、モバイルIPv4登録メッセージを認証するのに使用されるセッションキーを生成するために[MIPKEYS]で手順に従います。 HAAAは一回だけを選択します。
9.13. MIP-MSA-Lifetime AVP
9.13. MIP-MSA-生涯AVP
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-生涯AVP(AVP Code367)はタイプUnsigned32にはあって、セッションキーか一回だけが有効である期間(秒の)を表します。 寿命が期限が切れたなら、合同会議キーか一回だけを場合によって使用してはいけません。 それが適用されるセッションがまだ活発ですが、セッションの主要であるか一回だけの寿命が期限が切れるなら、セッションキーか一回だけを変えなければなりませんか、または協会のモバイルIPv4セッションを終えなければなりません。
Calhoun, et al. Standards Track [Page 42] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[42ページ]。
9.14. MIP-HA-to-FA-SPI AVP
9.14. MIP、ファSPI AVP、ハ。
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からFA-SPI AVP(AVP Code323)はタイプUnsigned32にはあって、HAとFAがHA-FA移動性セキュリティ協会について言及するのに使用するSecurity Parameter Indexを含んでいます。 FAはSPIを割り当てます、そして、それは(0)がなくて255の間に値を持ってはいけません。255は[MOBILEIP]で定義された予約された名前空間です。
10. Accounting AVPs
10. 会計AVPs
10.1. Accounting-Input-Octets AVP
10.1. 会計入力八重奏AVP
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入力八重奏AVP(AVP Code363)はユーザから受け取られたIPパケットに、タイプUnsigned64にはあって、八重奏の数を含んでいます。 このAVP MUSTはすべてのAccounting-要求メッセージに含まれていて、また、対応するAccounting-答えメッセージに存在しているかもしれません。
10.2. Accounting-Output-Octets AVP
10.2. 会計出力八重奏AVP
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出力八重奏AVP(AVP Code364)はユーザに送られたIPパケットに、タイプUnsigned64にはあって、八重奏の数を含んでいます。 このAVP MUSTはすべてのAccounting-要求メッセージに含まれていて、また、対応するAccounting-答えメッセージに存在しているかもしれません。
10.3. Acct-Session-Time AVP
10.3. Acctセッション時間AVP
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-時間AVP(AVP Code46)は秒にタイプUnsigned32にはあって、現在のセッションの長さを示します。 このAVP MUSTはすべてのAccounting-要求メッセージに含まれていて、また、対応するAccounting-答えメッセージに存在しているかもしれません。
10.4. Accounting-Input-Packets AVP
10.4. 会計入力パケットAVP
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がパケットを入力していたのが、タイプUnsigned64にはあって、ユーザから受け取られたIPパケットの数を含んでいます(AVP Code365)。 このAVP MUSTはすべてのAccounting-要求メッセージに含まれていて、また、対応するAccounting-答えメッセージに存在しているかもしれません。
10.5. Accounting-Output-Packets AVP
10.5. 会計出力パケットAVP
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がパケットを出力していたのが、タイプUnsigned64にはあって、ユーザに送られたIPパケットの数を含んでいます(AVP Code366)。 このAVP MUSTはすべてのAccounting-要求メッセージに含まれていて、また、対応するAccounting-答えメッセージに存在しているかもしれません。
Calhoun, et al. Standards Track [Page 43] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[43ページ]。
10.6. Event-Timestamp AVP
10.6. イベントタイムスタンプAVP
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-タイムスタンプ(AVP Code55)は、タイプTimeにはあって、1970年1月1日の以来秒のこのイベントが移動性エージェントの上に起こった時代に記録するAccounting-要求メッセージで含められるかもしれません、協定世界時0時0分。
11. AVP Occurrence Tables
11. AVP発生テーブル
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.
以下のテーブルは本書では定義されたAVPsとDiameterメッセージにおける彼らの発生を提示します。 Grouped AVPの中に存在するだけである場合があるAVPsがこのテーブルに表されないことに注意してください。
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.
0、AVP MUST NOT、メッセージに存在してください。 0 ゼロか以上が現在のコネがメッセージであったならAVP MAYについて例証する+。 ゼロかものが現在のコネがメッセージであったならAVP MAYについて例証する0--1。 ものが現在のコネがメッセージであったならAVP MUSTについて例証する1。
11.1. Mobile IP Command AVP Table
11.1. モバイルIPコマンドAVPテーブル
The table in this section is limited to the Command Codes defined in this specification.
このセクションのテーブルはこの仕様に基づき定義されたCommand Codesに制限されます。
+-----------------------+
| 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 |
+-----------------------+ | コマンドコード| |-----+-----+-----+-----+ 属性名| AMR| 海部| HAR| HAA| ------------------------------|-----+-----+-----+-----+ 承認生涯| 0-1 | 0-1 | 1 | 0 | Authアプリケーションイド| 1 | 1 | 1 | 1 | Authセッション状態| 0-1 | 0-1 | 1 | 0 | Acctマルチセッションイド| 0-1 | 0-1 | 0 | 0-1 | あて先ホスト| 0-1 | 0 | 0-1 | 0 | 目的地分野| 1 | 0 | 1 | 0 | エラーメッセージ| 0 | 0-1 | 0 | 0-1 | エラー報告ホスト| 0 | 0-1 | 0 | 0-1 | MIP候補ホームエージェントのホスト| 0-1 | 0 | 0-1 | 0 | MIPホームエージェントのホスト| 0-1 | 0 | 0-1 | 0 | 外国AAAを溯源するMIP| 0-1 | 0 | 0-1 | 0 | MIPファ挑戦| 0-1 | 0 | 0 | 0 | MIPファからMn MSA| 0 | 0-1 | 0 | 0 | ハ、MSAへのMIPファ| 0 | 0-1 | 0 | 0 | MIP、ファMSA、ハ。| 0 | 0 | 0-1 | 0 | MIP、Mn MSA、ハ。| 0 | 0-1 | 0-1 | 0 |
Calhoun, et al. Standards Track [Page 44] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[44ページ]。
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ミネソタからファMSA| 0 | 0 | 0-1 | 0 | ハ、MSAへのMIPミネソタ| 0 | 0-1 | 0-1 | 0 | ハ、SPIへのMIPファ| 0 | 0 | 0 | 0-1 | MIP、ファ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ファからMn SPI| 0 | 0 | 0 | 0-1 | MIPミネソタからファ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 |
------------------------------|-----+-----+-----+-----|
MIP、Mn SPI、ハ。| 0 | 0 | 0 | 0-1 | ハ、SPIへのMIPミネソタ| 0 | 0 | 0 | 0-1 | MIP特徴ベクトル| 0-1 | 0-1 | 1 | 0 | MIPフィルタ規則| 0 | 0+ | 0+ | 0 | MIPホームエージェントアドレス| 0-1 | 0-1 | 0-1 | 0-1 | MIP-MSA-生涯| 0 | 0-1 | 0-1 | 0 | MIP Mn AAA Auth| 1 | 0 | 0 | 0 | MIPのモバイルノードアドレス| 0-1 | 0-1 | 0-1 | 0-1 | MIPレッジReply| 0 | 0-1 | 0 | 0-1 | MIPレッジRequest| 1 | 0 | 1 | 0 | 発生源ホスト| 1 | 1 | 1 | 1 | 発生源分野| 1 | 1 | 1 | 1 | 発生源州のイド| 0-1 | 0-1 | 0-1 | 0-1 | プロキシインフォメーション| 0+ | 0+ | 0+ | 0+ | 再直接のホスト| 0 | 0+ | 0 | 0+ | ホスト用法を向け直してください。| 0 | 0-1 | 0 | 0-1 | マックスキャッシュ時間を向け直してください。| 0 | 0-1 | 0 | 0-1 | 結果コード| 0 | 1 | 0 | 1 | 再Authはタイプを要求します。| 0 | 0-1 | 0 | 0 | ルート記録| 0+ | 0 | 0+ | 0 | セッションイド| 1 | 1 | 1 | 1 | ユーザ名| 1 | 0-1 | 1 | 0-1 | ------------------------------|-----+-----+-----+-----|
Calhoun, et al. Standards Track [Page 45] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[45ページ]。
11.2. Accounting AVP Table
11.2. 会計AVPテーブル
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].
このセクションのテーブルによる本書では定義されたどのAVPsを表すかに使用されているのは、Accountingメッセージに存在していることです、[DIAMBASE]で定義されるようにことです。
+-------------+
| 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 |
-------------------------------------|------+------+
+-------------+ | コマンドコード| |------+------+ 属性名| ACR| ACA| -------------------------------------|------+------+ 会計入力八重奏| 1 | 0-1 | 会計入力パケット| 1 | 0-1 | 会計出力八重奏| 1 | 0-1 | 会計出力パケット| 1 | 0-1 | Acctマルチセッションイド| 1 | 0-1 | Acctセッション時間| 1 | 0-1 | MIP特徴ベクトル| 1 | 0-1 | MIPホームエージェントアドレス| 1 | 0-1 | MIPのモバイルノードアドレス| 1 | 0-1 | イベントタイムスタンプ| 0-1 | 0 | -------------------------------------|------+------+
12. IANA Considerations
12. IANA問題
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によって管理された既存の名前空間にそれらの値を割り当てさせました。
12.1. Command Codes
12.1. コマンドコード
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]で定義されたCommand Code名前空間から値260と262を割り当てます。 この仕様に基づく、名前空間の課題に関してセクション5を見てください。
12.2. AVP Codes
12.2. AVPコード
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を見てください。
12.3. Result-Code AVP Values
12.3. 結果コードAVP値
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.
この仕様は4008と4005--5024を値に割り当てます--[DIAMBASE]で定義されたResult-コードAVP(AVP Code268)値の名前空間からの5025。 この仕様に基づく、名前空間の課題に関してセクション6を見てください。
Calhoun, et al. Standards Track [Page 46] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[46ページ]。
12.4. MIP-Feature-Vector AVP Values
12.4. MIP特徴ベクトルAVP値
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].
32ビットが課題に利用可能なMIP特徴ベクトルAVP(AVP Code337)にあります。 このドキュメントはセクション7.5で記載されているようにビット1--9を割り当てます。 残っているビットはStandards Action[IANA]を通して割り当てられるだけであるべきです。
12.5. MIP-Algorithm-Type AVP Values
12.5. MIPアルゴリズムタイプAVP値
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 Code345)が値2を定義するので ゼロ以外のすべての残余価値がDesignated Expert[IANA]を通して課題に利用可能です。
12.6. MIP-Replay-Mode AVP Values
12.6. MIP再生モードAVP値
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再生モードAVP(AVP Code346)は値1--3を定義します。 ゼロ以外のすべての残余価値がDesignated Expert[IANA]を通して課題に利用可能です。
12.7. Application Identifier
12.7. アプリケーション識別子
This specification uses the value two (2) to the Application Identifier namespace defined in [DIAMBASE]. See section 4 for more information.
この仕様はApplication Identifier名前空間への2(2)が[DIAMBASE]で定義した値を使用します。 詳しい情報に関してセクション4を見てください。
13. Security Considerations
13. セキュリティ問題
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 Applicationについて説明します。 使用される認証アルゴリズムはモバイルIPv4プロトコル、および[MIPCHAL]の中で使用された変換に依存しています。 また、[MIPKEYS]に関連して、この仕様はホームDiameterサーバが認証していて保全を保護するモバイルIPv4登録メッセージ[MOBILEIP]における使用のためにセッションキーと一回だけを作成して、分配できるメソッドを定義します。 主要な分配は非対称です、モバイルノードとのコミュニケーションがDiameterプロトコルでモバイルIPv4プロトコル[MIPKEYS、MOBILEIP](ホームのエージェントとForeignへのコミュニケーションとして、エージェントは起こる)で現れるとき。 信頼されていないDiameterエージェントが出席しているところでは、終わりから終わりへのセキュリティを使用しなければなりません。 終わりから終わりへのセキュリティはAAAHとFAとAAAHとHAとのTLSかIPSecセキュリティ協会の形を取ります。 これらの接続は公開鍵と証明書の使用で認証されるでしょう。 しかしながら、AAAHが安全にキーの分配を始めることができる前に、証明書に現れるアイデンティティは、特定のモバイルIPv4 Diameterセッションまで認可されて、バウンドしなければなりません。
Calhoun, et al. Standards Track [Page 47] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[47ページ]。
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-ホストAVPを含む再直接の応答を得ます。 これは安全な接続が確立されるときAAAHによって提示された証明書に取り組まされるべきであるアイデンティティです。 この場合、Diameterプロキシと再直接のエージェントのネットワークは正しいAAAHのアイデンティティを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のアイデンティティを含んでいるのでTLSの設立を認可するかもしれないオリジナルのAMRメッセージを観測して、注意したかもしれないということであるか、そして、同じ実体からのIPSec接続。 さもなければ、AAAHはすべてのリストが訪問されたドメイン(ローミングパートナー)を認可したと主張するのが必要であり、このリストに基づくTLSかIPSec接続に権限を与えるでしょう。 接続の唯一の設立が第一歩であり、AAAHにはAMRメッセージ自体を受け取り次第サービスを否定する別の機会があることに注意してください。 このステップでは、AAAHはFAが確実に有効になるようにするためにAMRの内部のAVPsをチェックできます。 例えば、モバイルIP COAがTLSかIPSec接続の終点として使用されるIPアドレスと等しいのはチェックできます。 しかしながら、そのような方針は、AAAとモバイルIPトンネルパケットのためにFAが異なったインタフェースを使用するのを防いで、あらゆる展開状況で望ましいかもしれないというわけではありません。
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のアイデンティティをAMRのAAAHに与えます、そして、AAAHはTLSかIPSec交渉の間、公開鍵証明書の同じアイデンティティを受けると予想するはずです。 それ自身の再直接のサーバとして機能することによって、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
このアプリケーションは、各組のMSAsに、主要なただ一つのセッションを2つの実体の間に作成して、広げます。 例えば同じセッションキーはミネソタ-HA MSAとHA-MN MSAに使用されます。 これはセキュリティ見解からするために安全です、セッションキーがそれぞれのモバイルIPコントロールメッセージの保全を保護する固有識別文字値を生成するのに合わせられたハッシュ関数と共に使用されるだけであるとき。 モバイルIPメッセージにはタイムスタンプか一回だけ[MOBILEIP]の使用による内蔵の反復操作による保護があって、プロトコルの本質で、要求がいつも異なっている、応答(少なくともメッセージタイプがコード化するコネ)から、bitwiseします。 これは他の状況で起こるかもしれない問題を避けます。
Calhoun, et al. Standards Track [Page 48] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[48ページ]。
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.
攻撃者が再生か反射攻撃を仕掛けることができたところでは、同じキーが(例えば)1つ以上の接続のときにそうでなければ、保護のないトラフィックを暗号化するのに使用されたなら、ネットワークで急いで歩いてください。
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一方向関数でセッションキーを生成するのに使用されます)。 一回だけと認証拡大がRegistration Replyのクリアテキストコピーへのアクセスでだれによっても観測されるかもしれないので、十分なエントロピーを含んでいないなら、モバイルノードとホームDiameterサーバの間のあらかじめ共有されたキーはオフライン辞書攻撃に被害を受け易いでしょうに。 これを防ぐために、あらかじめ共有にされるのは少なくとも手当たりしだいに選ばれた量の96がビットであったならモバイルノードとホームDiameterサーバの間でSHOULDを合わせます。
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.
セッションキーが断固としているので、長期の秘密と一回だけ、一回だけのSHOULDで、時間的とグローバルにユニークであってください。 一回だけが繰り返されるなら、セッションキーもそうするでしょうに。 これを防ぐために、一回だけは少なくとも128ビットの無作為の[RANDOM]価値であることが強く推薦されます。 ミネソタとAAAH MUSTの間の長期の秘密が定期的にリフレッシュされて、長期の秘密の回復に用心するのは一回だけの再利用か他の要素がそうします。 これは、バンドの外でメカニズムを使用することによって、達成されます。(メカニズムは本書では指定されません)。
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-生涯AVP価値をゼロに設定することは勧められないことに注意してください、長い間(いいえはリフレッシュする)セッションキーを保つと脆弱性のレベルが増強されるのに従って。
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[DIAMBASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
J. Arkko, "Diameter Base Protocol", RFC 3588,
September 2003.
[DIAMBASE] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、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、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[MOBILEIP] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[MOBILEIP] パーキンス、C.、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
Calhoun, et al. Standards Track [Page 49] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[49ページ]。
[MIPCHAL] Perkins, C. and P. Calhoun, "Mobile IPv4
Challenge/Response Extensions", RFC 3012, November
2000.
[MIPCHAL] パーキンスとC.とP.カルフーン、「モバイルIPv4挑戦/応答拡大」、RFC3012、2000年11月。
[NAI] Aboba, B. and M. Beadles, "The Network Access
Identifier", RFC 2486, January 1999.
[NAI] AbobaとB.とM.用務員、「ネットワークアクセス識別子」、RFC2486、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.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[MIPKEYS] Perkins, C. and P. Calhoun, "Authentication,
Authorization, and Accounting (AAA) Registration Keys
for Mobile IP", RFC 3957, March 2005.
[MIPKEYS]パーキンスとC.とP.カルフーン、「モバイルIPのための認証、承認、および会計(AAA)登録キー」、RFC3957、2005年3月。
[AAANAI] Johansson, F. and T. Johansson, "Mobile IPv4 Extension
for Carrying Network Access Identifiers", RFC 3846,
June 2004.
[AAANAI] ヨハンソンとF.とT.ヨハンソン、「ネットワークアクセス識別子を運ぶためのモバイルIPv4拡張子」、RFC3846、2004年6月。
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[IPSEC] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、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]ブレーク-ウィルソン、S.、ニストロム、M.、Hopwood(D.、ミッケルセン、J.、およびT.ライト)は「層のセキュリティ(TLS)拡大を輸送します」、RFC3546、2003年6月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
14.2. Informative References
14.2. 有益な参照
[MIPREQ] Glass, S., Hiller, T., Jacobs, S., and C. Perkins,
"Mobile IP Authentication, Authorization, and
Accounting Requirements", RFC 2977, October 2000.
[MIPREQ] ガラス、S.、ヒラー、T.、ジェイコブズ、S.、およびC.パーキンス、「モバイルIP認証、承認、および会計要件」、RFC2977(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]ヒラー、T.、ウォルシュ、P.、チェン、X.、ムンソン、M.、Dommety、G.、Sivalingham、S.、リム、B.、マッキャン、P.、Shiino、H.、ヒルシュマン、B.、マニング、S.、シュー、R.、クー、H.、Lipford、M.、カルフーン、P.、見よ、C.、ジャキュース、E.、キャンベル、E.、シュー、Y.、馬場、S.、Ayaki、T.、瀬木、T.とA.ハミード、「AAAのためのCDMA2000のワイヤレスのデータ要件」RFC3141、2001年6月。
[EVALROAM] Aboba, B. and G. Zorn, "Criteria for Evaluating
Roaming Protocols", RFC 2477, January 1999.
[EVALROAM] AbobaとB.とG.ゾルン、「ローミングプロトコルを評価する評価基準」、RFC2477、1999年1月。
[MIPNAI] Calhoun, P. and C. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC 2794, March 2000.
[MIPNAI] カルフーンとP.とC.パーキンス、「IPv4"、RFC2794、2000年3月のためのモバイルIPネットワークアクセス識別子拡張子。」
Calhoun, et al. Standards Track [Page 50] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[50ページ]。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
イーストレークとD.と3番目、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」[無作為]のBCP106、2005年6月のRFC4086。
15. Acknowledgements
15. 承認
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 Document Readingパーティへの彼らの参加についてネナンドTrifunovic、Haseeb Akhtar、およびPankajパテルに感謝したがっています。 彼の非常に役に立つ提案されたテキストのためのエリックGuttman。 フレドリック・ヨハンソンへのマーチンジュリアン、およびそれらの非常に役に立つ寄付されたテキストのためのボブ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ワーキンググループの関係者に感謝したがっています: ケビンパーサー、トーマス・パナギオティスはエクルンド、ポールFunk、マイケル・チェン、ヘンリーHaverinen、およびジョハン・ヨハンソンにマークします。 Diameter-EAPからパシEronenによる一般再直接のサーバテキストを借りました。
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.
パットCalhounはサン・マイクロシステムズに感謝したがっています、彼らの雇用には彼がいた間、このドキュメントにそそがれた努力の大部分をしたように。
Authors' Addresses
作者のアドレス
Questions about this memo can be directed to:
このメモに関する質問による以下のことよう指示できます。
Pat Calhoun Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
西タスマン・DriveパットカルフーンシスコシステムズInc.170カリフォルニア95134サンノゼ(米国)
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
トニーヨハンソンBytemobile Inc.2029ステアリン・法廷マウンテンビュー、カリフォルニア 94043
Phone: +1 650-641-7817 Fax: +1 650-641-7701 EMail: tony.johansson@bytemobile.com
以下に電話をしてください。 +1 650-641-7817Fax: +1 650-641-7701 メールしてください: tony.johansson@bytemobile.com
Calhoun, et al. Standards Track [Page 51] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[51ページ]。
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA
チャールズE.パーキンスノキアリサーチセンター313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
Phone: +1 650-625-2986 Fax: +1 650-625-2502 EMail: Charles.Perkins@nokia.com
以下に電話をしてください。 +1 650-625-2986Fax: +1 650-625-2502 メールしてください: Charles.Perkins@nokia.com
Tom Hiller Lucent Technologies 1960 Lucent Lane Naperville, IL 60566 USA
トムヒラールーセントテクノロジーズ1960の透明なLane IL60566ナパービル(米国)
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
ピーターJ.マッキャンルーセントテクノロジーズ1960の透明なLane IL60563ナパービル(米国)
Phone: +1 630-713-9359 Fax: +1 630-713-1921 EMail: mccap@lucent.com
以下に電話をしてください。 +1 630-713-9359Fax: +1 630-713-1921 メールしてください: mccap@lucent.com
Calhoun, et al. Standards Track [Page 52] RFC 4004 Diameter MIP August 2005
カルフーン、他 規格は直径MIP2005年8月にRFC4004を追跡します[52ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Calhoun, et al. Standards Track [Page 53]
カルフーン、他 標準化過程[53ページ]
一覧
スポンサーリンク
