[要約] RFC 2477は、ローミングプロトコルの評価基準を提供するためのガイドラインです。その目的は、異なるネットワーク間でのユーザーの移動をサポートするための効果的なローミングプロトコルの選択と実装を促進することです。
Network Working Group B. Aboba
Request for Comments: 2477 G. Zorn
Category: Informational Microsoft Corporation
January 1999
Criteria for Evaluating Roaming Protocols
ローミングプロトコルを評価するための基準
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
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.
このドキュメントでは、ダイヤルアップインターネットユーザー用の「ローミング機能」のプロビジョニングの要件について説明します。 「ローミング機能」は、複数のインターネットサービスプロバイダー（ISP）を使用しながら、1つだけの正式な顧客とベンダーの関係を維持する機能として定義されます。
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つ以上の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).
従業員にグローバルなダイヤルアップサービスの包括的なパッケージを提供することを望む企業。これらのサービスには、インターネットアクセスだけでなく、仮想プライベートネットワーク（VPN）を介した企業イントラネットへの安全なアクセスも含まれます。
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.
このドキュメントでは、ローミング機能をプロビジョニングするためのアーキテクチャフレームワークを提供するとともに、アーキテクチャの要素が満たす必要のある要件について説明します。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [4].
このドキュメントでは、キーワード「MAY」、「MUST、「MUST NOT」、「optional」、「recommended」、「SHOULD」、および「SHOULD NOT」は、[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つ以上の必須要件または非必須要件を満たさない場合、準拠しません。その機能の要件をすべて満たす必要がある、満たさない、満たすべきではないプロトコル提出は、「無条件に準拠する」と言われます。すべての必須要件と必須要件を満たさないが、プロトコルのすべての必須要件と必須要件を満たさないものは、「条件付きで準拠している」と言います。
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.
電話帳これは、電話番号や関連する属性など、ダイヤルアップアクセスに関するデータを含むデータベースまたはドキュメントです。
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.
電話帳サーバーこれは、電話帳の最新バージョンを維持するサーバーです。クライアントは、電話帳を最新の状態に保つために電話帳サーバーと通信します。
Network Access Server The Network Access Server (NAS) is the device that clients dial in order to get access to the network.
ネットワークアクセスサーバーネットワークアクセスサーバー（NAS）は、クライアントがネットワークにアクセスするためにダイヤルするデバイスです。
Authentication server This is a server which provides for authentication/authorization within the roaming architecture.
認証サーバーこれは、ローミングアーキテクチャ内で認証/承認を提供するサーバーです。
Accounting server This is a server which provides for accounting within the roaming architecture.
アカウンティングサーバーこれは、ローミングアーキテクチャ内でアカウンティングを提供するサーバーです。
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.
認証プロキシ認証プロキシは、認証転送、ポリシー実装、共有シークレット管理、属性編集など、いくつかの目的でローミングアーキテクチャ内に展開できます。 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.
アカウンティングプロキシアカウンティングプロキシは、アカウンティングの転送、信頼性の向上、監査、「疑似トランザクション」機能など、いくつかの目的でローミングアーキテクチャ内に展開できます。 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.
ネットワークアクセス識別子認証およびアカウンティングパケットのルーティングを提供するために、ユーザー名に構造を含めることができます。この構造は、認証またはアカウンティングプロキシが、要求を受信する認証またはアカウンティングサーバーを見つける手段を提供します。
The roaming architecture consists of three major subsystems:
ローミングアーキテクチャは、3つの主要なサブシステムで構成されています。
Phone book 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.
電話帳サブシステムは、ユーザーの電話帳の保守と更新に関係しています。電話帳は、ローミングが有効になっているPoint of Presence（POP）の場所と電話番号に関する情報をユーザーに提供します。認証サブシステムの機能は、許可されたユーザーに電話帳のPOPへのアクセスを提供し、許可されていないユーザーのアクセスを拒否することです。会計サブシステムの目的は、ユーザーのセッション中に使用されるリソースに関する情報を提供することです。
The phone book subsystem provides for the following:
電話帳サブシステムは、以下を提供します。
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.
電話帳のコンパイル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.
電話帳の更新電話帳がコンパイルされたら、ユーザーに伝達する必要があります。電話帳の更新プロセスの標準化により、プロバイダーはクライアントソフトウェアやオペレーティングシステムに関係なく、ユーザーの電話帳を更新できます。
The authentication subsystem provides for the following:
認証サブシステムは、以下を提供します。
Connection management Authentication NAS Configuration/Authorization Address Assignment/Routing Security
接続管理認証NAS構成/許可アドレス割り当て/ルーティングセキュリティ
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を使用できるようにするには、まず接続を確立する必要があります。
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.
識別認証は2つの部分で構成されます。ID（またはID）の要求と、要求（または検証）の証明です。認証プロセスの一部として、ユーザーは、ネットワークアクセスサーバー（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.
認証認証は通常、ネットワークへのアクセスを許可する前に必要です。 CHAP [8]とPAP [9]は、現在PPP [10]フレームワーク内で最も一般的に使用されている2つの認証プロトコルです。一部のユーザーグループは、特別な目的（企業のイントラネットへのアクセス権の取得など）のために、さまざまな形式のIDの証明（トークンまたはスマートカード、Kerberos資格情報など）を必要としています。拡張認証プロトコル（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構成/承認セッションをセットアップするには、承認パラメータをホーム認証サーバーからローカル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.
アドレスの割り当て/ルーティングユーザーが残りのインターネットと通信できることが望ましい場合、セッションには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.
セキュリティユーザーセッションを認証および承認するプロセスでは、さまざまなセキュリティの脅威に対する保護を提供することが望ましい場合があります。
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.
会計サブシステムの機能は、ローミングコンソーシアムの参加者がセッション中に使用されたリソースを追跡できるようにすることです。関連情報には、ユーザーがサービスに接続していた時間、接続速度、ポートタイプなどが含まれます。
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.
認証クライアントは、電話帳の更新を送信するサーバーの信頼性を判断できなければなりません（MUST）。サーバーはクライアントを認証することもできます。
Versioning The update protocol MUST provide for updating of the phone book from an arbitrary previous version to the latest available version.
バージョン管理更新プロトコルでは、電話帳を任意の以前のバージョンから最新の利用可能なバージョンに更新する必要があります。
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.
整合性チェッククライアントは、適用する前に受信した更新の整合性を判別できなければならず、更新後に新しく生成された電話帳の整合性を判別できなければなりません（MUST）。
Light weight transfers Since the client may be a low-end machine or internet appliance, the update protocol MUST be lightweight.
軽量転送クライアントはローエンドマシンまたはインターネットアプライアンスであるため、更新プロトコルは軽量である必要があります。
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.
言語サポート電話帳更新メカニズムは、電話帳が特定の言語と文字セットで送信されることを要求する機能をサポートする必要があります。たとえば、顧客がロシア語のソフトウェアパッケージを持っている場合、伝播および更新プロトコルは、ユーザーがロシア語の電話帳を要求するためのメカニズムを提供する必要があります。
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 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.
サービス属性電話帳は、特定の電話番号とサービスプロバイダーに関連する情報を提供することに加えて、サービスの構成に関連する情報を提供する必要があります。これらの属性は、サービスの操作に関する情報をクライアントに提供するために必要です。
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.
拡張性電話帳の属性を追加する必要があることが多いため、電話帳の形式は、更新プロトコルを変更せずに、電話番号、プロバイダー、およびサービスの属性の追加をサポートする必要があります。新しい電話帳属性の登録は、IANAによって処理されます。属性スペースは、成長に対応するのに十分な大きさでなければなりません。
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.
コンパクト電話帳は通常頻繁に更新されるため、電話帳の形式は、更新に使用される帯域幅を最小限に抑えるためにコンパクトでなければなりません。
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など）のサポートを提供する場合があります（MAY）。これらは、インターネットを介した企業イントラネットアクセスのプロビジョニングに役立つ場合があるためです。クライアントは接続時にすぐにPPPネゴシエーションを開始することを目的としているため、スクリプトのサポートはローミング標準の一部であってはなりません（SHOULD NOT）。
A roaming standard MUST provide a standardized format for the userID and realm presented to the NAS.
ローミング標準は、NASに提示されるユーザーIDとレルムの標準化された形式を提供する必要があります。
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.
認証タイプローミング標準はCHAPをサポートしなければならず（MUST）、EAPをサポートする必要があります（SHOULD）。セキュリティ上の理由により、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.
スケーラビリティローミング標準が利用可能になると、インターネット上で広く展開される可能性があります。したがって、ローミング標準は、何千もの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のサポート現在、RADIUS [2,3]が認証、承認、アカウンティングソリューションとして広く普及していることを考えると、ローミング標準は、RADIUS対応デバイスをローミングアーキテクチャ内に組み込む必要があります。これは、RADIUSとローミング標準の認証、承認、およびアカウンティングプロトコルとの間のゲートウェイの開発によって実現されることが期待されます。
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またはローカルネットワークとの互換性を確保するために、認証/承認プロキシは、多くの場合、ホーム認証サーバーから返される属性を追加、削除、または変更します。さらに、認証プロキシは多くの場合、リソース管理とポリシー機能を実行します。その結果、ローミング標準は、属性編集を実行してポリシーを実装するプロキシの機能をサポートする必要があります。
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.
レイヤー2トンネリングプロトコルPPTP、L2F、L2TPなどのレイヤー2トンネリングプロトコルは、リモートネットワークへの安価なアクセス手段としての仮想プライベートネットワークの実装に大きな期待を寄せています。したがって、プロキシ実装はレイヤ2トンネリングの使用を妨げてはなりません（MUST NOT）。
Layer 3 tunneling protocols Layer-3 tunneling protocols as embodied in Mobile IP [5], hold great promise for providing "live", transparent mobility on the 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.
レイヤー3トンネリングプロトコルモバイルIP [5]で具体化されたレイヤー3トンネリングプロトコルは、インターネット上のモバイルノードの一部に「ライブ」の透過的なモビリティを提供することを約束します。したがって、ローミング標準は、サービスプロバイダー側でのモバイルIP外部エージェントまたはその他のモバイルIP機能のプロビジョニングを妨げてはなりません。
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.
セキュリティ分析ローミング標準には、セキュリティの脅威と対策の説明を含む、完全なセキュリティ分析が含まれている必要があります。これには、不正防止と検出のメカニズムの仕様が含まれます。
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].
ホップバイホップセキュリティローミング標準は、ホップバイホップの完全性保護と機密性を提供しなければなりません（MUST）。これは、ネットワーク層セキュリティ（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.
エンドツーエンドのセキュリティポリシーの実装と属性の編集はローミングシステムでは一般的であるため、プロキシはローカルNASとホームサーバーの間の転送中にパケットを変更する必要がある場合があります。承認された変更を許可すると同時に、不正なプロキシによる攻撃を防ぐには、ローミング標準がデータオブジェクトのセキュリティをサポートする必要があります。その結果、ローミング標準は、属性ごとにエンドツーエンドの機密性と整合性保護を提供する必要があります。ただし、否認防止はローミング標準の要件ではありません。
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.
リアルタイムアカウンティング今日のローミング実装では、不正の検出とリスク管理をサポートするために、リアルタイムアカウンティングは実際に必要です。その結果、ローミング標準は、リアルタイムアカウンティングのサポートを提供する必要があります。
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.
アカウンティングレコードの形式今日、NASアカウンティングの標準は提案されておらず、プロバイダーが自分の組織内でアカウンティング情報を通信するために使用するプロトコルには、さまざまなバリエーションがあります。したがって、ローミング標準では、アカウンティングレコードの標準化された形式を規定する必要があります。効率を上げるために、レコード形式はコンパクトでなければなりません。
Extensibility A standard accounting record format MUST be able to encode metrics commonly used to determine the user's bill. Since these metrics 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.
拡張性標準のアカウンティングレコード形式は、ユーザーの請求書を決定するために一般的に使用されるメトリックをエンコードできる必要があります。これらのメトリックは時間の経過とともに変化するため、将来のメトリックを追加できるように、アカウンティングレコード形式は拡張可能でなければなりません。レコード形式は、標準のメトリックとベンダー固有のメトリックの両方をサポートする必要があります。
[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.、Alsopp、J.、Ding、J。およびW. Wang、「ローミング実装のレビュー」、RFC 2194、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.、Rubens、A.、Simpson、W。、およびS. Willens、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2138、1997年4月。
[3] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[3] リグニー、C。、「RADIUSアカウンティング」、RFC 2139、1997年4月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[5] パーキンス、C。、「IPモビリティサポート」、RFC 2002、1996年10月。
[6] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[6] ケントS.およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[7] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[7] Blunk、L.およびJ. Vollbrecht、「PPP Extensible Authentication Protocol（EAP）」、RFC 2284、1998年3月。
[8] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[8] シンプソン、W。、「PPPチャレンジハンドシェイク認証プロトコル（CHAP）」、RFC 1994、1996年8月。
[9] Lloyd, B. and Simpson, W., "PPP Authentication Protocols", RFC 1334, October 1992.
[9] ロイドB.およびシンプソンW。、「PPP認証プロトコル」、RFC 1334、1992年10月。
[10] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[10] Simpson、W。、「The Point-to-Point Protocol（PPP）」、STD 51、RFC 1661、1994年7月。
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で説明されています。
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.
この問題空間に関する多くの有用な議論をしてくれたPat Calhoun（pcalhoun@eng.sun.com）、Butt Anton（butch@ipass.com）およびJohn Vollbrecht（jrv@merit.edu）に感謝します。
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードアボバマイクロソフトコーポレーションワンマイクロソフトウェイレドモンド、ワシントン州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
グレンゾーンマイクロソフトコーポレーションワンマイクロソフトウェイレドモンド、ワシントン州98052
Phone: 425-703-1559 EMail: glennz@microsoft.com
電話：425-703-1559メール：glennz@microsoft.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
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.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。