Network Working Group D. Mitton
Request for Comments: 3127 Nortel Networks
Category: Informational M. St.Johns
Rainmaker Technologies
S. Barkley
UUNET
D. Nelson
Enterasys Networks
B. Patil
Nokia
M. Stevens
Ellacoya Networks
B. Wolff
Databus Inc.
June 2001
Authentication, Authorization, and Accounting:
Protocol Evaluation
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This memo represents the process and findings of the Authentication, Authorization, and Accounting Working Group (AAA WG) panel evaluating protocols proposed against the AAA Network Access Requirements, RFC 2989. Due to time constraints of this report, this document is not as fully polished as it might have been desired. But it remains mostly in this state to document the results as presented.
このメモは、プロセスと認証の結果を示し、これによってレポートの時間的な制約へのAAAネットワークアクセス要件に対して提案プロトコル、RFC 2989.を評価する許可、およびアカウンティングのワーキンググループ（AAA WG）パネルは、この文書では、などの完全研磨ではありませんそれが望まれている可能性があります。しかし、それは、提示された結果を文書化するために、この状態では、ほとんどのまま。
Table of Contents
目次
1. Process Description . . . . . . . . . . . . . . . . . . . . . .3
1.1 WG Co-Chair's Note . . . . . . . . . . . . . . . . . . . . . .3
1.2 Chairman's Note . . . . . . . . . . . . . . . . . . . . . . . .4
1.3 Members Statements . . . . . . . . . . . . . . . . . . . . . .4
1.4 Requirements Validation Process . . . . . . . . . . . . . . . .6
1.5 Proposal Evaluation . . . . . . . . . . . . . . . . . . . . . .7
1.6 Final Recommendations Process . . . . . . . . . . . . . . . . .7
2. Protocol Proposals . . . . . . . . . . . . . . . . . . . . . . .8
3. Item Level Compliance Evaluation . . . . . . . . . . . . . . . 8
3.1 General Requirements . . . . . . . . . . . . . . . . . . . . . 9
3.2 Authentication Requirements. . . . . . . . . . . . . . . . . .11
3.3 Authorization Requirements . . . . . . . . . . . . . . . . . .12
3.4 Accounting Requirements . . . . . . . . . . . . . . . . . . .12
3.5 MOBILE IP Requirements . . . . . . . . . . . . . . . . . . . .13
4. Protocol Evaluation Summaries . . . . . . . . . . . . . . . . .14
4.1 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
4.2 Radius++ . . . . . . . . . . . . . . . . . . . . . . . . . . .14
4.3 Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . .14
4.4 COPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
4.5 Summary Recommendation . . . . . . . . . . . . . . . . . . .14
5. Security Considerations . . . . . . . . . . . . . . . . . . . .14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . .15
7. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . .15
A. Appendix A - Summary Evaluations . . . . . . . . . . . . . . .17
B. Appendix B - Review of the Requirements . . . . . . . . . . . .18
B.1 General Requirements. . . . . . . . . . . . . . . . . . . . . .18
B.2 Authentication Requirements . . . . . . . . . . . . . . . . . .19
B.3 Authorization Requirements. . . . . . . . . . . . . . . . . . .19
B.4 Accounting Requirements . . . . . . . . . . . . . . . . . . . .20
C. Appendix C - Position Briefs . . . . . . . . . . . . . . . . .21
C.1 SNMP PRO Evaluation . . . . . . . . . . . . . . . . . . . . .21
C.2 SNMP CON Evaluation . . . . . . . . . . . . . . . . . . . . .28
C.3 RADIUS+ PRO Evaluation . . . . . . . . . . . . . . . . . . . .33
C.4 RADIUS+ CON Evaluation . . . . . . . . . . . . . . . . . . . .37
C.5 Diameter PRO Evaluation . . . . . . . . . . . . . . . . . . .44
C.6 Diameter CON Evaluation . . . . . . . . . . . . . . . . . . .50
C.7 COPS PRO Evaluation . . . . . . . . . . . . . . . . . . . . .55
C.8 COPS CON Evaluation . . . . . . . . . . . . . . . . . . . . .59
D. Appendix D - Meeting Notes . . . . . . . . . . . . . . . . . .66
D.1 Minutes of 22-Jun-2000 Teleconference . . . . . . . . . . . .66
D.2 Minutes of 27-Jun-2000 Teleconference . . . . . . . . . . . .68
D.3 Minutes of 29-Jun-2000 Teleconference . . . . . . . . . . . .73
D.4 Minutes of 06-Jul-2000 Teleconference . . . . . . . . . . . .78
D.5 Minutes of 11-Jul-2000 Teleconference . . . . . . . . . . . .80
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .84
Due to time constraints, the original draft of this document was rushed to meet the publication deadline of the June 2000 Pittsburgh meeting. Since the meeting has passed, we do not wish to substantially revise the findings within this document, so that we don't give the appearance of changing information after the presentation. Only additional descriptions of the process, formatting, layout editing and errors of fact have been corrected in subsequent revisions.
時間の制約のため、この文書の原案は、2000年6月ピッツバーグ会議の公表期限を満たすために運ばれました。会議が経過しているので、我々は、プレゼンテーションの後に情報の変更の外観を与えないように、実質的に、このドキュメント内の所見を改訂したくありません。実際のプロセス、書式設定、レイアウト編集やエラーの唯一の追加記述は、その後の改訂で修正されました。
After the AAA WG re-charter was approved, and the Network Access Requirements document passed AAA WG Last Call, a Solicitation of Protocol Submissions was issued on 4/13/2000. The Solicitation was sent to the AAA WG mailing list, as well as to other IETF WG mailing lists related to AAA, including NASREQ, Mobile IP, RAP, and SNMPv3.
AAA WGの再チャーターが承認された、およびネットワークアクセスの要件文書がラストコールAAA WGを通過した後は、議定書の提出の勧誘は、2000年4月13日に発行されました。勧誘はNASREQ、モバイルIP、RAP、およびSNMPv3などのAAAに関連する他のIETF WGのメーリングリストへのと同様、AAA WGメーリングリストに送信されました。
Submissions were solicited effective immediately. Authors of candidate protocols were requested to notify the AAA WG chairs of their intent to submit a candidate protocol. It was suggested that this notification be sent by May 1, 2000.
応募は、直ちに有効に募集されました。候補プロトコルの作者が候補プロトコルを提出する意向のAAA WGいすを通知するよう要求しました。これは、この通知は2000年5月1日で送信することが示唆されました。
Protocol submissions and compliance description documents were to be submitted in Internet Draft format by email to internet-drafts@ietf.org. The deadline for submissions was June 1, 2000. To be considered as a candidate, submissions needed to include an unqualified RFC 2026 statement, as described at: http://www.ietf.org/Sec10.txt
議定書の提出やコンプライアンスの説明文書はinternet-drafts@ietf.orgに電子メールで、インターネットドラフト形式で提出されることになっていました。 http://www.ietf.org/Sec10.txt：で説明するよう提出期限は、候補とみなされるためには修飾されていないRFC 2026のステートメントを含めるために必要な提出6月1日、2000年でした
In order to assist the AAA WG in evaluating the protocol submissions and compliance description documents, the AAA WG chairs then formed an evaluation team, which was announced on May 20, 2000. The job of the team was be to put together an Internet Draft documenting their evaluation of the protocol submissions. The goal is to have a first draft available prior to the July 14, 2000 submission deadline for IETF 48.
プロトコルの提出やコンプライアンスの説明文書を評価するにはAAA WGを支援するために、AAA WGいすは、チームの仕事は一緒に文書化し、インターネットドラフトを配置することだった5月20日、2000年に発表された評価チームを結成しましたプロトコルの提出のその評価。目標は、7月14日、IETF 48 2000提出期限前に利用できる最初のドラフトを持つことです。
In composing the evaluation draft, the evaluation team was asked to draw from the protocol specifications, the compliance descriptions, and other relevant documents, the Network Access Requirements document, RFC 2989.
評価案を構成するには、評価チームは、プロトコル仕様、コンプライアンスの説明、およびその他の関連文書、ネットワークアクセスの要件の文書、RFC 2989から描くように頼まれました。
Mike St. Johns was asked to chair the evaluation team. The chairs of WGs related to AAA were also invited to join the team. These included Dave Mitton, co-chair of NASREQ WG, Basavaraj Patil, co-chair of Mobile IP WG, and Mark Stevens, co-chair of the RAP WG.
マイク・セントジョンズは、椅子に評価チームを頼まれました。 AAAに関連のWGの議長はまた、チームに参加するために招待されました。これらは、デイブ・ミトン、NASREQ WGの共同議長、Basavarajパティル、モバイルIP WGの共同議長、およびマーク・スティーブンス、RAP WGの共同議長を含みます。
Additional members of the evaluation team were chosen to represent the interests of network operators as well as developers of AAA client and server software.
評価チームの追加メンバーは、AAAクライアントとサーバソフトウェアのネットワーク事業者の利益だけでなく、開発者が代表に選ばれました。
As usual, the IESG advised the evaluation team. IESG advisors included Randy Bush and Bert Wijnen, Directors of the Operations and Management Area.
いつものように、IESGは、評価チームを助言しました。 IESGアドバイザーはランディブッシュとバートWijnen、オペレーションの取締役および管理領域が含まれています。
This document is the result of 6 weeks of intense work by the panel listed below. Our mission was to evaluate the various AAA proposals and provide recommendations to the AAA working group and to the IESG on the viability of each of the proposals.
この文書では、下記のパネルによって激しい仕事の6週間の結果です。私たちの使命は、様々なAAAの提案を評価し、提案のそれぞれの生存能力にAAAワーキンググループへとIESGへの勧告を提供することでした。
The evaluation process had three distinct phases. 1) Validate the AAA requirements document [AAAReqts] against the base requirements documents for NASREQ, MOBILEIP and ROAMOPS. 2) Evaluate each of the SNMP, Radius++, Diameter and COPS proposal claims against the validated requirements. 3) Provide final recommendations based on side by side comparison for each proposal on a requirement by requirement basis.
評価プロセスは、3つの異なるフェーズを持っていました。 1）[AAAReqts] NASREQ、MOBILEIPとROAMOPSための基本要件文書に対するAAA要件ドキュメントを検証。 2）SNMP、半径++の各々を評価し、検証要求に対する直径とCOPS提案クレーム。 3）要件ごとの要件の各提案のための側の比較により側に基づいて最終的な推奨事項を提供。
In general, the ONLY information the evaluators were allowed to use throughout the process was that provided in the source documents (the requirements document and the proposal) or documents referenced by the source documents. In other words, if it wasn't written down, it generally didn't exist. Our cutoff for acceptance of information was 1 June 2000 - any submissions after that time were not considered in the panel's deliberations.
一般的に、評価者は、プロセス全体で使用することを許された唯一の情報は、ソースドキュメントが参照するソースドキュメント（要件ドキュメントと提案）または文書に提供したことでした。それはダウン書かれていなかった場合は、他の言葉で、それは一般的に存在しませんでした。情報の受け入れのための私達のカットオフは2000年6月1日だった - その時の後に任意の提出は、パネルの審議に考慮されませんでした。
The group was chaired by Michael St.Johns. David Mitton was the document editor. Following are the background statements and any conflicts of interest from them and the rest of the panel.
グループは、マイケル・St.Johnsが議長を務めました。デヴィッド・ミトンは、文書エディタでした。背景文およびそれらからの関心の任意の競合やパネルの残りの部分は次のとおりです。
Michael St. Johns, Rainmaker Technologies
マイケル・セントジョンズ、レインメーカー・テクノロジーズ
I have no known conflicts of interest with respect to the AAA process. I have neither advocated nor participated in the creation of any of the submissions. My company is a service company (ISP) and will not be involved in the manufacture or sale of AAA enabled products. Other than my participation as the chair of the AAA evaluation process, I have not had any contact with the AAA standards process.
私は、AAAプロセスに関して興味のある既知の競合を持っていません。私はどちらも提唱していないにも提出のいずれかの作成に参加しました。私の会社は、サービス会社（ISP）であるとAAA対応製品の製造や販売に関与することはありません。 AAA評価プロセスの議長としての私の参加以外にも、私はAAAの標準化プロセスとの接触を持っていませんでした。
David Mitton, Nortel Networks
デイビット・ミットン、ノーテルネットワークス
I have been Nasreq WG co-chair and author of several Nasreq drafts. As well as, previously contributed to several RADIUS drafts.
私はいくつかのNASREQドラフトのNASREQ WGの共同議長と著者となっています。同様に、あらかじめいくつかのRADIUSドラフトに貢献しました。
I have been a RADIUS NAS implementor and Technical Prime on our Server products, so know it extremely well. In my current job role I am involved with Nortel's IP Mobility products, which support Diameter.
私は、私たちのサーバー製品にRADIUS NASの実装と技術総理となって、その非常によくそれを知っています。私の現在の仕事の役割の中で、私は、DiameterをサポートするNortelのIPモビリティ製品と関わっています。
I have written a presentation on COPS vs NASreq Requirements for a Nasreq meeting, but have not implemented it, nor consider myself an through expert on the subject.
私はNASREQ会議のNASREQ要件対COPSについてのプレゼンテーションを書かれているが、それを実装していない、また主題の専門家を通じて自分自身を検討してください。
Stuart Barkley, UUNET
スチュアートバークリー、UUNET
I've been working for 5 years at UUNET on various parts of our dialup network. I have extensive experience with designing, developing and operating our SNMP based usage data gathering system. I've also been involved in our radius based authentication and authorization systems in an advisory position.
私は、私たちのダイヤルアップネットワークのさまざまな部分にUUNETで5年間働いてきました。私が開発し、当社のSNMPベースの利用状況データ収集システムを操作、設計と豊富な経験を持っています。私はまた、顧問の位置に私達の半径ベースの認証と認可のシステムに関わってきました。
I've participated in radius/roamops/nasreq/aaa groups for the past several years. I'm not an author or contributer on any of the requirements or protocol documents being presented although I have been peripherally involved in these working groups.
私は過去数年間、半径/ ROAMOPS / NASREQ / AAAのグループに参加してきました。私は私が末梢これらのワーキンググループに関与してきたが、提示されている要件やプロトコルドキュメントのいずれかの上の著者やcontributerありませんよ。
Dave Nelson, Enterasys Networks
デイヴ・ネルソン、エンテラシス・ネットワーク
Very active in the RADIUS WG, especially during the early years. No involvement in the AAA submission. Have not contributed to the development of Diameter.
特に初期の年の間に、RADIUS WGに大活躍。 AAAの提出でNO関与しません。直径の発展に貢献していません。
No involvement with SNMPv3 or the AAA submission. David Harrington, a proponent, works in a different group within my company. We have not discussed the submission. No involvement with the COPS protocol.
SNMPv3のと関与しないか、AAAの提出なし。デヴィッド・ハリントン、提案者は、私の会社内の異なるグループに所属しています。私たちは、提出を検討していません。 COPSプロトコルませ関与しません。
Basavaraj Patil, Nokia
Basavarajパティル、ノキア
I am a contributor to the AAA requirements document (RFC 2977) submitted by the Mobile IP WG. I was a member of the team that was constituted to capture the Mobile IP requirements for AAA services.
私は、モバイルIP WGから提出されたAAA要件ドキュメント（RFC 2977）に貢献しています。私はAAAサービスのためのモバイルIPの要件をキャプチャするために構成されたチームのメンバーでした。
As part of the co-chairing activity of the Mobile IP WG I have realized the need for AAA services by Mobile IP and hence closely followed the work done in the AAA WG, RADIUS, RoamOps and TR45.6.
モバイルIP WGの共同議長の活動の一環として、私は、モバイルIPによるAAAサービスの必要性を実現し、ひいては密接AAA WG、RADIUS、ROAMOPSとTR45.6で行われた作業に従っています。
My present work at Nokia does involve looking at AAA protocols (to some extent at least) for use in wireless networks. I have also done some work with AAA protocols such as Diameter in my previous job at Nortel Networks.
ノキアでの私の本研究では、ワイヤレスネットワークでの使用のために（少なくともある程度まで）AAAプロトコルを見て関与しません。私はまた、このようなノーテルネットワークスで私の前の仕事に直径としてAAAプロトコルといくつかの作業を行っています。
Mark Stevens, Ellacoya Networks
マーク・スティーブンス、Ellacoya Networksの
I am the co-chair of the IETF RAP working group which is the working group that has developed the COPS protocol. I have not contributed to the documents describing how COPS can satisfy AAA requirements.
私はCOPSプロトコルを開発したワーキンググループであるIETF RAPワーキンググループの共同議長ています。私はCOPSは、AAAの要件を満たすことができる方法を説明した文書に貢献していません。
I participated in early AAA working group meetings, but have not been an active participant since the group's rechartering. The company that currently employees me builds devices might benefit from being AAA enabled.
私は初期のAAAワーキンググループの会合に参加したが、グループのrechartering以来、積極的に参加していませんでした。現在の従業員は私のデバイスはAAAが有効にされることから恩恵を受ける可能性が構築する会社。
Barney Wolff, Databus Inc.
バーニー・ウルフ、データバス株式会社
I have implemented RADIUS client, proxy and server software, under contract to AT&T. That software is owned by AT&T and I have no financial interest in it.
私はAT＆Tとの契約に基づき、RADIUSクライアント、プロキシおよびサーバソフトウェアを実装しています。そのソフトウェアは、AT＆Tが所有していると私はそれには経済的利害関係を持っていません。
I have been a member of the RADIUS WG for several years, and consider myself an advocate for RADIUS against what I consider unjustified attacks on it.
私は数年前からRADIUS WGのメンバーとなって、そして自分自身に、私はそれに不当な攻撃を考えるものに対するRADIUSのための擁護者を検討しています。
I've never worked for any of the companies whose staff have produced any of the proposals, although I obviously might at some future time.
私は、そのスタッフが、私は明らかにいくつかの将来の時点でかもしれませんが、提案のいずれかを生産している企業のいずれかのために働いたことがありません。
For each of the base requirements documents, the chair assigned a team member to re-validate the requirement. The process was fairly mechanical; the evaluator looked at what was said in [AAAReqts], and verified that the references and supporting text in the basis document supported the requirement in [AAAReqts] as stated. Where the reference was wrong, too general, missing or otherwise did not support the requirement, the evaluator either deleted or downgraded the requirement. The results of that process were sent to the AAA mailing list and are also included in this document in the appendixes. The group's used [AAAReqts] as modified by our validation findings to evaluate the AAA proposals.
基本要件文書のそれぞれについて、議長は、要件を再検証するためにチームメンバーを割り当てます。プロセスはかなりの機械でした。評価者は、[AAAReqts]に言われたことを見て、と述べたように基礎文書の参照とサポートテキストは[AAAReqts]で要件をサポートすることを確認しました。参照が間違っていた場合には、あまりにも一般的な、存在しないか、またはそれ以外のことは要件をサポートしていませんでした、評価者は、いずれかの削除または要件を格下げ。そのプロセスの結果は、AAAのメーリングリストに送られたとも付録では、この文書に含まれています。 AAAの提案を評価するために、私たちの検証の結果によって変更されたグループの[AAAReqts]使用。
For each of the four proposals, the chair assigned two panel members to write evaluation briefs. One member was assigned to write a 'PRO' brief and could take the most generous interpretation of the proposal; he could grant benefit of doubt. The other member was assigned to write a 'CON' brief and was required to use the strictest criteria when doing his evaluation.
4つの案のそれぞれについて、議長は、評価ブリーフを書くために2人のパネルメンバーを割り当て。一つのメンバーは、「PRO」簡単に書くために割り当てられていたとの提案の最も寛大な解釈を取ることができます。彼は疑いの利益を与えることができます。他のメンバーは「CON」簡潔に書くために割り当てられていたし、彼の評価を行う際に最も厳しい基準を使用する必要がありました。
Each brief looked at each individual requirement and evaluated how close the proposal came in meeting that requirement. Each item was scored as one of an 'F' for failed to meet the requirement, 'P' for partially meeting the requirement, or 'T' for totally meeting the requirement. The proposals were scored only on the information presented. This means that a particular protocol might actually meet the specifics of a requirement, but if the proposal did not state, describe or reference how that requirement was met, in might be scored lower.
各簡潔には、個々の要件を見て、提案がその要件を満たすに来てどれだけ近いかを評価しました。各項目は、部分的に完全な要件を満たすための要件、または「T」を満たすための要件を満たすことができなかった、「P」の「F」のひとつとしてスコア化しました。提案はのみ提示された情報に採点しました。これは、特定のプロトコルが実際に要件の仕様を満たしていますが、提案は述べるなかった場合は下の得点される可能性がありますで、その要件が満たされたかを説明したり、参照可能性があることを意味します。
The panel met by teleconference to discuss each proposal and the PRO and CON briefs. Each of the briefers discussed the high points of the brief and gave his summary findings for the proposal. We then discussed each individual requirement line-by-line as a group. At the conclusion, the members provided their own line-by-line evaluations which were used to determine the consensus evaluation for the specific requirement relative to that proposal. The meeting notes from those teleconferences as well as the individual briefs are included in the appendixes.
パネルには、各提案とPROとCONブリーフを議論する会議で会いました。 briefersのそれぞれは、簡単の高いポイントを議論し、提案のための彼の要約の調査結果を与えました。我々は、グループとして、各個々の要件ライン・バイ・ラインについて議論しました。最後に、メンバーはその提案に対する特定の要件のコンセンサスの評価を決定するために使用された、独自のライン・バイ・ラインの評価を与えました。これらの電話会議だけでなく、個々のブリーフから会議メモは付録に含まれています。
The panel met for one last time to compare the results for the four proposals and to ensure we'd used consistent evaluation criteria. We did a requirement by requirement discussion, then a discussion of each of the protocols.
パネルには4つの提案の結果を比較するために、我々は一貫性のある評価基準を使用したいことを確認するために、1つの最後の時間のために会いました。私たちは、プロトコルのそれぞれの議論、その後、要件の議論により、要件をしました。
The final phase was for each member to provide his final summary evaluation for each of the protocols. Each proposal was scored as either Not Acceptable, Acceptable Only For Accounting, Acceptable with Engineering and Fully Acceptable. Where a proposal was acceptable with engineering, the member indicated whether it would be a small, medium or large amount.
最終段階は、プロトコルごとに彼の最後の概要評価を提供するために、各メンバーのためでした。各提案はどちらか、アカウンティングのみ許容、許容エンジニアリングでも許容されると完全に受け入れられないとして採点しました。提案は、エンジニアリングと受け入れられた場合、会員は、小規模、中規模または大規模な量であるかどうかを示します。
It should be noted that score indicated the opinion of the team member. And they may have taken into consideration background knowledge or additional issues not captured in the minutes presented here.
スコアがチームメンバーの意見を示したことに留意すべきです。そして、彼らはここで紹介する分に入力されていません対価の背景知識やその他の問題に入れている可能性があります。
Each member's scores were used within the group to develop the group's consensus.
各メンバーのスコアは、グループのコンセンサスを開発するためにグループ内で使用されました。
The following proposal documents were submitted to the AAA WG for consideration by the deadline.
次の提案書は、期限までに検討のためAAA WGに提出されました。
- SNMP:
- SNMP：
[SNMPComp] "Comparison of SNMPv3 Against AAA Network Access Requirements", Work in Progress.
[SNMPComp]「のSNMPv3に対するAAAネットワークアクセス要件の比較」が進行中で働いています。
- RADIUS Enhancements:
- RADIUS機能の強化：
[RADComp] "Comparison of RADIUS Against AAA Network Access Requirements", Work in Progress.
[RADComp]「RADIUSに対するAAAネットワークアクセス要件の比較」が進行中で働いています。
[RADExt] "Framework for the extension of the RADIUS(v2) protocol", Work in Progress.
【RADExt「RADIUS（V2）プロトコルの拡張のためのフレームワーク」、ProgressのWork。
- Diameter
- 直径
[DIAComp] "Comparison of Diameter Against AAA Network Access Requirements", Work in Progress.
[DIAComp]「AAAネットワークアクセス要件に対する直径の比較」が進行中で働いています。
- COPS for AAA:
- AAAのためのCOPS：
[COPSComp] "Comparison of COPS Against the AAA NA Requirements", Work in Progress.
[COPSComp]「AAA NA要件に対するCOPSの比較」が進行中で働いています。
[COPSAAA] "COPS Usage for AAA", Work in Progress.
[COPSAAA]、進行中の作業 "AAAの使用上のCOPS"。
For each requirement item, the group reviewed the proposal's level of compliance. Where the proposal was lacking, the evaluators may have made supposition on how hard it would be to resolve the problem. The following shows the consensus results for each requirement item.
各要求項目について、グループは、コンプライアンスの提案のレベルを検討しました。提案が欠けていた場合、評価者は、それが問題を解決することですいかに難しいかの仮定を行っている可能性があります。以下に、各要求項目についてのコンセンサス結果を示しています。
Key: T = Total Compliance, Meets all requirements fully P = Partial Compliance, Meets some requirements F = Failed Compliance, Does not meet requirements acceptably
キー：T =総コンプライアンスは、許容可能な要件を満たしていない、完全にはP =部分的なコンプライアンスは、Fは、コンプライアンスを失敗しました。=いくつかの要件を満たしているすべての要件を満たしています
Where two are shown eg: P/T, there was a tie.
2が示されている場合例：P / T、ネクタイがありました。
The sub-section numbering corresponds to the requirements document section and item numbers. This relative numbering was also used in the Protocol Position presentations, here in the appendices.
サブセクション番号は、要件ドキュメントセクションと項目番号に対応します。この相対的なナンバリングも付録にここで、プロトコルポジションのプレゼンテーションで使用されました。
SNMP was downgraded due to a lack of detail of how the current agent model would be adapted to a client request based transaction. The RADIUS proposal did not address the problem adequately. There are open issues in all proposals with respect to webs of proxies.
SNMPは、電流エージェントモデルは、クライアントの要求に基づく取引に適用される方法の詳細の欠如に格下げされました。 RADIUSの提案は適切に問題を解決しませんでした。プロキシのウェブに関する全ての提案で開いて問題があります。
The group particularly noted that it didn't think any protocol did well in this requirement. Insufficient work has been done to specify link failure detection and primary server recovery in most submissions. COPS has some mechanisms but not all. How these mechanisms would work in a web of proxies has not been addressed.
グループは、特にそれがどのプロトコルがこの要件によくやったとは思いませんでしたことを指摘しました。不十分な作業は、ほとんどの提出にリンク障害検出およびプライマリサーバの復旧を指定するために行われてきました。 COPSは、いくつかのメカニズムではなく、すべてを持っています。これらのメカニズムは、プロキシのウェブに働くだろうどのように対処されていません。
Many of the submissions missed the point of the requirement. There should be a way for the peers to authenticate each other, end-to-end, or user-to-server. However, the group questions who really needs this feature, and if it could be done at a different level.
応募の多くは、要件のポイントを逃しました。ピアが互いを認証するための方法、エンド・ツー・エンド、またはユーザとサーバがあるはずです。しかし、実際にこの機能を必要とし、それは別のレベルで行うことができれば、グループの質問。
Mutual authentication in RADIUS is only between hops.
RADIUSでの相互認証は、唯一のホップの間にあります。
3.1.4 Transmission Level Security - SNMP:T, RADIUS:P, Diameter:T, COPS:T
3.1.4トランスミッションレベルセキュリティ - SNMP：T、RADIUS：P、直径：T、COPS：T
All protocols have methods of securing the message data.
すべてのプロトコルは、メッセージデータを確保する方法があります。
3.1.5 Data Object Confidentiality - SNMP:P, RADIUS:P, Diameter:T, COPS:T
3.1.5データ・オブジェクトの機密性 - SNMP：P、RADIUS：P、直径：T、COPS：T
This requirement usually comes from third-party situations, such as access outsourcing.
この要件は、通常、このようなアクセスのアウトソーシングなど、サードパーティの状況から来ています。
Diameter and COPS both use CMS formats to secure data objects. The group is concerned if this method and it's support is perhaps too heavy weight for NAS and some types of edge systems.
直径とCOPSの両方のデータ・オブジェクトを確保するためにCMS形式を使用します。この方法およびそれのサポートはおそらくNASとエッジシステムのいくつかのタイプの重すぎる重量であればグループが懸念されます。
How to guard the data object from changes was not adequately described in the SNMP proposal. The RADIUS solution was not very strong either.
どのように変更からデータオブジェクトを守るためには、適切にSNMPの提案で説明されていません。 RADIUSソリューションは、いずれかの非常に強力ではなかったです。
All protocols can figure out some way to transport a certificate.
すべてのプロトコルは、証明書を輸送するいくつかの方法を見つけ出すことができます。
The requirement does not give a definition of "how reliable" it must be.
要件は、「どのように信頼性」でなければならないの定義を与えるものではありません。
The SNMP and RADIUS proposals lacked in providing solutions to message retransmission and recovery.
SNMPとRADIUS提案はメッセージの再送信と回復へのソリューションを提供して欠けていました。
The SNMP proposal indicated that this area is still in the experimental stages.
SNMPの提案は、この領域は、実験的な段階にまだあることを示しています。
3.1.11 Support Proxy and Routing Brokers - SNMP:F, RADIUS:P, Diameter:T, COPS:P
3.1.11サポートプロキシとルーティングブローカー - SNMP：F、RADIUS：P、直径：T、COPS：P
The SNMP proposal did not address this requirement. COPS claims support, but does not work through some of the issues. Diameter was the only protocol that attempted to address this area to a fair extent.
SNMPの提案は、この要件に対応していませんでした。 COPSはサポートを主張するが、問題のいくつかを介して動作しません。直径が公正な範囲で、このエリアに対処しようとした唯一のプロトコルでした。
We treated this requirement as something like "non-repudiation". There is a concern that digital signatures may be too computationally expensive for some equipment, and not well deployed on those platforms.
私たちは、「否認防止」のようなものとして、この要件を処理しました。デジタル署名は、いくつかの機器のためにあまりにも計算コストが高い、ともこれらのプラットフォームで展開されていないことが懸念されます。
The SNMP and RADIUS proposals did not attempt to work this requirement. COPS suggests that a History PIB will help solve this problem but gives no description.
SNMPとRADIUS提案は、この要件を仕事にしようとしませんでした。 COPSは歴史PIBは、この問題を解決するのに役立つだろうことを示唆しているが、何の説明を与えません。
3.1.13 Shared Secret Not Required - SNMP:P/T, RADIUS:T, Diameter:T, COPS:T
3.1.13共有秘密必須ではありません - SNMP：P / T、RADIUS：T、直径：T、COPS：T
The requirement is interpreted to mean that any application level security can be turned off in the presence of transport level security.
要件は、任意のアプリケーションレベルのセキュリティは、トランスポートレベルのセキュリティの存在下でオフにすることができることを意味すると解釈されます。
Pretty much every protocol can use an enveloping secure transport that would allow them not to use an internal secret.
ほとんどすべてのプロトコルは、彼らが内部の秘密を使用しないようにできるようになる包む安全な輸送を使用することができます。
3.1.14 Ability to Carry Service Specific Attributes - SNMP:T, RADIUS:T, Diameter:T, COPS:T
T、RADIUS：T、直径：T、COPS：T SNMP - サービス固有の属性を運ぶために3.1.14能力
3.2.4 PAP/Clear-text Passwords - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.2.4 PAP /クリアテキストのパスワード - SNMP：T、RADIUS：T、直径：T、COPS：T
The requirement for clear-text passwords comes from one-time-password systems and hard-token (SecurID) systems.
クリアテキストのパスワードの要件は、ワンタイムパスワードシステムとハードトークン（SecurIDの）システムから来ています。
3.2.5 Reauthentication on demand - SNMP:T, RADIUS:P, Diameter:P, COPS:T
3.2.5再認証要求に応じて - SNMP：T、RADIUS：P、直径：P、COPS：T
To supply this, the proposal must have asynchronous peer-to-peer capabilities, and there must defined operation for such state changes.
これを供給するために、提案は、非同期のピア・ツー・ピアの能力を持っている必要があり、そのような状態変化のための操作が定義されなければなりません。
We also distinguished event-driven Reauthentication from timer-driven (or lifetime-driven). Also concerned about how this would work in a proxy environment.
我々はまた、から、イベント駆動型の再認証を区別タイマー駆動型（または寿命ドリブン）。また、これは、プロキシ環境でどのように動作するかを懸念。
3.2.6 Authorization w/o Authentication - SNMP:P, RADIUS:T/P, Diameter:T, COPS:T
/ O認証W 3.2.6承認 - SNMP：P、RADIUS：T / P、直径：T、COPS：T
This requirement really means authorization with trivial authentications (e.g. by assertion or knowledge).
この要件は、本当に些細な認証（例えば、アサーションや知識による）との承認を意味します。
3.3.1 Static and Dynamic IP Addr Assignment - SNMP:P/F, RADIUS:T, Diameter:T, COPS:T
3.3.1静的および動的IP ADDR割り当て - SNMP：P / F、RADIUS：T、直径：T、COPS：T
There is difficulty in interpreting what is static or dynamic with respect to the viewpoint of the client, server, administrator or user.
クライアント、サーバ、管理者やユーザーの視点に関しては、静的または動的であるものを解釈することは困難です。
3.3.2 RADIUS Gateway Capability - SNMP:P, RADIUS:P, Diameter:T/P, COPS:P
3.3.2 RADIUSゲートウェイ機能 - SNMP：P、RADIUS：P、直径：T / P、COPS：P
It was noted that any new capability in a new AAA protocol would not be able to map directly back to RADIUS. But this is already a problem within a RADIUS environment.
これは、新しいAAAプロトコルのいずれかの新機能が直接バックRADIUSにマッピングすることはできないだろうと指摘しました。しかし、これは、すでにRADIUS環境内の問題です。
3.3.4 Preclude Layer 2 Tunneling - SNMP:F, RADIUS:T, Diameter:T, COPS:T
3.3.4排除して、レイヤ2トンネリング - SNMP：F、RADIUS：T、直径：T、COPS：T
3.3.5 Reauthorization on Demand - SNMP:P/F, RADIUS:P, Diameter:T/P, COPS:T
3.3.5オンデマンド再承認 - SNMP：P / F、RADIUS：P、直径：T / P、COPS：T
Some evaluators wondered how the server will know that re-authorization is supposed to be done? Will it interface to something external, or have sufficient internals?
いくつかの評価者は、サーバーが再認証が行われることになっていることを知っているだろうかと思いましたか？それは外部の何かへのインタフェース、または十分な内部を持っているのだろうか？
3.3.6 Support for Access Rules & Filters - SNMP:P, RADIUS:P, Diameter:P, COPS:T/P
アクセスルール＆フィルタの3.3.6のサポート - SNMP：P、RADIUS：P、直径：P、COPS：T / P
Only the Diameter proposal actually tackled this issue, but the group felt that the rules as designed were too weak to be useful. There was also concern about standardizing syntax without defining semantics.
直径のみの提案は、実際にこの問題に取り組んが、グループは設計どおりのルールが有用であるには余りにも弱いと感じました。セマンティクスを定義せずに構文を標準化する懸念もありました。
All of the protocols were weak to non-existent on specifying how this would be done in a web of proxies situation.
プロトコルのすべてが、これはプロキシの状況をウェブで行われるだろうかを指定するには、存在しないに低調に推移しました。
3.4.2 Mandatory Compact Encoding - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.4.2必須コンパクトエンコーディング - SNMP：T、RADIUS：T、直径：T、COPS：T
3.4.3 Accounting Record Extensibility - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.4.3アカウンティングレコード拡張 - SNMP：T、RADIUS：T、直径：T、COPS：T
Some members of the group are not sure how this fits into the rest of the AAA protocol, which is primarily real-time and event driven. Would this be better met with FTP?
グループの一部のメンバーが、これは主に、駆動リアルタイムおよびイベントであるAAAプロトコルの残りにどのように適合するか確認されていません。これは、FTPと会った方が良いでしょうか？
3.4.6 Accounting Timestamps - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.4.6会計タイムスタンプ - SNMP：T、RADIUS：T、直径：T、COPS：T
3.5.1 Encoding of MOBILE IP Registration Messages - SNMP:T, RADIUS:T/P, Diameter:T, COPS:T
モバイルIP登録メッセージの3.5.1エンコーディング - SNMP：T、RADIUS：T / P、直径：T、COPS：T
There was considerable discussion about what it means to be "firewall friendly". It was suggested that not making the firewall look into packets much beyond the application port number. Protocols such as SNMP and COPS are at a disadvantage, as you must look far into the packet to understand the intended operation. Diameter will have the disadvantage of SCTP, which is not well deployed or recognized at the moment.
それは「ファイアウォールに優しい」ことを意味するものについてはかなりの議論がありました。これは、多くのアプリケーションのポート番号を超えたパケットにファイアウォールの外観をしていないことが示唆されました。あなたが意図した動作を理解するために、パケットに遠くを見なければならないようなSNMPとCOPSなどのプロトコルは、不利な立場にあります。直径がうまく展開したり、現時点では認識されないSCTP、という欠点を持っています。
SNMP and COPS also have the problem that they are used for other types of operations than just AAA.
SNMPとCOPSはまた、彼らは単にAAA以外の操作の他のタイプのために使用されている問題を抱えています。
Should firewalls have AAA Proxy engines?
ファイアウォールは、AAAプロキシエンジンを持っているべきですか？
We didn't look at "NAT friendly" issues either.
私たちは、いずれかの「NATに優しい」の問題を見ていませんでした。
COPS:T
COPS：T
The group is not clear on how this requirement impacts the actual protocol. Raj explained it to us, but we mostly took it on faith.
グループは、どのようにこの要件の影響実際のプロトコル上の明確ではありません。ラジは、私たちにそれを説明したが、我々はほとんど信仰にそれを取りました。
SNMP is generally not acceptable as a general AAA protocol. There may be some utility in its use for accounting, but the amount of engineering to turn it into a viable A&A protocol argues against further consideration.
SNMPは、一般的に、一般的なAAAプロトコルとして許容されません。そこ会計のための使用でいくつかの有用性かもしれないが、エンジニアリングの量は、実行可能なA＆さらに検討に対して主張しているプロトコルにそれを回すために。
Radius++ is not considered acceptable as an AAA protocol. There is a fairly substantial amount of engineering required to make it meet all requirements, and that engineering would most likely result in something close to the functionality of Diameter.
半径++は、AAAプロトコルとして許容されるとは見なされません。そこには、すべての要件を満たすために必要なエンジニアリングのかなりかなりの量があり、その技術は、Diameterの機能に近いものの中で最も可能性の高い結果となります。
Diameter is considered acceptable as an AAA protocol. There is some minor engineering required to bring it into complete compliance with the requirements but well within short term capabilities. Diameter might also benefit from the inclusion of a broader data model ala COPS.
直径は、AAAプロトコルとして許容されると考えられます。要件に完全に準拠さが、うまく短期の能力の範囲内でそれを持って来るために必要ないくつかのマイナーなエンジニアリングがあります。直径もCOPS ALAより広範なデータモデルを含めることの恩恵を受ける可能性があります。
COPS is considered acceptable as an AAA protocol. There is some minor to medium engineering required to bring it into complete compliance with the requirements.
COPSは、AAAプロトコルとして許容されると考えられます。要件に完全準拠にそれを持って来るために必要なメディアエンジニアリングのいくつかのマイナーがあります。
The panel expresses a slight preference for Diameter based on the perception that the work for Diameter is further along than for COPS. However, using SCTP as the transport mechanism for Diameter places SCTP on the critical path for Diameter. This may ultimately result in COPS being a faster approach if SCTP is delayed in any way.
パネルは、直径の作業がさらにCOPSよりも沿っているという認識に基づいて直径がわずかな優先を表します。しかし、直径のためのトランスポートメカニズムとしてSCTPを使用すると、直径のためのクリティカルパス上のSCTPを配置します。 SCTPは、どのような方法で遅延した場合、これは最終的にはより高速なアプローチであることCOPSをもたらすことができます。
AAA protocols enforce the security of access to the Internet. The design of these protocols and this evaluation process took many security requirements as critical issues for evaluation. A candidate protocol must meet the security requirements as documented, and must be engineered and reviewed properly as developed and deployed.
AAAプロトコルは、インターネットへのアクセスのセキュリティを強化します。これらのプロトコルの設計とその評価プロセスは、評価のための重要な問題として、多くのセキュリティ要件を取りました。候補プロトコルを開発し、展開として適切に文書化、および設計されている必要があり、レビューなどのセキュリティ要件を満たす必要があります。
[AAAReqts] Aboba, B., Clahoun, P., Glass, S., Hiller, T., McCann, P., Shiino, H., Walsh, P., Zorn, G., Dommety, G., Perkins, C., Patil, B., Mitton, D., Manning, S., Beadles, M., Chen, X., Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu, R., Koo, H., Lipford, M., Campbell, E., Xu, Y., Baba, S. and E. Jaques, "Criteria for Evaluating AAA Protocols for Network Access", RFC 2989, April 2000.
【AAAReqts] Aboba、B.、Clahoun、P.、ガラス、S.、ヒラー、T.、マッキャン、P.、椎野、H.、ウォルシュ、P.、ゾルン、G.、Dommety、G.、パーキンス、 C.、パティル、B.、ミットン、D.、マニング、S.、Beadles、M.、チェン、X.、Sivalingham、S.、ハミード、A.、マンソン、M.、ジェイコブス、S.、リム、 B.、ハーシュマン、B.、スー、R.、クー、H.、Lipford、M.、キャンベル、E.、徐、Y.、馬場、S.及びE.・ジャック、「ネットワークのAAAプロトコルを評価するための基準アクセス」、RFC 2989、2000年4月。
[AAAComp] Ekstein, TJoens, Sales and Paridaens, "AAA Protocols: Comparison between RADIUS, Diameter and COPS", Work in Progress.
【AAAComp] Ekstein、TJoens、販売およびParidaens、 "AAAプロトコル：RADIUS、直径とCOPSの比較"、ProgressのWork。
[SNMPComp] Natale, "Comparison of SNMPv3 Against AAA Network Access Requirements", Work in Progress.
[SNMPComp]ナターレ、進行中で働いて「SNMPv3の反対AAAネットワークアクセス要件の比較」。
[RADComp] TJoens and DeVries, "Comparison of RADIUS Against AAA Network Access Requirements", Work in Progress.
[RADComp] TJoensと、進行中の作業DeVries、「RADIUS AAAネットワークアクセス要件に対するの比較」。
[RADExt] TJoens, Ekstein and DeVries, "Framework for the extension of the RADIUS (v2) protocol", Work in Progress,
【RADExt] TJoens、EksteinおよびDeVries、 "RADIUS（V2）プロトコルの拡張のためのフレームワーク"、進行中で働いて、
[DIAComp] Calhoun, "Comparison of Diameter Against AAA Network Access Requirements", Work in Progress.
[DIAComp]カルフーン、「AAAネットワークアクセス要件に対する直径の比較」が進行中で働いています。
[COPSComp] Khosravi, Durham and Walker, "Comparison of COPS Against the AAA NA Requirements", Work in Progress.
[COPSComp] Khosravi、ダラムとウォーカー、「AAA NA要件に対するCOPSの比較」が進行中で働いています。
[COPSAAA] Durham, Khosravi, Weiss and Filename, "COPS Usage for AAA", Work in Progress.
【COPSAAA]ダラム、Khosravi、ワイスとファイル名は、「AAAのための使用をCOPS」、進行中の作業。
David Mitton Nortel Networks 880 Technology Park Drive Billerica, MA 01821
デヴィッド・ミトンNortel Networksの880テクノロジーパークドライブビレリカ、MA 01821
Phone: 978-288-4570 EMail: dmitton@nortelnetworks.com
電話：978-288-4570 Eメール：dmitton@nortelnetworks.com
Michael StJohns Rainmaker Technologies 19050 Pruneridge Ave, Suite 150 Cupertino, CA 95014
マイケルStJohnsレインメーカー・テクノロジーズ19050 Pruneridgeアベニュー、スイート150クパチーノ、CA 95014
Phone: 408-861-9550 x5735 EMail: stjohns@rainmakertechnologies.com
電話番号：408-861-9550 x5735メール：stjohns@rainmakertechnologies.com
Stuart Barkley UUNET F1-1-612 22001 Loudoun County Parkway Ashburn, VA 20147 US
スチュアートバークリーUUNET F1-1-612 22001ラウドン郡パークウェイアッシュバーン、バージニア州20147米国
Phone: 703-886-5645 EMail: stuartb@uu.net
電話：703-886-5645 Eメール：stuartb@uu.net
David B. Nelson Enterasys Networks, Inc. (a Cabletron Systems company) 50 Minuteman Road Andover, MA 01810-1008
デビッド・B・ネルソンエンテラシスネットワークス株式会社（Cabletronシステムズ社）50ミニット・ロードアンドーバー、マサチューセッツ州01810から1008
Phone: 978-684-1330 EMail: dnelson@enterasys.com
電話：978-684-1330 Eメール：dnelson@enterasys.com
Basavaraj Patil Nokia 6000 Connection Dr. Irving, TX 75039
Basavarajパティルノキア6000の接続博士アーヴィング、TX 75039
Phone: +1 972-894-6709 EMail: Basavaraj.Patil@nokia.com
電話：+1 972-894-6709電子メール：Basavaraj.Patil@nokia.com
Mark Stevens Ellacoya Networks 7 Henry Clay Drive Merrimack, NH 03054
マーク・スティーブンスEllacoya Networksの7ヘンリー・クレイドライブメリマック、NH 03054
Phone: 603-577-5544 ext. 325 EMail: mstevens@ellacoya.com
電話：603-577-5544内線。 325 Eメール：mstevens@ellacoya.com
Barney Wolff, Pres. Databus Inc. 15 Victor Drive Irvington, NY 10533-1919 USA
バーニーヴォルフ、デプレ。データバス株式会社15ビクタードライブアーヴィングトン、NY 10533から1919 USA
Phone: 914-591-5677 EMail: barney@databus.com
電話：914-591-5677 Eメール：barney@databus.com
Appendix A - Summary Evaluations Consensus Results by Requirement and Protocol
付録A - 要件とプロトコル別サマリ評価コンセンサス結果
Requirement Section SNMP Radius++ Diameter COPS 1.1.1 P P T T 1.1.2 P P P T/P 1.1.3 T T/P T T 1.1.4 T P T T 1.1.5 P P T T 1.1.6 F P T T 1.1.7 T T T T 1.1.8 P P T T 1.1.9 T T T T 1.1.10 P T T T 1.1.11 F P T P 1.1.12 F F T P 1.1.13 P/T T T T 1.1.14 T T T T
要件章SNMP半径++直径COPS 1.1.1 PPTT 1.1.2 PPPT / P 1.1.3 TT / PTT 1.1.4 TPTT 1.1.5 PPTT 1.1.6 FPTT 1.1.7 TTTT 1.1.8 PPTT 1.1.9 TTTT 1.1.10 PTTT 1.1.11 FPTP 1.1.12 FFTP 1.1.13 P / TTTT 1.1.14 TTTT
1.2.1 T T T T
1.2.2 T T T T
1.2.3 T T T T
1.2.4 T T T T
1.2.5 T P P T
1.2.6 P T/P T T
1.3.1 P/F T T T 1.3.2 P T T/P P 1.3.3 T/P/F T T P 1.3.4 F T T T 1.3.5 P/F P T/P T 1.3.6 P P P T/P 1.3.7 F P/F P T/P 1.3.8 T P T T
1.3.1 P / F T T T 1.3.2 P T T / P P 1.3.3 T / P / F T T P 1.3.4 F T T T 1.3.5 P / F P T / P T 1.3.6 P P P T / P 1.3.7 F P / F P T / P 1.3.8 T P T T
1.4.1 T T T T 1.4.2 T T T T 1.4.3 T T T T 1.4.4 T F P P 1.4.5 T T T T 1.4.6 T T T T 1.4.7 T T T T
1.4.1 T T T T 1.4.2 T T T T 1.4.3 T T T T 1.4.4 T F P P 1.4.5 T T T T 1.4.6 T T T T 1.4.7 T T T T
1.5.1 T T/P T T 1.5.2 F T P P 1.5.3 F P T T
1.5.1 T T / P T T 1.5.2 F T P P 1.5.3 F P T T
Appendix B - Review of the Requirements
付録B - 要求事項のレビュー
Comments from the Panel on then work in progress, "Criteria for Evaluating AAA Protocols for Network Access" now revised and published as RFC 2989. This became the group standard interpretation of the requirements at the time.
その後、上のパネルからのコメント進行中の作業、「ネットワークアクセス用のAAAプロトコルを評価するための基準は、」今、これは一度に要件のグループの標準的な解釈になったRFC 2989.として改訂し、公表しました。
B.1 General Requirements
B.1一般要件
Scalability - In clarification [a], delete "and tens of thousands of simultaneous requests." This does not appear to be supported by any of the three base documents.
スケーラビリティ - 明確で[A]、削除「と十同時リクエストの数千人の。」これは、3つのベースの文書のいずれかによってサポートされて表示されません。
Transmission level security - [Table] Delete the ROAMOPS "M" and footnote "6". This appears to be an over generalization of the roaming protocol requirement not necessarily applicable to AAA.
送信レベルのセキュリティ - [表] ROAMOPS「M」を削除し、「6」脚注。これはAAAに必ずしも適用できないローミングプロトコル要件の過剰一般化であるように思われます。
Data object confidentiality - [Table] Delete the MOBILE IP "S" and footnote "33". The base document text does not appear to support this requirement.
データオブジェクトの機密性 - [表]モバイルIP「S」を削除し、脚注「33」。基本文書のテキストは、この要件をサポートするためには表示されません。
Reliable AAA transport mechanism - In clarification [h] delete everything after the "...packet loss" and replace with a ".". The requirements listed here are not necessarily supported by the base document and could be mistakenly taken as requirements for the AAA protocol in their entirety.
信頼性の高いAAA搬送機構 - 解明に[H]「...パケットロス」の後にすべてのものを削除して交換してください「」。ここに記載されている要件は、必ずしもベース文書によってサポートされていないと誤ってその全体がAAAプロトコルのための要件として採用することができます。
Run over IPv4 - [Table] Replace the MOBILE IP footnote "17" with footnote "33". This appears to be a incorrect reference.
IPv4の上で実行 - [表]脚注「33」と「17」モバイルIP脚注を交換します。これは正しくない参照であるように思われます。
Run over IPv6 - [Table] Replace the MOBILE IP footnote "18" with a footnote pointing to section 8 of [8]. This appears to be an incorrect reference.
IPv6で実行 - [表] [8]のセクション8を指し脚注で「18」をモバイルIP脚注を交換します。これは正しくない参照であるように思われます。
Auditability - Clarification [j] does not appear to coincide with the NASREQ meaning of Auditability. Given that NASREQ is the only protocol with an auditability requirement, this section should be aligned with that meaning.
監査能力 - の明確化[j]は、監査可能性のNASREQの意味と一致して表示されません。 NASREQは、監査能力要件を持つ唯一のプロトコルであることを考えると、このセクションには、その意味で整列する必要があります。
Shared secret not required - [Table] General - This section is misleadingly labeled. Our team has chosen to interpret it as specified in clarification [k] rather than any of the possible interpretations of "shared secret not required". We recommend the tag in the table be replaced with "Dual App and Transport Security Not Required" or something at least somewhat descriptive of [k]. Delete the NASREQ "S" and footnote "28" as not supported by the NASREQ document. Delete the MOBILE IP "O" and footnotes "34" and 39" as not supported.
必須ではありません共有秘密 - [表]一般 - このセクションは紛らわしく標識されています。明確に指定されている私たちのチームはそれを解釈することではなく、「必要ない共有秘密」の可能な解釈のいずれよりも[k]を選択しました。私たちは、テーブル内のタグは、「デュアル・アプリケーションおよびトランスポート・セキュリティ必須ではありません」または[k]の少なくともいくらかわかりやすいと置き換えることをお勧めします。 NASREQドキュメントでサポートされていないようNASREQ「S」を削除し、脚注「28」。サポートされていないなどのモバイルIP「O」と脚注「34」と39" を削除します。
B.2 Authentication Requirements
B.2認証要件
NAI Support - [Table] Replace MOBILE IP footnote "38" with "39". This appears to be a more appropriate reference.
NAIのサポート - [表]は "39" を使用したモバイルIPの脚注 "38" を交換してください。これは、より適切な基準であるように思われます。
CHAP Support - [Table] Delete MOBILE IP "O" as unsupported.
CHAPサポート - [表]サポートされていないとして、 "O" モバイルIPを削除します。
EAP Support - [Table] Delete MOBILE IP "O" as unsupported.
EAPのサポート - [表]モバイルIPサポートされていないとして、 "O" を削除します。
PAP/Clear-Text Support - [Table] Replace NASREQ footnote "10" with "26" as being more appropriate. Replace ROAMOPS "B" with "O". The reference text appears to not explicitly ban this and specifically references clear text for OTP applications. Delete MOBILE IP "O" as unsupported.
PAP /クリアテキストのサポート - [表]より適切であるとして「26」とNASREQ脚注「10」を置き換え。 ROAMOPS "O" と "B" を交換してください。参照テキストは、これを明示的に禁止し、具体的にOTPアプリケーションのための明確なテキストを参照していないように見えます。サポートされていないなどのモバイルIP「O」を削除します。
Re-authentication on demand - Clarification [e] appears to go beyond the requirements in NASREQ and MOBILE IP. [Table] Delete MOBILE IP footnote "30" as inapplicable.
再認証要求に応じて - 明確化[E]はNASREQとモバイルIPの要求事項を越えて行くように見えます。 [表]適用できないようにモバイルIP脚注「30」を削除します。
Authorization Only without Authentication - Clarification [f] does not include all NASREQ requirements, specifically that unneeded credentials MUST NOT be required to be filled in. Given that there are no other base requirements (after deleting the MOBILE IP requirement) we recommend that clarification [f] be brought in line with NASREQ. [Table] Delete MOBILE IP "O" and footnote "30". The referenced text does not appear to support the requirement.
唯一の認証なしで承認 - の明確化[f]は不要な資格情報を記入する必要はしてはならない、特にことを、すべてのNASREQ要件が含まれていませんが与えられ、他の基本要件は、（モバイルIPの要件を削除した後）が存在しないことを、私たちは[その明確化をお勧めします。 F] NASREQに沿ってもたらされます。 [表]モバイルIP "O" と脚注 "30" を削除します。参照テキストは、要件をサポートするためには表示されません。
B.3 Authorization Requirements
B.3許可の要件
Static and Dynamic... - Clarification [a] appears to use a particularly strange definition of static and dynamic addressing. Recommend clarification here identifying who (e.g. client or server) thinks address is static/dynamic. [Table] ROAMOPS "M" appears to be a derived requirement instead of directly called out. The footnote "1" should be changed to "5" as being more appropriate. A text clarification should be added to this document identifying the derived requirement.
静的および動的な... - 明確化[A]静的および動的なアドレッシングの特に奇妙な定義を使用して表示されます。アドレスが動的/静的であると考える（例えばクライアントまたはサーバ）ここで明確に識別することをお勧めします。 [表] ROAMOPS「M」は、直接呼び出さ代わりに由来する要件であると思われます。脚注「1」がより適切であるとして「5」に変更されなければなりません。テキスト明確化由来の要件を識別するこの文書に追加されるべきです。
RADIUS Gateway capability - [Table] Delete the MOBILE IP "O" and footnote "30". The referenced text does not appear to support the requirement.
RADIUSゲートウェイ機能 - [表]モバイルIP「O」を削除し、脚注「30」。参照テキストは、要件をサポートするためには表示されません。
Reject capability - [Table] Delete the NASREQ "M" and footnote "12". The NASREQ document does not appear to require this capability.
[表] NASREQ「M」を削除し、脚注「12」 - 能力を拒否する。 NASREQ文書は、この機能を必要とするように表示されません。
Reauthorization on Demand - [Table] Delete the MOBILE IP "S" and footnotes "30,33" The referenced text does not support this requirement.
オンデマンド再承認 - [表]モバイルIP「S」を削除し、脚注「30,33」参照テキストは、この要件をサポートしていません。
Support for Access Rules... - Clarification [e] has a overbroad list of requirements. NASREQ only requires 5-8 on the list, and as The MOBILE IP requirement is not supported by its references, this clarification should match NASREQ requirements. [Table] Delete the MOBILE IP "O" and footnotes "30,37" as not supported.
アクセスルールのサポートは... - 明確化[E]は要件のoverbroadリストを持っています。 NASREQはリストだけで5-8を必要とし、モバイルIPの要件は、その参照によってサポートされていないとして、この明確化はNASREQ要件と一致する必要があります。 [表]サポートされていないなどのモバイルIP「O」と脚注「30,37」を削除。
State Reconciliation - Clarification [f] should be brought in line with NASREQ requirements. The clarification imposes overbroad requirements not required by NASREQ and NASREQ is the only service with requirements in this area.
国家和解 - 明確化は、[F] NASREQ要件に沿ってもたらされる必要があります。明確化はNASREQとNASREQが必要としないoverbroad要件を課し、この領域での要件を有する唯一のサービスです。
B.4 Accounting Requirements
B.4会計の要件
Real-Time accounting - [Table] Replace MOBILE IP footnote [39] with a footnote pointing to section 3.1 of [3] as being more appropriate.
リアルタイムアカウンティング - [表]より適切であると[3]のセクション3.1を指す脚注と[39]モバイルIP脚注を交換します。
Mandatory Compact Encoding - [Table] Delete MOBILE IP "M" and footnote "33" as the reference does not support the requirement.
必須コンパクトエンコーディング - [表]基準要件をサポートしていないなどのモバイルIP「M」と脚注「33」を削除します。
Accounting Record Extensibility - [Table] Delete NASREQ "M" and footnote "15" as the reference does not support the requirement.
アカウンティングレコードの拡張 - [表]基準要件をサポートしていないとしてNASREQ「M」と脚注「15」を削除します。
Accounting Time Stamps - [Table] Delete MOBILE IP "S" and footnote "30" as they don't support the requirement. Replace MOBILE IP footnote "40" with a footnote pointing to section 3.1 of [3] as being more appropriate.
会計のタイムスタンプ - [表]モバイルIPを削除し、「S」と脚注「30」彼らは要件をサポートしていないよう。より適切であると[3]のセクション3.1を指す脚注でモバイルIP脚注「40」を置き換えます。
Dynamic Accounting - [Table] Replace the NASREQ footnote "18" with a footnote pointing to section 8.4.1.5 of [3]. Delete the MOBILE IP "S" and footnote "30" as the reference does not support the requirement.
動的アカウンティング - [表]のセクション8.4.1.5を指す脚注とNASREQ脚注「18」を置き換え[3]。参照が要件をサポートしていないとして、モバイルIP「S」と脚注「30」を削除します。
Footnote section.
脚注セクション。
[40] should be pointing to 6.1 of [4]. [41] should be pointing to 6.2.2 of [4]. [45] should be pointing to 6.4 of [4]. [46] should be pointing to 8 of [4].
[40] [4]の6.1を指しすべきです。 [41] [4]の6.2.2を指しすべきです。 [45] [4]の6.4を指しすべきです。 [46] [4]の8を指しすべきです。
Appendix C - Position Briefs
付録C - ポジションブリーフ
C.1 SNMP PRO Evaluation
C.1 SNMP PRO評価
Evaluation of SNMP AAA Requirements PRO Evaluation Evaluator - Stuart Barkley
スチュアートバークリー - SNMP AAA要件PRO評価評価者の評価
Ref [1] is "Comparison of SNMPv3 Against AAA Network Access Requirements", aka 'the document' Ref [2] is the aaa eval criteria as modified by us, aka 'the requirements'
文献[1]は別名「文書」は文献[2]は、我々が修正され、AAAの評価基準別名の要件」で、「SNMPv3のAAAネットワークアクセス要件に対するの比較」であります
The document uses T to indicate total compliance, P to indicate partial compliance and F to indicate no compliance. For each section I've indicated my grade for the section. If there is a change, I've indicated that and the grade given by the authors.
文書にはコンプライアンスを示さないために部分的コンプライアンス及びFを示すために、トータルコンプライアンス、Pを示すために、Tを使用します。各セクションのために私はセクションのための私の成績を示しました。変更がある場合、私はそれを示してきたし、グレードは著者によって与えられます。
1 Per item discussion
商品ディスカッションごとに1
The document indicates that SNMP can adequately handle that scale from the requirements document. Since most current uses are ppp connections and SNMP is already capable of handling the interface table and other per session tables it is clear that basic capacity exists. Additions to support other tables and variables scales in a simple linear fashion with the number of additional variables and protocol interactions. Regardless of the final selected protocol handling the scaling required is not a trivial undertaking. SNMP can draw upon existing network management practices to assist in this implementation.
文書には、SNMPが十分に要件文書からその規模を扱うことができることを示しています。最新の用途は、PPP接続され、SNMPがすでにインタフェーステーブルおよびその他のあたりのセッションテーブルを処理することが可能であるので、基本的な能力が存在することは明らかです。追加の変数とプロトコルの相互作用の数とシンプルな直線的に他のテーブルや変数のスケールをサポートするために追加。かかわらず、必要なスケーリングを取り扱う最終選択されたプロトコルの些細な仕事ではありません。 SNMPは、この実装を支援するために、既存のネットワーク管理手法に頼ることができます。
SNMP is of vital importance to the operation of most networks. Existing infrastructures can handle required failover or other redundant operations.
SNMPは、ほとんどのネットワークの操作に極めて重要です。既存のインフラストラクチャは、必要なフェイルオーバーや他の冗長操作を処理することができます。
The use of shared secrets described in the document is a well understood method of integrity control. Although shared secrets don't necessarily provide full authentication since other parties may also have the same secrets, the level of authentication is sufficient for the task at hand. In many cases the SNMP infrastructure will already exist and shared secrets should already be properly managed on an operational network. A failure of the SNMP shared secret approach regardless of the AAA protocol will likely leave equipment and systems open to substantial misuse bypassing any more elaborate AAA authentication.
文書で説明した共有秘密の使用は、完全性制御のよく理解する方法です。他の関係者も同じ秘密を持っているかもしれないので、共有秘密は必ずしも完全な認証を提供していませんが、認証のレベルは、当面の作業には十分です。多くの場合、SNMPインフラストラクチャがすでに存在し、共有秘密は、すでに適切に運用ネットワーク上で管理されるべきです。かかわらず、AAAプロトコルのSNMP共有秘密アプローチの失敗はおそらく機器や任意のより精巧なAAA認証をバイパスかなりの誤用にオープンシステムのままにします。
SNMPv3 provides many additional security options which were not available or were more controversial in previous SNMP versions.
SNMPv3は利用できなかったか、以前のSNMPバージョンでより多くの物議をした多くの追加のセキュリティオプションを提供します。
The document discusses SNMPv3 which can provide data confidentially for data passing over the wire. There is substantial implied AAA architecture (brokers and proxies) in the requirements that full conformance is difficult to determine. In particular, the evaluator has difficulty with the concept of "the target AAA entity for whom the data is ultimately destined", but will concede that the desired requirement is only partially met (most especially with the transfer of a PAP password).
文書は、ワイヤ上を通過するデータの機密にデータを提供できるのSNMPv3を説明します。完全な適合を判断することは困難である要件の大幅な暗黙のAAAアーキテクチャ（ブローカーやプロキシ）があります。特に、評価者は、「データが最終的に運命づけられている誰のための目標AAAエンティティ」の概念の難しさを持っていますが、必要な要件は部分的にしか（最も特にPAPパスワードの転送に）満たされていることを認めるだろう。
SNMP has full capabilities that allow the authentication of the data. Brokers, proxies or other intermediaries in the data chain can verify the source of the information and determine that the data has not been tampered with. The document downgrades the grade to P because of confusion over the integrity checking role of intermediaries.
SNMPは、データの認証を許可する完全な機能を備えています。データ・チェーン内のブローカ、プロキシ、又は他の媒体は、情報のソースを確認し、データが改ざんされていないと判断することができます。文書には、理由仲介の役割を整合性チェックの混乱のPへのグレードをダウングレードします。
The requirements require the capability of transporting certificates but do not have any specific use for the certificates. The requirements make assumptions that the protocol selected will be dependent upon certificates, but this is not necessarily true. SNMP can transport arbitrary objects and can transport certificates if necessary. The document indicates some issues with size of certificates and current maximum practical data sizes, however if the compact encoding requirement extends to the internal certificate information this should be less of an issue.
要件は、証明書を輸送する機能を必要とするが、証明書のいずれかの具体的な使用を持っていません。要件は、選択したプロトコルが証明書に依存するであろう仮定を行うが、これは必ずしも真実ではありません。 SNMPは、任意のオブジェクトを輸送することができ、必要に応じて証明書を輸送することができます。文書しかしコンパクトエンコーディング要件が内部証明書情報に延びているときは、この問題を小さくする必要があり、証明書と現在の最大の実用的なデータサイズの大きさにいくつかの問題を示しています。
The requirements is stated rather strongly and makes substantial assumptions of AAA protocol architecture and based upon current protocols and their failings. SNMP allows for great flexibility in retransmission schemes depending upon the importance of the data.
要件はかなり強く述べたとAAAプロトコルアーキテクチャの実質的な仮定を行い、現在のプロトコルとその欠点に基づいています。 SNMPは、データの重要性に応じて、再送スキームにおける大きな柔軟性を可能にします。
SNMP has operated in this mode for many years.
SNMPは、長年にわたって、このモードで動作しています。
SNMP must support IPv6 for many other systems so support for this should be possible by the time the requirement becomes effective. The document indicates that experimental versions satisfying this requirement are already in existence.
このためのサポートが必要条件が有効になる時間によって可能でなければなりませんので、SNMPは、他の多くのシステムにIPv6をサポートしている必要があります。文書では、この要件を満たす実験的なバージョンがすでに存在していることを示しています。
The requirements make significant assumptions about the final architecture. It is well within the capabilities of SNMP to provide intermediaries which channel data flows between multiple parties. The document downgrades SNMPs compliance with this requirement due to issues which are covered more specifically under "Data Object Confidentially" which the evaluator has downgraded to P.
要件は、最終的なアーキテクチャについての重要な仮定を作ります。これは、チャネルデータは、複数の当事者間を流れる仲介を提供するだけでなく、SNMPの能力の範囲内です。評価者はP.にダウングレードしている「内密データオブジェクト」の下で、より具体的に覆われている問題に、この要件を持つドキュメント格下げSNMPs遵守
Data flows inside SNMP are easily auditable by having secondary data flows established which provide copies of all information to auxiliary servers. The document grades this as a failure, but this support is only minor additions within a more fully fleshed out set of data flows.
SNMPは、補助サーバへのすべての情報のコピーを提供確立フロー二次データを有することによって、容易に監査可能である内部データが流れます。文書の障害としてグレードこの、しかし、このサポートは、データフローのより完全肉付けセット内のわずかな追加です。
Shared secrets are not required by SNMP. They are desirable in many instances where a lower level does not provide the necessary capabilities. The document supplies pointers to various security modes available.
共有秘密は、SNMPによって必要とされていません。彼らは、より低いレベルが必要な機能を提供していない多くの場合において望ましいです。文書は、利用可能なさまざまなセキュリティモードへのポインタを提供します。
SNMP has long had the ability for other parties to create new unambiguous attributes.
SNMPは長い新しい明確な属性を作成するために他の当事者のための能力を持っています。
SNMP easily supports this. NAIs were defined to be easily carried in existing protocols.
SNMPは、簡単にこれをサポートしています。 NAIは、簡単に既存のプロトコルで運ばれるように定義されました。
SNMP can easily provide objects to pass the necessary information for CHAP operation.
SNMPは、簡単にCHAP動作に必要な情報を渡すためにオブジェクトを提供することができます。
SNMP can easily provide objects to pass the necessary information for EAP operation. As with CHAP or PAP MIB objects can be created to control this operation thus the upgrade from the document grade.
SNMPは、簡単にEAPの動作に必要な情報を渡すためにオブジェクトを提供することができます。 CHAPまたはPAPと同じようにMIBオブジェクトは、このように、文書のグレードからのアップグレードを、この動作を制御するために作成することができます。
SNMP can easily provide objects to pass the necessary information for PAP operation. The requirement about non-disclosure of clear text passwords make assumptions about the protocol implementation. The choice to use clear text passwords is inherently insecure and forced protocol architecture don't really cover this. This requirement grade is downgraded to P (partial) because the document does not really address the confidentially of the data at application proxies.
SNMPは、簡単にPAP動作に必要な情報を渡すためにオブジェクトを提供することができます。クリアテキストのパスワードの非開示についての要件は、プロトコルの実装についての仮定を行います。クリアテキストのパスワードを使用するための選択が本質的に安全であると強制プロトコルアーキテクチャは、実際にこれをカバーしていません。文書が実際にアプリケーションプロキシで内密のデータに対処していないため、この要件グレードはP（部分）に格下げされます。
SNMP can easily provide objects to control this operation.
SNMPは、簡単にこの動作を制御するためのオブジェクトを提供することができます。
The document makes an incorrect interpretation of this requirement. However, SNMP makes no restriction which prevents to desired requirements. No actual change of grade is necessary, since both the actual requirements and the incorrect interpretation are satisfied by SNMP.
文書では、この要件を誤って解釈します。ただし、SNMPは、所望の要求に防ぐ制限を行うものではありません。実際の要件と間違った解釈の両方がSNMPによって満たされるので、グレードの実際の変更は、必要ありません。
SNMP can easily provide objects to control this operation.
SNMPは、簡単にこの動作を制御するためのオブジェクトを提供することができます。
As the document describes, with the addition of any necessary compatibility variables SNMP can be gatewayed to RADIUS applications.
文書としてSNMPは、RADIUSアプリケーションにゲートウェイすることができ、任意の必要な互換性変数を追加して、説明しています。
Any of the active components in the SNMP based structure could decide to reject and authentication request for any reason. Due to mixing different levels of requirements the document doesn't attempt to directly address this, instead indicating that a higher level application can cause this operation.
SNMPベースの構造における活性成分のいずれかが何らかの理由で要求を拒否し、認証することを決定することもできます。要件の異なるレベルを混合するドキュメントを直接代わりに、より高いレベルのアプリケーションがこの動作を引き起こす可能性があることを示し、これに対処しようとしません。
Nothing in SNMP explicitly interacts with the selection of any tunneling mechanisms the client may select. The document author was unclear about the needs here.
SNMPで何も明示的にクライアントが選択する可能性のトンネリングメカニズムの選択と相互作用しません。文書作成者は、ここではニーズについて不明でした。
SNMP can easily provide objects to control this operation.
SNMPは、簡単にこの動作を制御するためのオブジェクトを提供することができます。
The document indicates that should it be desired SNMP can provide objects to control these operations. In addition, active components can apply substantial further configurable access controls.
文書は、SNMPこれらの動作を制御するオブジェクトを提供することができ、所望されるべきであることを示します。また、活性成分は、実質的なさらなる構成アクセス制御を適用することができます。
The requirements describe an over broad set of required capabilities. The document indicates concern over incompatibilities in the requirements, however SNMP can provide methods to allow active components to reacquire lost state information. These capabilities directly interact with scalability concerns and care needs to be taken when expecting this requirement to be met at the same time as the scalability requirements.
要件は、必要な機能の広範なセットで記述します。文書は、しかし、SNMPは、活性成分が失われた状態情報を再取得できるようにする方法を提供することができ、要件の非互換性に懸念を示しています。これらの機能は、直接、スケーラビリティの問題と、この要件は、スケーラビリティの要件と同時に満たされることを期待する場合は注意する必要があるとの対話します。
The document indicates that SNMP can easily provide objects to control this operation.
文書には、SNMPを簡単にこの動作を制御するためにオブジェクトを提供できることを示しています。
SNMP can provide this mode of operation. The document outlines methods both fully within SNMP and using SNMP to interface with other transfer methods. Many providers already use SNMP for real time notification of other network events. This capability can directly interact with scalability concerns and implementation care needs to be taken to make this properly interact is large scale environments.
SNMPは、この動作モードを提供することができます。文書は、完全にSNMP内および他の転送方法とインターフェースするようにSNMPを使用して、両方の方法を概説します。多くのプロバイダは、すでに他のネットワークイベントのリアルタイム通知用のSNMPを使用しています。この機能は、直接、スケーラビリティの問題と実装のケアと対話することができ、これが適切に大規模な環境で対話するために取られる必要があります。
The document indicates the possibility of controlling external protocols to handle data transmissions where the BER encoding of SNMP objects would be considered excessive. SNMP BER encoded protocol elements are generally in a fairly compact encoding form compared with text based forms (as used in some existing radius log file implementations). This interacts with the general requirement for carrying service specific attributes and the accounting requirement for extensibility. With careful MIB design and future work on SNMP payload compression the SNMP coding overhead can be comparable with other less extensible protocols.
文書には、SNMPオブジェクトのBERエンコーディングが過剰と考えられるデータ伝送を処理するために、外部のプロトコルを制御する可能性を示しています。 SNMP BER符号化されたプロトコル要素は、（いくつかの既存の半径ログファイルの実装に使用されるような）テキストベースのフォームと比較して、かなりコンパクトな符号化形態です。これは、サービス固有の属性と拡張のための会計要件を実施するための一般的な要件と対話します。 SNMPのペイロード圧縮に慎重なMIBの設計と今後の作業でSNMPコーディングオーバーヘッドは、他のあまり、拡張プロトコルと匹敵することができます。
SNMP has a strong tradition of allowing vendor specific data objects to be transferred.
SNMPは、ベンダー固有のデータオブジェクトを転送できるようにすることの強い伝統を持っています。
There are many methods which a SNMP based system could use for batch accounting. The document discusses SNMP parameters to control the batching process and indicates that certain existing MIBs contain examples of implementation strategies. SNMP log tables can provide accounting information which can be obtained in many methods not directly related to real time capabilities. The underlying system buffering requirements are similar regardless of the protocol used to transport the information.
SNMPベースのシステムは、バッチ会計に使用できる多くの方法があります。文書は、バッチプロセスを制御するためにSNMPパラメータを説明し、特定の既存のMIBが実装戦略の例が含まれていることを示しています。 SNMPログテーブルが直接、リアルタイム機能に関係のない多くの方法で得ることができる会計情報を提供することができます。基礎となるシステム・バッファリング要件は関係なく、情報を輸送するために使用されるプロトコルの類似しています。
SNMP is very amenable to providing guaranteed delivery. Particularly in a pull model (versus the often assumed push model) the data gatherer can absolutely know that all data has been transfered. In the common push model the data receiver does not know if the originator of the data is having problems delivering the data.
SNMPは保証された配信を提供するのに非常に適しています。特に、（多くの場合、仮定プッシュモデル対）プルモデルでのデータ収集器は絶対にすべてのデータが転送されたことを知ることができます。データの発信元がデータを配信する問題を抱えている場合、共通のプッシュモデルでは、データ受信機は知りません。
Timestamps are used for many SNMP based operations. The document points at the DateAndTime textual convention which is available for use. As with all environments the timestamps accuracy needs evaluation before the information should be relied upon.
タイムスタンプは、多くのSNMPベースの操作のために使用されています。使用可能であるのDateAndTimeのテキストの表記法で文書を指します。情報が依拠しなければならない前に、すべての環境と同じようにタイムスタンプの精度は、評価を必要とします。
As long as there is some way to relate multiple records together there are no problems resolving multiple records for the same session. This interacts with the scalability requirement and care must be taken when implementing a system with both of these requirements.
限り、複数のレコードを関連付けるためにいくつかの方法があると一緒に同じセッションのために複数のレコードを解決する問題はありません。これは、スケーラビリティの要件と相互作用し、これらの要件の両方を備えたシステムを実装する際には注意が必要です。
SNMP can easily provide objects to transfer this information.
SNMPは、簡単にこの情報を転送するためのオブジェクトを提供することができます。
SNMP is already deployed in many operational networks. SNMPv3 addresses most concerns people had with the operation of previous versions. True SNMPv3 proxies (as opposed to AAA proxies) should become commonplace components in firewalls for those organizations which require firewalls.
SNMPは、すでに多くの運用ネットワークに配置されます。 SNMPv3は、ほとんどの人が、以前のバージョンの動作としていた懸念に対処します。真のSNMPv3プロキシは（AAAプロキシではなく）ファイアウォールを必要とする組織のためのファイアウォールでは一般的なコンポーネントになるはずです。
SNMP is not concerned with the LHA. This can be under control of the Local network to meet its needs.
SNMPはLHAとの関係ではありません。これは、そのニーズを満たすために、ローカル・ネットワークの制御下に置くことができます。
SNMP appears to meet most stated requirements. The areas where the SNMP proposal falls short are areas where specific AAA architectures are envisioned and requirements based upon that architecture are specified.
SNMPは、ほとんど述べた要件を満たすために表示されます。 SNMPの提案が不足する領域は、特定のAAAアーキテクチャが想定され、そのアーキテクチャに基づく要件が指定されているエリアです。
Scaling of the protocol family is vital to success of a AAA suite. The SNMP protocol has proved scalable in existing network management and other high volume data transfer operations. Care needs to be taken in the design of a large scale system to ensure meeting the desired level of service, but this is true of any large scale project.
プロトコルファミリのスケーリングは、AAAスイートの成功に不可欠です。 SNMPプロトコルは、既存のネットワーク管理やその他の大容量データ転送操作で拡張性のあることが判明しています。ケアは、サービスの所望のレベルを満たすことを確認するために、大規模システムの設計に取られる必要があるが、これは任意の大規模なプロジェクトの真のです。
SNMP is well understood and already supported in many ISP and other operational environments. Trust models already exist in many cases and can be adapted to provide the necessary access controls needed by the AAA protocols. Important issues with previous versions of SNMP have been corrected in the current SNMPv3 specification.
SNMPはよく理解し、すでに多くのISPや他の動作環境でサポートされています。トラストモデルは、すでに多くの場合に存在し、AAAプロトコルによって必要と必要なアクセス制御を提供するように適合することができます。 SNMPの以前のバージョンとの重要な問題は、現在のSNMPv3の仕様で修正されました。
The SNMP proposal is silent on the specific data variables and message types to be implemented. This is largely due to the requirements not specifying the necessary data elements and the time constraints in extracting that information from the base document set. Such a data model is necessary regardless of the ultimate protocol selected.
SNMPの提案は、特定のデータ変数および実装するためのメッセージタイプに沈黙しています。これは、ベース文書集合からの情報を抽出する際に必要なデータ要素と時間の制約を指定しない必要条件によるところが大きいです。そのようなデータ・モデルにかかわらず、選択された最終的なプロトコルの必要があります。
SNMP appears to fully meet all necessary requirements for the full AAA protocol family.
SNMPは、完全にフルAAAプロトコルファミリのために必要なすべての要件を満たすように表示されます。
C.2 SNMP CON Evaluation
C.2 SNMPのCON評価
Evaluation of SNMP AAA Requirements CON Evaluation Evaluator - Michael StJohns
マイケルStJohns - SNMP AAA要件CON評価評価者の評価
Ref [1] is "Comparison of SNMPv3 Against AAA Network Access Requirements", aka 'the document' Ref [2] is the aaa eval criteria as modified by us.
文献[1]「SNMPv3のAAAネットワークアクセス要件に対するの比較」で、別名「文書」は文献[2]は、私たちによって修正されたAAAの評価基準です。
The document uses T to indicate total compliance, P to indicate partial compliance and F to indicate no compliance. For each section I've indicated my grade for the section. If there is no change, I've indicated that and the grade given by the authors.
文書にはコンプライアンスを示さないために部分的コンプライアンス及びFを示すために、トータルコンプライアンス、Pを示すために、Tを使用します。各セクションのために私はセクションのための私の成績を示しました。変更がない場合、私はそれを示してきたし、グレードは著者によって与えられます。
Section 1 - Per item discussion
第1節 - 商品ディスカッションパー
1.1.1 Scalability - Although the document indicates compliance with the requirement, its unclear how SNMP actually meets those requirements. The document neither discusses how SNMP will scale, nor provides applicable references. The argument that there is an existence proof given the deployed SNMP systems appears to assume that one manager contacting many agents maps to many agents (running AAA) contacting one AAA server. A server driven system has substantially different scaling properties than a client driven system and SNMP is most definitely a server (manager) driven system. Eval - F
1.1.1スケーラビリティ - ドキュメントが要件に準拠していることを示しますが、その不明確SNMPは、実際には、これらの要件を満たしていますか。文書はどちらもSNMPが拡張する方法について説明していない、また該当の参照を提供します。存在が展開SNMPシステム与えられた証拠があるという引数は1つのマネージャは、多くのエージェントに多くのエージェントマップを接触させ（AAAを実行している）1台のAAAサーバに連絡することを前提とするように見えます。サーバー駆動システムは、クライアント駆動システムよりも実質的に異なるスケーリング特性を持っており、SNMPは、ほとんど間違いなく、サーバ（マネージャ）駆動方式です。評価 - F
1.1.2 Fail-over - The document indicates the use of application level time outs to provide this mechanism, rather than the mechanism being a characteristic of the proposed protocol. The protocol provides only partial compliance with the requirement. Eval - P
1.1.2フェールオーバー - ドキュメントは、提案されたプロトコルの特性であるというよりも、機構は、この機構を提供するために、アプリケーションレベルのタイムアウトを使用することを示しています。プロトコルは、要件に部分的にしかコンプライアンスを提供します。評価 - P
1.1.3 Mutual Authentication - There is some slight handwaving here, but the protocol's USM mode should be able to support this requirement. Eval - No Change (T)
1.1.3相互認証は - ここにいくつかのわずかなhandwavingがありますが、プロトコルのUSMモードでは、この要件をサポートすることができるはずです。評価 - 変更なし（T）
1.1.4 Transmission Level Security - The authors should elaborate on the specific use of the SNMPv3 modes to support these requirements, but the text is minimally acceptable. Eval - No Change (T)
1.1.4トランスミッションレベルセキュリティ - 著者は、これらの要件をサポートするためのSNMPv3モードの特定の使用について詳しく説明する必要がありますが、テキストは最小限に許容されます。評価 - 変更なし（T）
1.1.5 Data Object Confidentiality - The authors describe a mechanism which does not appear to completely meet the requirement. VACM is a mechanism for an end system (agent) to control access to its data based on manager characteristics. This mechanism does not appear to map well to this requirement. Eval - P
1.1.5データの機密性をオブジェクト - 著者は完全に要件を満たすように見えない仕組みを説明します。 VACMマネージャ特性に基づいて、そのデータへのアクセスを制御するために、エンドシステム（エージェント）のための機構です。このメカニズムは、この要件にうまくマッピングするためには表示されません。評価 - P
1.1.6 Data Object Integrity - There appears to be some handwaving going on here. Again, SNMP does not appear to be a good match to this requirement due to at least in part a lack of a proxy intermediary concept within SNMP. Eval - F
1.1.6データオブジェクトの整合性は - ここで起こっていくつかのhandwavingがあるように見えます。ここでも、SNMPが原因SNMP内の代理仲介概念の少なくとも一部が不足して、この要件に良い試合ではありません。評価 - F
1.1.7 Certificate Transport - The document does indicate compliance, but notes that optimization might argue for use of specialized protocols. Eval - No Change (T)
1.1.7証明書交通 - 文書は、コンプライアンスを示していますが、最適化は、特殊なプロトコルの使用のために主張する人もいるかもしれないと述べています。評価 - 変更なし（T）
1.1.8 Reliable AAA Transport - The document indicates some confusion with the exact extent of this requirement. Given the modifications suggested by the eval group to the explanatory text in [2] for the related annotation, the point by point explanatory text is not required. The document does indicate that the use of SNMP is irrespective of the underlying transport and the support of this requirement is related at least partially to the choice of transport. However, SNMP over UDP - the most common mode for SNMP - does not meet this requirement. Eval - No Change (P)
1.1.8信頼できるAAA輸送 - ドキュメントはこの要件の正確な広がりを持ついくつかの混乱を示しています。 [2]関連する注釈のために、ポイント説明文によってポイントを必要としないで説明テキストに評価グループによって提案された変更を考えます。文書には、SNMPの使用に関係なく根本的な輸送のであり、この要件のサポートは、トランスポートの選択に少なくとも部分的に関係していることを示しているん。しかし、UDP上でSNMP - SNMPのための最も一般的なモード - この要件を満たしていません。評価 - 変更なし（P）
1.1.9 Run over IPv4 - While the evaluator agrees that SNMPv3 runs over V4, the authors need to point to some sort of reference. Eval - No Change (T)
IPv4のオーバーラン1.1.9は - 評価者は、SNMPv3のがV4上で実行されることに同意しますが、著者は、リファレンスのいくつかの並べ替えを指すようにする必要があります。評価 - 変更なし（T）
1.1.10 Run over IPv6 - The document indicates both experimental implementations and future standardization of SNMPv3 over IPv6. Eval - No Change (P)
IPv6のオーバーラン1.1.10 - ドキュメントは、実験的な実装およびIPv6経由のSNMPv3の将来の標準化の両方を示しています。評価 - 変更なし（P）
1.1.11 Support Proxy and Routing Brokers - The section of the document (5.5.3) that, by title, should have the discussion of SNMP proxy is marked as TBD. The section notes that the inability to completely comply with the data object confidentiality and integrity requirements might affect the compliance of this section and the evaluator agrees. Eval - F
1.1.11サポートプロキシとルーティングブローカー - タイトルで、SNMPプロキシの議論はTBDとしてマークされていなければならない、という文書（5.5.3）のセクション。セクションでは、できないことは、完全にこのセクションの遵守に影響を与える可能性のあるデータオブジェクトの機密性と完全性要件に準拠していることを指摘し、評価者は同意します。評価 - F
1.1.12 Auditability - The document indicates no compliance with this requirement. Eval - No Change (F)
1.1.12監査能力 - ドキュメントはこの要件へのコンプライアンスを全く示していません。評価 - 変更なし（F）
1.1.13 Shared Secret Not Required - Slight handwaving here, but SNMPv3 does not necessarily require use of its security services if other security services are available. However, the interaction with VACM in the absence of USM is not fully described and may not have good characteristics related to this requirement. Eval - P
1.1.13共有秘密必須ではありません - ここではわずかhandwavingが、他のセキュリティ・サービスが利用可能な場合にSNMPv3は、必ずしもそのセキュリティサービスを使用する必要はありません。しかし、USMの非存在下でVACMとの相互作用が完全に記載されておらず、この要求に関連する良好な特性を有していなくてもよいです。評価 - P
1.1.14 Ability to Carry Service Specific Attributes - SNMP complies via the use of MIBs. Eval - No Change (T)
1.1.14能力は、サービスの特定の属性を運ぶために - SNMPは、MIBの使用を通じて準拠しています。評価 - 変更なし（T）
1.2.1 NAI Support - The document indicates that MIB objects can be created to meet this requirement, but gives no further information. Eval - P
NAIのサポート1.2.1 - ドキュメントは、MIBオブジェクトがこの要件を満たすために作成することができることを示しているが、それ以上の情報を与えません。評価 - P
1.2.2 CHAP Support - The document indicates that MIB objects can be created to meet this requirement, but gives no further information. Given the normal CHAP model, its unclear exactly how this would work. Eval - F
1.2.2 CHAPサポート - ドキュメントは、MIBオブジェクトがこの要件を満たすために作成することができることを示しているが、それ以上の情報を与えません。まさにこれがどのように動作するか、通常のCHAPモデル、その不明確を考えます。評価 - F
1.2.3 EAP Support - The document notes that EAP payloads can be carried as specific MIB objects, but also notes that further design work would be needed to fully incorporate EAP. Eval - No Change (P)
1.2.3 EAPサポート - ドキュメントは、EAPペイロードは、特定のMIBオブジェクトとして実施することができることを指摘するだけでなく、さらにデザイン作業が完全にEAPを組み込むために必要とされるであろうことを指摘しています。評価 - 変更なし（P）
1.2.4 PAP/Clear-text Passwords - The document notes the use of MIB objects to carry the clear text passwords and the protection of those objects under normal SNMPv3 security mechanisms. Eval - No Change (T)
1.2.4 PAP /クリアテキストのパスワード - ドキュメントは、クリアテキストのパスワードと、通常のSNMPv3セキュリティメカニズムの下で、これらのオブジェクトの保護を運ぶためのMIBオブジェクトを使用することを指摘しています。評価 - 変更なし（T）
1.2.5 Reauthorization on demand - While there's some handwaving here, its clear that the specific applications can generate the signals to trigger reauthorization under SNMP. Eval - No Change (T)
特定のアプリケーションは、SNMPの下で再認可をトリガするための信号を生成することができることをいくつかhandwavingがここにありますが、その明確な - 1.2.5オンデマンドで再承認。評価 - 変更なし（T）
1.2.6 Authorization w/o Authentication - The author appears to be confusing the AAA protocol authorization with the AAA user authorization and seems to be over generalizing the ability of SNMP to deal with general AAA user authorization. Eval - F
認証O / W 1.2.6認証 - 著者は、AAAのユーザ認証にAAAプロトコル許可を混乱されるように表示され、一般的なAAAのユーザ認証に対処するためのSNMPの能力を一般の上にあるように思われます。評価 - F
1.3.1 Static and Dynamic IP Addr Assignment - The reference to MIB objects without more definite references or descriptions continues to be a negative. While the evaluator agrees that MIB objects can represent addresses, the document needs to at least lead the reader in the proper direction. Eval - F
1.3.1静的および動的IP ADDRの割り当て - より明確な言及または説明なしでMIBオブジェクトへの参照はマイナスであり続けています。評価者は、MIBオブジェクトがアドレスを表すことができることに同意しながら、文書は、少なくとも正しい方向に読者を導く必要があります。評価 - F
1.3.2 RADIUS Gateway Capability - The transport and manipulation of Radius objects appears to be only a part of what is required. Eval - P
1.3.2 RADIUSゲートウェイ機能 - 半径オブジェクトの輸送および操作が必要とされるものの一部のみであるように思われます。評価 - P
1.3.3 Reject Capability - Again, a clarification of how SNMP might accomplish this requirement would be helpful. The overall document lacks a theory of operation for SNMP in an AAA role that might have clarified the various approaches. Eval - F
1.3.3は機能を拒否 - ここでも、SNMPは、この要件を達成するかもしれない方法の明確化が参考になります。全体的な文書では、様々なアプローチを明らかにしたかもしれないAAAの役割でSNMPのための動作理論を欠いています。評価 - F
1.3.4 Preclude Layer 2 Tunneling - Document indicates lack of understanding of this requirement. Eval - F
1.3.4は、レイヤ2トンネリングを排除 - ドキュメントはこの要件の理解の欠如を示しています。評価 - F
1.3.5 Reauth on Demand - See response in 1.3.3 above. None of the text responding to this requirement, nor any other text in the document, nor any of the references describes the appropriate framework and theory. Eval - F
オンデマンド1.3.5再認証は、 - 上記の1.3.3での応答を参照してください。この要件に対応したテキスト、また文書内の他のテキストのいずれも、また参照のいずれかが適切な枠組みと理論を説明していません。評価 - F
1.3.6 Support for ACLs - The response text again references MIB objects that can be defined to do this job. There is additional engineering and design needed before this is a done deal. Eval - P
ACLの1.3.6サポート - 応答テキストは、再びこの仕事をするように定義することができるMIBオブジェクトを参照します。これが完了した取引である前に、必要に応じて追加のエンジニアリングとデザインがあります。評価 - P
1.3.7 State Reconciliation - The text fails to address the basic question of how to get the various parts of the AAA system back in sync. Eval - F
1.3.7国家和解 - テキストはバック同期してAAAシステムのさまざまな部分を取得する方法の基本的な質問に対処するために失敗しました。評価 - F
1.3.8 Unsolicited Disconnect - Assuming that the NAS is an SNMP agent for an AAA server acting as an SNMP manager the evaluator concurs. Eval - No Change (T).
1.3.8迷惑を切断 - NASは、評価者は同意SNMPマネージャとして機能するAAAサーバのSNMPエージェントであると仮定すると。評価 - 変更なし（T）。
1.4.1 Real Time Accounting - SNMP Informs could accomplish the requirements. Eval - No Change (T)
1.4.1リアルタイムの会計 - SNMP応答要求要件を達成することができます。評価 - 変更なし（T）
1.4.2 Mandatory Compact Encoding - This is a good and reasonable response. SNMP can vary the style and type of reported objects to meet specific needs. Eval - No Change (T).
1.4.2必須コンパクトエンコーディング - これは良いと合理的な応答です。 SNMPは、特定のニーズを満たすためにスタイルと報告されたオブジェクトの種類を変えることができます。評価 - 変更なし（T）。
1.4.3 Accounting Record Extensibility - MIBs are extensible. Eval - No Change (T)
1.4.3会計情報レコードの拡張 - MIBは拡張可能です。評価 - 変更なし（T）
1.4.4 Batch Accounting - MIBs provide data collection at various times. Eval - No Change (T)
1.4.4バッチ会計 - MIBは、様々な時点でのデータ収集を提供します。評価 - 変更なし（T）
1.4.5 Guaranteed Delivery - There's some weasel wording here with respect to what guaranteed means, but the description of mechanisms does appear to meet the requirements. Eval - No Change (T)
1.4.5保証配信は - 手段を保証するものに関して、ここでいくつかのイタチ文言ありますが、メカニズムの記述は、要件を満たしているように見えるん。評価 - 変更なし（T）
1.4.6 Accounting Timestamps - Accounting records can use the DateAndTime Textual Convention to mark their times. Eval - No Change (T)
会計タイムスタンプは1.4.6 - アカウンティングレコードは、自分の時間をマークするのDateAndTimeテキストの表記法を使用することができます。評価 - 変更なし（T）
1.4.7 Dynamic Accounting - The author may have partially missed the point on this requirement. While the number of records per session is not of great interest, the delivery may be. The author should go a little more into depth on this requirement. Eval - No Change (T)
1.4.7ダイナミック会計 - 著者は、部分的にこの要件上のポイントを逃している可能性があります。セッションあたりのレコード数が非常に重要ではありませんが、配信であってもよいです。著者は、この要件に深さにもう少し行く必要があります。評価 - 変更なし（T）
1.5.1 Encoding of MOBILE IP Registration Messages - Registration messages can probably be encoded as SNMP messages. Eval - No Change (T)
モバイルIP登録メッセージの1.5.1エンコーディング - 登録メッセージは、おそらくSNMPメッセージとしてエンコードすることができます。評価 - 変更なし（T）
1.5.2 Firewall Friendly - There's a chicken and egg problem with the response to the requirement in that the author hopes that SNMP as an AAA protocol will encourage Firewall vendors to make SNMP a firewall friendly protocol. Eval - F
1.5.2ファイアウォールフレンドリー - 著者はSNMPは、AAAプロトコルとしてSNMPファイアウォールフレンドリープロトコルにするためにファイアウォールベンダーを奨励することを期待しているという点で、要求に応じ付き鶏と卵の問題があります。評価 - F
1.5.3 Allocation of Local Home Agent - The author disclaims an understanding of this requirement. Eval - F
ローカルホームエージェントの1.5.3配分 - 著者は、この要件の理解を負いません。評価 - F
The documents evaluation score was substantially affected by a lack of any document, reference or text which described a theory of operation for SNMP in AAA mode. Of substantial concern are the items relating to the AAA server to server modes and AAA client to server modes and the lack of a map to the SNMP protocol for those modes.
文書の評価スコアは、実質的にAAAモードでのSNMPのための動作理論を説明した任意のドキュメント、参照またはテキストの欠如によって影響を受けました。かなり懸念されるのは、サーバーのモードにサーバーモードとAAAクライアントにAAAサーバとそれらのモードのためのSNMPプロトコルへのマップの欠如に関連するアイテムです。
The evaluator also notes that the scaling issues of SNMP in SNMP agent/manager mode are in no way indicative of SNMP in AAA client/server mode. This has a possibility to substantially impair SNMPs use in an AAA role.
評価者はまた、SNMPエージェント/マネージャモードでのSNMPのスケーリングの問題は、AAAクライアント/サーバモードでない方法でSNMPを示すものであることを指摘しています。これは、実質的にSNMPsがAAAの役割で使用損なう可能性があります。
However, SNMP may have a reasonable role in the Accounting space. SNMP appears to map well with existing technology, and with the requirements.
ただし、SNMPは、会計空間の合理的な役割を有することができます。 SNMPは、既存の技術とうまくマッピングするために表示され、要件を持ちます。
SNMP appears to meet the general requirements of an IP capable protocol, but may not have a proper field of use for all specific requirements.
SNMPは、IP対応のプロトコルの一般的な要件を満たすように見えますが、すべての特定の要件のための使用の適切なフィールドを持っていないかもしれません。
Recommended in Part. SNMP is NOT RECOMMENDED for use as either an authentication or authorization protocol, but IS RECOMMENDED for use as an accounting protocol.
パートに推奨。 SNMPは、認証や認証プロトコルのいずれかとして使用することは推奨されていませんが、アカウンティングプロトコルとして使用することをお勧めします。
C.3 RADIUS+ PRO Evaluation
C.3 RADIUS + PRO評価
Evaluation of RADIUS AAA Requirements PRO Evaluation
RADIUS AAA要件PRO評価の評価
Evaluator - Mark Stevens
評価者 - マーク・スティーブンス
Ref [1] is "Comparison of RADIUS Against AAA Network Access Requirements" Ref [2] is "Framework for the extension of the RADIUS(v2) protocol" Ref [3] is the aaa eval criteria as modified by us.
参考文献[1]「RADIUS AAAに対するネットワークアクセス要件の比較」である文献[2]参考文献「RADIUS（V2）プロトコルの拡張のためのフレームワークは、」[3]米国で変更されるAAAの評価基準です。
The documents uses T to indicate total compliance, P to indicate partial compliance and F to indicate no compliance.
文書には、コンプライアンスを示さないために、部分的コンプライアンスおよびFを示すために、全コンプライアンス、Pを示すために、Tを使用しています。
For each section I've indicated my grade for the section. I have indicated whether or not my evaluation differs from the statements made with respect to RADIUS++. The evaluation ratings as given below may differ from the evaluations codified in the document referred to as, "Comparison of RADIUS Against AAA Network Access Requirements" without any indication.
各セクションのために私はセクションのための私の成績を示しました。私は、私の評価はRADIUS ++に対する発言と異なっているか否かを示しています。下記のように評価評価は、文書において体系化評価と異なる場合があり、任意の指示なしに、「RADIUS AAAに対するネットワークアクセス要件の比較」と呼びます。
1.1.1 [a] Scalability - In as much as a protocol's scalability can be measured, the protocol seems to transmit information in a fairly efficient manner.So, in that the protocol appears not to consume an inordinate amount of bandwidth relative to the data it is transmitting, this protocol could be considered scalable. However, the protocol has a limit in the number of concurrent sessions it can support between endpoints. Work arounds exist and are in use. Eval - P (no change)
1.1.1 [A]スケーラビリティ - でできるだけ多くのプロトコルのスケーラビリティを測定することができるように、プロトコルは、プロトコルがデータ帯域幅に対して過度の量を消費しないように見えるという点で、かなり効率的manner.Soに情報を送信するように思われますそれがこのプロトコルはスケーラブルで考えることができ、送信されます。しかし、プロトコルは、エンドポイント間でサポートできる同時セッション数には限界があります。回避策は存在し、使用されています。評価 - P（変更なし）
1.1.2 [b] Fail-over - The document indicates the use of application level time outs to provide this mechanism, rather than the mechanism being a characteristic of the proposed protocol. The fail-over requirement indicates that the protocol must provide the mechanism rather than the application. The implication is that the application need not be aware that the fail-over and subsequent correction when it happens. The application using the RADIUS++ protocol will be involved in fail-over recovery activities. The protocol layer of the software does not appear to have the capability built-in. Given the wording of the requirement: Eval - P (changed from T)
1.1.2 [B]フェールオーバー - 文書は、このメカニズムではなく、提案されたプロトコルの特性であるメカニズムを提供するために、アプリケーションレベルのタイムアウトを使用することを示しています。フェイルオーバーの要件は、プロトコルは、アプリケーションではなく、メカニズムを提供しなければならないことを示しています。含意は、アプリケーションがフェイルオーバーとその後の補正は、それが発生したときにことを意識する必要はないということです。 RADIUS ++プロトコルを使用してアプリケーションを復旧活動をフェールオーバー-に関与することになります。ソフトウェアのプロトコル層は、機能が内蔵されていないと思われます。 P（Tから変更） - 評価：要件の文言を考えます
1.1.3 [c] Mutual Authentication - The RADIUS++ protocol provides shared-secret as a built-in facility for mutual authentication. The authors of the document suggest the use of IPSec to obtain mutual authentication functions. The RADIUS++ protocol provides no road blocks to obtaining mutual authentication between instances of AAA applications, however the protocol provides no facilities for doing so.
1.1.3 [C]相互認証 - RADIUS ++プロトコルは、相互認証のための組み込み機能として共有秘密を提供します。文書の著者は、相互認証機能を取得するためのIPSecの使用を示唆しています。 RADIUS ++プロトコルはAAAアプリケーションのインスタンス間で相互認証を得ることに何の道ブロックを提供しない、しかし、プロトコルがそうするために何の施設を提供していません。
1.1.4 [d] Transmission Level Security - The RADIUS++ protocol provides no transmission level security features, nor does it preclude the use of IPSec to obtain transmission level security. Eval - P (no change)
1.1.4 [D]の送信レベルのセキュリティ - RADIUS ++プロトコルには、伝送レベルのセキュリティ機能を提供しない、またそれは、送信レベルのセキュリティを得るためのIPSecの使用を排除するものではありません。評価 - P（変更なし）
1.1.5 [e] Data Object Confidentiality - The document describes a RAIDUS++ message designed to server as an envelope in which encrypted RADIUS messages (attributes) may be enclosed. Eval - T (no change)
1.1.5 [E]データオブジェクトの機密性 - 文書がRAIDUSを記述する++ RADIUSメッセージ（属性）、暗号化されたエンベロープとしてサーバーに設計されたメッセージを封入することができます。評価 - T（変更なし）
1.1.6 [f] Data Object Integrity - Using visible signatures, the RADIUS++ protocol appears to meet this requirement. Eval - T (no change)
1.1.6 [f]は、データ・オブジェクト・インテグリティ - 可視署名を使用して、RADIUSプロトコル++は、この要件を満たしています。評価 - T（変更なし）
1.1.7 [g] Certificate Transport - The document indicates compliance through the use of the CMS-Data Radius Attribute (message). Eval - T (no change)
1.1.7 [G]証明交通 - ドキュメントはCMS-データRADIUS属性（メッセージ）の使用を介してコンプライアンスを示します。評価 - T（変更なし）
1.1.8 [h] Reliable AAA Transport - The document points out that RADIUS++ can be considered a reliable transport when augmented with Layer 2 Tunneling Protocol. The protocol itself does not provide reliability features. Reliability remains the responsibility of the application or a augmenting protocol. Eval - P (no change)
1.1.8 [H]信頼できるAAA交通 - 文書は、レイヤ2トンネリングプロトコルで拡張するときRADIUSが++信頼性の高い輸送を考慮することができることを指摘しています。プロトコル自体は信頼性機能を提供していません。信頼性は、アプリケーションまたは拡張プロトコルの責任残っています。評価 - P（変更なし）
1.1.10 [j] Run over IPv6 - an IPv6 Address data type must be defined. Eval - T (no change)
1.1.10 [jを] IPv6の上で実行します - IPv6アドレスデータ型を定義する必要があります。評価 - T（変更なし）
1.1.11 [k] Support Proxy and Routing Brokers - There is no mechanism for rerouting requests, but an extension can be made to do so. Eval - T (no change)
1.1.11 [k]はサポートプロキシとルーティングブローカー - そこ要求を再ルーティングするためのメカニズムはありませんが、拡張子がそうさせることができます。評価 - T（変更なし）
1.1.12 [l] Auditability - The document indicates no compliance with this requirement. Eval - F (no change)
1.1.12 [L]監査能力 - ドキュメントはこの要件とはコンプライアンスを示しません。評価 - F（変更なし）
1.1.13 [m] Shared Secret Not Required - RADIUS++ can be configured to run with empty shared secret values. Eval - T (no change)
1.1.13 [m]の共有秘密必須ではありません - RADIUSは++空の共有秘密値を使用して実行するように構成することができます。評価 - T（変更なし）
1.1.14 [n] Ability to Carry Service Specific Attributes - Vendor escape mechanism can be used for this purpose.. Eval - T (no change)
1.1.14 [n]は能力がサービス固有の属性を運ぶために - ベンダー・エスケープ機構がこの目的のために使用することができる..評価 - T（変更なし）
1.2.2 [b] CHAP Support - Subject to dictionary attacks. Eval - P (changed from T)
1.2.2 [B] CHAPサポート - 辞書攻撃を条件。評価 - P（Tから変更）
1.2.4 [d] PAP/Clear-text Passwords - No end-to-end security, but potential for encapsulation exists within current paradigm of the protocol. - Eval -T (no change)
1.2.4 [D] PAP /クリアテキストのパスワード - なしエンドツーエンドのセキュリティが、カプセル化のための可能性は、プロトコルの現在のパラダイム内に存在します。 - 評価-T（変更なし）
1.2.5 [e] Reauthentication on demand - The RADIUS protocol supports re-authentication. In case re-authentication is initiated by the user or AAA client, the AAA client can send a new authentication request. Re-authentication can be initiated from the visited or home AAA server by sending a challenge message to the AAA client. Eval - T (no change)
1.2.5は、[E]再認証は、オンデマンド - RADIUSプロトコルは、再認証をサポートしています。再認証は、ユーザまたはAAAクライアントによって開始された場合には、AAAクライアントは、新たな認証要求を送信することができます。再認証AAAクライアントにチャレンジメッセージを送信することにより、訪問やホームAAAサーバから開始することができます。評価 - T（変更なし）
1.2.6 [f] Authorization w/o Authentication - A new message type can be created to enable RADIUS++ to support Aw/oA . Eval - T (no change)
1.2.6 [F] W / O認証承認 - 新しいメッセージタイプはW / OAをサポートするために、RADIUS ++を可能にするために作成することができます。評価 - T（変更なし）
1.3.1[a] Static and Dynamic IP Addr Assignment - Both supported. IPv6 would require the definition of a new address data type. Eval - P (no change)
1.3.1 [A]静的および動的IP ADDRの割り当て - の両方がサポートされています。 IPv6は、新しいアドレスのデータ型の定義が必要となります。評価 - P（変更なし）
1.3.2 [b] RADIUS Gateway Capability - The transport and manipulation of RADIUS objects appears to be only a part of what is required. Requirement seems to be worded to preclude RADIUS. Eval - P (changed from T)
1.3.2 [B] RADIUSゲートウェイ機能 - RADIUSオブジェクトの輸送および操作が必要とされるものの一部のみであるように思われます。要件は、RADIUSを排除するために言葉で表現しているようです。評価 - P（Tから変更）
1.3.4 [d] Preclude Layer 2 Tunneling - I do not see a definition in the AAA eval criteria document. Eval - ?
1.3.4 [D]排除して、レイヤ2トンネリング - 私はAAAの評価基準文書の定義を参照しません。評価 - ？
1.3.5 [e] Reauthorization on Demand - Implementation in the field demonstrate that extensions to RADIUS can support the desired behavior. Re-authentication is currently coupled to re-authorization. Eval - P (no change)
1.3.5 [E]オンデマンドで再承認 - フィールドの実装は、RADIUSへの拡張が必要な動作をサポートできることを示しています。再認証は現在、再認証をするために結合されています。評価 - P（変更なし）
1.3.6 [f] Support for ACLs - Currently done in the applications behind the RADIUS end points, not the within the protocol. RADIUS++ could define additional message types to deal with expanded access control within new service areas. Eval - P (no change)
1.3.6 [F] ACLのサポート - 現在のプロトコル内で、RADIUSエンドポイントの背後にあるアプリケーションではない行います。 RADIUS ++は、新しいサービスエリア内で拡張アクセスコントロールに対処するために、追加のメッセージタイプを定義することができます。評価 - P（変更なし）
1.3.8 [h] Unsolicited Disconnect - RADIUS++ extensions to support. Eval - T. (no change)
1.3.8 [H]迷惑を切断 - サポートするRADIUS ++の拡張機能。評価 - T.（変更なし）
1.4.4 [d] Batch Accounting - RADIUS++ offers no new features to support batch accounting. Eval - F No change)
1.4.4 [D]バッチ会計 - RADIUSは++バッチ・アカウンティングをサポートするための新しい機能を提供しています。評価 - 変更なしF）
1.4.5 [e] Guaranteed Delivery - Retransmission algorithm employed. Eval - T (no change)
1.4.5 [E]保証付き配信 - 再送信アルゴリズムを採用します。評価 - T（変更なし）
1.4.6 [f] Accounting Timestamps - RADIUS++ extensions support timestamps. Eval - T (no change)
1.4.6 [F]会計のタイムスタンプを - RADIUS ++の拡張機能は、タイムスタンプをサポートしています。評価 - T（変更なし）
1.4.7 [g] Dynamic Accounting - RADIUS++ extensions to support. Eval - T (no change)
1.4.7 [G]ダイナミック会計 - RADIUS ++の拡張機能をサポートします。評価 - T（変更なし）
1.5.1 [a] Encoding of MOBILE IP Registration Messages - RADIUS++ extensions can be made to include registration messages as an opaque payload. Eval - T (no change)
1.5.1 [A]モバイルIP登録メッセージのエンコーディングを - RADIUS ++の拡張機能は、不透明なペイロードとして登録メッセージを含めるようにすることができます。評価 - T（変更なし）
1.5.2 [b] Firewall Friendly - RADIUS is known to be operational in environments where firewalls acting as a proxy are active. Eval - T (no change)
1.5.2 [B]ファイアウォールフレンドリー - RADIUSプロキシとして動作するファイアウォールがアクティブである環境で動作することが知られています。評価 - T（変更なし）
1.5.3 [c] Allocation of Local Home Agent -Requirement statement needs some clarification and refinement. Eval - F (no change)
1.5.3 [C]ローカルホームエージェント-Requirement文の配分は、いくつかの明確化と改善が必要です。評価 - F（変更なし）
The RADIUS protocol, and its associated extensions, is presently not fully compliant with the AAA Network Access requirements. However, it is possible with a small effort to extend present procedures to meet the requirements as listed in, while maintaining a high level of interoperability with the wide deployment and installed base of RADIUS clients and servers.
RADIUSプロトコル、およびそれに関連する拡張は、現在、AAAネットワークアクセス要件に完全に準拠していません。しかし、それは広い展開とRADIUSクライアントとサーバーのインストールベースとの相互運用性の高いレベルを維持しながら、に記載されているような要件を満たすために、本手順を拡張するための小さな努力で可能です。
RADIUS++ the protocol and the application meet the majority of the requirements and can be extended to meet the requirements where necessary.
RADIUS ++プロトコルおよびアプリケーション要件の大部分を満たし、ここで必要な要件を満たすように拡張することができます。
RADIUS++ as it could be developed would provide a level of backward compatibility that other protocols cannot achieve. By extending RADIUS in the simple ways described in the documents listed above, the transition from existing RADIUS-based installations to RADIUS++ installations would be easier. Although accounting continues to be weaker than other approaches, the protocol remains a strong contender for continued use in the areas of Authorization and Authentication.
RADIUS ++、それは他のプロトコルを達成することができない、下位互換性のレベルを提供する開発される可能性があるので。上記の文献に記載された簡単な方法でRADIUSを拡張することにより、RADIUS ++インストールに既存のRADIUSベースのインストールからの移行が容易になるだろう。会計は他のアプローチよりも弱いことを継続するが、このプロトコルは認可および認証の分野における継続的な使用のための強力な候補のままです。
C.4 RADIUS+ CON Evaluation
C.4のRADIUS + CON評価
Evaluation of RADIUS++ (sic) AAA Requirements CON Evaluation Evaluator - David Nelson
RADIUSの評価++（原文のまま）AAA要件CON評価評価者 - デヴィッド・ネルソン
Ref [1] is "Comparison of RADIUS Against AAA Network Access Requirements", a.k.a. 'the document' Ref [2] is "Framework for the extension of the RADIUS(v2) protocol", a.k.a. 'the protocol' Ref [3] is the AAA evaluation criteria as modified by us. Ref [4] is RFC 2869. Ref [5] is an expired work in progress "RADIUS X.509 Certificate Extensions". Ref [6] is RFC 2868
参考文献[1]「RADIUS AAAに対するネットワークアクセス要件の比較」であり、別名「文書」は、参考文献[2]、別名「プロトコル」REF「RADIUS（V2）プロトコルの拡張のためのフレームワーク」である[3]であります私たちによって修正されたAAA評価基準。文献[4]は文献[5]「RADIUS X.509証明書エクステンション」進行中の期限切れの仕事であるRFC 2869です。参考文献[6] RFC 2868であります
The document uses T to indicate total compliance, P to indicate partial compliance and F to indicate no compliance. Evaluator's Note: The document [1] pre-dates the protocol [2]. It is clear from reading [2], that some of the issues identified as short comings in [1] are now addressed in [2]. The evaluator has attempted to take note of these exceptions, where they occur.
文書にはコンプライアンスを示さないために部分的コンプライアンス及びFを示すために、トータルコンプライアンス、Pを示すために、Tを使用します。評価者の注意：ドキュメント[1]前の日付プロトコル[2]。これは、問題のいくつかは、今で対処されている[1]のような短所を識別していること、[2]読みから明らかである[2]。評価者は、それらが発生し、これらの例外、メモを取るしようとしています。
Section 1 - Per item discussion
第1節 - 商品ディスカッションパー
1.1.1 Scalability - The document [1] indicates partial compliance, largely in deference to the "tens of thousands of simultaneous requests" language in [3], that has been deprecated. The issue of simultaneous requests from a single AAA client is addressed in [1], indicating that the apparent limitation of 256 uniquely identifiable outstanding request can be worked around using well known techniques, such as the source UDP port number of the request. The document claims "P", and the evaluator concurs.
1.1.1スケーラビリティ - ドキュメント[1]は、大部分が廃止されました[3]の「十同時要求の数千人の」言語に服従して、部分的なコンプライアンスを示しています。単一のAAAクライアントからの同時要求の問題は、256を一意に識別未処理の要求は、要求の送信元UDPポート番号のような周知の技術を使用して回避することができるの見かけ限定ことを示す、[1]にアドレス指定されます。文書には、「P」を要求して、評価者は同意します。
1.1.2 Fail-over - The document [1] indicates the use of application level time outs to provide the fail-over mechanism. Since the AAA protocol is indeed an application-layer protocol, this seems appropriate. There are significant issues of how to handle fail-over in a proxy-chain environment that have not been well addressed, however. The document claims "T", and the evaluator awards "P".
1.1.2フェールオーバー - 文書[1]フェイルオーバー機構を提供するために、アプリケーションレベルのタイムアウトを使用することを示しています。 AAAプロトコルは、実際のアプリケーション層プロトコルであるため、これは適切と思われます。フェイルオーバうまく対処されていないプロキシチェーン環境では、しかし、どのように扱うかの重要な問題があります。文書は「T」と主張、および評価者賞「P」。
1.1.3 Mutual Authentication - The document [1] indicates that mutual authentication exists in the presence of a User-Password or CHAP-Password attribute in an Access-Request packet or the Message-Authenticator [4] in any packet. Once again, this addresses hop-by-hop authentication of RADIUS "peers", but does not fully address proxy-chain environments, in which trust models would need to be established. The document further indicates that strong mutual authentication could be achieved using the facilities of IPsec. This claim would apply equally to all potential AAA protocols, and cannot be fairly said to be a property of the protocol itself. The document claims "T", and the evaluator awards "F".
1.1.3相互認証 - 文書[1]は、相互認証がAccess-Requestパケットまたはメッセージ認証[4]のいずれかのパケット内にユーザパスワードまたはCHAP-Password属性の存在下で存在することを示しています。もう一度、これは、RADIUS「ピア」のホップバイホップの認証を扱いますが、完全に信頼モデルを確立する必要があるだろうしたプロキシチェーン環境に対処しません。文書には、さらに強力な相互認証は、IPSecの機能を使用して達成することができることを示しています。この主張は、すべての潜在的なAAAプロトコルにも同様に適用される、とかなりプロトコル自体の性質であると言うことができません。文書には、「T」を主張し、評価者賞「F」。
1.1.4 Transmission Level Security - The document [1] indicates that transmission layer security, as defined in [3], is provided in the protocol, using the mechanisms described in section 1.1.3. It should be noted that this requirement is now a SHOULD in [3]. The document claims "P", and the evaluator concurs.
1.1.4トランスミッションレベルセキュリティ - で定義されるように文書[1]、その透過層セキュリティを示す[3]、セクション1.1.3で説明されたメカニズムを使用して、プロトコルで提供されます。この要件は、今ではSHOULDであることに留意すべきである[3]。文書には、「P」を要求して、評価者は同意します。
1.1.5 Data Object Confidentiality - The document [1] indicates that end-to-end confidentiality is not available in RADIUS, but goes on to say that it could be added. The protocol [2] actually makes an attempt to specify how this is to be done, in section 4.3.2.2 of [2], using a CMS-data attribute, based in large part upon RFC 2630. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. The document claims "F", but in light of the specifics of the protocol [2], the evaluator awards "P".
1.1.5データオブジェクトの機密性 - ドキュメント[1]、エンドツーエンドの機密性は、RADIUSで使用できませんが、それは追加することができることを言うようになっていることを示しています。プロトコル[2]は、実際にこれを、評価者がいないRFC 2630上に大部分的に基づいてCMSデータ属性を使用して、[2]のセクション4.3.2.2に、これが実行されるべき方法を指定するための試みを行います時間は、AAAの仕事にRFC 2630の適用性を調べました。文書は、「F」と主張するが、プロトコルの仕様に照らして、[2]、評価者賞「P」。
1.1.6 Data Object Integrity - The document [1] indicates that end-to-end integrity is not available in RADIUS, but goes on to say that it could be added. The protocol [2] actually makes an attempt to specify how this is to be done, in section 4.3.2.1 of [2], using a CMS-data attribute, based in large part upon RFC 2630. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. The document claims "F", but in light of the specifics of the protocol [2], the evaluator awards "P".
1.1.6データオブジェクトの整合性 - ドキュメント[1]、エンドツーエンドの整合性がRADIUSで使用できませんが、それは追加することができたと言うことになっていることを示しています。プロトコル[2]は、実際にこれを、評価者がいないRFC 2630上に大部分的に基づいてCMSデータ属性を使用して、[2]のセクション4.3.2.1に、これが実行されるべき方法を指定するための試みを行います時間は、AAAの仕事にRFC 2630の適用性を調べました。文書は、「F」と主張するが、プロトコルの仕様に照らして、[2]、評価者賞「P」。
1.1.7 Certificate Transport - The document [1] indicates that certificate transport is not available in RADIUS, but goes on to say that it could be added. The protocol [2] actually makes an attempt to specify how this is to be done, in section 4.3.2.3 of [2], using a CMS-data attribute, based in large part upon RFC 2630. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. Other relevant work in the area of certificate support in RADIUS may be found in an expired work in progress, "RADIUS X.509 Certificate Extensions" [5]. The document claims "F", but in light of the specifics of the protocol [2], the evaluator awards "P".
1.1.7証明書交通 - ドキュメント[1]は、証明書のトランスポートがRADIUSで利用できないことを示しているが、それは追加することができることを言うようになります。プロトコル[2]は、実際にこれを、評価者がいないRFC 2630上に大部分的に基づいてCMSデータ属性を使用して、[2]のセクション4.3.2.3に、これが実行されるべき方法を指定するための試みを行います時間は、AAAの仕事にRFC 2630の適用性を調べました。 RADIUSでの証明書のサポートの分野における他の関連する作業が進行中で期限切れの仕事で見ることができる、「RADIUS X.509証明書エクステンション」[5]。文書は、「F」と主張するが、プロトコルの仕様に照らして、[2]、評価者賞「P」。
1.1.8 Reliable AAA Transport - The document [1] indicates that RADIUS provides partial compliance with the requirements of the original AAA requirements document. However, in [3], the requirement has been simplified to "resilience against packet loss". Once again, the evaluator finds that the protocol [2] meets this criteria on a hop-by-hop basis, but fails to effectively address these issues in a proxy-chain environment. The document claims "P", and the evaluator awards "F".
1.1.8信頼できるAAA交通 - 文書[1]はRADIUSは、元のAAA要件ドキュメントの要件を部分的にコンプライアンスを提供することを示しています。しかしながら、[3]において、要件は、「パケット損失に対する回復力」に簡略化されています。再度、評価者は、プロトコル[2]はホップバイホップに基づいて、この基準を満たしているが、効果的にプロキシチェーン環境でこれらの問題に対処することができないと認めます。文書には、「P」を主張し、評価者賞「F」。
1.1.9 Run over IPv4 - RADIUS is widely deployed over IPv4. The document claims "T", and the evaluator concurs.
IPv4のオーバーラン1.1.9 - RADIUSは広くIPv4の上で展開されています。文書には、「T」を主張し、評価者は同意します。
1.1.10 Run over IPv6 - The document [1] indicates that adoption of a limited number of new RADIUS attributes to support IPv6 is straightforward. Such discussion has transpired on the RADIUS WG mailing list, although that WG is in the process of shutting down. The document claims "P", and the evaluator concurs.
IPv6のオーバーラン1.1.10 - ドキュメント[1]は、新しいRADIUSの限られた数の採用は、IPv6が簡単ですサポートするために、属性ことを示しています。そのWGは、シャットダウン処理であるが、そのような議論は、RADIUS WGメーリングリストで蒸散しています。文書には、「P」を要求して、評価者は同意します。
1.1.11 Support Proxy and Routing Brokers - The document [1] indicates that RADIUS is widely deployed in proxy-chains of RADIUS servers. This is equivalent to the Proxy Broker case, but the Routing Broker case is a different requirement. The protocol [2] does not describe any detail of how a Routing Broker might be accommodated, although it opens the door by indicating that the RADIUS++ protocol is peer-to-peer, rather than client/server. The document claims "P", and the evaluator awards "F".
1.1.11サポートプロキシとルーティングブローカー - ドキュメント[1] RADIUSが広くRADIUSサーバのプロキシチェーンで展開されていることを示しています。これは、プロキシブローカ場合に相当するが、ルーティングブローカの場合は、異なる要件です。それはRADIUS ++プロトコルは、ピア・ツー・ピアではなく、クライアント/サーバであることを示すことにより、ドアを開けたが、プロトコル[2]は、ルーティング・ブローカが収容されるかもしれない方法の任意の詳細を記載していません。文書には、「P」を主張し、評価者賞「F」。
1.1.12 Auditability - The document [1] indicates no compliance with this requirement. The document claims "F", and the evaluator concurs.
1.1.12監査能力 - 文書[1]は、この要件とはコンプライアンスを示しません。文書は「F」と主張し、評価者は同意します。
1.1.13 Shared Secret Not Required - The document [1] indicates that RADIUS may effectively skirt the requirement of application-layer security by using a value of "zero" for the pre-shared secret. While this is a bit creative, it does seem to meet the requirement. The document claims "T" and the evaluator concurs.
1.1.13共有秘密ではない必須 - 文書[1] RADIUSを効果的に事前共有秘密は、「ゼロ」の値を使用して、アプリケーション・レイヤ・セキュリティの要件をスカートしてもよいことを示しています。これは少し創造的であるが、要件を満たしているように見えるん。文書には、「T」を主張し、評価者は同意します。
1.1.14 Ability to Carry Service Specific Attributes - RADIUS has a well defined Vendor-Specific Attribute, which, when properly used, does indeed provide for the ability to transport service-specific attributes. The document claims "T", and the evaluator concurs.
1.1.14能力は、サービスの特定の属性を運ぶために - RADIUSは、適切に使用すれば、実際にサービス固有の属性を輸送する能力を提供しない、明確に定義されたベンダー固有の属性を持っています。文書には、「T」を主張し、評価者は同意します。
1.2.1 NAI Support - The document [1] indicates that RADIUS specifies the NAI as one of the suggested formats for the User-Name attribute. The document claims "T", and the evaluator agrees.
1.2.1 NAIのサポート - ドキュメント[1]は、RADIUSは、User-Name属性の推奨フォーマットの一つとしてNAIを指定していることを示しています。文書には、「T」を主張し、評価者は同意します。
1.2.2 CHAP Support - CHAP support is widely deployed in RADIUS. The document claims [1] "T", and the evaluator concurs.
1.2.2 CHAPサポート - CHAPのサポートは広くRADIUSで展開されています。文書請求項[1]、「T」、及び評価者同意。
1.2.3 EAP Support - The document [1] indicates that EAP support in RADIUS is specified in [4]. The document claims [1] "T", and the evaluator concurs.
1.2.3 EAPサポート - 文書[1] RADIUSにおけるEAPサポートを[4]に指定されていることを示しています。文書請求項[1]、「T」、及び評価者同意。
1.2.4 PAP/Clear-text Passwords - The document [1] indicates that RADIUS provides protection of clear-text passwords on a hop-by-hop basis. The protocol [2] indicates how additional data confidentiality may be obtained in section 4.3.2.2 of [2], using a CMS-data attribute, based in large part upon RFC 2630. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. The document claims [1] "F", but in light of the specifics of the protocol [2], the evaluator awards "P".
1.2.4 PAP /クリアテキストのパスワード - ドキュメント[1] RADIUSは、ホップバイホップ毎にクリアテキストのパスワードの保護を提供することを示しています。プロトコル[2]評価者は、この時点で、適用性を調査していないRFC 2630上に大部分的に基づいてCMSデータ属性を使用して、[2]のセクション4.3.2.2で得ることができる方法の追加データの機密性を示しAAAの作品へのRFC 2630の。 [1]「F」が、プロトコル[2]は、評価者賞「P」の内容に照らして文書クレーム。
1.2.5 Reauthentication on demand - The document [1] indicates that RADIUS may accomplish re-authentication on demand by means of an Access-Challenge message sent from a server to a client. The evaluator disagrees that this is likely to work for a given session once an Access-Accept message has been received by the client. The document claims "T", and the evaluator awards "F".
オンデマンド1.2.5再認証 - 文書[1] RADIUSは、サーバからクライアントに送信されたAccess-Challengeメッセージを用いてオンデマンドで再認証を行うことができることを示しています。評価者は、Access-Acceptメッセージがクライアントによって受信された後、これは特定のセッションのために働く可能性があることを同意しません。文書には、「T」を主張し、評価者賞「F」。
1.2.6 Authorization w/o Authentication - This requirement, as applied to the protocol specification, mandates that non- necessary authentication credentials not be required in a request for authorization. The actual decision to provide authorization in the absence of any authentication resides in the application (e.g. AAA server). RADIUS does require some form of credential in request messages. The document [1] claims "F", and the evaluator concurs.
認証O / W 1.2.6認可 - この要件は、プロトコル仕様、認可要求で要求されていない、必要な認証情報を非義務に適用されます。任意認証の不在下で認可を提供するために実際の決定は、アプリケーション（例えば、AAAサーバ）に存在します。 RADIUSは、要求メッセージに資格のいくつかのフォームを必要としません。文書[1]は「F」を主張し、評価者は同意します。
1.3.1 Static and Dynamic IP Addr Assignment - The document [1] indicates that RADIUS can assign IPv4 addresses, and can easily be extended to assign IPv6 addresses (see section 1.1.10). Of greater concern, however, is the issue of static vs. dynamic addresses. If dynamic address has the same meaning as it does for DHCP, then there are issues of resource management that RADIUS has traditionally not addressed. The document claims "P", and the evaluator concurs.
1.3.1静的および動的IP ADDR割り当て - 文書[1]はRADIUSは、IPv4アドレスを割り当てることができ、容易にIPv6アドレス（セクション1.1.10を参照）を割り当てるように拡張することができることを示しています。大きな懸念されるのは、しかし、静的対動的アドレスの問題です。動的アドレスは、それがDHCPの場合と同じ意味を持っている場合、RADIUSは、伝統的に取り組まれていない資源管理の問題があります。文書には、「P」を要求して、評価者は同意します。
1.3.2 RADIUS Gateway Capability - The document [1] maintains that a RADIUS++ to RADIUS gateway is pretty much a tautology. The document claims "T", and the evaluator concurs.
1.3.2 RADIUSゲートウェイ機能 - 文書[1] RADIUSゲートウェイへRADIUSは++かなりトートロジーであることを維持します。文書には、「T」を主張し、評価者は同意します。
1.3.3 Reject Capability - The document [1] maintains that RADIUS Proxy Servers, and potentially RADIUS++ Routing Brokers, have the ability to reject requests based on local policy. The document claims "T" and the evaluator concurs.
1.3.3は機能を拒否 - ドキュメント[1]はRADIUSプロキシサーバ、および潜在的にRADIUS ++ルーティングブローカーは、ローカルポリシーに基づいて要求を拒否する能力を持っていると主張します。文書には、「T」を主張し、評価者は同意します。
1.3.4 Preclude Layer 2 Tunneling - The document [1] indicates that [6] defines support for layer two tunneling in RADIUS. The document claims "T", and the evaluator concurs.
1.3.4排除して、レイヤ2トンネリング - 文書[1]〜[6] RADIUSにおけるレイヤ2つのトンネリングのサポートを定義することを示しています。文書には、「T」を主張し、評価者は同意します。
1.3.5 Reauth on Demand - The document [1] indicates that RADIUS provides this feature by means of the Session-Timeout and Termination- Action attributes. While this may, in fact, be sufficient to provide periodic re-authorization, it would not provide re- authorization on demand. The protocol [2] does not address this further. The document claims "P", and the evaluator awards "F".
オンデマンド1.3.5再認証 - ドキュメント[1]は、RADIUSは、セッションタイムアウトにより、この機能を提供してTermination-アクション属性ことを示しています。これは、実際には、定期的な再認証を提供するのに十分であるかもしれないが、それはオンデマンドで再認証を提供しないであろう。プロトコル[2]さらに、これに対処しません。文書には、「P」を主張し、評価者賞「F」。
1.3.6 Support for ACLs - The document [1] describes the attributes in RADIUS that are used to convey the access controls described in [3]. Certain of these (e.g. QoS) are not currently defined in RADIUS, but could easily be defined as new RADIUS attributes. The document claims "P", and the evaluator concurs.
ACLの1.3.6サポート - 文書は、[1]〜[3]に記載のアクセス制御を伝えるために使用されるRADIUSの属性を記述する。これら（例えばQoS）のの一部は現在、RADIUSで定義されていませんが、簡単に新しいRADIUS属性として定義することができます。文書には、「P」を要求して、評価者は同意します。
1.3.7 State Reconciliation - The document [1] addresses each of the sub- items, as listed in the original AAA requirements document. In reviewing the document against the modified requirements of [3], there is still an issue with server-initiated state reconciliation messages. While the protocol [2] makes provision for such messages, as servers are allowed to initiate protocol dialogs, no detailed message formats are provided. This is an area that has traditionally been a short coming of RADIUS. The document claims "P", and the evaluator awards "F".
1.3.7状態調整 - 元AAA要件文書に記載されている文書[1]は、サブアイテムの各々に対処します。 [3]の修正要求事項に対する文書のレビューでは、サーバー開始状態の和解メッセージで問題が依然として存在しています。サーバは、プロトコルダイアログを開始するために許可されているようなプロトコル[2]は、そのようなメッセージのために準備する間、詳細なメッセージフォーマットが提供されていません。これは、伝統的にRADIUSの短いつつある分野です。文書には、「P」を主張し、評価者賞「F」。
1.3.8 Unsolicited Disconnect - Much of the discussion from the previous section applies to this section. The document [1] claims "F", and the evaluator concurs.
1.3.8迷惑を切断 - 前のセクションからの議論の多くは、このセクションに適用されます。文書[1]は「F」を主張し、評価者は同意します。
1.4.1 Real Time Accounting - RADIUS Accounting is widely deployed and functions within the definition of real time contained in [3]. The document [1] claims "T", and the evaluator concurs.
1.4.1リアルタイムの会計 - RADIUSアカウンティングは広く、[3]に含まれるリアルタイムの定義の範囲内に配備され、機能しています。文書[1]は「T」を主張し、評価者は同意します。
1.4.2 Mandatory Compact Encoding - RADIUS Accounting contains TLVs for relevant accounting information, each of which is fairly compact. Note that the term "bloated" in [3] is somewhat subjective. The document [1] claims "T", and the evaluator concurs.
1.4.2必須コンパクトエンコーディング - RADIUSアカウンティングは、そのそれぞれがかなりコンパクトで、関連する会計情報のためのTLVが含まれています。 [3]において「肥大化」はやや主観的であることに注意してください。文書[1]は「T」を主張し、評価者は同意します。
1.4.3 Accounting Record Extensibility - RADIUS Accounting may be extended by means of new attributes or by using the Vendor-Specific attribute. While it has been argued that the existing attribute number space is too small for the required expansion capabilities, the protocol [2] addresses this problem in section 3.0, and its subsections, of [2]. The document [1] claims "T", and the evaluator concurs.
RADIUSアカウンティングの新しい属性によって、またはベンダー固有の属性を使用して拡張することができる - 会計情報レコード拡張は1.4.3。それは既存の属性数のスペースが必要な拡張機能、プロトコルのための小さすぎると主張してきたが[2] [2]の、セクション3.0、およびそのサブセクションでは、この問題に対処します。文書[1]は「T」を主張し、評価者は同意します。
1.4.4 Batch Accounting - RADIUS has no explicit provisions for batch accounting, nor does the protocol [2] address how this feature might be accomplished. The document [1] claims "F", and the evaluator concurs.
1.4.4バッチ会計 - RADIUSは、バッチ会計のための明示的な規定を持っていない、またプロトコル[2]は、この機能が達成される可能性がありますどのように対処しません。文書[1]は「F」を主張し、評価者は同意します。
1.4.5 Guaranteed Delivery - RADIUS Accounting is widely deployed and provides guaranteed delivery within the context of the required application-level acknowledgment. The document [1] claims "T", and the evaluator concurs.
1.4.5保証付き配信 - RADIUSアカウンティングを広く展開し、必要なアプリケーションレベルの確認応答のコンテキスト内で保証された配信を提供しています。文書[1]は「T」を主張し、評価者は同意します。
1.4.6 Accounting Timestamps - The document [1] indicates that this feature is specified in [4] as the Event-Timestamp attribute. The document claims [1] "T", and the evaluator concurs.
会計タイムスタンプは、1.4.6 - 文書[1]この機能はイベントタイムスタンプ属性として[4]で指定されていることを示します。文書請求項[1]、「T」、及び評価者同意。
1.4.7 Dynamic Accounting - The document [1] indicates that this requirement is partially met using the accounting interim update message as specified in [4]. In addition, there was work in the RADIUS WG regarding session accounting extensions that has not been included in [4], i.e., some expired works in progress. The document claims [1] "P", and the evaluator concurs.
1.4.7動的アカウンティング - [1]文書は、で指定されるように、この要件は、部分的に会計暫定更新メッセージを使用して満たされることを示している[4]。また、進行中の[4]、すなわち、いくつかの期限が切れた作品には含まれていないセッションアカウンティングの拡張に関するRADIUS WGでの仕事がありました。文書請求項[1]「P」、及び評価者は同意。
1.5.1 Encoding of MOBILE IP Registration Messages - The document [1] claims "F", and the evaluator concurs.
モバイルIP登録メッセージの1.5.1エンコード - 文書[1]は「F」を主張し、評価者は同意します。
1.5.2 Firewall Friendly - The document [1] indicates that RADIUS deployment is know to have occurred in fire-walled environments. The document claims "T", and the evaluator concurs.
1.5.2ファイアウォールフレンドリー - ドキュメント[1]は、RADIUSの展開が火壁の環境で発生したと知っていることを示しています。文書には、「T」を主張し、評価者は同意します。
1.5.3 Allocation of Local Home Agent - The document [1] claims "F", and the evaluator concurs.
ローカルホームエージェントの1.5.3配分 - ドキュメント[1]「F」と主張し、評価者は同意。
The document [1] and the protocol [2] suffer from having been written in a short time frame. While the protocol does provide specific guidance on certain issues, citing other relevant documents, it is not a polished protocol specification, with detailed packet format diagrams. There is a pool of prior work upon which the RADIUS++ protocol may draw, in that many of the concepts of Diameter were first postulated as works in progress within the RADIUS WG, in an attempt to "improve" the RADIUS protocol. All of these works in progress have long since expired, however.
文書[1]とプロトコル[2]は、短い時間枠内に書き込まれた苦しみます。プロトコルは、特定の問題に関する具体的な指針を提供していますが、その他の関連文書を引用し、それが詳細なパケットフォーマット図で研磨プロトコル仕様、ではありません。最初のRADIUSプロトコルを「改善」する試みでRADIUS WG内で進行中の作品、と仮定された直径の概念の多くでRADIUS ++プロトコルを引く可能性がある時に前の仕事のプールがあります。進行中のこれらの作品のすべてが長いので、期限が切れています。
RADIUS++ meets many of the requirements of an AAA protocol, as it is the current de facto and de jure standard for AAA. There are long-standing deficiencies in RADIUS, which have been well documented in the RADIUS and NASREQ WG proceedings. It is technically possible to revamp RADIUS to solve these problems. One question that will be asked, however, is: "What significant differences would there be between a finished RADIUS++ protocol and the Diameter protocol?".
それはAAAの事実上の電流とデジュール標準であるようにRADIUS ++は、AAAプロトコルの要件の多くを満たします。うまくRADIUSとNASREQ WG議事録に記載されているRADIUSでの長年の欠点があります。これらの問題を解決するためにRADIUSを刷新することは技術的には可能です。よくある質問は、しかし、である：「有意差が完成RADIUS ++プロトコルとDiameterプロトコルの間があるだろうか？」。
Recommended in part. What may possibly be learned from this submission is that it is feasible to have a more RADIUS-compliant RADIUS-compatibility mode in Diameter.
一部にはおすすめです。どのような可能性がこの投稿から学ぶことができること、直径がよりRADIUS準拠のRADIUS互換モードを持つことが可能であるということです。
C.5 Diameter PRO Evaluation
C.5直径PRO評価
Evaluation of Diameter against the AAA Requirements PRO Evaluation Evaluator - Basavaraj Patil
AAAの要件PRO評価評価者に対する直径の評価 - Basavarajパティル
Ref [1] is "Diameter Framework Document". Ref [2] is "Diameter NASREQ Extensions". Ref [3] is the AAA evaluation criteria as modified by us. Ref [4] is "Diameter Accounting Extensions". Ref [5] is "Diameter Mobile IP Extensions". Ref [6] is "Diameter Base Protocol". Ref [7] is "Diameter Strong Security Extension". Ref [8] is "Comparison of Diameter Against AAA Network Access Requirements".
参考文献[1]「直径フレームワークドキュメント」です。文献[2]は "直径NASREQ拡張機能" です。参考文献[3]米国で変更されるAAAの評価基準です。参考文献[4]「直径アカウンティング拡張」です。文献[5]「直径のモバイルIP拡張機能」です。参考文献[6]「直径ベースプロトコル」です。文献[7]「直径強力なセキュリティ拡張機能」です。文献[8]「AAAネットワークアクセス要件に対する直径の比較」です。
The document uses T to indicate total compliance, P to indicate partial compliance and F to indicate no compliance.
文書にはコンプライアンスを示さないために部分的コンプライアンス及びFを示すために、トータルコンプライアンス、Pを示すために、Tを使用します。
Evaluator's note : The Diameter compliance document [8] claims Total "T" compliance with all the requirements except : - 1.2.5 - 1.5.2
評価者のノート：直径コンプライアンス文書[8]を除くすべての要件との合計「T」の準拠を主張する： - 1.5.2 - 1.2.5
Section 1 - Per item discussion
第1節 - 商品ディスカッションパー
Diameter is an evolution of RADIUS and has taken into consideration all the lessons learned over many years that RADIUS has been in service. The use of SCTP as the transport protocol reduces the need for multiple proxy servers (Sec 3.1.1 Proxy Support of [1]) as well as removing the need for application level acks. The use and support of forwarding and redirect brokers enhances scalability. Evaluator concurs with the "T" compliance on this requirement.
直径は、RADIUSの進化であり、すべてのレッスンは、RADIUSがサービスされてきた長年にわたって学んで考慮されています。トランスポートプロトコルとしてSCTPを使用することは、複数のプロキシサーバーの必要（[1]の章3.1.1プロキシサポート）ならびにアプリケーションレベルのACKの必要性を除去することを減少させます。使用およびサポート転送のやブローカーをリダイレクトするには、スケーラビリティが向上します。評価者は、この要件の「T」の準拠に同意します。
Again with the use of SCTP, Diameter is able to detect disconnect indications upon which it switches to an alternate server (Sec 4.0 [6]). Also Requests and Responses do not have to follow the same path and this increases the reliability. Evaluator concurs with the "T" compliance on this requirement.
再びSCTPを使用して、直径は、それが代替サーバに切り替えた際に切断指示を検出することができる（秒4.0 [6]）。また、リクエストとレスポンスは同じ道をたどる必要はありません、これは信頼性を向上させます。評価者は、この要件の「T」の準拠に同意します。
The compliance document quotes the use of symmetric transforms for mutual authentication between the client and server (Sec 7.1 of [6]). The use of IPSec as an underlying security mechanism and thereby use the characteristics of IPSec itself to satisfy this requirement is also quoted. Evaluator concurs with the "T" compliance on this requirement.
コンプライアンス文書は、クライアントとサーバ（[6]の章7.1）との間の相互認証のための対称的な変換の使用を引用します。これにより、基礎となるセキュリティ機構としてのIPSecを使用すると、この要件を満たすためのIPSec自体の特性を使用することも引用されています。評価者は、この要件の「T」の準拠に同意します。
Although this requirement has been deprecated by the AAA evaluation team the document complies with it based on the definition (referring to hop-by-hop security). Section 7.1 of [6] provides the details of how this is accomplished in Diameter. Evaluator concurs with the "T" compliance on this requirement.
この要件は、AAA評価チームによって廃止されましたが、文書は、定義（ホップバイホップするセキュリティ参照）に基づいて、それに準拠しています。セクション7.1 [6]これは、直径が達成される方法の詳細を提供します。評価者は、この要件の「T」の準拠に同意します。
This requirement seems to have come from Diameter. Ref [7] explains in detail the use of Cryptographic Message Syntax (CMS) to achieve data object confidentiality. A CMS-Data AVP is defined in [7]. Evaluator concurs with the "T" compliance on this requirement.
この要件は、Diameterから来ているようです。参考文献[7]に詳細にデータオブジェクトの機密性を達成するために、暗号メッセージ構文（CMS）の使用を説明します。 CMS-データAVPは[7]で定義されています。評価者は、この要件の「T」の準拠に同意します。
Using the same argument as above and the hop-by-hop security feature in the protocol this requirement is completely met by Diameter. Evaluator concurs with the "T" compliance on this requirement.
上記と同じ引数と、この要件を完全に直径によって満たされるプロトコルでホップバイホップセキュリティ機能を使用して。評価者は、この要件の「T」の準拠に同意します。
Again with the use of the CMS-Data AVP, objects defined as these types of attributes allow the transport of certificates. Evaluator concurs with the "T" compliance on this requirement.
再びCMS-データAVPを使用して、属性のこれらのタイプとして定義されたオブジェクトは、証明書の輸送を可能にします。評価者は、この要件の「T」の準拠に同意します。
Diameter recommends that the protocol be run over SCTP. SCTP provides the features described for a reliable AAA transport. Although the compliance is not a perfect fit for the definition of this tag item, it is close enough and the functionality achieved by using SCTP is the same. Evaluator concurs with the "T" compliance on this requirement.
直径は、プロトコルがSCTP上で実行されることをお勧めします。 SCTPは、信頼できるAAA輸送のために説明した機能を提供します。コンプライアンスは、このタグの項目の定義にぴったりではありませんが、それは十分に近く、SCTPを使用することによって達成機能は同じです。評価者は、この要件の「T」の準拠に同意します。
Is an application layer protocol and does not depend on the underlying version of IP. Evaluator concurs with the "T" compliance on this requirement.
アプリケーション層のプロトコルであり、IPの基本的なバージョンに依存しません。評価者は、この要件の「T」の準拠に同意します。
Is an application layer protocol and does not depend on the underlying version of IP. Evaluator concurs with the "T" compliance on this requirement.
アプリケーション層のプロトコルであり、IPの基本的なバージョンに依存しません。評価者は、この要件の「T」の準拠に同意します。
Section 3.1.1/2 of the framework document [1] provides an explanation of how Diameter supports proxy and routing brokers. In fact it almost appears as though the requirement for a routing broker came from Diameter. Evaluator concurs with the "T" compliance on this requirement.
フレームワーク文書のセクション3.1.1 / 2 [1]直径がプロキシとルーティングブローカをサポートする方法の説明を提供します。ルーティングブローカーのための要件は直径から来たかのように実際にはほとんど表示されます。評価者は、この要件の「T」の準拠に同意します。
With the use of CMS-Data AVP [7] a trail is created when proxies are involved in the transaction. This trail can provide auditability. Evaluator concurs with the "T" compliance on this requirement.
プロキシが取引に関与しているとき、CMS-データAVPを使用して、[7]証跡が作成されます。このトレイルは、監査能力を提供することができます。評価者は、この要件の「T」の準拠に同意します。
With the use of IPSec as the underlying security mechanism, Diameter does not require the use of shared secrets for message authentication. Evaluator concurs with the "T" compliance on this requirement.
基本的なセキュリティメカニズムとしてのIPSecを使用すると、直径は、メッセージ認証用の共有秘密を使用する必要はありません。評価者は、この要件の「T」の準拠に同意します。
The base protocol [6] is defined by Diameter and any one else can define specific extensions on top of it. Other WGs in the IETF can design an extension on the base protocol with specific attributes and have them registered by IANA. Evaluator concurs with the "T" compliance on this requirement.
基本プロトコル[6]直径によって定義され、他のいずれかがそれの上に特定の拡張機能を定義することができます。 IETFの他のWGは、特定の属性を持つ基本プロトコルの拡張を設計することができ、それらは、IANAによって登録されています。評価者は、この要件の「T」の準拠に同意します。
The base protocol [6] defines an AVP that can be used to support NAIs. Diameter goes one step further by doing Message forwarding based on destination NAI AVPs. Evaluator concurs with the "T" compliance on this requirement.
ベースプロトコルは、[6]のNAIをサポートするために使用することができるAVPを定義します。直径が先NAIのAVPに基づいてメッセージの転送を行うことで、さらに一歩行きます。評価者は、この要件の「T」の準拠に同意します。
Reference [2] section 3.0 describes the support for CHAP. Evaluator concurs with the "T" compliance on this requirement.
リファレンス[2]セクション3.0は、CHAPのためのサポートについて説明します。評価者は、この要件の「T」の準拠に同意します。
Reference [2] section 4.0 describes the support for EAP. Evaluator concurs with the "T" compliance on this requirement.
リファレンス[2]セクション4.0は、EAPのためのサポートについて説明します。評価者は、この要件の「T」の準拠に同意します。
Reference [2] section 3.1.1.1 describes the support for PAP. Evaluator concurs with the "T" compliance on this requirement.
リファレンス[2]セクション3.1.1.1は、PAPのためのサポートについて説明します。評価者は、この要件の「T」の準拠に同意します。
The use of Session-Timeout AVP as the mechanism for reauthentication is claimed by the compliance document. However no direct references explaining this in the base protocol [6] document were found.
再認証のためのメカニズムとしてセッションタイムアウトAVPの使用は、コンプライアンス文書で主張されています。しかし、基本プロトコルでこれを説明するための直接的な参照は、[6]文書が見つかりませんでした。
Evaluator deprecates the compliance on this to a "P"
評価者は、「P」に、この上のコンプライアンスを非難します
Note: However this is a trivial issue.
注意：ただし、これは些細な問題です。
Diameter allows requests to be sent without having any authentication information included. A Request-type AVP is defined in [2] and it can specify authorization only without containing any authentication. Evaluator concurs with the "T" compliance on this requirement.
直径は、要求が含まれる任意の認証情報を有することなく送信されることを可能にします。要求タイプAVPは、[2]で定義されており、それだけで、任意の認証を含まない許可を指定することができます。評価者は、この要件の「T」の準拠に同意します。
The base protocol includes an AVP for carrying the address. References [6.2.2 of 2] and [4.5 of 5] provide detailed explanations of how this can be done. Evaluator concurs with the "T" compliance on this requirement.
ベース・プロトコルアドレスを運ぶためのAVPを含みます。参考文献[2の6.2.2]と[5の4.5]はこれを行う方法の詳細な説明を提供しています。評価者は、この要件の「T」の準拠に同意します。
One of the basic facets of Diameter is to support backward compatibility and act as a RADIUS gateway in certain environments. Evaluator concurs with the "T" compliance on this requirement.
直径の基本的な面の一つは、特定の環境におけるRADIUSゲートウェイとして下位互換性と行為をサポートすることです。評価者は、この要件の「T」の準拠に同意します。
Based on the explanation provided in the compliance document for this requirement evaluator concurs with the "T" compliance on this requirement.
この要件の評価のためのコンプライアンス・マニュアルに記載されている説明に基づいて、この要件の「T」の準拠に同意。
Ref [2] defines AVPs supporting L2 tunnels Evaluator concurs with the "T" compliance on this requirement.
参考文献[2] L2は、評価者は、この要件の「T」コンプライアンスに同意トンネル支持AVPを定義します。
A session timer defined in [6] is used for reauthorization. However Diameter allows reauthorization at any time. Since this is a peer-to-peer type of protocol any entity can initiate a reauthorization request. Evaluator concurs with the "T" compliance on this requirement.
[6]で定義されたセッションタイマが再承認のために使用されます。しかし、直径はいつでも再認可することができます。このプロトコルのピア・ツー・ピア型であるため、任意のエンティティは、再認可要求を開始することができます。評価者は、この要件の「T」の準拠に同意します。
Diameter defines two methods. One that supports backward compatibility for RADIUS and another one with the use of a standard AVP with the filters encoded in it. Evaluator concurs with the "T" compliance on this requirement.
直径が2つのメソッドを定義します。下位RADIUSのための互換性とそれにエンコードされたフィルタを備えた標準のAVPを使用して別のものをサポートしていますワン。評価者は、この要件の「T」の準拠に同意します。
A long explanation on each of the points defined for this tag item in the requirements document. Evaluator concurs with the "T" compliance for this requirement.
要件文書では、このタグ項目に対して定義された点のそれぞれに長い説明。評価者は、この要件のための「T」コンプライアンスに同意します。
The base protocol [6] defines a set of session termination messages which can be used for unsolicited disconnects. Evaluator concurs with the "T" compliance on this requirement.
基本プロトコル[6]は未承諾の切断のために使用することができるセッション終了メッセージのセットを定義します。評価者は、この要件の「T」の準拠に同意します。
Evaluator concurs with the "T" compliance based on explanations in [4].
評価者は、[4]での説明に基づいて、「T」コンプライアンスに同意します。
Use of Accounting Data Interchange Format (ADIF)-Record-AVP for compact encoding of accounting data. Evaluator concurs with the "T" compliance.
会計データのコンパクトなエンコーディングのための会計データ交換フォーマット（ADIF）-record-AVPの使用。評価者は、「T」の準拠に同意します。
ADIF can be extended. Evaluator concurs with the "T" compliance.
ADIFを拡張することができます。評価者は、「T」の準拠に同意します。
Sec 1.2 of [4] provides support for batch accounting.
[4]の秒1.2は、バッチ会計のためのサポートを提供します。
Sections 2.1/2 of [4] describe messages that are used to guarantee delivery of accounting records. Evaluator concurs with the "T" compliance.
[4]アカウンティングレコードの配信を保証するために使用されるメッセージを説明のセクション2.1 / 2。評価者は、「T」の準拠に同意します。
Timestamp AVP [6] is present in all accounting messages. Evaluator concurs with the "T" compliance.
タイムスタンプAVP [6]は、すべてのアカウンティングメッセージに存在しています。評価者は、「T」の準拠に同意します。
Interim accounting records equivalent to a call-in-progress can be sent periodically. Evaluator concurs with the "T" compliance.
通話中に相当中間会計記録を定期的に送信することができます。評価者は、「T」の準拠に同意します。
Ref [5] provides details of how Diameter can encode MIP messages. Evaluator concurs with the "T" compliance.
参考文献[5]直径はMIPメッセージをエンコードする方法の詳細を提供します。評価者は、「T」の準拠に同意します。
Some handwaving here and a possible way of solving the firewall problem with a Diameter proxy server. Document claims "T", evaluator deprecates it to a "P"
ここではいくつかのhandwavingと直径プロキシサーバーとファイアウォールの問題を解決するための可能な方法。文書が「T」を主張し、評価者は、「P」にそれを非難します
Diameter can assign a local home agent in a visited network in conjunction with the FA in that network. Evaluator concurs with the "T"
直径は、そのネットワークでFAと一緒に訪問したネットワーク内のローカルホームエージェントを割り当てることができます。評価者は、「T」に同意します
Summary Recommendation
推薦の概要
Diameter is strongly recommended as the AAA protocol. The experience gained from RADIUS deployments has been put to good use in the design of this protocol. It has also been designed with extensibility in mind thereby allowing different WGs to develop their own specific extension to satisfy their requirements. With the use of SCTP as the transport protocol, reliability is built in. Security has been addressed in the design of the protocol and issues that were discovered in RADIUS have been fixed. Diameter also is a session based protocol which makes it more scalable. The support for forwarding and redirect brokers is well defined and this greatly improves the scalability aspect of the protocol.
直径が強くAAAプロトコルとして推奨されます。 RADIUSの展開から得られた経験は、このプロトコルの設計にうまく利用に供されています。また、それによって異なるのWGは、その要件を満たすために、独自の特定の拡張子を開発できるようにする拡張性を考慮して設計されています。トランスポートプロトコルとしてSCTPを使用することで、信頼性が組み込まれています。セキュリティプロトコルの設計で対処されていて、RADIUSで発見された問題が修正されました。直径はまた、よりスケーラブルになり、セッションベースのプロトコルです。フォワーディングのサポートとブローカーをリダイレクトが明確に定義され、これは大幅プロトコルのスケーラビリティの側面を改善します。
Lastly the protocol has been implemented by at least a few people and interop testing done. This in itself is a significant step and a positive point for Diameter to be the AAA protocol.
最後に、プロトコルは、少なくとも少数の人々によって実装されており、相互運用性テストが行われ。それ自体では、これは重要なステップと直径がAAAプロトコルであるために正の点です。
C.6 Diameter CON Evaluation
C.6直径CON評価
Evaluation of Diameter against the AAA Requirements CON Brief Evaluator: Barney Wolff
CONブリーフ評価者AAAの要件に対する直径の評価：バーニーヴォルフ
Section 1 - Per item discussion
第1節 - 商品ディスカッションパー
1.1.1 Scalability - P (was T) The evaluator is concerned with scalability to the small, not to the large. Diameter/SCTP may prove difficult to retrofit to existing NAS equipment.
1.1.1スケーラビリティ - P（Tであった）評価を小に、大きくないとスケーラビリティに関するものです。直径/ SCTPは、既存のNAS機器に改造することは困難証明することがあります。
1.1.2 Fail-over - P (was T) SCTP gives an indication of peer failure, but nothing in any Diameter or SCTP document the evaluator was able to find even mentions how or when to switch back to a primary server to which communication was lost. After a failure, the state machines end in a CLOSED state and nothing seems to trigger exit from that state. It was not clear whether a server, on rebooting, would initiate an SCTP connection to all its configured clients. If not, and in any case when the communication failure was in the network rather than in the server, the client must itself, after some interval, attempt to re-establish communication. But no such guidance is given.
1.1.2フェールオーバー - P（Tであった）SCTPは、ピアの障害の指標を与えるが、どの場合やバック通信があったプライマリサーバへの切り替えを任意の直径又はSCTP文書に評価者が見つけることができた何も述べていません失われました。障害が発生した後、ステート・マシンは、CLOSED状態で終了し、何もその状態からの退出をトリガするようです。サーバーは、再起動するには、そのすべての構成されたクライアントへのSCTP接続を開始するかどうかは明らかではなかったです。そうでない場合は、通信ネットワークに障害がなく、サーバーにあったどのような場合には、クライアント自体は、いくつかの間隔の後、再確立通信に試みなければなりません。しかし、そのような指導が与えられていません。
Of course, the requirement itself fails to mention the notion of returning to a recovered primary. That is a defect in the requirement. The evaluator has had unfortunate experience with a vendor's RADIUS implementation that had exactly the defect that it often failed to notice recovery of the primary.
もちろん、要件自体が回復し、主に戻るの概念を言及しませんでした。これは、要件の欠陥です。評価者は、それは多くの場合、主の回復に気づくことができなかった正確に欠陥があったベンダーのRADIUS実装と不幸な経験をしてきました。
1.1.5 Data Object Confidentiality - P (was T). Yes, the CMS data type is supported. But the work in progress, "Diameter Strong Security Extension", says:
1.1.5データ・オブジェクトの機密性 - P（Tでした）。はい、CMSのデータ型がサポートされています。しかし、進行中の作業は、「直径強力なセキュリティ拡張機能」、言います：
Given that asymmetric transform operations are expensive, Diameter servers MAY wish to use them only when dealing with inter-domain servers, as shown in Figure 3. This configuration is normally desirable since Diameter entities within a given administrative domain MAY inherently trust each other. Further, it is desirable to move this functionality to the edges, since NASes do not necessarily have the CPU power to perform expensive cryptographic operations.
非対称変換操作は高価であることを考えると、直径サーバは、特定の管理ドメイン内の直径エンティティは、本質的に互いに信頼性があるため、この設定は通常、望ましい図3に示すように、ドメイン間のサーバーを扱う場合にのみ、それらを使用することもできます。 NASは必ずしも高価な暗号化操作を実行するためのCPUパワーを持っていないので、エッジにこの機能を移動することが望ましいです。
Given all the fuss that has been made about "end-to-end" confidentiality (which really means "NAS-to-home_server"), the evaluator finds it absurd that the proposed solution is acknowledged to be unsuited to the NAS.
（実際には「NASツーhome_server」を意味）「エンドツーエンド」の機密性について説明したすべての大騒ぎを考えると、評価者は、提案された解決策は、NASには不向きであることを認めていること、それは不合理見つけました。
1.1.12 Auditability - T (based on our interpretation as non-repudiation, rather than the definition given in reqts)
1.1.12監査能力 - T（むしろreqtsに与えられた定義よりも、否認防止など、当社の解釈に基づいて）
1.2.5 Reauthentication on demand - P (was T). No mechanism was evident for the server to demand a reauthentication, based for example on detection of suspicious behavior by the user. Session-timeout is not sufficient, as it must be specified at the start.
オンデマンド1.2.5再認証 - P（Tでした）。サーバは、ユーザによる疑わしい挙動の検出に例えば基づいて再認証を要求するためのメカニズムは明らかではなかったです。セッションタイムアウトそれは開始時に指定しなければならないよう、十分ではありません。
1.3.2 RADIUS Gateway Capability - P (was T). RADIUS has evolved from the version on which Diameter was based. EAP is a notable case where the convention that the Diameter attribute number duplicates the RADIUS one is violated. No protocol, not even RADIUS++, can claim a T on this.
1.3.2 RADIUSゲートウェイ機能 - P（Tでした）。 RADIUSは、直径がベースれたバージョンから進化してきました。 EAPは、Diameter属性番号がRADIUS 1を複製規則に違反した顕著な場合です。いいえプロトコルではなく、さらにRADIUS ++は、これにTを主張することはできません。
1.3.3 Reject Capability - T (The evaluator fails to understand how any AAA protocol could rate anything other than T on this.)
1.3.3は機能を拒否 - T（評価者は、任意のAAAプロトコルがこの上のT以外のものを評価可能性がどのように理解することができません。）
1.3.5 Reauth on Demand - P (was T). As with reauthentication, there is no evident mechanism for the server to initiate this based on conditions subsequent to the start of the session.
オンデマンド1.3.5再認証 - P（Tでした）。再認証と同様に、サーバは、セッションの開始の後の条件に基づいて、これを開始するための明白なメカニズムは存在しません。
1.3.6 Support for ACLs - P (was T). The evaluator finds the Filter-Rule AVP laughably inadequate to describe filters. For example, how would it deal with restricting SMTP to a given server, unless all IP options are forbidden so the IP header length is known? No real NAS could have such an impoverished filter capability, or it would not survive as a product.
ACLの1.3.6サポート - P（Tでした）。評価者は、フィルタを記述するために、フィルタ・ルールのAVPは、ばかばかしいほど不十分で見つけました。例えば、どのようにIPヘッダの長さが知られているように、すべてのIPオプションが禁止されていない限り、特定のサーバーへのSMTPを制限に対処するのでしょうか？本当のNASは、このような貧しいフィルタ機能を持っていないか、またはそれが製品として生き残ることができません。
1.3.7 State Reconciliation - P (was T). It is difficult for the evaluator to understand how this is to work in a multi-administration situation, or indeed in any proxy situation. Furthermore, SRQ with no session-id is defined to ask for info on all sessions, not just those "owned" by the requester.
1.3.7状態調整 - P（Tでした）。評価者は、これが、マルチ管理状況で、あるいは実際には任意のプロキシの状況で動作するようにであるかを理解することは困難です。さらに、無セッションIDを持つSRQは、すべてのセッションでの情報のための要求者によって「所有」だけでなく、それらを尋ねるように定義されています。
1.4.4 Batch Accounting - P (was T). The evaluator suspects that simply sending multiple accounting records in a single request is not how batch accounting should or will be done.
1.4.4バッチ会計 - P（Tでした）。評価者は、単に単一の要求で複数の会計記録を送信することは、バッチ会計または行われるべきかではないことを疑います。
1.4.6 Accounting Timestamps - T (The evaluator notes with amusement that NTP time cycles in 2036, not 2038 as claimed in the Diameter drafts. It's Unix time that will set the sign bit in 2038.)
1.4.6会計タイムスタンプ - T（。2036年におけるNTPタイムサイクルは、直径ドラフトに記載いない2038としてアミューズメントと評価者のメモこれは、2038で符号ビットをセットするUNIX時間です）
1.5.2 Firewall Friendly - F (was T). Until such time as firewalls are extended to know about or proxy SCTP, it is very unlikely that SCTP will be passed. Even then, the convenient feature of being able to send a request from any port, and get the reply back to that port, means that a simple port filter will not be sufficient, and statefulness will be required. Real friendship would require that both source and dest ports be 1812.
1.5.2ファイアウォールフレンドリー - F（T）でした。ファイアウォールはおよそまたはプロキシSCTPを知っているように拡張されているような時間までは、SCTPが渡されることはほとんどありません。その後も、任意のポートからのリクエストを送信し、戻ってそのポートへの回答を得ることができるという便利な機能は、簡単なポートフィルタが十分ではない、とステートフル性が要求されることを意味します。本当の友情は両方のソースとdestのポートが1812であることが必要となります。
In some areas, Diameter is not completely thought through. In general, real effort has gone into satisfying a stupendous range of requirements.
一部の地域では、直径は完全に考え抜かれていません。一般的には、本当の努力は、要件の途方もない範囲を満たすに行ってきました。
Diameter certainly fails the KISS test. With SCTP, the drafts add up to 382 pages - well over double the size of RADIUS even with extensions. The evaluator sympathizes with the political instinct when faced with a new requirement no matter how bizarre, to say "we can do that" and add another piece of filigree. But the major places where Diameter claims advantage over RADIUS, namely "end-to-end" confidentiality and resource management, are just the places where some hard work remains, if the problems are not indeed intractable.
直径は確かにKISSテストを失敗しました。 SCTPでは、ドラフトは382ページまで追加 - まあでも、拡張子を持つRADIUSのダブルサイズの上に。フィリグリーの別の部分を追加し、「私たちはそれを行うことができます」と言って、どんなに奇妙な新しい要件に直面していないとき、評価者は、政治的本能と同情します。問題は確かに難治でない場合でも、直径がRADIUSに対する優位性を主張し、主要な場所、すなわち「エンド・ツー・エンド」の機密性とリソース管理は、いくつかのハードワークが残っているだけの場所です。
More specifically, the evaluator sees no indication that specifying the separate transport protocol provided any advantage to defray the large increase in complexity. Application acks are still required, and no benefit from the transport acks was evident to the evaluator. Nor was there any obvious discussion of why "sequenced in-order" delivery is required, when AAA requests are typically independent. SCTP offers out-of-order delivery, but Diameter seems to have chosen not to use that feature.
より具体的には、評価者は、別のトランスポートプロトコルを指定することは複雑で大きな増加を負担するために、任意の利点を提供したという表示を見ません。アプリケーションACKは依然として必要とされ、そして輸送のACKからの利益は、評価者には明らかではなかったです。 NOR AAA要求は一般的に独立しているとき「の順に配列決定」の配信を、必要とされる理由のいずれかの明白な議論がありました。 SCTPは、アウトオブオーダーの配信を提供していますが、直径はその機能を使用しないことを選択しているようです。
Whether TLV encoding or ASN.1/BER is superior is a religious question, but Diameter manages to require both, if the "strong" extension is implemented. The evaluator has a pet peeve with length fields that include the header, making small length values invalid, but that is a minor point.
TLVエンコーディングまたはASN.1 / BERが優れているかどうかは、宗教的な質問ですが、「強い」拡張が実装されている場合の直径は、両方を必要とするように管理しています。評価者は、短い長さの値が無効なって、ヘッダを含む長さフィールドを持つペットpeeveを有し、それはマイナーな点です。
Finally, interoperability would be greatly aided by defining a standard "dictionary" format by which an implementation could adopt wholesale a set of attributes, perhaps from another vendor, and at least know how to display them. That is one of the advantages of MIBs.
最後に、相互運用性が大幅に実装は、おそらく別のベンダーから、属性の卸売セットを採用し、少なくともそれらを表示する方法を知っている可能性があることにより、標準の「辞書」のフォーマットを定義することによって支援されるだろう。これはMIBのの利点の一つです。
Diameter is clearly close enough to meeting the myriad requirements that it is an acceptable candidate, though needing some polishing. Whether the vast increase in complexity is worth the increase in functionality over RADIUS is debatable.
直径は、いくつかの研磨を必要とするものの、それは、許容可能な候補である無数の要件を満たすには十分明確に近接しています。複雑で膨大な増加は、RADIUSを超える機能の増加の価値があるかどうかは議論の余地があります。
C.7 COPS PRO Evaluation
C.7 COPS PRO評価
Evaluation of COPS AAA Requirements PRO Evaluation Evaluator - David Nelson
デビッド・ネルソン - COPS AAA要件PRO評価評価者の評価
Ref [1] is "Comparison of COPS Against the AAA NA Requirements", work in progress, a.k.a. 'the document' Ref [2] is RFC 2748 a.k.a. 'the protocol' Ref [3] is the AAA evaluation criteria as modified by us. Ref [4] is "AAA Protocols: Comparison between RADIUS, Diameter, and COPS" work in progress. Ref [5] is "COPS Usage for AAA", work in progress.
参考文献[1]別名「文書」は、参考文献[2] RFC 2748年米国で変更される別名「プロトコル」は、参考文献[3] AAAの評価基準である「AAA NA要件に対するCOPSの比較」、進行中の作業であり、 。進行中の作業：「RADIUS、直径、およびCOPSの比較AAAプロトコル」参考文献[4]です。文献[5]は「AAAのためのCOPSの使用」、進行中の作業です。
This document uses T to indicate total compliance, P to indicate partial compliance and F to indicate no compliance.
この文書には、コンプライアンスを示さないために部分的コンプライアンス及びFを示すために、トータルコンプライアンス、Pを示すために、Tを使用します。
Section 1 - Per item discussion
第1節 - 商品ディスカッションパー
1.1.1 Scalability - The document [1] claims "T", and the evaluator concurs.
1.1.1スケーラビリティ - 文書[1]は「T」を主張し、評価者は同意します。
1.1.2 Fail-over - The document [1] claims "T", and the evaluator concurs.
1.1.2フェールオーバー - ドキュメント[1]は「T」を主張し、評価者は同意します。
1.1.3 Mutual Authentication - The document claims "T", and the evaluator concurs.
1.1.3相互認証 - 文書が「T」を主張し、評価者は同意。
1.1.4 Transmission Level Security - The document [1] indicates that transmission layer security, as defined in [3], is provided in the protocol, using the mechanisms described in [2]. It should be noted that this requirement is now a SHOULD in [3]. The document claims "T", and the evaluator concurs.
1.1.4トランスミッションレベルセキュリティ - で定義されるように文書[1]、その透過層セキュリティを示す[3]、[2]に記載のメカニズムを使用して、プロトコルで提供されます。この要件は、今ではSHOULDであることに留意すべきである[3]。文書には、「T」を主張し、評価者は同意します。
1.1.5 Data Object Confidentiality - The document [1] indicates that end-to-end confidentiality is provided using a CMS-data attribute, based in large part upon RFC 2630. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. The document claims "T", and the evaluator concurs.
1.1.5データ・オブジェクトの機密性 - 文書[1]評価者は、この時点での適用性を検討していないRFC 2630上に大部分的に基づいて、エンド・ツー・エンドの機密性をCMSデータ属性を使用して提供されていることを示しAAAの作品へのRFC 2630。文書には、「T」を主張し、評価者は同意します。
1.1.6 Data Object Integrity - The document [1] indicates that data object integrity is provided using a CMS-data attribute, based in large part upon RFC 2630. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. The document claims "T", and the evaluator concurs.
1.1.6データ・オブジェクトの整合性 - 文書[1]評価者は、この時にRFC 2630の適用可能性を検討していないRFC 2630上に大部分的に基づいて、データオブジェクトの完全性をCMSデータ属性を使用して提供されていることを示しAAAの作品。文書には、「T」を主張し、評価者は同意します。
1.1.7 Certificate Transport - The document [1] indicates that certificate transport is provided using a CMS-data attribute, based in large part upon RFC 2630 and RFC 1510. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. The document claims "T", and the evaluator concurs.
1.1.7証明書交通 - ドキュメント[1]は、証明書の輸送はRFC 2630およびRFC 1510により、大部分的に基づいて、CMS-データ属性を使用して提供された評価者は、この時点では、RFC 2630の適用性を検討していないことを示しAAAの作品に。文書には、「T」を主張し、評価者は同意します。
1.1.8 Reliable AAA Transport - The document [1] indicates that COPS uses TCP, which certainly meets the requirements for a reliable transport. The document claims "T", and the evaluator concurs.
1.1.8信頼できるAAA交通 - ドキュメント[1]は、COPSは確かに信頼性の高い輸送のための要件を満たしているTCPを使用していることを示しています。文書には、「T」を主張し、評価者は同意します。
1.1.9 Run over IPv4 - The document [1] claims "T", and the evaluator concurs.
IPv4の上1.1.9ラン - 文書[1]は「T」を主張し、評価者は同意します。
1.1.10 Run over IPv6 - The document [1] claims "T", and the evaluator concurs.
IPv6を介し1.1.10ラン - 文書[1]は「T」を主張し、評価者は同意します。
1.1.11 Support Proxy and Routing Brokers - Reasonable detail of proxy operations is provided in [5]. The document [1] claims "T", and the evaluator concurs.
1.1.11サポートプロキシとルーティングブローカー - プロキシ操作の合理的な詳細は[5]で提供されます。文書[1]は「T」を主張し、評価者は同意します。
1.1.12 Auditability - The document [1] alludes to a History PIB that would enable auditing without explaining how it would work. The AAA Extension [5] does not provide additional insight. The document claims "T", and the evaluator awards "P".
1.1.12監査能力 - ドキュメント[1]は、それがどのように動作するかを説明せずに監査を可能にする歴史PIBを暗示します。 AAA拡張[5]は、追加の洞察を提供していません。文書は「T」と主張、および評価者賞「P」。
1.1.13 Shared Secret Not Required - The document [1] claims "T" and the evaluator concurs.
1.1.13共有秘密必須ではありません - ドキュメント[1]「T」を主張し、評価者は同意。
1.1.14 Ability to Carry Service Specific Attributes - The document [1] claims "T", and the evaluator concurs.
1.1.14能力は、サービス固有の属性を運ぶために - 文書[1]は「T」を主張し、評価者は同意します。
1.2.1 NAI Support - The document [1] indicates that NAI is to be supported in the Information Model, but notes that for cases where certificates are in use, the more restrictive syntax of RFC 2459 applies. The document claims "T", and the evaluator awards "P".
1.2.1 NAIのサポート - ドキュメント[1]はNAIは情報モデルでサポートされることを示しますが、証明書を使用している場合のために、RFC 2459のより制限構文が適用されることを指摘しています。文書は「T」と主張、および評価者賞「P」。
1.2.2 CHAP Support - The document [1] claims "T", and the evaluator concurs.
1.2.2 CHAPサポート - ドキュメント[1]は "T" を主張し、評価者は同意。
1.2.3 EAP Support - The document [1] claims "T", and the evaluator concurs.
1.2.3 EAPサポート - ドキュメント[1]は "T" を主張し、評価者は同意。
1.2.4 PAP/Clear-text Passwords - The document [1] indicates compliance, presumably using a CMS-data attribute, based in large part upon RFC 2630. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. The document claims "T", and the evaluator concurs.
1.2.4 PAP /クリアテキストのパスワード - ドキュメント[1]評価者は、この時点では、RFCに2630の適用可能性を検討していないRFC 2630により、大部分的に基づいて、おそらくCMS-データ属性を使用して、準拠していることを示しAAAの作品。文書には、「T」を主張し、評価者は同意します。
1.2.5 Reauthentication on demand - The document [1] claims "T", and the evaluator concurs.
オンデマンド1.2.5再認証 - 文書[1]は「T」を主張し、評価者は同意します。
1.2.6 Authorization w/o Authentication - This requirement, as applied to the protocol specification, mandates that non- necessary authentication credentials not be required in a request for authorization. The actual decision to provide authorization in the absence of any authentication resides in the application (e.g. AAA server). The document [1] claims "T", and the evaluator concurs.
認証O / W 1.2.6認可 - この要件は、プロトコル仕様、認可要求で要求されていない、必要な認証情報を非義務に適用されます。任意認証の不在下で認可を提供するために実際の決定は、アプリケーション（例えば、AAAサーバ）に存在します。文書[1]は「T」を主張し、評価者は同意します。
1.3.1 Static and Dynamic IP Addr Assignment - The document [1] claims "T", and the evaluator concurs.
1.3.1静的および動的IP ADDR割り当て - 文書[1]「T」を主張し、評価者は同意。
1.3.2 RADIUS Gateway Capability - The document [1] claims "T", and in the absence of any detailed discussion of how this is accomplished, in either [1] or [5], the evaluator awards "P".
1.3.2 RADIUSゲートウェイ機能 - 文書[1]「T」を主張し、これは、[1]または[5]、評価者賞「P」のいずれかで、達成される方法のいずれかの詳細な議論が存在しない場合です。
1.3.3 Reject Capability - The document claims [1] "T" and the evaluator concurs.
1.3.3機能を拒否 - 文書請求項[1]「T」と評価者同意。
1.3.4 Preclude Layer 2 Tunneling - The document [1] claims "T", and in the absence of any detailed discussion of how this is accomplished, in either [1] or [5], the evaluator awards "P".
1.3.4排除して、レイヤ2トンネリング - 文書[1]「T」を主張し、これは、[1]または[5]、評価者賞「P」のいずれかで、達成される方法のいずれかの詳細な議論が存在しない場合です。
1.3.5 Reauth on Demand - The document [1] claims "T", and the evaluator concurs.
オンデマンド1.3.5再認証 - 文書[1]は「T」を主張し、評価者は同意します。
1.3.6 Support for ACLs - The document [1] "T", and the evaluator concurs.
1.3.6 ACLのサポート - 文書[1]、「T」、及び評価者は同意。
1.3.7 State Reconciliation - The document [1] "T", and the evaluator concurs.
1.3.7状態調整 - 文書[1]、「T」、及び評価者同意。
1.3.8 Unsolicited Disconnect - The document [1] claims "T", and the evaluator concurs.
1.3.8迷惑切断 - 文書[1]は「T」を主張し、評価者は同意します。
1.4.1 Real Time Accounting - The document [1] claims "T", and the evaluator concurs.
1.4.1リアルタイムアカウンティング - 文書[1]は「T」を主張し、評価者は同意します。
1.4.2 Mandatory Compact Encoding - Note that the term "bloated" in [3] is somewhat subjective. The document [1] claims "T", and the evaluator concurs.
1.4.2必須コンパクトエンコーディング - で「肥大化」という用語は、[3]幾分主観的であることに留意されたいです。文書[1]は「T」を主張し、評価者は同意します。
1.4.3 Accounting Record Extensibility - The document [1] claims "T", and the evaluator concurs.
アカウンティングレコード拡張1.4.3 - 文書[1]は「T」を主張し、評価者は同意します。
1.4.4 Batch Accounting - The protocol [2] [5] does not address how in detail this feature might be accomplished. The document [1] claims "T", and the awards "P".
1.4.4バッチ会計 - プロトコル[2] [5]この機能が実現されるかもしれない方法を詳細に扱っていません。文書[1]は "T"、及び賞 "P" を主張します。
1.4.5 Guaranteed Delivery - Guaranteed delivery is provided by TCP. The document [1] claims "T", and the evaluator concurs.
1.4.5保証付き配信 - 配信はTCPによって提供される保証。文書[1]は「T」を主張し、評価者は同意します。
1.4.6 Accounting Timestamps - The document [1] claims "T", and the evaluator concurs.
1.4.6会計タイムスタンプ - 文書[1]は「T」を主張し、評価者は同意します。
1.4.7 Dynamic Accounting - The document [1] claims "T", and the evaluator concurs.
1.4.7動的アカウンティング - 文書[1]は「T」を主張し、評価者は同意します。
1.5.1 Encoding of MOBILE IP Registration Messages - The document [1] claims "T", and the evaluator concurs.
モバイルIP登録メッセージの1.5.1エンコード - 文書[1]は「T」を主張し、評価者は同意します。
1.5.2 Firewall Friendly - The document [1] claims "T", and the evaluator concurs.
1.5.2ファイアウォールフレンドリー - 文書[1]は「T」を主張し、評価者は同意します。
1.5.3 Allocation of Local Home Agent - The document [1] claims "T", and the evaluator concurs.
ローカルホームエージェントの1.5.3配分 - ドキュメント[1]「T」を要求して、評価者は同意。
It may appear, upon initial inspection, that the evaluator has not lent a critical eye to the compliance assertions of the document [1]. First, this memo is a "PRO" brief, and as such reasonable benefit of doubt is to be given in favor of the protocol submission. Second, there is a fundamental conceptual issue at play. The COPS-PR model provides a sufficient set of basic operations and commands, a stateful model, the ability for either "peer" to initiate certain kinds of requests, as well as an extensible command set, to be able to support a wide variety of network and resource management protocols. The details of protocol specific messages is left to
評価者は、文書[1]のコンプライアンスの主張に批判的な目を貸していないことを、最初の検査時に、表示されることがあります。まず、このメモは、「PRO」簡単で、疑いのように合理的な利益などのプロトコルの提出に賛成して与えられることにあります。第二に、遊びの基本的な概念の問題があります。 COPS-PRモデルは多種多様をサポートすることができるように、基本的な操作とコマンドの十分なセット、ステートフルモデル、要求の特定の種類、ならびに拡張可能なコマンドセットを開始するための「ピア」のいずれかのための能力を提供しますネットワークおよび資源管理プロトコル。プロトコル特定のメッセージの詳細については、に任されています
Policy Information Base (PIB) data objects. Since no AAA PIB has been written, the evacuator can only (optimistically) assess the inherent capabilities of the base protocol to accomplish the intended requirements of [3], given a reasonable set of assumptions about what an AAA PIB might look like.
ポリシー情報ベース（PIB）データオブジェクト。何AAA PIBが書き込まれていないので、排気装置のみ（楽観）AAA PIBがどのように見えるかについての仮定の合理的なセットが与えられると、[3]の意図された要件を達成するために、ベースプロトコルの固有の能力を評価することができます。
In some sense, this akin to asserting that a given algorithm can be correctly implemented in a specific programming language, without actually providing the code.
指定されたアルゴリズムが正しく実際にコードを提供せず、特定のプログラミング言語で実装することができることを主張するにはいくつかの意味では、これは似。
The PIB model used by COPS is a powerful and flexible model. The protocol document [5] spends a considerable amount of time enumerating and describing the benefits of this data model, and explaining its roots in Object Oriented (OO) design methodology. Analogies are made to class inheritance and class containment, among others. It's always hard to say bad things about OO.
COPSが使用するPIBモデルは強力で柔軟なモデルです。プロトコル文献[5]このデータ・モデルの利点を列挙し、記述かなりの時間を費やし、オブジェクト指向（OO）設計手法でそのルーツを説明します。アナロジーは、とりわけ、クラス継承とクラスの封じ込めに作られています。これは、OOの悪口を言うのは常に難しいです。
COPS-AAA would appear to meet (totally or partially) all of the requirements of [3], at least as can be determined without the benefit of an AAA PIB.
COPS-AAAは、AAA PIBの恩恵なしに決定することができる少なくともとして、（完全にまたは部分的に）[3]の要件の全てを満たすように思われます。
Recommended with reservation. Before final acceptance of COPS-AAA, someone is going to have to write the AAA PIB and evaluate its details.
予約をお勧めします。 COPS-AAAの最終的な受け入れの前に、誰かがAAA PIBを書いて、その詳細を評価するために持っているとしています。
C.8 COPS CON Evaluation
C.8はCON評価をCOPS
Evaluation of COPS against the AAA Requirements CON Evaluation Evaluator - David Mitton
AAAの要件CON評価評価者に対するCOPSの評価 - デヴィッド・ミトン
The Primary document discussed here is [COPSComp] and the arguments therein based on the proposal [COPSAAA].
ここで説明する主な文書は、[COPSComp]で、引数は、その中に提案[COPSAAA]に基づきます。
[COPSComp] "Comparison of COPS Against the AAA NA Requirements", Work in Progress. [COPSAAA] "COPS Usage for AAA", Work in Progress. [EksteinProtoComp] "AAA Protocols: Comparison between RADIUS, Diameter, and COPS", Work in Progress.
[COPSComp]「AAA NA要件に対するCOPSの比較」が進行中で働いています。 [COPSAAA]、進行中の作業 "AAAの使用上のCOPS"。 【EksteinProtoComp "AAAプロトコル：RADIUS、直径、およびCOPSの比較"、ProgressのWork。
References: (in order of relevancy)
参考文献：（関連性の順番で）
[COPSBase] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The Common Open Policy Service Protocol", RFC 2748, January 2000.
[COPSBase]ダラム、D.、ボイル、J.、コーエン、R.、ヘルツォーク、S.、ラジャン、R.とA. Sastry、 "一般的なオープンポリシーサービスプロトコル"、RFC 2748、2000年1月。
[COPSFwork] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[COPSFwork] Yavatkar、R.、Pendarakis、D.とR.ゲラン、 "ポリシーベースのアドミッション制御のためのフレームワーク"、RFC 2753、2000年1月。
[COPSPR] "COPS Usage for Policy Provisioning", Work in Progress.
[COPSPR]が進行中で働いて「ポリシープロビジョニングの使用上のCOPS」。
[COPSSPPI] "Structure of Policy Provisioning Information (SPPI)", Work in Progress.
、進行中の作業[COPSSPPI]「ポリシープロビジョニング情報（SPPI）の構造」。
[COPSCMS] "COPS Over CMS", Work in Progress.
[COPSCMS] "CMSオーバーCOPS" が進行中で働いています。
[COPSTLS] "COPS Over TLS", Work in Progress.
[COPSTLS] "TLSオーバーCOPS" が進行中で働いています。
[COPSGSS] "COPS Extension for GSS-API based Authentication Support", Work in Progress.
、進行中の作業[COPSGSS] "GSS-APIベースの認証のサポートのためのCOPS拡張子を"。
Other COPS & RSVP RFCs & drafts not listed as not directly relevant.
その他のCOPS＆RSVPのRFC＆ドラフトは直接関係ないとしてリストされていません。
Compliance: T==Total, P==Partial, F=Failed
コンプライアンス：T ==合計、P ==部分、F =失敗
Section 1 - Per item discussion
第1節 - 商品ディスカッションパー
Initial Note: [COPSComp] claims "unconditional compliance" with all requirements.
初期注：[COPSComp]すべての要件に「無条件の遵守」を主張しています。
1.1.1 Scalability - P (was T) The evaluator is concerned with scalability of many always-on TCP connections to a server supporting a lot of clients, particularly with the heartbeat messages. The claim that the request handle is "unbounded" sounds fishy.
1.1.1スケーラビリティ - P（Tでした）評価者は常時オン、多くのスケーラビリティと懸念している、特にハートビートメッセージで、クライアントの多くをサポートするサーバへのTCP接続。要求ハンドルが「無制限」であるという主張は怪しいですね。
1.1.2 Fail-over - P (was T) COPS gives an indication of peer failure, and has mechanisms to restart state, but there seems to be a bias toward a single state server. COPS has decided that synchronizing state between multiple hot servers is out of scope.
1.1.2フェールオーバー - P（Tであった）COPSピア失敗の指示を与え、状態を再起動するための機構を有しているが、単一の状態サーバーへのバイアスがあるように思われます。 COPSは、複数のホットサーバ間で状態を同期すると、範囲外であることを決定しました。
Because COPS uses TCP, it is at the mercy of the TCP timers of the implementation which can be significant. Connection timeout reporting to the application may be delayed beyond the client authentication timeouts. Tuning the Keep-Alive message to a tighter period will increase the session and system overhead.
COPSは、TCPを使用しているため、それは重要なことができ、実装のTCPタイマーの慈悲です。アプリケーションへの報告接続タイムアウトは、クライアント認証のタイムアウトを超えて遅れることがあります。タイトな期間にキープアライブメッセージをチューニングすると、セッションおよびシステムのオーバーヘッドが増加します。
1.1.3 Mutual Authentication - P (was T) The explanation is sort of for message object integrity. It does not describe authentication techniques. The evaluator assumes that COPS peers would authenticate each other at Client-Open time. But cannot understand how this would work if proxies are involved.
1.1.3相互認証 - P（T）であった説明は、メッセージオブジェクトの完全性のソートのです。これは、認証技術を説明していません。評価者は、COPSピアは、クライアントのオープン時に互いを認証することを前提としています。しかし、プロキシが関与している場合、これはどのように動作するかを理解することはできません。
1.1.5 Data Object Confidentiality - T Seems almost a carbon copy of the Diameter capabilities. This evaluator echoes the high overhead concerns of the Diameter evaluator for the CMS capability. TLS is not mentioned here, but is piled on later.
1.1.5データオブジェクトの機密性 - Tは、Diameter機能のほとんどカーボンコピーです。この評価者は、CMS機能のための直径評価の高いオーバーヘッドの懸念をエコーします。 TLSは、ここに記載されていないが、後に積まれています。
1.1.8 Reliable AAA Transport - T (maybe P) COPS meets this requirement as well as any other protocol we've evaluated. That is it does have one application level ACK. Statements such as "TCP provides guaranteed delivery" are incorrect. COPS does attempt to identify outages by using a keep-alive message between TCP peers.
1.1.8信頼できるAAA交通 - T（多分P）COPSこの要件だけでなく、私たちが評価されてきた他のプロトコルを満たしています。つまり、1つのアプリケーション・レベルのACKを持っています。例えば、「TCPは保証された配信を提供します」などの文が正しくありません。 COPSは、TCPピア間のキープアライブメッセージを使用して停止を同定する試みを行います。
1.1.11 Support Proxy and Routing Brokers - P (was T) How client types are supported forward is not well understood by this evaluator. Does each client type require the Broker to make a different client Open request to it's upstream servers? What about routing brokers?
1.1.11サポートプロキシとルーティングブローカー - Pは、クライアントタイプが前方にサポートされているだけでなく、この評価者によって理解されていない方法（Tでした）。各クライアントタイプは、アップストリームサーバーだと、異なるクライアントのオープン要求をするためにブローカーを必要としていますか？どのようなブローカーのルーティングについてはどうですか？
1.1.12 Auditability - P (was T) (based on our interpretation as non-repudiation, rather than the definition given in reqts) The explanation of a History PIB is incomplete and therefore inconclusive.
1.1.12監査能力 - Pは（Tた）履歴PIBの説明は不完全したがって決定的である（否認防止ではなく、reqtsに与えられた定義のように我々の解釈に基づいて）。
1.1.13 Shared Secret Not Required - T Except this clause in [COPSAAA] 6.2 page 14 "COPS MUST be capable of supporting TLS"
1.1.13共有秘密必須ではありません - [COPSAAA] 6.2 14ページでこの句を除きT「COPSはTLSをサポートすることができなければなりません」
a) COPS only allows a small number of unique objects to be added. 256 Object "classes" or types, with 256 subtypes or versions. Client types are 16 bits long, where the high bit indicates "enterprise" specific values. But pertain to a COPS peer- connection session. The client type seems to just identify the information model for the message. eg. it will be fixed to one value for AAA.
A）COPSは、一意のオブジェクトの数が少ない添加されることを可能にします。 256オブジェクト「クラス」や種類、256個のサブタイプまたはバージョンで。クライアントタイプは、高ビットが「企業」特定の値を示す場合、16ビット長です。しかし、COPS peer-接続セッションに関係します。クライアントタイプは、ちょうどメッセージのための情報モデルを識別しているようです。例えば。それはAAAのための1つの値に固定されます。
b) Service specific objects are not the same as Vendor Specific Objects. They pertain to objects within a client type.
b）はサービス固有のオブジェクトは、ベンダー固有のオブジェクトと同じではありません。彼らは、クライアントタイプ内のオブジェクトに関係します。
c) The PIB model leads to a different model interoperability. Because most vendor product differ in some way, each PIB will be different, and sharing common provisioning profiles will be a rather difficult mapping problem on the server.
C）PIBモデルは、異なるモデルの相互運用性につながります。ほとんどのベンダー製品は、いくつかの方法が異なりますので、各PIBは異なるだろう、と共通プロビジョニングプロファイルを共有すると、サーバ上かなり難しいマッピングの問題になります。
d) It's not clear the different client types can be mixed or that other objects definitions can be used from other defined client types. It's really unclear how the client type of a connection propagates in a proxy situation.
D）それは別の種類のクライアントが混在することができたり、他のオブジェクトの定義が他の定義されたクライアントタイプから使用することができますはっきりしません。接続のクライアントタイプがプロキシ状況でどのように伝播するか、それは本当に不明です。
1.2.1 NAI Support - T The requirement that RFC 2459 (X.509 profiles) be met presumes that Auth servers would not have a mapping or local transformation.
NAIのサポート1.2.1 - T 2459（X.509プロファイルを）RFC要件が満たされることは、認証サーバがマッピングまたはローカル変換を持っていないことを前提としています。
1.2.2 CHAP Support - T An Information Model is being invoked, which I don't see really fleshed out anywhere. [COPSAAA] does a bit of handwaving and definitions but doesn't deliver much meat. Nonetheless, this could be handled ala RADIUS.
1.2.2 CHAPサポート - Tアン情報モデルは、私は本当にどこでも肉付けを参照しない、呼び出されています。 [COPSAAA] handwavingと定義のビットを行いますが、多くの肉を提供していません。それにもかかわらず、これはRADIUSたala処理することができます。
1.2.3 EAP Support - P (was T) Again with the non-existent Information Model. To do EAP, this evaluator thinks another Request or Decision type is needed here to indicate to proxies that an extended message exchange is in progress.
1.2.3 EAPサポート - Pは、存在しない情報モデルで再び（Tでした）。 EAPを行うには、この評価者は、別の要求や意思決定のタイプが拡張されたメッセージ交換が進行中であることをプロキシに示すために、ここで必要とされていると考えています。
The comment "Please note: with existing algorithms, any authorization scheme not based on prior authentication is meaningless" is meaningless out of application context.
コメントは、「ご注意：既存のアルゴリズムで、以前の認証に基づいていない任意の認証スキームが無意味である」アプリケーションコンテキストのうち無意味です。
1.3.2 RADIUS Gateway Capability - P (was T). It would be interesting to see RADIUS attributes wrapped in some COPS "Information Model".
1.3.2 RADIUSゲートウェイ機能 - P（Tでした）。いくつかのCOPS「情報モデル」に包まれたRADIUS属性を見るのは興味深いだろう。
More work for the "Information Model" author!
「情報モデル」の作者のためのより多くの仕事！
1.3.6 Support for Access Rules & Filters - P (was T) Yet more work for the "Information Model" author, including some design issues which alluded the RADIUS and Diameter designers. At least an attempt was made in Diameter. There is nothing here.
1.3.6アクセスルール＆フィルタのサポート - P（Tでした）しかし、RADIUSおよび直径デザイナーを暗に示したいくつかの設計上の問題を含む「情報モデル」の作者のためのより多くの仕事、。少なくとも試みが直径で行われました。ここには何もありません。
1.3.7 State Reconciliation - P (was T). It is difficult for the evaluator to understand how well the COPS mechanisms work in a multi-administration situation, or in any proxy situation. Multi-server coordination, if allowed, seems to be lacking a description.
1.3.7状態調整 - P（Tでした）。評価者は、COPSメカニズムがマルチ行政の状況で、または任意のプロキシ状況でどのように機能するかを十分に理解することが困難です。マルチサーバコーディネートは、許可されている場合、説明を欠いているように見えます。
1.4.2 Mandatory Compact Encoding - T This evaluator does not believe that ADIF is a compact format. But does believe that the Information Model author can design a PIB with accounting statistics that will satisfy this requirement.
1.4.2必須コンパクトエンコーディング - この評価者Tは、ADIFはコンパクトな形式であることを信じていません。しかし、情報モデル作成者がこの要件を満たすアカウンティング統計でPIBを設計することができると信じていません。
1.4.3 Accounting Record Extensibility - P (was T) By defining a vendor/device specific PIB for additional elements.
1.4.3アカウンティングレコード拡張 - Pは、付加的な要素は、ベンダー/デバイス固有のPIBを定義することにより（T）でした。
1.4.4 Batch Accounting - P (was T) Offered description does not seem to match the requirement.
1.4.4バッチ会計 - P（Tであった）提供される説明は、要件と一致していないようです。
1.4.5 Guaranteed Delivery - P (was T) TCP does NOT "guarantee delivery", only application Acks can do that. If these acks can be generated similar to the description here, then this requirement is met.
1.4.5保証付き配信 - P（Tでした）TCPは、「保証配達」、唯一のアプリケーションACKがそれを行うことができません。これらのACKが、ここで説明と同様に生成することができた場合は、この要件が満たされています。
1.4.6 Accounting Timestamps - T Another item for the "Information Model" author.
1.4.6会計タイムスタンプ - 「情報モデル」作者のために別のアイテムをT。
1.4.7 Dynamic Accounting - T Event and interim accounting can be supported.
1.4.7ダイナミック会計 - Tのイベントや中間会計をサポートすることができます。
1.5.1 Encoding of MOBILE IP Registration Messages - P (was T) Yet more work for the "Information Model" author. Hope he can handle it.
モバイルIP登録メッセージの1.5.1エンコーディング - 「情報モデル」の著者のためのP（Tでした）しかし、より多くの仕事。彼はそれを扱うことができます願っています。
1.5.2 Firewall Friendly - P (was T) I guess. Because it uses TCP and can be identified by known connection port. But there is an issue with respect to the impact level of mixed COPS traffic coming through a common firewall port.
1.5.2ファイアウォールフレンドリー - P（Tでした）私は推測します。それは、TCPを使用し、既知の接続ポートによって識別することができますので。しかし、一般的なファイアウォールポートを経由してくる混合COPSトラフィックの影響レベルに関して問題があります。
1.5.3 Allocation of Local Home Agent - P (was T) Just add another element to that "Information Model" definition.
ローカルホームエージェントの1.5.3配分 - P（Tでした）ただ、その「情報モデル」の定義に別の要素を追加します。
COPS was designed to do some things similar to what we want and be somewhat flexible, but with a totally different set of assumptions on how many clients and requests would be funneled through the infrastructure and the acceptable overhead. This evaluator is not sure that it scales well to the fast evolving access market where every product doesn't implement a small set of common features, but a large set of overlapping ones.
COPSは、我々が望むものに似たいくつかのことを行うと、やや柔軟性が、インフラおよび許容できるオーバーヘッドを通じて注ぎ込まれますどのように多くのクライアントとのリクエストに仮定の全く異なるセットになるように設計されました。この評価者は、すべての製品は、一般的な機能の小さなセットが、重複したものの大規模なセットを実装しない高速な進化アクセス市場にも拡大縮小することを確認されていません。
COPS started out with small and easily met set of design goals for RSVP and DiffServe, and is evolving as a new hammer to hit other nails [COPSPR]. As COPS implementors get more operational experience, it is interesting to see more reliability fixes/features quickly get patched in.
COPSは、小規模でスタートし、簡単にRSVPとDiffserveのための設計目標の設定、および他の爪[COPSPR]をヒットする新しいハンマーとして進化して会いました。 COPSの実装者は、より多くの運用経験を得ると、すぐにパッチを適用しますより信頼性の修正/機能を見るのは興味深いです。
Understanding COPS requires that you read a number RFCs and drafts which do not readily integrate well together. Each application of COPS has spawned a number of drafts. It's not clear if one wants to or can implement a single COPS server that can service AAA and other application clients.
COPSを理解することは、容易に一緒にうまく統合していない数のRFCとドラフトを読んでいることが必要です。 COPSの各アプリケーションは、ドラフトの数を生み出しました。 1がしたいか、AAAおよびその他のアプリケーションのクライアントにサービスを提供することができ、単一のCOPSサーバを実装することが可能かどうかは明らかではありません。
The COPS authors seem to overly believe in the goodness of TCP, and rely on it to solve all their transport problems, with concessions to application keep-alive messages to probe the connection status and sequence numbers to prevent replay attacks. This evaluator believes this type of approach may work for many networks but really doesn't scale well in larger configurations. End-to-end application acks are the only guaranteed delivery solution, particularly where distributed state is involved.
COPSの著者は、過度にTCPの良さを信じているようだ、とリプレイ攻撃を防ぐために、接続状態とシーケンス番号を調べるために、アプリケーションに譲歩して、キープアライブメッセージをすべてのそれらの輸送の問題を解決するために、それに依存しています。この評価者は、このタイプのアプローチは、多くのネットワークのために働くかもしれないが、実際に大規模な構成ではうまくスケールしないと考えています。エンドツーエンド・アプリケーション・ACKは、分散状態が関与特にのみ保証された配信ソリューションです。
COPS falls into an in between place on encoding. It has small number of simple data object blobs which are concatenated ala RADIUS/Diameter TLVs to form a flexible message layout. However, they attempt to limit the number of objects by making them arbitrarily complex ala SNMP MIBs, and defining yet another data structuring language for these PIBs. There is a lot of computer science style grandstanding in [COPSAAA] Section 1.2, but no translation into how a set of data objects can be used to meet these wonderful features in operation. (or even if we needed them) This will be the crux of the interoperability issue. RADIUS implementations interoperate because they at least, understand a common set of functional attributes from the RFCs. And vendor extent ions can be simply customized in as needed via dictionaries. If PIB definitions are needed for every piece and version of access equipment, before you can use it, then the bar for ease of configuration and use has been raised quite high.
COPSは、エンコーディングの場所の間でに落ちます。これは柔軟メッセージのレイアウトを形成するために、RADIUS /直径のTLVたala連結され、単純なデータ・オブジェクトブロブの数が少ないです。しかし、彼らは任意の複雑なALAのSNMP MIBの作り、そしてこれらのPIBのためにさらに別のデータの構造化言語を定義することによって、オブジェクトの数を制限しようとします。 [COPSAAA]セクション1.2が、データオブジェクトのセットが動作してこれらの素晴らしい機能を満たすために使用することができる方法への変換なしでコンピュータサイエンスのスタイルスタンドプレーがたくさんあります。 （あるいは我々は彼らを必要としても）これは、相互運用性の問題の核心となります。彼らは、少なくとも、RFCのからの機能的属性の共通セットを理解するためのRADIUS実装は相互運用します。辞書を経由して、必要に応じて、ベンダーのエクステントイオンは単純でカスタマイズすることができます。あなたがそれを使用することができます前に、PIBの定義は、アクセス機器のすべての部分とバージョンのために必要とされる場合は、設定と使いやすさのためのバーは非常に高い上昇しました。
Support for PIB definition and vendor extensions will be on the same order as MIB integration in SNMP management products and put the supposed complexity of Diameter to shame.
PIBの定義とベンダーの拡張機能のサポートは、SNMP管理製品におけるMIBの統合と同じオーダーであると恥に直径のはず複雑さを配置します。
COPS has a structure that could be made to serve as a AAA protocol, perhaps by just copying the features of RADIUS and Diameter into it. The author of [COPSAAA] and [COPSComp] has not done the whole job yet and some of the missing pieces are vexing even for those already in the field.
COPSは、おそらくそれにRADIUSと直径の特徴をコピーし、AAAプロトコルとして機能するように作ることができる構造を有しています。 [COPSAAA]と[COPSComp]の著者は、まだ全体の仕事をしておらず、行方不明の作品のいくつかは、既にフィールドにそれらのためにも、厄介されています。
While some of the synergy with other COPS services is attractive, this evaluator is concerned about the liabilities of combining AAA services with the new emerging COPS applications in a single server entity will introduce more complexity than needed and opportunities to have progress pulled into other rat-holes. (eg. Policy Frameworks)
他のCOPSサービスとの相乗効果のいくつかは魅力的ですが、この評価者は、他のrat-に引き込まより必要以上に複雑さと進歩を持っている機会をご紹介します単一サーバエンティティに新興COPSアプリケーションでAAAサービスを組み合わせるの負債を懸念しています穴。 （例えばポリシーフレームワーク）
Appendix D - Meeting Notes
付録D - ミーティングノート
The minutes of the team meetings as recorded by various members.
様々なメンバーによって記録され、チームの会議の議事録。
D.1 Minutes of 22-Jun-2000 Teleconference
22 - 6月 - 2000遠隔会議の議事録D.1
Recorded by: Mark Stevens
マーク・スティーブンス：によって記録
Arguments for and against SNMP as an AAA protocol were given. Stuart Barkley gave a summary of the pro argument. Mike St. Johns gave a summary of the con argument. Dave Nelson asked for "instructions to the jury" in an effort to determine what evidence could and could not be used in making decisions.
AAAプロトコルとしてSNMPおよびに対する引数が与えられました。スチュアートバークリーは、プロの引数の概要を与えました。マイク・セント・ジョンズは、詐欺の引数の概要を与えました。デイブネルソンと意思決定を行う際に使用することができなかったことができるもの証拠を決定するための努力で「陪審への指示」を求めました。
The AAA evaluation criteria is weak in some areas and in others it appears to be written with what might be interpreted as undue influence from the NASREQ working group.
AAAの評価基準は、一部の地域では弱く、他の人にNASREQワーキンググループからの不当な影響として解釈される可能性がありますどのように書かれているように見えます。
Mike St. Johns offered that we must restrict ourselves to considering only the evidence provided in the compliance documents and any supporting documents to which they may refer.
マイク・セントジョンズたちは、コンプライアンス文書とそれらが参照され得る任意の書類で提供される唯一の証拠を考慮に自分自身を制限しなければならないことを申し出ました。
In summary: AAA evaluation criteria document, AAA evaluation criteria source documents, protocol response documents and reference documents.
要約：AAA評価基準書、AAA評価基準ソースドキュメント、プロトコル応答ドキュメントおよび参照ドキュメント。
The question as to what the group should do with malformed requirements came up. The consensus seemed to be that we would use the requirements as adjusted in our last meeting where the requirements made no sense.
グループは、不正な形式の要件に何をすべきかについての質問が上がりました。コンセンサスは、要件は何も意味を成していない私たちの最後の会議で調整として、我々は要件を使用することであるように思われました。
The floor was then given to Stuart Barkley for the pro SNMP argument.
床は、その後プロSNMP引数にスチュアートバークリーに与えられました。
Highlights:
ハイライト：
* In most areas the requirements are met by SNMP. * Confidentiality and Certificate transport mechanisms may be weak, but workable. * With regard to Authentication, every technique can be supported although support for PAP or cleartext passwords is weak. * With regard to Authorization, there is nothing in the requirements that cannot be supported. * Accounting everything supported, although there is no specific consideration for compact encoding. SNMP not as bloated as ASCII or XML based encoding schemes. Requirement for compact encoding weakly indicated in requirements anyway. Server-specific attributes needed, but compact encoding preclude w/o tradeoffs.
*ほとんどの地域での要件は、SNMPによって満たされます。 *機密性と証明書の輸送メカニズムは弱いが、実行可能かもしれません。 PAPまたは平文パスワードのサポートが弱いですが*認証に関しては、すべての技術をサポートすることができます。 *認証に関しては、サポートできない要件では何もありません。 *会計すべてがコンパクトなエンコーディングのための具体的な考慮事項はありませんが、サポートされています。 ASCIIまたはXMLベースの符号化方式としてSNMPなど肥大化していません。コンパクトなエンコーディングのための要件は、弱く、とにかく要件に示されています。サーバー固有の属性が必要ですが、コンパクトなエンコードはトレードオフO / W排除します。
* With regard to mobile IP requirement, everything works well, although firewall friendliness is a judgment call. * Proxy mechanisms of SNMPv3 mitigates problems w/ firewalls. * Scalability is ok. * Overall, meets most requirements and shortfalls are minor. * In some cases requirements seemed to expressed in a manner that "stacks" the odds against SNMP. * SNMP is deployed everywhere already.
ファイアウォール親しみが審判の判定ですが*モバイルIPの要件に関しては、すべてが、うまく動作します。 * SNMPv3ののプロキシメカニズムは、ファイアウォール/ wの問題を軽減します。 *スケーラビリティはokです。 *全体的に、ほとんどの要件や不足が軽微で満たしています。 *いくつかのケースでは要件は、SNMPに対するオッズを「スタック」という形で表現するように見えました。 * SNMPは、すでにどこにでも展開されています。
* The protocol has a well-understood behavior despite the tedium of MIB definition, so it has the advantage of not requiring the creation of a new infrastructure. * AAA response document is silent on architecture and MIB definition, but there is too much work to do at this stage of evaluation. Not having done the MIB definitions and architecture is not a limitation of the protocol. * SNMP is a good candidate.
*プロトコルは、MIB定義の退屈にもかかわらず、十分に理解振る舞いを持っているので、新しいインフラストラクチャの作成を必要としないという利点を有します。 * AAA応答文書は、アーキテクチャとMIB定義に沈黙しているが、評価のこの段階で行うにはあまりにも多くの仕事があります。プロトコルを限定するものではないMIB定義およびアーキテクチャを行わ有しない。 * SNMPは良い候補です。
Mike St. Johns took the floor to give a summary of the con argument.
マイク・セント・ジョンズは、詐欺の引数の要約を与えるために、床を取りました。
* Neither the requirements, core documents nor response document specify the mechanism of operation. * Liberties were taken in the assertion that the server to server interaction requirements were met. * The scaling arguments are weak. * Fail-over arguments are weak. * Security aspects work well with the manager/server paradigm, but not well in bidirectional interactions among peers. * The authentication requirements not understood by authors of the response document. * SNMP is just data moving protocol. * Message formats not specified. * What is the method for supporting authentication? Storing the information is handled, but what do the nodes do with it?
*要件、コア文書や応答文書はいずれも、操作のメカニズムを指定します。 *自由は、サーバとの対話の要件にサーバーが満たされたアサーションに撮影されました。 *スケーリング引数は弱いです。 *フェールオーバーの引数は弱いです。 *セキュリティの側面は、ピア間の双方向の対話でよくマネージャ/サーバパラダイムでうまく動作しますが、ありません。 *認証要件は、応答文書の作成者によって理解されていません。 * SNMPプロトコルを動かすだけのデータです。指定されていません*メッセージフォーマット。 *認証をサポートするための方法は何ですか？情報を保存する処理されますが、ノードはそれで何をしますか？
* The protocol certainly shined in the area of meeting accounting requirements. * Although SNMP could certainly play a role in the accounting space, it is unusable in the areas of Authorization and Authentication. * The response document does not address how the problem will be solved. * It does not address the scalability issues that may arise in the transition from a manager-agent mode of operation to a client-server model.
*プロトコルは確かに会計上の要件を満たすの領域に輝い。 SNMPは確かに会計空間の役割を果たしている可能性がありますが*、それが認可と認証の分野で使用不可能です。 *応答文書は、問題が解決されるか対応していません。 *これは、クライアントサーバモデルへの操作のマネージャー・エージェント・モードからの移行で発生する可能性のあるスケーラビリティの問題に対処していません。
The group then examined each requirement against SNMP in a line-by-line exercise.
グループは、行ごとの運動にSNMPに対する各要件を調べました。
D.2 Minutes of 27-Jun-2000 Teleconference
27 - 6月 - 2000遠隔会議の議事録D.2
Attendees - All (Mike St. John, Dave Mitton, Dave Nelson, Mark Stevens, Barney Wolff, Stuart Barkley, Steven Crain, Basavaraj Patil)
出席者 - すべて（マイク・セント・ジョン、デイヴ・ミトン、デイヴ・ネルソン、マーク・スティーブンス、バーニー・ウルフ、スチュアートバークリー、スティーブン・クレイン、Basavarajパティル）
Minutes recorded by : Basavaraj Patil
で記録された議事録：Basavarajパティル
Evaluation of RADIUS++ AAA Requirements
RADIUS ++ AAA要件の評価
Pro : Mark Stevens Con : Dave Nelson
プロ：マーク・スティーブンスコン：デイブ・ネルソン
- Question raised on if all meetings held so far have been recorded. Last week's meeting was recorded by Mark. Previous meetings have been recorded by Mike. All of these minutes should be available in the archive.
- これまでに開催されたすべての会議が記録されている場合の質問は、上の隆起しました。先週の会議は、マークによって記録されました。前の会議はマイクによって記録されています。これらの分はすべて、アーカイブに利用可能であるべきです。
- Dave Nelson mentioned that Pat Calhoun has responded on the AAA WG mailing list to the changes made to the requirements document by the evaluation team. Pat's response includes arguments for inclusion of some of the requirements that were deleted by the eval team.
- デイブネルソンはパットカルフーンは、評価チームによる要件ドキュメントに加えられた変更にAAA WGメーリングリストで対応してきたことを述べました。パットの応答はevalのチームによって削除された要件の一部を含めるの引数を含んでいます。
- Mike concluded that we can reinstate these requirements after reviewing Pat's comments in detail and the RFCs referenced. The intent is to take Pat's comments/document and review it between now and next Thursday (July 6th) and integrate the comments based on the findings at that time.
- マイクは、我々が詳細にパットのコメントを検討した後、これらの要件および参照RFCを回復できることを結論付けました。その意図は、パットのコメント/文書を取り、今と次木曜日（7月6日）の間、それを確認し、その時点での知見に基づいて、コメントを統合することです。
Voting Procedure for evaluation : No voting during the discussion. All votes MUST be submitted to Mike by COB, June 28th, 00.
議論の中にはありません投票：評価のための手順を投票。すべての票はCOB、6月28日、00でマイクに提出しなければなりません。
- Dave Nelson's summary of the Con statement for RADIUS++. Overview of the points on which the evaluator disagrees with the compliance statement.
- RADIUS ++のためのコン文のデイヴ・ネルソンの要約。ポイントの概要は、どの評価者は、コンプライアンスの声明に同意しません。
Conclusion from Dave : Not recommended (Details in the con statement).
デイブから結論：（コン文の詳細）推奨しません。
Q: Is it possible to use it for accounting? A: Authentication and Authorization could be separated, but Accounting is the weak link in this protocol and hence is not suitable.
Q：それは、会計のためにそれを使用することは可能ですか？ ：認証と承認を分離することができたが、会計は、このプロトコルで弱いリンクであるため適切ではありません。
- Mark Steven's summary of the Pro statement Agreed with most of the observations made by Dave Nelson. The biggest thing going for it is that it has been running in this environment for a while and it does meet most of the requirements in the document. Transition will be easy and backwards compatibility is a key plus point.
- プロのステートメントのマーク・スティーブンの概要はデイブネルソンによって行われた観察のほとんどに同意しました。それのために行く最大のものは、それがしばらくの間、この環境で実行されていて、それが文書内の要件のほとんどを満たしてないということです。移行が簡単になり、後方互換性は重要なプラスポイントです。
Point-by-point Discussion:
ポイントごとディスカッション：
General (1.1):
一般（1.1）：
BW - There is no actual limit on the number of outstanding requests. The protocol itself does not limit the number.
BW - 未解決の要求の数には実際の制限はありません。プロトコル自体は、数を限定するものではありません。
DN -Simultaneous requests is not the same as outstanding requests.
DN -Simultaneous要求は、未処理の要求と同じではありません。
Discussion of workarounds that have been implemented to overcome this problem.
この問題を克服するために実装されている回避策の議論。
DN - This is an application layer protocol and uses application level time-outs to provide fail-over solutions. Analogy and discussion on the use of round-trip-timer in TCP.
DN - これは、アプリケーション層プロトコルであり、フェイルオーバーソリューションを提供するために、アプリケーションレベルのタイムアウトを使用します。類推とTCPでのラウンドトリップタイマーの使用についての議論。
Example of how robust a network can be based on a machine at MIT that was decommissioned and a new one with the same name installed in the network.
ネットワークが廃止されたMITのマシンやネットワークにインストールされ、同じ名前を持つ新しいものに基づくことができる方法を堅牢なの例。
Discussion of environments where proxies for primary, secondary and tertiaries exist and the possible effect of flooding messages in the event of a fail-over detection.
第一、第二及びtertiariesのプロキシが存在する環境およびフェイルオーバー検出の場合にはフラッディングメッセージの可能な効果の議論。
No Discussion. Accepted as stated.
何についての議論はありません。述べたように受け入れられました。
This requirement was deleted from the list by the evaluation team. It was deleted because it is an overgeneralization of Roam Ops.
この要件は、評価チームがリストから削除されました。それはローミングオプスのovergeneralizationあるので、それが削除されました。
DN - There is a concern regarding what this really means. Referred to what Pat is saying about this on the list and the need for it to be reinstated.
DN - これは本当に何を意味するのかについての懸念があります。パットはリストとそれが復活されるために必要で、このことについて言っていることに言及しました。
Suggestion to change the tag in the requirements document to hop-by-hop security.
提案は、ホップバイホップするために、セキュリティ要件文書にタグを変更します。
Does the Roamops group use transmission level security to imply hop-by-hop security?
ホップバイホップのセキュリティを意味するROAMOPSグループ用送信レベルのセキュリティをしていますか？
Mike explained the concept of Cryptographic Message Syntax (CMS - RFC2630). There are some issues regarding the use of CMS at an end point. Symmetric or Asymmetric keys can be used.
マイクは暗号メッセージ構文（ - RFC2630 CMS）の概念を説明しました。エンドポイントでのCMSの使用に関するいくつかの問題があります。対称または非対称キーを使用することができます。
There does not seem to be a problem with the suggested usage of CMS in RADIUS++.
RADIUS ++でのCMSの提案使用法に問題があるように思えません。
No discussion. (I guess everyone concurs with the statement in the compliance document and the reviewers comments).
いいえ議論ません。 （私は誰もが、コンプライアンス文書内の文や査読コメントに同意推測します）。
BW - Radius provides reliability at the application layer by doing retransmissions. So why is there a need for a reliable AAA transport protocol?
BW - 半径は、再送信を行うことによって、アプリケーション層での信頼性を提供します。なぜ信頼できるAAAのトランスポートプロトコルの必要性はあるのか？
- Is it packet loss that the protocol needs to be concerned about?
- それは、プロトコルは心配する必要があるとパケット損失ですか？
DN - This requirement is tied to the failover issue. Explanation of the negative impact of retransmissions in a network, especially in the case of a web of proxies.
DN - この要件は、フェイルオーバーの問題に結びついています。特にプロキシのウェブの場合にはネットワークに再送信の負の影響の説明。
Conclusion is that this requirement deals with packet loss.
結論は、この要件は、パケット損失を扱うということです。
Running over IPv6 should be a trivial issue.
IPv6の上で実行することは些細な問題でなければなりません。
- Discussion on what this requirement means and analogy to DNS servers in a network.
- この要件は、ネットワーク内のDNSサーバに意味と類推かについての議論。
- RADIUS can be extended to support this requirement and from the compliance document this does not appear to be fully cooked yet.
- RADIUSは、この要件をサポートするように拡張することができ、コンプライアンス文書から、これはまだ完全に調理されていないよう。
No Discussion
ませんディスカッション
This seems to be a trivial issue to be addressed in RADIUS++.
これは、RADIUS ++で対処すべき些細な問題のようです。
No Discussion
ませんディスカッション
Authentication Requirements:
認証要件：
Trivial - Total compliance.
トリビアル - 合計の準拠。
Comment : RADIUS support of CHAP could be better and the response needs to be encrypted.
コメント：CHAPのRADIUSサポートがより良いかもしれないし、応答を暗号化する必要があります。
No Discussion
ませんディスカッション
DN - Document claims that the server can reauthenticate by issuing an Access-challenge. There is a change to the state machine and the suggested solution is too simplistic. Also backwards compatibility would be an issue.
DN - ドキュメントは、サーバがアクセスチャレンジを発行して再認証できると主張しています。そこステートマシンに変更があると提案された解決策は単純すぎます。また、下位互換性が問題になることでしょう。
DN - This is trivial to fix, but this is not mentioned in the compliance document.
DN - これは修正するのは簡単ですが、これは、コンプライアンス文書で言及されていません。
Authorization Requirements:
必要な権限：
- RADIUS does not rise to the demands of being a resource manager - RADIUS assigns an address and it stays assigned for the session. There is no concept of leasing.
- RADIUSは、リソース・マネージャであることの要求に上昇しない - RADIUSはアドレスを割り当て、それがセッションのために割り当てられたままです。リースの概念はありません。
This is a requirement written that is not applicable to RADIUS itself.
これは、自分自身を半径には適用されない書かれた要件です。
Call dropped. Somebody else needs to fill in here. (Mike ????)
電話が切れた。他の誰かがここに記入する必要があります。 （マイク????）
Accounting Requirements:
会計の要件：
No dissent. No discussion
いいえ異議ありません。いいえ議論ません
Comment made regarding ASN.1 and XML in this context
この文脈でのASN.1とXMLに関するコメント作ら
No discussion
いいえ議論ません
No specific wording in the document to show how this can be done. Basically it is real time accounting without the real time constraint.
これを行う方法を示すための文書の具体的な文言はありません。基本的には、リアルタイムの制約なしに占めるリアルタイムです。
It may be a trivial issue.
それは些細な問題になることがあります。
No Discussion
ませんディスカッション
There is ongoing discussion in the AAA WG on this requirement. The RADIUS WG is also discussing this (comment). The idea here is to be able to send the equivalent of a phonecall in progress type of messages.
この要件にAAA WGで進行中の議論があります。 RADIUS WGも、この（コメント）を検討しています。ここでの考え方は、メッセージの進行型ではphonecallと同等のものを送ることができるようにすることです。
Mobile IP Requirements:
モバイルIPの要件：
May be trivial. Discussion on what this requirement really is. Is it just the ability to carry the reg. message as payload? Does the AAA protocol have to delve into the reg. message and behave differently.
些細なことがあります。この要件が本当に何であるかについての議論。 REGを運ぶだけの能力があります。ペイロードとしてメッセージ？ AAAプロトコルは、REG掘り下げるために持っています。メッセージと動作が異なります。
No Discussion
ませんディスカッション
This concept needs to be clarified as the author writing the compliance statement did not understand it either.
コンプライアンス文を書く著者はどちらかそれを理解していなかったとして、この概念を明確にする必要があります。
If you notice anything that I recorded here as something misinterpreted, please feel free to make corrections.
あなたは、私が誤解ものとしてここに記録されたものに気付いた場合、修正を行うこと自由に感じなさい。
D.3 Minutes of 29-Jun-2000 Teleconference
29 - 6月 - 2000遠隔会議の議事録D.3
Attendees: Mike St. John, Dave Mitton, Dave Nelson, Barney Wolff, Stuart Barkley, Steven Crain, Basavaraj Patil. Missing: Mark Stevens.
出席者：マイク・セント・ジョン、デイヴ・ミトン、デイヴ・ネルソン、バーニー・ウルフ、スチュアートバークリー、スティーブン・クレイン、Basavarajパティル。行方不明：マーク・スティーブンスを。
Minutes recorded by: Stuart Barkley
スチュアートバークリー：によって記録された議事録
Evaluation of Diameter AAA Requirements
直径AAAの要件の評価
Advocates:
支持者：
Pro: Basavaraj Patil Con: Barney Wolff
プロ：Basavarajパティルコン：バーニーヴォルフ
Summary discussion:
概要ディスカッション：
PRO summary (Basavaraj Patil):
PRO概要（Basavarajパティル）：
session based lightweight base + extensions has implementation experience based upon radius fixes specific problems with radius, interoperates with radius looks like requirements are written for diameter
セッションベースの軽量なベース+拡張は、実装の半径に基づいて経験半径で特定の問題を修正している半径要件は、直径のために書かれているように見えるとの相互運用が可能
CON summary (Barney Wolff):
CONサマリー（バーニー・ウルフ）：
meets most needs, designed with requirements in mind
念頭に置いての要件を設計し、最もニーズを満たし
issues: scalability in small devices (strong crypto specifically)
問題：小型デバイスにおけるスケーラビリティ（特に強い暗号）
failover (need guidance on failover recovery procedures)
フェイルオーバ（フェイルオーバー・リカバリー手順のガイダンスを必要とします）
Data object confidentiality has been expressed as very important, diameter glosses over it referring to rfc2630, cost to run on NAS device
非常に重要な、直径はRFC2630を参照その上にグロスなどのデータオブジェクトの機密性は、NASデバイス上で実行するためのコストを表明してきました
ACL: filter style syntax seems inadequate
ACL：フィルタスタイルの構文は不十分なようです
state reconciliation: difficult over global multiple administrative domains
状態の和解：グローバル複数の管理ドメインにわたる困難
batch accounting: implementation doesn't meet intended need
バッチ会計：実装が意図した必要性を満たしていません
firewall friendly: until firewalls support SCTP will be failure
ファイアウォールに優しい：ファイアウォールは、SCTPが失敗になりますサポートまで
summary very close
非常に近い概要
concerns:
懸念：
size and complexity needs almost all extensions to actually support needs separation of SCTP and data (as per IESG suggestion?) application vs transport acks
輸送のACK対サイズと複雑さは、実際にSCTPとデータのニーズ分離をサポートするために、ほぼすべての拡張機能を必要とする（IESG提案どおり？）アプリケーション
Point-by-point Discussion:
ポイントごとディスカッション：
General (1.1):
一般（1.1）：
Handles large number of requests
多数の要求を処理します
SCTP reduces proxy needs (how? what is justification for this statement?)
SCTPは、プロキシのニーズ削減（この文を正当化するものであるかを？）
Scalability in large
大規模でのスケーラビリティ
Recovery from SCTP failure needs discussion (Note to DM: Include in final document considerations)
SCTPの故障ニーズの議論からの回復（DMへの注意：最終文書の検討事項に含めます）
No Discussion
ませんディスカッション
No Discussion
ませんディスカッション
Crypto in NAS NAS needs knowledge of when to use crypto One Time Passwords
NAS NASにおける暗号は、暗号ワンタイムパスワードを使用する際の知識を必要とします
No Discussion
ませんディスカッション
No Discussion
ませんディスカッション
No Discussion
ませんディスカッション
No Discussion
ませんディスカッション
No Discussion
ませんディスカッション
No Discussion
ませんディスカッション
No Discussion
ませんディスカッション
Authentication Requirements:
認証要件：
No Discussion
ませんディスカッション
No Discussion
ませんディスカッション
No Discussion
ませんディスカッション
No Discussion
ませんディスカッション
No Discussion
ませんディスカッション
Authorization Requirements:
必要な権限：
No Discussion
ませんディスカッション
Protocol requirement or implementation/application requirement? Which RADIUS versions are to be supported? Which subset?
プロトコル要件または実装/アプリケーション要件？どのRADIUSのバージョンはサポートされていますか？どのサブセット？
No Discussion
ませんディスカッション
No Discussion
ませんディスカッション
Raj to look at this again
ラジは再び、このを見て
Standardizes syntax not semantics. Standardizes semantics in NASREQ extension, but is very weak
シンタックスないセマンティクスを標準化しています。 NASREQ拡張子にセマンティクスを標準化しますが、非常に弱いです
Appears to be weak in that server must "query the world" to restore its state Just in time reconciliation Simultaneous usage limitations More discussion needed
「世界を照会」必要があり、そのサーバーに弱いように見えるだけでより多くの議論が必要な時間の調整同時使用制限にその状態を復元します
No Discussion
ませんディスカッション
Accounting Requirements:
会計の要件：
No Discussion
ませんディスカッション
Is ADIF compact? Is ADIF UTF-8 compatible?
ADIFのコンパクトのですか？ ADIFのUTF-8が対応していますか？
No Discussion
ませんディスカッション
Diameter okay for small batches. Specification doesn't seem suitable for large batch transfers (100,000+ records)
小さいバッチのための直径大丈夫。仕様は、（100,000レコードの）大規模なバッチ転送に適していないようです
No Discussion
ませんディスカッション
No Discussion
ませんディスカッション
No Discussion
ませんディスカッション
Mobile IP Requirements:
モバイルIPの要件：
Taken of faith
信仰の撮影
Issues with SCTP being supported initially through firewalls
SCTPの問題は、ファイアウォール経由で最初にサポートされています
Still lack of understanding of the AAA protocol requirements here (versus just being a roaming attribute)
それでも（ちょうどローミング属性であることに対して）ここでAAAプロトコル要件の理解の欠如
Overall summary:
全体の要約：
Diameter seems to meet most requirements and is a likely candidate to support AAA requirements.
直径はほとんどの要件を満たしているようだとAAAの要件をサポートするための有力候補です。
Other matters:
その他の事項：
Votes on Diameter should be in by Sunday evening. Same format as before. Mike will tally up as both majority and average votes.
直径上の投票は日曜日の夕方まででなければなりません。前と同じ形式。マイクは過半数と平均票の両方としてアップ集計されます。
Should different requirements have different weight?
異なる要件が異なる重量を持つべきでしょうか？
Possibility of SNMP reconsideration as per ADs? To close off our task in timeframe allocated, should not reopen submissions or discussions. Could cause to drag on for long time causing us to miss our July 15 date.
ADのあたりなどのSNMP見直しの可能性？割り当てられた時間枠内で、当社のタスクを閉鎖するには、提出または議論を再開すべきではありません。私たちは私たちの7月15日の日付を欠場する原因と長時間にドラッグする可能性があります。
Possibility of needing a few extra days to finish report due to editing and review needs of the group. Mike to ask ADs to consider slight time extension possibility.
いくつかの余分な日を必要とする可能性が伴うグループの編集とレビューのニーズにレポートを終了します。マイクは若干の時間延長の可能性を検討するために、広告を依頼します。
"No discussion" means that the topic was mentioned but there we no objections/issues raised on that requirement being met.
「ディスカッションはまだありません」というトピックが言及されたことを意味しませんが、そこに我々満たされている要件に上げ異議/問題。
These are based upon my notes. Please send any corrections to the list.
これらは、私のノートに基づいています。リストにすべての修正を送ってください。
D.4 Minutes of 06-Jul-2000 Teleconference
06 - 7月 - 2000遠隔会議の議事録D.4
Minutes of AAA-Team Telecon 7/6/00 By: Barney Wolff
AAA-チームテレコン7/6/00ことでの議事録：バーニーヴォルフ
Pro review of COPS - Dave Nelson
COPSのプロレビュー - デイヴ・ネルソン
Likes the object model. No apparent showstoppers. Will resend review with typos corrected.
オブジェクトモデルが好き。明白な致命ありません。修正タイプミスとの評価を再送信します。
Con review of COPS - Dave Mitton
COPSのコンレビュー - デイブ・ミトン
Architecture is mostly there. Strong dependency on info model, sceptical of object model. Problem with info model in multi-vendor, multi-administration environment. How does server speak to multiple client flavors? Will resend review with typos corrected.
アーキテクチャはほとんどあり。オブジェクトモデルの懐疑的な情報モデルに強く依存、。マルチベンダー、マルチ管理環境における情報モデルを通報します。どのサーバが複数のクライアントの風味に話すのですか？修正タイプミスとの評価を再送信します。
Comment by Mike StJ "replace SNMP with COPS" - :) I think.
マイクSTJでコメント「COPSでSNMPを置き換える」 - :)私は思います。
Per-Item discussion
アイテム単位の議論
1.1.1 Scalability - concern re always-on TCP. Direction to DM - add general issue of number of connections.
1.1.1スケーラビリティ - TCP常時オンの再懸念。 DMへの方向 - 接続数の一般的な問題を追加します。
1.1.2 Failover - No hot backup, but true of all protocols. (ie, no explicit mention of server-server protocol that might keep a backup server in sync so it could take over instantly.)
1.1.2フェイルオーバー - いいえ、ホットバックアップが、すべてのプロトコルの真実。 （すなわち、それは瞬時に引き継ぐことができるように同期してバックアップサーバを維持する可能性があるサーバーのサーバープロトコルの明示的な言及。）
1.1.3 Mutual Authentication - perhaps relies on TLS. Draft does not otherwise support this.
1.1.3相互認証は - おそらくTLSに依存しています。ドラフトは、そうでない場合はこの機能をサポートしていません。
1.1.11 Proxy & Routing Brokers - client-type interaction with proxy is questionable. (In later discussion, it appears client-type is a field in the request, and perhaps all AAA is one type, so may not be an issue.)
1.1.11プロキシ＆ルーティングブローカー - プロキシとクライアントタイプの相互作用は疑問です。 （後の説明では、クライアントタイプがリクエストのフィールドで表示され、おそらくすべてのAAAが1種類なので、問題にならないかもしれません。）
1.1.13 Shared secret not req'd - runs over TLS, no multiple levels of security.
req'dない1.1.13共有秘密は - TLS、セキュリティの無い複数のレベルを介して実行されます。
1.2.1 NAI Support - some uncertainty on the impact of RFC 2459 (X.509 profiles) on this - may restrict NAI in some way?
1.2.1 NAIのサポート - RFC 2459（X.509プロフィール）の影響に関するいくつかの不確実性、この上は - いくつかの方法でNAIを制限することができますか？
1.2.6 Authorization without Authentication - Mike comments the requirement is broken. BW comment (post-meeting) - the requirement appears intended specifically to chastise RADIUS for requiring User-Name and some sort of password in an Access-Request, even if it's sent pre-connect, on receipt of DNIS, for example. Sure it's silly, but does it really matter whether an attribute is absent or filled with "NONE"? This was just nasty sniping at RADIUS on somebody's part, imho.
認証なし1.2.6承認 - マイクは要件が壊れてコメントしています。 BWコメント（ポスト会議） - 要件が表示され、それは、例えば、DNISの受信時に、あらかじめ接続送らいた場合でも、ユーザー名とアクセス要求にパスワードのいくつかの並べ替えを必要とするためにRADIUSを厳しく非難し、具体的に意図。確かにそれは愚かだが、実際に属性が存在しないか、または「NONE」で満たされているかどうかは関係ありませんか？これは私見、誰かの一部のRADIUSでちょうど厄介な狙撃しました。
1.5.2 Firewall-Friendly - COPS like any Swiss-Army-Knife protocol (SNMP) requires the firewall to look inside the packets, because passing AAA may be allowed but not other protocol uses. So it would be a big help, for both COPS and SNMP, to define a different port for its AAA application.
1.5.2ファイアウォール・フレンドリー - 任意のスイスアーミーナイフプロトコル（SNMP）のようなCOPS渡しAAAはなく、他のプロトコルが使用許可される可能性があるため、パケットの内部を見るために、ファイアウォールが必要です。だから、そのAAAアプリケーションの別のポートを定義するには、COPSとSNMPの両方のために、大きな助けになります。
D.5 Minutes of 11-Jul-2000 Teleconference
11 - 7月 - 2000遠隔会議の議事録D.5
Present: Mike, Bernard, Paul, Bert, Raj, Dave N., Dave M., Barney, Stuart, Mark Recorded By: Dave Nelson
現在：デイブネルソン：マイク、ベルナール、ポール、バート、ラジ、デイブN.、デイブM.、バーニー、スチュアート、マークによって記録
Mike St. Johns set the ground rules.
マイク・セント・ジョンズは、グラウンドルールを設定します。
An item by item review of the summary results was held.
要約結果の項目の見直しによって項目が開催されました。
1.1.1 Question as to why SNMP and RADIUS++ are "P"? There are issues regarding scaling of retries in a web of proxies (multi-layer proxy; primary, secondary tertiary servers at each level).
SNMPおよびRADIUSが++「P」である理由についての1.1.1の質問？ （;各レベルでのプライマリ、二級、三級のサーバー多層プロキシ）プロキシのウェブでの再試行のスケーリングに関する問題があります。
1.1.2 No protocol did very well. Similar issues as above, e.g. web of proxies. Recovery of state from a previously failed primary server?
1.1.2ませプロトコルは非常によくありませんでした。上記と同様の問題、例えばプロキシのウェブ。以前に失敗したプライマリサーバからの状態の回復？
1.1.3 Question as to how serious is the need for this requirement? May be some legitimate requirements from Mobile IP. Is this requirement an AAA-level issue?
どのように深刻にとして1.1.3の質問は、この要件が必要でしょうか？モバイルIPからの正当な要求事項かもしれません。この要件は、AAAレベルの問題ですか？
1.1.5 Most protocols evaluated used CMS to meet this requirement. Question as to applicability of CMS for NASes and other edge devices? There is a requirement for object by object confidentiality. consider three-party scenarios.
評価さ1.1.5ほとんどのプロトコルは、この要件を満たすためにCMSを使用していました。 NASおよび他のエッジデバイスのためのCMSの適用可能性についての質問？オブジェクトの機密性によって、オブジェクトのための要件があります。三者のシナリオを検討してください。
1.1.6 Question as to why SNMP did not rate the same as for item 1.1.5? The evaluation is based on what was contained in the submission documents, rather than capabilities of the protocol itself. Too much hand waving.
SNMPは、項目1.1.5と同じ評価をしなかった理由についての1.1.6の質問？評価はむしろ、プロトコル自体の機能よりも、提出書類に含まれていたものに基づいています。あまりにも多くの手を振って。
1.1.8 Question as to meaning of "reliable"? Discussion of transport protocols was deferred to later in the meeting.
「信頼性」の意味として、1.1.8の質問？トランスポートプロトコルの議論は、後の会議でに延期されました。
1.1.10 SNMP received "P" because of hand waving in the submission documents.
手の提出書類に手を振っているので1.1.10 SNMPは、「P」を受けました。
1.1.11 SNMP received "F" because this section of the submission document indicated "t.b.d.". Diameter was the only protocol submission to completely address this item.
提出文書のこのセクションは、「t.b.d.」を示しているため1.1.11 SNMPは、「F」を受けました。直径は完全にこのアイテムに対処するための唯一のプロトコルの提出しました。
1.1.12 We treated this requirement as "non-repudiation". There is a concern that digital signatures are computationally expensive and are not globally available. COPS has more work to do on this item.
1.1.12私たちは、「否認防止」として、この要件を処理しました。デジタル署名が計算上高価であり、世界的に利用できないという懸念があります。 COPSは、この項目に行うにはより多くの仕事を持っています。
1.1.13 Question that "no shared secrets" should be interpreted to mean that an alternative key management mechanism is available? We treated this as meaning that application-layer security could be turned off in deference to transport layer security. There had been discussion of the use of IKE in the AAA protocol.
「何も共有秘密は、」代替鍵管理メカニズムが利用可能であることを意味すると解釈されるべきではないことを1.1.13質問？私たちは、アプリケーション層のセキュリティは層のセキュリティを輸送するために服従でオフにすることができることを意味するものとして、これを処理しました。 AAAプロトコルでIKEの使用についての議論が行われていました。
1.2.4 Is there a need for a clear-text "password" for service such as OTP, SecurID, et. al.? It was noted that all plain passwords are exposed in clear-text at the NAS or other edge device, which is no more inherently trustworthy than any AAA server or proxy.
1.2.4ならOTP、SecurIDの、などのサービスのためのクリアテキスト「パスワード」が必要です。アル。？これは、すべての普通のパスワードがNASでクリアテキストまたはそれ以上の本質的に信頼できる任意のAAAサーバまたはプロキシを超えていない他のエッジデバイスに露出されていることが注目されました。
1.2.5 We distinguished event-driven reauthentication from timer-driven (or lifetime-driven). How is this requirement to be met in a proxy environment?
1.2.5私たちは、タイマー駆動型（または寿命ドリブン）からイベント駆動型の再認証を区別しました。プロキシ環境で満たされるために、この要件はどのように？
1.3.1 We had difficulty in determining what "static" meant, and from which reference point it was measured.
1.3.1私たちは何を意味するのか、「静的な」決定の難しさがあったが、それが測定されたポイントを参照しているから。
1.3.2 We agreed that NAIs could be handled, possibly with some restrictions.
1.3.2は、我々はのNAIは、おそらくいくつかの制限付きで、処理することができることに合意しました。
1.3.4 The SNMP submission documents contained significant hand waving.
SNMPの提出書類は手を振って大きな手を含ま1.3.4。
1.3.5 Similar comments as to item 1.2.5. The question was raised as to how the server knows when to send this request?
項目1.2.5と1.3.5のように同様のコメント。質問はこの要求を送信する際に、サーバーが知っている方法として育てられましたか？
1.3.6 We found that the notation in Diameter was weak, and of a least common denominator nature. In general, there was concern about achieving interoperability when the syntax was standardized but the
1.3.6我々は、直径が表記と最小公分母性質の弱いことがわかりました。一般的には、構文は標準化されたものの場合は、相互運用性を実現する懸念がありました
semantics were not. This area needs further work.
意味はありませんでした。このエリアにはさらなる研究が必要です。
1.4.4 There was significant skepticism regarding batch accounting as part of the AAA protocol. How large are the "batches"? Should this requirement be met using FTP or something similar?
1.4.4 AAAプロトコルの一部として会計バッチに関する重要な懐疑論がありました。どのように大規模な「バッチ」はありますか？この要件は、FTPまたは類似のものを使用して満たされるべきか？
1.5.2 There was some discussion of what constitutes firewall friendly. It was suggested that the firewall didn't want to look into packets much past the application protocol address (e.g. UDP or TCP port number). Protocols such as SNMP and COPS that have usage other than AAA are at a disadvantage, since the firewall must look deep into the application PDU to determine the intended purpose of the packet. Diameter suffers from reliance of SCTP, which is not widely deployed or widely recognized by firewalls. Should firewalls also be AAA proxy engines? Has this issue anything to do with interoperability with NAT?
1.5.2は、ファイアウォールに優しい構成するもののいくつかの議論がありました。これは、ファイアウォールがアプリケーション・プロトコル・アドレス（例えば、UDPまたはTCPポート番号）を超えて多くのパケットに見たくなかったことが示唆されました。ファイアウォールは、パケットの意図された目的を決定するために、深いアプリケーションPDUを調べなければならないので、AAA以外の使用を有するようSNMPとCOPSなどのプロトコルは、不利です。直径がファイアウォールによって広く配備又は広く認識されていないSCTPの信頼苦しんでいます。ファイアウォールはまた、AAAプロキシエンジンすべきですか？ NATとの相互運用性を行うには、この問題の何かを持っていますか？
1.5.3 We had some confusion as to what the requirement actually was. Raj seemed to be able to explain it, but the rest of us had to take it on faith.
私たちは、要件が実際に何であったかのよういくつかの混乱があった1.5.3。ラジはそれを説明することができるように見えたが、私たちの残りの部分は、信仰でそれを取らなければなりませんでした。
A poll was taken on overall acceptability and effort for each of the protocols submitted, for requirements conformance.
世論調査は、要件に適合するために、提出されたプロトコルのそれぞれについて、全体的な受容性と努力で撮影されました。
Each member indicated their evaluation in the form of (Acceptable, Not-Acceptable) with qualifiers for (Accounting, or effort to change) This information will be summarized in the final report.
各メンバーは、この情報は、最終報告書にまとめて説明する（変更するには、会計、またはエフォート）の修飾子を持つ（ - 許容できない、許容）の形で自分の評価を示しました。
A general wrap-up discussion was held.
一般的なラップアップの議論が行われました。
It was considered important that as much of the thought processes and rationales be placed in the final report as is feasible. Mike St. John will work with Dave Mitton on the ID. We really need to meet the IETF July 14 submission deadline, even if we have to issue an update on the AAA WG mailing list. All agreed that the process went fairly well. In future evaluations of this nature, it would be well for the evaluators to follow the requirements documents closely, for the submitters to create accurate and complete conformance documents, and to allow a "re-spin" cycle to correct errors and omissions in the requirements documents and conformance documents.
それは実現可能であると思考プロセスや根拠の同じくらいが最終的なレポートに配置することが重要と考えられました。マイク・セント・ジョンは、IDにデイブ・ミトンで動作します。私たちは本当に私たちがAAA WGメーリングリストの更新を発行する必要がある場合でも、IETF 7月14日提出期限を満たしている必要があります。すべてのプロセスはかなりうまくいったことに合意しました。評価者は、要件の誤りや記載漏れを訂正するための「再スピン」サイクルを提出者は、正確で完全な適合文書を作成するために、密接要件文書に従うこと、およびできるようにするためにこのような性質の将来の評価では、それはよくなります文書や適合文書。
A discussion of the transport protocol was held.
トランスポートプロトコルの議論が行われました。
The issue with transport is congestion control. There has been a problem with streams-oriented applications over TCP. The IESG is increasingly sensitive to this issue in new protocols. It was noted that AAA was a transaction-oriented application. Other request-response applications, such as DNS, seem to scale welt to Internet-scale using simple application-level retries and UDP transport. TCP has problems with head-of-line blocking, especially when multiple sessions are using a single TCP connection. AAA typically will send 3 or 4 iterations and then indicate a failure to the upper layers. It won't continue retransmissions in the face of congestion, like TCP. It was noted that bulk data transfer may not best be implemented in the AAA protocol. Concern was voiced that SCTP is not a widely implemented protocol. AAA will implement congestion control by limiting the number of outstanding requests. Some RADIUS implementations send lots of traffic when they encounter misconfigured shared secrets, but this is likely caused by a lack of proper error recovery. Diameter, as currently drafted, relies on SCTP. Can AAA run over UDP? The IESG didn't say "no"; their issue is addressing congestion control.
輸送の問題は、輻輳制御です。 TCP上のストリーム指向のアプリケーションとの問題がありました。 IESGは新しいプロトコルでは、この問題にますます敏感です。これは、AAAは、トランザクション指向のアプリケーションであることが注目されました。 DNSなどの他の要求応答アプリケーションは、シンプルなアプリケーションレベルの再試行とUDPトランスポートを使用して、インターネット規模にウエルト拡大するように見えます。 TCPは、複数のセッションが単一のTCP接続を使用している場合は特に、ヘッドオブラインブロッキングの問題を持っています。 AAAは、典型的には3または4回の反復を送信した後、上位層に失敗を示すことになります。これは、TCPのように、輻輳の顔に再送を続行しません。これは、バルクデータ転送が最良のAAAプロトコルで実現されないことに留意しました。懸念は、SCTPが広く実装されたプロトコルではないことを表明しました。 AAAは、未処理の要求の数を制限することにより、輻輳制御を実装します。いくつかのRADIUS実装は、彼らが誤って設定共有秘密に遭遇した際に大量のトラフィックを送信するが、これはおそらく、適切なエラー回復の欠如によって引き起こされます。直径は、現在起草として、SCTPに依存しています。 AAA UDP上で実行できますか？ IESGは「ノー」と言っていませんでした。彼らの問題は、輻輳制御に取り組んでいます。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。