[要約] RFC 3127は、認証、認可、および会計（AAA）プロトコルの評価に関するものであり、その目的は既存のAAAプロトコルの評価と改善の提案です。
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.
Copyright（c）The Internet Society（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月のピッツバーグ会議の出版期限を満たすために急いでいました。会議が過ぎて以来、このドキュメント内の調査結果を実質的に修正することは望ましくないので、プレゼンテーション後に情報を変更するように見えません。その後の改訂では、プロセス、フォーマット、レイアウトの編集、および事実のエラーの追加の説明のみが修正されています。
1.1. WG Co-Chair's Note:
1.1. WG共同議長のメモ：
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 Recharterが承認され、ネットワークアクセス要件がAAA WGの最後の呼び出しに合格した後、2000年4月13日にプロトコル提出の勧誘が発行されました。勧誘は、AAA WGメーリングリストと、NASREQ、モバイルIP、RAP、SNMPV3などのAAAに関連する他のIETF 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
プロトコルの送信とコンプライアンスの説明文書は、インターネットdrafts@ietf.orgに電子メールでインターネットドラフト形式で送信されます。提出の締め切りは2000年6月1日でした。候補者と見なされるためには、http：//www.ietf.org/sec10.txtで説明されているように、資格のないRFC 2026ステートメントを含める必要があります。
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チェアは2000年5月20日に発表された評価チームを形成しました。プロトコル提出の評価。目標は、IETF 48の2000年7月14日の提出期限の前に最初のドラフトを利用できるようにすることです。
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に関連するWGSの椅子もチームに参加するよう招待されました。これらには、Nasreq WGの共同議長であるDave Mitton、モバイルIP WGの共同議長、RAP WGの共同議長であるMark Stevensが含まれます。
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アドバイザーには、運用および管理エリアのディレクターであるRandy BushとBert Wijnenが含まれます。
1.2. Chairman's Note:
1.2. 議長のメモ：
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）NASREQ、MOBILIP、およびROAMOPSの基本要件ドキュメントに対して、AAA要件ドキュメント[AAAREQTS]を検証します。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.
このグループはマイケル・セントジョンズの議長を務めました。David Mittonはドキュメント編集者でした。以下は、背景声明と、それらとパネルの残りの部分からの利益相反です。
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 WGの共同議長であり、いくつかのNasreqドラフトの著者です。同様に、以前にいくつかの半径ドラフトに貢献していました。
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の実装者であり、技術的なプライムであったので、非常によく知っています。私の現在の仕事の役割では、直径をサポートする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会議のCOPS対NASREQの要件に関するプレゼンテーションを書いていますが、それを実施していませんし、自分自身を主題の専門家とは見なしていません。
Stuart Barkley, 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ベースの使用データ収集システムの設計、開発、運用に関する豊富な経験があります。また、私はまた、私たちのRADIUSベースの認証と認証システムに勧めの位置に関与してきました。
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.
私は過去数年間、RADIUS/ROAMOPS/NASREQ/AAAグループに参加しました。私は、これらのワーキンググループに周辺的に関与していますが、提示されている要件またはプロトコルドキュメントのいずれの著者や貢献者ではありません。
Dave Nelson, Enterasys Networks
Dave Nelson、Enterasysネットワーク
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.
特に初期の頃、半径WGで非常に活発です。AAAの提出に関与していません。直径の開発に貢献していません。
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
バサヴァラジ・パティル、ノキア
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.
Nokiaでの私の現在の仕事は、ワイヤレスネットワークで使用するために（少なくともある程度）AAAプロトコルを見ることを伴います。また、Nortel Networksでの以前の仕事で直径などのAAAプロトコルでいくつかの作業を行ってきました。
Mark Stevens, 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ラップワーキンググループの共同議長です。私は、警官がどのように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ワーキンググループ会議に参加しましたが、グループの充電以来、積極的な参加者ではありませんでした。現在私の従業員がデバイスを構築している会社は、AAA対応の恩恵を受ける可能性があります。
Barney Wolff, Databus Inc.
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のメンバーであり、自分がそれに対する不当な攻撃と見なされることに対する半径の擁護者であると考えています。
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人のパネルメンバーを割り当てました。1人のメンバーが「プロ」のブリーフを書くように割り当てられ、提案の最も寛大な解釈を取ることができました。彼は疑いの恩恵を受けることができました。他のメンバーは「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.
各ブリーフは、個々の要件を調べ、その要件を満たすことで提案がどれほど近づいたかを評価しました。各アイテムは、要件を満たすことができなかったために「F」の1つとしてスコアリングされました。「P」は要件を部分的に満たすため、または要件を完全に満たすために「T」として採点されました。提案は、提示された情報でのみ採点されました。これは、特定のプロトコルが実際に要件の詳細を満たしている可能性があることを意味しますが、提案が記載されていない場合、その要件がどのように満たされたかを説明または参照してください。
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.
パネルは、各提案とプロと詐欺のブリーフについて議論するために、電気会議で会いました。それぞれのブリーフは、ブリーフの高いポイントについて議論し、提案のための彼の概要の調査結果を述べました。次に、個々の要件をグループとして行ごとに説明しました。結論として、メンバーは、その提案に関連する特定の要件のコンセンサス評価を決定するために使用された独自のラインごとの評価を提供しました。会議は、これらの通信事項と個別のブリーフからのメモが付録に含まれています。
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]「AAAネットワークアクセス要件とのSNMPV3の比較」、進行中の作業。
- RADIUS Enhancements:
- 半径の強化：
[RADComp] "Comparison of RADIUS Against AAA Network Access Requirements", Work in Progress.
[RadComp]「AAAネットワークアクセス要件との半径の比較」、進行中の作業。
[RADExt] "Framework for the extension of the RADIUS(v2) protocol", Work in Progress.
[Radext] "Radius（V2）プロトコルの拡張のためのフレームワーク」、進行中の作業。
- Diameter
- 直径
[DIAComp] "Comparison of Diameter Against AAA Network Access Requirements", Work in Progress.
[diacomp]「AAAネットワークアクセス要件との直径の比較」、進行中の作業。
- COPS for AAA:
- AAAの警官：
[COPSComp] "Comparison of COPS Against the AAA NA Requirements", Work in Progress.
[COPSCOMP]「AAA NA要件に対するCOPの比較」、進行中の作業。
[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.
サブセクション番号は、要件ドキュメントセクションとアイテム番号に対応します。この相対番号は、ここでのプロトコル位置のプレゼンテーションでも使用されていました。
3.1.1 Scalability - SNMP:P, RADIUS:P, Diameter:T, COPS:T
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は、現在のエージェントモデルがクライアントリクエストベースのトランザクションにどのように適合するかについての詳細が不足しているため、格下げされました。半径の提案は、問題に適切に対処しませんでした。プロキシのWebに関して、すべての提案にオープンな問題があります。
3.1.2 Fail-over - SNMP:P, RADIUS:P, Diameter:P, COPS:T/P
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.
このグループは、この要件においてプロトコルがうまくいったとは考えていなかったことを特に指摘しました。ほとんどの提出でリンク障害検出とプライマリサーバーの回復を指定するには、不十分な作業が行われました。警官にはいくつかのメカニズムがありますが、すべてではありません。これらのメカニズムがプロキシのウェブでどのように機能するかは対処されていません。
3.1.3 Mutual Authentication - SNMP:T, RADIUS:T/P, Diameter:T, COPS:T
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.
半径の相互認証は、ホップ間のみです。
3.1.4 Transmission Level Security - SNMP:T, RADIUS:P, Diameter: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
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.
直径と警官はどちらもCMS形式を使用してデータオブジェクトを保護します。この方法は、この方法であり、サポートがNASといくつかのタイプのエッジシステムにとって重量が多すぎるかどうかを懸念しています。
3.1.6 Data Object Integrity - SNMP:F, RADIUS:P, Diameter:T, COPS:T
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提案で適切に説明されていませんでした。半径ソリューションもそれほど強くありませんでした。
3.1.7 Certificate Transport - SNMP:T, RADIUS:T, Diameter:T, COPS:T
All protocols can figure out some way to transport a certificate.
すべてのプロトコルは、証明書を輸送する何らかの方法を把握できます。
3.1.8 Reliable AAA Transport - SNMP:P, RADIUS:P, Diameter:T, COPS:T
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および半径の提案は、メッセージの再送信と回復の解決策を提供することに欠けていました。
3.1.9 Run over IPv4 - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.1.10 Run over IPv6 - SNMP:P, RADIUS:T, Diameter:T, COPS:T
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
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の提案は、この要件に対処しませんでした。警官はサポートを主張していますが、いくつかの問題を乗り越えません。直径は、この領域にかなりの領域に対処しようとした唯一のプロトコルでした。
3.1.12 Auditability - SNMP:F, RADIUS:F, Diameter:T, COPS:P
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および半径の提案は、この要件を実行しようとしませんでした。警官は、歴史PIBがこの問題を解決するのに役立つが、説明をしないことを示唆しています。
3.1.13 Shared Secret Not Required - SNMP:P/T, RADIUS:T, Diameter: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
3.2.1 NAI Support - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.2.2 CHAP Support - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.2.3 EAP Support - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.2.4 PAP/Clear-text Passwords - SNMP:T, RADIUS:T, Diameter:T,
COPS:T
The requirement for clear-text passwords comes from one-time-password systems and hard-token (SecurID) systems.
クリアテキストパスワードの要件は、1回限りのパスワードシステムとハードトークン（SecurID）システムに由来しています。
3.2.5 Reauthentication on demand - SNMP:T, RADIUS:P, Diameter: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
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
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
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に直接戻ることができないことに留意されました。しかし、これはすでに半径環境内で問題です。
3.3.3 Reject Capability - SNMP:T/P/F, RADIUS:T, Diameter:T, COPS:P
3.3.4 Preclude Layer 2 Tunneling - SNMP:F, RADIUS:T, Diameter:T,
COPS:T
3.3.5 Reauthorization on Demand - SNMP:P/F, RADIUS:P, Diameter: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
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.
直径の提案のみが実際にこの問題に取り組んでいましたが、グループは、設計されたルールは弱すぎて役に立たないと感じました。また、セマンティクスを定義せずに構文を標準化することについての懸念もありました。
3.3.7 State Reconciliation - SNMP:F, RADIUS:P/F, Diameter:P, COPS:T/P
All of the protocols were weak to non-existent on specifying how this would be done in a web of proxies situation.
すべてのプロトコルは、プロキシの状況のウェブでこれがどのように行われるかを指定することに存在していませんでした。
3.3.8 Unsolicited Disconnect - SNMP:T, RADIUS:P, Diameter:T, COPS:T
3.4.1 Real Time Accounting - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.4.2 Mandatory Compact Encoding - SNMP:T, RADIUS:T, Diameter:T,
COPS:T
3.4.3 Accounting Record Extensibility - SNMP:T, RADIUS:T,
Diameter:T, COPS:T
3.4.4 Batch Accounting - SNMP:T, RADIUS:F, Diameter:P, COPS:P
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.5 Guaranteed Delivery - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.4.6 Accounting Timestamps - SNMP:T, RADIUS:T, Diameter:T,
COPS:T
3.4.7 Dynamic Accounting - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.5.1 Encoding of MOBILE IP Registration Messages - SNMP:T,
RADIUS:T/P, Diameter:T, COPS:T
3.5.2 Firewall Friendly - SNMP:F, RADIUS:T, Diameter:P, COPS:P
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やCOPなどのプロトコルは、意図した操作を理解するためにパケットをはるかに見なければならないため、不利な点にあります。直径にはSCTPの欠点があり、現時点では十分に展開または認識されていません。
SNMP and COPS also have the problem that they are used for other types of operations than just AAA.
SNMPと警官には、AAA以外の他のタイプの操作に使用されているという問題もあります。
Should firewalls have AAA Proxy engines?
ファイアウォールにはAAAプロキシエンジンが必要ですか？
We didn't look at "NAT friendly" issues either.
「ナットフレンドリー」の問題も見ませんでした。
COPS:T
警官：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＆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 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プロトコルとして受け入れられると見なされます。要件を完全に順守するために必要なマイナーエンジニアリングが必要ですが、短期的な機能内に十分です。直径は、より広範なデータモデルALA COPSを含めることからも恩恵を受ける可能性があります。
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.
パネルは、直径の作業は警官よりもさらに並んでいるという認識に基づいて、直径のわずかな好みを表しています。ただし、直径の輸送メカニズムとしてSCTPを使用すると、直径の重要なパスにSCTPが配置されます。これにより、SCTPが何らかの形で遅れている場合、COPはより速いアプローチになる可能性があります。
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.、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。、およびE. Jaques、「ネットワークの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、sales and paridaens、「AAAプロトコル：半径、直径、警官の比較」、進行中の作業。
[SNMPComp] Natale, "Comparison of SNMPv3 Against AAA Network Access Requirements", Work in Progress.
[SNMPComp] Natale、「SNMPV3とAAAネットワークアクセス要件の比較」、進行中の作業。
[RADComp] TJoens and DeVries, "Comparison of RADIUS Against AAA Network Access Requirements", Work in Progress.
[radcomp] tjoens and devries、「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] Calhoun、「AAAネットワークアクセス要件との直径の比較」、進行中の作業。
[COPSComp] Khosravi, Durham and Walker, "Comparison of COPS Against the AAA NA Requirements", Work in Progress.
[Copscomp] Khosravi、Durham、およびWalker、「AAA NA要件に対する警官の比較」、進行中の作業。
[COPSAAA] Durham, Khosravi, Weiss and Filename, "COPS Usage for AAA", Work in Progress.
[Copsaaa] Durham、Khosravi、Weiss、Filename、「Cops for aaa」は進行中の作業。
David Mitton Nortel Networks 880 Technology Park Drive Billerica, MA 01821
David Mitton Nortel Networks 880 Technology Park Drive Billerica、MA 01821
Phone: 978-288-4570 EMail: dmitton@nortelnetworks.com Michael StJohns Rainmaker Technologies 19050 Pruneridge Ave, Suite 150 Cupertino, CA 95014
電話：978-288-4570メール：dmitton@nortelnetworks.com Michael Stjohns Rainmaker Technologies 19050 Pruneridge Ave、Suite 150 Cupertino、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
スチュアートバークリーウネットF1-1-612 22001ラウドンカウンティパークウェイアシュバーン、バージニア州20147米国
Phone: 703-886-5645 EMail: stuartb@uu.net
電話：703-886-5645メール：stuartb@uu.net
David B. Nelson Enterasys Networks, Inc. (a Cabletron Systems company) 50 Minuteman Road Andover, MA 01810-1008
David B. Nelson Enterasys Networks、Inc。（Cabletron Systems Company）50 Minuteman Road Andover、MA 01810-1008
Phone: 978-684-1330 EMail: dnelson@enterasys.com
電話：978-684-1330メール：dnelson@enterasys.com
Basavaraj Patil Nokia 6000 Connection Dr. Irving, TX 75039
Basavaraj Patil Nokia 6000 Connection Dr. Irving、TX 75039
Phone: +1 972-894-6709
EMail: Basavaraj.Patil@nokia.com
Mark Stevens Ellacoya Networks 7 Henry Clay Drive Merrimack, NH 03054
マークスティーブンスエラコーヤネットワーク7ヘンリークレイドライブメリマック、ニューハンプシャー03054
Phone: 603-577-5544 ext. 325 EMail: mstevens@ellacoya.com
電話：603-577-5544内線325メール：mstevens@ellacoya.com
Barney Wolff, Pres. Databus Inc. 15 Victor Drive Irvington, NY 10533-1919 USA
バーニー・ウルフ、プレス。DataBus Inc. 15 Victor Drive Irvington、NY 10533-1919 USA
Phone: 914-591-5677 EMail: barney@databus.com
電話：914-591-5677メール：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
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.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
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.
PANERのコメントは、進行中の作業「ネットワークアクセスのAAAプロトコルを評価するための基準」で、RFC 2989として改訂および公開されました。これは、当時の要件のグループ標準解釈になりました。
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を介して実行します[表]モバイルIP脚注「17」を脚注「33」に置き換えます。これは誤った参照のようです。
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を介して実行します[表]モバイルIP脚注「18」を[8]のセクション8を指す脚注に置き換えます。これは誤った参照のようです。
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]で指定されているように解釈することを選択しました。テーブルのタグを「デュアルアプリと輸送セキュリティは不要」に置き換えることをお勧めします。NASREQドキュメントではサポートされていないように、Nasreq "S"と脚注「28」を削除します。サポートされていないモバイルIP "O"と脚注「34」と39「および39」を削除します。
NAI Support - [Table] Replace MOBILE IP footnote "38" with "39". This appears to be a more appropriate reference.
NAIサポート - [表]モバイルIPフットノート「38」を「39」に置き換えます。これは、より適切な参照のようです。
CHAP Support - [Table] Delete MOBILE IP "O" as unsupported.
CHAPサポート - [表]サポートされていないモバイルIP "O"を削除します。
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/CLEAR -TEXTサポート - [表] NASREQの脚注「10」を「26」に置き換えます。roamops "b"を「o」に置き換えます。参照テキストはこれを明示的に禁止していないようであり、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要件、特に不要な資格情報を記入する必要はないことを承認する必要はありません。f] Nasreqと並んで連れて行かれます。[表]モバイルIP "O"と脚注「30」を削除します。参照されたテキストは、要件をサポートしていないようです。
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.
アクセスルールのサポート... -Clarification [e]には、要件のオーバーロードリストがあります。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はこの分野に要件を持つ唯一のサービスです。
Real-Time accounting - [Table] Replace MOBILE IP footnote [39] with a footnote pointing to section 3.1 of [3] as being more appropriate.
リアルタイム会計 - [表]モバイルIP脚注[39]を、[3]のセクション3.1を指し示す脚注に置き換えます。
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.
動的会計 - [表] Nasreqの脚注「18」を[3]のセクション8.4.1.5を指す脚注に置き換えます。参照が要件をサポートしていないため、モバイル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].
Appendix C - Position Briefs
付録C-位置ブリーフ
Evaluation of SNMP AAA Requirements PRO Evaluation Evaluator - Stuart Barkley
SNMP AAA要件の評価プロ評価評価者-Stuart Barkley
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'
ref [1]は「AAAネットワークアクセス要件とのSNMPV3の比較」、別名「ドキュメント」ref [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 a change, I've indicated that and the grade given by the authors.
ドキュメントはTを使用して完全なコンプライアンスを示し、Pは部分的なコンプライアンスを示し、Fはコンプライアンスを示さないことを示します。各セクションについて、セクションの成績を示しました。変更がある場合、私はそれと著者によって与えられた成績を示しました。
1 Per item discussion
アイテムのディスカッションごとに1
1.1 General Requirements
1.1 一般的な要件
1.1.1 Scalability - Grade T
1.1.1 スケーラビリティ - グレードt
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は、この実装を支援するために、既存のネットワーク管理プラクティスを利用できます。
1.1.2 Fail-over - Grade T
1.1.2 フェールオーバー - グレードt
SNMP is of vital importance to the operation of most networks. Existing infrastructures can handle required failover or other redundant operations.
SNMPは、ほとんどのネットワークの動作にとって非常に重要です。既存のインフラストラクチャは、必要なフェールオーバーまたはその他の冗長操作を処理できます。
1.1.3 Mutual Authentication - Grade T
1.1.3 相互認証 - グレードt
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認証を大幅にバイパスする実質的な誤用に開放される可能性があります。
1.1.4 Transmission Level Security - Grade T
1.1.4 トランスミッションレベルのセキュリティ - グレードt
SNMPv3 provides many additional security options which were not available or were more controversial in previous SNMP versions.
SNMPV3は、以前のSNMPバージョンでは利用できない、またはより物議を醸した多くの追加のセキュリティオプションを提供します。
1.1.5 Data Object Confidentiality - New Grade P (from T)
1.1.5 データオブジェクトの機密性 - 新しいグレードP（Tから）
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パスワードの転送で）。
1.1.6 Data Object Integrity - New Grade T (from P)
1.1.6 データオブジェクトの整合性 - 新しいグレードT（Pから）
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に格下げしています。
1.1.7 Certificate Transport - Grade T
1.1.7 証明書輸送 - グレードt
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は、任意のオブジェクトを輸送し、必要に応じて証明書を輸送できます。このドキュメントは、証明書のサイズと現在の最大の実用的なデータサイズに関するいくつかの問題を示していますが、コンパクトなエンコード要件が内部証明書情報に拡張された場合、これは問題ではありません。
1.1.8 Reliable AAA Transport - New Grade T (from P)
1.1.8 信頼できるAAAトランスポート - 新しいグレードT（Pから）
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は、データの重要性に応じて、再送信スキームの柔軟性を大きく可能にします。
1.1.9 Run over IPv4 - Grade T
1.1.9 IPv4 -grade tを実行します
SNMP has operated in this mode for many years.
SNMPは長年このモードで動作してきました。
1.1.10 Run over IPv6 - New Grade T (from P)
1.1.10 IPv6を介して実行 - 新しいグレードT（Pから）
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をサポートする必要があるため、要件が効果的になるまでにこれをサポートすることが可能です。このドキュメントは、この要件を満たす実験バージョンがすでに存在していることを示しています。
1.1.11 Support Proxy and Routing Brokers - New Grade T (from P)
1.1.11 プロキシとルーティングブローカーをサポート - 新しいグレードT（Pから）
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に格下げした「Data Objectively」でより具体的にカバーされている問題により、この要件のSNMPSコンプライアンスを格下げします。
1.1.12 Auditability - New Grade T (from F)
1.1.12 監査可能性 - 新しいグレードT（Fから）
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内のデータフローは、すべての情報のコピーを補助サーバーに提供する二次データフローを確立することにより、簡単に監査できます。ドキュメントはこれを障害として評価しますが、このサポートは、より完全に具体化されたデータフロー内のわずかな追加です。
1.1.13 Shared Secret Not Required - Grade T
1.1.13 共有秘密は不要-GradeT
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では必要ありません。これらは、より低いレベルが必要な機能を提供しない多くの場合に望ましいです。このドキュメントは、利用可能なさまざまなセキュリティモードへのポインターを提供します。
1.1.14 Ability to Carry Service Specific Attributes - Grade T
1.1.14 サービス固有の属性を携帯する能力 - グレードt
SNMP has long had the ability for other parties to create new unambiguous attributes.
SNMPは、他の関係者が新しい明確な属性を作成する能力を長い間持っていました。
1.2 Authentication Requirements
1.2 認証要件
1.2.1 NAI Support - Grade T
1.2.1 NAIサポート - グレードt
SNMP easily supports this. NAIs were defined to be easily carried in existing protocols.
SNMPはこれを簡単にサポートします。NAISは、既存のプロトコルで簡単に運ばれると定義されました。
1.2.2 CHAP Support - Grade T
1.2.2 チャップサポート - グレードt
SNMP can easily provide objects to pass the necessary information for CHAP operation.
SNMPは、CHAP操作に必要な情報を渡すためのオブジェクトを簡単に提供できます。
1.2.3 EAP Support - New Grade T (from P)
1.2.3 EAPサポート - 新しいグレードT（Pから）
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と同様に、この操作を制御するために作成することができます。したがって、ドキュメントグレードからのアップグレード。
1.2.4 PAP/Clear-text Passwords - New Grade P (from T)
1.2.4 PAP/クリアテキストパスワード - 新しいグレードP（Tから）
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（部分）に格下げされます。
1.2.5 Reauthorization on demand - Grade T
1.2.5 オンデマンドの再承認 - グレードt
SNMP can easily provide objects to control this operation.
SNMPは、この操作を制御するオブジェクトを簡単に提供できます。
1.2.6 Authorization w/o Authentication - New Grade T (from T)
1.2.6 認証付き認証 - 新しいグレードT（Tから）
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によって満たされるため、実際のグレードの変更は必要ありません。
1.3 Authorization Requirements
1.3 承認要件
1.3.1 Static and Dynamic IP Addr Assignment - Grade T
1.3.1 静的および動的IP ADDR割り当て-Grade T
SNMP can easily provide objects to control this operation.
SNMPは、この操作を制御するオブジェクトを簡単に提供できます。
1.3.2 RADIUS Gateway Capability - Grade T
1.3.2 RADIUSゲートウェイ機能 - グレードt
As the document describes, with the addition of any necessary compatibility variables SNMP can be gatewayed to RADIUS applications.
ドキュメントが説明しているように、必要な互換性変数を追加すると、SNMPはRADIUSアプリケーションにゲートウェイで済みます。
1.3.3 Reject Capability - Grade T
1.3.3 拒否機能 - グレードt
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ベースの構造のアクティブコンポーネントは、何らかの理由で拒否および認証要求を決定する可能性があります。さまざまなレベルの要件を混合しているため、ドキュメントはこれに直接対処しようとはしません。代わりに、より高いレベルのアプリケーションがこの操作を引き起こす可能性があることを示します。
1.3.4 Preclude Layer 2 Tunneling - New Grade T (from ?)
1.3.4 レイヤー2トンネリングを排除 - 新しいグレードT（from？）
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の何も、クライアントが選択できるトンネルメカニズムの選択と明示的に相互作用するものはありません。ドキュメントの著者は、ここでのニーズについて不明でした。
1.3.5 Reauth on Demand - Grade T
1.3.5 オンデマンドreauth -grade t
SNMP can easily provide objects to control this operation.
SNMPは、この操作を制御するオブジェクトを簡単に提供できます。
1.3.6 Support for ACLs - Grade T
1.3.6 ACLSのサポート-GradeT
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が望ましい場合は、これらの操作を制御するオブジェクトを提供できることを示しています。さらに、アクティブなコンポーネントは、大幅な構成可能なアクセス制御を適用できます。
1.3.7 State Reconciliation - Grade T
1.3.7 状態和解 - グレードt
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は、アクティブなコンポーネントが失われた状態情報を再取得できるようにする方法を提供できます。これらの機能は、スケーラビリティの懸念と直接相互作用する必要があります。この要件がスケーラビリティ要件と同時に満たされることを期待する場合は、注意を払う必要があります。
1.3.8 Unsolicited Disconnect - Grade T
1.3.8 未承諾の切断 - グレードt
The document indicates that SNMP can easily provide objects to control this operation.
このドキュメントは、SNMPがこの操作を制御するオブジェクトを簡単に提供できることを示しています。
1.4 Accounting Requirements
1.4 会計要件
1.4.1 Real Time Accounting - Grade T
1.4.1 リアルタイム会計 - グレードt
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を使用しています。この機能は、スケーラビリティの懸念と直接相互作用することができ、これを適切に相互作用させるために実装ケアを取る必要があります。
1.4.2 Mandatory Compact Encoding - Grade T
1.4.2 必須のコンパクトエンコーディング - グレードt
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エンコードプロトコル要素は、一般に、テキストベースのフォームと比較してかなりコンパクトなエンコードフォームにあります（既存のRADIUSログファイルの実装で使用されています）。これは、サービス固有の属性を運ぶための一般的な要件と、拡張性のための会計要件と相互作用します。慎重なMIB設計とSNMPペイロード圧縮に関する将来の作業により、SNMPコーディングオーバーヘッドは、他の拡張可能なプロトコルと同等になります。
1.4.3 Accounting Record Extensibility - Grade T
1.4.3 会計記録の拡張性 - グレードt
SNMP has a strong tradition of allowing vendor specific data objects to be transferred.
SNMPには、ベンダー固有のデータオブジェクトを転送できるようにする強力な伝統があります。
1.4.4 Batch Accounting - Grade T
1.4.4 バッチアカウンティング - グレードt
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ログテーブルは、リアルタイム機能に直接関係しない多くの方法で取得できる会計情報を提供できます。基礎となるシステムバッファリング要件は、情報の輸送に使用されるプロトコルに関係なく類似しています。
1.4.5 Guaranteed Delivery - Grade T
1.4.5 保証配達 - グレードt
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は、保証された配信を提供することに非常に適しています。特に、プルモデル（しばしば想定されるプッシュモデル）では、データ収集者はすべてのデータが転送されたことを完全に知ることができます。一般的なプッシュモデルでは、データ受信機は、データの発信者がデータの配信に問題を抱えているかどうかを知りません。
1.4.6 Accounting Timestamps - Grade T
1.4.6 会計タイムスタンプ - グレードt
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ベースの操作に使用されます。ドキュメントは、使用可能なデータアンドタイムテキスト条約を指します。すべての環境と同様に、情報が依存する前にタイムスタンプの精度が評価される必要があります。
1.4.7 Dynamic Accounting - Grade T
1.4.7 動的会計 - グレードt
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.
複数のレコードを一緒に関連付ける方法がある限り、同じセッションの複数のレコードを解決するのに問題はありません。これはスケーラビリティの要件と相互作用し、これらの両方の要件を備えたシステムを実装するときに注意する必要があります。
1.5 MOBILE IP Requirements
1.5 モバイルIP要件
1.5.1 Encoding of MOBILE IP Registration Messages - Grade T
1.5.1 モバイルIP登録メッセージのエンコード-GradeT
SNMP can easily provide objects to transfer this information.
SNMPは、この情報を転送するオブジェクトを簡単に提供できます。
1.5.2 Firewall Friendly - New Grade T (from P)
1.5.2 ファイアウォールフレンドリー - 新しいグレードT（Pから）
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プロキシとは対照的に）は、ファイアウォールを必要とする組織のファイアウォールでは一般的なコンポーネントになるはずです。
1.5.3 Allocation of Local Home Agent - New Grade T (from ?)
1.5.3 地元のホームエージェントの割り当て-New Grade T（from？）
SNMP is not concerned with the LHA. This can be under control of the Local network to meet its needs.
SNMPはLHAに関心がありません。これは、ニーズを満たすためにローカルネットワークを制御できます。
2. Summary Discussion
2. 要約ディスカッション
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プロトコルは、既存のネットワーク管理およびその他の大量データ転送操作でスケーラブルであることが証明されています。希望するレベルのサービスを確実に満たすために、大規模システムの設計に注意する必要がありますが、これは大規模なプロジェクトに当てはまります。
3. General Requirements
3. 一般的な要件
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の提案は、実装される特定のデータ変数とメッセージタイプについて沈黙しています。これは主に、必要なデータ要素を指定していない要件と、ベースドキュメントセットからその情報を抽出する際の時間制約が原因です。このようなデータモデルは、選択された究極のプロトコルに関係なく必要です。
4. Summary Recommendation
4. 概要の推奨
SNMP appears to fully meet all necessary requirements for the full AAA protocol family.
SNMPは、完全なAAAプロトコルファミリに必要なすべての要件を完全に満たしているようです。
Evaluation of SNMP AAA Requirements CON Evaluation Evaluator - Michael StJohns
SNMP AAA要件の評価Con評価評価者-MichaelStjohns
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.
ref [1]は「snmpv3とAAAネットワークアクセス要件との比較」であり、別名「ドキュメント」ref [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.
ドキュメントはTを使用して完全なコンプライアンスを示し、Pは部分的なコンプライアンスを示し、Fはコンプライアンスを示さないことを示します。各セクションについて、セクションの成績を示しました。変更がない場合、私はそれと著者によって与えられた成績を示しました。
Section 1 - Per item discussion
セクション1-アイテムのディスカッションごと
1.1 General Requirements
1.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人のエージェントに連絡する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.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.2 フェールオーバー - ドキュメントは、提案されたプロトコルの特性であるメカニズムではなく、このメカニズムを提供するためのアプリケーションレベルのタイムアウトを使用することを示します。プロトコルは、要件の部分的なコンプライアンスのみを提供します。評価-P 1.1.3相互認証 - ここにはわずかな手順がありますが、プロトコルの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 データオブジェクトの整合性 - ここで何らかの手順が起こっているようです。繰り返しますが、SNMPは、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の使用が基礎となる輸送に関係なく、この要件のサポートが少なくとも部分的に輸送の選択に関連していることを示しています。ただし、SNMPの最も一般的なモードであるUDP上の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)
1.1.9 IPv4を介して実行 - 評価者は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)
1.1.10 IPv6を介して実行 - このドキュメントは、実験的実装と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.12 Auditability - The document indicates no compliance with this requirement. Eval - No Change (F)
1.1.11 プロキシとルーティングブローカーをサポート - タイトルでは、SNMPプロキシの議論がTBDとしてマークされるべきであるドキュメントのセクション（5.5.3）。このセクションでは、データオブジェクトの機密性と整合性の要件を完全に遵守できないことが、このセクションのコンプライアンスに影響し、評価者が同意する可能性があることに注目しています。評価-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 共有秘密は必須ではありません - ここではわずかな手順ですが、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は、MIBSを使用して準拠しています。評価 - 変更なし（t）
1.2 Authentication Requirements
1.2 認証要件
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
1.2.1 NAIサポート - このドキュメントは、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/CLEAR -TEXTパスワード - ドキュメントは、MIBオブジェクトを使用してクリアテキストのパスワードを携帯することと、通常のSNMPV3セキュリティメカニズムの下でそれらのオブジェクトの保護を指摘しています。評価 - 変更なし（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)
1.2.5 オンデマンドの再承認 - ここには何らかの手順がありますが、特定のアプリケーションがSNMPの下で再承認をトリガーするための信号を生成できることは明らかです。評価 - 変更なし（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
1.2.6 認証付き認証 - 著者は、AAAユーザー認可とAAAプロトコル認証を混同しているようであり、SNMPが一般的なAAAユーザー許可に対処する能力を一般化しすぎているようです。評価-F
1.3 Authorization Requirements
1.3 承認要件
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.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.1 静的および動的IP ADDR割り当て - より明確な参照または説明のないMIBオブジェクトへの参照は引き続き否定的です。評価者は、MIBオブジェクトがアドレスを表すことができることに同意しますが、ドキュメントは少なくとも適切な方向に読者を導く必要があります。評価-F 1.3.2半径ゲートウェイ機能 - 半径オブジェクトの輸送と操作は、必要なものの一部にすぎないようです。評価-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 オンデマンドReauth-上記の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
1.3.6 ACLSのサポート - 応答テキストは、このジョブを実行するために定義できる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 Accounting Requirements
1.4 会計要件
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 Batch Accounting -MIBSは、さまざまな時期にデータ収集を提供します。評価 - 変更なし（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.6 Accounting Timestamps - Accounting records can use the DateAndTime Textual Convention to mark their times. Eval - No Change (T)
1.4.5 保証された配達 - 保証された意味に関して、ここにはいくつかのイタチの言葉遣いがありますが、メカニズムの説明は要件を満たしているように見えます。評価 - 変更なし（t）1.4.6会計タイムスタンプ - 会計記録は、データアンドタイムテキスト条約を使用して時間をマークすることができます。評価 - 変更なし（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 MOBILE IP Requirements
1.5 モバイルIP要件
1.5.1 Encoding of MOBILE IP Registration Messages - Registration messages can probably be encoded as SNMP messages. Eval - No Change (T)
1.5.1 モバイルIP登録メッセージのエンコーディング - 登録メッセージは、おそらく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 ファイアウォールフレンドリー - 著者がAAAプロトコルとしてのSNMPがファイアウォールベンダーにSNMPがSNMPをファイアウォールに優しいプロトコルにすることを奨励することを著者が望んでいるという点で、要件に対する鶏肉と卵の問題があります。評価-F
1.5.3 Allocation of Local Home Agent - The author disclaims an understanding of this requirement. Eval - F
1.5.3 地元のホームエージェントの割り当て - 著者は、この要件の理解を否認します。評価-F
2. Summary Discussion
2. 要約ディスカッション
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を示すものではないことにも注目しています。これは、AAAの役割でSNMPの使用を大幅に損なう可能性があります。
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は、既存のテクノロジーと要件に適しているようです。
3. General Requirements
3. 一般的な要件
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対応プロトコルの一般的な要件を満たしているように見えますが、すべての特定の要件に適切な使用分野がない場合があります。
4. Summary Recommendation
4. 概要の推奨
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は、認証または承認プロトコルとして使用することは推奨されませんが、会計プロトコルとして使用することをお勧めします。
Evaluation of RADIUS AAA Requirements PRO Evaluation
RADIUS AAA要件プロの評価の評価
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.
ref [1]は「AAAネットワークアクセス要件との半径の比較」Ref [2]は、「RADIUS（V2）プロトコルの拡張のためのフレームワーク」REF [3]は、当社によって変更されたAAA評価基準です。
The documents uses T to indicate total compliance, P to indicate partial compliance and F to indicate no compliance.
ドキュメントでは、Tを使用して完全なコンプライアンスを示し、Pは部分的なコンプライアンスを示し、Fはコンプライアンスを示さないことを示します。
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.
各セクションについて、セクションの成績を示しました。私は、私の評価が半径に関して行われたステートメントと異なるかどうかを示しました。以下に示すような評価評価は、「AAAネットワークアクセス要件とのRADIUSの比較」と呼ばれる文書で成文化された評価とは異なる場合があります。
1.1 General Requirements
1.1 一般的な要件
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]スケーラビリティ - プロトコルのスケーラビリティを測定できるのと同じくらい、プロトコルは情報をかなり効率的な方法で送信しているように見えます。そのため、プロトコルは、送信しているデータと比較して、膨大な量の帯域幅を消費しないように見えます。、このプロトコルはスケーラブルと見なすことができます。ただし、プロトコルには、エンドポイント間でサポートできる同時セッションの数に制限があります。回避策は存在し、使用されています。評価-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.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.2 [b]フェールオーバー - ドキュメントは、提案されたプロトコルの特徴であるメカニズムではなく、このメカニズムを提供するためのアプリケーションレベルのタイムアウトを使用することを示しています。フェールオーバー要件は、プロトコルがアプリケーションではなくメカニズムを提供する必要があることを示しています。意味は、アプリケーションが発生したときにフェールオーバーとその後の修正を認識する必要はないということです。RADIUSプロトコルを使用したアプリケーションは、フェイルオーバー回復活動に関与します。ソフトウェアのプロトコル層には、機能が組み込まれているようには見えません。要件の文言を考えると、評価-p（tから変更）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]データオブジェクトの機密性 - ドキュメントは、暗号化された半径メッセージ（属性）が同封される可能性のある封筒としてサーバーに設計された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 -Data 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トンネルプロトコルで増強された場合、半径は信頼できる輸送と見なすことができることを指摘しています。プロトコル自体は、信頼性の機能を提供しません。信頼性は、アプリケーションまたは増強プロトコルの責任のままです。評価-P（変更なし）
1.1.9 [i] Run over IPv4 - Eval - T (no change)
1.1.9 [i] IPv4を介して実行 - 評価-T（変更なし）
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.14 [n] Ability to Carry Service Specific Attributes - Vendor
escape mechanism can be used for this purpose.. Eval - T (no
change)
1.2 Authentication Requirements
1.2 認証要件
1.2.1 [a] NAI Support - Eval - T (no change)
1.2.1 [a] naiサポート - 評価-T（変更なし）
1.2.2 [b] CHAP Support - Subject to dictionary attacks. Eval - P (changed from T)
1.2.2 [b] Chap Support-辞書攻撃の対象。評価-P（Tから変更）
1.2.3 [c] EAP Support - Eval - T (no change)
1.2.3 [c] EAPサポート - 評価-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/Clear-Textパスワード - エンドツーエンドのセキュリティはありませんが、プロトコルの現在のパラダイム内にはカプセル化の可能性があります。 - eval -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]認証付き認証 - 半径がAW/OAをサポートできるようにするために、新しいメッセージタイプを作成できます。評価-T（変更なし）
1.3 Authorization Requirements
1.3 承認要件
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ゲートウェイ機能 - 半径オブジェクトの輸送と操作は、必要なものの一部にすぎないようです。要件は、半径を排除するために表現されているようです。評価-P（Tから変更）
1.3.3 [c] Reject Capability - Eval -T
1.3.3 [c]能力を拒否する-TAL -T
1.3.4 [d] Preclude Layer 2 Tunneling - I do not see a definition in the AAA eval criteria document. Eval - ? 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.4 [D]レイヤー2トンネリングを排除 - AAA Eval Criteriaドキュメントに定義は表示されません。評価 - ？1.3.5 [e]需要の再認可 - フィールドでの実装は、半径までの拡張が望ましい動作をサポートできることを示しています。現在、再承認は再承認と結びついています。評価-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] ACLSのサポート - 現在、プロトコル内ではなく、半径のエンドポイントの背後にあるアプリケーションで行われています。RADIUSは、新しいサービスエリア内の拡張されたアクセス制御に対処するために、追加のメッセージタイプを定義できます。評価-P（変更なし）
1.3.7 [g] State Reconciliation - Eval - F (no change)
1.3.7 [g]状態和解 - 評価-F（変更なし）
1.3.8 [h] Unsolicited Disconnect - RADIUS++ extensions to support.
Eval - T. (no change)
1.4 Accounting Requirements
1.4 会計要件
1.4.1 [a] Real Time Accounting - Eval - T (no change)
1.4.1 [a]リアルタイム会計 - 評価-T（変更なし）
1.4.2 [b] Mandatory Compact Encoding - Eval - T (no change)
1.4.2 [b]必須のコンパクトエンコーディング - 評価-T（変更なし）
1.4.3 [c] Accounting Record Extensibility - Eval - T (no change)
1.4.3 [c]会計記録の拡張性 - 評価-T（変更なし）
1.4.4 [d] Batch Accounting - RADIUS++ offers no new features to
support batch accounting. Eval - F No change)
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.7 [g] Dynamic Accounting - RADIUS++ extensions to support. Eval - T (no change)
1.4.7 [g]動的会計 - サポートする半径拡張機能。評価-T（変更なし）
1.5 MOBILE IP Requirements
1.5 モバイルIP要件
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]ファイアウォールに優しい - 半径は、プロキシとして機能するファイアウォールがアクティブである環境で動作することが知られています。評価-T（変更なし）
1.5.3 [c] Allocation of Local Home Agent -Requirement statement needs some clarification and refinement. Eval - F (no change) 2. Summary Discussion
1.5.3 [c]地元のホームエージェントの割り当て - 強化声明は、いくらかの明確化と改良が必要です。評価-F（変更なし）2。要約ディスカッション
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クライアントとサーバーの幅広い展開とインストールされたベースとの高いレベルの相互運用性を維持することが可能です。
3. General Requirements
3. 一般的な要件
RADIUS++ the protocol and the application meet the majority of the requirements and can be extended to meet the requirements where necessary.
RADIUSプロトコルとアプリケーションは要件の大部分を満たし、必要に応じて要件を満たすために拡張できます。
4. Summary Recommendation
4. 概要の推奨
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.
開発できる半径は、他のプロトコルが達成できないレベルの後方互換性を提供します。上記のドキュメントに記載されている簡単な方法で半径を延長することにより、既存の半径ベースのインストールから半径のインストールへの移行が簡単になります。会計は他のアプローチよりも弱くなっていますが、プロトコルは承認と認証の分野で継続的に使用するための強力な候補者のままです。
Evaluation of RADIUS++ (sic) AAA Requirements CON Evaluation Evaluator - David Nelson
RADIUS（sic）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
ref [1]は「AAAネットワークアクセス要件との半径の比較」、別名「ドキュメント」ref [2]は「RADIUS（V2）プロトコルの拡張のフレームワーク」、別名「プロトコル」ref [3]です。私たちによって変更されたAAA評価基準。Ref [4]はRFC2869です。Ref[5]は、進行中の期限切れの作業「半径X.509証明書拡張機能」です。ref [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.
ドキュメントはTを使用して完全なコンプライアンスを示し、Pは部分的なコンプライアンスを示し、Fはコンプライアンスを示さないことを示します。評価者の注：ドキュメント[1]はプロトコル[2]を事前に日付付けしています。[2]の読書[2]から、[1]で短いcomingsとして特定された問題のいくつかが現在[2]で対処されていることは明らかです。評価者は、これらの例外が発生する場所に注意を払おうとしました。
Section 1 - Per item discussion
セクション1-アイテムのディスカッションごと
1.1 General Requirements
1.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]の「3]の「数万の同時リクエスト」言語に主に敬意を表して、部分的なコンプライアンスを示します。単一のAAAクライアントからの同時リクエストの問題は[1]で対処されています。これは、リクエストのソースUDPポート番号などのよく知られている手法を使用して、256の一意に識別可能な未解決のリクエストの明らかな制限を実行できることを示しています。ドキュメントは「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パケットまたは任意のパケットにメッセージ-Authenticator [4]にユーザーパスワードまたはチャップパスワード属性の存在下で相互認証が存在することを示します。繰り返しになりますが、これは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]は、セクション1.1.3で説明されているメカニズムを使用して、[3]で定義されている送信層セキュリティがプロトコルで提供されていることを示しています。この要件は現在[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]は、エンドツーエンドの機密性が半径では利用できないことを示していますが、さらに追加できると述べています。プロトコル[2]は、RFC 2630に主に基づいて、CMS-DATA属性を使用して、[2]のセクション4.3.2.2で、これがどのように行われるかを指定しようとする試みを試みます。評価者はそうではありません。時間、RFC 2630のAAA作業への適用性を調査しました。このドキュメントは「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]は、エンドツーエンドの整合性が半径で使用できないことを示していますが、さらに追加できると述べています。プロトコル[2]は、RFC 2630に主に基づいて、CMS-DATA属性を使用して、[2]のセクション4.3.2.1で、これがどのように行われるかを指定しようとする試みを試みます。評価者はそうではありません。時間、RFC 2630のAAA作業への適用性を調査しました。このドキュメントは「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]は、証明書輸送が半径で利用できないことを示していますが、さらに追加できると言っています。プロトコル[2]は、RFC 2630に主に基づいて、CMS-DATA属性を使用して、[2]のセクション4.3.2.3で、これがどのように行われるかを指定しようとする試みを試みます。評価者はそうしていません。時間、RFC 2630のAAA作業への適用性を調査しました。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.
1.1.9 IPv4を介して実行 - 半径は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.
1.1.10 IPv6を介して実行 - ドキュメント[1]は、IPv6をサポートするための限られた数の新しいRADIUS属性の採用が簡単であることを示しています。このような議論は、Radius WGメーリングリストで繰り返されていますが、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サーバーのプロキシチェーンに広く展開されていることを示しています。これはプロキシブローカーのケースに相当しますが、ルーティングブローカーのケースは別の要件です。プロトコル[2]は、ルーティングブローカーがどのように収容されるかについての詳細を説明していませんが、RADIUSプロトコルがクライアント/サーバーではなくピアツーピアであることを示してドアを開きます。この文書は「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 Authentication Requirements
1.2 認証要件
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がNAIをユーザー名属性の推奨フォーマットの1つとして指定していることを示しています。ドキュメントは「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 Support -Chap Supportは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/Clear-Textパスワード - ドキュメント[1]は、RADIUSがホップバイホップベースでクリアテキストパスワードの保護を提供することを示しています。プロトコル[2]は、RFC 2630に基づいてCMS-DATA属性を使用して、[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がサーバーからクライアントに送信されたアクセスチャレンジメッセージによって、オンデマンドの再認証を達成できることを示しています。評価者は、クライアントがアクセス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.
1.2.6 認証付き認証 - プロトコル仕様に適用されるこの要件は、許可のリクエストに必要でない認証資格が必要ないことを義務付けています。認証がない場合に承認を提供するという実際の決定は、アプリケーション（AAAサーバーなど）にあります。RADIUSは、リクエストメッセージで何らかの形の資格情報を必要とします。ドキュメント[1]は「F」を主張し、評価者は同意します。
1.3 Authorization Requirements
1.3 承認要件
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 Gateway機能 - ドキュメント[1]は、半径から半径のゲートウェイがかなりトートロジーであると主張しています。ドキュメントは「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]が半径のレイヤー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 reauth on Demand-Document [1]は、RADIUSがセッションの時間と終了アクション属性によってこの機能を提供することを示しています。実際、これは定期的な再承認を提供するのに十分である可能性がありますが、オンデマンドの再認可は提供されません。プロトコル[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.
1.3.6 ACLSのサポート - ドキュメント[1]は、[3]で説明されているアクセス制御を伝えるために使用される半径の属性を説明しています。これらの特定（QOなど）は現在半径で定義されていませんが、新しい半径属性として簡単に定義できます。ドキュメントは「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 状態調整 - ドキュメント[1]は、元のAAA要件ドキュメントにリストされているように、各サブ項目に対応します。[3]の変更された要件に対してドキュメントを確認する際、サーバーが開始した状態調整メッセージにはまだ問題があります。プロトコル[2]は、サーバーがプロトコルダイアログの開始を許可されているため、そのようなメッセージを提供しますが、詳細なメッセージ形式は提供されていません。これは、伝統的に半径の短い到来であった領域です。この文書は「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 Accounting Requirements
1.4 会計要件
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.
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 Batch Accounting -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]に含まれていないセッションアカウンティング拡張機能、つまり期限が切れた作業の一部に関するAdius WGには、進行中の作業がありました。ドキュメントは[1]「P」を主張し、評価者は同意します。
1.5 MOBILE IP Requirements
1.5 モバイルIP要件
1.5.1 Encoding of MOBILE IP Registration Messages - The document [1] claims "F", and the evaluator concurs.
1.5.1 モバイルIP登録メッセージのエンコーディング - ドキュメント[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]は、半径の展開が火壁の環境で発生したことを知っていることを示しています。ドキュメントは「t」を主張し、評価者は同意します。
1.5.3 Allocation of Local Home Agent - The document [1] claims "F", and the evaluator concurs.
1.5.3 ローカルホームエージェントの割り当て - ドキュメント[1]は「F」を主張し、評価者は同意します。
2. Summary Discussion
2. 要約ディスカッション
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]は、短い時間枠で書かれていることに苦しんでいます。プロトコルは、他の関連するドキュメントを引用して特定の問題に関する特定のガイダンスを提供しますが、詳細なパケット形式の図を備えた洗練されたプロトコル仕様ではありません。半径のプロトコルの多くは、半径WG内で進行中の作業として最初に想定されていたため、半径プロトコルの多くが最初に想定されていました。ただし、これらの作業はすべて、期限切れ以来長い間続いています。
3. General Requirements
3. 一般的な要件
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?".
RADIUSは、AAAの現在の事実上の標準であるため、AAAプロトコルの要件の多くを満たしています。半径には長年の欠陥があり、これは半径およびNasreq WGの手続きで十分に文書化されています。これらの問題を解決するために半径を刷新することは技術的に可能です。ただし、尋ねられる質問の1つは、「完成した半径プロトコルと直径プロトコルの間には、どのような大きな違いがありますか？」です。
4. Summary Recommendation
4. 概要の推奨
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.
一部をお勧めします。この提出から学ぶかもしれないことは、直径がより半径に準拠した半径互換性モードを持つことが可能であることです。
Evaluation of Diameter against the AAA Requirements PRO Evaluation Evaluator - Basavaraj Patil
AAA要件に対する直径の評価プロ評価評価者-BasavarajPatil
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".
ref [1]は「直径フレームワークドキュメント」です。ref [2]は「直径Nasreq拡張機能」です。ref [3]は、私たちによって変更されたAAA評価基準です。ref [4]は「直径アカウンティング拡張機能」です。ref [5]は「直径モバイルIPエクステンション」です。ref [6]は「直径ベースプロトコル」です。ref [7]は「直径強いセキュリティ拡張」です。ref [8]は「AAAネットワークアクセス要件との直径の比較」です。
The document uses T to indicate total compliance, P to indicate partial compliance and F to indicate no compliance.
ドキュメントはTを使用して完全なコンプライアンスを示し、Pは部分的なコンプライアンスを示し、Fはコンプライアンスを示さないことを示します。
Evaluator's note : The Diameter compliance document [8] claims Total
"T" compliance with all the requirements except : - 1.2.5 - 1.5.2
Section 1 - Per item discussion
セクション1-アイテムのディスカッションごと
1.1 General Requirements
1.1 一般的な要件
1.1.1 Scalability
1.1.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.
直径は半径の進化であり、半径が奉仕してきた長年にわたって学んだすべての教訓を考慮しています。輸送プロトコルとしてSCTPを使用すると、複数のプロキシサーバー（[1]のSEC 3.1.1プロキシサポート）の必要性が低下し、アプリケーションレベルACKの必要性が削除されます。転送およびリダイレクトブローカーの使用とサポートは、スケーラビリティを向上させます。評価者は、この要件に関する「t」コンプライアンスに同意します。
1.1.2 Fail-over
1.1.2 フェールオーバー
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を使用すると、直径は、代替サーバーに切り替える切断表示を検出できます（Sec 4.0 [6]）。また、リクエストや応答は同じパスをたどる必要はなく、これにより信頼性が向上します。評価者は、この要件に関する「t」コンプライアンスに同意します。
1.1.3 Mutual Authentication
1.1.3 相互認証
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」コンプライアンスに同意します。
1.1.4 Transmission Level Security
1.1.4 送信レベルのセキュリティ
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評価チームによって廃止されましたが、文書は定義に基づいてそれに準拠しています（ホップバイホップセキュリティを参照）。[6]のセクション7.1は、これが直径でどのように達成されるかの詳細を示しています。評価者は、この要件に関する「t」コンプライアンスに同意します。
1.1.5 Data Object Confidentiality
1.1.5 データオブジェクトの機密性
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.
この要件は直径から来たようです。ref [7]は、データオブジェクトの機密性を実現するために、暗号化メッセージ構文（CMS）の使用を詳細に説明しています。CMS-DATA AVPは[7]で定義されています。評価者は、この要件に関する「t」コンプライアンスに同意します。
1.1.6 Data Object Integrity
1.1.6 データオブジェクトの整合性
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」コンプライアンスに同意します。
1.1.7 Certificate Transport
1.1.7 証明書輸送
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-DATA AVPを使用すると、これらのタイプの属性として定義されたオブジェクトにより、証明書の輸送が可能になります。評価者は、この要件に関する「t」コンプライアンスに同意します。
1.1.8 Reliable AAA Transport
1.1.8 信頼できるAAA輸送
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」コンプライアンスに同意します。
1.1.9 Run over IPv4
1.1.9 IPv4を介して実行します
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」コンプライアンスに同意します。
1.1.10 Run over IPv6
1.1.10 IPv6を介して実行します
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」コンプライアンスに同意します。
1.1.11 Support Proxy and Routing Brokers
1.1.11 プロキシとルーティングブローカーをサポートします
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.
Framework Document [1]のセクション3.1.1/2は、直径がプロキシとルーティングブローカーをどのようにサポートするかについての説明を提供します。実際、ルーティングブローカーの要件は直径から来たように見えます。評価者は、この要件に関する「t」コンプライアンスに同意します。
1.1.12 Auditability
1.1.12 監査可能性
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-DATA AVP [7]を使用すると、プロキシがトランザクションに関与しているときにトレイルが作成されます。このトレイルは監査可能性を提供できます。評価者は、この要件に関する「t」コンプライアンスに同意します。
1.1.13 Shared Secret Not Required
1.1.13 共有秘密は必要ありません
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」コンプライアンスに同意します。
1.1.14 Ability to Carry Service Specific Attributes
1.1.14 サービス固有の属性を携帯する能力
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の他のWGSは、特定の属性を使用してベースプロトコル上の拡張機能を設計し、IANAによって登録することができます。評価者は、この要件に関する「t」コンプライアンスに同意します。
1.2 Authentication Requirements
1.2 認証要件
1.2.1 NAI Support
1.2.1 NAIサポート
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]は、NAISをサポートするために使用できるAVPを定義します。直径は、宛先NAI AVPに基づいてメッセージ転送を行うことにより、さらに一歩進んでいます。評価者は、この要件に関する「t」コンプライアンスに同意します。
1.2.2 CHAP Support
1.2.2 チャップサポート
Reference [2] section 3.0 describes the support for CHAP. Evaluator concurs with the "T" compliance on this requirement.
参照[2]セクション3.0では、Chapのサポートについて説明します。評価者は、この要件に関する「t」コンプライアンスに同意します。
1.2.3 EAP Support
1.2.3 EAPサポート
Reference [2] section 4.0 describes the support for EAP. Evaluator concurs with the "T" compliance on this requirement.
参照[2]セクション4.0では、EAPのサポートについて説明します。評価者は、この要件に関する「t」コンプライアンスに同意します。
1.2.4 PAP/Clear-text Passwords
1.2.4 PAP/クリアテキストパスワード
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」コンプライアンスに同意します。
1.2.5 Reauthentication on demand
1.2.5 オンデマンドの再認証
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.
注：ただし、これは些細な問題です。
1.2.6 Authorization w/o Authentication
1.2.6 認証付き許可
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」コンプライアンスに同意します。
1.3 Authorization Requirements
1.3 承認要件
1.3.1 Static and Dynamic IP Addr Assignment
1.3.1 静的および動的IP ADDR割り当て
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が含まれています。参考文献[6.2.2 of 2]および[4.5 of 5]は、これがどのように行われるかについての詳細な説明を提供します。評価者は、この要件に関する「t」コンプライアンスに同意します。
1.3.2 RADIUS Gateway Capability
1.3.2 RADIUSゲートウェイ機能
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.
直径の基本的なファセットの1つは、後方互換性をサポートし、特定の環境で半径ゲートウェイとして機能することです。評価者は、この要件に関する「t」コンプライアンスに同意します。
1.3.3 Reject Capability
1.3.3 機能を拒否します
Based on the explanation provided in the compliance document for this requirement evaluator concurs with the "T" compliance on this requirement.
この要件のコンプライアンスドキュメントで提供されている説明に基づいて、評価者はこの要件に関する「t」コンプライアンスに同意します。
1.3.4 Preclude Layer 2 Tunneling
1.3.4 レイヤー2トンネリングを排除します
Ref [2] defines AVPs supporting L2 tunnels Evaluator concurs with the "T" compliance on this requirement.
ref [2]は、この要件の「t」コンプライアンスに同意するL2トンネル評価者をサポートするAVPを定義します。
1.3.5 Reauth on Demand
1.3.5 オンデマンドでreauth
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」コンプライアンスに同意します。
1.3.6 Support for ACLs
1.3.6 ACLSのサポート
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つの方法を定義します。半径の後方互換性をサポートするものと、フィルターがエンコードされた標準のAVPを使用して別の互換性をサポートします。評価者は、この要件に関する「t」コンプライアンスに同意します。
1.3.7 State Reconciliation
1.3.7 州の和解
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」コンプライアンスに同意します。
1.3.8 Unsolicited Disconnect
1.3.8 未承諾の切断
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」コンプライアンスに同意します。
1.4 Accounting Requirements
1.4 会計要件
1.4.1 Real Time Accounting
1.4.1 リアルタイム会計
Evaluator concurs with the "T" compliance based on explanations in [4].
評価者は、[4]の説明に基づいて「t」コンプライアンスに同意します。
1.4.2 Mandatory Compact Encoding
1.4.2 必須のコンパクトエンコーディング
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」コンプライアンスに同意します。
1.4.3 Accounting Record Extensibility
1.4.3 会計記録の拡張性
ADIF can be extended. Evaluator concurs with the "T" compliance.
adifを拡張できます。評価者は「T」コンプライアンスに同意します。
1.4.4 Batch Accounting
1.4.4 バッチアカウンティング
Sec 1.2 of [4] provides support for batch accounting.
[4]のSec 1.2は、バッチアカウンティングのサポートを提供します。
1.4.5 Guaranteed Delivery
1.4.5 保証された配達
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」コンプライアンスに同意します。
1.4.6 Accounting Timestamps
1.4.6 会計タイムスタンプ
Timestamp AVP [6] is present in all accounting messages. Evaluator concurs with the "T" compliance.
タイムスタンプAVP [6]は、すべての会計メッセージに存在します。評価者は「T」コンプライアンスに同意します。
1.4.7 Dynamic Accounting
1.4.7 動的会計
Interim accounting records equivalent to a call-in-progress can be sent periodically. Evaluator concurs with the "T" compliance.
進行中のコールに相当する暫定会計記録は、定期的に送信できます。評価者は「T」コンプライアンスに同意します。
1.5 MOBILE IP Requirements
1.5 モバイルIP要件
1.5.1 Encoding of MOBILE IP Registration Messages
1.5.1 モバイルIP登録メッセージのエンコード
Ref [5] provides details of how Diameter can encode MIP messages. Evaluator concurs with the "T" compliance.
ref [5]は、直径がMIPメッセージをエンコードする方法の詳細を提供します。評価者は「T」コンプライアンスに同意します。
1.5.2 Firewall Friendly
1.5.2 ファイアウォールフレンドリー
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"
ここでのいくつかの手順と、直径プロキシサーバーでファイアウォールの問題を解決する可能性のある方法。ドキュメントは「t」を主張し、評価者はそれを「P」に非難します
1.5.3 Allocation of Local Home Agent
1.5.3 地元のホームエージェントの割り当て
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の展開から得られた経験は、このプロトコルの設計に有効に活用されています。また、拡張性を念頭に置いて設計されており、さまざまなWGSが要件を満たすために独自の拡張機能を開発できるようにしています。SCTPを輸送プロトコルとして使用すると、信頼性が組み込まれています。セキュリティはプロトコルの設計で対処されており、半径で発見された問題が修正されています。Diameterは、セッションベースのプロトコルでもあり、よりスケーラブルになります。転送およびリダイレクトブローカーのサポートは明確に定義されており、これによりプロトコルのスケーラビリティの側面が大幅に向上します。
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プロトコルになるための肯定的なポイントです。
Evaluation of Diameter against the AAA Requirements CON Brief Evaluator: Barney Wolff Section 1 - Per item discussion
AAA要件に対する直径の評価CON BRIECT評価者：Barney Wolffセクション1-アイテムのディスカッションごと
1.1 General Requirements
1.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ドキュメントの何もありません。評価者は、通信が失われたプライマリサーバーにどのように、いつ切り替えるかについても言及することができました。障害後、状態マシンは閉じた状態で終わり、その状態からの出口を引き起こすものは何もないようです。サーバーが再起動すると、構成されたすべてのクライアントへの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.3 Mutual Authentication - T
1.1.3 相互認証-T
1.1.4 Transmission Level Security - T
1.1.4 トランスミッションレベルのセキュリティ-T
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に示すように、ドメイン間サーバーを扱う場合にのみ直径サーバーを使用することをお勧めします。この構成は、特定の管理ドメイン内の直径エンティティが本質的に互いに信頼できるため、通常望ましいものです。さらに、NASEには高価な暗号操作を実行する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-to-home_Server」を意味することを意味する）について行われたすべての騒ぎを考えると、評価者は、提案された解決策がNASに不適切であると認められていることはばかげていると感じています。
1.1.6 Data Object Integrity - P (was T). See above.
1.1.6 データオブジェクトの整合性-P（t）。上記を参照。
1.1.7 Certificate Transport - T
1.1.7 証明書輸送-T
1.1.8 Reliable AAA Transport - T
1.1.8 信頼できるAAA輸送-T
1.1.9 Run over IPv4 - T
1.1.9 IPv4 -tを介して実行します
1.1.10 Run over IPv6 - T
1.1.10 IPv6 -tを介して実行します
1.1.11 Support Proxy and Routing Brokers - T
1.1.11 プロキシとルーティングブローカーをサポート-T
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.1.13 Shared Secret Not Required - T
1.1.13 共有秘密は不要-t
1.1.14 Ability to Carry Service Specific Attributes - T
1.1.14 サービス固有の属性を携帯する能力-T
1.2 Authentication Requirements
1.2 認証要件
1.2.1 NAI Support - T
1.2.1 NAIサポート-T
1.2.2 CHAP Support - T
1.2.2 チャップサポート-T
1.2.3 EAP Support - T
1.2.3 EAPサポート-T
1.2.4 PAP/Clear-text Passwords - T
1.2.4 PAP/クリアテキストパスワード-T
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.2.6 Authorization w/o Authentication - T
1.2.6 認証付き認証-T
1.3 Authorization Requirements
1.3 承認要件
1.3.1 Static and Dynamic IP Addr Assignment - T
1.3.1 静的および動的IP ADDR割り当て-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）。半径は、直径の基礎となるバージョンから進化しました。EAPは、直径の属性が半径1を複製する条約に違反されるという注目すべきケースです。半径さえも、これについて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.4 Preclude Layer 2 Tunneling - T
1.3.3 拒否機能-T（評価者は、AAAプロトコルがこれに関するT以外のものをどのように評価できるかを理解できません。）1.3.4レイヤー2トンネリング-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.
1.3.6 ACLSのサポート-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.3.8 Unsolicited Disconnect - T
1.3.8 未承諾の切断-t
1.4 Accounting Requirements
1.4 会計要件
1.4.1 Real Time Accounting - T
1.4.1 リアルタイム会計-T
1.4.2 Mandatory Compact Encoding - T
1.4.2 必須のコンパクトエンコード-T
1.4.3 Accounting Record Extensibility - T
1.4.3 会計記録の拡張性-T
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.5 Guaranteed Delivery - T
1.4.5 保証された配達-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（評価者は、直径のドラフトで主張されているように、2038年ではなく2036年にNTPタイムサイクルを模していることを説明しています。
1.4.7 Dynamic Accounting - T
1.4.7 動的会計-T
1.5 MOBILE IP Requirements
1.5 モバイルIP要件
1.5.1 Encoding of MOBILE IP Registration Messages - T
1.5.1 モバイルIP登録メッセージのエンコード-T
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を知るまで、SCTPが合格する可能性は非常に低いです。それでも、任意のポートからリクエストを送信し、そのポートに返信を戻すことができるという便利な機能は、単純なポートフィルターでは十分ではなく、状態が必要であることを意味します。本当の友情では、ソースポートとデステットポートの両方が1812であることが必要です。
1.5.3 Allocation of Local Home Agent - T
1.5.3 地元のホームエージェントの割り当て-T
2. Summary Discussion
2. 要約ディスカッション
In some areas, Diameter is not completely thought through. In general, real effort has gone into satisfying a stupendous range of requirements.
一部の領域では、直径が完全に考えられていません。一般的に、途方もない範囲の要件を満たすことに真の努力が寄せられてきました。
3. General Requirements
3. 一般的な要件
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.
直径は確かにキステストに失敗します。SCTPを使用すると、ドラフトは最大382ページになります。拡張機能があっても、半径のサイズの2倍以上です。評価者は、「私たちはそれができる」と言うために、どんなに奇妙であっても新しい要件に直面したとき、政治的本能に同情し、別のフィリグリーを追加します。しかし、直径が半径にわたって利点を主張する主要な場所、すなわち「エンドツーエンド」の機密性とリソース管理は、問題が実際に手に負えない場合、何らかの努力が残る場所にすぎません。
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の利益は明らかではありませんでした。また、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が優れているかどうかは宗教的な問題ですが、「強い」拡張が実装されている場合、直径は両方を要求することができます。評価者には、ヘッダーを含む長さのフィールドを備えたペットのピーブがあり、小さな長さの値が無効になりますが、それは小さなポイントです。
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.
最後に、相互運用性は、おそらく別のベンダーからの属性のセットを実装することができる標準の「辞書」形式を定義することにより、大いに役立ち、少なくともそれらを表示する方法を知っています。それはMIBSの利点の1つです。
4. Summary Recommendation
4. 概要の推奨
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.
直径は明らかに、それが許容可能な候補者であるという無数の要件を満たすのに十分近いですが、いくらかの磨きが必要です。複雑さの大幅な増加が半径上での機能の増加に値するかどうかは議論の余地があります。
Evaluation of COPS AAA Requirements PRO Evaluation Evaluator - David Nelson
警官の評価AAA要件プロ評価評価者 - デビッドネルソン
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.
ref [1]は「AAA NA要件に対するCOPの比較」であり、進行中の作業、「ドキュメント」ref [2]はRFC 2748 A.K.A.です。。ref [4]は「AAAプロトコル：半径、直径、およびCOPの比較」が進行中です。ref [5]は「AAAのCOPS使用」であり、進行中の作業です。
This document uses T to indicate total compliance, P to indicate partial compliance and F to indicate no compliance.
このドキュメントでは、Tを使用して完全なコンプライアンスを示し、Pは部分的なコンプライアンスを示し、Fはコンプライアンスを示さないことを示します。
Section 1 - Per item discussion
セクション1-アイテムのディスカッションごと
1.1 General Requirements
1.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]で説明されているメカニズムを使用してプロトコルで提供されていることを示します。この要件は現在[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 データオブジェクトの機密性-Document [1]は、RFC 2630に基づいて主にCMS-DATA属性を使用してエンドツーエンドの機密性が提供されることを示しています。現時点では、評価者はRFC 2630の適用性を調査していません。AAA作業。ドキュメントは「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に基づいて、データオブジェクトの整合性がCMS -DATA属性を使用して提供されることを示しています。現時点では、評価者はRFC 2630の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 -DATA属性を使用して証明書輸送が提供されることを示しています。この時点で、AAAへのRFC 2630の適用性は調査されていません。仕事。ドキュメントは「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.
1.1.9 IPv4を介して実行 - ドキュメント[1]は「t」を主張し、評価者は同意します。
1.1.10 Run over IPv6 - The document [1] claims "T", and the evaluator concurs.
1.1.10 IPv6を介して実行 - ドキュメント[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 Authentication Requirements
1.2 認証要件
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/Clear-Textパスワード - ドキュメント[1]は、おそらくRFC 2630に基づいてCMS-DATA属性を使用するコンプライアンスを示しています。現時点では、評価者はRFC 2630の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.
1.2.6 認証付き認証 - プロトコル仕様に適用されるこの要件は、許可のリクエストに必要でない認証資格が必要ないことを義務付けています。認証がない場合に承認を提供するという実際の決定は、アプリケーション（AAAサーバーなど）にあります。ドキュメント[1]は「t」を主張し、評価者は同意します。
1.3 Authorization Requirements
1.3 承認要件
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 Gateway機能 - ドキュメント[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 reauth on demand-ドキュメント[1]は「t」を主張し、評価者は同意します。
1.3.6 Support for ACLs - The document [1] "T", and the evaluator concurs.
1.3.6 ACLSのサポート - ドキュメント[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 Accounting Requirements
1.4 会計要件
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 MOBILE IP Requirements
1.5 モバイルIP要件
1.5.1 Encoding of MOBILE IP Registration Messages - The document [1] claims "T", and the evaluator concurs.
1.5.1 モバイルIP登録メッセージのエンコーディング - ドキュメント[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」を主張し、評価者は同意します。
2. Summary Discussion
2. 要約ディスカッション
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 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.
最初の検査で、評価者は文書のコンプライアンスアサーションに批判的な目を貸していないように見えるかもしれません[1]。第一に、このメモは「プロ」のブリーフであり、そのような合理的な疑いの利益は、プロトコルの提出に有利に与えられるべきです。第二に、プレイ中に基本的な概念的な問題があります。COPS-PRモデルは、十分な基本操作とコマンド、ステートフルモデル、「ピア」が特定の種類のリクエストを開始する能力、および拡張可能なコマンドセットを提供し、さまざまなものをサポートできるようにします。ネットワークおよびリソース管理プロトコル。プロトコル固有のメッセージの詳細は、ポリシー情報ベース（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について悪いことを言うのはいつも難しいです。
3. General Requirements
3. 一般的な要件
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]のすべての要件を（完全または部分的に）満たすように見えます。
4. Summary Recommendation
4. 概要の推奨
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を書き、その詳細を評価する必要があります。
Evaluation of COPS against the AAA Requirements CON Evaluation Evaluator - David Mitton
AAA要件に対するCOPSの評価Con評価評価者-DavidMitton
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要件に対するCOPの比較」、進行中の作業。[Copsaaa]「AAAのCOPSの使用」、進行中の作業。[EksteinProtocomp]「AAAプロトコル：半径、直径、およびCOPの比較」、進行中の作業。
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] Durham、D.、Boyle、J.、Cohen、R.、Herzog、S.、Rajan、R。and A. Sastry、「The Common Open Policy Service Protocol」、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。and R. Guerin、「政策ベースの入場管理の枠組み」、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 Over CMS」は進行中の作業。
[COPSTLS] "COPS Over TLS", Work in Progress.
[COPSTLS]「TLSを超える警官」、進行中の作業。
[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 RFCSおよびドラフトは、直接関連していないとリストされていません。
Compliance: T==Total, P==Partial, F=Failed
Section 1 - Per item discussion
セクション1-アイテムのディスカッションごと
Initial Note: [COPSComp] claims "unconditional compliance" with all requirements.
最初のメモ：[CopsComp]は、すべての要件で「無条件のコンプライアンス」を主張しています。
1.1 General Requirements
1.1 一般的な要件
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はピアの故障を示し、状態を再開するメカニズムを備えていますが、単一の状態サーバーにバイアスがあるようです。警官は、複数のホットサーバー間の状態を同期することは範囲外であると判断しました。
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.4 Transmission Level Security - T
1.1.4 トランスミッションレベルのセキュリティ-T
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は、直径機能のほぼカーボンコピーのようです。この評価者は、CMS機能の直径評価者の高いオーバーヘッドの懸念をエコーします。TLSはここでは言及されていませんが、後で積み上げられます。
1.1.6 Data Object Integrity - T See above.
1.1.6 データオブジェクトの整合性-T上記を参照してください。
1.1.7 Certificate Transport - T
1.1.7 証明書輸送-T
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）COPは、この要件と、当社が評価した他のプロトコルを満たしています。つまり、アプリケーションレベルのACKが1つあります。「TCPが保証された配信を提供する」などのステートメントは正しくありません。警官は、TCPピア間のキープアライブメッセージを使用して、停止を特定しようとします。
1.1.9 Run over IPv4 - T
1.1.9 IPv4 -tを介して実行します
1.1.10 Run over IPv6 - T
1.1.10 IPv6 -tを介して実行します
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）（t）（reqtsで与えられた定義ではなく、非repudiationとしての解釈に基づいて）履歴PIBの説明は不完全であり、したがって決定的ではありません。
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 共有秘密は不要-T [COPSAAA] 6.2のこの条項を除きます。
1.1.14 Ability to Carry Service Specific Attributes - P (was T)
1.1.14 サービス固有の属性を携帯する能力-P（t）
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ビットの長さで、高いビットは「エンタープライズ」特定の値を示します。しかし、警官のピア接続セッションに関係します。クライアントタイプは、メッセージの情報モデルを識別するだけのようです。例えば。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 Authentication Requirements
1.2 認証要件
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.
1.2.1 NAIサポート-T RFC 2459（X.509プロファイル）が満たされるという要件は、AUTHサーバーにマッピングまたはローカル変換がないと仮定します。
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 Support -T情報モデルが呼び出されていますが、どこにも肉付けされていません。[Copsaaa]は少し手順と定義を行いますが、多くの肉を届けません。それにもかかわらず、これは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を行うには、この評価者は、拡張メッセージ交換が進行中であることをプロキシに示すために、ここで別の要求または決定タイプが必要であると考えています。
1.2.4 PAP/Clear-text Passwords - T
1.2.4 PAP/クリアテキストパスワード-T
1.2.5 Reauthentication on demand - T
1.2.5 オンデマンドで再認可-T
1.2.6 Authorization w/o Authentication - T
1.2.6 認証付き認証-T
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 Authorization Requirements
1.3 承認要件
1.3.1 Static and Dynamic IP Addr Assignment - T 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.1 静的および動的IP ADDR割り当て-T 1.3.2半径ゲートウェイ機能-P（T）。一部の警官「情報モデル」に包まれているRadius属性を見るのは興味深いでしょう。
1.3.3 Reject Capability - T
1.3.3 拒否機能-T
1.3.4 Preclude Layer 2 Tunneling - T
1.3.4 レイヤー2トンネリングを排除-t
More work for the "Information Model" author!
「情報モデル」の著者のためのより多くの作業！
1.3.5 Reauthorization on Demand - T
1.3.5 オンデマンドの再承認-T
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）は、半径と直径のデザイナーを暗示するいくつかの設計上の問題を含む、「情報モデル」著者のためにより多くの作業を行います。少なくとも直径の試みがなされました。ここには何もありません。
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）。評価者が、警官のメカニズムがマルチ副産物の状況、またはどのような委任状の状況でどの程度うまく機能するかを理解することは困難です。マルチサーバーの調整は、許可されていれば、説明がないようです。
1.3.8 Unsolicited Disconnect - T
1.3.8 未承諾の切断-t
1.4 Accounting Requirements
1.4 会計要件
1.4.1 Real Time Accounting - T
1.4.1 リアルタイム会計-T
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（T）追加要素のベンダー/デバイス固有のPIBを定義することにより。
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 MOBILE IP Requirements
1.5 モバイルIP要件
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.
1.5.1 モバイルIP登録メッセージのエンコーディング-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を使用し、既知の接続ポートで識別できるためです。しかし、共通のファイアウォールポートを介して来る混合警官のトラフィックの影響レベルに関して問題があります。
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）は、その「情報モデル」定義に別の要素を追加するだけです。
2. Summary Discussion
2. 要約ディスカッション
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は、私たちが望むものに似たことを行い、いくぶん柔軟性があるように設計されましたが、インフラストラクチャと許容可能なオーバーヘッドを通じて何人のクライアントとリクエストが注目されるかについて、まったく異なる仮定セットがあります。この評価者は、すべての製品が共通の機能の小さなセットではなく、重複する大きなセットを実装していない高速進化するアクセス市場を十分に拡大するかどうかはわかりません。
3. General Requirements
3. 一般的な要件
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.
警官は、RSVPとDiffserveの小さくて簡単に満たされたデザイン目標から始まり、他の爪を打つための新しいハンマーとして進化しています[Copspr]。警官の実装者がより多くの運用体験を得るにつれて、より多くの信頼性の修正/機能がすばやくパッチを当てるのを見るのは興味深いです。
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.
警官を理解するには、容易に統合されない番号RFCとドラフトを読む必要があります。警官の各適用により、多くのドラフトが生まれました。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.
警官の著者は、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.
警官はエンコーディングの間に入ります。柔軟なメッセージレイアウトを形成するために、ALA半径/直径TLVを連結した少数の単純なデータオブジェクトブロブがあります。ただし、オブジェクトの数を任意に複雑にし、これらのPIBのさらに別のデータ構造化言語を定義することにより、オブジェクトの数を制限しようとします。[Copsaaa]セクション1.2には多くのコンピューターサイエンススタイルが壮大ですが、データオブジェクトのセットを使用してこれらの素晴らしい機能を操作する方法への翻訳はありません。（または、たとえそれらが必要であっても）これは、相互運用性の問題の核心になります。RADIUS実装は、少なくともRFCからの共通の機能属性セットを理解しているため、相互運用します。また、ベンダーの範囲イオンは、辞書を介して必要に応じて単純にカスタマイズできます。アクセス機器のすべてのピースとバージョンに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統合と同じ順序であり、想定される直径の複雑さを恥ずかしく思います。
4. Summary Recommendation
4. 概要の推奨
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には、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サービスとの相乗効果の一部は魅力的ですが、この評価者は、AAAサービスを単一のサーバーエンティティで新しい新興COPSアプリケーションと組み合わせることの責任を懸念しています。穴。（たとえば、ポリシーフレームワーク）
Appendix D - Meeting Notes
付録D-会議メモ
The minutes of the team meetings as recorded by various members.
さまざまなメンバーが記録したチームミーティングの議事録。
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に対する賛否両論が与えられました。スチュアート・バークリーは、プロの議論の要約を述べました。マイク・セント・ジョンズは、詐欺の議論の要約を示しました。デイブ・ネルソンは、決定を下す際にどのような証拠を使用できるか、使用できないかを決定するために、「ju審員への指示」を求めました。
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またはクリアテキストのパスワードのサポートは弱いものの、すべての手法をサポートできます。
*承認に関して、要件にはサポートできないものは何もありません。
*サポートされているすべてのことを説明しますが、コンパクトエンコーディングには具体的な考慮事項はありません。SNMPは、ASCIIまたはXMLベースのエンコーディングスキームほど肥大化していません。とにかく、要件に弱く示されているコンパクトエンコードの要件。必要なサーバー固有の属性が必要ですが、コンパクトなエンコードはトレードオフで排除されます。
* 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のプロキシメカニズムは、ファイアウォールを備えた問題を軽減します。*スケーラビリティは問題ありません。*全体として、ほとんどの要件を満たし、不足は軽微です。*場合によっては、要件は、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に対する各要件を調べました。
Attendees - All (Mike St. John, Dave Mitton, Dave Nelson, Mark Stevens, Barney Wolff, Stuart Barkley, Steven Crain, Basavaraj Patil)
参加者 - すべて（マイク・セント・ジョン、デイブ・ミットン、デイブ・ネルソン、マーク・スティーブンス、バーニー・ウルフ、スチュアート・バークリー、スティーブン・クレイン、バサヴァラジ・パティル）
Minutes recorded by : Basavaraj Patil
記録された議事録：Basavaraj Patil
Evaluation of RADIUS++ AAA Requirements
半径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.
- Dave Nelsonは、Pat CalhounがAAA WGメーリングリストで、評価チームによって要件文書に加えられた変更に応答したと述べました。PATの回答には、評価チームによって削除された要件の一部を含めるための議論が含まれています。
- 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.
- マイクは、PATのコメントを詳細にレビューした後、これらの要件を回復できると結論付け、RFCSを参照しました。目的は、PATのコメント/文書を撮影し、今後（7月6日）の間にレビューし、その時点での調査結果に基づいてコメントを統合することです。
Voting Procedure for evaluation : No voting during the discussion. All votes MUST be submitted to Mike by COB, June 28th, 00.
評価のための投票手順：議論中の投票なし。すべての票は、6月28日、コブによってマイクに提出する必要があります。
- Dave Nelson's summary of the Con statement for RADIUS++. Overview of the points on which the evaluator disagrees with the compliance statement.
- Dave NelsonのRadiusのCon Statementの要約。評価者がコンプライアンスステートメントに同意しない点の概要。
Conclusion from Dave : Not recommended (Details in the con statement).
デイブからの結論：推奨されていません（CONステートメントの詳細）。
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：会計に使用することは可能ですか？A：認証と承認を分離することができますが、会計はこのプロトコルの弱いリンクであるため、適切ではありません。
- 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）：
1.1.1 Scalability
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-シンガーリクエストは、未解決のリクエストと同じではありません。
Discussion of workarounds that have been implemented to overcome this problem.
この問題を克服するために実装された回避策の議論。
1.1.2 Fail-over
1.1.2 フェールオーバー
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.
プライマリ、セカンダリ、および三分神経のプロキシが存在する環境と、フェールオーバー検出が発生した場合のフラッディングメッセージの可能な効果の議論。
1.1.3 Mutual Authentication
1.1.3 相互認証
No Discussion. Accepted as stated.
議論はありません。記載されているとおりに受け入れられます。
1.1.4 Transmission level security
1.1.4 送信レベルのセキュリティ
This requirement was deleted from the list by the evaluation team. It was deleted because it is an overgeneralization of Roam Ops.
この要件は、評価チームによってリストから削除されました。Roam Opsの過剰な一般化であるため、削除されました。
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グループは、送信レベルのセキュリティを使用して、ホップバイホップセキュリティを暗示していますか？
1.1.5 Data Object Confidentiality
1.1.5 データオブジェクトの機密性
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.
マイクは、暗号化メッセージ構文の概念（CMS -RFC2630）を説明しました。エンドポイントでのCMSの使用に関するいくつかの問題があります。対称キーまたは非対称キーを使用できます。
There does not seem to be a problem with the suggested usage of CMS in RADIUS++.
半径中のCMSの推奨使用に問題はないようです。
1.1.6/7 Data Object Integrity/Certificate Transport
1.1.6/7データオブジェクトの整合性/証明書輸送
No discussion. (I guess everyone concurs with the statement in the compliance document and the reviewers comments).
議論はありません。（誰もがコンプライアンス文書の声明とレビュアーのコメントに同意していると思います）。
1.1.8 Reliable AAA Transport
1.1.8 信頼できるAAA輸送
BW - Radius provides reliability at the application layer by doing retransmissions. So why is there a need for a reliable AAA transport protocol?
BW -RADIUSは、再送信を行うことにより、アプリケーション層で信頼性を提供します。では、なぜ信頼できる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.
結論は、この要件がパケットの損失を扱っているということです。
1.1.9/10 Run over IPv4/6
1.1.9/10 IPv4/6で実行します
Running over IPv6 should be a trivial issue.
IPv6を介して実行することは些細な問題です。
1.1.11 Support Proxy and Routing Brokers
1.1.11 プロキシとルーティングブローカーをサポートします
- 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.
- 半径を拡張してこの要件をサポートすることができ、コンプライアンスドキュメントからこれはまだ完全に調理されていないようです。
1.1.12 Auditability
1.1.12 監査可能性
No Discussion 1.1.13 Shared Secret Not Required
議論なし1.1.13共有秘密は必要ありません
This seems to be a trivial issue to be addressed in RADIUS++.
これは、半径で対処すべき些細な問題のようです。
1.1.14 Ability to carry Service Specific Attributes
1.1.14 サービス固有の属性を携帯する能力
No Discussion
議論はありません
Authentication Requirements:
認証要件：
1.2.1 NAI Support
1.2.1 NAIサポート
Trivial - Total compliance.
些細な - 総コンプライアンス。
1.2.2 CHAP Support
1.2.2 チャップサポート
Comment : RADIUS support of CHAP could be better and the response needs to be encrypted.
コメント：CHAPのRADIUSサポートの方が優れている可能性があり、応答を暗号化する必要があります。
1.2.3/4 EAP/PAP
1.2.3/4 EAP/PAP
No Discussion
議論はありません
1.2.5 Reauthentication on Demand
1.2.5 オンデマンドの再認証
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 -Documentは、アクセスチャレンジを発行することにより、サーバーが再確認できると主張しています。状態マシンに変更があり、推奨されるソリューションは単純すぎます。また、後方の互換性が問題になります。
1.2.6 Authorization w/o Authentication
1.2.6 認証付き許可
DN - This is trivial to fix, but this is not mentioned in the compliance document.
DN-これは修正するのが簡単ですが、これはコンプライアンスドキュメントでは言及されていません。
Authorization Requirements:
承認要件：
1.3.1 Static and Dynamic IP Addr assignment
1.3.1 静的および動的IP ADDR割り当て
- 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は住所を割り当て、セッションに割り当てられたままです。リースの概念はありません。
1.3.2 RADIUS Gateway Capability
1.3.2 RADIUSゲートウェイ機能
This is a requirement written that is not applicable to RADIUS itself.
これは、半径自体に適用できない要件です。
1.3.3/4/5/6/7/8
1.3.3/4/5/6/7/8
Call dropped. Somebody else needs to fill in here. (Mike ????)
電話が切れた。他の誰かがここに記入する必要があります。（マイク????）
Accounting Requirements:
会計要件：
1.4.1 Real time accounting
1.4.1 リアルタイム会計
No dissent. No discussion
異議はありません。議論はありません
1.4.2 Mandatory compact encoding
1.4.2 必須のコンパクトエンコーディング
Comment made regarding ASN.1 and XML in this context
このコンテキストでASN.1とXMLに関してコメントが作成されました
1.4.3 Accounting Record Extensibility
1.4.3 会計記録の拡張性
No discussion
議論はありません
1.4.4 Batch Accounting
1.4.4 バッチアカウンティング
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.
それは些細な問題かもしれません。
1.4.5/6 Guaranteed Delivery/Accounting Timestamps
1.4.5/6保証付き配達/会計タイムスタンプ
No Discussion
議論はありません
1.4.7 Dynamic Accounting
1.4.7 動的会計
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で継続的な議論があります。半径WGもこれについて議論しています（コメント）。ここでのアイデアは、進行中のメッセージのタイプのメッセージに相当するメッセージを送信できることです。
Mobile IP Requirements:
モバイルIP要件：
1.5.1 Encoding of Mobile IP Reg. Messages
1.5.1 モバイルIP regのエンコード。メッセージ
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を掘り下げる必要がありますか。メッセージと動作は異なります。
1.5.2 Firewall Friendly
1.5.2 ファイアウォールフレンドリー
No Discussion
議論はありません
1.5.3 Allocation of Local Home Agents
1.5.3 地元のホームエージェントの割り当て
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.
ここで私が録音したものが誤って解釈されたものとして何かに気付いた場合は、修正をお気軽にお問い合わせください。
Attendees: Mike St. John, Dave Mitton, Dave Nelson, Barney Wolff, Stuart Barkley, Steven Crain, Basavaraj Patil. Missing: Mark Stevens.
参加者：マイク・セント・ジョン、デイブ・ミットン、デイブ・ネルソン、バーニー・ウォルフ、スチュアート・バークリー、スティーブン・クレイン、バサヴァラジ・パティル。行方不明：マークスティーブンス。
Minutes recorded by: Stuart Barkley
記録された議事録：スチュアート・バークリー
Evaluation of Diameter AAA Requirements
直径AAA要件の評価
Advocates:
支持者：
Pro: Basavaraj Patil Con: Barney Wolff
プロ：Basavaraj Patil Con：Barney Wolff
Summary discussion:
要約ディスカッション：
PRO summary (Basavaraj Patil):
プロサマリー（Basavaraj Patil）：
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 Summary（Barney Wolff）：
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
サイズと複雑さは、SCTPとデータの分離（IESGの提案に従って）の分離を実際にサポートするために、ほぼすべての拡張機能を必要とします。アプリケーションと輸送ACK
Point-by-point Discussion:
ポイントバイポイントの議論：
General (1.1):
一般（1.1）：
1.1.1 Scalability
1.1.1 スケーラビリティ
Handles large number of requests
多数のリクエストを処理します
SCTP reduces proxy needs (how? what is justification for this statement?)
SCTPはプロキシのニーズを減らします（どのように？この声明の正当化とは何ですか？）
Scalability in large
大規模なスケーラビリティ
1.1.2 Fail-over
1.1.2 フェールオーバー
Recovery from SCTP failure needs discussion (Note to DM: Include in final document considerations)
SCTP障害からの回復には議論が必要です（DMへの注意：最終的なドキュメントの考慮事項に含める）
1.1.3 Mutual Authentication
1.1.3 相互認証
No Discussion
議論はありません
1.1.4 Transmission level security
1.1.4 送信レベルのセキュリティ
No Discussion
議論はありません
1.1.5/6 Data Object Confidentiality/Data Object Integrity
1.1.5/6データオブジェクト機密性/データオブジェクトの整合性
Crypto in NAS NAS needs knowledge of when to use crypto One Time Passwords
NAS NASのCryptoは、Cryptoのワンタイムパスワードを使用するタイミングの知識が必要です
1.1.7 Certificate Transport
1.1.7 証明書輸送
No Discussion
議論はありません
1.1.8 Reliable AAA Transport
1.1.8 信頼できるAAA輸送
No Discussion
議論はありません
1.1.9/10 Run over IPv4/6
1.1.9/10 IPv4/6で実行します
No Discussion
議論はありません
1.1.11 Support Proxy and Routing Brokers
1.1.11 プロキシとルーティングブローカーをサポートします
No Discussion
議論はありません
1.1.12 Auditability
1.1.12 監査可能性
No Discussion
議論はありません
1.1.13 Shared Secret Not Required
1.1.13 共有秘密は必要ありません
No Discussion
議論はありません
1.1.14 Ability to carry Service Specific Attributes
1.1.14 サービス固有の属性を携帯する能力
No Discussion
議論はありません
Authentication Requirements:
認証要件：
1.2.1 NAI Support
1.2.1 NAIサポート
No Discussion
議論はありません
1.2.2 CHAP Support
1.2.2 チャップサポート
No Discussion
議論はありません
1.2.3/4 EAP/PAP
1.2.3/4 EAP/PAP
No Discussion
議論はありません
1.2.5 Reauthentication on Demand
1.2.5 オンデマンドの再認証
No Discussion
議論はありません
1.2.6 Authorization w/o Authentication
1.2.6 認証付き許可
No Discussion
議論はありません
Authorization Requirements:
承認要件：
1.3.1 Static and Dynamic IP Addr assignment
1.3.1 静的および動的IP ADDR割り当て
No Discussion
議論はありません
1.3.2 RADIUS Gateway Capability
1.3.2 RADIUSゲートウェイ機能
Protocol requirement or implementation/application requirement? Which RADIUS versions are to be supported? Which subset?
プロトコルの要件または実装/アプリケーションの要件？どの半径バージョンがサポートされますか？どのサブセット？
1.3.3 Reject Capability
1.3.3 機能を拒否します
No Discussion
議論はありません
1.3.4 Preclude L2TP
1.3.4 L2TPを排除します
No Discussion
議論はありません
1.3.5 Reauthorize on demand
1.3.5 オンデマンドを再承認します
Raj to look at this again
これをもう一度見るラジ
1.3.6 Support for ACLs
1.3.6 ACLSのサポート
Standardizes syntax not semantics. Standardizes semantics in NASREQ extension, but is very weak
セマンティクスではなく構文を標準化します。Nasreq拡張のセマンティクスを標準化しますが、非常に弱いです
1.3.7 State reconciliation
1.3.7 州の和解
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
サーバーが「世界を照会」するために「世界を照会」する必要があるように見えるように思われます。
1.3.8 Unsolicited disconnect
1.3.8 未承諾の切断
No Discussion
議論はありません
Accounting Requirements:
会計要件：
1.4.1 Real time accounting
1.4.1 リアルタイム会計
No Discussion
議論はありません
1.4.2 Mandatory compact encoding
1.4.2 必須のコンパクトエンコーディング
Is ADIF compact? Is ADIF UTF-8 compatible?
Adifはコンパクトですか？Adif UTF-8は互換性がありますか？
1.4.3 Accounting Record Extensibility
1.4.3 会計記録の拡張性
No Discussion
議論はありません
1.4.4 Batch Accounting
1.4.4 バッチアカウンティング
Diameter okay for small batches. Specification doesn't seem suitable for large batch transfers (100,000+ records)
小さなバッチでは直径は大丈夫です。仕様は、大きなバッチ転送には適していないと思われます（100,000レコード）
1.4.5 Guaranteed Delivery
1.4.5 保証された配達
No Discussion
議論はありません
1.4.6 Accounting Timestamps
1.4.6 会計タイムスタンプ
No Discussion
議論はありません
1.4.7 Dynamic Accounting
1.4.7 動的会計
No Discussion
議論はありません
Mobile IP Requirements:
モバイルIP要件：
1.5.1 Encoding of Mobile IP Reg. Messages
1.5.1 モバイルIP regのエンコード。メッセージ
Taken of faith
信仰を奪った
1.5.2 Firewall Friendly
1.5.2 ファイアウォールフレンドリー
Issues with SCTP being supported initially through firewalls
最初にファイアウォールを通じてサポートされているSCTPの問題
1.5.3 Allocation of Local Home Agents
1.5.3 地元のホームエージェントの割り当て
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.
広告に従って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.
これらは私のメモに基づいています。修正をリストに送信してください。
Minutes of AAA-Team Telecon 7/6/00 By: Barney Wolff
AAA-Team Telecon 7/6/00の議事録：Barney Wolff
Pro review of COPS - Dave Nelson
警官のプロレビュー - デイブネルソン
Likes the object model. No apparent showstoppers. Will resend review with typos corrected.
オブジェクトモデルが好きです。明らかなショーストッパーはありません。タイプミスが修正された状態でレビューを再送信します。
Con review of COPS - Dave Mitton
警官のレビュー - デイブ・ミットン
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.
Mike STJによるコメント「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.8 Reliable AAA Transport - TCP + appl heartbeat.
1.1.8 信頼性の高いAAAトランスポート-TCP Appl Heartbeat。
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.
1.1.13 共有Secret Not Req'd- 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.3 EAP Support - multi-pass handshake needs work.
1.2.3 EAPサポート - マルチパスハンドシェイクには作業が必要です。
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コメント（ポストミーティング） - 要件は、たとえば、DNIを受け取った場合に、事前接続が送信されたとしても、アクセス要求でユーザー名と何らかのパスワードを要求するために半径を懲らしめることを目的としているように見えます。確かにそれはばかげていますが、属性が存在しないのか、「なし」で満たされているのかは本当に重要ですか？これは、誰かの側の半径での厄介な狙撃でした。
1.3.2 RADIUS Gateway - skepticism was expressed.
1.3.2 Radius Gateway-懐疑論が表現されました。
1.3.4 Preclude L2 Tunnels - too much handwaving.
1.3.4 L2トンネルを排除 - 手順が多すぎます。
1.3.6 Access Rules - lots of work needed.
1.3.6 アクセスルール - 多くの作業が必要です。
1.3.7 State Reconciliation - multi-server coordination is an issue.
1.3.7 州の和解 - マルチサーバーの調整が問題です。
1.4.4 Batch Accounting - for small batches, perhaps.
1.4.4 バッチアカウンティング - おそらく小さなバッチ用。
1.4.5 Guaranteed Delivery - application acks are an area of mystery.
1.4.5 保証された配信 - アプリケーションACKは謎の領域です。
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）のような警官は、AAAを通過させることが許可される可能性がありますが、他のプロトコルの使用は許可されないため、ファイアウォールをパケットの内側に見る必要があります。したがって、COPとSNMPの両方にとって、AAAアプリケーションの別のポートを定義することは大きな助けになるでしょう。
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).
1.1.1 なぜSNMPと半径が「P」なのかという質問ですか？プロキシのウェブ（多層プロキシ、各レベルでのプライマリ、二次三次サーバー）のレトリのスケーリングに関する問題があります。
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.4 Called hop-by-hop or transmission level?
1.1.4 ホップバイホップまたは送信レベルと呼ばれますか？
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を使用しました。naseやその他のエッジデバイスに対するCMSの適用性に関する質問？オブジェクトの機密性によるオブジェクトには要件があります。3パーティのシナリオを検討してください。
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.
1.1.6 SNMPがアイテム1.1.5と同じと同じと評価しなかった理由についての質問？評価は、プロトコル自体の機能ではなく、提出書類に含まれていたものに基づいています。手を振ることが多すぎます。
1.1.7 No comments.
1.1.7 コメントはありません。
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.9 No comments.
1.1.9 コメントはありません。
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.
1.1.11 SNMPは「F」を受け取りました。これは、提出文書のこのセクションが「T.B.D.」を示しているためです。直径は、このアイテムに完全に対処する唯一のプロトコルの提出でした。
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 この要件を「非控除」として扱いました。デジタル署名は計算的に高価であり、グローバルに利用できないという懸念があります。警官は、このアイテムについてもっとやるべきことがあります。
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.1.14 No comments.
1.1.14 コメントはありません。
1.2.1 No comments.
1.2.1 コメントはありません。
1.2.2 No comments.
1.2.2 コメントはありません。
1.2.3 No comments.
1.2.3 コメントはありません。
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など、サービスのための明確なテキスト「パスワード」が必要ですか。al。？すべてのプレーンパスワードは、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.2.6 We asserted that this requirement is an oxymoron.
1.2.6 この要件は矛盾表現であると主張しました。
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 おそらくいくつかの制限で、NAISを処理できることに同意しました。
1.3.3 No comment.
1.3.3 ノーコメント。
1.3.4 The SNMP submission documents contained significant hand waving.
1.3.4 SNMPの提出書類には、重要な手口が含まれていました。
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.3.5 アイテム1.2.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.3.7 Question as to how this requirement is achieved via proxies?
1.3.7 この要件は、プロキシを介してどのように達成されるかについての質問ですか？
1.4.1 No comment.
1.4.1 ノーコメント。
1.4.2 No comment.
1.4.2 ノーコメント。
1.4.3 No comment.
1.4.3 ノーコメント。
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プロトコルの一部として、Batch Accountingに関して重要な懐疑論がありました。「バッチ」の大きさはどれくらいですか？この要件は、FTPなどを使用して満たす必要がありますか？
1.4.5 No comment.
1.4.5 ノーコメント。
1.4.6 No comment.
1.4.6 ノーコメント。
1.4.7 No comment.
1.4.7 ノーコメント。
1.5.1 No comment.
1.5.1 ノーコメント。
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ポート番号など）をはるかに超えてパケットを調べたくないことが示唆されました。AAA以外の使用法を備えたSNMPやCOPなどのプロトコルは不利な点にあります。これは、ファイアウォールがパケットの意図された目的を決定するためにアプリケーションPDUを深く調べなければならないためです。直径はSCTPの依存に苦しんでおり、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トランスポートを使用して、Weltをインターネットスケールにスケーリングするようです。TCPには、特に複数のセッションが単一のTCP接続を使用している場合、ヘッドオブラインブロッキングに問題があります。AAAは通常、3回または4回の反復を送信し、上層の障害を示します。TCPのように、混雑に直面して再送信を続けません。バルクデータ転送は、AAAプロトコルで最も実装されていない可能性があることに注意してください。SCTPは広く実装されているプロトコルではないという懸念が表明されました。AAAは、未払いのリクエストの数を制限することにより、混雑制御を実装します。一部の半径の実装は、誤った共有秘密に遭遇したときに多くのトラフィックを送信しますが、これは適切なエラー回復の欠如によって引き起こされる可能性があります。現在ドラフトされている直径は、SCTPに依存しています。AAAはUDPを介して実行できますか？IESGは「いいえ」とは言いませんでした。彼らの問題は、混雑制御に対処することです。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。