RFC2194 日本語訳
2194 Review of Roaming Implementations. B. Aboba, J. Lu, J. Alsop, J.Ding, W. Wang. September 1997. (Format: TXT=81533 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Aboba
Request for Comments: 2194 Microsoft
Category: Informational J. Lu
AimQuest Corp.
J. Alsop
i-Pass Alliance
J. Ding
Asiainfo
W. Wang
Merit Network, Inc.
September 1997
Abobaがコメントのために要求するワーキンググループB.をネットワークでつないでください: 2194年のマイクロソフトカテゴリ: 情報のJ.のW.ワング長所ネットワークInc.Lu AimQuest社のJ.Alsop i-パス同盟J.鐘の音Asiainfo1997年9月
Review of Roaming Implementations
ローミング実装のレビュー
1. Status of this Memo
1. このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
2. Abstract
2. 要約
This document reviews the design and functionality of existing roaming implementations. "Roaming capability" may be loosely defined as the ability to use any one of multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support.
このドキュメントは実装に移動しながら存在するデザインと機能性を再検討します。 「ローミング能力」は1だけとの正式な顧客ベンダー関係を維持している間、緩く複数のインターネット接続サービス業者(ISP)のどれかを使用する能力と定義されるかもしれません。 ローミング能力が必要であるかもしれないケースに関する例はISP「同盟者」とISPに提供された企業ネットワークアクセスサポートを含んでいます。
3. Introduction
3. 序論
Considerable interest has arisen recently in a set of features that fit within the general category of "roaming capability" for Internet users. Interested parties have included:
相当な興味は最近、インターネットユーザのために「ローミング能力」の一般的なカテゴリの中で合う特徴のセットで起こりました。 利害関係者は含みました:
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 service over a
wider area.
より広い領域をサービスオーバーに提供するために他の地方のプロバイダーのものにそれらの取り組みを結合するために見て、特定の州か州の中で作動する地方のインターネットサービスプロバイダ(ISP)。
National ISPs wishing to combine their operations with those of
one or more ISPs in another nation to offer more comprehensive
service in a group of countries or on a continent.
国のグループか大陸の上で、より包括的なサービスを提供するためにもう1人の国の1つ以上のISPのものに彼らの操作を結合したがっている国家のISP。
Businesses desiring to offer their employees a comprehensive
package of access services on a global basis. Those services may
地球規模でアクセス・サービスの包括的なパッケージを彼らの従業員に提供することを望んでいるビジネス。 それらのサービスはそうするかもしれません。
Aboba, et. al. Informational [Page 1] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[1ページ]のRFC2194レビュー
include Internet access as well as secure access to corporate
intranets via a Virtual Private Network (VPN), enabled by
tunneling protocols such as PPTP, L2F, or L2TP.
PPTP、L2F、またはL2TPなどのトンネリングプロトコルによって有効にされたVirtual兵士のNetwork(VPN)を通して企業イントラネットへの安全なアクセスと同様にインターネット・アクセスを含めてください。
What is required to provide roaming capability? The following list is a first cut at defining the requirements for successful roaming among an arbitrary set of ISPs:
何が、能力に移動しながら提供するのに必要ですか? 以下のリストは任意のセットのISPの中のうまくいっているローミングのための要件を定義するところの最初のカットです:
Phone number presentation
Phone number exchange
Phone book compilation
Phone book update
Connection management
Authentication
NAS Configuration/Authorization
Address assignment and routing
Security
Accounting
電話番号プレゼンテーション電話数の交換電話本の編集電話本のアップデートConnection管理Authentication NAS Configuration/承認Address課題とルーティングSecurity Accounting
In this document we review existing roaming implementations, describing their functionality within this framework. In addition to full fledged roaming implementations, we will also review implementations that, while not meeting the strict definition of roaming, address several of these problem elements. These implementations typically fall into the category of shared use networks or non-IP dialup networks.
このフレームワークの中でそれらの機能性について説明して、本書では私たちは、実装に移動しながら存在しながら、論評します。 また、完全なローミング実装に加えて、私たちはローミングの厳しい定義を満たしていない間にこれらの問題要素の数個を扱う実装を見直すつもりです。 これらの実装はネットワークか非IPダイアルアップがネットワークでつなぐ共有された使用のカテゴリに通常なります。
3.1. Terminology
3.1. 用語
This document frequently uses the following terms:
このドキュメントは頻繁に次の用語を使用します:
home ISP This is the Internet service provider with whom the user
maintains an account relationship.
ホームISP Thisはユーザがアカウント関係を維持するインターネット接続サービス業者です。
local ISP This is the Internet service provider whom the user calls
in order to get access. Where roaming is implemented the local
ISP may be different from the home ISP.
地方のISP Thisはユーザがアクセサリーを得るために呼ぶインターネット接続サービス業者です。 ローミングがどこで地方のISPであると実装されるかは、ホームISPと異なっているかもしれません。
phone book
This is a database or document containing data pertaining to
dialup access, including phone numbers and any associated
attributes.
電話帳Thisはダイアルアップアクセスに関係するデータを含むデータベースかドキュメントです、電話番号とどんな関連属性も含んでいて。
Aboba, et. al. Informational [Page 2] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[2ページ]のRFC2194レビュー
shared use network
This is an IP dialup network whose use is shared by two or
more organizations. Shared use networks typically implement
distributed authentication and accounting in order to
facilitate the relationship among the sharing parties. Since
these facilities are also required for implementation of
roaming, implementation of shared use is frequently a first
step toward development of roaming capabilities. In fact, one
of the ways by which a provider may offer roaming service is
to conclude shared use agreements with multiple networks.
However, to date the ability to accomplish this has been
hampered by lack of interoperability among shared use
implementations.
共有されて、ネットワークを使用してください。Thisは使用が2つ以上の組織によって共有されるIPダイアルアップネットワークです。 ネットワークが通常実装する共有された使用は、共有パーティーで関係を容易にするために認証と会計を広げました。 また、これらの施設がローミングの実装に必要であるので、頻繁に共有された使用の実装はローミング能力の開発に向かった第一歩です。 事実上、プロバイダーがローミング・サービスを提供するかもしれない方法の1つは共有されて、複数のネットワークとの協定を使用するように結論づけることです。 しかしながら、これを達成する能力が共有される中で相互運用性の不足によって妨げられた日付に、実装を使用してください。
non-IP dialup network
This is a dialup network providing user access to the member
systems via protocols other than IP. These networks may
implement phone book synchronization facilities, in order to
provide systems, administrators and users with a current list
of participating systems. Examples of non-IP dialup networks
supporting phone book synchronization include FidoNet and
WWIVnet.
IP以外のプロトコルを通したメンバーシステムへのユーザアクセスであるなら、非IPダイアルアップネットワークThisはダイアルアップネットワークです。 これらのネットワークは、電話帳同期が施設であると実装するかもしれません、参加システムの現在のリストにシステム、管理者、およびユーザを提供するために。電話帳同期をサポートする非IPダイアルアップネットワークに関する例はFidoNetとWWIVnetを含んでいます。
4. Global Reach Internet Consortium (GRIC)
4. グローバルな範囲インターネット共同体(GRIC)
Led by a US-based Internet technology developer, AimQuest Corporation, ten Internet Service Providers (ISPs) from the USA, Australia, China, Japan, Hong Kong, Malaysia, Singapore, Taiwan, and Thailand formed the Global Reach Internet Connection (GRIC) in May, 1996. The goals of GRIC were to facilitate the implementation of a global roaming service and to coordinate billing and settlement among the membership. Commercial operation began in December of 1996, and GRIC has grown to over 100 major ISPs and Telcos from all over the world, including NETCOM, USA; KDD and Mitsubishi, Japan; iStar, Canada; Easynet, UK; Connect.com, Australia; Iprolink, Switzerland; Singapore Telecom; Chunghwa Telecom, Taiwan; and Telekom Malaysia. Information on GRIC is available from http://www.gric.net/.
米国ベースのインターネット技術開発者、エイムクエスト社によって導かれて、日本、香港(マレーシア)の米国、オーストラリア、中国、シンガポール、台湾、およびタイからの10のインターネットサービスプロバイダ(ISP)が1996年5月にGlobal ReachインターネットConnection(GRIC)を形成しました。 GRICの目標は、国際ローミング・サービスの実装を容易にして、会員資格の中で課金決済を調整することでした。 商業活動は1996年12月に始まりました、そして、GRICは世界中からの100以上の主要なISPと通信業者まで成長しました、Netcom、米国を含んでいて。 KDDと三菱、日本。 iStar、カナダ。 Easynet、イギリス。 Connect.com、オーストラリア。 Iprolink、スイス。 シンガポールテレコム。 Chunghwaテレコム、台湾。 そして、Telekomマレーシア。 GRICに関する情報は http://www.gric.net/ から利用可能です。
In implementing their roaming service, GRIC members have chosen software developed by AimQuest. AimQuest Corporation's roaming implementation comprises the following major components: the AimTraveler Authentication Server (AAS), the AimTraveler Routing Server (ARS), and the AimQuest Internet Management System (AIMS), software designed to facilitate the billing process. Information on the AimQuest roaming implementation is available from http://www.aimquest.com/.
それらのローミングがサービスであると実装する際に、GRICメンバーはAimQuestによって開発されたソフトウェアを選びました。 エイムクエスト社のローミング実装は以下の主要コンポーネントを包括します: AimTraveler Authentication Server(AAS)、AimTravelerルート設定Server(ARS)、およびAimQuestインターネットManagement System(AIMS)、支払いを容易にするように設計されたソフトウェアは処理されます。 AimQuestローミング実装に関する情報は http://www.aimquest.com/ から利用可能です。
Aboba, et. al. Informational [Page 3] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[3ページ]のRFC2194レビュー
The AimTraveler Authentication Server (AAS) runs at each member ISP location, and handles incoming authentication requests from NAS devices and other AASes. The AimTraveler Routing Server (ARS) can run anywhere. A single routing server can be used where centralized routing is desired, or multiple routing servers can be run in order to increase speed and reliability or to gateway to networks of particularly large partners.
AimTraveler Authentication Server(AAS)はそれぞれのメンバーISP位置で稼働していて、NASデバイスと他のAASesから入って来る認証要求を扱います。 AimTravelerルート設定Server(ARS)はどこでも稼働できます。 集結されたルーティングが望まれているか、複数のルーティングサーバが速度と信頼性を増強する命令に立候補することであるかもしれないところか特に大きいパートナーのネットワークへのゲートウェイにただ一つのルーティングサーバを使用できます。
The first version of the AimTraveler software, deployed by AimQuest in May, 1996, supported direct authentication between members of the roaming consortium, but as GRIC grew, management of the relationships between the authentication servers became a problem. In August. 1996, AimQuest began development of the AimTraveler Routing Server (ARS) in order to improve scalability.
ローミング共同体にもかかわらず、GRICが成長したのでメンバーの間のダイレクト認証であるとサポートされた、1996年5月にAimQuestによって配布されたAimTravelerソフトウェアの最初のバージョン、認証サーバの間の関係の管理は問題になりました。 8月に。 1996 AimQuestは、スケーラビリティを改良するためにAimTravelerルート設定Server(ARS)の開発を始めました。
The routing server is comprised of two elements: The Central Accounting Server and the Central Routing Server. The Central Accounting Server collects all the roaming accounting data for settlement. The Central Routing Server manages and maintains information on the authentication servers in the roaming consortium. Adding, deleting, or updating ISP authentication server information (e.g. adding a new member ISP) may be accomplished by editing of a configuration file on the Central Routing Server. The configuration files of the AimTraveler Authentication Servers do not need to be modified.
ルーティングサーバは2つの要素から成ります: ルート設定ServerセントラルAccounting ServerとセントラルセントラルAccounting Serverは解決のためのすべてのローミング会計データを集めます。 セントラルルート設定Serverはローミング共同体で認証サーバの情報を管理して、保守します。 ISP認証サーバ情報(例えば、新しいメンバーISPを加える)を加えるか、削除するか、またはアップデートするのがセントラルルート設定Serverにおける構成ファイルの編集で実行されるかもしれません。AimTraveler Authentication Serversに関する構成ファイルは変更される必要はありません。
The AimTraveler Authentication and Routing Servers are available for various UNIX platforms. Versions for Windows NT are under development. The AimTraveler Authentication Server supports both the UNIX password file and Kerberos.
AimTraveler Authenticationとルート設定Serversは様々なUNIXプラットホームに利用可能です。Windows NTのためのバージョンは開発中です。 AimTraveler Authentication Serverは、両方がUNIXパスワードファイルとケルベロスであるとサポートします。
The AimQuest Internet Management System (AIMS) is designed for large ISPs who need a centralized management system for all ISP operations, including sales, trouble-ticketing, service, and billing. AIMS produces usage and transaction statement reports, and includes a settlement module to produce settlement/billing reports for the roaming consortium members. Based on these reports, the providers charge their ISP/roaming customers, and pay/settle the roaming balance among the providers. AIMS currently runs on Sun/Solaris/Oracle. A version for Windows NT and SQL Server is expected to become available in Q4 1996.
AimQuestインターネットManagement System(AIMS)はすべてのISP操作の集中的管理システムを必要とする大きいISPのために設計されています、販売、問題チケット発行、サービス、および支払いを含んでいて。 AIMSは、ローミング共同体のメンバーのために解決/支払いレポートを製作するために用法とトランザクション声明レポートを製作して、解決モジュールを含んでいます。 これらのレポートに基づいて、プロバイダーは、プロバイダーの中でローミング残額を彼らのISP/ローミング顧客を請求して、支払うか、または精算します。 AIMSは現在、Sun/Solaris/オラクルの上で作業します。 Windows NTとSQLサーバーのためのバージョンがQ4 1996で利用可能になると予想されます。
4.1. Phone number presentation
4.1. 電話番号プレゼンテーション
Currently there are two principal methods by which GRIC users can discover available phone numbers: a Web-based directory provided by the GRIC secretariat, and a GRIC phone book client on the user PC with dialing capability.
現在、GRICユーザが利用可能な電話番号を発見できる2つの主要なメソッドがあります: ユーザPCの上でGRIC事務局、およびGRIC電話帳クライアントによって能力にダイヤルするのに提供されたウェブベースのディレクトリ。
Aboba, et. al. Informational [Page 4] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[4ページ]のRFC2194レビュー
4.1.1. Web based directory
4.1.1. ウェブはディレクトリを基礎づけました。
A directory of GRIC phone numbers is available on the GRIC home page, http://www.gric.com/. The list of numbers is arranged by country and provider. For each provider within a country, this directory, provided in the form of a table, offers the following information:
GRIC電話番号のディレクトリはGRICホームページで利用可能です、 http://www.gric.com/ 。数のリストは国とプロバイダーによってアレンジされます。 国の中の各プロバイダーのために、テーブルの形に提供されたこのディレクトリは以下の情報を提供します:
Provider address, voice phone and fax
Customer support phone number
Provider domain name
Primary Domain Name Server
Secondary Domain Name Server
Dial-up IP Address
News server
Web page
POP phone numbers (i.e. 1-408-366-9000)
POP locations (i.e. Berkeley)
Proxy addresses
Dialer configuration
プロバイダーアドレス、音声電話、およびファックスCustomerは、電話番号Providerドメイン名Primary Domain Name Server Secondary Domain Name Server Dial上がっているIP Address NewsサーバウェブページPOP電話番号(すなわち、1-408-366-9000)POP位置(すなわち、バークレー)のプロキシアドレスがDialer構成であるとサポートします。
In order to discover phone numbers using the Web-based directory, it is expected that users will be online, and will navigate to the appropriate country and provider. They then look up the number and insert it into the AimQuest Ranger dialer.
ウェブベースのディレクトリを使用することで電話番号を発見するために、ユーザがオンラインであり、適切な国とプロバイダーへナビゲートすると予想されます。 彼らは、次に、数を見上げて、AimQuest Rangerダイヤラーにそれを挿入します。
4.1.2. GRIC phone book client
4.1.2. GRIC電話帳クライアント
The GRIC phone book client software provides for phone book presentation as well as automated updating of phone numbers. The GRIC phone book includes a list of countries, states, cities and area/city codes, as well as detailed provider information, including the cutomer support phone number, and Internet server configuration info. The Phone book, developed with Java, is available for download from the AimQuest Web site:
GRIC電話帳クライアントソフトウェアは電話番号の自動化されたアップデートと同様に電話帳プレゼンテーションに備えます。 GRIC電話帳は国、州、都市、詳細なプロバイダー情報と同様にcutomerサポート電話番号を含む領域/都市名コード、およびインターネット・サーバ構成インフォメーションのリストを含んでいます。 AimQuestウェブサイトからJavaと共に開発された電話の本はダウンロードできます:
http://www.aimquest.com/dialer.html
http://www.aimquest.com/dialer.html
4.2. Phone number exchange
4.2. 電話番号交換
GRIC members submit information both about themselves and their POPs to the GRIC secretariat, which is run by AimQuest. The GRIC secretariat then compiles a new phone book and provides updates on the GRIC FTP and Web servers.
GRICメンバーはAimQuestによって経営されているGRIC事務局に自分たちと彼らのPOPの情報を提出します。 GRIC事務局は、次に、新しい電話帳を編集して、GRIC FTPとウェブサーバに関する最新情報を提供します。
GRIC users then download the phone numbers either in Windows .ini file format or in HTML.
そして、GRICユーザは.iniファイルがフォーマットするウィンドウズかHTMLにおける電話番号をダウンロードします。
Aboba, et. al. Informational [Page 5] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[5ページ]のRFC2194レビュー
4.3. Phone book compilation
4.3. 電話帳編集
GRIC phone books are compiled manually, and represent a concatenation of available numbers from all the members of the roaming consortium, with no policy application. As new POPs come online, the numbers are forwarded to GRIC, which adds them to the phone book servers.
GRIC電話帳は、ローミング共同体のすべてのメンバーから手動でコンパイルされて、有効な数の連結を表します、方針アプリケーションなしで。 新しいPOPがオンラインで来るとき、数をGRICに送ります。(GRICは電話帳サーバにそれらを追加します)。
4.4. Phone book update
4.4. 電話帳最新版
Phone numbers in the GRIC phone book client are updated automatically upon connection. The AimTraveler server includes an address book which contains the phone numbers of all the roaming consortium members.
接続のときに自動的にGRIC電話帳クライアントの電話番号をアップデートします。 AimTravelerサーバはすべてのローミング共同体のメンバーの電話番号を含むアドレス帳を含んでいます。
4.5. Connection management
4.5. 接続管理
The AimTraveler software supports SLIP and PPP, as well as PAP and CHAP authentication.
AimTravelerソフトウェアは、SLIP、PPP、PAP、およびCHAPが認証であるとサポートします。
4.6. Authentication
4.6. 認証
GRIC implements distributed authentication, utilizing the user's e- mail address as the userID (i.e. "liu@Aimnet.com") presented to the remote NAS device.
GRIC道具は認証を広げました、リモートNASデバイスに寄贈されたuserID(すなわち、" liu@Aimnet.com ")としてユーザの電子郵便の宛先を利用して。
After the initial PPP authentication exchange, the userID, domain, and pasword information (or in the case of CHAP, the challenge and the response) are then passed by the NAS to the AimTraveler Authentication Server which supports both TACACS+ and RADIUS.
そして、初期のPPP認証交換の後に、userID、ドメイン、およびpasword情報(またはCHAPの場合、挑戦、および応答で)はNASによって両方のTACACSが+であるとサポートするAimTraveler Authentication ServerとRADIUSに渡されます。
If the authentication request comes from a regular customer login, normal user id and password authentication is performed. If the user requesting authentication is a "roamer," (has a userID with an @ and domain name), the authentication server sends an query to the closest routing server. When AimTraveler Routing Server receives the authentication request, it first authenticates the AAS sending the request, and if this is successful, it checks its authentication server table. If it is able to match the domain of the user to that of a "Home ISP", then the Home ISP authentication server's routing information are sent back to the local ISP's authentication server. Based on the information received from the routing server, the AAS makes an authentication request to the user's Home ISP AAS for user id and password verification.
認証要求が上得意ログインから来るなら、正常なユーザイドとパスワード認証は実行されます。 認証サーバは最も近いルーティングサーバに質問を送ります。認証を要求するユーザが「放浪者」であるなら(@とドメイン名があるuserIDを持っています)、AimTravelerルート設定Serverが認証要求を受け取るとき、最初に、要求を送るAASを認証して、これがうまくいくなら、それは認証サーバテーブルをチェックします。 「ホームISP」のものにユーザのドメインを合わせることができるなら、地方のISPの認証サーバはホームISP認証サーバのルーティング情報に送り返されます。ルーティングサーバから受け取られた情報に基づいて、AASはユーザイドとパスワード検証のために認証要求をユーザのホームISP AASにします。
If the user is a valid user, the Home ISP authentication server sends a "permission granted" message back to the Local ISP authentication server. The Local ISP authentication server then requests the NAS to grant the user a dynamic IP address from its address pool. If the
ユーザが正規ユーザーであるなら、ホームISP認証サーバは「与えられた許可」メッセージをLocal ISP認証サーバに送り返します。次に、Local ISP認証サーバは、動的IPアドレスをアドレスプールからユーザに与えるようNASに要求します。 the
Aboba, et. al. Informational [Page 6] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[6ページ]のRFC2194レビュー
username or password is incorrect, the Home ISP AAS will send a rejection message to the Local ISP AAS, and the user will be dropped by the NAS.
ユーザ名かパスワードが不正確です、そして、ホームISP AASは拒絶メッセージをLocal ISP AASに送るでしょう、そして、ユーザはNASによって下げられるでしょう。
If multiple routing servers are installed, and the query to the first routing server does not result in a match, the query is forwarded to the next routing server. The server queries are cached on the routing servers, improving speed for repeated queries. The cache is sustained until a routing server table entry is updated or deleted. Updating or deleting results in a message to all neighbor routing servers to delete their caches.
複数のルーティングサーバがインストールされて、最初のルーティングサーバへの質問がマッチをもたらさないなら、次のルーティングサーバに質問を送ります。サーバ質問はルーティングサーバでキャッシュされます、繰り返された質問のために速度を改良して。 キャッシュは、ルーティングサーバテーブルエントリーをアップデートするまで支えられるか、または削除されます。 それらのキャッシュを削除するためにすべての隣人ルーティングサーバにメッセージの結果をアップデートするか、または削除します。
The local authentication server also receives the accounting data from the NAS. If the data is for a regular customer login, the data is written to the Local ISP AAS log file. If the data is for a "roamer," the data is written to three places: the Local ISP AAS log file, the Home ISP AAS log file, and the ARS log file.
また、ローカルの認証サーバはNASから会計データを受け取ります。 データが上得意ログインのためのものであるなら、データはLocal ISP AASログファイルに書かれます。 データが「放浪者」のためのものであるなら、データは3つの場所まで書かれます: Local ISP AASログファイル、ホームISP AASログファイル、およびARSログはファイルされます。
If the local ISP authentication server has caching turned on, then it will cache information on Home ISP authentication server configurations sent by the routing server. This means that if the same domain is queried again, the local authentication server does not need to query the routing server again. The local cache is cleared when the local authentication server receives an update message from the routing server or system manager.
ローカルのISP認証サーバでキャッシュをつけていると、それはルーティングサーバによって送られたホームISP認証サーバ構成の情報をキャッシュするでしょう。これは、同じドメインが再び質問されるなら、ローカルの認証サーバが再びルーティングサーバについて質問する必要はないことを意味します。 ローカルの認証サーバがルーティングサーバかシステム・マネージャからアップデートメッセージを受け取るとき、ローカルなキャッシュはクリアされます。
4.7. NAS Configuration/Authorization
4.7. NAS構成/承認
AimTraveler is comprised of two components, a Client(AAS) and a Server(ARS).
AimTravelerは2つのコンポーネント、Client(AAS)、およびServer(ARS)から成ります。
The AimTraveler Client acts as the PPP dial-up authentication server. When it detects an '@' sign in the userID field, it queries the AimTraverler Server for routing information, then forwards the authentication request to user's home authentication server. The AimTraveler Server, a centralized routing server, contains the authorized ISP's domain name, authentication servers and other information.
AimTraveler ClientはPPPダイヤルアップ認証サーバとして機能します。userID分野に'@'サインを検出するとき、それは、ルーティング情報のためにAimTraverler Serverについて質問して、次に、ユーザのホーム認証サーバに認証要求を転送します。AimTraveler Server(集結されたルーティングサーバ)は認可されたISPのドメイン名、認証サーバ、および他の情報を含んでいます。
The AimTraveler currently supports RADIUS and TACACS+, and could be extended to support other authentication protocols. It also receives all the accounting records, which are subsequently used as input data for billing.
AimTravelerは現在RADIUSとTACACSが+であるとサポートして、他の認証がプロトコルであるとサポートするために広げることができました。 また、それはすべての会計帳簿を受け取ります。(会計帳簿は次に、支払いに入力データとして使用されます)。
Since ISPs' NAS devices may be configured differently, the attributes returned by the home ISP AAS are discarded.
ISPのNASデバイスが異なって構成されるかもしれないので、ホームISP AASによって返された属性は捨てられます。
Aboba, et. al. Informational [Page 7] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[7ページ]のRFC2194レビュー
4.8. Address assignment and routing
4.8. アドレス課題とルーティング
All addresses in GRIC are assigned dynamically from within the address pool of the local ISP. Static addresses and routed LAN connections will be considered in the future, when GRIC offers corporate roaming service, with the implementation of tunneling protocols
GRICのすべてのアドレスが地方のISPのアドレスプールからダイナミックに割り当てられます。 静的なアドレスと発送されたLAN接続は未来に考えられるでしょう、トンネリングプロトコルの実装で。(その時、GRICは法人のローミング・サービスを提供します)。
4.9. Security
4.9. セキュリティ
The user's password is hashed with MD5 before being sent from the Local ISP AAS to the Home ISP AAS. An encryption key is shared between the AAS and ARS. The current version of AimTraveler AAS does not support token cards or tunneling protocols.
Local ISP AASからホームISP AASに送る前にMD5と共にユーザのパスワードを論じ尽くします。 暗号化キーはAASとARSの間で共有されます。 AimTraveler AASの最新版は、トークン・カードかトンネリングがプロトコルであるとサポートしません。
4.10. Accounting
4.10. 会計
The AimTraveler Authentication Server (AAS) software can act as either a RADIUS or TACACS+ accounting server. When accounting information is received from the NAS, the local AimTraveler Authentication Server (AAS) sends accounting data (user name, domain name, login time) to both the Central Accounting Server (part of the ARS) and the user's Home ISP AimTraveler authentication server. In the case of GRIC, the Central Accounting Server is run by AimQuest.
AimTraveler Authentication Server(AAS)ソフトウェアはRADIUSかTACACS+会計サーバを機能させることができます。NASから課金情報を受け取るとき、地方のAimTraveler Authentication Server(AAS)はセントラルAccounting Server(ARSの一部)とユーザのホームISP AimTraveler認証サーバの両方に会計データ(ユーザ名、ドメイン名、ログイン時間)を送ります。GRICの場合では、セントラルAccounting ServerはAimQuestによって実行されます。
The data sent to the central accounting server and home ISP are identical except for the form of user id and time stamp. For a traveler whose home ISP is in the US, but who is traveling in Japan, the Local (Japanese) ISP AimTraveler authentication server will receive an accounting record timestamped with Japan time while the Home (US) ISP AimTraveler authentication server will receive an accounting record timestamped with the appropriate US timezone.
ユーザイドとタイムスタンプのフォームを除いて、主要な会計サーバとホームISPに送られたデータは同じです。 ホームISPが米国にありますが、日本を旅行している旅行者に関しては、ホーム(米国)ISP AimTraveler認証サーバが適切な米国タイムゾーンでtimestampedされる会計帳簿を受け取る間、Localの(日本)のISP AimTraveler認証サーバは日本時間でtimestampedされる会計帳簿を受け取るでしょう。
The accounting data includes 2 new attributes for settlement reporting:
会計データは解決報告のための2つの新しい属性を含んでいます:
Attribute Number Type
--------- ------ ----
属性数のタイプ--------- ------ ----
Roaming-Server-ID 101 string
Isp-ID 102 string
ローミングServer ID101はIsp-ID102ストリングを結びます。
The Roaming-Server-ID attribute identifies the AAS sending the authentication request. The Isp-ID attribute identifies the local ISP. Using this information the home ISP can track the roaming activities of its users (where their users are logging in).
Roaming Server ID属性は認証要求を送るAASを特定します。 Isp-ID属性は地方のISPを特定します。 この情報を使用して、ホームISPはユーザ(彼らのユーザがログインしているところ)のローミング活動を追跡できます。
Aboba, et. al. Informational [Page 8] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[8ページ]のRFC2194レビュー
The AimTraveler Server running at AimQuest keeps a record of all roaming transactions, which are used as input to the settlement and billing process. At the end of each month, AimQuest provides a roaming transaction summary to GRIC members using AIMS. The AIMS software is configurable so that it takes into account the settlement rules agreed to by GRIC members.
AimQuestで稼働するAimTraveler Serverはすべてのローミングトランザクションに関する記録をつけます。(トランザクションは解決と課金プロセスに入力されるように使用されています)。 各月の末には、AimQuestは、AIMSを使用することでローミングトランザクション概要をGRICメンバーに提供します。AIMSソフトウェアが構成可能であるので、それはGRICメンバーで、規則が同意した解決を考慮に入れます。
5. i-Pass implementation
5. i-パス実装
5.1. Overview
5.1. 概要
i-Pass Alliance Inc., based in Mountain View, California, has developed and operates a commercial authentication and settlement clearinghouse service which provides global roaming between Internet service providers. The service is fully operational.
マウンテンビュー(カリフォルニア)でベースであるi-パスAlliance Inc.は、展開して、インターネット接続サービス業者の間に国際ローミングを提供する商業認証と解決情報センターサービスを運用します。 サービスは完全に操作上です。
i-Pass Alliance Inc. has additional offices in Toronto, Singapore, and London. More information on i-Pass can be obtained from http://www.ipass.com.
i-パスAlliance Inc.には、トロント、シンガポール、およびロンドンの追加オフィスがあります。 http://www.ipass.com からi-パスに関する詳しい情報を得ることができます。
The i-Pass network consists of a number of servers that provide real-time authentication services to partner ISPs. Authentication requests and accounting records for roaming users are encrypted and sent to an i-Pass serverwhere they are logged, and then forwarded to a home ISP for authentication and/or logging.
i-パスネットワークはパートナーISPへのリアルタイムの認証サービスを提供する多くのサーバから成ります。 ローミングユーザへの認証要求と会計帳簿が暗号化されていて、i-パスserverwhereに送って、認証、そして/または、伐採のためにホームISPに彼らを登録して、次に、送ります。
Periodically, i-Pass reconciles all accounting records, generates billing statements, and acts as a single point for collecting and remitting payments.
i-パスは、定期的に、すべての会計帳簿を和解させて、請求書を作って、支払いを集めて、送金するための1ポイントとして作動します。
i-Pass provides its service only to ISPs and channel partners. It does not attempt to establish a business relationship with individual-user customers of an ISP.
i-パスはISPとチャンネルパートナーだけに対するサービスを提供します。 それは、ISPの個々のユーザ顧客との取引関係を確立するのを試みません。
5.2. Access Point Database (APD)
5.2. アクセスポイントデータベース(APD)
i-Pass maintains a list of roaming access points in an Oracle database. This list is searchable by geographical region using a Web browser, and may be downloaded in its entirety using FTP. The information stored for each access point includes:
i-パスはオラクルデータベースのローミングアクセスポイントのリストを維持します。 このリストを地理的な領域のそばでウェブブラウザを使用することで探せて、FTPを使用することで全体としてダウンロードするかもしれません。 各アクセスポイントとして保存された情報は:
Name of service provider
Country
State or Province
City or Region
Telephone number
Technical support phone number
Service types available
サービスプロバイダーCountry州、Province市または手があいているRegion Telephoneの数のTechnicalサポート電話番号Serviceタイプの名前
Aboba, et. al. Informational [Page 9] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[9ページ]のRFC2194レビュー
Technical information (help file)
Service pricing information
情報に値を付ける技術資料(ヘルプファイル)サービス
The Access Point Database is maintained by i-Pass staff, based on input from i-Pass partners.
Access Point Databaseはi-パスパートナーからの入力に基づいてi-パススタッフによって維持されます。
5.3. Phone number presentation
5.3. 電話番号プレゼンテーション
ni-Pass has developed a Windows application wth a simple point and click interface called the "i-Pass Dial Wizard", which assists end- users in selecting and connecting to a local Internet access point.
「i-パスダイヤルウィザード」(地方のインターネットアクセスポイントに選択して、接続するのに終わりのユーザを助ける)と呼ばれて、Niパスは簡単なポイントとクリックが連結するウィンドウズのアプリケーションwthを開発しました。
The Dial Wizard allows users to first select the country in which they are roaming. A list of states, provinces, or other regions in the selected country is then presented. Finally a list of access points within the state or province is presented. The Dial Wizard displays the city name, modem phone number, and price information for each access point within the state or region.
Dial Wizardはユーザに最初に、彼らが移動している国を選択させます。 そして、選択された国の州、州、または他の領域のリストは提示されます。 最終的に州か州の中のアクセスポイントのリストは提示されます。 Dial Wizardは州か領域の中の各アクセスポイントのための都市の名、モデム電話番号、および価格情報を表示します。
When the user selects the desired access point, a Windows 95 "DialUp Networking" icon is created for that access point. If there is a login script associated with the access point, the DialUp Scripting tool is automatically configured. This means that end-users never have to configure any login scripting requirements.
ユーザが必要なアクセスポイントを選択するとき、Windows95「ダイアルアップネットワーク」アイコンはそのアクセスポイントに作成されます。 アクセスポイントに関連しているログインスクリプトがあれば、DialUp Scriptingツールは自動的に構成されます。 これは、エンドユーザが要件に原稿を書くどんなログインも決して構成する必要はないことを意味します。
The Dial Wizard has a built-in phonebook containing all the i-Pass access points. The phonebook may be automatically refreshed from a master copy located onISPs web site.
Dial Wizardには、すべてのi-パスアクセスポイントを含む内蔵のphonebookがあります。 phonebookはマスターのコピーの見つけられたonISPsウェブサイトから自動的にリフレッシュされるかもしれません。
The Dial Wizard is provided free of charge to i-Pass partners. i- Pass also provides the i-Pass Dial Wizard Customization Kit which allows ISP partners to generate customized versions of the Dial Wizard with their own logo, etc.
無料でi-パスパートナーにDial Wizardを提供します。また、iパスはISPパートナーにそれら自身のロゴなどでDial Wizardのカスタム設計されたバージョンを生成させるi-パスDial Wizard Customization Kitを提供します。
5.4. Authentication
5.4. 認証
There are three entities involved in servicing an authentication request:
認証要求を修理するのにかかわる3つの実体があります:
Local ISP At the local ISP, the authentication server is modified to
recognize user IDs of the form username@auth_domain as being
remote authentication requests. These requests are forwarded
to an i-Pass server.
地方のISP Atの地方のISP、認証サーバは、リモート認証要求であるとしてフォーム username@auth_domain のユーザIDを認識するように変更されます。 i-パスサーバにこれらの要求を転送します。
Aboba, et. al. Informational [Page 10] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[10ページ]のRFC2194レビュー
i-Pass Server
The i-Pass server receives the authentication request, logs
it, and forwards it to the home ISP identified by the
auth_domain portion of the user ID.
iで通っているサーバをServerにiで通過してください。ユーザIDのauth_ドメイン部分によって特定されたホームISPに、認証要求を受け取って、それを登録して、それを送ります。
Home ISP The home ISP receives the authentication request, performs
authentication using its normal authentication method, and
returns a YES/NO response to the i-Pass server, which in turn
forwards the reply to the originating ISP.
ホームISP、ホームISPは、認証要求を受け取って、正常な認証方法を使用することで認証を実行して、i-パスサーバへの応答を全くaはい/に返しません。(順番に、サーバは起因するISPに回答を送ります)。
i-Pass provides software components which run on the authentication servers of the local and home ISPs. Each member ISP must integrate these components with the native authentication method being used by the ISP. To simplify this task, i-Pass has developed "drop-in" interfaces for the most commonly used authentication methods. At the date of writing, the following interfaces are supported:
i-パスは地方とホームISPの認証サーバで動くソフトウェアコンポーネントを提供します。 それぞれのメンバーISPはISPによって使用される固有の認証方法とこれらのコンポーネントを統合しなければなりません。 このタスクを簡素化するために、i-パスは最も一般的に使用された認証方法のために「中に低下する」インタフェースを開発しました。 書くことの日付に、以下のインタフェースはサポートされます:
Livingston RADIUS
Ascend RADIUS
Merit RADIUS
TACACS+
Xylogics erpcd (Versions 10 and 11)
リビングストンRADIUS Ascend RADIUS Merit RADIUS TACACS+Xylogics erpcd(バージョン10と11)
A generic interface is also provided which authenticates based on the standard UNIX password file. This is intended as a starting point for ISPs using authentication methods other than those listed above.
また、標準のUNIXに基づいてパスワードファイルを認証するジェネリックインタフェースを提供します。 それら以外の認証方法を使用するISPのための出発点が上に記載したようにこれは意図します。
The software integration effort for a typical ISP is on the order of 2-5 man-days including testing. Platforms currently supported include:
2-5 テストするのを含む人日の注文には典型的なISPのためのソフトウェア統合取り組みがあります。 現在サポートされているプラットホームは:
Solaris 2.5 (Sparc).LI
Solaris 2.5 (Intel)
BSDI
Digital Unix
Linux
FreeBSD
HP/UX
Solaris2.5(Sparc).LI Solaris2.5(インテル)のBSDIのデジタルunixリナックス無料OSの一つhp/UX
ISPs may chooe to provide authentication for their end-users roaming elsewhere, but not to provide access points to the i-Pass network. In this case the software integration effort is greatly reduced and can be as little as 1/2 a man-day.
ISPは、i-パスネットワークにアクセスポイントを提供するのではなく、ほかの場所を歩き回っている彼らのエンドユーザに認証を提供するためにchooeされるかもしれません。 この場合、ソフトウェア統合取り組みは、大いに減少して、1人日あたり最小1/2であるかもしれません。
5.5. Accounting
5.5. 会計
Accounting transactions are handled in the same way as authentication requests. In addition to being logged at the i-Pass servers,
同様に、認証が要求するように会計トランザクションは扱われます。 i-パスサーバで登録されることに加えて
Aboba, et. al. Informational [Page 11] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[11ページ]のRFC2194レビュー
accounting transactions are sent in real-time to the home ISP. This is intended to allow ISPs to update users' credit limit information on a real-time basis (to the extent that this capability is supported by their billing and accounting systems).
会計トランザクションはホームISPにリアルタイムで状態で送られます。 これが、ISPがリアルタイムベース(この能力がそれらの支払いと会計システムによってサポートされるという範囲への)のユーザの掛貸限度額情報をアップデートするのを許容することを意図します。
Settlement is performed monthly. The settlement process involves calculating the costs associated with each individual session, and aggregating them for each ISP. A net amount is then calculated which is either due from i-Pass to the ISP, or from the ISP to i-Pass, depending on the actual usage pattern.
解決は毎月実行されます。 解決プロセスは、コストを計算して、それぞれの個々のセッションに関連している各ISPのためにそれらに集めることを伴います。 次に、ネットの量は計算されます(i-パスからISP、またはISPからi-パスまで当然です)、実際の用法パターンによって。
The following reports are supplied to member ISPs:
以下のレポートをメンバーISPに提供します:
A Monthly Statement showing summaries of usage, service provided,
and any adjustments along with the net amount owing.
ネットの量の負うと共に用法、提供されたサービス、およびどんな調整の概要も示しているMonthly Statement。
A Call Detail Report showing roaming usage by the ISP's customers.
ISPの顧客で用法に移動しながら目立つCall Detail Report。
A Service Provided report showing detailed usage of the ISP's
facilities by remote users.
Service Providedレポート表示はリモート・ユーザーでISPの施設の使用法を詳しく述べました。
The above reports are generated as ASCII documents and are distributed to i-Pass partners electronically, either by e-mail or from a secure area on the i-Pass web site. Hard-copy output is available on request.
上記のレポートは、ASCIIが記録するように発生していて、メール、または、i-パスウェブサイトの安全な領域からi-パスパートナーに電子的に配布されます。 ハードコピー出力は要求に応じて利用可能です。
The Call Detail Report is also generated as a comma-delimited ASCII file suitable for import into the ISP's billing database. The Call Detail Report will normally be used by the ISP to generate end-user billing for roaming usage.
また、Call Detail Reportは輸入に適したコンマで区切られたASCIIファイルとしてISPの支払いデータベースに生成されます。 通常、Call Detail ReportはISPによって使用されて、ローミング用法のためにエンドユーザ支払いを生成するでしょう。
5.6. Security
5.6. セキュリティ
All transactions between ISPs and the i-Pass servers are encrypted using the SSL protocol. Public key certificates are verified at both the client and server. i-Pass issues these certificates and acts as the Cetificate Authority.
ISPとi-パスサーバの間のすべてのトランザクションが、SSLプロトコルを使用することで暗号化されています。 公開鍵証明書は. i-パスがこれらの証明書を発行するクライアントとサーバと行為の両方でCetificate Authorityが確かめられます。
Transactions are also verified based on a number of other criteria such as source IP address.
また、トランザクションはソースIPアドレスなどの他の多くの評価基準に基づいて確かめられます。
5.7. Operations
5.7. 操作
i-Pass operates several authentication server sites. Each site consists of two redundant server systems located in secure facilities and "close" to the Internet backbone. The authentication server sites are geographically distributed to minimize the possibility of failure due to natural disasters etc.
i-パスはいくつかの認証サーバサイトを操作します。 各サイトは「近いところに安全な施設とインターネットの基幹の」位置した2台の余分なサーバシステムから成ります。 認証サーバサイトは、天災などのため失敗の可能性を最小にするために地理的に配布されます。
Aboba, et. al. Informational [Page 12] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[12ページ]のRFC2194レビュー
i-Pass maintains a Network Operations Center in Mountain View which is staffed on a 7x24 basis. Its functions include monitoring the i- Pass authentication servers, monitoring authentication servers located at partner facilities, and dealing with problem reports.
i-パスは7×24ベースに配置されるマウンテンビューでネットワーク運営センターを維持します。 機能は、iパス認証サーバをモニターするのを含んでいます、パートナー施設に位置する認証サーバをモニターして、問題報告書に対処して。
6. ChinaNet implementation
6. ChinaNet実装
ChinaNet, owned by China Telecom, is China's largest Internet backbone. Constructed by Asiainfo, a Dallas based system integration company, it has 31 backbone nodes in 31 Chinese provincial capital cities. Each province is building its own provincial network, has its own dialup servers, and administers its own user base.
中国テレコムによって所有されていたChinaNetは中国の最も大きいインターネットの基幹です。 Asiainfo、ダラスのベースのシステムインテグレーション会社によって組み立てられて、それは31の中国の地方の中心都市都市に31のバックボーンノードを持っています。 各州は、それ自身の地方のネットワークを造っていて、それ自身のダイアルアップサーバを持って、それ自身のユーザベースを管理します。
In order to allow hinaNet users to be able to access nodes outside their province while traveling, a nationwide roaming system has been implemented. The roaming system was developed by AsiaInfo, and is based on the RADIUS protocol.
hinaNetユーザが旅行している間、それらの州の外でノードにアクセスできるのを許容するために、全国的なローミングシステムは導入されました。 ローミングシステムは、AsiaInfoによって開発されて、RADIUSプロトコルに基づいています。
6.1. Phone number presentation
6.1. 電話番号プレゼンテーション
Since China Telecom uses one phone number (163) for nationwide Internet access, most cities have the same Internet access number. Therefore a phone book is not currently required for the ChinaNet implementation. A web-based phone book will be added in a future software release in order to support nationwide ISP/CSP telephone numbers and HTTP server addresses.
中国テレコムが全国的なインターネット・アクセスに1つの電話番号(163)を使用するので、ほとんどの都市には、同じインターネット・アクセス番号があります。 したがって、電話帳は現在、ChinaNet実装に必要ではありません。 ウェブベースの電話帳は、全国的なISP/CSP電話番号とHTTPがサーバアドレスであるとサポートするために今後のソフトウェアリリースで加えられるでしょう。
6.2. Connection management
6.2. 接続管理
The current roaming client and server supports both PPP and SLIP.
クライアントとサーバに移動する電流はPPPとSLIPの両方をサポートします。
6.3. Address assignment and routing
6.3. アドレス課題とルーティング
ChinaNet only supports dynamic IP address assignment for roaming users. In addition, static addresses are supported for users authenticating within their home province.
ChinaNetは、ローミングユーザのために動的IPアドレスが課題であるとサポートするだけです。 さらに、静的なアドレスは彼らの故郷の中で認証するユーザのためにサポートされます。
6.4. Authentication
6.4. 認証
When user accesses a local NAS, it provides its userID either as "username" or "username@realm". The NAS will pass the userID and password to the RADIUS proxy/server. If the "username" notation is used, the Radius proxy/server will assume that the user is a local user and will handle local authentication accordingly. If "user- name@realm" is used, the RADIUS proxy/server will process it as a roaming request.
ユーザが地方のNASにアクセスするとき、それは「ユーザ名」か" username@realm "としてuserIDを提供します。 NASはRADIUSプロキシ/サーバにuserIDとパスワードを渡すでしょう。「ユーザ名」記法が使用されていると、Radiusプロキシ/サーバは、ユーザが地元のユーザであり、それに従って、地方の認証を扱うと仮定するでしょう。 「ユーザ name@realm 」が使用されていると、RADIUSプロキシ/サーバはローミング要求としてそれを処理するでしょう。
Aboba, et. al. Informational [Page 13] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[13ページ]のRFC2194レビュー
When the RADIUS proxy/server handles a request from a roaming user, it will first check the cache to see if the user information is already stored there. If there is a cache hit, the RADIUS proxy/server do the local authentication accordingly. If it does not find user information in its cache, it will act as a proxy, forwarding the authentication request to the home RADIUS server. When the home RADIUS server responds, the local server will forward the response to the NAS. If the user is authenticated by the home server, the local RADIUS proxy will cache the user information for a period of time (3 days by default).
RADIUSプロキシ/サーバがローミングユーザからの要求を扱うとき、それは、最初に、ユーザー情報がそこに既に保存されるかどうか確認するためにキャッシュをチェックするでしょう。 キャッシュがあれば、ヒット、RADIUSプロキシ/サーバはそれに従って、地方の認証をします。 キャッシュにおけるユーザー情報を見つけないと、プロキシとして務めるでしょう、ホームRADIUSサーバに認証要求を転送して。ホームRADIUSサーバが反応するとき、ローカルサーバはNASへの応答を進めるでしょう。 ユーザがホームサーバによって認証されると、地元のRADIUSプロキシがしばらくユーザー情報をキャッシュする、(3日間、デフォルトで)
Caching is used to avoid frequent proxying of requests and responses between the local RADIUS proxy and the home RADIUS server. When the home RADIUS server sends back a valid authentication response, the local RADIUS proxy/server will cache the user information for a period of time (3 days by default). When the user next authenticates directly against the home RADIUS server, the home RADIUS server will send a request to the local server or servers to clear the user's information from the cache.
キャッシュは、地元のRADIUSプロキシとホームRADIUSサーバの間の要求と応答の頻繁なproxyingを避けるのに使用されます。ホームRADIUSサーバが有効な認証応答を返送すると、ローカルのRADIUSプロキシ/サーバがしばらくユーザー情報をキャッシュする、(3日間、デフォルトで) 次のユーザが直接ホームに対してサーバ、ホームRADIUSサーバが認証するRADIUSを認証するときにはローカルサーバかサーバに要求を送って、キャッシュからのユーザの情報をクリアしてください。
6.4.1. Extended hierarchy
6.4.1. 拡張階層構造
In some provinces, the local telecommunications administration Provincial ISP) further delegates control to county access nodes, creating another level of hierarchy. This is done to improve scalability and to avoid having the provincial ISP databases grow too large. In the current implementation, each provincial ISP maintains its own central RADIUS server, including information on all users in the province, while county nodes maintain distributed RADIUS servers. For intra-province roaming requests the local RADIUS proxy/server will directly forward the request to the home RADIUS server.
いくつかの州では、地方のテレコミュニケーション管理Provincial ISP) 一層の代表がカウンティーのアクセスノードに制御します、別のレベルの階層構造を作成して。 スケーラビリティを改良して、地方のISPデータベースが大きくし過ぎるのを避けるためにこれをします。 現在の実装では、それぞれの地方のISPはそれ自身の主要なRADIUSサーバを維持します、州のすべてのユーザの情報を含んでいて、カウンティーのノードが分配されたRADIUSサーバを維持しますが。 イントラ州ローミング要求のために、ローカルのRADIUSプロキシ/サーバは直接ホームRADIUSサーバに要求を転送するでしょう。
However, for inter-province roaming requests, the local RADIUS server does not forward the request directly to the home RADIUS server. Instead, the request is forwarded to the central provincial RADIUS server for the home province. This implementation is suitable only when county level ISPs do not mind combining and sharing their user information. In this instance, this is acceptable, since all county level ISPs are part of China Telecom. In a future release, this multi-layer hierarchy will be implemented using multi-layer proxy RADIUS, in a manner more resembling DNS.
しかしながら、相互州ローミング要求のために、ローカルのRADIUSサーバは直接ホームRADIUSサーバに要求を転送しません。代わりに、故郷のために主要な地方のRADIUSサーバに要求を転送します。 カウンティーのレベルISPがそれらのユーザー情報を結合して、共有するのを気にしないときだけ、この実装は適当です。 この場合、これは、すべてのカウンティーのレベルISPが中国テレコムの一部であるので、許容できます。 今後のリリースでは、このマルチ層の階層構造は、DNSに類似しながら、方法でマルチ層のプロキシRADIUSをさらに使用することで実装されるでしょう。
6.5. Security
6.5. セキュリティ
Encryption is used between the local RADIUS proxy/server and the home RADIUS server. Public/Private key encryption will be supported in the next release. IP tunneling and token card support is under consideration.
暗号化はローカルのRADIUSプロキシ/サーバとホームRADIUSサーバの間で使用されます。公衆/秘密鍵暗号化は次のリリースでサポートされるでしょう。 IPトンネリングとトークン・カードサポートは考慮中であります。
Aboba, et. al. Informational [Page 14] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[14ページ]のRFC2194レビュー
6.6. Accounting
6.6. 会計
Accounting information is transferred between the local RADIUS accounting proxy/server and home RADIUS accounting server. Every day each node sends a summary accounting information record to a central server in order to support nationwide settlement. The central server is run by the central Data Communication Bureau of China Telecom. Every month the central server sends the settlement bill to the provincial ISPs.
ローカルのRADIUS会計プロキシ/サーバとホームRADIUS会計サーバの間に課金情報を移します。毎日、各ノードは、全国的な解決をサポートするために概要課金情報記録をセントラルサーバーに送ります。 セントラルサーバーは中国テレコムの中央のData通信局によって実行されます。 毎月、セントラルサーバーは解決請求書を地方のISPに送ります。
6.7. Inter-ISP/CSP roaming
6.7. 相互ISP/CSPローミング
ChinaNet supports both ISP and CSP (Content Service Provider) roaming on its system. For example, Shanghai Online, a Web-based commercial content service, uses RADIUS for authentication of ChinaNet users who do not have a Shanghai Online account. In order to support this, the Shanghai Online servers function as a RADIUS client authenticating against the home RADIUS server. When users access a protected document on the HTTP server, they are prompted to send a username/password for authentication. The user then responds with their userID in "user-name@realm" notation.
ChinaNetは、システムの上を移動しながら、ISPとCSPの両方(内容Service Provider)をサポートします。 例えば、上海Online(ウェブベースの商業コンテンツサービス)は上海Onlineアカウントを持っていないChinaNetユーザの認証にRADIUSを使用します。 これをサポートするために、上海OnlineサーバはホームRADIUSサーバに対して認証するRADIUSクライアントとして機能します。ユーザがHTTPサーバの保護されたドキュメントにアクセスするとき、彼らが認証のためのユーザ名/パスワードを送るようにうながされます。 そして、ユーザはそれらのuserIDと共に" user-name@realm "記法で応じます。
A CGI script on the HTTP server then acts as a RADIUS authentication client, sending the request to the home RADIUS server. After the home RADIUS server responds, the CGI script passes the information to the local authentication agent. From this point forward, everything is taken care of by the local Web authentication mechanism.
次に、HTTPサーバに関するCGIスクリプトはRADIUS認証クライアントとして機能します、ホームRADIUSサーバに要求を送って。ホームRADIUSサーバが反応した後にCGIスクリプトは地元の認証エージェントに情報を渡します。 このポイントフォワードから、すべてがローカルのウェブ認証機構によって世話をされます。
7. Microsoft implementation
7. マイクロソフト実装
Microsoft's roaming implementation was originally developed in order to support the Microsoft Network (MSN), which now offers Internet access in seven countries: US, Canada, France, Germany, UK, Japan, and Australia. In each of these countries, service is offered in cooperation with access partners. Since users are able to connect to the access partner networks while maintaining a customer-vendor relationship with MSN, this implementation fits within the definition of roaming as used in this document.
マイクロソフトのローミング実装は元々、現在7つの国でインターネット・アクセスを提供するマイクロソフトネットワーク(MSN)をサポートするために開発されました: 米国、カナダ、フランス、ドイツ、イギリス、日本、およびオーストラリア。 それぞれのこれらの国では、アクセスパートナーと提携してサービスを提供します。 ユーザがMSNとの顧客ベンダー関係を維持している間、アクセスパートナーネットワークに接続できるので、この実装は本書では使用されるように移動する定義の中で合います。
7.1. Implementation overview
7.1. 実装概要
The first version of the Microsoft roaming software was deployed by the MSN partners in April, 1996. This version included a Phone Book manager tool running under Windows 95, as well as a RADIUS server/proxy implementation running under Windows NT; TACACS+ is
マイクロソフトがソフトウェアに移動する最初のバージョンは1996年4月にMSNパートナーによって配布されました。 このバージョンはWindows95で実行される電話Bookマネージャツールを含んでいました、Windows NTで実行されるRADIUSサーバ/プロキシ実装と同様に。 TACACS+はそうです。
Aboba, et. al. Informational [Page 15] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[15ページ]のRFC2194レビュー
currently not supported. Additional components now under development include a Connection Manager client for Windows 95 as well as an HTTP-based phone book server for Windows NT. The Phone Book manager tool is also being upgraded to provide for more automated phone book compilation.
現在、サポートされません。 現在開発中の追加コンポーネントはWindows NTのためのHTTPベースの電話帳サーバと同様にWindows95のためのConnectionマネージャのクライアントを含んでいます。 また、電話Bookマネージャツールは、より自動化された電話帳編集に備えるためにアップグレードしています。
7.2. Phone number presentation
7.2. 電話番号プレゼンテーション
The Connection Manager is responsible for the presentation and updating of phone numbers, as well as for dialing and making connections. In order to select phone numbers, users are asked to select the desired country and region/state. Phone numbers are then presented in the area selected. The primary numbers are those from the users service provider which match the service type (Analog, ISDN, Analog & IDN), country and region/state selected. The other numbers (selected clicking on the More button) are those for other service providers that have a roaming agreement with the users service provider.
Connectionマネージャは接続に電話番号のプレゼンテーションとアップデートと、ダイヤルして、作るのに責任があります。 電話番号を選択するために、ユーザが必要な国と領域/状態を選択するように頼まれます。 そして、電話番号は選択された領域に提示されます。 プライマリ数はユーザサービスプロバイダーからのタイプ(アナログ、ISDN、Analog、およびIDN)、国、および領域/州が選択したサービスに合っているものです。 他の数(Moreボタンをクリックしながら、選択される)はユーザサービスプロバイダーとのローミング協定を持っている他のサービスプロバイダーのためのそれらです。
7.2.1. Cost data
7.2.1. 原価資料
Cost data is not presented to users along with the phone numbers. However, such information may be made available by other means, such as via a Web page.
原価資料は電話番号に伴うユーザに提示されません。 しかしながら、ウェブページを通したなど他の手段でそのような情報を利用可能にするかもしれません。
7.2.2. Default phone book format
7.2.2. デフォルト電話帳形式
The Connection Manager supports the ability to customize the phone book format, and it is expected that many ISPs will make use of this capability. However, for those who wish to use it "off the shelf" a default phone book format is provided. The default phone book is comprised of several files, including:
Connectionマネージャは電話帳形式をカスタム設計する能力をサポートします、そして、多くのISPがこの能力を利用すると予想されます。 しかしながら、それが「すぐ入手できること」を使用に願っている人にとって、デフォルト電話帳形式を提供します。 デフォルト電話帳はいくつかのファイル、包含から成ります:
Service profile
Phone Book
Region file
サービスプロフィール電話Book Regionファイル
The service profile provides information on a given service, which may be an isolated Internet Service Provider, or may represent a roaming consortium. The service profile, which is in .ini file format, is comprised of the following information:
サービスプロフィールは与えられたサービスの情報を提供します。(孤立しているインターネットサービスプロバイダであるかもしれない、またはサービスはローミング共同体を代表するかもしれません)。 サービスプロフィール(.iniファイル形式にはある)は以下の情報から成ります:
The name of the service
The filename of the service's big icon
The filename of the service's little icon
A description of the service
The service phone book filename
名前、サービスの大きいアイコンのファイル名を修理してください、サービスの少ないサービスのアイコンA記述のファイル名、サービス電話帳ファイル名
Aboba, et. al. Informational [Page 16] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[16ページ]のRFC2194レビュー
The service phone book version number
The service regions file
The URL of the service phone book server
The prefix used by the service (i.e. "MSN/aboba")
The suffix or domain used by the service (i.e. "aboba@msn.com")
Whether the user name is optional for the service
Whether the password is optional for the service
Maximum length of the user name for the service
Maximum length of the password for the service
Information on service password handling (lowercase, mixed case, etc.)
Number of redials for this service
Delay between redials for this service
References to other service providers that have roaming agreements
The service profile filenames for each of the references
Mask and match phone book filters for each of the references
(these are 32 bit numbers that are applied against the capability
flags in the phone book)
The dial-up connection properties configuration
(this is the DUN connectoid name)
サービス電話帳バージョン番号、サービスに、ユーザ名のサービスの最大の長さに、パスワードがサービスパスワード取り扱い(小文字の、そして、複雑なケースなど)に関するサービス情報のためのパスワードのサービスの最大の長さのために任意であるか否かに関係なく、ユーザ名が任意であるか否かに関係なく、サービス領域はサービス(すなわち、" aboba@msn.com ")で接尾語かドメインが利用したサービス(すなわち、"MSN/aboba")で接頭語が使用したサービス電話帳サーバのURLをファイルします。 それぞれの参照Maskとマッチ電話帳のためのサービスプロフィールファイル名がそれぞれの参照(これらは電話帳の能力旗に対して適用される32ビットの数である)のためにダイアルアップ接続特性の構成をフィルターにかけるというローミング協定を持っている他のサービスプロバイダーへのこのサービスReferencesのためのリダイヤルの間のこのサービスDelayのためのリダイヤルの数(これはDUN connectoid名です)
The phone book file is a comma delimited ASCII file containing the following data:
電話帳ファイルは以下のデータを含むコンマの区切られたASCIIファイルです:
Unique number identifying a particular record (Index)
Country ID
A zero-base index into the region file
City
Area code
Local phone number
Minimum Speed
Maximum speed
Capability Flags:
Bit 0: 0=Toll, 1=Toll free
Bit 1: 0=X25, 1=IP
Bit 2: 0=Analog, 1=No analog support
Bit 3: 0=no ISDN support, 1=ISDN
Bit 4: 0
Bit 5: 0
Bit 6: 0=No Internet access, 1=Internet access
Bit 7: 0=No signup access, 1=Signup access
Bit 8-31: reserved
The filename of the dialup network file
(typically refers to a script associated with the number)
特定の記録的な(インデックス)国のID Aゼロベースインデックスを領域に特定するユニークな数が市のAreaコードLocal電話番号Minimum Speed Maximum速度Capability Flagsをファイルします: ビット0: 0 = 鳴ってください、そして、1はフリーダイヤルBit1と等しいです: 0=X25、1はIPビット2と等しいです: 0はアナログと等しく、1はどんなアナログのサポートBitとも3等しくはありません: 1=ISDN Bit4、0はどんなISDNサポートとも等しくはありません: 0ビット5: 0ビット6: 1=インターネット・アクセスBit7、0はどんなインターネット・アクセスとも等しくはありません: 1=SignupアクセスBit8-31、0はどんなsignupアクセスとも等しくはありません: 予約されて、ダイアルアップネットワークのファイル名はファイルされます。(数に関連しているスクリプトを通常参照します)
Aboba, et. al. Informational [Page 17] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[17ページ]のRFC2194レビュー
A sample phone book file is shown below:
サンプル電話帳ファイルは以下で見せられます:
65031,1,1,Aniston,205,5551212,2400,2400,1,0,myfile
200255,1,1,Auburn/Opelika,334,5551212,9600,28800,0,10,
200133,1,1,Birmingham,205,5551212,9600,28800,0,10,
130,1,1,Birmingham,205,3275411,9600,14400,9,0,yourfile
65034,1,1,Birmingham,205,3285719,9600,14400,1,0,myfile
65031 1、1、アニストン、205、5551212、2400、2400、1、0、myfile200255、1、1、赤褐色/Opelika、334、5551212、9600、28800、0、10、200133、1、1、バーミンガム、205、5551212、9600、28800、0、10、130、1、1、バーミンガム、205、3275411、9600、14400、9、0、yourfile65034、1、1、バーミンガム、205、3285719、9600、14400、1、0、myfile
7.2.3. Additional attributes
7.2.3. 追加属性
As described previously, it is likely that some ISPs will require additional phone number attributes or provider information beyond that supported in the default phone book format. Attributes of interest may vary between providers, or may arise as a result of the introduction of new technologies. As a result, the set of phone number attributes is likely to evolve over time, and extensibility in the phone book format is highly desirable.
以前に説明されるように、いくつかのISPがデフォルト電話帳形式でサポートされたそれを超えて追加電話番号属性かプロバイダー情報を必要としそうでしょう。 興味がある属性は、プロバイダーの間で異なるか、または新技術の導入の結果、起こるかもしれません。 その結果、電話番号属性のセットは時間がたつにつれて発展しそうです、そして、電話帳形式の伸展性は非常に望ましいです。
For example, in addition to the attributes provided in the default phone book, the following additional attributes have been requested by customers:
例えば、デフォルト電話帳に提供された属性に加えて、以下の追加属性は顧客が要求されています:
Multicast support flag
External/internal flag (to differentiate display between the
"internal" or "other" list box)
Priority (for control of presentation order)
Modem protocol capabilities (V.34, V.32bis, etc.)
ISDN protocol capabilities (V.110, V.120, etc.)
No password flag (for numbers using telephone-based billing)
Provider name
マルチキャストのサポート旗のExternal/内部の旗(「内部」の、または、「他」のリスト箱の間のディスプレイを差別化する)の優先権(プレゼンテーション命令のコントロールのための)モデムプロトコル能力(V.34、V.32bisなど) ISDNプロトコル能力(V.110、V.120など) パスワード旗(電話ベースの支払いを使用する数のための)のプロバイダー名がありません。
7.2.4. Addition of information on providers
7.2.4. プロバイダーの情報の追加
The default phone book does not provide a mechanism for display of information on the individual ISPs within the roaming consortium, only for the consortium as a whole. For example, the provider icons (big and little) are included in the service profile. The service description information is expected to contain the customer support number. However, this information cannot be provided on an individual basis for each of the members of a roaming consortium. Additional information useful on a per-provider basis would include:
デフォルト電話帳はローミング共同体の中で個々のISPでメカニズムを情報表示に提供しません、全体で共同体のためだけに。 例えば、プロバイダーアイコン(大きくて小さい)はサービスプロフィールに含まれています。 サービス記述情報が顧客サポート番号を含むと予想されます。 しかしながら、個別的にローミング共同体のメンバー各人にこの情報を提供できません。 1プロバイダーあたり1個のベースで役に立つ追加情報は以下を含んでいるでしょう。
Provider voice phone number
Provider icon
Provider fax phone number
Provider customer support phone number
プロバイダー声の電話番号ProviderアイコンProviderファックス電話番号Provider顧客サポート電話番号
Aboba, et. al. Informational [Page 18] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[18ページ]のRFC2194レビュー
7.3. Phone number exchange
7.3. 電話番号交換
Currently phone number exchange is not supported by the phone book server. As a result, in the MSN implementation, phone number exchange is handled manually. As new POPs come online, the numbers are forwarded to MSN, which tests the numbers and approves them for addition to the phone book server. Updated phone books are produced and loaded on the phone book server on a weekly basis.
現在の、電話番号交換は電話帳サーバで後押しされていません。その結果、MSN実装では、電話番号交換は手動で扱われます。 新しいPOPがオンラインで来るとき、数をMSNに送ります。(MSNは電話帳サーバに数をテストして、追加のためにそれらを承認します)。電話帳サーバで毎週ベースでアップデートされた電話帳を製作して、ロードします。
7.4. Phone book compilation
7.4. 電話帳編集
The Phone Book Manager tool was created in order to make it easier for the access partners to create and update their phone books. It supports addition, removal, and editing of phone numbers, generating both a new phone book, as well as associated difference files.
電話Bookマネージャツールは、アクセスパートナーが彼らの電話帳を作成して、アップデートするのをより簡単にするように作成されました。 それは電話番号の追加、取り外し、および編集をサポートします、両方が新しい電話帳であると生成して、関連違いのファイルと同様に。
With version 1 of the Phone Book Administration tool, phone books are compiled manually, and represent a concatenation of available numbers from all partners, with no policy application. With version 1, the updates are prepared by the partners and forwarded to MSN, which tests the numbers and approves them for addition to the phone book. The updates are then concatenated together to form the global update file.
電話Book政権ツールのバージョン1で、電話帳は、すべてのパートナーから手動でコンパイルされて、有効な数の連結を表します、方針アプリケーションなしで。 バージョン1と共に、アップデートをパートナーは準備して、MSNに送ります。(MSNは電話帳に数をテストして、追加のためにそれらを承認します)。 そして、アップデートは、グローバルな更新ファイルを形成するために一緒に連結されます。
The new version of the Phone Book Administration tool automates much of the phone book compilation process, making it possible for phone book compilation to be decentralized with each partner running their own phone book server. Partners can then maintain and test their individual phone books and post them on their own Phone Book Server.
電話Book政権ツールの新しいバージョンは電話帳編集プロセスの多くを自動化します、電話帳編集がそれら自身の電話Book Serverに各パートナーが次に. パートナーが維持できるそれら自身の電話帳サーバを実行している状態で分散されて、彼らの個々の電話帳をテストして、それらを掲示するのを可能にして。
7.5. Phone book update
7.5. 電話帳最新版
There is a mechanism to download phone book deltas, as well as to download arbitrary executables which can perform more complex update processing. Digital signatures are only used on the downloading of executables, since only these represent a security threat - the Connection Manager client does not check for digital signatures on deltas because bogus deltas can't really cause any harm.
電話帳デルタをダウンロードして、より複雑なアップデート処理を実行できる任意のexecutablesをダウンロードするために、メカニズムがあります。 デジタル署名はexecutablesのダウンロードのときに使用されるだけです、これらだけが軍事的脅威を表すので--にせのデルタが本当に少しの害も引き起こさない場合があるので、Connectionマネージャのクライアントはデジタル署名がないかどうかデルタでチェックしません。
The Connection Manager updates the phone book each time the user logs on. This is accomplished via an HTTP GET request to the phone book server. When the server is examining the request, it can take into account things like the OS version on the client, the language on the client, the version of Connection Manager on the client, and the version of the phone book on the client, in order to determine what it wants to send back.
ユーザがログオンするたびにConnectionマネージャは電話帳をアップデートします。 これは電話帳サーバへのHTTP GET要求で達成されます。サーバが要求を調べているとき、クライアントの上のOSバージョン、クライアントの上の言語、クライアントの上のConnectionマネージャのバージョン、およびクライアントの上の電話帳のバージョンのようなものを考慮に入れることができます、それが何を返送したがっているかを決定するために。
Aboba, et. al. Informational [Page 19] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[19ページ]のRFC2194レビュー
In the GET response, the phone book server responds with the difference files necessary to update the client's phone book to the latest version. The client then builds the new phone book by successively applying these difference files. This process results in the update of the entire phone book, and is simple enough to allow it to be easily implemented on a variety of HTTP servers, either as a CGI script or (on NT) as an ISAPI DLL.
GET応答では、違いのファイルがクライアントの電話帳を最新版にアップデートするのに必要な状態で電話帳サーバは反応します。 そして、クライアントは、これらの違いのファイルを適用しながら、相次ぐことで新しい電話帳を造ります。 または、このプロセスは、全体の電話帳のアップデートをもたらして、それがさまざまなHTTPサーバで容易に実装されるのを許容するほど簡単です、どちらかCGIスクリプトとして(NTの) ISAPI DLLとして。
The difference files used in the default phone book consist of a list of phone book entries, each uniquely identified by their index number. Additions consist of phone book entries with all the information filed in; deletions are signified by entries with all entries zeroed out. A sample difference file is shown below:
デフォルト電話帳で使用される違いのファイルは電話帳エントリーのリストから成ります、とそれぞれがそれらの指数で唯一特定しました。 追加はすべての情報が列を作って繰り込んだ電話帳エントリーから成ります。 エントリーが合っていたゼロすべてが外にある状態で、削除はエントリーで意味されています。 サンプル違いのファイルは以下で見せられます:
65031,1,1,Aniston,205,5551212,2400,2400,1,0,myfile
200255,1,1,Auburn/Opelika,334,5551212,9600,28800,0,10,
200133,0,0,0,0,0,0,0,0,0
130,1,1,Birmingham,205,5551211,9600,14400,9,0,yourfile
65034,1,1,Birmingham,205,5551210,9600,14400,1,0,myfile
65031 バーミンガム、1、1、アニストン、205、5551212、2400、2400(1、0)は200255、1、1をmyfileして、赤褐色/Opelika、334、5551212、9600、28800、0、10、200133、0、0、0、0、0、0、0、0、130、1、1、0バーミンガム、205、5551211、9600(14400、9、0)は65034、1、1をyourfileして、205、5551210、9600(14400、1、0)はmyfileされます。
7.6. Connection management
7.6. 接続管理
The Connection Manager can support any protocol which can be configured via use of Windows Dialup Networking, including PPP and SLIP running over IP. The default setting is for the IP address as well as the DNS server IP address to be assigned by the NAS. The DNS server assignment capability is described in [1].
ConnectionマネージャはWindows Dialup Networkingの使用で構成できるどんなプロトコルもサポートできます、IPをひくPPPとSLIPを含んでいて。 既定の設定はDNSサーバIPアドレスと同様にIPアドレスがNASによって割り当てられることです。 DNSサーバ課題能力は[1]で説明されます。
7.7. Authentication
7.7. 認証
The Connection Manager client and RADIUS proxy/server both support
suffix style notation (i.e. "aboba@msn.com"), as well as a prefix
notation ("MSN/aboba").
ConnectionマネージャのクライアントとRADIUSプロキシ/サーバは、接尾語スタイルが記法(すなわち、" aboba@msn.com ")であるとともにサポートします、前置表記法("MSN/aboba")と同様に。
The prefix notation was developed for use with NAS devices with small maximum userID lengths. For these devices the compactness of the prefix notation significantly increases the number of characters available for the userID field. However, as an increasing number of NAS devices are now supporting 253 octet userIDs (the maximum supported by RADIUS) the need for prefix notation is declining.
前置表記法はNASデバイスによる使用のためにわずかな最大のuserIDの長さで開発されました。 これらのデバイスに関しては、前置表記法のコンパクト性はuserID分野に手があいているキャラクタの数をかなり増強します。 しかしながら、増加する数のNASデバイスが、現在253八重奏がuserIDs(RADIUSによってサポートされた最大)であるとサポートしているとき、前置表記法の必要性は減退しています。
After receiving the userID from the Connection Manager client, the NAS device passes the userID/domain and password information (or in the case of CHAP, the challenge and the response) to the RADIUS
ConnectionマネージャのクライアントからuserIDを受けた後に、NASデバイスはuserID/ドメインとパスワード情報(またはCHAPの場合、挑戦、および応答で)をRADIUSに通り過ぎます。
Aboba, et. al. Informational [Page 20] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[20ページ]のRFC2194レビュー
proxy. The RADIUS proxy then checks if the domain is authorized for roaming by examining a static configuration file. If the domain is authorized, the RADIUS proxy then forwards the request to the appropriate RADIUS server. The domain to server mapping is also made via a static configuration file.
プロキシ。 そして、RADIUSプロキシは、ドメインが静的な構成ファイルを調べることによって移動するために認可されるかどうかチェックします。 ドメインが認可されているなら、RADIUSプロキシは適切なRADIUSサーバに要求を転送します。また、サーバマッピングへのドメインは静的な構成ファイルで作られています。
While static configuration files work well for small roaming consortia, for larger consortia static configuration will become tedious. Potentially more scalable solutions include use of DNS SRV records for the domain to RADIUS server mapping.
静的な構成ファイルが小さいローミングコンソーシアムにうまくいっている間、より大きいコンソーシアム静電気に関して、構成は退屈になるでしょう。 潜在的によりスケーラブルなソリューションはDNS SRV記録のドメインの使用をRADIUSサーバマッピングに含んでいます。
7.8. NAS configuration/authorization
7.8. NAS構成/承認
Although the attributes returned by the home RADIUS server may make sense to home NAS devices, the local NAS may be configured differently, or may be from a different vendor. As a result, it may be necessary for the RADIUS proxy to edit the attribute set returned by the home RADIUS server, in order to provide the local NAS with the appropriate configuration information. The editing occurs via attribute discard and insertion of attributes by the proxy.
ホームRADIUSサーバによって返された属性はホームNASデバイスに理解できますが、地方のNASは異なって構成されるか、または異なったベンダーから来ているかもしれません。 その結果、RADIUSプロキシがホームRADIUSサーバによって返された属性セットを編集するのが必要であるかもしれません、適切な設定情報を地方のNASに提供するために。 編集はプロキシによる属性の属性破棄と挿入で起こります。
Alternatively, the home RADIUS server may be configured not to return any network-specific attributes, and to allow these to be inserted by the local RADIUS proxy.
あるいはまた、ホームRADIUSサーバは、どんなネットワーク特有の属性も返さないで、これらが地元のRADIUSプロキシによって挿入されるのを許容するために構成されるかもしれません。
Attributes most likely to cause conflicts include:
闘争を最も引き起こしそうな属性は:
Framed-IP-Address Framed-IP-Netmask Framed-Routing Framed-Route
Filter-Id Vendor-Specific Session-Timeout Idle-Timeout
Termination-Action
縁どられたIPアドレスのフィルタイドのベンダー特有のセッションタイムアウトアイドルタイムアウト終了縁どられたIPネットマスク縁どられたルート設定縁どられたルート動作
Conflicts relating to IP address assignment and routing are very common. Where dynamic address assignment is used, an IP address pool appropriate for the local NAS can be substituted for the IP address pool designated by the home RADIUS server.
IPアドレス課題に関連する闘争とルーティングは非常に一般的です。 ダイナミックなアドレス課題が使用されているところでは、ホームRADIUSサーバによって指定されたIPアドレスプールに地方のNASに、適切なIPアドレスプールを代入できます。
However, not all address conflicts can be resolved by editing. In some cases, (i.e., assignment of a static network address for a LAN) it may not be possible for the local NAS to accept the home RADIUS server's address assignment, yet the roaming hosts may not be able to accept an alternative assignment.
しかしながら、編集ですべてのアドレス闘争を解決できるというわけではありません。 いくつかの場合、地方のNASがホームRADIUSサーバのアドレス課題を受け入れるのにおいて(すなわち、LANのための静的なネットワーク・アドレスの課題)それが可能でないかもしれない、しかし、ローミングホストは代替の課題を受け入れることができないかもしれません。
Filter IDs also pose a problem. It is possible that the local NAS may not implement a filter corresponding to that designated by the home RADIUS server. Even if an equivalent filter is implemented, in order to guarantee correct operation, the proxy's configuration must track changes in the filter configurations of each of the members of the
また、フィルタIDは問題を設定します。 地方のNASはホームRADIUSサーバによって指定されたそれに対応するフィルタを実装しないかもしれません。それは同等なフィルタが正しい操作を保証するために実装されても、プロキシの構成がメンバー各人のフィルタ構成における変化を追わなければならないのが可能です。
Aboba, et. al. Informational [Page 21] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[21ページ]のRFC2194レビュー
roaming consortium. In practice this is likely to be unworkable. Direct upload of filter configuration is not a solution either, because of the wide variation in filter languages supported in today's NAS devices.
共同体に移動します。 実際には、これは「非-実行可能」である傾向があります。 フィルタ構成のダイレクトアップロードはソリューションではありません、今日のNASデバイスでサポートされたフィルタ言語の広い変化のために。
Since by definition vendor specific attributes have meaning only to devices created by that vendor, use of these attributes is problematic within a heterogeneous roaming consortium. While it is possible to edit these attributes, or even to discard them or allow them to be ignored, this may not always be acceptable. In cases where vendor specific attributes relate to security, it may not be acceptable for the proxy to modify or discard these attributes; the only acceptable action may be for the local NAS to drop the user. Unfortunately, RADIUS does not distinguish between mandatory and optional attributes, so that there is no way for the proxy to take guidance from the server.
そのベンダーが定義上ベンダーの特定の属性でデバイスだけへの意味を作成するので、これらの属性の使用は種々雑多なローミング共同体の中で問題が多いです。 これらの属性を編集するか、それらを捨てるか、またはそれらが無視されるのを許容するのさえ可能ですが、これはいつも許容できるかもしれないというわけではありません。 ベンダーの特定の属性がセキュリティに関連する場合では、プロキシがこれらの属性を変更するか、または捨てるのが、許容できないかもしれません。 唯一の許容できる動作は地方のNASがユーザを下げることであるかもしれません。 残念ながら、RADIUSは義務的で任意の属性を見分けません、プロキシがサーバから指導を取る方法が全くないように。
Conflicts over session or idle timeouts may result if since both the local and home ISP feel the need to adjust these parameters. While the home ISP may wish to adjust the parameter to match the user's software, the local ISP may wish to adjust it to match its own service policy. As long as the desired parameters do not differ too greatly, a compromise is often possible.
両方以来地方とホームISPがこれらのパラメタを調整する必要性を感じるなら、セッションに関する闘争かアイドルタイムアウトが結果として生じるかもしれません。 ホームISPがユーザのソフトウェアを合わせるようにパラメタを調整したがっているかもしれない間、地方のISPは、それ自身のサービス方策を合わせるようにそれを調整したがっているかもしれません。 また、必要なパラメタは大きな開きがない限り、感染がしばしば可能です。
7.9. Address assignment and routing
7.9. アドレス課題とルーティング
While the Connection Manager software supports both static and dynamic address assignment, in the MSN implementation, all addresses are dynamically assigned.
Connectionマネージャソフトウェアが、静的なものと同様にダイナミックなアドレスが課題であるとサポートしている間、MSN実装では、すべてのアドレスがダイナミックに割り当てられます。
However, selected partners also offer LAN connectivity to their customers, usually via static address assignment. However, these accounts do not have roaming privileges since no mechanism has been put in place for allowing these static routes to move between providers.
しかしながら、また、選択されたパートナーは通常静的なアドレス課題でLANの接続性を彼らの顧客に提供します。 しかしながら、これらのアカウントには、メカニズムが全くこれらのスタティックルートがプロバイダーの間で移行するのを許容するために適所に置かれていないので、ローミング特権がありません。
Users looking to do LAN roaming between providers are encouraged to select a router supporting Network Address Translation (NAT). NAT versions implemented in several low-end routers are compatible with the dynamic addressing used on MSN, as well as supporting DHCP on the LAN side.
プロバイダーの間のLANローミングをするのを目指しているユーザがNetwork Address Translationが(NAT)であるとサポートするルータを選択するよう奨励されます。 いくつかのローエンドルータで実装されたNATバージョンはMSNで使用されるダイナミックなアドレシングとLAN側でDHCPをサポートするのと互換性があります。
7.10. Security
7.10. セキュリティ
The RADIUS proxy/server implementation does not support token cards or tunneling protocols.
RADIUSプロキシ/サーバ実装は、トークン・カードかトンネリングがプロトコルであるとサポートしません。
Aboba, et. al. Informational [Page 22] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[22ページ]のRFC2194レビュー
7.11. Accounting
7.11. 会計
In the MSN roaming implementation, the accounting data exchange process is specified in terms of an accounting record format, and a method by which the records are transferred from the partners to MSN, which acts as the settlement agent. Defining the interaction in terms of record formats and transfer protocols implies that the partners do not communicate with the settlement agent using NAS accounting protocols. As a result, accounting protocol interoperability is not be required.
MSNローミング実装では、会計データ交換プロセスは会計レコード形式、および記録がパートナーからMSNまで移されるメソッドで指定されます。MSNは解決エージェントとして務めます。 レコード形式と転送プロトコルで相互作用を定義するのは、パートナーがNAS会計プロトコルを使用することで解決エージェントとコミュニケートしないのを含意します。 結果、会計プロトコル相互運用性がそうでないように、必要であってください。
However, for this advantage to be fully realized, it is necessary for the accounting record format to be extensible. This makes it more likely that the format can be adapted for use with the wide variety of accounting protocols in current use (such as SNMP, syslog, RADIUS, and TACACS+), as well as future protocols. After all, if the record format cannot express the metrics provided by a particular partner's accounting protocol, then the record format will not be of much usefor a heterogeneous roaming consortium.
しかしながら、この完全に実感されるべき利点に会計レコード形式が広げることができるのが必要です。 これで、使用のために現在の使用(SNMPや、syslogや、RADIUSや、TACACS+などの)での広いバラエティーの会計プロトコルで形式を適合させることができるのは、よりありそうになります、将来のプロトコルと同様に。 結局、レコード形式が特定のパートナーの会計プロトコルによって提供された測定基準を表すことができないと、レコード形式はuseforのa種々雑多なローミング共同体のあまりものにならないでしょう。
7.11.1. Accounting record format
7.11.1. 会計帳簿形式
The Microsoft RADIUS proxy/server supports the ability to customize the accounting record format, and it is expected that some ISPs will make use of this capability. However for those who want to use it "off the shelf" a default accounting record format is provided. The accounting record includes information provided by RADIUS:
マイクロソフトRADIUSプロキシ/サーバは会計レコード形式をカスタム設計する能力をサポートします、そして、いくつかのISPがこの能力を利用すると予想されます。 しかしながら、それに「すぐ入手でき」て使用に欲しい人にとって、デフォルト会計レコード形式を提供します。 会計帳簿はRADIUSによって提供された情報を含んでいます:
User Name (String; the user's ID, including prefix or suffix)
NAS IP address (Integer; the IP address of the user's NAS)
NAS Port (Integer; identifies the physical port on the NAS)
Service Type (Integer; identifies the service provided to the user)
NAS Identifier (Integer; unique identifier for the NAS)
Status Type (Integer; indicates session start and stop,
as well as accounting on and off)
Delay Time (Integer; time client has been trying to send)
Input Octets (Integer; in stop record, octets received from port)
Output Octets (Integer; in stop record, octets sent to port)
Session ID (Integer; unique ID linking start and stop records)
Authentication (Integer; indicates how user was authenticated)
Session Time (Integer; in stop record, seconds of received service)
Input Packets (Integer; in stop record, packets received from port)
Output Packets (Integer; in stop record, packets sent to port)
Termination Cause (Integer; in stop record, indicates termination cause)
Multi-Session ID (String; for linking of multiple related sessions)
Link Count (Integer; number of links up when record was generated)
NAS Port Type (Integer; indicates async vs. sync ISDN, V.120, etc.)
ユーザName(ストリング; 接頭語か接尾語を含むユーザのID)NAS IPがNAS Portを扱う、(整数; ユーザのNASのIPアドレス)(整数;、NASの上の物理的なポート) サービスTypeが特定する、(整数;、ユーザに提供されたサービス) NAS Identifierは特定します; (整数; NASに、ユニークな識別子) 状態Type(整数; セッション始めと停止を示して、時々説明する)遅れTime(整数; クライアントを調節するのは発信しようとしていた)入力Octets(停止記録の整数、八重奏はポートから受信されました); Octets(停止記録の整数、八重奏はポートに発信した)Session ID(整数; 始めと停止記録をリンクするユニークなID)認証を出力してください、(整数;、ユーザはどう認証されたか) セッションTime(停止記録、秒の容認されたサービスにおける整数)入力Packets(停止記録の整数、パケットはポートから受信された)出力Packets(停止記録の整数、パケットはポートに発信した)終了Cause(停止記録の整数は終了原因を示す)マルチSession IDが示す、(ストリング; mulをリンクするためにtipleの関連するセッション) リンクCount(整数; 記録が生成されたなら上がっているリンクの数)NAS Port Type(整数; async、対同時性ISDN V.120を示す、など)
Aboba, et. al. Informational [Page 23] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[23ページ]のRFC2194レビュー
However, since this default format is not extensible, it cannot easily be adapted to protocols other than RADIUS, services other than dialup (i.e. dedicated connections) or rated events (i.e. file downloads). This is a serious limitation, and as a result, customers have requested a more general accounting record format.
しかしながら、この省略時書式が広げることができないので、容易にRADIUS以外のプロトコルにそれを適合させることができません、ダイアルアップ(すなわち、接続を捧げる)か評定されたイベント以外のサービス(すなわち、ファイルダウンロード)。 これは重大な制限です、そして、その結果、顧客は、より一般的な会計レコード形式を要求しました。
7.11.2. Transfer mechanism
7.11.2. トランスファ・メカニズム
Prior to being transferred, the accounting records are compressed so as to save bandwidth. The transfer of accounting records is handled via FTP, with the transfer being initiated by the receiving party, rather than by the sending party. A duplicate set of records is kept by the local ISP for verification purposes.
移す前に、会計帳簿は、帯域幅を保存するために圧縮されます。 会計帳簿の転送はFTPで扱われます、転送が送付パーティーでというよりむしろ受領者によって起こされている状態で。 記録の写しセットは検証目的のために地方のISPによって維持されます。
8. Merit Network Implementation
8. 長所ネットワーク実装
8.1. Overview
8.1. 概要
MichNet is a regional IP backbone network operated within the state of Michigan by Merit Network, Inc., a nonprofit corporation based in Ann Arbor, Michigan. Started in 1966, MichNet currently provides backbone level Internet connectivity and dial-in IP services to its member and affiliate universities, colleges, K-12 schools, libraries, government institutions, other nonprofit organizations, and commercial business entities.
MichNetはMerit Network Inc.(アナーバー(ミシガン)のベースの非営利企業)によるミシガン州の中で経営された地方のIPバックボーンネットワークです。 1966年に始められます、MichNetは現在、バックボーンレベルインターネットの接続性とメンバー、系列大学、大学、幼小中高学校、ライブラリ、政府機関、他の非営利組織の管理運営、および商業企業体に対するダイヤルインのIPサービスを提供します。
As of May 1, 1997, MichNet had 11 members and 405 affiliates. Its shared dial-in service operated 133 sites in Michigan and one in Washington, D.C, with 4774 dial-in lines. Additional dial-in lines and sites are being installed daily.
1997年5月1日の時点で、MichNetには、11人のメンバーと405の系列がありました。 共有されたダイヤルインのサービスは4774個のダイアルイン回線でミシガンの133のサイトとワシントン、D.Cの1つを操作しました。 追加ダイアルイン回線とサイトは毎日インストールされています。
MichNet also provides national and international dial-in services to its members and affiliates through an 800 number and other external services contracting with national and global service providers.
また、MichNetは国家の、そして、グローバルなサービスプロバイダーと契約するフリーダイヤルと他の外部サービスでそのメンバーと系列に対する国家的、そして、国際的なダイヤルインのサービスを提供します。
The phone numbers of all MichNet shared dial-in sites are published both on the Merit web site and in the MichNet newsletters. Merit also provides links to information about the national and international service sites through their respective providers' web sites. Such information can be found at http://www.merit.edu/mich- net/shared.dialin/.
すべてのMichNetの分配しているダイヤルインのサイトの電話番号はMeritウェブサイトとMichNetニュースレターで発表されます。 また、長所は国家的、そして、国際的なサービスサイトの情報へのリンクをそれらのそれぞれのプロバイダーのウェブサイトを通して提供します。 http://www.merit.edu/mich- net/shared.dialin/でそのような情報を見つけることができます。
8.1.1. MichNet State-Wide Shared Dial-In Services
8.1.1. 州全体のMichNetはダイヤルインのサービスを共有しました。
Each MichNet shared dial-in service site is owned and maintained by either Merit or by a member or affiliate organization. All sites must support PPP and Telnet connections.
各MichNetはどちらかのMeritかメンバーによって所有されて、維持されたダイヤルインのサービスサイトか系統機関を共有しました。 すべてのサイトが、PPPとTelnetが接続であるとサポートしなければなりません。
Aboba, et. al. Informational [Page 24] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[24ページ]のRFC2194レビュー
Each organization participating in the shared dial-in service is assigned a realm-name. Typically the realm-name resembles a fully qualified domain name. Users accessing the shared dial-in service identify themselves by using a MichNet AccessID which consists of their local id concatenated with "@" followed by the realm-name - e.g. user@realm
分野名は共有されたダイヤルインのサービスに参加する各組織に配属されます。 通常、分野名は完全修飾ドメイン名に類似しています。 共有されたダイヤルインのサービスにアクセスするユーザが分野名が例えば"@"のあとに続いていて連結された地元のイドから成るMichNet AccessIDを使用するのによる自分たちのために user@realm を特定します。
Merit operates a set of Authentication, Authorization and Accounting (AAA) servers supporting the RADIUS protocol which are called core servers. The core servers support all the dial-in service sites and act as proxy servers to other AAA servers running at the participating organizations. For security reasons, Merit staff run all core servers; in particular, the user password is in the clear when the proxy core server decodes an incoming request and then re- encodes it and forwards it out again,
長所は1セットのAuthentication、Authorization、およびRADIUSプロトコルをサポートするAccounting(AAA)サーバを操作します(コアサーバと呼ばれます)。 コアサーバはプロキシサーバとして参加組織のときに稼働する他のAAAサーバにすべてのダイヤルインのサービスサイトと行為をサポートします。 安全保障上の理由で、Meritスタッフはすべてのコアサーバを実行します。 プロキシコアサーバが入って来る要求を解読して、次に、それを再コード化して、再びそれを外に送るとき、特に、ユーザパスワードが明確にあります。
The core servers also enforce a common policy among all dial-in servers. The most important policy is that each provider of access must make dial-in ports available to others when the provider's own users do not have a need for them. To implement this policy, the proxy server distinguishes between realms that are owners and realms that are guests.
また、コアサーバはすべてのダイヤルインサーバの中で共通政策を実施します。 最も重要な方針はプロバイダーの自己のユーザに彼らの必要がないとき、アクセスの各プロバイダーでダイヤルインのポートが他のものにとって利用可能にならなければならないということです。 この政策を実施するために、プロキシサーバは所有者である分野とゲストである分野を見分けます。
One piece of the policy determining whether the provider's organization has need of the port, is implemented by having the proxy core server track the realms associated with each of the sessions connected at a particular huntgroup. If there are few ports available (where few is determined by a formula) then guests are denied access. Guests are also assigned a time limit and their sessions are terminated after some amount of time (currently one hour during prime time, two hours during non-prime time).
分野がそれぞれのセッションに関連づけたプロキシコアサーバ足跡を持っているポートについてそうしなければならなくて、プロバイダーの組織がそうしたかどうか決定するのが実装される方針の1つの断片が特定のhuntgroupで接続しました。 利用可能な(わずかしか公式で決定しないところ)ポートがわずかしかなければ、アクセサリーはゲストに対して否定されます。 また、タイムリミットはゲストに割り当てられます、そして、彼らのセッションはいつかの時間(1時間に現在、ゴールデンアワーの非ゴールデンアワーの間の2時間)の後に終えられます。
The other part of the policy is to limit the number of guests that are allowed to connect. This is done by limiting the number of simultaneous guest sessions for realms. Each realm is allocated a number of "simultaneous access tokens" - SATs. When a guest session is authorized the end server for the realm decrements the count of available SATs, and when the session is terminated the count of SATs is incremented. A Merit specific attribute is added to the request by the core if the session will be a "guest" and will require a SAT. The end server must include a reply with an attribute containing the name of the "token pool" from which the token for this session is taken. The effect of this is to limit the number of guests connected to the network to the total number of tokens allocated to all realms.
方針のもう片方の部分は接続できる客数を制限することです。 同時のゲストセッションの数を分野に制限することによって、これをします。土曜日、多くの「同時アクセストークン」を各分野に割り当てます。 ゲストセッションが認可されているとき、分野へのエンドサーバは土曜日の利用可能のカウントを減少させます、そして、セッションが終えられるとき、土曜日のカウントは増加されています。 セッションが「ゲスト」であり、土曜日を必要とするなら、Meritの特定の属性はコアによって要求に追加されます。 エンドサーバは属性がこのセッションのためのトークンが取られる「トークンプール」の名前を含んでいる回答を含まなければなりません。 この効果はネットワークに関連づけられた客数をすべての分野に割り当てられたトークンの総数に制限することです。
Aboba, et. al. Informational [Page 25] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[25ページ]のRFC2194レビュー
Each realm is authenticated and authorized by its own AAA server. The proxy core servers forward requests to the appropriate server based on a configuration file showing where each realm is to be authenticated. Requests from realms not in the configuration are dropped.
各分野は、それ自身のAAAサーバによって認証されて、認可されます。プロキシコアサーバは各分野がどこで認証されることになっているかを示す構成ファイルに基づく適切なサーバに要求を転送します。 分野からの要求は構成で下げられません。
The Merit AAA server software supports this policy. Merit provides this software to member and affiliate organizations. The software is designed to work with many existing authentication servers, such as Kerberos IV, UNIX password, TACACS, TACACS+, and RADIUS. This enables most institutions to utilize the authentication mechanism they have in place.
Merit AAAサーバソフトウェアはこの方針をサポートします。 長所はこのソフトウェアをメンバーと系統機関に提供します。 ソフトウェアは多くの既存の認証サーバで働くように設計されています、ケルベロスIVや、UNIXパスワードや、TACACSや、TACACS+や、RADIUSなどのように。 これは、ほとんどの団体がそれらが適所に持っている認証機構を利用するのを可能にします。
8.1.2. MichNet National and International Dial-In Services
8.1.2. MichNetの国家の、そして、国際のダイヤルインのサービス
In addition to the MichNet shared dial-in service, Merit also provides access from locations outside of Michigan by interconnecting with other dial-in services. These services are typically billed by connect time. Merit acts as the accounting agent between its member and affiliate organizations and the outside service provider.
また、MichNetの分配しているダイヤルインのサービスに加えて、Meritは、アクセスを位置からミシガンの外に他のダイヤルインのサービスで内部連絡することによって、提供します。 接続時間によってこれらのサービスに通常請求されます。 メンバーと、系統機関と外のサービスプロバイダーの間の会計エージェントとして行為に値してください。
The services currently supported are a national 800 number and service via the ADP/Autonet dial-in network. Connection with IBM/Advantis is being tested, and several other service interconnects are being investigated.
現在サポートされているサービスは、ADP/オートネットダイヤルインネットワークを通した国家のフリーダイヤルとサービスです。 IBM/Advantisとの接続はテストされています、そして、他のいくつかのサービス内部連絡が調査されています。
Calls placed by a Merit member/affiliate user to these external dial-in services are authenticated by having each of those services forward RADIUS authentication requests and accounting messages to a Merit proxy core server. The core forwards the requests to the member/affiliate server for approval. Session records are logged at the Merit core server and at the member/affiliate erver. Merit bills members/affiliates monthly, based on processing of the accounting logs. The members and affiliates are responsible for rebilling their users.
それぞれのそれらのサービスに認証要求と会計メッセージをMeritプロキシコアサーバにRADIUSに転送させることによって、これらの外部のダイヤルインのサービスへのMeritメンバー/系列ユーザによって出された電話は認証されます。コアは承認のためのメンバー/系列サーバに要求を転送します。 セッション記録はMeritコアサーバにおいてメンバー/系列erverに登録されます。長所は会計ログの処理に月毎の、そして、基づいているメンバー/系列に請求します。 メンバーと系列は彼らのユーザを再請求するのに責任があります。
The Merit AAA software supports the ability to request positive confirmation of acceptance of charges, and provides tools for accumulating and reporting on use by realm and by user.
Merit AAAソフトウェアは、充電の積極的な引き受けの確認を要求する能力をサポートして、分野とユーザによる使用に関して蓄積して、報告するのにツールを提供します。
8.2. Authentication and Authorization
8.2. 認証と承認
Authentication of a Telnet session is supported using the traditional id and password method, with the id being a MichNet AccessID of the form user@realm, while a PPP session may be authenticated either using an AccessID and password within a script, or using PAP. Support for challenge/response authentication mechanisms using EAP is under development.
Telnetセッションの認証は伝統的なイドを使用して、パスワードメソッドであるとサポートされます、フォーム user@realm のMichNet AccessIDであるイドで、PPPセッションはスクリプトの中でAccessIDとパスワードを使用するか、またはPAPを使用することで認証されるかもしれませんが。 EAPを使用する挑戦/応答認証機構のサポートは開発中です。
Aboba, et. al. Informational [Page 26] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[26ページ]のRFC2194レビュー
When a user dials into a MichNet shared dial-in port, the NAS sends an Access-Request to a core AAA server using the RADIUS protocol. First the core server applies any appropriate huntgroup access policies to the request. If the Request fails the policy check, an Access-Reject is returned to the NAS. Otherwise, the core server forwards it to the user's home authentication server according to the user's realm. The home authentication server authenticates and authorizes the access request. An Access-Accept or Access-Reject is sent back to the core server. If an Access-Accept is sent, the home server will create a dial-in session identifier which is unique to this session and insert it in a Class attribute in the Access-Accept. The core server looks at the request and the response from the home server again and decides either to accept or reject the request. Finally, the core server sends either an Access-Accept or Access- Reject to the NAS.
ユーザがいつMichNetにダイヤルするかがダイヤルインのポートを共有して、NASは、RADIUSプロトコルを使用することでAccess-要求をコアAAAサーバに送ります。 まず最初に、コアサーバはどんな適切なhuntgroupアクセス方針も要求に適用します。 Requestが方針チェックに失敗するなら、Access-廃棄物をNASに返します。 さもなければ、ユーザの分野に応じて、コアサーバはユーザのホーム認証サーバにそれを送ります。 ホーム認証サーバは、アクセス要求を認証して、認可します。 Access受け入れるか、Access拒絶、コアサーバが送り返される、Access受け入れるのは、送ります、ホームサーバがこのセッションにユニークであり、それをClassに挿入する識別子が中でAccess受け入れるのを結果と考えるダイヤルインのセッションを作成するということです。 コアサーバは、再びホームサーバから要求と応答を見て、要求を受け入れるか、または拒絶すると決めます。 Access受け入れてください。最終的に、コアサーバが発信する、または、NASへのAccess廃棄物。
When a user dials into a contracted ISP's huntgrup (MichNet National and International Service), the ISP sends a RADIUS access request to a Merit core server. The rest of the authentication and authorization path is the same as in the shared dial-in service, except that no huntgroup access policy is applied but a Huntgroup-Service attribute is sent to the home authentication server with its value being the name of the service, and a copy of the attribute must be returned by the home server with a flag appended to the original value to indicate a positive authorization of user access to the specified service.
ユーザが収縮したISPのhuntgrup(MichNet Nationalと国際Service)にダイヤルするとき、ISPはMeritコアサーバにRADIUSアクセス要求を送ります; Huntgroup-サービス属性をホーム認証サーバにサービスの名前である値で送ります、そして、どんなhuntgroupアクセス方針も適用されていないのを除いて、認証と承認経路の残りは共有されたダイヤルインのサービスと同じですが、ホームサーバは指定されたサービスへのユーザアクセスの正の承認を示すために元の値に旗を追加している状態で属性のコピーを返さなければなりません。
The MichNet shared dial-in service typically requires authorization of some sort, for example, a user dialing into a huntgroup as a guest must be authorized with a token from the user's realm. Participating institutions have control in defining authorization rules. Currently authorization may be done using any combination of the user's group status and user's account status. A set of programming interfaces is also provided for incorporating new authorization policies.
ゲストがある種の承認、例えば、huntgroupにダイヤルするユーザであるに違いありませんが、トークンでユーザの分野から認可されて、共有されたダイヤルインのサービスが通常必要とするMichNet。 参加団体は承認規則を定義する際にコントロールを持っています。 現在の、承認はユーザのグループ状態とユーザのアカウントステータスのどんな組み合わせも使用し終わるかもしれません。 また、1セットのプログラミングインターフェースは、新しい承認方針を取り入れながら、備えられます。
8.3. Accounting
8.3. 会計
In the Merit AAA server, a session is defined as starting from the moment the user connects to the NAS, and ending at the point when the user disconnects. During the course of a session, both the core server and the home server maintain status information about the session. This allows the AAA servers to apply policies based on the current status, e.g. limit guest access by realm to number of
Merit AAAサーバでは、セッションはユーザがNASに接続する瞬間から始めて、ユーザが切断するとポイントで終わると定義されます。 セッションのコースの間、コアサーバとホームサーバの両方がセッション頃に状態情報を保守します。 これは数への分野によって現在の状態、例えば、限界ゲストアクセスに基礎づけられた方針を応用するAAAサーバを許容します。
Aboba, et. al. Informational [Page 27] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[27ページ]のRFC2194レビュー
available tokens, or to limit number of simultaneous sessions for a given AccessID. Information such as whether the session is for a guest, whether it used a token, and other information is included with the accounting stop information when it is logged. Merit has made enhancements to the RADIUS protocol, that are local to the AAA server, to support maintenance of session status information.
利用可能なトークン、与えられたAccessIDのための同時のセッションの限界番号 それがトークンを使用したか否かに関係なく、セッションがゲストのためのものであるかなどの情報と他の情報はそれがいつ登録されるかという会計停止情報で含まれています。 長所は増進をRADIUSプロトコルにして、それは、セッション状態情報のメインテナンスをサポートするためにAAAサーバに地方です。
When a user session is successfully authenticated, the NAS sends out a RADIUS accounting start request to the core server. The core server forwards that request to the user's home server. The home server updates the status of the session and then responds to the core. The core server in turn responds to the NAS. In the accounting Start request, a NAS conforming to the RADIUS specification must return the Class attribute and value it received in the Access-Accept for the session, thus sending back the dial-in session identifier created by the session's home server.
ユーザセッションが首尾よく認証されるとき、NASはRADIUS会計スタート要求をコアサーバに出します。コアサーバはその要求をユーザのホームサーバに転送します。ホームサーバは、セッションの状態をアップデートして、次に、コアまで応じます。 コアサーバは順番にNASに反応します。 Startが要求する会計では、RADIUS仕様に従うのがそれがその結果、セッションのためにAccess受け入れる発信で受けたClass属性と値を返さなければならないNASはセッションのホームサーバによって作成されたダイヤルインのセッション識別子を支持します。
When a user ends a session, an accounting stop request is sent through the same path. the same path. The dial-in session identifier is again returned by the NAS, providing a means of uniquely identifying a session. By configuring the finite state machine in each of the AAA servers, any accounting requests may be logged by any of the servers where the accounting requests are received.
ユーザが終わるとき、セッションであり、同じ経路同じ経路を通して会計停止要求を送ります。 唯一セッションを特定する手段を提供して、ダイヤルインのセッション識別子は再びNASによって返されます。 それぞれのAAAサーバで有限状態機械を構成することによって、どんな会計要求も会計要求が受信されているサーバのいずれによっても登録されるかもしれません。
Because the same session logs are available on every server in the path of a session's authorization and accounting message, problems with reconciliation of specific sessions may be resolved easily. For the shared dial-in service, there are no usage charges. Merit has tools to verify that organizations do not authorize more guest sessions than the number of SATs allocated to the organization. For surcharged sessions, Merit sends each organization a summary bill each month. Files with detail session records are available for problem resolution. Each organization is responsible for billing its own users, and should have the same session records as are collected by Merit.
同じセッション・ログがセッションの承認と会計メッセージの経路のあらゆるサーバで利用可能であるので、特定のセッションの和解に関する問題は容易に解決されるかもしれません。 共有されたダイヤルインのサービスのために、用法充電は全くありません。 長所には、組織が組織に割り当てられた土曜日の数より多くのゲストセッションを認可しないことを確かめるツールがあります。 割増しされたセッションのために、Meritは毎月概要請求書を各組織に送ります。 詳細セッション記録があるファイルは問題解決に利用可能です。 各組織は、それ自身のユーザに請求するのに責任があって、Meritによって集められるのと同じセッション記録を持つべきです。
Merit receives a monthly invoice from other dial-in service providers and pays them directly, after first verifying that the charges correspond to the session records logged by Merit.
長所は、他のダイヤルインのサービスプロバイダーから毎月のインボイスを受け取って、直接それらを支払います、最初に充電がMeritによって登録されたセッション記録に対応することを確かめた後に。
8.4. Software and Development
8.4. ソフトウェアと開発
Merit has developed the AAA server software which supports the above capabilities initially by modifying the RADIUS server provided by Livingston, and later by doing a nearly total rewrite of the software to make enhancement and extension of capabilites easier. Merit makes a basic version of its server freely available for noncommercial use.
長所は初めはcapabilitesの増進と拡大をより簡単にするようにリビングストンによって提供されて、ソフトウェアのほとんど総書き直しをすることによって後のRADIUSサーバを変更することによって上の能力をサポートするAAAサーバソフトウェアを開発しました。 長所で、サーバの基本的なバージョンは自由に非営利的な使用に利用可能になります。
Aboba, et. al. Informational [Page 28] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[28ページ]のRFC2194レビュー
Merit has started the Merit AAA Server Consortium which consists of Merit and a number of NAS vedors, ISPs and server software vendors. The consortium supports ongoing development of the Merit AAA server. The goal is to build a server that supports proxy as well as end server capabilities, that is feature rich, and that interoperates with major vendors' NAS products.
長所は成るMeritのMerit AAA Server Consortium、多くのNAS vedors、ISP、およびサーバソフトウェアベンダーを始動しました。 共同体はMerit AAAサーバの開発現況をサポートします。目標はすなわち、終わりのサーバ能力、特徴金持ちと同様にプロキシをサポートして、主要なベンダーのNAS製品で共同利用するサーバを組立てることです。
The building block of the Merit AAA server, the Authentication/Authorization Transfer Vector (AATV), is a very powerful concept that enables the ultimate modularity and flexibility of the AAA server. The structure and methods of the AATV model are published with all versions of the AAA server.
Merit AAAサーバのブロック(Authentication/承認Transfer Vector(AATV))はAAAサーバの究極のモジュール方式と柔軟性を可能にする非常に強力な概念です。AATVモデルの構造とメソッドはAAAサーバのすべてのバージョンで発行されます。
Objects for extending the authorization server are also available in the enhanced version of the AAA server. Merit is also looking at ways to provide a method of extending the AAA server in its executable form, to improve the server efficiency and scalability, and to provide better monitoring, instrumentation and administration of the server.
また、承認サーバを広げるためのオブジェクトもAAAサーバの高められたバージョンで利用可能です。また、長所はサーバ効率とスケーラビリティを改良する実行可能なフォームでAAAサーバを広げるメソッドを提供して、サーバのモニターするほうがよい、計装、および管理を提供する方法を見ています。
9. FidoNet implementation
9. FidoNet実装
Since its birth in 1984, FidoNet has supported phone book synchronization among its member nodes, which now number approximately 35,000. As a non-IP dialup network, FidoNet does not provide IP services to members, and does not utilize IP-based authentication technology. Instead member nodes offer bulletin-board services, including access to mail and conferences known as echoes.
生まれて以来1984年に、FidoNetはメンバーノードの中で電話帳同期をサポートしました。ノードは現在、およそ3万5000に達します。 非IPダイアルアップネットワークとして、FidoNetはメンバーに対するIPサービスを提供しないで、またIPベースの認証技術を利用しません。 代わりに、メンバーノードは郵送するアクセスとエコーとして知られている会議を含む掲示板のサービスを提供します。
In order to be able to communicate with each other, FidoNet member systems require a sychronized phone book, known as the Nodelist. The purpose of the Nodelist is to enable resolution of FidoNet addresses (expressed in the form zone:network/node, or 1:161/445) to phone numbers. As a dialup network, FidoNet requires phone numbers in order to be deliver mail and conference traffic.
互いにコミュニケートできるように、FidoNetメンバーシステムはNodelistとして知られているsychronized電話帳を必要とします。 Nodelistの目的はFidoNetアドレス(フォームゾーン: ネットワーク/ノード、または1:161/445に、言い表される)の解決を電話番号に可能にすることです。 ダイアルアップネットワークとして、FidoNetは、メールと会議トラフィックを提供することになるように電話番号を必要とします。
In order to minimize the effort required in regularly synchronizing a phone book of 35,000 entries, the weekly Nodelist updates are transmitted as difference files. These difference files, known as the Nodediff, produce the Nodelist for the current week when applied to the previous week's Nodelist. In order to minimize transfer time, Nodediffs are compressed prior to transfer.
3万5000のエントリーの電話帳を定期的に同期させるのにおいて必要である取り組みを最小にするために、違いがファイルされるとき、毎週のNodelistアップデートは伝えられます。 Nodediffとして知られているこれらの違いのファイルは現在の週から適用されると前の週のNodelistのためにNodelistを生産します。 転送時間を最小にするために、Nodediffsは転送の前に圧縮されます。
Information on FidoNet, as well as FidoNet Technical Standards (FTS) documents (including the Nodelist specification) and standards proposals are available from the FidoNet archive at http://www.fidonet.org/.
FidoNetに関する情報、FidoNet Technical Standards(FTS)と同様に、ドキュメント(Nodelist仕様を含んでいる)と規格提案は http://www.fidonet.org/ のFidoNetアーカイブから利用可能です。
Aboba, et. al. Informational [Page 29] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[29ページ]のRFC2194レビュー
9.1. Scaling issues
9.1. スケーリング問題
With a Nodelist of 35,000 entries, the FidoNet Nodelist is now 3.1 MB in size, and the weekly Nodediffs are 175 KB. In compressed form, the Nodelist is approximately 1 MB, and the weekly Nodediff is 90 KB. As a result, the transfer of the Nodediff takes approximately 45 seconds using a 28,800 bps modem.
現在3万5000のエントリーのNodelistと共に、FidoNet Nodelistはサイズが3.1MBです、そして、毎週のNodediffsは175KBです。 圧縮形では、Nodelistはおよそ1MBです、そして、毎週のNodediffは90KBです。 その結果、Nodediffの転送は、2万8800ビーピーエスモデムを使用することでおよそ45秒取ります。
In order to improve scalability, the implementation of a domain name service approach is examined in [8]. The proposal evisages use of a capability analagous to the DNS ISDN record in order to map names to phone numbers, coupled with an additional record to provide the attributes associated with a given name.
スケーラビリティを改良するために、ドメイン名サービスアプローチの実装は[8]で調べられます。 DNS ISDNへのanalagousが属性を提供するために追加記録に結びつけられた電話番号に名前を写像するために記録する能力の提案evisages使用は名と交際しました。
9.2. Phone number presentation
9.2. 電話番号プレゼンテーション
While FidoNet member systems perform hone book synchronization, users need only know the FidoNet address of the systems they wish to contact. As a result users do not need to maintain copies of the Nodelist on their own systems. This is similar to the Internet, where the DNS takes care of the domain name to IP address mapping, so that users do not have to remember IP addresses.
FidoNetメンバーシステムが砥石本の同期を実行している間、ユーザはそれらが連絡したがっているシステムのFidoNetアドレスを知るだけでよいです。 これはインターネットと同様です、ユーザがIPアドレスを覚えている必要はないように。その結果、ユーザはそれら自身のシステムの上でNodelistのコピーを維持する必要はありません。(そこでは、DNSがIPアドレス・マッピングまでドメイン名の世話をします)。
Nevertheless, FidoNet systems often find it useful to be able to present lists of nodes, and as a result, FidoNet Nodelist compilers typically produce a representation of the Nodelist that can be searched or displayed online, as well as one that is used by the system dialer.
それにもかかわらず、FidoNetシステムは、しばしばノードのリストを提示できるのが役に立つのがわかります、そして、その結果、FidoNet Nodelistコンパイラはオンラインで捜すか、または表示できるNodelistの表現を通常作成します、システムダイヤラーによって使用されるものと同様に。
9.2.1. FidoNet Nodelist format
9.2.1. FidoNet Nodelist形式
The FidoNet Nodelist format is documented in detail in [3]. The Nodelist file consists of lines of data as well as comment lines, which begin with a semi-colon. The first line of the Nodelist is a general interest comment line that includes the date and the day number, as well as a 16-bit CRC. The CRC is included so as to allow the system assembling the new Nodelist to verify its integrity.
FidoNet Nodelist書式は詳細に[3]に記録されます。 Nodelistファイルは注釈行と同様にデータの系列から成ります。注釈行はセミコロンで始まります。 Nodelistの最初の系列は日付と日の番号を含んでいる一般的興味注釈行です、16ビットのCRCと同様に。 CRCは、新しいNodelistを組み立てるシステムが保全について確かめるのを許容するために含まれています。
Each Nodelist data line contains eight comma separated fields:
それぞれのNodelistデータラインは8つのコンマの切り離された分野を含んでいます:
Keyword
Zone/Region/Net/Node number
Node name
Location
Sysop name
Phone number
Maximum Baud rate
Flags (optional)
キーワードZone/領域/ネット/ノード番号Node名前Location Sysop名前電話番号Maximum BaudレートFlags(任意)です。
Aboba, et. al. Informational [Page 30] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[30ページ]のRFC2194レビュー
FidoNet Nodelists are arranged geographically, with systems in the same zone, region, and network being grouped together. As a result, FidoNet Nodelists do not require a separate regions file. Among other things, the keyword field can be used to indicate that a system is temporarily out of service.
FidoNet Nodelistsはシステムで一緒に分類される同じゾーン、領域、およびネットワークで地理的にアレンジされます。 その結果、FidoNet Nodelistsは別々の領域ファイルを必要としません。 特に、システムが一時使われなくなっているのを示すのにキーワード分野を使用できます。
Reference [3] discusses Nodelist flags in considerable detail. Among other things, the flags include information on supported modem modulation and error correction protocols. Reference [4] also proposes a series of ISDN capability flags, and [5] proposes flags to indicate times of system availability.
参照[3]は詳細にかなりのNodelist旗について議論します。 特に、旗はサポートしているモデム変調とエラー訂正プロトコルの情報を含んでいます。 また、参照[4]は一連のISDN能力旗を提案します、そして、[5]はシステム稼働率の倍を示すために旗を提案します。
9.3. Phone number exchange
9.3. 電話番号交換
FidoNet coordinators are responsible for maintaining up to date information on their networks, regions, and zones. Every week network coordinators submit to their regional coordinators updated versions of their portions of the Nodelist. The regional coordinators then compile the submissions from their network coordinators, and submit them to the zone coordinator. The zone coordinators then exchange their submissions to produce the new Nodelist. As a result, it is possible that the view from different zones may differ at any given time.
FidoNetコーディネータは彼らのネットワーク、領域、およびゾーンの情報を日付まで保守するのに責任があります。 毎週、ネットワークコーディネータは彼らのNodelistの一部のアップデートされたバージョンを彼らの地方のコーディネータに提出します。 地方のコーディネータは、次に、彼らのネットワークコーディネータから差出をコンパイルして、ゾーンのコーディネータに彼らを提出します。 そして、ゾーンのコーディネータは、新しいNodelistを生産するために彼らの差出を交換します。 その結果、異なったゾーンからの視点がその時々で異なるのは、可能です。
9.3.1. The Nodediff
9.3.1. Nodediff
The format of the Nodediff is discussed in detail in [3]. In preparing the Nodediffs, network coordinators may transmit only their difference updates, which can be collated to produce the Nodediff directly.
[3]で詳細にNodediffの形式について議論します。 Nodediffsを準備する際に、ネットワークコーディネータは彼らの違いのアップデートだけを伝えるかもしれません。(直接Nodediffを生産するためにアップデートを照合できます)。
One weakness in the current approach is that there is no security applied to the coordinator submissions. This leaves oen the possibility of propagation of fraudulent updates. In order to address this, [6] proposes addition of a shared secret to the update files.
現在のアプローチにおける1つの弱点はコーディネータ差出に適用されたセキュリティが全くないということです。 これは詐欺的なアップデートの伝播の可能性にoenを残します。 これを扱うために、[6]は共有秘密キーの追加を更新ファイルに提案します。
9.3.2. Addition of nodes
9.3.2. ノードの追加
In order to apply for allocation of a FidoNet address and membership in the Nodelist, systems must demonstrate that they are functioning by sending mail to the local network coordinator. Once the local network coordinator receives the application, they then allocate a new FidoNet address, and add a Nodelist entry.
NodelistでFidoNetアドレスと会員資格の配分に申し込むために、システムは、それらが企業内情報通信網のコーディネータにメールを送ることによって機能しているのを示さなければなりません。 企業内情報通信網のコーディネータがいったんアプリケーションを受け取ると、彼らは、次に、新しいFidoNetアドレスを割り当てて、Nodelistエントリーを加えます。
Aboba, et. al. Informational [Page 31] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[31ページ]のRFC2194レビュー
9.3.3. Deletion of nodes
9.3.3. ノードの削除
Since FidoNet nodes are required to be functioning during the zone mail hour in order to receive mail, and since nodes receive the weekly Nodelist from their local network coordinators on a weekly basis, there is a built-in mechanism for discovery of non-functional nodes.
FidoNetノードがメールを受け取るためにゾーンメール時間機能していなければならなくて、ノードが彼らの企業内情報通信網のコーディネータから毎週ベースで毎週のNodelistを受けるので、非機能的なノードの発見のための内蔵のメカニズムがあります。
Nodes found to be down are reported to the local network coordinator and subsequently marked as down within the Nodelist. Nodes remaining down for more than two weeks may be removed from the Nodelist, at the discretion of the network coordinator.
下がるために見つけられたノードは、Nodelistのように企業内情報通信網のコーディネータに報告されて、次に、マークされます。 2週間以上残っているノードはNodelistから取り除かれるかもしれません、ネットワークコーディネータの裁量で。
9.4. Phone book update
9.4. 電話帳最新版
The Nodelist contains the phone numbers and associated attributes of each participating system. New Nodelists become available on Fridays, and are made available to participating systems by their local network coordinators, who in turn receive them from the regional and zone coordinators.
Nodelistはそれぞれの参加システムの電話番号と関連属性を含んでいます。 新しいNodelistsは金曜日に利用可能になって、彼らの企業内情報通信網のコーディネータで参加システムに利用可能にします。(そのコーディネータは、地方とゾーンのコーディネータから彼らを順番に受けます)。
While it is standard practice for participating systems to get their Nodelists from their local network coordinators, should the local network coordinator not be available for some reason, either the updates or the complete Nodelist may be picked up from other network, or regional coordinators. Please note that since the view from different zones may differ, nodes wishing to update their Nodelists should not contact systems from outside their zone.
参加システムが彼らの企業内情報通信網のコーディネータからそれらのNodelistsを手に入れるのが、標準的技法である間、アップデートか完全なNodelistのどちらかが企業内情報通信網のコーディネータがある理由で手があかないなら他のネットワーク、または地方のコーディネータから再開されるかもしれません。 異なったゾーンからの視点が異なるかもしれないので、それらのNodelistsをアップデートしたがっているノードはそれらのゾーンの外からシステムに連絡するはずがありません。
9.5. Phone book compilation
9.5. 電話帳編集
Once FidoNet systems have received the Nodediff, the apply it to the previous week's Nodelist in order to prepare a new Nodelist. In order to receive Nodediffs and compile the Nodelist, the following software is required:
一度、FidoNetシステムがNodediffを受けたことがある、新しいNodelistを準備するために前の週のNodelistにそれを適用してください。 Nodediffsを受けて、Nodelistをコンパイルするために、以下のソフトウェアが必要です:
A FidoNet-compatible mailer implementation, used to transfer files
A Nodelist compiler
ファイルA Nodelistコンパイラを移すのに使用されるFidoNetコンパチブル郵送者実装
One of the purposes of the Nodelist compiler is to apply Nodediffs to the previous Nodelist in order to produce an updated Nodelist. The other purpose is to compile the updated Nodelist into the format required by the particular mailer implementation used by the member system. It is important to note that while the Nodelist and Nodediff formats are standardized (FTS-0005), as is the file transfer protocol (FTS-0001), the compiled format used by each mailer is implementation dependent.
Nodelistコンパイラの目的の1つはアップデートされたNodelistを生産するために前のNodelistにNodediffsを適用することです。 もう片方の目的はメンバーシステムによって使用される特定の郵送者実装によって必要とされた形式にアップデートされたNodelistをコンパイルすることです。 NodelistとNodediff形式がファイル転送プロトコル(FTS-0001)のように標準化されますが(FTS-0005)、各郵送者によって使用されたコンパイルされた形式が実装に依存していることに注意するのは重要です。
Aboba, et. al. Informational [Page 32] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[32ページ]のRFC2194レビュー
One reason that compiled formats to differ is the addition of out of band information to the Nodelist during the compilation process. Added information includes phone call costs as well as shared secrets.
異なるように形式をコンパイルした1つの理由が追加である、編集の間のNodelistへのバンド情報で処理してください。 付記された情報は共有秘密キーと同様に電話コストを含んでいます。
9.5.1. Cost data
9.5.1. 原価資料
Although cost information is not part of the Nodelist, in compiling the Nodelist into the format used by the mailer, Nodelist compilers support the addition of cost information. This information is then subsequently used to guide mailer behavior.
コスト情報はNodelistの一部ではありませんが、郵送者によって使用された形式にNodelistをコンパイルする際に、Nodelistコンパイラはコスト情報の追加をサポートします。 そして、この情報は、次に、郵送者の振舞いを誘導するのに使用されます。
Since phone call costs depend on the rates charged by the local phone company, this information is local in nature and is typically entered into the Nodelist compiler's configuration file by the system administrator.
電話コストが地方の電話会社によって請求されたレートによるので、この情報は、現実に地方であり、システム管理者によってNodelistコンパイラの構成ファイルに通常入力されます。
9.5.2. Shared secrets
9.5.2. 共有秘密キー
In FidoNet, shared secrets are used for authenticated sessions between systems. Such authenticated sessions are particularly important between the local, regional and zone coordinators who handle preparation and transmission of the Nodediffs. A single shared secret is used per system.
FidoNetでは、共有秘密キーはシステムの間の認証されたセッションに使用されます。そのような認証されたセッションはNodediffsの準備とトランスミッションを扱う地方と、地方とゾーンのコーディネータの間で特に重要です。 ただ一つの共有秘密キーはシステム単位で使用されます。
9.6. Accounting
9.6. 会計
Within FidoNet, the need for accounting arises primarily from the need of local, regional and zone coordinators to be reimbursed for their expenses. In order to support this, utilities have been developed to account for network usage at the system level according to various metrics. However, the accounting techniques are not applied at the user level. Distributed authentication and acounting are not implemented and therefore users may not roam between systems.
FidoNetの中では、会計の必要性は、彼らの費用で還付されるために主として地方の必要性、地方とゾーンのコーディネータから起こります。 これをサポートして、様々な測定基準に従ってシステムレベルでネットワーク用法を説明するためにユーティリティを開発してあります。 しかしながら、会計技術はユーザレベルで適用されません。 分配された認証とacountingは実装されません、そして、したがって、ユーザはシステムの間を歩き回らないかもしれません。
10. Acknowledgements
10. 承認
Thanks to Glen Zorn of Microsoft and Lynn Liu and Tao Wang of AimQuest for useful discussions of this problem space.
この問題スペースの役に立つ議論をAimQuestのマイクロソフトのGlenゾルン、リンリュウ、およびタオワングをありがとうございます。
Security Considerations
セキュリティ問題
Security issues are discussed in sections 5.6 and 6.5.
セクション5.6と6.5で安全保障問題について議論します。
Aboba, et. al. Informational [Page 33] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[33ページ]のRFC2194レビュー
11. References
11. 参照
[1] Cobb, S., "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses", RFC 1877, Microsoft, December 1995.
[1] コッブ、S.、「ネームサーバアドレスのためのpppインターネットプロトコル制御プロトコル拡大」、RFC1877、マイクロソフト、1995年12月。
[2] Fielding, R., et al., "Hypertext Transfer Protocol - HTTP/1.1.", RFC 2068, UC Irvine, January, 1997.
[2] フィールディング、R.、他、「ハイパーテキストはHTTP/1.1にプロトコルを移す」、RFC2068、UCアーバイン1月、1997
[3] Baker, B., R. Moore, D. Nugent. "The Distribution Nodelist." FTS-0005, February, 1996.
[3] ベイカー、B.、R.ムーア、D.ニュージェント。 「分配Nodelist。」 1996年2月のFTS-0005。
[4] Lentz, A. "ISDN Nodelist flags." FSC-0091, June, 1996.
[4] レンツ、A.「ISDN Nodelist旗。」 1996年6月のFSC-0091。
[5] Thomas, D. J. "A Proposed Nodelist flag indicating Online Times of a Node." FSC-0062, April, 1996.
[5] D. J. トーマス、「NodeのOnlineタイムズを示すProposed Nodelist旗。」 1996年4月のFSC-0062。
[6] Kolin, L. "Security Passwords in Nodelist Update Files." FSC-0055, March, 1991.
[6] L. コリン、「Nodelist更新ファイルのセキュリティパスワード。」 1991年3月のFSC-0055。
[7] Gwinn, R., D. Dodell. "Nodelist Flag Changes Draft Document." FSC-0009, November, 1987.
[7]Gwinn、R.、D.Dodell。 「Nodelist旗の変化はドキュメントを作成します。」 1987年11月のFSC-0009。
[8] Heller, R. "A Proposal for A FidoNet Domain Name Service." FSC-0069, December, 1992.
[8] R. ヘレル、「FidoNetドメイン名サービスのための提案。」 1992年12月のFSC-0069。
[9] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2058, Livingston, Merit, Daydreamer, January 1997.
[9] RFC2058、リビングストンは、Rigney、C.、ルーベン、A.、シンプソン、W.、およびS.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」に値します、空想家、1997年1月。
[10] Rigney, C., "RADIUS Accounting", RFC 2059, Livingston, January 1997.
[10]Rigney、C.、「半径会計」、RFC2059、リビングストン1997年1月。
Aboba, et. al. Informational [Page 34] RFC 2194 Review of Roaming Implementations September 1997
et Aboba、アル。 実装1997年9月に移動する情報[34ページ]のRFC2194レビュー
12. Authors' Addresses
12. 作者のアドレス
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: 206-936-6605
EMail: bernarda@microsoft.com
以下に電話をしてください。 206-936-6605 メールしてください: bernarda@microsoft.com
Juan Lu
AimQuest Corporation
1381 McCarthy Blvd.
Milpitas, California 95035
ホアンLuエイムクエスト社1381マッカーシーBlvd. ミルピタス、カリフォルニア 95035
Phone: 408-273-2730 ext. 2762
EMail: juanlu@aimnet.net
以下に電話をしてください。 408-273-2730 ext。 2762はメールされます: juanlu@aimnet.net
John Alsop
i-Pass Alliance Inc.
650 Castro St., Suite 280
Mountain View, CA 94041
マウンテンビュー、Suite280カリフォルニア ジョンAlsop i-パス同盟株式会社650カストロ通り、94041
Phone: 415-968-2200
Fax: 415-968-2266
EMail: jalsop@ipass.com
以下に電話をしてください。 415-968-2200 Fax: 415-968-2266 メールしてください: jalsop@ipass.com
James Ding
Asiainfo
One Galleria Tower
13355 Noel Road, #1340
Dallas, TX 75240
ジェームス鐘の音Asiainfo1ガレリア塔13355のクリスマスの道路、ダラス、#1340テキサス 75240
Phone: 214-788-4141
Fax: 214-788-0729
EMail: ding@bjai.asiainfo.com
以下に電話をしてください。 214-788-4141 Fax: 214-788-0729 メールしてください: ding@bjai.asiainfo.com
Wei Wang
Merit Network, Inc.
4251 Plymouth Rd., Suite C
Ann Arbor, MI 48105-2785
ウェイワング長所ネットワークInc.4251プリマス通り、スイートCアナーバー、MI48105-2785
Phone: 313-764-2874
EMail: weiwang@merit.edu
以下に電話をしてください。 313-764-2874 メールしてください: weiwang@merit.edu
Aboba, et. al. Informational [Page 35]
et Aboba、アル。 情報[35ページ]
一覧
スポンサーリンク
