RFC2477 日本語訳
2477 Criteria for Evaluating Roaming Protocols. B. Aboba, G. Zorn. January 1999. (Format: TXT=23530 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Aboba
Request for Comments: 2477 G. Zorn
Category: Informational Microsoft Corporation
January 1999
Abobaがコメントのために要求するワーキンググループB.をネットワークでつないでください: 2477年のG.ゾルンカテゴリ: 情報のマイクロソフト社1999年1月
Criteria for Evaluating Roaming Protocols
ローミングプロトコルを評価する評価基準
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 (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
1. Abstract
1. 要約
This document describes requirements for the provisioning of "roaming capability" for dialup Internet users. "Roaming capability" is defined as the ability to use multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one.
このドキュメントはダイアルアップインターネットユーザのために「ローミング能力」の食糧を供給する要件について説明します。 「ローミング能力」は1だけとの正式な顧客ベンダー関係を維持している間、複数のインターネット接続サービス業者(ISP)を使用する能力と定義されます。
2. Introduction
2. 序論
Operational roaming services are currently providing worldwide roaming capabilities, and these services continue to grow in popularity [1]. Interested parties have included:
操作上のローミング・サービスは現在世界的なローミング能力を前提としています、そして、これらのサービスは人気[1]で成長し続けています。 利害関係者は含みました:
Regional Internet Service Providers (ISPs) operating within a
particular state or province, looking to combine their efforts
with those of other regional providers to offer services over a
wider area.
より広い領域にわたってサービスを提供するために他の地方のプロバイダーのものにそれらの取り組みを結合するために見て、特定の州か州の中で作動する地方のインターネットサービスプロバイダ(ISP)。
National ISPs wishing to combine their operations with those of
one or more ISPs in another nation to provide greater coverage in
a group of countries or on a continent.
国のグループか大陸の上の、より大きい適用範囲を提供するためにもう1人の国の1つ以上のISPのものに彼らの操作を結合したがっている国家のISP。
Businesses desiring to offer their employees a comprehensive
package of dialup services on a global basis. Those services can
include Internet access as well as secure access to corporate
intranets via a Virtual Private Network (VPN).
地球規模で包括的なダイアルアップサービスのパッケージを彼らの従業員に提供することを望んでいるビジネス。 それらのサービスはVirtual兵士のNetwork(VPN)を通して企業イントラネットへの安全なアクセスと同様にインターネット・アクセスを含むことができます。
Aboba & Zorn Informational [Page 1] RFC 2477 Evaluating Roaming Protocols January 1999
プロトコル1999年1月に移動するAbobaとゾルン情報[1ページ]のRFC2477Evaluating
This document provides an architectural framework for the provisioning of roaming capabilities, as well as describing the requirements that must be met by elements of the architecture.
このドキュメントはアーキテクチャの原理で満たさなければならない必要条件について説明することと同様にローミング能力の食糧を供給するのに建築フレームワークを提供します。
2.1. Requirements language
2.1. 要件言語
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [4].
そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、[4]で説明されるように解釈されることになっていてください、」であるべきです
Please note that the requirements specified in this document are to be used in evaluating 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 use in roaming. For example, requiring that a protocol support confidentiality is NOT the same thing as requiring that all protocol traffic be encrypted.
本書では指定された要件はプロトコル差出を評価する際に使用されることです。 そういうものとして、要件言語はこれらのプロトコルの能力について言及します。 プロトコルドキュメントは、これらの特徴が必要であるか、お勧め、またはローミングにおける使用に、任意であるかを指定するでしょう。 例えば、プロトコルサポート秘密性がすべてがトラフィックについて議定書の中で述べるのが必要であるのと同じものでないことは必要であることで、暗号化されてください。
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つ以上を満たさないなら、プロトコル提案は対応しません。 そして、すべての必須を満たすプロトコル提案、必須である、能力のためのどんな要件も「無条件に言いなりになる」と言われていません;であるべきです または、要件ではなく、すべての必須と必須を満たしますが、すべて満足するというわけではないもの、「条件付きに言いなりになる」とプロトコルのためのどんな要件も言うべきではありません。
2.2. Terminology
2.2. 用語
This document frequently uses the following terms:
このドキュメントは頻繁に次の用語を使用します:
phone book
This is a database or document containing data pertaining to
dialup access, including phone numbers and any associated
attributes.
電話帳Thisはダイアルアップアクセスに関係するデータを含むデータベースかドキュメントです、電話番号とどんな関連属性も含んでいて。
phone book server
This is a server that maintains the latest version of the phone
book. Clients communicate with phone book servers in order to
keep their phone books up to date.
電話帳サーバThisは電話帳の最新版を維持するサーバです。 クライアントは、それらの電話帳が時代について行かせるために電話帳サーバとコミュニケートします。
Network Access Server
The Network Access Server (NAS) is the device that clients dial in
order to get access to the network.
ネットワークAccess Server Network Access Server(NAS)はクライアントがネットワークに近づく手段を得るためにダイヤルするデバイスです。
Authentication server
This is a server which provides for authentication/authorization
within the roaming architecture.
認証サーバThisはローミングアーキテクチャの中に認証/承認に備えるサーバです。
Aboba & Zorn Informational [Page 2] RFC 2477 Evaluating Roaming Protocols January 1999
プロトコル1999年1月に移動するAbobaとゾルン情報[2ページ]のRFC2477Evaluating
Accounting server
This is a server which provides for accounting within the roaming
architecture.
会計サーバThisはローミングアーキテクチャの中に会計に備えるサーバです。
Authentication proxy
Authentication proxies may be deployed within the roaming
architecture for several purposes, including authentication
forwarding, policy implementation, shared secret management, and
attribute editing. To the NAS, the authentication proxy appears
to act as an authentication server; to the authentication server,
the proxy appears to act as an authentication client.
認証推進を含んでいて、Authenticationプロキシがいくつかの目的のためにローミングアーキテクチャの中で配布されるかもしれない認証プロキシ(政策の実施)は秘密の管理、および属性編集を共有しました。 NASにおいて、認証プロキシは、認証サーバとして機能するように見えます。 認証サーバに、プロキシは、認証クライアントとして機能するように見えます。
Accounting proxy
Accounting proxies may be deployed within the roaming architecture
for several purposes, including accounting forwarding, reliability
improvement, auditing, and "pseudo-transactional" capability. To
the NAS, the accounting proxy appears to act as an accounting
server; to the accounting server, the proxy appears to act as an
accounting client.
会計プロキシAccountingプロキシはいくつかの目的のためにローミングアーキテクチャの中で配布されるかもしれません、推進を説明するのを含んでいて、信頼性の改良、監査の、そして、「疑似取引」の能力。 NASにおいて、会計プロキシは、会計サーバとして機能するように見えます。 会計サーバに、プロキシは、会計クライアントとして機能するように見えます。
Network Access Identifier
In order to provide for the routing of authentication and
accounting packets, user name MAY contain structure. This
structure provides a means by which the authentication or
accounting proxies will locate the authentication or accounting
server that is to receive the request.
ネットワークAccess Identifier Inは認証のルーティングに備えるために注文します、そして、パケットを説明して、ユーザ名は構造を含むかもしれません。 この構造は認証か会計プロキシが要求を受け取ることになっている認証か会計サーバの場所を見つける手段を提供します。
3. Architectural framework
3. 建築フレームワーク
The roaming architecture consists of three major subsystems:
ローミングアーキテクチャは3つの主要なサブシステムから成ります:
Phone book Subsystem
Authentication Subsystem
Accounting Subsystem
電話帳Subsystem Authentication Subsystem Accounting Subsystem
The phone book subsystem is concerned with the maintenance and updating of the user phone book. The phone book provides the user with information on the location and phone numbers of Points of Presence (POPs) that are roaming enabled. The function of the authentication subsystem is to provide authorized users with access to the POPs in the phonebook, and to deny access to unauthorized users. The goal of the accounting subsystem is to provide information on the resources utilized during the user's session.
電話帳サブシステムはユーザ電話帳のメインテナンスとアップデートに関係があります。 電話帳は可能にされたローミングであるPresence(POP)のPointsの位置と電話番号の情報をユーザに提供します。 認証サブシステムの機能は、phonebookのPOPへのアクセスを認定ユーザに提供して、権限のないユーザへのアクセスを拒絶することです。 会計サブシステムの目標はユーザのセッションの間に利用されたリソースの情報を提供することです。
3.1. Phone Book Subsystem
3.1. 電話帳サブシステム
The phone book subsystem provides for the following:
電話帳サブシステムは以下に備えます:
Aboba & Zorn Informational [Page 3] RFC 2477 Evaluating Roaming Protocols January 1999
プロトコル1999年1月に移動するAbobaとゾルン情報[3ページ]のRFC2477Evaluating
Phone number presentation
Phone number exchange
Phone book compilation
Phone book update
電話番号プレゼンテーション電話数の交換電話本の編集電話本の最新版
Phone number presentation
Phone number presentation involves the display of available phone
numbers to the user, and culminates in the choosing of a number.
Since the user interface and sequence of events involved in phone
number presentation is a function of the connection management
software being used, it is likely that individual vendors will
take different approaches to the problem. These differences can
include variances in the format of the client phone books, varying
approaches to presentation, etc. There is no inherent problem
with this. As a result, phone number presentation need not be
standardized.
電話番号プレゼンテーション電話数のプレゼンテーションは、利用可能な電話番号のディスプレイにユーザにかかわって、数を選ぶのに終わります。 電話番号プレゼンテーションにかかわるイベントのユーザーインタフェースと系列が使用される接続管理ソフトウェアの機能であるので、個々のベンダーは問題への異なるアプローチを取りそうでしょう。 プレゼンテーションなどへのアプローチを変えて、これらの違いはクライアント電話帳の形式で変化を含むことができます。 これに関するどんな固有の問題もありません。 その結果、電話番号プレゼンテーションは標準化される必要はありません。
Phone number exchange
Phone number exchange involves propagation of phone number changes
between providers in a roaming association. Current roaming
implementations do not provide for complete automation of the
phone number exchange process [1]. As a result, phone number
exchange need not be standardized at this time.
電話番号交換電話数の交換はプロバイダーの間の電話番号変化の伝播にローミング協会にかかわります。 現在のローミング実装は電話番号交換プロセス[1]の完全なオートメーションに備えません。 その結果、電話番号交換はこのとき、標準化される必要はありません。
Phone book compilation
Once an ISP's phone book server has received its updates it needs
to compile a new phone book and propagate this phone book to all
the phone book servers operated by that ISP. Given that the
compilation process does not affect protocol interoperability, it
need not be standardized.
電話帳編集Once、ISPの電話帳サーバはそれが新しい電話帳を編集して、この電話帳を伝播するために必要とするアップデートをそのISPによって操作されたすべての電話帳サーバに受けました。 編集プロセスがプロトコル相互運用性に影響しないなら、それは標準化される必要はありません。
Phone book update
Once the phone book is compiled, it needs to be propagated to
users. Standardization of the phone book update process allows
for providers to update user phone books, independent of their
client software or operating system.
電話帳はOnceをアップデートします。電話帳は編集されて、それは、ユーザに伝播される必要があります。 電話帳更新処理の標準化は、プロバイダーがユーザ電話帳をアップデートするのを許容します、それらのクライアントソフトウェアかオペレーティングシステムの如何にかかわらず。
3.2. Authentication Subsystem
3.2. 認証サブシステム
The authentication subsystem provides for the following:
認証サブシステムは以下に備えます:
Connection management
Authentication
NAS Configuration/Authorization
Address Assignment/Routing
Security
接続管理Authentication NAS Configuration/承認Address Assignment/ルート設定Security
Aboba & Zorn Informational [Page 4] RFC 2477 Evaluating Roaming Protocols January 1999
プロトコル1999年1月に移動するAbobaとゾルン情報[4ページ]のRFC2477Evaluating
Connection management
In order to be able to use the POPs of the local provider, it is
first necessary to bring up a connection.
ローカルのプロバイダーのPOPを使用できる接続管理In注文、接続を育てるのが最初に、必要です。
Identification
Authentication consists of two parts: the claim of identity (or
identification) and the proof of the claim (or verification). As
part of the authentication process, users identify themselves to
the Network Access Server (NAS) in a manner that allows the
authentication request to be routed its home destination.
識別Authenticationは2つの部品から成ります: アイデンティティのクレーム(または、識別)とクレームの証拠(または、検証)。 ユーザは認証過程の一部であると、Network Access Server(NAS)に認証要求が発送されるのを許容する方法で名乗ります。そのホームの目的地。
Authentication
Authentication is typically required prior to allowing access to
the network. CHAP [8] and PAP [9] are the two authentication
protocols most commonly used within the PPP [10] framework today.
Some groups of users are requiring different forms of proof of
identity (e.g., token or smart cards, Kerberos credentials, etc.)
for special purposes (such as acquiring access to corporate
intranets). The Extensible Authentication Protocol (EAP) [7] was
created in order to provide a general mechanism for support of
these methods.
ネットワークへのアクセスを許す前に、認証Authenticationが通常必要です。 CHAP[8]とPAP[9]は今日PPP[10]フレームワークの中で最も一般的に使用されている2つの認証プロトコルです。 ユーザのグループの中には特別な目的(企業イントラネットへのアクセスを取得などなどの)のために異なったフォームの身元(例えば、トークンやスマートカード、ケルベロス資格証明書など)の証拠を必要としているものもあります。 拡張認証プロトコル(EAP)[7]は、これらのメソッドのサポートに一般的機構を提供するために作成されました。
NAS configuration/authorization
In order to set up the session, authorization parameters need to
be sent to from the home authentication server to the local ISP's
NAS.
セッションをセットアップするNAS構成/承認In命令、承認パラメタはホーム認証サーバから地方のISPのNASまで発信する必要があります。
Address assignment/routing
If it is desired that the user be able to communicate with the
rest of the Internet, then the session will be assigned a routable
IP address by the NAS.
課題/ルーティングがIfであると扱ってください。ユーザがインターネットの残りとコミュニケートできることが望まれていて、次に、NASによる発送可能IPアドレスはセッションに割り当てられるでしょう。
Security
In the process of authenticating and authorizing the user session,
it may be desirable to provide protection against a variety of
security threats.
セキュリティIn、ユーザセッションを認証して、認可するプロセス、さまざまな軍事的脅威に対する保護を提供するのは望ましいかもしれません。
3.3. Accounting Subsystem
3.3. 会計サブシステム
The function of the accounting subsystem is to enable the participants in the roaming consortium to keep track of what resources are used during a session. Relevant information includes how long the user was connected to the service, connection speed, port type, etc.
会計サブシステムの機能はローミング共同体の関係者がどんなリソースがセッションの間使用されるかに関する道を保つのを可能にすることです。 関連情報は、ユーザがどれくらい長い間サービス、接続速度、ポートタイプなどに接続されたかを含んでいます。
Aboba & Zorn Informational [Page 5] RFC 2477 Evaluating Roaming Protocols January 1999
プロトコル1999年1月に移動するAbobaとゾルン情報[5ページ]のRFC2477Evaluating
4. Roaming Requirements
4. ローミング要件
4.1. Phonebook requirements
4.1. Phonebook要件
4.1.1. Phone book update protocol
4.1.1. 電話帳アップデートプロトコル
Portability The update protocol MUST allow for updating of clients on a range of platforms and operating systems. Therefore the update mechanism MUST NOT impose any operating system-specific requirements.
アップデートプロトコルがプラットホームとオペレーティングシステムしたがって、さまざまなアップデートメカニズムでクライアントにアップデートすると考慮しなければならない移植性は少しのオペレーティングシステム決められた一定の要求も課してはいけません。
Authentication The client MUST be able to determine the authenticity of the server sending the phone book update. The server MAY also be able to authenticate the client.
クライアントができるに違いない認証は電話帳最新版を送るサーバの信憑性を決定します。 また、サーバはクライアントを認証できるかもしれません。
Versioning The update protocol MUST provide for updating of the phone book from an arbitrary previous version to the latest available version.
アップデートプロトコルをVersioningすると、電話帳の任意の旧バージョンから最新の利用可能なバージョンまでのアップデートは備えられなければなりません。
Integrity Checking The client MUST be able to determine the integrity of the received update before applying it, and MUST be able to determine the integrity of the newly produced phone book after updating it.
クライアントのCheckingがそれをアップデートするのにおいてそれを適用するのにおいて容認されたアップデートの保全を決定できなければならない前、新たに生産された電話帳の保全を決定できなければならない保全。
Light weight transfers Since the client may be a low-end machine or internet appliance, the update protocol MUST be lightweight.
軽量はローエンドマシンかインターネットが器具であったかもしれないならクライアントのSinceを移して、アップデートプロトコルは軽量であるに違いありません。
Language support The phone book update mechanism MUST support the ability to request that the phone book be transmitted in a particular language and character set. For example, if the customer has a Russian language software package, then the propagation and update protocols MUST provide a mechanism for the user to request a Russian language phone book.
電話帳アップデートメカニズムが電話帳が特定の言語と文字集合で伝えられるよう要求する能力をサポートしなければならない言語サポート。 例えば、顧客がロシアの言語ソフトウェアパッケージを持っているなら、ユーザがロシアの言語電話帳を要求するように、伝播とアップデートプロトコルはメカニズムを提供しなければなりません。
4.1.2. Phone book format
4.1.2. 電話帳形式
Phone number attributes The phone book format MUST support phone number attributes commonly used by Internet service providers. These attributes are required in order to provide users with information on the capabilities of the available phone numbers.
電話帳形式がインターネット接続サービス業者によって一般的に使用された電話番号属性をサポートしなければならない電話番号属性。 これらの属性が、利用可能な電話番号の能力の情報をユーザに提供するのに必要です。
Provider attributes In addition to providing information relating to a given phone number, the phone book MUST provide information on the individual
与えられた電話番号に関連する情報を提供することへのプロバイダー属性In追加、電話帳は個人の情報を提供しなければなりません。
Aboba & Zorn Informational [Page 6] RFC 2477 Evaluating Roaming Protocols January 1999
プロトコル1999年1月に移動するAbobaとゾルン情報[6ページ]のRFC2477Evaluating
roaming consortium members. These attributes are required in order to provide users with information about the individual providers in the roaming consortium.
共同体のメンバーに移動します。 これらの属性が、ローミング共同体で個々のプロバイダーの情報をユーザに提供するのに必要です。
Service attributes In addition to providing information relating to a given phone number, and service provider, the phone book MUST provide information relevant to configuration of the service. These attributes are necessary to provide the client with information relating to the operation of the service.
与えられた電話番号、およびサービスプロバイダーに関連する情報を提供することへのサービス属性In追加、電話帳はサービスの構成に関連している情報を提供しなければなりません。 これらの属性が、サービスの操作に関連する情報をクライアントに提供するのに必要です。
Extensibility Since it will frequently be necessary to add phone book attributes, the phone book format MUST support the addition of phone number, provider and service attributes without modification to the update protocol. Registration of new phone book attributes will be handled by IANA. The attribute space MUST be sufficiently large to accomodate growth.
それが頻繁に望んでいる伸展性Sinceは電話帳属性を加えるのに必要です、電話帳形式が電話番号の追加をサポートしなければなりません、プロバイダーということであり、変更なしで属性を修理します。アップデートプロトコルに。 新しい電話帳属性の登録はIANAによって扱われるでしょう。 属性スペースはaccomodateの成長に十分大きくなければなりません。
Compactness Since phone book will typically be frequently updated, the phone book format MUST be compact so as to minimize the bandwidth used in updating it.
コンパクト性Since電話帳を頻繁に通常アップデートして、電話帳形式は、それをアップデートする際に使用される帯域幅を最小にするためにコンパクトでなければなりません。
4.2. Authentication requirements
4.2. 認証要件
4.2.1. Connection Management
4.2.1. 接続管理
Given the current popularity and near ubiquity of PPP, a roaming standard MUST provide support for PPP and IP. A roaming standard MAY provide support for other framing protocols such as SLIP. However, SLIP support is expected to prove difficult since SLIP does not support negotiation of connection parameters and lacks support for protocols other than IP.
PPPの現在の人気の、そして、近い偏在を考えて、ローミング規格はPPPとIPのサポートを提供しなければなりません。 ローミング規格はSLIPなどの他の縁どりプロトコルのサポートを提供するかもしれません。 しかしながら、SLIPが接続パラメタの交渉をサポートしないで、IP以外のプロトコルのサポートを欠いているのでSLIPサポートが、難しいと判明すると予想されます。
A roaming standard MAY provide support for non-IP protocols (e.g., IPX or AppleTalk) since these may be useful for the provision of corporate intranet access via the Internet. Since it is intended that the client will begin PPP negotiation immediately on connection, support for scripting SHOULD NOT be part of a roaming standard.
これらがインターネットを通して企業イントラネットアクセスの支給の役に立つかもしれないので、ローミング規格は非IPプロトコル(例えば、IPXかAppleTalk)のサポートを提供するかもしれません。 クライアントがすぐ接続のPPP交渉を始めることを意図して以来、ローミングの部分が標準であったならSHOULD NOTに原稿を書くのについてサポートします。
4.2.2. Identification
4.2.2. 識別
A roaming standard MUST provide a standardized format for the userID and realm presented to the NAS.
ローミング規格はNASに寄贈されたuserIDと分野のための標準化された形式を提供しなければなりません。
Aboba & Zorn Informational [Page 7] RFC 2477 Evaluating Roaming Protocols January 1999
プロトコル1999年1月に移動するAbobaとゾルン情報[7ページ]のRFC2477Evaluating
4.2.3. Verification of Identity
4.2.3. アイデンティティの検証
Authentication types
A roaming standard MUST support CHAP, and SHOULD support EAP. Due
to security concerns, PAP authentication SHOULD NOT be supported.
A possible exception is where PAP is used to support a one time
password or token.
規格を歩き回っている認証タイプAはCHAPをサポートしなければなりません、そして、SHOULDはEAPをサポートします。 安全上の配慮、PAP認証SHOULD NOTはサポートされますか? 可能な例外はPAPが使い捨てパスワードかトークンをサポートするのに使用されるところです。
Scalability
A roaming standard, once available, is likely to be widely
deployed on the Internet. A roaming standard MUST therefore
provide sufficient scalability to allow for the formation of
roaming associations with thousands of ISP members.
かつて利用可能なスケーラビリティAローミング規格はインターネットで広く配布されそうです。 したがって、ローミング規格は何千人ものISPメンバーとのローミング仲間の構成を考慮できるくらいのスケーラビリティを提供しなければなりません。
RADIUS Support
Given the current popularity and near ubiquity of RADIUS [2,3] as
an authentication, authorization and accounting solution, a
roaming standard MUST be able to incorporate RADIUS-enabled
devices within the roaming architecture. It is expected that this
will be accomplished by development of gateways between RADIUS and
the roaming standard authentication, authorization, and accounting
protocol.
現在の人気と認証としてのRADIUS[2、3]の偏在におけるRADIUS Support Given、承認と会計ソリューション、ローミング規格はローミングアーキテクチャの中にRADIUSによって可能にされたデバイスを組み込むことができなければなりません。 これが移動しているRADIUSの間のゲートウェイの開発、標準の認証、承認、および会計プロトコルによって達成されると予想されます。
4.2.4. NAS Configuration/Authorization
4.2.4. NAS構成/承認
In order to ensure compatibility with the NAS or the local network, authentication/authorization proxies often will add, delete, or modify attributes returned by the home authentication server. In addition, an authentication proxy will often carry out resource management and policy functions. As a result, a roaming standard MUST support the ability of proxies to perform attribute editing and implement policy.
NASか企業内情報通信網との互換性を確実にするために、認証/承認プロキシは、しばしばホーム認証サーバによって返された属性を、加えるか、削除するか、または変更するでしょう。さらに、認証プロキシはしばしば資源管理と方針機能を行うでしょう。 その結果、ローミング規格はプロキシが属性編集を実行して、政策を実施する能力をサポートしなければなりません。
4.2.5. Address assignment/routing
4.2.5. アドレス課題/ルーティング
A roaming standard MUST support dynamic address assignment. Static address assignment MAY be supported, most likely via layer 2 or layer 3 tunneling.
ローミング規格は、ダイナミックなアドレスが課題であるとサポートしなければなりません。 静的なアドレス課題はたぶん層2か層3のトンネリングでサポートされるかもしれません。
Layer 2 tunneling protocols
Layer-2 tunneling protocols, such as PPTP, L2F, or L2TP, hold
great promise for the implementation of Virtual Private Networks
as a means for inexpensive access to remote networks. Therefore
proxy implementations MUST NOT preclude use of layer 2 tunneling.
PPTPなどのプロトコルにトンネルを堀りながらプロトコルLayer-2にトンネルを堀る層2(L2F、またはL2TP)が、リモートネットワークへの安価なアクセスのための手段としてVirtual兵士のNetworksの実装のためのかなりの見込みを有します。 したがって、プロキシ実装は層2のトンネリングの使用を排除してはいけません。
Layer 3 tunneling protocols
Layer-3 tunneling protocols as embodied in Mobile IP [5], hold
great promise for providing "live", transparent mobility on the
層3がモバイルIP[5]に表現されるようにプロトコルにトンネルを堀りながらプロトコルLayer-3にトンネルを堀って、「生きてください」、透明な移動性を提供するのにオンにかなりの見込みを有してください。
Aboba & Zorn Informational [Page 8] RFC 2477 Evaluating Roaming Protocols January 1999
プロトコル1999年1月に移動するAbobaとゾルン情報[8ページ]のRFC2477Evaluating
part of mobile nodes on the Internet. Therefore, a roaming
standard MUST NOT preclude the provisioning of Mobile IP Foreign
Agents or other Mobile IP functionality on the part of service
providers.
インターネットのモバイルノードの一部。 したがって、ローミング規格はサービスプロバイダー側のモバイルIP Foreignエージェントか他のモバイルIPの機能性の食糧を供給することを排除してはいけません。
4.2.6. Security
4.2.6. セキュリティ
Security analysis
A roaming standard MUST include a thorough security analysis,
including a description of security threats and countermeasures.
This includes specification of mechanisms for fraud prevention and
detection.
証券分析Aローミング規格は軍事的脅威と対策の記述を含む徹底的な証券分析を含まなければなりません。 これは詐欺の防止と検出のためのメカニズムの仕様を含んでいます。
Hop by hop security
A roaming standard MUST provide for hop-by-hop integrity
protection and confidentiality. This MAY be accomplished through
support of network layer security (IPSEC) [6].
ホップセキュリティAローミング規格によるホップはホップごとの保全保護と秘密性に備えなければなりません。 これはネットワーク層セキュリティ(IPSEC)[6]のサポートで達成されるかもしれません。
End-to-end security
As policy implementation and attribute editing are common in
roaming systems, proxies may need to modify packets in transit
between a local NAS and the home server. In order to permit
authorized modifications while at the same time guarding against
attacks by rogue proxies, it is necessary for a roaming standard
to support data object security. As a result, a roaming standard
MUST provide end-to-end confidentiality and integrity protection
on an attribute-by-attribute basis. However, non-repudiation is
NOT a requirement for a roaming standard.
終わりから終わりへのセキュリティAs政策の実施と属性編集がローミングシステムで一般的である、プロキシは地方のNASとホームサーバの間のトランジットでパケットを変更する必要があるかもしれません。同時に凶暴なプロキシによる攻撃に用心する間、認可された変更を可能にするために、ローミング規格が、データがオブジェクトセキュリティであるとサポートするのが必要です。 その結果、ローミング規格は属性ごとのベースで終わりから終わりへの秘密性と保全保護を提供しなければなりません。 しかしながら、非拒否はローミング規格のための要件ではありません。
4.3. Accounting requirements
4.3. 会計要件
Real-time accounting
In today's roaming implementations, real-time accounting is a
practical necessity in order to support fraud detection and risk
management. As a result, a roaming standard MUST provide support
for real-time accounting.
リアルタイムで、Inを説明して、今日は実装に移動していて、リアルタイムの会計は、詐欺が検出とリスク管理であるとサポートする実用的な必要性です。 その結果、ローミング規格はリアルタイムの会計のサポートを提供しなければなりません。
Accounting record formats
Today there is no proposed standard for NAS accounting, and there
is wide variation in the protocols used by providers to
communicate accounting information within their own organizations.
Therefore, a roaming standard MUST prescribe a standardized format
for accounting records. For the sake of efficiency, the record
format MUST be compact.
そこの会計レコード形式TodayはNAS会計の提案された標準ではありません、そして、プロバイダーによって使用される、それら自身の組織の中で課金情報を伝えるプロトコルの広い変化があります。 したがって、ローミング規格は会計帳簿のための標準化された形式を定めなければなりません。 効率のために、レコード形式はコンパクトであるに違いありません。
Extensibility
A standard accounting record format MUST be able to encode metrics
commonly used to determine the user's bill. Since these metrics
伸展性のA標準の会計帳簿形式はユーザの請求書を決定するのに一般的に使用される測定基準をコード化できなければなりません。 これらの測定基準以来
Aboba & Zorn Informational [Page 9] RFC 2477 Evaluating Roaming Protocols January 1999
プロトコル1999年1月に移動するAbobaとゾルン情報[9ページ]のRFC2477Evaluating
change over time, the accounting record format MUST be extensible
so as to be able to add future metrics as they come along. The
record format MUST support both standard metrics as well as
vendor-specific metrics.
時間の変化、会計レコード形式は、やって来るとき将来の測定基準を加えることができるように広げることができなければなりません。 レコード形式は標準の測定基準とベンダー特有の測定基準の両方をサポートしなければなりません。
5. References
5. 参照
[1] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, "Review of
Roaming Implementations", RFC 2194, September 1997.
[1]Aboba、B.、Lu、J.、Alsop、J.、鐘の音、J.、およびW.ワング、「ローミング実装のレビュー」、RFC2194、1997年9月。
[2] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April
1997.
[2]RigneyとC.とルーベンとA.とシンプソン、W.とS.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2138(1997年4月)。
[3] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[3]Rigney、C.、「半径会計」、RFC2139、1997年4月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[5] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[5] パーキンス、C.、「IP移動性サポート」、RFC2002、1996年10月。
[6] Kent, S. and R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
[6] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[7] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.
[7]BlunkとL.と1998年のJ.Vollbrecht、「ppp拡張認証プロトコル(EAP)」、RFC2284行進。
[8] Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996.
[8] シンプソン、W.、「pppチャレンジハンドシェイク式認証プロトコル(やつ)」、RFC1994、1996年8月。
[9] Lloyd, B. and Simpson, W., "PPP Authentication Protocols", RFC
1334, October 1992.
[9] ロイドとB.とシンプソン、W.、「ppp認証プロトコル」、RFC1334、1992年10月。
[10] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
[10] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
6. Security Considerations
6. セキュリティ問題
This document, being a requirements document, does not have any security concerns. The security requirements on protocols to be evaluated using this document are mainly described in section 5.2.
このドキュメントには、要件ドキュメントであり、どんな安全上の配慮もありません。 このドキュメントを使用することで評価されるというプロトコルに関するセキュリティ要件はセクション5.2で主に説明されます。
7. Acknowledgements
7. 承認
Thanks to Pat Calhoun (pcalhoun@eng.sun.com), Butch Anton (butch@ipass.com) and John Vollbrecht (jrv@merit.edu) for many useful discussions of this problem space.
この問題スペースの多くの役に立つ議論をパットCalhoun( pcalhoun@eng.sun.com )、Butchアントン( butch@ipass.com )、およびジョンVollbrecht( jrv@merit.edu )をありがとうございます。
Aboba & Zorn Informational [Page 10] RFC 2477 Evaluating Roaming Protocols January 1999
プロトコル1999年1月に移動するAbobaとゾルン情報[10ページ]のRFC2477Evaluating
8. Authors' Addresses
8. 作者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: 425-936-6605 EMail: bernarda@microsoft.com
以下に電話をしてください。 425-936-6605 メールしてください: bernarda@microsoft.com
Glen Zorn Microsoft Corporation One Microsoft Way Redmond, WA 98052
谷間ゾルンマイクロソフト社1つのマイクロソフト道、レッドモンド、ワシントン 98052
Phone: 425-703-1559 EMail: glennz@microsoft.com
以下に電話をしてください。 425-703-1559 メールしてください: glennz@microsoft.com
Aboba & Zorn Informational [Page 11] RFC 2477 Evaluating Roaming Protocols January 1999
プロトコル1999年1月に移動するAbobaとゾルン情報[11ページ]のRFC2477Evaluating
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Aboba & Zorn Informational [Page 12]
AbobaとゾルンInformationalです。[12ページ]
一覧
スポンサーリンク
