RFC3141 日本語訳
3141 CDMA2000 Wireless Data Requirements for AAA. T. Hiller, P. Walsh,X. Chen, M. Munson, G. Dommety, S. Sivalingham, B. Lim, P. McCann, H.Shiino, B. Hirschman, S. Manning, R. Hsu, H. Koo, M. Lipford, P.Calhoun, C. Lo, E. Jaques, E. Campbell,Y.Xu,S.Baba,T.Ayaki,T.Seki,A.Hameed. June 2001. (Format: TXT=27998 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Hiller, Lucent Technologies
Request for Comments: 3141 P. Walsh, Lucent Technologies
Category: Informational X. Chen, Alcatel
M. Munson
G. Dommety, Cisco Systems
S. Sivalingham, Ericsson Wireless Communications
B. Lim, LG Information & Communications, Ltd.
P. McCann, Lucent Technologies
H. Shiino, Lucent Technologies
B. Hirschman, Motorola
S. Manning, Award Solutions, Inc.
R. Hsu, Qualcomm, Inc.
H. Koo, Samsung Telecommunications America, Inc.
M. Lipford, Sprint PCS
P. Calhoun, Sun Laboratories, Inc.
C. Lo, Vodafone
E. Jaques, Vodafone
E. Campbell, CommWorks Corporation, A 3Com Company
Y. Xu, WaterCove Networks
S. Baba, Toshiba America Research, Inc.
T. Ayaki, DDI Corporation
T. Seki, DO Corporation
A. Hameed, Fujitsu
June 2001
ワーキンググループのT.ヒラーをネットワークでつないでください、そして、ルーセントテクノロジーズはコメントのために以下を要求します。 3141 P.ウォルシュ、ルーセントテクノロジーズカテゴリ: 情報のX.チェン、アルカテルM.ムンソンG.Dommety、S.Sivalingham、シスコシステムズエリクソン無線通信B.リムとLG情報とLtd.のP.マッキャン、ルーセントテクノロジーズH.Shiino、コミュニケーションルーセントテクノロジーズのB.ヒルシュマン(モトローラのS.マニング)はInc.R.シュー、クアルコムInc.Hをソリューションに与えます; クー、三星テレコミュニケーションアメリカInc.M.Lipford、短距離競走PCS P.カルフーン、Sun研究所Inc.C.最低気温、ボーダフォンのE.ジャキュース、ボーダフォンのE.キャンベル、CommWorks社、3Com会社Y.シュー、WaterCoveネットワークS.馬場、東芝アメリカ研究Inc.T.Ayaki(株式会社ディーディーアイのT.瀬木)は社のA.ハミードをします、富士通2001年6月
CDMA2000 Wireless Data Requirements for AAA
AAAのためのCDMA2000のワイヤレスのデータ要件
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This memo specifies cdma2000 wireless data AAA (Authentication, Authorization, Accounting) requirements associated with third generation wireless architecture that supports roaming among service providers for traditional PPP and Mobile IP services.
このメモは伝統的なPPPとモバイルIPサービスのためにサービスプロバイダーの中でローミングをサポートする第三世代ワイヤレスアーキテクチャに関連しているcdma2000のワイヤレスのデータAAA(認証、Authorization、Accounting)要件を指定します。
Hiller, et al. Informational [Page 1] RFC 3141 CDMA2000 Wireless Data Requirements June 2001
ヒラー、他 情報の[1ページ]RFC3141CDMA2000ワイヤレスデータ要件2001年6月
1. Introduction
1. 序論
The architecture is designed for use with a cellular network as an access medium. Sections 1, 2, present a brief high level review of the cdma2000 wireless data architecture. Section 3 presents cdma2000 AAA requirements.
アーキテクチャは使用のためにセルラー・ネットワークと共にアクセス媒体として設計されています。 セクション1、2 cdma2000のワイヤレスのデータアーキテクチャの簡潔な高い平らなレビューを提示してください。 セクション3はcdma2000AAA要件を提示します。
This document specifies AAA requirements associated with a third generation cdma2000 wireless architecture that supports roaming among service providers for traditional PPP and Mobile IP services. The architecture is designed for use with a cellular network as an access medium.
このドキュメントは伝統的なPPPとモバイルIPサービスのためにサービスプロバイダーの中でローミングをサポートする第三世代のcdma2000のワイヤレスのアーキテクチャに関連しているAAA要件を指定します。 アーキテクチャは使用のためにセルラー・ネットワークと共にアクセス媒体として設計されています。
Sections 1 and 2 present a brief, high level review of the cdma2000 wireless data architecture as an aid to interested AAA WG members. Section 3 presents cdma2000 AAA requirements, and is self contained relative to the architecture review.
セクション1と2は関心があるAAA WGメンバーへの援助としてcdma2000のワイヤレスのデータアーキテクチャの簡潔で、高い平らなレビューを提示します。 セクション3は、cdma2000AAA要件を提示して、アーキテクチャレビューに比例して自給自足です。
1.1. Requirements language
1.1. 要件言語
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119].
そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、[RFC2119]で説明されるように解釈されることになっていてください、」であるべきです
Please note that the requirements specified in this document are to be used in evaluating AAA protocol submissions. As such, the requirements language refers to capabilities of these protocols; the protocol documents will specify whether these features are required, recommended, or optional. For example, requiring that a protocol support confidentiality is NOT the same thing as requiring that all protocol traffic be encrypted.
本書では指定された要件はAAAプロトコル差出を評価する際に使用されることです。 そういうものとして、要件言語はこれらのプロトコルの能力について言及します。 プロトコルドキュメントは、これらの特徴が必要であるか、お勧め、または任意であるかを指定するでしょう。 例えば、プロトコルサポート秘密性がすべてがトラフィックについて議定書の中で述べるのが必要であるのと同じものでないことは必要であることで、暗号化されてください。
A protocol submission is not compliant if it fails to satisfy one or more of the MUST or MUST NOT requirements for the capabilities that it implements. A protocol submission that satisfies all the MUST, MUST NOT, SHOULD and SHOULD NOT requirements for its capabilities is said to be "unconditionally compliant"; one that satisfies all the MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT requirements for its protocols is said to be "conditionally compliant."
1つか以上を満たさないならプロトコル提案が対応でない、それが実装する能力のためのNOT要件はそうしなければなりません。 すべてを満たすプロトコル提案、NOT、能力のためのSHOULDとSHOULD NOT要件は「無条件に言いなりになる」と言われています;でなければならない すべてを満たすもの、プロトコルのためのすべてのSHOULDかSHOULD NOT要件だけが「条件付きに言いなりになる」と言われているというわけではないというNOT要件はそうしなければなりません。
1.2. General Service Requirements
1.2. ゼネラルサービス要件
o Provide service during subscriber visiting between wireless
networks systems while maintaining a formal customer-service
provider relation with only one wireless service provider.
o 1つの無線サービスプロバイダだけとの正式な顧客サービスプロバイダー関係を維持している間、サービスを提供してくださいワイヤレス・ネットワークシステムの間の加入者訪問の間。
o Support Traditional PPP and Mobile IP services:
o Traditional PPPとモバイルIPにサービスをサポートしてください:
Hiller, et al. Informational [Page 2] RFC 3141 CDMA2000 Wireless Data Requirements June 2001
ヒラー、他 情報の[2ページ]RFC3141CDMA2000ワイヤレスデータ要件2001年6月
o Support dynamic and static home address assignments for
Mobile IP
o Support a Home Agent in the mobile's home wireless network,
home ISP, or private network.
o Support IP Security on the Mobile IP tunnel between Foreign
Agent and Home Agent, in order to avoid the overhead of a
voluntary tunnel on the radio interface.
o モバイルのホームワイヤレス・ネットワーク、ホームISP、または私設のネットワークでモバイルIP o Supportのためのダイナミックで静的なホームアドレス課題にホームのエージェントをサポートしてください。モバイルIPのo Support IP SecurityはForeignエージェントとホームのエージェントの間でトンネルを堀ります、ラジオインタフェースの自発的のトンネルのオーバーヘッドを避けるために。
o Provide robust authentication, authorization and accounting
services (AAA):
o 体力を要している認証、承認、および会計サービス(AAA)を提供してください:
o Provide separation of airlink resource AAA services and data
resource AAA services.
o Authenticate and authorize a mobile based on an IMSI and an
NAI. The architecture allows for a carrier to determine if
billing is based on the IMSI or the NAI.
o Support optional AAA broker services between wireless
carriers and between wireless carriers and other external
data networks.
o Allow for distribution of specific Mobile IP security key
information to support home agent assignment, fast handoff,
and fast HA-FA authentication assignment during
registration.
o 空路連結リソースAAAサービスとデータリソースAAAサービスo Authenticateの分離を提供してください、そして、IMSIとNAIに基づくモバイルを認可してください。 アーキテクチャは、キャリヤーが、支払いがIMSIかNAIに基づいているかどうかと決心しているのを許容します。特定のモバイルIPセキュリティ主要な情報の分配が、登録の間、ホームがエージェント課題と、速い移管と、速いHA-FA認証課題であるとサポートするように、o Support任意のAAAのブローカーは無線電話会社の間と、そして、他の外部のデータ網無線電話会社とoの間でAllowを調整します。
o Provide QoS
o QoSを提供してください。
Hiller, et al. Informational [Page 3] RFC 3141 CDMA2000 Wireless Data Requirements June 2001
ヒラー、他 情報の[3ページ]RFC3141CDMA2000ワイヤレスデータ要件2001年6月
2. High Level Architecture
2. 高い平らなアーキテクチャ
The high level architecture is shown in Figure 1. The six major entities that compose the network are the Home Agent, the PDSN, the AAA Server, the Radio Network, the HLR/VLR, and Mobile Client.
高い平らなアーキテクチャは図1に示されます。 ネットワークを構成する6つの主要な実体が、ホームのエージェント(PDSN)のAAA Serverと、Radio Networkと、HLR/VLRと、モバイルClientです。
Visited Access Home Access
Provider Network Provider Network
+--------+ +--------+
| | SS7 | |
| VLR |-----------------| HLR |
| | | |
+--------+ +--------+
|
|
| Visited Access Broker Home IP
| Provider Network Network Network
| +--------+ +--------+ +--------+
| | | | | | |
| | AAA |------| AAA |---| AAA |
| | | | | | |
| +--------+ +--------+ +--------+
| \ \ |
| \ \ |
| \ \ |
| \ \ |
| \ \ |
+---------+ +---------+ +---------+
| | | | | |
| RN |-------| PDSN |-------| HA |
| | | | | |
+---------+ +---------+ +---------+
|
| Visited Access Home Network
| Provider Network -Private
Mobile| -Visited Provider
IP | -Home Provider
| -Home ISP
+--------+
| Mobile |
| Node |
+--------+
訪問されたアクセスホームアクセスプロバイダネットワーク内の提供者ネットワーク+--------+ +--------+ | | SS7| | | VLR|-----------------| HLR| | | | | +--------+ +--------+ | | | 訪問されたアクセスブローカーホームIP| プロバイダーネットワークネットワークネットワーク| +--------+ +--------+ +--------+ | | | | | | | | | AAA|------| AAA|---| AAA| | | | | | | | | +--------+ +--------+ +--------+ | \ \ | | \ \ | | \ \ | | \ \ | | \ \ | +---------+ +---------+ +---------+ | | | | | | | Rn|-------| PDSN|-------| ハ| | | | | | | +---------+ +---------+ +---------+ | | 訪問されたアクセスホームネットワーク| プロバイダーのネットワークの個人的モバイル| -訪問されたプロバイダーIP| -ホームプロバイダー| -ホームISP+--------+ | モバイル| | ノード| +--------+
Figure 1: General cdma2000 Wireless IP Architecture
図1: cdma2000 Wireless IP Architecture司令官
Hiller, et al. Informational [Page 4] RFC 3141 CDMA2000 Wireless Data Requirements June 2001
ヒラー、他 情報の[4ページ]RFC3141CDMA2000ワイヤレスデータ要件2001年6月
2.1. PDSN
2.1. PDSN
o Acts as a Foreign Agent;
o Establish, maintain, and terminate link layer to the mobile
client;
o Initiate the authentication, authorization and accounting for
the mobile client;
o Optionally, securely tunnel using IP security to the Home
Agent;
o Receives service parameters from AAA for mobile client;
o Collect usage data for accounting purposes to be relayed to
AAA;
o Routes packets to external packet data networks or to the HA in
the case of reverse tunneling;
o Maps home address and Home Agent address to a unique link layer
identifier used to communicate with Radio Network.
o 外国人のエージェントとしての条例。 o モバイルクライアントへのリンクレイヤを確立して、維持して、終えてください。 o モバイルクライアントのために認証、承認、および会計を開始してください。 o 任意に、ホームのエージェントにIPセキュリティを使用することでしっかりとトンネルを堀ってください。 o モバイルクライアントのためにAAAからサービスパラメタを受け取ります。 o 用法データを集めて、会計目的はAAAにリレーされてください。 o 外部のパケットデータ網、または、逆のトンネリングの場合におけるHAにパケットを発送します。 o ホームアドレスとホームのエージェントがユニークなリンクレイヤ識別子に扱う地図は以前はよくRadio Networkとコミュニケートしていました。
2.2. Authentication, Authorization, and Accounting Server
2.2. 認証、承認、および会計サーバ
o Interact with the Foreign Agent and other AAA servers to
authorize, authenticate and perform accounting for the mobile
client;
o Provides mechanism to support security association between
PDSN/FA and HA and between the MN and PDSN/FA;
o For dynamic Home Agent assignment, dynamically identify an HA
and assign a MN on that HA, and provide the security
association between the MN and HA;
o Provide QoS information to the PDSN;
o Optionally, assign dynamic home address.
o モバイルクライアントのために会計とForeignエージェントと他のAAAサーバと対話して、認可して、認証して、実行してください。 o セキュリティがPDSN/FAとHAとミネソタとPDSN/FAとの協会であるとサポートするためにメカニズムを提供します。 o ダイナミックなホームエージェント課題には、ダイナミックにHAを特定してください、そして、そのHAにミネソタを割り当ててください、そして、ミネソタとHAとのセキュリティ協会を供給してください。 o PDSNへの情報をQoSに供給してください。 o 任意に、ダイナミックなホームアドレスを割り当ててください。
2.3. Radio Network
2.3. ラジオ放送網
o Maps Mobile Client identifier reference to a unique link layer
identifier used to communicate with PDSN;
o Validates Mobile Station for access service;
o Manages physical layer connection to the Mobile Client;
o Maintain state of reachability for packet service between the
access radio network and the mobile station;
o Buffers packets arriving from the PDSN, when radio resources
are not in place or are insufficient to support the flow from
the PDSN;
o Relays packets between the mobile station and the PDSN.
o ユニークなリンクレイヤ識別子のモバイルClient識別子参照がPDSNとコミュニケートするのに使用した地図。 o アクセス・サービスのためにモバイル駅を有効にします。 o 物理的な層の接続をモバイルClientに管理します。 o アクセスラジオネットワークと移動局の間のパケットサービスのために可到達性の状態を維持してください。 o ラジオリソースが適所にないか、または流れをサポートするために不十分であるときにPDSNからPDSNから到着するパケットをバッファリングします。 o 移動局とPDSNの間のパケットをリレーします。
2.4. Location Registers (VLR/HLR)
2.4. 位置のレジスタ(VLR/HLR)
o Stores authentication and authorization information for the
radio network.
o ラジオ放送網のための認証と承認情報を保存します。
Hiller, et al. Informational [Page 5] RFC 3141 CDMA2000 Wireless Data Requirements June 2001
ヒラー、他 情報の[5ページ]RFC3141CDMA2000ワイヤレスデータ要件2001年6月
2.5. Home Agent
2.5. ホームのエージェント
o Maintains user registration and redirects packets to the PDSN;
o Optionally, establish an IP secure tunnel to the PDSN/FA;
o Supports the dynamic Home Agent assignment;
o Optionally, assigns dynamic home address;
o Support reverse tunneling.
o ユーザ登録を維持して、PDSNにパケットを向け直します。 o 任意に、IPの安全なトンネルをPDSN/FAに確立してください。 o ダイナミックなホームエージェント課題をサポートします。 o 任意に、ダイナミックなホームアドレスを割り当てます。 o 逆のトンネリングをサポートしてください。
2.6. Mobile Node
2.6. モバイルノード
o Support PPP;
o Can act as a Mobile IP Node; and support Foreign Agent
Challenge and NAI;
o Interacts with the Radio Network to obtain appropriate radio
resources from the network for the exchange of packets;
o Maintains knowledge of status of radio resources (e.g., active,
standby, dormant);
o Buffers packets when radio resources are not in place or are
insufficient to support the flow to the network.
o pppをサポートしてください。 o モバイルIP Nodeとして機能できます。 そして、ForeignエージェントChallengeとNAIをサポートしてください。 o ネットワークから適切なラジオリソースをパケットの交換に得るためにRadio Networkと対話します。 o ラジオリソース(例えば、予備の、そして、眠っている能動態)の状態に関する知識を維持します。 o ラジオリソースが適所にないか、またはネットワークに流れをサポートするために不十分であるときに、パケットをバッファリングします。
3. AAA Requirements
3. AAA要件
3.1. Core AAA Requirements
3.1. コアAAA要件
The following is a summary of cdma2000 AAA specific requirements. In these requirements, the serving network and home network may or may not have a direct business relationship. In such cases in which there is not a direct business relationship, service may be supported indirectly via broker.
↓これはcdma2000AAA決められた一定の要求の概要です。 これらの要件では、給仕ネットワークとホームネットワークは直接売買関係を持っているかもしれません。 そのような場合どれが直接売買関係がないかで、サービスは間接的にブローカーを通してサポートされるかもしれません。
o Authenticate and authorize a user NAI in a roaming environment.
The NAI is obtained via CHAP (for traditional PPP service) or a
Foreign Agent Challenge (for Mobile IP service). A shared
secret exists between the mobile and its HAAA. The FAC will
typically be computed in a manner consistent with CHAP.
o Transport wireless data attributes from the home network to the
Serving network. This may often take the form of a user
profile.
o Encrypt or sign one or more AVPs in an AAA message between
home, serving network, or some broker across multiple AAA
server hops.
o Support a reliable AAA transport mechanism.
o This transport mechanism will be able indicate to an AAA
application that a message was delivered to the next peer
AAA application or that a time out occurred.
o Retransmission is controlled by the reliable AAA transport
mechanism, and not by lower layer protocols such as TCP.
o ローミング環境でユーザNAIを認証して、認可してください。 CHAP(伝統的なPPPサービスのための)かForeignエージェントChallenge(モバイルIPサービスのための)を通してNAIを入手します。 共有秘密キーはモバイルとそのHAAAの間に存在しています。 FACはホームネットワークからServingネットワークまでCHAP o Transportのワイヤレスのデータ属性と一致した方法で通常計算されるでしょう。 これはしばしばユーザ・プロファイルの形を連れて行くかもしれません。複数のAAAサーバホップo Supportの向こう側に信頼できるAAA移送機構を仲介してください。o Encryptかo This移送機構ができるというホーム、給仕ネットワーク、またはいくつかの間のAAAメッセージのより多くのサイン1AVPsが、メッセージが次の同輩AAAアプリケーションに提供されたか、またはo RetransmissionがTCPなどの下位層プロトコルによって制御されるのではなく、信頼できるAAA移送機構によって制御されるのをAAAアプリケーションに示します。タイムアウトは起こりました。
Hiller, et al. Informational [Page 6] RFC 3141 CDMA2000 Wireless Data Requirements June 2001
ヒラー、他 情報の[6ページ]RFC3141CDMA2000ワイヤレスデータ要件2001年6月
o Even if the AAA message is to be forwarded, or the message's
options or semantics do not conform with the AAA protocol,
the transport mechanism will acknowledge that the peer
received the AAA message. However, if the message fails to
pass authentication, it will not be acknowledged.
o Acknowledgements should be allowed to be piggybacked in AAA
messages
o The reliable transport mechanism features shall have the
capability to detect silent failures of the AAA peer or path
to the AAA peer, to manage failure on a proactive basis.
o Transport a digital certificate in an AAA message, in order
to minimize the number of round trips associated with AAA
transactions. Note: This requirement applies to AAA
applications and not mobile stations.
o Support both proxy and non-proxy brokers, where non-proxy
brokers imply the broker terminates an entire request and
initiates a new request. AAA brokers should have the
capability to modify certain parts of AAA messages whereby
to operate to in non-proxy or proxy environments.
o Provide message integrity and identity authentication on a
per hop (AAA node) basis.
o Support replay protection and optional non-repudiation
capabilities for all authorization and accounting messages.
The AAA protocol must provide the capability for accounting
messages to be matched with prior authorization messages.
o Support accounting via both bilateral arrangements and via
broker AAA servers providing accounting clearinghouse and
reconciliation between serving and home networks. There is
an explicit agreement that if the private network or home
ISP authenticates the mobile station requesting service,
then the private network or home ISP network also agrees to
reconcile charges with the home service provider or broker.
Real time accounting must be supported.
o Provides security between AAA servers, and between AAA
server and PDSN or HA via IP security.
o AAAメッセージが進めることであるまたはメッセージのオプションか意味論がAAAプロトコルに従わないでも、移送機構は、同輩がAAAメッセージを受け取ったと認めるでしょう。 しかしながら、メッセージが認証を通過しないと、それは承認されないでしょう。o Acknowledgementsはa先を見越す基礎AAAメッセージのo Transportのaデジタル証明書の上に失敗を管理するために信頼できる移送機構機能にはAAAの同輩か経路の静かな失敗をAAAの同輩に検出する能力があるものとするというAAAメッセージoで便乗できるはずです、AAAトランザクションに関連している周遊旅行の数を最小にするために。 以下に注意してください。 この要件はプロキシと非プロキシブローカーの両方を移動局o Supportではなく、AAAアプリケーションに適用します、非プロキシブローカーが、ブローカーが全体の要求を終えて、新しい要求を開始すると暗示するところで。 AAAのブローカーには、すべての承認と会計で保護と任意の非拒否能力をプロキシ環境非プロキシかo Provideメッセージの保全にaにおけるアイデンティティホップ(AAAノード)基礎o Supportあたり認証して再演するために作動するのが通信するAAAメッセージのある部分を変更する能力があるべきです。 AAAプロトコルは会計情報センターと和解を給仕とホームネットワークの間に提供しながら両方の双方のアレンジメントを通してブローカーAAAサーバで先の承認メッセージo Support会計に合わせられるべき会計メッセージに能力を提供しなければなりません。 また、私設のネットワークかホームISPがサービスを要求する移動局を認証するなら私設のネットワークかホームISPネットワークが、ホームサービスプロバイダーかブローカーと充電を仲直りさせるのに同意するという明白な協定があります。 . IPセキュリティを通したAAAのAAAサーバとサーバとPDSNかHAの間のo Providesセキュリティであることをリアルタイムの会計をサポートしなければなりません。
3.2. Mobile IP Specific Requirements and AAA
3.2. モバイルIP決められた一定の要求とAAA
3.2.1. Mobile IP Security Discussion
3.2.1. モバイルIPセキュリティ議論
Three Mobile IP security extensions are defined in RFC 2002:
3つのモバイルIPセキュリティ拡大がRFC2002で定義されます:
. HA - FA
. MN - FA
. HA - MN
ハ--ファMn--ファ。. ハ--ミネソタ
Hiller, et al. Informational [Page 7] RFC 3141 CDMA2000 Wireless Data Requirements June 2001
ヒラー、他 情報の[7ページ]RFC3141CDMA2000ワイヤレスデータ要件2001年6月
Therefore, Mobile IP and IPsec security models differ in that Mobile IP provides its own authentication mechanisms calculated within the Mobile IP registration procedures whereas IPsec uses IPsec AH.
したがって、モバイルIPとIPsec機密保護モデルはモバイルIPがモバイルIP登録手順の中で計算されたそれ自身の認証機構を提供するという点において異なりますが、IPsecはIPsec AHを使用します。
The keys and SPIs associated with the MN-FA and HA-FA extensions need to be dynamically established in a roaming wireless carrier environment. The MN-FA extension is useful for allowing a new FA (PDSN) to quickly authenticate a mobile using the previous foreign agent extension. The HA-FA extension is useful for the HA to ensure that only FAs from carrier's with roaming agreements access the HA. The MN-HA is usually provisioned, but for dynamic Home Agent assignment, this security association must be dynamically created.
ミネソタ-FAとHA-FA拡張子に関連しているキーとSPIsは、ダイナミックにローミング無線電話会社環境に設立される必要があります。 新しいFA(PDSN)がすぐにモバイルを認証するのを前の外国エージェント拡張子を使用することで許容することのミネソタ-FA拡張子は役に立ちます。 HAがローミング協定アクセスがあるキャリヤーのものからのその唯一のFAsにHAを確実にするように、HA-FA拡張子は役に立ちます。 ミネソタ-HAは通常食糧を供給されますが、ダイナミックなホームエージェント課題において、このセキュリティ協会をダイナミックに創設しなければなりません。
It is possible to use IPsec AH between MN and FA, FA and HA, and MN and HA. IKE may be used to establish security associations between these entities. However, use of IKE may pose a problem for smaller mobiles and may introduce unacceptable delays for certain applications (e.g., Voice Over IP). The following three sections outline Mobile IP specific functions that benefit from AAA based key distribution.
ミネソタと、FAと、FAと、HAと、ミネソタとHAの間でIPsec AHを使用するのは可能です。 IKEは、これらの実体の間のセキュリティ協会を証明するのに使用されるかもしれません。 しかしながら、IKEの使用は、より小さいモバイルのために問題を設定して、あるアプリケーション(例えば、Voice Over IP)のために容認できない遅れを導入するかもしれません。 以下の3つのセクションがAAAに基づいている主要な分配の利益を得るモバイルIP具体的な機能について概説します。
3.2.2. Dynamic Home Agent Assignment
3.2.2. ダイナミックなホームエージェント課題
A visited or home AAA server will optionally be able perform dynamic HA assignment. For dynamically assigned HA, the visited AAA server will indicate to the home AAA server whether it supports dynamic HA assignment in those cases in which the mobile node requests dynamic assignment. If so indicated, the home AAA server may choose to allow the visited AAA server to perform the HA assignment. Otherwise, the home AAA assigns the HA.
訪問されるかホームAAAサーバは任意にできるでしょう。ダイナミックなHA課題を実行してください。 ダイナミックに割り当てられたHAに関しては、訪問されたAAAサーバは、それが、ダイナミックなHAがモバイルノードがダイナミックな課題を要求するそれらの場合で課題であるとサポートするかどうかをホームAAAサーバに示すでしょう。 そうだとすれば、示されて、ホームAAAサーバは、訪問されたAAAサーバがHA課題を実行するのを許容するのを選ぶかもしれません。 さもなければ、ホームAAAはHAを割り当てます。
3.2.3. Fast Handoff
3.2.3. 速い移管
To achieve a faster handoff, the mobile may attempt to avoid an AAA transaction with the home AAA server. To accomplish this, the mobile may send the PDSN the Previous FA address in the RRQ message from the mobile, along with the MN-FA authentication extension. The new PDSN passes the Previous FA address and MN-FA authentication extension to the visited AAA server. If the visited AAA server is able authenticate the MN-FA authentication extension for the mobile, then the visited AAA may be able to avoid an actual transaction to the home AAA server.
より速い移管を達成するために、モバイルは、ホームAAAサーバでAAAトランザクションを避けるのを試みるかもしれません。これを達成するために、モバイルはモバイルからのRRQメッセージのPrevious FAアドレスをPDSNに送るかもしれません、ミネソタ-FA認証拡張子と共に。 新しいPDSNはPrevious FAアドレスとミネソタ-FA認証拡張子を訪問されたAAAサーバに通過します。訪問されたAAAサーバができるなら、モバイルのためのミネソタ-FA認証拡張子を認証してください、そして、次に、訪問されたAAAはホームAAAサーバとして現物売買を避けてもよいです。
Hiller, et al. Informational [Page 8] RFC 3141 CDMA2000 Wireless Data Requirements June 2001
ヒラー、他 情報の[8ページ]RFC3141CDMA2000ワイヤレスデータ要件2001年6月
3.2.4. HA-FA Authentication
3.2.4. ハ、-、ファ、認証
To achieve a fast registration for the case of a mobile station with a Home Agent, the PDSN and HA may receive from the AAA mechanism a HA-FA key and SPI that is used to authenticate the PDSN and the HA to each other.
ホームのエージェントがいる移動局に関するケース、PDSN、およびHAのために速い登録を達成するのはPDSNとHAを認証するのに使用されるAAAメカニズムのHA-FAキーとSPIから互いになりまで受信されるかもしれません。
3.2.5. Key Distribution
3.2.5. 主要な分配
These functions are primarily useful in a wireless environment in which handoffs may occur rapidly (implying a need for low latency), or where mobile devices have limited computing power. To achieve these functions, AAA will be used to securely pass keys and SPIs between the serving network and target network in encrypted form. These keys are then used for the specific functions outlined in this document.
これらの機能はhandoffsが急速(低遅延の必要性を含意する)に現れるかもしれないか、またはモバイル機器がコンピューティングパワーを制限したワイヤレスの環境で主として役に立ちます。 これらの機能を獲得すると、AAAは、しっかりと暗号化されたフォームでの給仕ネットワークと目標ネットワークの間にキーとSPIsを渡すのに使用されるでしょう。 そして、これらのキーは本書では概説された具体的な機能に使用されます。
3.3. IKE and AAA
3.3. IKEとAAA
The use of IKE in the cdma2000 wireless architecture requires the use of certificates. However, the AAA servers may be able to distribute a pre- shared key to the Mobile IP Agents for use during Phase 1 ISAKMP exchanges. This may lessen the need for on-line revocation checks.
cdma2000のワイヤレスのアーキテクチャにおけるIKEの使用は証明書の使用を必要とします。 しかしながら、AAAサーバは使用のためにPhase1ISAKMP交換の間、モバイルIPエージェントのあらかじめ共有されたキーを分配できるかもしれません。 これはオンライン取消しチェックの必要性を少なくするかもしれません。
3.4. Interoperability with RADIUS
3.4. 半径がある相互運用性
Users with a home AAA server based on RADIUS may desire to roam into a wireless carrier network that uses "new" AAA servers based on the requirements in this document, and vice verse. The AAA protocol should be designed in a way so as to make conversions to and from RADIUS messages straight forward. This will allow for the development of gateway processes to aid in interoperability. Note: The features of the new AAA protocols which are beyond the feature set of the RADIUS protocol will not be available for users while on home or serving networks based on RADIUS.
RADIUSに基づくホームAAAサーバをもっているユーザは、本書では要件に基づく、「新しい」AAAサーバ、および副の詩を使用する無線電話会社ネットワークに移動することを望むかもしれません。 AAAプロトコルは、RADIUSとRADIUSからの変換を前方でまっすぐなメッセージにするように方法で設計されるべきです。 これは、ゲートウェイプロセスの開発が相互運用性で支援されるのを許容するでしょう。 以下に注意してください。 RADIUSプロトコルの特徴セットにある新しいAAAプロトコルの特徴はホームかネットワークに役立つときRADIUSに基づいている間、ユーザに利用可能にならないでしょう。
4. References
4. 参照
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
5. Security Considerations
5. セキュリティ問題
This document is very much about security. These requirements do not require the serving and home networks to not be in the same domain nor must they have a direct relationship. The serving network requires authorization from the home network so that the serving
このドキュメントはセキュリティに関するまさしくそのいろいろな事です。 これらの要件は、給仕とホームネットワークが同じドメインにないのを必要としません、そして、それらには、直接の因果関係があってはいけません。 したがって、給仕ネットワークがホームネットワークから承認を必要とする、それ、給仕
Hiller, et al. Informational [Page 9] RFC 3141 CDMA2000 Wireless Data Requirements June 2001
ヒラー、他 情報の[9ページ]RFC3141CDMA2000ワイヤレスデータ要件2001年6月
network obtains proof it will get paid for services rendered to the mobile. This implies the home network must authenticate the user. AAA functions must be performed in a secure manner. The requirements contained in section 2 outline the security required.
ネットワークはモバイルに提供されたサービスのために稼ぐという証拠を得ます。 これは、ホームネットワークがユーザを認証しなければならないのを含意します。 安全な方法でAAA機能を実行しなければなりません。 要件はセクション2アウトラインに必要であるセキュリティを含みました。
Mobile IP supports authentication mechanisms outside IP Security. These mechanism may be enhanced in a cellular wireless environment by allowing a home AAA server to distribute keys to the serving network. Additionally, the home AAA server may be able to send a pre-shared key to be used in Phase 1 ISAKMP security association establishment between FA and HA. These keys would sent in encrypted form from the home network to the serving network. As supported in the requirements contained in section 2, the encryption could be handled via public cryptography and certificates.
モバイルIPは、IP Securityの外で認証がメカニズムであるとサポートします。 ホームAAAサーバが給仕ネットワークのキーを分配するのを許容することによって、これらのメカニズムはセルワイヤレスの環境で高められるかもしれません。 さらに、ホームAAAサーバは、FAとHAの間のPhase1ISAKMPセキュリティ協会設立に使用されるためにあらかじめ共有されたキーを送ることができるかもしれません。 暗号化されたフォームでホームネットワークから給仕ネットワークに送って、これらのキーはそうするでしょう。 セクション2に含まれた要件でサポートされるように、公共の暗号と証明書で暗号化を扱うことができるでしょう。
6. IANA Considerations
6. IANA問題
This document does not create any new number spaces for IANA administration.
このドキュメントはIANA管理のために少しの新しい数の空間も作成しません。
7. Acknowledgements
7. 承認
The authors are active members of the TIA TR45.6 committee.
作者はTIA TR45.6委員会の活動的なメンバーです。
8. Authors' Addresses
8. 作者のアドレス
Pat R. Calhoun Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, CA 94025 USA
パットR.カルフーンネットワークとセキュリティリサーチセンター、サン・マイクロシステムズ・インク15がネットワークでつなぐSun研究室はメンローパーク、カリフォルニア94025米国を旋回します。
Phone: (650) 786-7733 EMail: pcalhoun@eng.sun.com
以下に電話をしてください。 (650) 786-7733 メールしてください: pcalhoun@eng.sun.com
Ed Campbell CommWorks Corporation, A 3Com Company 3800 Golf Road Rolling Meadows, IL 60008
エドキャンベルCommWorks社、草地、イリノイ 60008を回転させる3Com会社3800ゴルフ道路
Phone: (847)262-2325 E-Mail: ed_campbell@commworks.com
以下に電話をしてください。 (847)262-2325 メールしてください: ed_campbell@commworks.com
Hiller, et al. Informational [Page 10] RFC 3141 CDMA2000 Wireless Data Requirements June 2001
ヒラー、他 情報の[10ページ]RFC3141CDMA2000ワイヤレスデータ要件2001年6月
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
西タスマン・DriveゴパルDommetyシスコシステムズInc.170カリフォルニア95134サンノゼ(米国)
EMail: gdommety@cisco.com
メール: gdommety@cisco.com
Tom Hiller Rm 2F-218 263 Shuman Dr. Lucent Technologies Naperville, IL USA
ナパービル、トム培土板Rm2F218 263シューマンルーセントテクノロジーズ不-米国博士
Phone: (630) 979-7673 EMail: tom.hiller@lucent.com
以下に電話をしてください。 (630) 979-7673 メールしてください: tom.hiller@lucent.com
Raymond T. Hsu Qualcomm Inc. 6455 Lusk Blvd. San Diego, CA 92121 USA
レイモンドT.シュークアルコム株式会社6455ラスクBlvd. サンディエゴ、カリフォルニア92121米国
Phone: (619) 651-3623 EMail: rhsu@qualcomm.com
以下に電話をしてください。 (619) 651-3623 メールしてください: rhsu@qualcomm.com
Mark A. Lipford Sprint PCS 15405 College Blvd. Lenexa, KS 66219
マークA.Lipford短距離競走PCS15405大学Blvd. レネクサ、カンザス 66219
Phone: (913) 890-4248 EMail: mlipfo01@sprintspectrum.com
以下に電話をしてください。 (913) 890-4248 メールしてください: mlipfo01@sprintspectrum.com
Serge Manning Award Solutions, Inc. 800 E. Campbell Rd., Suite 120 Richardson, TX 75081
テキサス Inc.800E.キャンベル通り、Suite120リチャードソン、サージマニング賞ソリューション75081
Phone: (972) 664-0727 x350 EMail: serge@awardsolutions.com
以下に電話をしてください。 (972) 664-0727x350 EMail: serge@awardsolutions.com
Hiller, et al. Informational [Page 11] RFC 3141 CDMA2000 Wireless Data Requirements June 2001
ヒラー、他 情報の[11ページ]RFC3141CDMA2000ワイヤレスデータ要件2001年6月
Peter J. McCann Lucent Technologies Rm 2Z-305 263 Shuman Blvd Naperville, IL 60566 USA
ピーター・J.マッキャン・ルーセントテクノロジーズRm 2Z-305 263シューマン・Blvd IL60566ナパービル(米国)
Phone: (630) 713 9359 EMail: mccap@lucent.com
以下に電話をしてください。 (630) 713 9359はメールされます: mccap@lucent.com
Mark Munson 1371 Winding Branch Circle Atlanta, Georgia 30338 USA
支店円のジョージア30338アトランタ(米国)を巻き上げするマーク・ムンソン1371
Phone: (678) 339-4439 EMail: mmunson@gte.net
以下に電話をしてください。 (678) 339-4439 メールしてください: mmunson@gte.net
Haeng Koo Samsung Telecommunications America, Inc. 1130 E. Arapaho Road Richardson, TX 75081 USA
Haengクー三星TelecommunicationsアメリカInc.1130E.アラパホRoadリチャードソン(テキサス)75081米国
Phone: (972)761-7755 EMail: hskoo@sta.samsung.com
以下に電話をしてください。 (972)761-7755 メールしてください: hskoo@sta.samsung.com
Pat Walsh Lucent Technologies 263 Shuman Blvd. 1F-545 Naperville, IL
パットウォルシュルーセントテクノロジーズ263シューマンBlvd. ナパービル、1F-545IL
Phone: +1 630-713-5063 EMail: walshp@lucent.com
以下に電話をしてください。 +1 630-713-5063 メールしてください: walshp@lucent.com
Hiller, et al. Informational [Page 12] RFC 3141 CDMA2000 Wireless Data Requirements June 2001
ヒラー、他 情報の[12ページ]RFC3141CDMA2000ワイヤレスデータ要件2001年6月
Yingchun Xu WaterCove Networks One Century Centre, Suite 550 1750 E. Golf Road Schaumburg, IL
1世紀にWaterCoveネットワークが集中させるYingchunシュー、Roadスカンバーブ、スイート550 1750E.Golfイリノイ
Phone: +1 847-477-9280 EMail: yxu@watercove.com
以下に電話をしてください。 +1 847-477-9280 メールしてください: yxu@watercove.com
Brent Hirschman 1501 Shure Dr. Arlington Heights, IL 60006 USA
ブレントヒルシュマン1501シュアーアーリントンハイツIL60006博士(米国)
Phone: (847) 632-1563 EMail: qa4053@email.mot.com
以下に電話をしてください。 (847) 632-1563 メールしてください: qa4053@email.mot.com
Eric Jaques Vodafone 2999 Oak Road, MS-750 Walnut Creek, CA 94596 USA
エリックジャキュースボーダフォン2999オーク道路、MS-750ウォールナットクリーク、カリフォルニア94596米国
Phone: +1-925-210-3900 EMail: ejaques@akamail.com
以下に電話をしてください。 +1-925-210-3900 メールしてください: ejaques@akamail.com
Sanjeevan Sivalingham Ericsson Wireless Communications Inc., Rm Q-356C 6455 Lusk Blvd San Diego, CA 92126 USA
Sanjeevan Sivalinghamエリクソン無線通信Inc.、Rm Q-356Cの6455ラスク・Blvdカリフォルニア92126サンディエゴ(米国)
Phone: (858) 332-5670 EMail: s.sivalingham@ericsson.com
以下に電話をしてください。 (858) 332-5670 メールしてください: s.sivalingham@ericsson.com
Hiller, et al. Informational [Page 13] RFC 3141 CDMA2000 Wireless Data Requirements June 2001
ヒラー、他 情報の[13ページ]RFC3141CDMA2000ワイヤレスデータ要件2001年6月
Xing Chen Alcatel USA 1000 Coit Road Plano, TX 75075 USA
Xingチェンアルカテル米国1000コイトRoadテキサス75075プラノ(米国)
Phone: 972-519-4142 Fax: +1 972-519-3300 EMail: xing.chen@usa.alcatel.com
以下に電話をしてください。 972-519-4142 Fax: +1 972-519-3300 メールしてください: xing.chen@usa.alcatel.com
Byung-Keun Lim LG Electronics Inc. 533, Hogye-dong, Donan-Ku, Anyang-shi, Kyungki-do, 431-080, Korea
Byung-コインリムLG電子株式会社533(Hogye-ドング、Donan区、安陽市)はKyungki431-080に韓国をします。
Phone: +82-31-450-7199 Fax: +82-31-450-7050 EMail: bklim@lge.com
以下に電話をしてください。 +82-31-450-7199 Fax: +82-31-450-7050 メールしてください: bklim@lge.com
Hajime Shiino Lucent Technologies Japan Ltd. 25 Mori Bldg. 1-4-30 Roppongi, Minato-ku Tokyo Japan
Hajime Shiinoルーセントテクノロジーズ日本Ltd.25モリBldg. 1-4-30 六本木、港区日本東京
Phone: +81-3-5561-3695 EMail: hshiino@lucent.com
以下に電話をしてください。 +81-3-5561-3695 メールしてください: hshiino@lucent.com
Shinichi Baba Toshiba America Research, Inc. PO Box 136, Convent Station, NJ 07961-0136 USA
新市ラム酒入りケーキ東芝アメリカ研究Inc.私書箱136、修道院駅、ニュージャージー07961-0136米国
Phone: (973) 829-4795 EMail: sbaba@tari.toshiba.com
以下に電話をしてください。 (973) 829-4795 メールしてください: sbaba@tari.toshiba.com
Hiller, et al. Informational [Page 14] RFC 3141 CDMA2000 Wireless Data Requirements June 2001
ヒラー、他 情報の[14ページ]RFC3141CDMA2000無線電信データ要件2001年6月
Takahiro Ayaki DDI corporation Ichibancho FS Bldg. 8, Ichibancho, Chiyoda-ku Tokyo Japan
Takahiro Ayaki DDI会社Ichibancho FS Bldg。 8 Ichibancho、東京日本千代田区
Phone: +81-3-3221-9682 EMail: ayaki@ddi.co.jp
以下に電話をしてください。 +81-3-3221-9682 メールしてください: ayaki@ddi.co.jp
Alan Hameed Fujitsu 2801 Telecom Parkway Richardson, Texas 75082 USA
電子通信パークウェイのリチャードソン、アランハミードテキサス75082米国富士通2801
Phone: (972) 479-2089
以下に電話をしてください。 (972) 479-2089
Charles N. Lo Vodafone AirTouch 2999 Oak Rd Walnut Creek, CA 94596 USA
チャールズN.最低気温ボーダフォンエアタッチ2999オークカリフォルニア94596第ウォールナットクリーク(米国)
Phone: (925) 210-3460 EMail: Charles.Lo@vodafone-us.com
以下に電話をしてください。 (925) 210-3460 メールしてください: Charles.Lo@vodafone-us.com
Takuo Seki IDO Corporation Gobancho YS Bldg. 12-3, Gobancho, Chiyoda-ku Tokyo Japan
Takuo瀬木IDO社のGobancho YS Bldg. 12-3 Gobancho、東京日本千代田区
Phone: +81-3-3263-9660 EMail: t-seki@kddi.com
以下に電話をしてください。 +81-3-3263-9660 メールしてください: t-seki@kddi.com
Hiller, et al. Informational [Page 15] RFC 3141 CDMA2000 Wireless Data Requirements June 2001
ヒラー、他 情報の[15ページ]RFC3141CDMA2000無線電信データ要件2001年6月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Hiller, et al. Informational [Page 16]
ヒラー、他 情報[16ページ]
一覧
スポンサーリンク
