RFC3127 日本語訳
3127 Authentication, Authorization, and Accounting: ProtocolEvaluation. D. Mitton, M. St.Johns, S. Barkley, D. Nelson, B. Patil,M. Stevens, B. Wolff. June 2001. (Format: TXT=170579 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループD.ミットンの要求をネットワークでつないでください: 3127 ノーテルはカテゴリをネットワークでつなぎます: B.パティルノキアM.スティーブンスEllacoyaがB.ヴォルフデータバス株式会社2001年6月にネットワークでつなぐ情報のM.のバークリーUUNET D.ネルソンEnterasysセントジョンズ雨乞い師技術S.ネットワーク
Authentication, Authorization, and Accounting:
Protocol Evaluation
認証、認可、および会計: プロトコル評価
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
このメモはAuthentication、Authorization、およびAAA Network Access Requirements(RFC2989)に対して提案されたプロトコルを評価するAccounting作業部会(AAA WG)委員会の過程と調査結果を表します。 このレポートの時間規制のため、それが望まれていたかもしれないとき、このドキュメントは同じくらい完全に推敲されません。 しかし、ほとんどこの州では、結果を記録するのが提示されるように残っています。
Mitton, et al. Informational [Page 1] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [1ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
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
1. .1.4に、要件合法化が.1.5提案評価. . . . . . . . . . . . . . . . . . . . . .7 1.6最終勧告を処理するという委員長の.41.3の注意メンバー声明が.2を処理するという記述. . . . . . . . . . . . . . . . . . . . . .3 1.1WG共同議長のメモ. . . . . . . . . . . . . . . . . . . . . .3 1.2を処理してください。 提案. . . . . . . . . . . . . . . . . . . . . . .8 3について議定書の中で述べてください。 項目レベル承諾評価. . . . . . . . . . . . . . . 8 3.1の一般要件. . . . . . . . . . . . . . . . . . . . . 9 3.2認証要件。 . . . . . . . . . . . . . . . . .11 3.3 認可要件. . . . . . . . . . . . . . . . . .12 3.4会計要件. . . . . . . . . . . . . . . . . . .12 3.5の可動のIP要件. . . . . . . . . . . . . . . . . . . .13 4。 評価概要. . . . . . . . . . . . . . . . .14 4.1SNMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 4.2半径++. . . . . . . . . . . . . . . . . . . . . . . . . . .14 4.3直径. . . . . . . . . . . . . . . . . . . . . . . . . . .14 4.4巡査. . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 4.5について議定書の中で述べてください。概要推薦. . . . . . . . . . . . . . . . . . .14 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . .14 6。 参照. . . . . . . . . . . . . . . . . . . . . . . . . .15 7。 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . .15 A.付録A--概要評価. . . . . . . . . . . . . . .17B.付録B--要件. . . . . . . . . . . .18B.1一般の要件のレビュー。 . . . . . . . . . . . . . . . . . . . . .18 B.2認証要件. . . . . . . . . . . . . . . . . .19B.3認可要件。 . . . . . . . . . . . . . . . . . .19 B.4会計要件… .20 C.付録C--位置の概要… .21 C.1 SNMPプロ評価. . . . . . . . . . . . . . . . . . . . .21C.2 SNMPは評価をだまします…; .28 C.3半径+プロ評価… .33 C.4半径+まやかし評価… .37 C.5直径プロ評価.44………………C.6直径まやかし評価; .50 プロ評価. . . . . . . . . . . . . . . . . . . . .55C.8が逮捕するC.7巡査は評価. . . . . . . . . . . . . . . . . . . . .59D.付録D(2000年6月22日電子会議. . . . . . . . . . . .66D.2のD.1分が書き留める2000年6月29日電子会議. . . . . . . . . . . .73D.4のD.3分が書き留める2000年7月6日電子会議の2000年6月27日電子会議. . . . . . . . . . . .68のミーティング注意. . . . . . . . . . . . . . . . . .66)をだまします….78 D.5分の2000年7月11日電子会議. . . . . . . . . . . .80の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . .84
Mitton, et al. Informational [Page 2] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [2ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
1. Process Description
1. プロセス記述
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再特許が承認されて、Network Access RequirementsドキュメントがAAA WG Last Callを渡した後に、プロトコルSubmissionsのSolicitationは4/13/2000に発行されました。 AAA WGメーリングリストにSolicitationを送りました、よくAAAに関連する他のIETF WGメーリングリストのように、NASREQ、モバイルIP、RAP、およびSNMPv3を含んでいて。
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
プロトコル差出と承諾記述ドキュメントはインターネットDraft形式でインターネット drafts@ietf.org にメールで提出することでした。 差出のための締め切りは2000年6月1日でした。 候補であるとみなされるために、差出は、以下で説明されるように2026年の資格のないRFC声明を含む必要がありました。 http://www.ietf.org/Sec10.txt
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日に発表されました)。 チームの仕事は彼らのプロトコル差出の評価を記録するインターネットDraftを組み立てるためにあることでした。 目標は2000年7月14日服従の締め切りの前にIETF48に利用可能な最初の草稿を持つことです。
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.
評価草稿を構成する際に、評価チームがプロトコル仕様、承諾記述、および他の関連ドキュメント、Network Access Requirementsドキュメント(RFC2989)から描くように頼まれました。
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の共同議長、Basavarajパティル、モバイルIP WGの共同いす、およびマーク・スティーブンス、RAP WGの共同議長を含んでいました。
Mitton, et al. Informational [Page 3] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [3ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
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アドバイザーはOperationsとManagement Areaのランディ・ブッシュとバート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) MOBILEIPとROAMOPS NASREQ、2のために、)ベース要件ドキュメントに対してAAA要件ドキュメント[AAAReqts]を有効にしてください。 それぞれのSNMP、+ +、Diameter、およびCOPS提案が有効にされた要件に対して要求するRadiusを評価してください。 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日でした--少しの差出もそれ以後パネルの熟考で考えられませんでした。
1.3. Members Statements
1.3. メンバー声明
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.
グループはマイケル・セントジョンズによってまとめられました。 デヴィッド・ミットンはドキュメントエディタでした。 以下に、バックグラウンド声明、それらからの興味があるどんな闘争、およびパネルの残りもあります。
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標準化過程との少しの接触もありません。
Mitton, et al. Informational [Page 4] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [4ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
David Mitton, Nortel Networks
デヴィッド・ミットン、ノーテルネットワーク
I have been Nasreq WG co-chair and author of several Nasreq drafts. As well as, previously contributed to several RADIUS drafts.
私は、いくつかのNasreq草稿のNasreq WG共同議長と作者です。 良く、以前に、いくつかのRADIUS草稿に寄付しています。
I have been a RADIUS NAS implementor and Technical Prime on our Server products, so know it extremely well. In my current job role I am involved with Nortel's IP Mobility products, which support Diameter.
私が私たちのServer製品の上のRADIUS NAS作成者とTechnical Primeであるので、それを非常によく知ってください。 現在の仕事の役割では、私はノーテルIP Mobility製品にかかわります。(製品はDiameterを支持します)。
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 Requirementsにプレゼンテーションを書きました、それを実行していなくて、自分を考えるのを除いてその問題の専門家を通して。
Stuart Barkley, UUNET
スチュアート・バークリー、UUNET
I've been working for 5 years at UUNET on various parts of our dialup network. I have extensive experience with designing, developing and operating our SNMP based usage data gathering system. I've also been involved in our radius based authentication and authorization systems in an advisory position.
私は5年間UUNETで私たちのダイアルアップネットワークの様々な部分に取り組んでいます。 私には、広範囲の経験が私たちのSNMPのベースの用法データ集会システムを設計して、開発して、操作すると共にあります。 また、私は状況報告のベースの認証と認可システムが置く私たちの半径にかかわりました。
I've participated in radius/roamops/nasreq/aaa groups for the past several years. I'm not an author or contributer on any of the requirements or protocol documents being presented although I have been peripherally involved in these working groups.
私は過去数年間半径/roamops/nasreq/aaaグループに参加しています。 私は、作者でなくて、周囲にこれらのワーキンググループにかかわったのではなく、contributerでもあります要件か提示されるプロトコルドキュメントのどんなも。
Dave Nelson, Enterasys Networks
デーヴ・ネルソン、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.
特に下積み時代の間、RADIUS WGで非常にアクティブです。 AAA服従におけるかかわり合いがありません。 Diameterの開発に貢献していません。
No involvement with SNMPv3 or the AAA submission. David Harrington, a proponent, works in a different group within my company. We have not discussed the submission. No involvement with the COPS protocol.
SNMPv3へのかかわり合いがないAAA服従。 デヴィッド・ハリントン(提案者)は私の会社の中で異なったグループで働いています。 私たちは服従について議論していません。 COPSプロトコルへのかかわり合いがありません。
Basavaraj Patil, Nokia
Basavarajパティル、ノキア
I am a contributor to the AAA requirements document (RFC 2977) submitted by the Mobile IP WG. I was a member of the team that was constituted to capture the Mobile IP requirements for AAA services.
私はモバイルIP WGによって提出されたAAA要件ドキュメント(RFC2977)への寄稿者です。 私は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で行われた仕事の後をつけました。
Mitton, et al. Informational [Page 5] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [5ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
My present work at Nokia does involve looking at AAA protocols (to some extent at least) for use in wireless networks. I have also done some work with AAA protocols such as Diameter in my previous job at Nortel Networks.
ノキアの私の本書は、ワイヤレス・ネットワークにおける使用のためにAAAプロトコル(ある程度少なくとも)を見ることを伴います。 また、私は私の前の仕事におけるDiameterなどのAAAプロトコルでノーテルNetworksにいくらかの仕事をしました。
Mark Stevens, Ellacoya Networks
マーク・スティーブンス、Ellacoyaネットワーク
I am the co-chair of the IETF RAP working group which is the working group that has developed the COPS protocol. I have not contributed to the documents describing how COPS can satisfy AAA requirements.
私はCOPSプロトコルを開発したワーキンググループであるIETF RAPワーキンググループの共同議長です。 私はCOPSがどうAAA要件を満たすことができるかを説明するドキュメントに貢献していません。
I participated in early AAA working group meetings, but have not been an active participant since the group's rechartering. The company that currently employees me builds devices might benefit from being AAA enabled.
私は、早めのAAAワーキンググループミーティングに参加しますが、グループが「再-特許」であるので、積極的な参加者ではありません。 会社、そんなに現在の従業員、私、装置がAAAが可能にした存在からためになるかもしれない体格。
Barney Wolff, Databus Inc.
バーニー・ヴォルフ、データバス株式会社
I have implemented RADIUS client, proxy and server software, under contract to AT&T. That software is owned by AT&T and I have no financial interest in it.
私は契約に基づきRADIUSクライアント、プロキシ、およびサーバソフトウェアをAT&Tに実行しました。 そのソフトウェアはAT&Tによって所有されています、そして、私はどんな財政的な関心もそれに持っていません。
I have been a member of the RADIUS WG for several years, and consider myself an advocate for RADIUS against what I consider unjustified attacks on it.
私は、数年間のRADIUS WGのメンバーであり、RADIUSのためにそれに対する攻撃であると不当なことであると証明される私が考えることに対して自分が支持者であると考えます。
I've never worked for any of the companies whose staff have produced any of the proposals, although I obviously might at some future time.
私はスタッフが提案のいずれも起こした会社のどれかで一度も働いたことがありません、私が何らかの将来の時間に明らかにそうするかもしれませんが。
1.4. Requirements Validation Process
1.4. 要件合法化の過程
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]。
Mitton, et al. Informational [Page 6] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [6ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
1.5. Proposal Evaluation
1.5. 提案評価
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人のメンバーが、'PRO'という要約を書くために割り当てられて、提案の最も寛大な解釈を取ることができました。 彼は疑問の利益を与えることができました。 もう片方のメンバーは、'CON'という要約を書くために選任されて、彼の評価をするとき、最も厳しい評価基準を使用しなければなりませんでした。
Each brief looked at each individual requirement and evaluated how close the proposal came in meeting that requirement. Each item was scored as one of an 'F' for failed to meet the requirement, 'P' for partially meeting the requirement, or 'T' for totally meeting the requirement. The proposals were scored only on the information presented. This means that a particular protocol might actually meet the specifics of a requirement, but if the proposal did not state, describe or reference how that requirement was met, in might be scored lower.
各要約は、それぞれの個々の要件を見て、その必要条件を満たしながらどれくらい近くに提案を入らせたかを評価しました。 失敗されて、部分的に条件を満たすために要件、'P'に会ってください。さもないと、完全に会うための't'が要件に会うので、各個条は'F'の1つとして得点されました。 提案は提示された情報だけで得られました。 これは、特定のプロトコルが実際に要件の詳細を満たすかもしれないことを意味しますが、提案がその必要条件が力でどう満たされたかに述べもしませんでしたし、説明もしませんでしたし、参照をつけもしなかったなら、より低く得点されてください。
The panel met by teleconference to discuss each proposal and the PRO and CON briefs. Each of the briefers discussed the high points of the brief and gave his summary findings for the proposal. We then discussed each individual requirement line-by-line as a group. At the conclusion, the members provided their own line-by-line evaluations which were used to determine the consensus evaluation for the specific requirement relative to that proposal. The meeting notes from those teleconferences as well as the individual briefs are included in the appendixes.
パネルは、各提案、PRO、およびCON概要について議論するために電子会議で触れました。 それぞれの報告者は、要約の高い先について議論して、提案のための彼の概要調査結果を与えました。 そして、私たちはグループとしての1行ずつのそれぞれの個々の要件について議論しました。 結論のときに、メンバーはその提案に比例して決められた一定の要求のためのコンセンサス評価を決定するのに使用されたそれら自身の1行ずつの評価を提供しました。 個々の概要と同様にそれらの電子会議からのミーティング注意は付属物に含まれています。
1.6. Final Recommendations Process
1.6. 最終勧告の過程
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つの提案のために結果を比較して、私たちが一貫した評価基準を使用したのを保証する時間続きます。 私たちは要件議論で要件をして、その時はそれぞれのプロトコルの議論です。
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.
最終段階は各メンバーがそれぞれのプロトコルのための彼の最終的な概要評価を提供することでした。 各提案はNot Acceptable、Acceptable Only For Accounting、EngineeringとFully AcceptableとAcceptableとして得られました。 提案が工学で許容できたところでは、メンバーは、それが小さいか、中型の、または、多量であるかどうかを示しました。
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.
スコアがチームメンバーの意見について簡単に述べたことに注意されるべきです。 そして、彼らはここに提示された議事録の間に得られなかった背景的知識か追加設定を考慮に入れたかもしれません。
Mitton, et al. Informational [Page 7] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [7ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
Each member's scores were used within the group to develop the group's consensus.
各メンバーのスコアは、グループのコンセンサスを育むのにグループの中で使用されました。
2. Protocol Proposals
2. プロトコル提案
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)プロトコルの拡大のための枠組み」、ProgressのWork。
- 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要件に対する巡査の比較」、処理中の作業。
[COPSAAA] "COPS Usage for AAA", Work in Progress.
[COPSAAA]は仕事進行中で「AAAのために用法を獲得します」。
3. Item Level Compliance Evaluation
3. 項目レベル承諾評価
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が総Complianceと等しく、Meetsがすべて、Pが部分的なComplianceと完全に、等しいという要件であり、Meetsは失敗したいくつかの要件F=Complianceです、大会要件ではなく、Does、許容できる。
Where two are shown eg: P/T, there was a tie.
egが2に見せられるところ: P/T、繋がりがありました。
Mitton, et al. Informational [Page 8] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [8ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
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.
小区分付番は要件ドキュメント部分と商品番号に対応しています。 また、この相対的な付番はプロトコルPositionプレゼンテーション、ここ、付録で使用されました。
3.1 General Requirements
3.1 一般要件
3.1.1 Scalability - SNMP:P, RADIUS:P, Diameter:T, COPS:T
3.1.1 スケーラビリティ--巡査: SNMP: P、半径: P、直径: T、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は現在のエージェントモデルがどうクライアントの要求のベースの取引に適合させられるだろうかに関する詳細の不足のため格下げされました。 RADIUS提案は適切に問題と取り組みませんでした。 プロキシのウェブに関してすべての提案には未解決の問題があります。
3.1.2 Fail-over - SNMP:P, RADIUS:P, Diameter:P, COPS:T/P
3.1.2 フェイルオーバー--巡査: SNMP: P、半径: P、直径: P、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.
グループは、どんなプロトコルもこの要件で順調であると思わなかったことに特に注意しました。 ほとんどの差出におけるリンク失敗検出と第一のサーバ回復を指定するために不十分な仕事をしました。 COPSはいくつかのメカニズムを持っていますが、すべて持っているというわけではありません。 これらのメカニズムがプロキシのウェブでどう動作するだろうかは記述されていません。
3.1.3 Mutual Authentication - SNMP:T, RADIUS:T/P, Diameter:T, COPS:T
3.1.3 互いの認証--巡査: SNMP: T、半径: T/P、直径: T、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.
ホップだけの間には、RADIUSでの互いの認証があります。
3.1.4 Transmission Level Security - SNMP:T, RADIUS:P, Diameter:T, COPS:T
3.1.4 トランスミッションレベルセキュリティ--巡査: SNMP: T、半径: P、直径: T、T
All protocols have methods of securing the message data.
すべてのプロトコルには、メッセージデータを保証する方法があります。
3.1.5 Data Object Confidentiality - SNMP:P, RADIUS:P, Diameter:T, COPS:T
3.1.5 データ・オブジェクト秘密性--巡査: SNMP: P、半径: P、直径: T、T
This requirement usually comes from third-party situations, such as access outsourcing.
通常、この要件はアクセスアウトソーシングなどの第三者状況から来ます。
Diameter and COPS both use CMS formats to secure data objects. The group is concerned if this method and it's support is perhaps too heavy weight for NAS and some types of edge systems.
直径とCOPSは、データ・オブジェクトを固定するのにともにCMS形式を使用します。 グループはこの方法であるなら関係があります、そして、サポートが恐らくNASと何人かのタイプの縁のシステムのための重過ぎる重さであるということです。
Mitton, et al. Informational [Page 9] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [9ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
3.1.6 Data Object Integrity - SNMP:F, RADIUS:P, Diameter:T, COPS:T
3.1.6 データ・オブジェクト保全--巡査: SNMP: F、半径: P、直径: T、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提案で適切に説明されませんでした。 RADIUS解決策はそれほど強くはありませんでした。
3.1.7 Certificate Transport - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.1.7 証明書輸送--巡査: SNMP: T、半径: T、直径: T、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
3.1.8 信頼できるAAA輸送--巡査: SNMP: P、半径: P、直径: T、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とRADIUS提案はメッセージの再送と回復の解決法を提供する際に欠けていました。
3.1.9 Run over IPv4 - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.1.9 IPv4の上の走行--巡査: SNMP: T、半径: T、直径: T、T
3.1.10 Run over IPv6 - SNMP:P, RADIUS:T, Diameter:T, COPS:T
3.1.10 IPv6の上の走行--巡査: SNMP: P、半径: T、直径: T、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
3.1.11 サポートプロキシとルート設定ブローカー--巡査: SNMP: F、半径: P、直径: T、P
The SNMP proposal did not address this requirement. COPS claims support, but does not work through some of the issues. Diameter was the only protocol that attempted to address this area to a fair extent.
SNMP提案はこの要件を記述しませんでした。 COPSはサポートを要求しますが、問題のいくつかを終えません。 直径はこの領域を公正な程度まで記述するのを試みた唯一のプロトコルでした。
3.1.12 Auditability - SNMP:F, RADIUS:F, Diameter:T, COPS:P
3.1.12 監査能力--巡査: SNMP: F、半径: F、直径: T、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とRADIUS提案は、この要件を働かせるのを試みませんでした。 COPSは、歴史PIBがこの問題を解決するのを助けますが、記述を全く与えないのを示します。
Mitton, et al. Informational [Page 10] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [10ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
3.1.13 Shared Secret Not Required - SNMP:P/T, RADIUS:T, Diameter:T, COPS:T
3.1.13 必要でない共有秘密キー--巡査: SNMP: P/T、半径: T、直径: T、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.1.14 サービスの特定の属性を運ぶ能力--巡査: SNMP: T、半径: T、直径: T、T
3.2 Authentication Requirements
3.2 認証要件
3.2.1 NAI Support - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.2.1 NAIサポート--巡査: SNMP: T、半径: T、直径: T、T
3.2.2 CHAP Support - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.2.2 やつサポート--巡査: SNMP: T、半径: T、直径: T、T
3.2.3 EAP Support - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.2.3 EAPサポート--巡査: SNMP: T、半径: T、直径: T、T
3.2.4 PAP/Clear-text Passwords - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.2.4 乳首/クリアテキストパスワード--巡査: SNMP: T、半径: T、直径: T、T
The requirement for clear-text passwords comes from one-time-password systems and hard-token (SecurID) systems.
クリアテキストパスワードのための要件は使い捨てパスワードシステムと固い象徴(SecurID)システムから来ます。
3.2.5 Reauthentication on demand - SNMP:T, RADIUS:P, Diameter:P, COPS:T
3.2.5 オンデマンドのReauthentication--COPS: SNMP: T、RADIUS: P、Diameter: P、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.
また、私たちはタイマでやる気満々、そして、(生涯駆動)とイベントドリブンReauthenticationを区別しました。 また、これがプロキシ環境でどう働くだろうかに関して、心配しています。
3.2.6 Authorization w/o Authentication - SNMP:P, RADIUS:T/P, Diameter:T, COPS:T
3.2.6 認証のない認可--巡査: SNMP: P、半径: T/P、直径: T、T
This requirement really means authorization with trivial authentications (e.g. by assertion or knowledge).
この要件は本当に些細な認証(例えば、主張か知識による)による認可を意味します。
Mitton, et al. Informational [Page 11] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [11ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
3.3 Authorization Requirements
3.3 認可要件
3.3.1 Static and Dynamic IP Addr Assignment - SNMP:P/F, RADIUS:T, Diameter:T, COPS:T
3.3.1 静的でダイナミックなIP Addr課題--巡査: SNMP: P/F、半径: T、直径: T、T
There is difficulty in interpreting what is static or dynamic with respect to the viewpoint of the client, server, administrator or user.
クライアント、サーバ、管理者またはユーザの観点に関して静的であるか、またはダイナミックなことを解釈することにおける苦労があります。
3.3.2 RADIUS Gateway Capability - SNMP:P, RADIUS:P, Diameter:T/P, COPS:P
3.3.2 半径ゲートウェイ能力--巡査: SNMP: P、半径: P、直径: T/P、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.
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.
3.3.3 Reject Capability - SNMP:T/P/F, RADIUS:T, Diameter:T, COPS:P
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.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
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?
Some evaluators wondered how the server will know that re- authorization is supposed to be done? Will it interface to something external, or have sufficient internals?
3.3.6 Support for Access Rules & Filters - SNMP:P, RADIUS:P, Diameter:P, COPS:T/P
3.3.6 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.
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
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.
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.3.8 Unsolicited Disconnect - SNMP:T, RADIUS:P, Diameter:T, COPS:T
3.4 Accounting Requirements
3.4 Accounting Requirements
3.4.1 Real Time Accounting - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.4.1 Real Time Accounting - SNMP:T, RADIUS:T, Diameter:T, COPS:T
Mitton, et al. Informational [Page 12] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 12] RFC 3127 AAA Protocol Evaluation Process June 2001
3.4.2 Mandatory Compact Encoding - 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.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
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?
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?
3.4.5 Guaranteed Delivery - SNMP:T, RADIUS:T, Diameter:T, COPS:T
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.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.4.7 Dynamic Accounting - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.5 MOBILE IP Requirements
3.5 MOBILE IP Requirements
3.5.1 Encoding of MOBILE IP Registration Messages - SNMP:T, RADIUS:T/P, 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
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.
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 and COPS also have the problem that they are used for other types of operations than just AAA.
SNMP and COPS also have the problem that they are used for other types of operations than just AAA.
Should firewalls have AAA Proxy engines?
Should firewalls have AAA Proxy engines?
We didn't look at "NAT friendly" issues either.
We didn't look at "NAT friendly" issues either.
COPS:T
COPS:T
The group is not clear on how this requirement impacts the actual protocol. Raj explained it to us, but we mostly took it on faith.
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.
Mitton, et al. Informational [Page 13] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 13] RFC 3127 AAA Protocol Evaluation Process June 2001
4. Protocol Evaluation Summaries
4. Protocol Evaluation Summaries
4.1. SNMP
4.1. SNMP
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 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.
4.2. Radius++
4.2. Radius++
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.
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.
4.3. Diameter
4.3. Diameter
Diameter is considered acceptable as an AAA protocol. There is some minor engineering required to bring it into complete compliance with the requirements but well within short term capabilities. Diameter might also benefit from the inclusion of a broader data model ala COPS.
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.
4.4. COPS
4.4. 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 is considered acceptable as an AAA protocol. There is some minor to medium engineering required to bring it into complete compliance with the requirements.
4.5. Summary Recommendation
4.5. Summary Recommendation
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.
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.
5. Security Considerations
5. Security Considerations
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 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.
Mitton, et al. Informational [Page 14] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 14] RFC 3127 AAA Protocol Evaluation Process June 2001
6. References
6. References
[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. and E. Jaques, "Criteria for Evaluating AAA Protocols for Network Access", RFC 2989, April 2000.
[AAAComp] Ekstein, TJoens, Sales and Paridaens, "AAA Protocols:
Comparison between RADIUS, Diameter and COPS", Work in
Progress.
[AAAComp] Ekstein, TJoens, Sales and Paridaens, "AAA Protocols: Comparison between RADIUS, Diameter and COPS", Work in Progress.
[SNMPComp] Natale, "Comparison of SNMPv3 Against AAA Network Access
Requirements", Work in Progress.
[SNMPComp] Natale, "Comparison of SNMPv3 Against AAA Network Access Requirements", Work in Progress.
[RADComp] TJoens and DeVries, "Comparison of RADIUS Against AAA
Network Access Requirements", Work in Progress.
[RADComp] TJoens and DeVries, "Comparison of RADIUS Against AAA Network Access Requirements", Work in Progress.
[RADExt] TJoens, Ekstein and DeVries, "Framework for the extension
of the RADIUS (v2) protocol", Work in Progress,
[RADExt] TJoens, Ekstein and DeVries, "Framework for the extension of the RADIUS (v2) protocol", Work in Progress,
[DIAComp] Calhoun, "Comparison of Diameter Against AAA Network
Access Requirements", Work in Progress.
[DIAComp] Calhoun, "Comparison of Diameter Against AAA Network Access Requirements", Work in Progress.
[COPSComp] Khosravi, Durham and Walker, "Comparison of COPS Against
the AAA NA Requirements", Work in Progress.
[COPSComp] Khosravi, Durham and Walker, "Comparison of COPS Against the AAA NA Requirements", Work in Progress.
[COPSAAA] Durham, Khosravi, Weiss and Filename, "COPS Usage for
AAA", Work in Progress.
[COPSAAA] Durham, Khosravi, Weiss and Filename, "COPS Usage for AAA", Work in Progress.
7. Authors' Addresses
7. Authors' Addresses
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
Phone: 978-288-4570 EMail: dmitton@nortelnetworks.com
Mitton, et al. Informational [Page 15] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 15] RFC 3127 AAA Protocol Evaluation Process June 2001
Michael StJohns Rainmaker Technologies 19050 Pruneridge Ave, Suite 150 Cupertino, CA 95014
Michael StJohns Rainmaker Technologies 19050 Pruneridge Ave, Suite 150 Cupertino, CA 95014
Phone: 408-861-9550 x5735 EMail: stjohns@rainmakertechnologies.com
Phone: 408-861-9550 x5735 EMail: stjohns@rainmakertechnologies.com
Stuart Barkley UUNET F1-1-612 22001 Loudoun County Parkway Ashburn, VA 20147 US
Stuart Barkley UUNET F1-1-612 22001 Loudoun County Parkway Ashburn, VA 20147 US
Phone: 703-886-5645 EMail: stuartb@uu.net
Phone: 703-886-5645 EMail: 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. (a Cabletron Systems company) 50 Minuteman Road Andover, MA 01810-1008
Phone: 978-684-1330 EMail: dnelson@enterasys.com
Phone: 978-684-1330 EMail: 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
Phone: +1 972-894-6709 EMail: Basavaraj.Patil@nokia.com
Mark Stevens Ellacoya Networks 7 Henry Clay Drive Merrimack, NH 03054
Mark Stevens Ellacoya Networks 7 Henry Clay Drive Merrimack, NH 03054
Phone: 603-577-5544 ext. 325 EMail: mstevens@ellacoya.com
Phone: 603-577-5544 ext. 325 EMail: mstevens@ellacoya.com
Barney Wolff, Pres. Databus Inc. 15 Victor Drive Irvington, NY 10533-1919 USA
Barney Wolff, Pres. Databus Inc. 15 Victor Drive Irvington, NY 10533-1919 USA
Phone: 914-591-5677 EMail: barney@databus.com
Phone: 914-591-5677 EMail: barney@databus.com
Mitton, et al. Informational [Page 16] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 16] RFC 3127 AAA Protocol Evaluation Process June 2001
Appendix A - Summary Evaluations Consensus Results by Requirement
and Protocol
Appendix A - Summary Evaluations Consensus Results by Requirement and Protocol
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
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.2.1 T T T T 1.2.2 T T T T 1.2.3 T T T T 1.2.4 T T T T 1.2.5 T P P T 1.2.6 P T/P T T
1.3.1 P/F T T T
1.3.2 P T T/P P
1.3.3 T/P/F T T P
1.3.4 F T T T
1.3.5 P/F P T/P T
1.3.6 P P P T/P
1.3.7 F P/F P T/P
1.3.8 T P T T
1.3.1 P/F T T T 1.3.2 P T T/P P 1.3.3 T/P/F T T P 1.3.4 F T T T 1.3.5 P/F P T/P T 1.3.6 P P P T/P 1.3.7 F P/F P T/P 1.3.8 T P T T
1.4.1 T T T T
1.4.2 T T T T
1.4.3 T T T T
1.4.4 T F P P
1.4.5 T T T T
1.4.6 T T T T
1.4.7 T T T T
1.4.1 T T T T 1.4.2 T T T T 1.4.3 T T T T 1.4.4 T F P P 1.4.5 T T T T 1.4.6 T T T T 1.4.7 T T T T
1.5.1 T T/P T T
1.5.2 F T P P
1.5.3 F P T T
1.5.1 T T/P T T 1.5.2 F T P P 1.5.3 F P T T
Mitton, et al. Informational [Page 17] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 17] RFC 3127 AAA Protocol Evaluation Process June 2001
Appendix B - Review of the Requirements
Appendix B - Review of the Requirements
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.
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.
B.1 General Requirements
B.1 General Requirements
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.
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.
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.
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.
Data object confidentiality - [Table] Delete the MOBILE IP "S" and footnote "33". The base document text does not appear to support this requirement.
Data object confidentiality - [Table] Delete the MOBILE IP "S" and footnote "33". The base document text does not appear to support this requirement.
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.
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.
Run over IPv4 - [Table] Replace the MOBILE IP footnote "17" with footnote "33". This appears to be a incorrect reference.
Run over IPv4 - [Table] Replace the MOBILE IP footnote "17" with footnote "33". This appears to be a incorrect reference.
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.
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.
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.
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.
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.
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.
Mitton, et al. Informational [Page 18] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 18] RFC 3127 AAA Protocol Evaluation Process June 2001
B.2 Authentication Requirements
B.2 Authentication Requirements
NAI Support - [Table] Replace MOBILE IP footnote "38" with "39". This appears to be a more appropriate reference.
NAI Support - [Table] Replace MOBILE IP footnote "38" with "39". This appears to be a more appropriate reference.
CHAP Support - [Table] Delete MOBILE IP "O" as unsupported.
CHAP Support - [Table] Delete MOBILE IP "O" as unsupported.
EAP Support - [Table] Delete MOBILE IP "O" as unsupported.
EAP Support - [Table] Delete MOBILE IP "O" as unsupported.
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 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.
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.
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.
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.
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.
B.3 Authorization Requirements
B.3 Authorization Requirements
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.
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.
RADIUS Gateway capability - [Table] Delete the MOBILE IP "O" and footnote "30". The referenced text does not appear to support the requirement.
RADIUS Gateway capability - [Table] Delete the MOBILE IP "O" and footnote "30". The referenced text does not appear to support the requirement.
Reject capability - [Table] Delete the NASREQ "M" and footnote "12". The NASREQ document does not appear to require this capability.
Reject capability - [Table] Delete the NASREQ "M" and footnote "12". The NASREQ document does not appear to require this capability.
Mitton, et al. Informational [Page 19] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 19] RFC 3127 AAA Protocol Evaluation Process June 2001
Reauthorization on Demand - [Table] Delete the MOBILE IP "S" and footnotes "30,33" The referenced text does not support this requirement.
Reauthorization on Demand - [Table] Delete the MOBILE IP "S" and footnotes "30,33" The referenced text does not support this requirement.
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.
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.
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.
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.
B.4 Accounting Requirements
B.4 Accounting Requirements
Real-Time accounting - [Table] Replace MOBILE IP footnote [39] with a footnote pointing to section 3.1 of [3] as being more appropriate.
Real-Time accounting - [Table] Replace MOBILE IP footnote [39] with a footnote pointing to section 3.1 of [3] as being more appropriate.
Mandatory Compact Encoding - [Table] Delete MOBILE IP "M" and footnote "33" as the reference does not support the requirement.
Mandatory Compact Encoding - [Table] Delete MOBILE IP "M" and footnote "33" as the reference does not support the requirement.
Accounting Record Extensibility - [Table] Delete NASREQ "M" and footnote "15" as the reference does not support the requirement.
Accounting Record Extensibility - [Table] Delete NASREQ "M" and footnote "15" as the reference does not support the requirement.
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.
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.
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.
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.
Footnote section.
Footnote section.
[40] should be pointing to 6.1 of [4]. [41] should be pointing to 6.2.2 of [4]. [45] should be pointing to 6.4 of [4]. [46] should be pointing to 8 of [4].
[40] 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].
Mitton, et al. Informational [Page 20] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 20] RFC 3127 AAA Protocol Evaluation Process June 2001
Appendix C - Position Briefs
Appendix C - Position Briefs
C.1 SNMP PRO Evaluation
C.1 SNMP PRO Evaluation
Evaluation of SNMP AAA Requirements PRO Evaluation Evaluator - Stuart Barkley
Evaluation of SNMP AAA Requirements PRO Evaluation Evaluator - 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] 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'
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.
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.
1 Per item discussion
1 Per item discussion
1.1 General Requirements
1.1 General Requirements
1.1.1 Scalability - Grade T
1.1.1 Scalability - Grade 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.
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.
1.1.2 Fail-over - Grade T
1.1.2 Fail-over - Grade T
SNMP is of vital importance to the operation of most networks. Existing infrastructures can handle required failover or other redundant operations.
SNMP is of vital importance to the operation of most networks. Existing infrastructures can handle required failover or other redundant operations.
1.1.3 Mutual Authentication - Grade T
1.1.3 Mutual Authentication - Grade 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
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
Mitton, et al. Informational [Page 21] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 21] RFC 3127 AAA Protocol Evaluation Process June 2001
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.
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.
1.1.4 Transmission Level Security - Grade T
1.1.4 Transmission Level Security - Grade T
SNMPv3 provides many additional security options which were not available or were more controversial in previous SNMP versions.
SNMPv3 provides many additional security options which were not available or were more controversial in previous SNMP versions.
1.1.5 Data Object Confidentiality - New Grade P (from T)
1.1.5 Data Object Confidentiality - New Grade P (from 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).
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).
1.1.6 Data Object Integrity - New Grade T (from P)
1.1.6 Data Object Integrity - New Grade T (from 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 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.
1.1.7 Certificate Transport - Grade T
1.1.7 Certificate Transport - Grade 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.
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.
1.1.8 Reliable AAA Transport - New Grade T (from P)
1.1.8 Reliable AAA Transport - New Grade T (from 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.
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.
Mitton, et al. Informational [Page 22] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 22] RFC 3127 AAA Protocol Evaluation Process June 2001
1.1.9 Run over IPv4 - Grade T
1.1.9 Run over IPv4 - Grade T
SNMP has operated in this mode for many years.
SNMP has operated in this mode for many years.
1.1.10 Run over IPv6 - New Grade T (from P)
1.1.10 Run over IPv6 - New Grade T (from 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 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.
1.1.11 Support Proxy and Routing Brokers - New Grade T (from P)
1.1.11 Support Proxy and Routing Brokers - New Grade T (from 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.
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.
1.1.12 Auditability - New Grade T (from F)
1.1.12 Auditability - New Grade T (from 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.
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.
1.1.13 Shared Secret Not Required - Grade T
1.1.13 Shared Secret Not Required - Grade T
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.
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.
1.1.14 Ability to Carry Service Specific Attributes - Grade T
1.1.14 Ability to Carry Service Specific Attributes - Grade T
SNMP has long had the ability for other parties to create new unambiguous attributes.
SNMP has long had the ability for other parties to create new unambiguous attributes.
1.2 Authentication Requirements
1.2 Authentication Requirements
1.2.1 NAI Support - Grade T
1.2.1 NAI Support - Grade T
SNMP easily supports this. NAIs were defined to be easily carried in existing protocols.
SNMP easily supports this. NAIs were defined to be easily carried in existing protocols.
Mitton, et al. Informational [Page 23] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 23] RFC 3127 AAA Protocol Evaluation Process June 2001
1.2.2 CHAP Support - Grade T
1.2.2 CHAP Support - Grade T
SNMP can easily provide objects to pass the necessary information for CHAP operation.
SNMP can easily provide objects to pass the necessary information for CHAP operation.
1.2.3 EAP Support - New Grade T (from P)
1.2.3 EAP Support - New Grade T (from 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 乳首/クリアテキストパスワード--新しいグレード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 オンデマンドのReauthorization--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課題--グレードT
SNMP can easily provide objects to control this operation.
SNMPは、この操作を制御するために容易にオブジェクトを提供できます。
1.3.2 RADIUS Gateway Capability - Grade T
1.3.2 半径ゲートウェイ能力--Tを等級付けしてください。
As the document describes, with the addition of any necessary compatibility variables SNMP can be gatewayed to RADIUS applications.
ドキュメントが説明するどんな必要な互換性の追加でも、RADIUSアプリケーションに変数SNMPをgatewayedされることができます。
Mitton, et al. Informational [Page 24] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [24ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
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--Tを等級付けしてください。
SNMP can easily provide objects to control this operation.
SNMPは、この操作を制御するために容易にオブジェクトを提供できます。
1.3.6 Support for ACLs - Grade T
1.3.6 ACLsのサポート--Tを等級付けしてください。
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はreacquireの無くなっている州の情報に動的機器を許容するメソッドを提供できます。 これらの能力は直接スケーラビリティ関心と対話します、そして、注意はスケーラビリティ要件と同時に会われるというこの要件を予想するとき、取られる必要があります。
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
SNMPはこの運転モードを提供できます。 SNMPと他の転写法に連結するのにSNMPを使用する中にドキュメントはメソッドの両方について完全に概説します。 多くのプロバイダーがリアルタイムでに既にSNMPを使用します。
Mitton, et al. Informational [Page 25] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [25ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
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.
他のネットワークイベントの通知。 この能力は直接スケーラビリティ関心と対話できます、そして、注意がこれを適切に相互作用させるように取るために必要とする実装は大規模環境です。
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は一般に、かなりコンパクトなコード化フォームに要素と比べているプロトコルをコード化しました。テキストはフォームを基礎づけました(いくつかの存在に使用されるように、半径ログは実装をファイルします)。 これは、サービスを提供するために一般的な要件で伸展性のための特定の属性と会計要件を相互作用させます。 SNMPペイロード圧縮への慎重なMIBデザインと今後の活動で、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パラメタについて議論して、ある既存のMIBsが実装戦略に関する例を含むのを示します。 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は配送が保証された提供に非常に従順です。 特に牽引力のモデル(しばしば想定されたプッシュモデルに対する)で、データ採集民は、すべてのデータがtransferedされたのを絶対に知ることができます。 データ受信装置がそうしない一般的なプッシュモデルで、データの創始者にデータを提供することにおける問題があるかどうかを知ってください。
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のベースの操作に使用されます。 ドキュメントは使用に利用可能なDateAndTime原文のコンベンションを指し示します。 すべての環境のように、情報を当てにされるべき前にタイムスタンプ精度は評価を必要とします。
Mitton, et al. Informational [Page 26] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [26ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
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登録メッセージのコード化--Tを等級付けしてください。
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 地元のホームのエージェントの配分--新しいグレードT(from ?)
SNMP is not concerned with the LHA. This can be under control of the Local network to meet its needs.
SNMPはLHAに関係がありません。 これは、需要を満たすためにLocalネットワークで制御されている場合があります。
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プロトコルによって必要とされた必要なアクセス制御を提供してください。 現在のSNMPv3仕様でSNMPの旧バージョンの切迫した課題を修正してあります。
Mitton, et al. Informational [Page 27] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [27ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
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プロトコルファミリーに、必要な必要条件を完全に満たすように見えます。
C.2 SNMP CON Evaluation
C.2 SNMPまやかし評価
Evaluation of SNMP AAA Requirements CON Evaluation Evaluator - Michael StJohns
SNMP AAAの要件まやかし評価評価者の評価--マイケルStJohns
Ref [1] is "Comparison of SNMPv3 Against AAA Network Access Requirements", aka 'the document' Ref [2] is the aaa eval criteria as modified by us.
審判[1]は「AAAネットワークアクセス要件に対するSNMPv3の比較」、通称'ドキュメント'Ref[2]が変更されるとして私たちによるaaa eval評価基準であるということです。
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つのAAAサーバに連絡しながら多くのエージェント(実行しているAAA)へ多くのエージェント地図に連絡するその1人のマネージャに就くように見えます。サーバ駆動のシステムには、実質的にクライアント駆動のシステムと異なったスケーリング特性があります、そして、SNMPは最も確実にサーバ(マネージャ)駆動のシステムです。 Eval--F
1.1.2 Fail-over - The document indicates the use of application level time outs to provide this mechanism, rather than the mechanism being a characteristic of the proposed protocol. The protocol provides only partial compliance with the requirement. Eval - P
1.1.2、フェイルオーバー--ドキュメントは、提案されたプロトコルの特性であるメカニズムよりむしろこのメカニズムを提供するためにアプリケーションレベルタイムアウトの使用を示します。 プロトコルは部分的な承諾だけに要件を提供します。 Eval--P
Mitton, et al. Informational [Page 28] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [28ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
1.1.3 Mutual Authentication - There is some slight handwaving here, but the protocol's USM mode should be able to support this requirement. Eval - No Change (T)
1.1.3 そこの互いのAuthenticationはそうです。或るものはここでhandwavingを侮辱しますが、プロトコルのUSMモードはこの要件をサポートすることができるべきです。 Eval--変化がありません。(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、トランスミッションLevel Security--作者はこれらの要件をサポートするためにSNMPv3モードの特定的用法について詳しく説明するべきですが、テキストは最少量で許容できます。 Eval--変化がありません。(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、データObject Confidentiality--作者は完全に条件を満たすように見えないメカニズムについて説明します。 VACMはエンドシステム(エージェント)がマネージャの特性に基づくデータへのアクセスを制御するメカニズムです。 このメカニズムはこの要件に井戸を写像するように見えません。 Eval--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、データObject Integrity--いくつかのhandwavingが、ここで先へ進みながら、あるように見えます。 一方、SNMPは、少なくとも一部SNMPの中のプロキシ仲介者概念の不足のためこの要件への良いマッチであるように見えません。 Eval--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 Transportを証明してください--ドキュメントは、コンプライアンスを示しますが、最適化が専門化しているプロトコルの使用について賛成の議論をするかもしれないことに注意します。 Eval--変化がありません。(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 Transport--ドキュメントはこの要件の正確な範囲への何らかの混乱を示します。 関連する注釈のための[2]の説明しているテキストへのevalグループ、ポイントごとに示された変更を考えて、説明しているテキストは必要ではありません。 ドキュメントは、SNMPの使用が基本的な輸送において関係ないのを示します、そして、この要件のサポートは輸送の選択に少なくとも部分的に関連します。 しかしながら、UDPの上のSNMP(SNMPのための最も一般的なモード)はこの必要条件を満たしません。 Eval--変化がありません。(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をひくのに同意している間、作者は、ある種の参照を示す必要があります。 Eval--変化がありません。(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の将来の規格化の両方を示します。 Eval--変化がありません。(p)
1.1.11 Support Proxy and Routing Brokers - The section of the document (5.5.3) that, by title, should have the discussion of SNMP proxy is marked as TBD. The section notes that the inability to completely comply with the data object confidentiality and integrity requirements might affect the compliance of this section and the evaluator agrees. Eval - F
1.1.11 サポートProxyとルート設定Brokers--ドキュメントのセクション、(5.5、.3、)、タイトルで、それはTBDとしてマークされたSNMPプロキシの議論をするべきです。 セクションは、完全にデータ・オブジェクト秘密性と保全要件に従うことができるというわけではないことがこのセクションのコンプライアンスに影響するかもしれなくて、評価者が同意することに注意します。 Eval--F
Mitton, et al. Informational [Page 29] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [29ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
1.1.12 Auditability - The document indicates no compliance with this requirement. Eval - No Change (F)
1.1.12、監査能力--ドキュメントはこの要件へのコンプライアンスを全く示しません。 Eval--変化がありません。(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 共有されたSecret Not Required--ここでのhandwavingを侮辱する、他のセキュリティー・サービスが利用可能であるなら、SNMPv3だけが必ずセキュリティー・サービスの使用を必要とするというわけではありません。 しかしながら、USMが不在のときVACMとの相互作用で、完全に説明されるというわけではなくて、良い特性はこの要件に関連しないかもしれません。 Eval--P
1.1.14 Ability to Carry Service Specific Attributes - SNMP complies via the use of MIBs. Eval - No Change (T)
1.1.14、Carry Service Specific Attributesへの能力--SNMPはMIBsの使用で応じます。 Eval--変化がありません。(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 Support--ドキュメントは、この必要条件を満たすためにMIBオブジェクトを作成できるのを示しますが、詳細を全く与えません。 Eval--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 Support--ドキュメントは、この必要条件を満たすためにMIBオブジェクトを作成できるのを示しますが、詳細を全く与えません。 普通のCHAPモデルを考えて、それはこれがちょうどどのように働くかが不明瞭です。 Eval--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 Support--ドキュメントは、特定のMIBが反対するようにEAPペイロードを運ぶことができることに注意しますが、さらなるデザインワークがEAPを完全に組み込むのに必要であることにまた注意します。 Eval--変化がありません。(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/クリアテキストPasswords--MIBの使用がクリアテキストパスワードを運ぶために反対して、それらの保護が正常なSNMPv3セキュリティー対策Evalの下で反対させるドキュメント注意--Changeがありません。(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 いくつかのhandwavingがここにある間、要求でのReauthorization、それは特定のアプリケーションがSNMPの下で「再-承認」の引き金となるように信号を生成することができるのが明確です。 Eval--変化がありません。(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、Authenticationのない承認--作者は、AAAプロトコル承認をAAAユーザ承認に間違えているように見えて、SNMPが一般的なAAAユーザ承認に対処する能力を一般化する上にいるように思えます。 Eval--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.1 静電気とDynamic IP Addr Assignment--より明確な参照も記述のないMIBオブジェクトの参照はずっとネガです。 評価者は、MIBオブジェクトがアドレスを表すことができるのに同意しますが、ドキュメントは、読者を適切な方向に少なくとも導く必要があります。 Eval--F
Mitton, et al. Informational [Page 30] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [30ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
1.3.2 RADIUS Gateway Capability - The transport and manipulation of Radius objects appears to be only a part of what is required. Eval - P
1.3.2、RADIUSゲートウェイCapability--Radiusオブジェクトの輸送と操作は必要であることに関する部分だけであるように見えます。 Eval--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 Capabilityを拒絶してください--一方、SNMPがどうこの要件を達成するかもしれないかに関する明確化は役立っているでしょう。 総合的なドキュメントは様々なアプローチをはっきりさせたかもしれないAAAの役割にSNMPのための動作理論を欠いています。 Eval--F
1.3.4 Preclude Layer 2 Tunneling - Document indicates lack of understanding of this requirement. Eval - F
1.3.4 Layer2Tunnelingを排除してください--ドキュメントはこの要件の無理解を示します。 Eval--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 Demandの上のReauth--応答コネ1.3.3が上であることを見てください。 この要件に応じるテキスト、ドキュメントのいかなる他のテキスト、および参照のどれかのいずれ、も適切なフレームワークと理論について説明しません。 Eval--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オブジェクトに参照をつけます。 これが完了した取引になる前に必要である追加工学とデザインがあります。 Eval--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 Reconciliationを述べてください--テキストは同時性でどうAAAシステムの様々な部分を得るかに関する基本的な質問を扱いません。 Eval--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、求められていないDisconnect--NASがSNMPマネージャとして務めるAAAサーバのためのSNMPエージェントであると仮定して、評価者は同意します。 Eval--変化がありません(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、本当のTime Accounting--SNMP Informsは要件を達成するかもしれません。 Eval--変化がありません。(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、義務的なCompact Encoding--これは良くて合理的な応答です。 SNMPは、特定の需要を満たすために報告されたオブジェクトのスタイルとタイプを変えることができます。 Eval--変化がありません(T)。
1.4.3 Accounting Record Extensibility - MIBs are extensible. Eval - No Change (T)
--1.4.3 Record Extensibilityを説明して、MIBsは広げることができます。 Eval--変化がありません。(T)
1.4.4 Batch Accounting - MIBs provide data collection at various times. Eval - No Change (T)
1.4.4、バッチAccounting--MIBsはいろいろな時にデータ収集を提供します。 Eval--変化がありません。(T)
1.4.5 Guaranteed Delivery - There's some weasel wording here with respect to what guaranteed means, but the description of mechanisms does appear to meet the requirements. Eval - No Change (T)
1.4.5 Deliveryは保証されました--どんな保証された手段に関して何らかのイタチ言葉遣いがここにあるか、しかし、メカニズムの記述は条件を満たすように見えます。 Eval--変化がありません。(T)
Mitton, et al. Informational [Page 31] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [31ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
1.4.6 Accounting Timestamps - Accounting records can use the DateAndTime Textual Convention to mark their times. Eval - No Change (T)
--1.4.6 Timestampsを説明して、会計帳簿は、彼らの時代をマークするのにDateAndTime Textual Conventionを使用できます。 Eval--変化がありません。(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、ダイナミックなAccounting--作者はこの要件のポイントから部分的に外れたかもしれません。 1セッションあたりの記録の数がすごくおもしろくない間、配送はおもしろいです。 作者はこの要件の深さにもう少し入るべきです。 Eval--変化がありません。(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 Registration Messagesがコード化されて、たぶんSNMPメッセージとして登録メッセージをコード化できます。 Eval--変化がありません。(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 Eval--F
1.5.3 Allocation of Local Home Agent - The author disclaims an understanding of this requirement. Eval - F
1.5.3、Localホームのエージェントの配分--作者はこの要件の理解を放棄します。 Eval--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.
ドキュメント評価スコアはSNMPのためにAAAモードで動作理論について説明したどんなドキュメント、参照またはテキストの不足でも実質的に影響を受けました。 かなりの関心において、サーバモードへの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の役割におけるSNMPs使用を損なう可能性があります。
However, SNMP may have a reasonable role in the Accounting space. SNMP appears to map well with existing technology, and with the requirements.
しかしながら、SNMPには、Accountingスペースの手頃な役割があるかもしれません。 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のできるプロトコルの一般的な必要条件を満たすように見えますが、適切な分野をすべての決められた一定の要求において役に立つようにしないかもしれません。
Mitton, et al. Informational [Page 32] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [32ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
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は使用のための認証か承認プロトコルのどちらかとしてのNOT RECOMMENDED、会計プロトコルとして使用のためのIS RECOMMENDEDです。
C.3 RADIUS+ PRO Evaluation
C.3半径+プロ評価
Evaluation of RADIUS AAA Requirements PRO Evaluation
半径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.
審判[1]は「AAAネットワークアクセス要件に対する半径の比較」Ref[2]による「RADIUS(v2)プロトコルの拡大のためのフレームワーク」Ref[3]が変更されるとして私たちによるaaa eval評価基準であるということであるということです。
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.
各セクションのために、私はグレードをセクションに示しました。 私の評価はRADIUS++に関して出された声明と異なっています。私は、以下に与えられている評価格付けがドキュメントで成文化された評価と異なるかもしれないかどうかが少しも指示なしで「AAAネットワークアクセス要件に対する半径の比較」と呼んだのを示しました。
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] スケーラビリティ--プロトコルのスケーラビリティがそうすることができるので、測定されてください、とプロトコルはかなり効率的なmanner.Soの情報を伝えるために思えます、プロトコルがそれが送っているデータに比例して過度の量の帯域幅を消費しないように見えるのでスケーラブルであるとこのプロトコルを考えることができました。 しかしながら、プロトコルには、それが終点の間でサポートすることができる同時発生のセッションの数における限界があります。 仕事aroundsは存在していて、使用中です。 Eval--P(変化がありません)
1.1.2 [b] Fail-over - The document indicates the use of application level time outs to provide this mechanism, rather than the mechanism being a characteristic of the proposed protocol. The fail-over requirement indicates that the protocol must provide the mechanism rather than the application. The implication is that the application need not be aware that the fail-over and subsequent correction when it happens. The application using the RADIUS++ protocol will be involved in fail-over recovery activities. The protocol layer of the software does not appear to have the capability built-in. Given the wording of the requirement: Eval - P (changed from T)
1.1.2、[b]フェイルオーバー--ドキュメントは、提案されたプロトコルの特性であるメカニズムよりむしろこのメカニズムを提供するためにアプリケーションレベルタイムアウトの使用を示します。 フェイルオーバー要件は、プロトコルがアプリケーションよりむしろメカニズムを提供しなければならないのを示します。 含意はアプリケーションがフェイルオーバーとそれであることのその後の修正が起こるのを意識している必要はないということです。 RADIUS++プロトコルを使用するアプリケーションはフェイルオーバー回復活動にかかわるでしょう。 ソフトウェアのプロトコル層は能力を内蔵にするように見えません。 要件の言葉遣いを与えます: Eval--P(Tから、変えます)
Mitton, et al. Informational [Page 33] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [33ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
1.1.3 [c] Mutual Authentication - The RADIUS++ protocol provides shared-secret as a built-in facility for mutual authentication. The authors of the document suggest the use of IPSec to obtain mutual authentication functions. The RADIUS++ protocol provides no road blocks to obtaining mutual authentication between instances of AAA applications, however the protocol provides no facilities for doing so.
1.1.3、[c]の互いのAuthentication--+ + プロトコルが互いの認証のための内蔵の施設として共有秘密キーを供給するRADIUS。 ドキュメントの作者は、互いの認証機能を得るためにIPSecの使用を勧めます。 + + プロトコルがAAAアプリケーションのインスタンスの間に互いの認証を得ることへの道路阻絶を全く供給しないRADIUS、しかしながら、プロトコルは施設を全くそうするのに提供しません。
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]トランスミッションLevel Security--+ + プロトコルがトランスミッションを全く供給しないRADIUSはセキュリティ機能を平らにして、それは、トランスミッションレベルセキュリティを得るためにIPSecの使用を排除しません。 Eval--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]データObject Confidentiality--ドキュメントは+ + メッセージが暗号化されたRADIUSメッセージ(属性)が同封されるかもしれない封筒としてサーバに設計したRAIDUSについて説明します。 Eval--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]データObject Integrity--目に見える署名を使用して、RADIUS++プロトコルはこの必要条件を満たすように見えます。 Eval--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] Transportを証明してください--ドキュメントはCMS-データRadius Attribute(メッセージ)の使用でコンプライアンスを示します。 Eval--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 Transport--ドキュメントは、Layer2Tunnelingプロトコルで増大するとRADIUS++缶が信頼できる輸送であると考えられると指摘します。 プロトコル自体は信頼性の機能を提供しません。 信頼性はアプリケーションか増大プロトコルの責任のままで残っています。 Eval--P(変化がありません)
1.1.9 [i] Run over IPv4 - Eval - T (no change)
1.1.9 [i] IPv4--Eval--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 Addressデータ型を定義しなければなりません。 Eval--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] Proxyとルート設定Brokersをサポートしてください--要求を別ルートで送るためのメカニズムが全くありませんが、そうするのを拡大をすることができます。 Eval--T(変化がありません)
1.1.12 [l] Auditability - The document indicates no compliance with this requirement. Eval - F (no change)
1.1.12、[l]監査能力--ドキュメントはこの要件へのコンプライアンスを全く示しません。 Eval--F(変化がありません)
1.1.13 [m] Shared Secret Not Required - RADIUS++ can be configured to run with empty shared secret values. Eval - T (no change)
1.1.13 [m]はSecret Not Requiredを共有しました--空の状態で稼働している場合+ +を構成できるRADIUSは秘密の値を共有しました。 Eval--T(変化がありません)
Mitton, et al. Informational [Page 34] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [34ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
1.1.14 [n] Ability to Carry Service Specific Attributes - Vendor escape mechanism can be used for this purpose.. Eval - T (no change)
1.1.14、Carry Service Specific Attributesへの[n]能力--このためにベンダー逃避機制を使用できます。 Eval--T(変化がありません)
1.2 Authentication Requirements
1.2 認証要件
1.2.1 [a] NAI Support - Eval - T (no change)
1.2.1 [a] NAIサポート--Eval--T(変化がありません)
1.2.2 [b] CHAP Support - Subject to dictionary attacks. Eval - P (changed from T)
1.2.2 辞書を条件とした[b]CHAP Supportは攻撃します。 Eval--P(Tから、変えます)
1.2.3 [c] EAP Support - Eval - T (no change)
1.2.3 [c] EAPサポート--Eval--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/クリアテキストPasswordsセキュリティ、しかし、カプセル化の可能性はプロトコルの現在のパラダイムの中に存在しています。 - 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]Reauthentication--RADIUSプロトコルは再認証をサポートします。 再認証がユーザかAAAのクライアントによって開始されるといけないので、AAAのクライアントは新しい認証要求を送ることができます。 訪問されるかホームAAAサーバから挑戦メッセージをAAAのクライアントに送ることによって、再認証を開始できます。 Eval--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] RADIUS++がAw/oA Evalをサポートするのを可能にするためにA新しいメッセージタイプを創造できるというAuthenticationのない承認、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]静電気とDynamic IP Addr Assignment--ともにサポートされます。 IPv6は新しいアドレスデータ型の定義を必要とするでしょう。 Eval--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ゲートウェイCapability--RADIUSオブジェクトの輸送と操作は必要であることに関する部分だけであるように見えます。 要件はRADIUSを排除するために言い表されるように思えます。 Eval--P(Tから、変えます)
1.3.3 [c] Reject Capability - Eval -T
1.3.3 [c]廃棄物能力--Eval-T
1.3.4 [d] Preclude Layer 2 Tunneling - I do not see a definition in the AAA eval criteria document. Eval - ?
1.3.4 [d] Layer2Tunnelingを排除してください--私はAAA eval評価基準ドキュメントの定義を見ません。 Eval--、--
Mitton, et al. Informational [Page 35] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [35ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
1.3.5 [e] Reauthorization on Demand - Implementation in the field demonstrate that extensions to RADIUS can support the desired behavior. Re-authentication is currently coupled to re- authorization. Eval - P (no change)
1.3.5、Demandの上の[e]Reauthorization--その分野の実装は、RADIUSへの拡大が望まれた行動をサポートすることができるのを示します。 再認証は現在、再承認と結合されます。 Eval--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エンドの後ろでアプリケーションでするのが指す、プロトコルの中で。 + +が対処するために追加メッセージタイプを定義できたRADIUSは新しいサービスエリアの中でアクセスコントロールを広げました。 Eval--P(変化がありません)
1.3.7 [g] State Reconciliation - Eval - F (no change)
1.3.7 [g] 州の和解--Eval--F(変化がありません)
1.3.8 [h] Unsolicited Disconnect - RADIUS++ extensions to support. Eval - T. (no change)
1.3.8、[h]の求められていないDisconnect--サポートするRADIUS++拡張子。 Eval--T。(変化がありません)
1.4 Accounting Requirements
1.4 会計要件
1.4.1 [a] Real Time Accounting - Eval - T (no change)
1.4.1 [a]リアルタイムで会計--Eval--T(変化がありません)
1.4.2 [b] Mandatory Compact Encoding - Eval - T (no change)
1.4.2 [b] 義務的なコンパクトなコード化--Eval--T(変化がありません)
1.4.3 [c] Accounting Record Extensibility - Eval - T (no change)
1.4.3 [c] 会計帳簿伸展性--Eval--T(変化がありません)
1.4.4 [d] Batch Accounting - RADIUS++ offers no new features to support batch accounting. Eval - F No change)
1.4.4、[d]バッチAccounting--サポートする+ +が新機能を全くバッチ会計を提供しないRADIUS。 Evalに、Fノー、が変化する、)
1.4.5 [e] Guaranteed Delivery - Retransmission algorithm employed. Eval - T (no change)
1.4.5 [e]は荷渡しを保証しました--使われた再送信アルゴリズム。 Eval--T(変化がありません)
1.4.6 [f] Accounting Timestamps - RADIUS++ extensions support timestamps. Eval - T (no change)
--1.4.6 [f] Timestampsを説明して、RADIUS++拡張子はタイムスタンプをサポートします。 Eval--T(変化がありません)
1.4.7 [g] Dynamic Accounting - RADIUS++ extensions to support. Eval - T (no change)
1.4.7、[g]のダイナミックなAccounting--サポートするRADIUS++拡張子。 Eval--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 Registration Messagesがコード化されて、RADIUS++拡張子に不透明なペイロードとして登録メッセージを含ませることができます。 Eval--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]ファイアウォールFriendly--RADIUSがプロキシとして務めるファイアウォールがアクティブであるところで環境で操作上であることが知られています。 Eval--T(変化がありません)
1.5.3 [c] Allocation of Local Home Agent -Requirement statement needs some clarification and refinement. Eval - F (no change)
1.5.3 [c] Localホームエージェント要件声明の配分は何らかの明確化と気品を必要とします。 Eval--F(変化がありません)
Mitton, et al. Informational [Page 36] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [36ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
2. Summary Discussion
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 Network Access要件で完全に対応するというわけではありません。 しかしながら、中に記載されているように条件を満たすために現在の手順を広げる小さい取り組みがある状態で、それは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.
それとしてのRADIUS++による開発されて、他のプロトコルが獲得できない後方の互換性のレベルを提供するだろうということであるかもしれません。 上にリストアップされたドキュメント、既存のRADIUSベースのインストールからRADIUSまでの変遷で述べられた簡単な方法でRADIUSを広げることによって、+ + インストールは、より簡単でしょう。 会計は他のアプローチよりずっと弱いのですが、プロトコルはAuthorizationとAuthenticationの領域に継続的な使用のための強い競争者のままで残っています。
C.4 RADIUS+ CON Evaluation
C.4半径+まやかし評価
Evaluation of RADIUS++ (sic) AAA Requirements CON Evaluation Evaluator - David Nelson
半径++(原文のまま)AAA要件の評価は評価評価者をだまします--デヴィッド・ネルソン
Ref [1] is "Comparison of RADIUS Against AAA Network Access Requirements", a.k.a. 'the document' Ref [2] is "Framework for the extension of the RADIUS(v2) protocol", a.k.a. 'the protocol' Ref [3] is the AAA evaluation criteria as modified by us. Ref [4] is RFC 2869. Ref [5] is an expired work in progress "RADIUS X.509 Certificate Extensions". Ref [6] is RFC 2868
審判[1]が「AAAネットワークアクセス要件に対する半径の比較」、通称'ドキュメント'Ref[2]が「RADIUS(v2)プロトコルの拡大のためのフレームワーク」であるということである、通称'プロトコル'Ref[3]は変更されるとして私たちによるAAA評価基準です。 審判[4]はRFC2869です。 審判[5]は進歩「RADIUS X.509証明書拡張子」で満期の仕事です。 審判[6]はRFC2868です。
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]から明確であり、それは[1]の短いcomingsが現在[2]で扱われるので特定された問題のいくつかです。 評価者は、これらの例外に注目するのを試みました。(そこでは、それらが起こります)。
Mitton, et al. Informational [Page 37] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [37ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
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]の「何万もの同時の要求」言語を重んじて推奨しない部分的なコンプライアンスを示します。 独身のAAAのクライアントからの同時の要求の問題は[1]で扱われます、よく知られているテクニックを使用する周りで256の唯一身元保証可能な傑出している要求の見かけの制限が働くことができるのを示して、要求のソースUDPポートナンバーなどのように。 ドキュメントは「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、互いのAuthentication--ドキュメント[1]は、互いの認証がAccess-リクエスト・パケットのUser-パスワードかCHAPパスワード属性かどんなパケットのMessage固有識別文字[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 トランスミッションLevel Security--[3]で定義されるトランスミッション層のセキュリティがプロトコルに提供されるのを示して、メカニズムを使用するとセクション1.1で.3に説明されたドキュメント[1] この要件が現在[3]のSHOULDであることに注意されるべきです。 ドキュメントは「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、データObject Confidentiality--ドキュメント[1]は、終わりから終わりへの秘密性がRADIUSで利用可能でないことを示しますが、それを加えることができたと言い続けます。 プロトコル[2]は実際にセクション4.3.2でこれをすることになっている方法を指定する試みを.2に[2]でします、CMS-データ属性を使用して、主にRFC2630に基づきます。 評価者はこのとき、RFC2630の適用性をAAA仕事に調査していません。 ドキュメントは「F」を要求しますが、プロトコル[2]の詳細の観点から、評価者は「P」を与えます。
Mitton, et al. Informational [Page 38] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [38ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
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、データObject Integrity--ドキュメント[1]は、終わりへの終わりの保全がRADIUSで利用可能でないことを示しますが、それを加えることができたと言い続けます。 プロトコル[2]は実際にセクション4.3.2でこれをすることになっている方法を指定する試みを.1に[2]でします、CMS-データ属性を使用して、主にRFC2630に基づきます。 評価者はこのとき、RFC2630の適用性を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 Transportを証明してください--ドキュメント[1]は、証明書輸送がRADIUSで利用可能でないことを示しますが、それを加えることができたと言い続けます。 プロトコル[2]は実際にセクション4.3.2でこれをすることになっている方法を指定する試みを.3に[2]でします、CMS-データ属性を使用して、主にRFC2630に基づきます。 評価者はこのとき、RFC2630の適用性を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 Transport--ドキュメント[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をひいてください--RADIUSはIPv4の上で広く配布されます。 ドキュメントは「T」を要求します、そして、評価者は同意します。
1.1.10 Run over IPv6 - The document [1] indicates that adoption of a limited number of new RADIUS attributes to support IPv6 is straightforward. Such discussion has transpired on the RADIUS WG mailing list, although that WG is in the process of shutting down. The document claims "P", and the evaluator concurs.
1.1.10 IPv6をひいてください--ドキュメント[1]は、IPv6をサポートする限られた数の新しいRADIUS属性の採用が簡単であることを示します。 停止することの途中にそのWGはありますが、そのような議論はRADIUS WGメーリングリストで蒸散しました。 ドキュメントは「P」を要求します、そして、評価者は同意します。
1.1.11 Support Proxy and Routing Brokers - The document [1] indicates that RADIUS is widely deployed in proxy-chains of RADIUS servers. This is equivalent to the Proxy Broker case, but the Routing Broker case is a different requirement. The protocol [2] does not describe any detail of how a Routing Broker might be accommodated, although it opens the door by indicating that the RADIUS++ protocol is peer-to- peer, rather than client/server. The document claims "P", and the evaluator awards "F".
1.1.11 Proxyとルート設定Brokersをサポートしてください--ドキュメント[1]は、RADIUSがRADIUSサーバのプロキシチェーンで広く配布されるのを示します。 これはProxy Brokerケースに同等ですが、ルート設定Brokerケースは異なった要件です。 プロトコル[2]はルート設定Brokerがどう設備されるかもしれないかに関する少しの詳細についても説明しません、RADIUS++プロトコルがクライアント/サーバドキュメント請求項「P」、および評価者賞「F」よりむしろ同輩から同輩であることを示すことによって、ドアを開けますが。
Mitton, et al. Informational [Page 39] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [39ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
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 共有されました。Secret Not Required--ドキュメント[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、Carry Service Specific Attributesへの能力--RADIUSにはよく定義されたVendor特有のAttributeがあります。(適切に使用されると、本当に、Attributeはサービス特有の属性を輸送する能力に備えます)。 ドキュメントは「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 Support--ドキュメント[1]は、RADIUSがUser-名前属性のための提案された形式の1つとしてNAIを指定するのを示します。 ドキュメントは「T」を要求します、そして、評価者は同意します。
1.2.2 CHAP Support - CHAP support is widely deployed in RADIUS. The document claims [1] "T", and the evaluator concurs.
1.2.2、CHAP Support--CHAPサポートはRADIUSで広く配布されます。 ドキュメントは、[1]が「T」であると主張します、そして、評価者は同意します。
1.2.3 EAP Support - The document [1] indicates that EAP support in RADIUS is specified in [4]. The document claims [1] "T", and the evaluator concurs.
1.2.3、EAP Support--ドキュメント[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/クリアテキストPasswords--ドキュメント[1]は、RADIUSがホップごとのベースにおけるクリアテキストパスワードの保護を提供するのを示します。 プロトコル[2]は秘密性が得られたコネセクション4.3.2が.2であったならそうするかもしれないCMS-データ属性を使用して、多大におけるベースの[2]の追加データがRFC2630でどう離れているかを示します。 評価者はこのとき、RFC2630の適用性をAAA仕事に調査していません。 ドキュメントは、[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、オンデマンドのReauthentication--ドキュメント[1]は、RADIUSがサーバからクライアントに送られたAccess-挑戦メッセージによってオンデマンドの再認証を実行するかもしれないのを示します。 評価者は、Access受け入れているメッセージがクライアントによっていったん受け取られるとこれが与えられたセッションの間働きそうであるのは意見を異にします。 ドキュメントは、「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
1.2.6、Authenticationのない承認--プロトコル仕様に適用されるような非必要な認証資格証明書がない命令が承認を求める要求で必要であるというこの要件。 承認を提供する実際の決定
Mitton, et al. Informational [Page 40] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [40ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
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.
どんな認証の欠如もアプリケーション(例えば、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 静電気とDynamic IP Addr Assignment--ドキュメント[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ゲートウェイCapability--ドキュメント[1]は、RADIUSゲートウェイへのRADIUS++がほとんどa同語反復であると主張します。 ドキュメントは「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 Capabilityを拒絶してください--ドキュメント[1]は、RADIUS Proxyサーバ、および潜在的にRADIUS++ルート設定Brokersにはローカルの方針に基づく要求を拒絶する能力があると主張します。 ドキュメント請求項「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 Layer2Tunnelingを排除してください--ドキュメント[1]は、[6]がRADIUSでトンネルを堀る層twoのサポートを定義するのを示します。 ドキュメントは「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、Demandの上のReauth--ドキュメント[1]は、RADIUSがSession-タイムアウトとTermination動作属性によってこの特徴を提供するのを示します。 事実上、これが周期的な再承認を提供するために十分であるかもしれない間、それはオンデマンドの再承認を提供しないでしょう。 プロトコル[2]はさらにこれを扱いません。 ドキュメントは、「P」、および評価者賞が「F」であると主張します。
1.3.6 Support for ACLs - The document [1] describes the attributes in RADIUS that are used to convey the access controls described in [3]. Certain of these (e.g. QoS) are not currently defined in RADIUS, but could easily be defined as new RADIUS attributes. The document claims "P", and the evaluator concurs.
1.3.6、ACLsのサポート--ドキュメント[1]は[3]で説明されたアクセス制御を伝えるのに使用されるRADIUSで属性について説明します。 RADIUSで定義されて、容易に新しいRADIUS属性と定義できて、現在、これら(例えば、QoS)が確かであるのは、そうではありません。 ドキュメントは「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
1.3.7 Reconciliationを述べてください--ドキュメント[1]はそれぞれのサブ項目を扱います、オリジナルのAAA要件ドキュメントに記載されているように。 [3]の変更された要件に対してドキュメントを再検討するのにおいて、サーバで開始している州の和解メッセージには問題がまだあります。 サーバが詳しく述べられなかったプロトコル対話を開始できるとき、プロトコル[2]はそのようなメッセージに備えますが
Mitton, et al. Informational [Page 41] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [41ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
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".
メッセージ・フォーマットを提供します。 これはRADIUSについて伝統的に短い来ることであった領域です。 ドキュメントは、「P」、および評価者賞が「F」であると主張します。
1.3.8 Unsolicited Disconnect - Much of the discussion from the previous section applies to this section. The document [1] claims "F", and the evaluator concurs.
1.3.8、求められていないDisconnect--前項からの議論の多くがこのセクションに適用されます。 ドキュメント[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、本当のTime Accounting--RADIUS Accountingは広く配布されて、リアルタイムでの[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、義務的なCompact Encoding--RADIUS Accountingは関連課金情報のためのTLVsを含んでいます。それはそれぞれかなりコンパクトです。 [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 Record Extensibilityを説明して、RADIUS Accountingは、新しい属性によるVendor特有の属性を使用することによって、広げられるかもしれません。 必要な拡張能力には、既存の属性数のスペースが小さ過ぎると主張されましたが、プロトコル[2]はセクション3.0のこの問題、およびその[2]の小区分を扱います。 ドキュメント[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、バッチ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 Deliveryは保証されました--RADIUS Accountingは必要なアプリケーションレベル承認の文脈の中で広く配布されて、保証された配送を提供します。 ドキュメント[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 Timestampsを説明して、ドキュメント[1]は、この特徴がEvent-タイムスタンプ属性として[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、ダイナミックなAccounting--ドキュメント[1]は、この必要条件が[4]の指定されるとしての説明している当座のアップデートメッセージを使用することで部分的に満たされるのを示します。 さらに、仕事が[4]に含まれていないセッション会計延期に関するRADIUS WGにありました、すなわち、或るものは執筆中の作品を吐き出しました。 ドキュメントは、[1]が「P」であると主張します、そして、評価者は同意します。
Mitton, et al. Informational [Page 42] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [42ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
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 Registration Messagesがコード化されて、[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、ファイアウォールFriendly--ドキュメント[1]は、RADIUS展開が炎から壁で囲まれた環境で起こったのを知ることであることを示します。 ドキュメントは「T」を要求します、そして、評価者は同意します。
1.5.3 Allocation of Local Home Agent - The document [1] claims "F", and the evaluator concurs.
1.5.3、Localホームのエージェントの配分--ドキュメント[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]は短い時間枠に書かれているのに苦しみます。 他の関連ドキュメントを引用して、プロトコルはある問題で特定の指導を提供しますが、それはつやが出ているプロトコル仕様ではありません、詳細なパケット・フォーマットダイヤグラムで。RADIUSを「改良する」試みにおけるRADIUS WGの中の進行中の作品が議定書を作るので仮定されて、+ + プロトコルが描くかもしれないRADIUSであり、多くのでDiameterの概念が1番目であった先の仕事のプールがあります。 しかしながら、これらの執筆中の作品のすべてが以来、長い間、期限が切れています。
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の現在の事実上の、そして、法律上の規格であるので。 長い地位の欠乏がRADIUSにあります。(RADIUSはRADIUSとNASREQ WG議事によく記録されました)。 これらの問題を解決するためにRADIUSを改造するのは技術的に可能です。しかしながら、行われる1つの質問は以下の通りです。 「どんな著しい違いに、完成RADIUSの間には、+ + プロトコルとDiameterプロトコルがあるでしょうか?」?
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.
一部推薦されます。 ことによるとこの服従から学習されるかもしれないことはDiameterによりRADIUS対応することのRADIUS-互換性モードを持っているのが可能であるということです。
Mitton, et al. Informational [Page 43] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [43ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
C.5 Diameter PRO Evaluation
C.5直径プロ評価
Evaluation of Diameter against the AAA Requirements PRO Evaluation Evaluator - Basavaraj Patil
AAAの要件プロ評価評価者に対する直径の評価--Basavarajパティル
Ref [1] is "Diameter Framework Document". Ref [2] is "Diameter NASREQ Extensions". Ref [3] is the AAA evaluation criteria as modified by us. Ref [4] is "Diameter Accounting Extensions". Ref [5] is "Diameter Mobile IP Extensions". Ref [6] is "Diameter Base Protocol". Ref [7] is "Diameter Strong Security Extension". Ref [8] is "Comparison of Diameter Against AAA Network Access Requirements".
審判[1]は「直径フレームワークドキュメント」です。 審判[2]は「直径NASREQ拡張子」です。 審判[3]は変更されるとして私たちによるAAA評価基準です。 審判[4]は「直径会計拡大」です。 審判[5]は「直径のモバイルIP拡大」です。 審判[6]は「直径基地のプロトコル」です。 審判[7]は「直径の強いセキュリティ拡大」です。 審判[8]は「AAAネットワークアクセス要件に対する直径の比較」です。
The document uses T to indicate total compliance, P to indicate partial compliance and F to indicate no compliance.
ドキュメントは、コンプライアンスを全く示さないように完全順守を示す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
評価者の注意: 以下を除いて、Diameter承諾ドキュメント[8]は、Total「T」がすべての要件への承諾であると主張します。 - 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.
直径は、RADIUSの発展であり、RADIUSが使用中であることの何年間もにわたっても学習されたすべてのレッスンを考慮に入れました。 トランスポート・プロトコルとしてのSCTPの使用は複数のプロキシサーバの必要性を減少させます。(アプリケーションレベルacksの必要性を取り除くことと同様に[1])の秒3.1の.1Proxy Support。 推進と再直接のブローカーの使用とサポートはスケーラビリティを高めます。 評価者はこの要件で「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の使用で、Diameterはそれが代替のサーバに切り替わる分離指摘を検出できます。(秒4.0の[6])。 また、RequestsとResponsesは同じ経路に続く必要はありません、そして、これは信頼性を増強します。 評価者はこの要件で「T」コンプライアンスに同意します。
Mitton, et al. Informational [Page 44] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [44ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
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.
承諾ドキュメントは左右対称の変換のクライアントとサーバの間の互いの認証の使用を引用します。(秒7.1の[6])。 基本的なセキュリティー対策としての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はこれがDiameterでどう達成されるかに関する詳細を明らかにします。 評価者はこの要件で「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.
この要件はDiameterから来たように思えます。 審判[7]は、データ・オブジェクト秘密性を達成するために詳細にCryptographic Message Syntax(CMS)の使用について説明します。 CMS-データ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.
プロトコルにおける上の同じ議論とホップごとのセキュリティ機能を使用して、この必要条件はDiameterによって完全に満たされます。 評価者はこの要件で「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.
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.
1.1.8 Reliable AAA Transport
1.1.8 Reliable AAA Transport
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.
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.
Mitton, et al. Informational [Page 45] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 45] RFC 3127 AAA Protocol Evaluation Process June 2001
1.1.9 Run over IPv4
1.1.9 Run over 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.
Is an application layer protocol and does not depend on the underlying version of IP. Evaluator concurs with the "T" compliance on this requirement.
1.1.10 Run over IPv6
1.1.10 Run over 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.
Is an application layer protocol and does not depend on the underlying version of IP. Evaluator concurs with the "T" compliance on this requirement.
1.1.11 Support Proxy and Routing Brokers
1.1.11 Support Proxy and Routing Brokers
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.
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.
1.1.12 Auditability
1.1.12 Auditability
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.
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.
1.1.13 Shared Secret Not Required
1.1.13 Shared Secret Not Required
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.
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.
1.1.14 Ability to Carry Service Specific Attributes
1.1.14 Ability to Carry Service Specific Attributes
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.
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.
Mitton, et al. Informational [Page 46] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 46] RFC 3127 AAA Protocol Evaluation Process June 2001
1.2 Authentication Requirements
1.2 Authentication Requirements
1.2.1 NAI Support
1.2.1 NAI Support
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.
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.
1.2.2 CHAP Support
1.2.2 CHAP Support
Reference [2] section 3.0 describes the support for CHAP. Evaluator concurs with the "T" compliance on this requirement.
Reference [2] section 3.0 describes the support for CHAP. Evaluator concurs with the "T" compliance on this requirement.
1.2.3 EAP Support
1.2.3 EAP Support
Reference [2] section 4.0 describes the support for EAP. Evaluator concurs with the "T" compliance on this requirement.
Reference [2] section 4.0 describes the support for EAP. Evaluator concurs with the "T" compliance on this requirement.
1.2.4 PAP/Clear-text Passwords
1.2.4 PAP/Clear-text Passwords
Reference [2] section 3.1.1.1 describes the support for PAP. Evaluator concurs with the "T" compliance on this requirement.
Reference [2] section 3.1.1.1 describes the support for PAP. Evaluator concurs with the "T" compliance on this requirement.
1.2.5 Reauthentication on demand
1.2.5 Reauthentication on demand
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.
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.
Evaluator deprecates the compliance on this to a "P"
Evaluator deprecates the compliance on this to a "P"
Note: However this is a trivial issue.
Note: However this is a trivial issue.
1.2.6 Authorization w/o Authentication
1.2.6 Authorization w/o Authentication
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.
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.
Mitton, et al. Informational [Page 47] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 47] RFC 3127 AAA Protocol Evaluation Process June 2001
1.3 Authorization Requirements
1.3 Authorization Requirements
1.3.1 Static and Dynamic IP Addr Assignment
1.3.1 Static and Dynamic IP Addr Assignment
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.
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.
1.3.2 RADIUS Gateway Capability
1.3.2 RADIUS Gateway Capability
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.
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.3.3 Reject Capability
1.3.3 Reject Capability
Based on the explanation provided in the compliance document for this requirement evaluator concurs with the "T" compliance on this requirement.
Based on the explanation provided in the compliance document for this requirement evaluator concurs with the "T" compliance on this requirement.
1.3.4 Preclude Layer 2 Tunneling
1.3.4 Preclude Layer 2 Tunneling
Ref [2] defines AVPs supporting L2 tunnels Evaluator concurs with the "T" compliance on this requirement.
Ref [2] defines AVPs supporting L2 tunnels Evaluator concurs with the "T" compliance on this requirement.
1.3.5 Reauth on Demand
1.3.5 Reauth on Demand
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.
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.
1.3.6 Support for ACLs
1.3.6 Support for 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.
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.
1.3.7 State Reconciliation
1.3.7 State Reconciliation
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.
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.
Mitton, et al. Informational [Page 48] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 48] RFC 3127 AAA Protocol Evaluation Process June 2001
1.3.8 Unsolicited Disconnect
1.3.8 Unsolicited Disconnect
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.
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.
1.4 Accounting Requirements
1.4 Accounting Requirements
1.4.1 Real Time Accounting
1.4.1 Real Time Accounting
Evaluator concurs with the "T" compliance based on explanations in [4].
Evaluator concurs with the "T" compliance based on explanations in [4].
1.4.2 Mandatory Compact Encoding
1.4.2 Mandatory Compact Encoding
Use of Accounting Data Interchange Format (ADIF)-Record-AVP for compact encoding of accounting data. Evaluator concurs with the "T" compliance.
Use of Accounting Data Interchange Format (ADIF)-Record-AVP for compact encoding of accounting data. Evaluator concurs with the "T" compliance.
1.4.3 Accounting Record Extensibility
1.4.3 Accounting Record Extensibility
ADIF can be extended. Evaluator concurs with the "T" compliance.
ADIF can be extended. Evaluator concurs with the "T" compliance.
1.4.4 Batch Accounting
1.4.4 Batch Accounting
Sec 1.2 of [4] provides support for batch accounting.
Sec 1.2 of [4] provides support for batch accounting.
1.4.5 Guaranteed Delivery
1.4.5 Guaranteed Delivery
Sections 2.1/2 of [4] describe messages that are used to guarantee delivery of accounting records. Evaluator concurs with the "T" compliance.
Sections 2.1/2 of [4] describe messages that are used to guarantee delivery of accounting records. Evaluator concurs with the "T" compliance.
1.4.6 Accounting Timestamps
1.4.6 Accounting Timestamps
Timestamp AVP [6] is present in all accounting messages. Evaluator concurs with the "T" compliance.
Timestamp AVP [6] is present in all accounting messages. Evaluator concurs with the "T" compliance.
1.4.7 Dynamic Accounting
1.4.7 Dynamic Accounting
Interim accounting records equivalent to a call-in-progress can be sent periodically. Evaluator concurs with the "T" compliance.
Interim accounting records equivalent to a call-in-progress can be sent periodically. Evaluator concurs with the "T" compliance.
Mitton, et al. Informational [Page 49] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 49] RFC 3127 AAA Protocol Evaluation Process June 2001
1.5 MOBILE IP Requirements
1.5 MOBILE IP Requirements
1.5.1 Encoding of MOBILE IP Registration Messages
1.5.1 Encoding of MOBILE IP Registration Messages
Ref [5] provides details of how Diameter can encode MIP messages. Evaluator concurs with the "T" compliance.
Ref [5] provides details of how Diameter can encode MIP messages. Evaluator concurs with the "T" compliance.
1.5.2 Firewall Friendly
1.5.2 Firewall Friendly
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"
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"
1.5.3 Allocation of Local Home Agent
1.5.3 Allocation of Local Home Agent
Diameter can assign a local home agent in a visited network in conjunction with the FA in that network. Evaluator concurs with the "T"
Diameter can assign a local home agent in a visited network in conjunction with the FA in that network. Evaluator concurs with the "T"
Summary Recommendation
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.
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.
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.
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.
C.6 Diameter CON Evaluation
C.6 Diameter CON Evaluation
Evaluation of Diameter against the AAA Requirements CON Brief Evaluator: Barney Wolff
Evaluation of Diameter against the AAA Requirements CON Brief Evaluator: Barney Wolff
Mitton, et al. Informational [Page 50] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 50] RFC 3127 AAA Protocol Evaluation Process June 2001
Section 1 - Per item discussion
Section 1 - Per item discussion
1.1 General Requirements
1.1 General Requirements
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 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.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 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.
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.
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.
1.1.3 Mutual Authentication - T
1.1.3 Mutual Authentication - T
1.1.4 Transmission Level Security - T
1.1.4 Transmission Level Security - 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 Data Object Confidentiality - P (was T). Yes, the CMS data type is supported. But the work in progress, "Diameter Strong Security Extension", says:
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.
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.
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.
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.
Mitton, et al. Informational [Page 51] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 51] RFC 3127 AAA Protocol Evaluation Process June 2001
1.1.6 Data Object Integrity - P (was T). See above.
1.1.6 Data Object Integrity - P (was T). See above.
1.1.7 Certificate Transport - T
1.1.7 Certificate Transport - T
1.1.8 Reliable AAA Transport - T
1.1.8 Reliable AAA Transport - T
1.1.9 Run over IPv4 - T
1.1.9 Run over IPv4 - T
1.1.10 Run over IPv6 - T
1.1.10 Run over IPv6 - T
1.1.11 Support Proxy and Routing Brokers - T
1.1.11 Support Proxy and Routing Brokers - T
1.1.12 Auditability - T (based on our interpretation as non- repudiation, rather than the definition given in reqts)
1.1.12 Auditability - T (based on our interpretation as non- repudiation, rather than the definition given in reqts)
1.1.13 Shared Secret Not Required - T
1.1.13 Shared Secret Not Required - T
1.1.14 Ability to Carry Service Specific Attributes - T
1.1.14 Ability to Carry Service Specific Attributes - T
1.2 Authentication Requirements
1.2 Authentication Requirements
1.2.1 NAI Support - T
1.2.1 NAI Support - T
1.2.2 CHAP Support - T
1.2.2 CHAP Support - T
1.2.3 EAP Support - T
1.2.3 EAP Support - T
1.2.4 PAP/Clear-text Passwords - T
1.2.4 PAP/Clear-text Passwords - 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 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.6 Authorization w/o Authentication - T
1.2.6 Authorization w/o Authentication - T
1.3 Authorization Requirements
1.3 Authorization Requirements
1.3.1 Static and Dynamic IP Addr Assignment - T
1.3.1 Static and Dynamic IP Addr Assignment - 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 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.3 Reject Capability - T (The evaluator fails to understand how any AAA protocol could rate anything other than T on this.)
1.3.3 Reject Capability - T (The evaluator fails to understand how any AAA protocol could rate anything other than T on this.)
Mitton, et al. Informational [Page 52] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 52] RFC 3127 AAA Protocol Evaluation Process June 2001
1.3.4 Preclude Layer 2 Tunneling - T
1.3.4 Preclude Layer 2 Tunneling - 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 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.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 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.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 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.8 Unsolicited Disconnect - T
1.3.8 Unsolicited Disconnect - T
1.4 Accounting Requirements
1.4 Accounting Requirements
1.4.1 Real Time Accounting - T
1.4.1 Real Time Accounting - T
1.4.2 Mandatory Compact Encoding - T
1.4.2 Mandatory Compact Encoding - T
1.4.3 Accounting Record Extensibility - T
1.4.3 Accounting Record Extensibility - 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 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.5 Guaranteed Delivery - T
1.4.5 Guaranteed Delivery - 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 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.7 Dynamic Accounting - T
1.4.7 Dynamic Accounting - T
1.5 MOBILE IP Requirements
1.5 MOBILE IP Requirements
1.5.1 Encoding of MOBILE IP Registration Messages - T
1.5.1 Encoding of MOBILE IP Registration Messages - 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
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
Mitton, et al. Informational [Page 53] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 53] RFC 3127 AAA Protocol Evaluation Process June 2001
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.
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.3 Allocation of Local Home Agent - T
1.5.3 Allocation of Local Home Agent - T
2. Summary Discussion
2. Summary Discussion
In some areas, Diameter is not completely thought through. In general, real effort has gone into satisfying a stupendous range of requirements.
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. General Requirements
Diameter certainly fails the KISS test. With SCTP, the drafts add up to 382 pages - well over double the size of RADIUS even with extensions. The evaluator sympathizes with the political instinct when faced with a new requirement no matter how bizarre, to say "we can do that" and add another piece of filigree. But the major places where Diameter claims advantage over RADIUS, namely "end-to-end" confidentiality and resource management, are just the places where some hard work remains, if the problems are not indeed intractable.
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.
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.
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.
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.
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.
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.
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.
Mitton, et al. Informational [Page 54] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 54] RFC 3127 AAA Protocol Evaluation Process June 2001
4. Summary Recommendation
4. Summary Recommendation
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.
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.
C.7 COPS PRO Evaluation
C.7 COPS PRO Evaluation
Evaluation of COPS AAA Requirements PRO Evaluation Evaluator - David Nelson
Evaluation of COPS AAA Requirements PRO Evaluation Evaluator - David Nelson
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] 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.
This document uses T to indicate total compliance, P to indicate partial compliance and F to indicate no compliance.
This document uses T to indicate total compliance, P to indicate partial compliance and F to indicate no compliance.
Section 1 - Per item discussion
Section 1 - Per item discussion
1.1 General Requirements
1.1 General Requirements
1.1.1 Scalability - The document [1] claims "T", and the evaluator concurs.
1.1.1 Scalability - The document [1] claims "T", and the evaluator concurs.
1.1.2 Fail-over - The document [1] claims "T", and the evaluator concurs.
1.1.2 Fail-over - The document [1] claims "T", and the evaluator concurs.
1.1.3 Mutual Authentication - The document claims "T", and the evaluator concurs.
1.1.3 Mutual Authentication - The document claims "T", and the evaluator concurs.
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 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.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 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.
Mitton, et al. Informational [Page 55] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 55] RFC 3127 AAA Protocol Evaluation Process June 2001
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 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.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 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.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 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.9 Run over IPv4 - The document [1] claims "T", and the evaluator concurs.
1.1.9 Run over IPv4 - The document [1] claims "T", and the evaluator concurs.
1.1.10 Run over IPv6 - The document [1] claims "T", and the evaluator concurs.
1.1.10 Run over IPv6 - The document [1] claims "T", and the evaluator concurs.
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 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.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 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.13 Shared Secret Not Required - The document [1] claims "T" and the evaluator concurs.
1.1.13 Shared Secret Not Required - The document [1] claims "T" and the evaluator concurs.
1.1.14 Ability to Carry Service Specific Attributes - The document [1] claims "T", and the evaluator concurs.
1.1.14 Ability to Carry Service Specific Attributes - The document [1] claims "T", and the evaluator concurs.
1.2 Authentication Requirements
1.2 Authentication Requirements
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 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.2 CHAP Support - The document [1] claims "T", and the evaluator concurs.
1.2.2 CHAP Support - The document [1] claims "T", and the evaluator concurs.
Mitton, et al. Informational [Page 56] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 56] RFC 3127 AAA Protocol Evaluation Process June 2001
1.2.3 EAP Support - The document [1] claims "T", and the evaluator concurs.
1.2.3 EAP Support - The document [1] claims "T", and the evaluator concurs.
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 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.5 Reauthentication on demand - The document [1] claims "T", and the evaluator concurs.
1.2.5 Reauthentication on demand - The document [1] claims "T", and the evaluator concurs.
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 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.3 Authorization Requirements
1.3 Authorization Requirements
1.3.1 Static and Dynamic IP Addr Assignment - The document [1] claims "T", and the evaluator concurs.
1.3.1 Static and Dynamic IP Addr Assignment - The document [1] claims "T", and the evaluator concurs.
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 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.3 Reject Capability - The document claims [1] "T" and the evaluator concurs.
1.3.3 Reject Capability - The document claims [1] "T" and the evaluator concurs.
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 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.5 Reauth on Demand - The document [1] claims "T", and the evaluator concurs.
1.3.5 Reauth on Demand - The document [1] claims "T", and the evaluator concurs.
1.3.6 Support for ACLs - The document [1] "T", and the evaluator concurs.
1.3.6 Support for ACLs - The document [1] "T", and the evaluator concurs.
1.3.7 State Reconciliation - The document [1] "T", and the evaluator concurs.
1.3.7 State Reconciliation - The document [1] "T", and the evaluator concurs.
1.3.8 Unsolicited Disconnect - The document [1] claims "T", and the evaluator concurs.
1.3.8 Unsolicited Disconnect - The document [1] claims "T", and the evaluator concurs.
Mitton, et al. Informational [Page 57] RFC 3127 AAA Protocol Evaluation Process June 2001
Mitton, et al. Informational [Page 57] RFC 3127 AAA Protocol Evaluation Process June 2001
1.4 Accounting Requirements
1.4 Accounting Requirements
1.4.1 Real Time Accounting - The document [1] claims "T", and the evaluator concurs.
1.4.1 Real Time Accounting - The document [1] claims "T", and the evaluator concurs.
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 Mandatory Compact Encoding - Note that the term "bloated" in [3] is somewhat subjective. The document [1] claims "T", and the evaluator concurs.
1.4.3 Accounting Record Extensibility - The document [1] claims "T", and the evaluator concurs.
--1.4.3 Record Extensibilityを説明して、[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、バッチAccounting--[5]がどれくらい詳細にこの特徴を扱わないプロトコル[2]は達成されるかもしれません。 ドキュメント[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 保証されたDelivery--荷渡しを保証するのはTCPによって提供されます。 ドキュメント[1]は「T」を要求します、そして、評価者は同意します。
1.4.6 Accounting Timestamps - The document [1] claims "T", and the evaluator concurs.
--1.4.6 Timestampsを説明して、[1]が「T」と、評価者であると主張するドキュメントは同意します。
1.4.7 Dynamic Accounting - The document [1] claims "T", and the evaluator concurs.
1.4.7、ダイナミックなAccounting--ドキュメント[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 Registration Messagesがコード化されて、[1]が「T」と、評価者であると主張するドキュメントは同意します。
1.5.2 Firewall Friendly - The document [1] claims "T", and the evaluator concurs.
1.5.2、ファイアウォールFriendly--ドキュメント[1]は「T」を要求して、評価者は同意します。
1.5.3 Allocation of Local Home Agent - The document [1] claims "T", and the evaluator concurs.
1.5.3、Localホームのエージェントの配分--ドキュメント[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
新規検査のときに評価者がドキュメント[1]の承諾主張に鑑識眼を与えていないように見えるかもしれません。 まず最初に、このメモは疑問の簡潔で、そういうものとして手頃な利益がプロトコル提案を支持して与えられることになっている「プロ」です。 2番目に、基本的な概念的な問題がプレーにあります。 COPS-PRモデルは、さまざまなネットワークとリソースが管理プロトコルであるとサポートすることができるように基本的な操作と十分なコマンド、statefulモデル、どちらかの「同輩」が、ある種類の要求を開始する能力、および広げることができるコマンドセットを提供します。 特定のメッセージが残されるプロトコルの詳細
Mitton, et al. Informational [Page 58] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [58ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
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.
方針Information基地(PIB)のデータ・オブジェクト。 AAA PIBが全く書かれていないので、吸収器は(楽観的に)ベースプロトコルが[3]の意図している要件を達成する固有の能力を評価できるだけです、AAA PIBが似るかもしれないことに関する妥当な仮定を考えて。
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]はこのデータモデルの利益を列挙して、説明して、Object Oriented(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は[3]の要件のすべてに会うように(完全にか部分的に)見えるでしょう、AAA PIBの利益なしで少なくとも決定できるように。
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に書いて、詳細を評価しなければならないでしょう。
C.8 COPS CON Evaluation
C.8巡査は評価をだまします。
Evaluation of COPS against the AAA Requirements CON Evaluation Evaluator - David Mitton
AAAの要件まやかし評価評価者に対する巡査の評価--デヴィッド・ミットン
The Primary document discussed here is [COPSComp] and the arguments therein based on the proposal [COPSAAA].
ここで議論したPrimaryドキュメントは、そこに提案[COPSAAA]に基づいた[COPSComp]と議論です。
[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要件に対する巡査の比較」、処理中の作業。 [COPSAAA]は仕事進行中で「AAAのために用法を獲得します」。 [EksteinProtoComp]、「AAAプロトコル:」 「半径と、直径と、巡査での比較」、処理中の作業。
Mitton, et al. Informational [Page 59] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [59ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
References: (in order of relevancy)
参照: (関連の順に)
[COPSBase] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R.
and A. Sastry, "The Common Open Policy Service Protocol",
RFC 2748, January 2000.
[COPSBase] ダラムとD.とボイルとJ.とコーエンとR.とハーツォグとS.とRajanとR.とA.Sastry、「一般的なオープンポリシーサービスプロトコル」、RFC2748、2000年1月。
[COPSFwork] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework
for Policy-based Admission Control", RFC 2753, January
2000.
[COPSFwork] YavatkarとR.とPendarakisとD.とR.ゲラン、「方針ベースの入場コントロールのためのフレームワーク」、RFC2753、2000年1月。
[COPSPR] "COPS Usage for Policy Provisioning", Work in Progress.
[COPSPR]は仕事進行中で「方針の食糧を供給する用法を獲得します」。
[COPSSPPI] "Structure of Policy Provisioning Information (SPPI)",
Work in Progress.
[COPSSPPI] 「方針の構造は情報(SPPI)に食糧を供給し」て、進行中で働いてください。
[COPSCMS] "COPS Over CMS", Work in Progress.
[COPSCMS] 「cmの上の巡査」は進行中で働いています。
[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 ExtensionはAuthentication Supportを基礎づけた」ProgressのWork。
Other COPS & RSVP RFCs & drafts not listed as not directly relevant.
他のCOPS&RSVP RFCsと草稿は直接関連しないとして記載しませんでした。
Compliance: T==Total, P==Partial, F=Failed
承諾: T=合計、部分的なP=F=は失敗しました。
Section 1 - Per item discussion
項目議論あたりのセクション1
Initial Note: [COPSComp] claims "unconditional compliance" with all requirements.
注意に頭文字をつけてください: [COPSComp]はすべての要件への「無条件の承諾」を要求します。
1.1 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.
P(Tであった)COPSは同輩失敗のしるしを与えて、再開状態にメカニズムを持っていますが、偏見はあるようにただ一つの州のサーバに向かって思えます。1.1.2、フェイルオーバー--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タイマの思うままのそれの理由です。 アプリケーションに報告する接続タイムアウトはクライアント認証タイムアウトを超えて遅れるかもしれません。 生きているKeepメッセージをよりきつい期間に調整すると、セッションとシステムオーバーヘッドは増強されるでしょう。
Mitton, et al. Informational [Page 60] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [60ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
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 互いのAuthentication--P、(Tでした) 説明はちょっとメッセージオブジェクト保全のためのものです。 それは認証のテクニックについて説明しません。 評価者は、COPS同輩がClient-オープンタイムに互いを認証すると仮定します。 しかし、プロキシがかかわるならこれがどのように働くかを理解できません。
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 データObject Confidentiality--ほとんどaカーボンコピーのT Seems Diameter、能力。 この評価者はCMS能力のためのDiameter評価者の高い頭上の関心を反響します。 TLSはここに言及されませんが、より遅いところで積み重ねられます。
1.1.6 Data Object Integrity - T See above.
1.1.6、データObject Integrity--上のT See。
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 Transport--T(多分P)COPSは私たちが評価したいかなる他のプロトコルと同様にこの必要条件を満たします。 すなわち、それは1つのアプリケーションのレベルACKを持っています。 「TCPは保証された配送を提供などなど」の声明が不正確です。 COPSは、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 Proxyとルート設定Brokersをサポートしてください--クライアントタイプが前方にサポートされるP(Tであった)はこの評価者によく解釈されません。 それぞれのクライアントタイプは、Brokerが異なったクライアントオープンにそれのものに上流のサーバを要求させるのを必要としますか? ルーティングブローカーはどうですか?
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でした) (reqtsで与えられた定義よりむしろ非拒否として私たちの解釈に基づいています) 歴史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 共有されたSecret Not Required--T Except、[COPSAAA]6.2 14ページのこの節、「COPS MUST、TLSをサポートすることができてください、」
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-
a) COPSは少ない数のユニークなオブジェクトを加えさせるだけです。 256オブジェクトは、「属する」か、または256の血液型亜型かバージョンでタイプされます。 長い間、クライアントタイプは高いビットが「企業」特定の値を示すところの16ビットです。 しかし、COPS同輩に関係してください。
Mitton, et al. Informational [Page 61] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [61ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
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.
接続セッション。 クライアントタイプは、メッセージのためにただ情報モデルを特定するように思えます。例えばそれはAAAのための1つの値に固定されるでしょう。
b) Service specific objects are not the same as Vendor Specific
Objects. They pertain to objects within a client type.
b) サービスの特定のオブジェクトはVendor Specific Objectsと同じではありません。 彼らはクライアントタイプの中でオブジェクトに関係します。
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 Support--RFC2459(X.509プロフィール)が会われるという要件が、そのAuthサーバがマッピングか地方にしないと推定するt、変換。
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 An情報Model(私は本当にどこでも太るのを見ない)は呼び出されています。 [COPSAAA]は、少しのhandwavingと定義をしますが、たくさんの肉を提供しません。 それにもかかわらず、これは扱われたala RADIUSであるかもしれません。
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 Support--再び実在しない情報ModelがあるP(Tでした)。 EAPをするために、この評価者は、別のRequestかDecisionタイプが拡張交換処理が進行しているのをプロキシに示すのにここで必要であると考えます。
1.2.4 PAP/Clear-text Passwords - T
1.2.4 乳首/クリアテキストパスワード--T
1.2.5 Reauthentication on demand - T
1.2.5 オンデマンドのReauthentication--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.1 静的でダイナミックなIP Addr課題--T
Mitton, et al. Informational [Page 62] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [62ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
1.3.2 RADIUS Gateway Capability - P (was T). It would be interesting to see RADIUS attributes wrapped in some COPS "Information Model".
1.3.2、半径ゲートウェイ能力--P(Tでした)。 RADIUS属性がいくつかのCOPS「情報モデル」で包装されるのを見るのはおもしろいでしょう。
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 オンデマンドのReauthorization--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 Access Rules&Filtersのサポート--P(Tであった)にもかかわらず、RADIUSとDiameterデザイナーについて暗示したいくつかのデザイン問題を含む「情報モデル」作者にとっての、より多くの仕事 Diameterで少なくとも試みるのをしました。 何もここにありません。
1.3.7 State Reconciliation - P (was T). It is difficult for the evaluator to understand how well the COPS mechanisms work in a multi-administration situation, or in any proxy situation. Multi- server coordination, if allowed, seems to be lacking a description.
1.3.7 和解を述べてください--P(Tでした)。 評価者が、COPSメカニズムがマルチ管理状況、または何かプロキシ状況でどれくらいよく働くかを理解しているのは、難しいです。 許容されているなら、マルチサーバコーディネートは記述を欠いているように思えます。
1.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、義務的なCompact Encoding--T This評価者は、ADIFがコンパクトな形式であると信じていません。 情報Model作者はこの要件を満たす会計統計があるデザインa 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を定義して、Record Extensibilityを説明すること。
1.4.4 Batch Accounting - P (was T) Offered description does not seem to match the requirement.
1.4.4、バッチAccounting--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 Deliveryは保証されました--P(Tであった)TCPはどんな「保証配送」もしないで、アプリケーションだけAcksはそれができます。 ここでの記述と同様の状態でこれらのacksを生成することができるなら、この必要条件は満たされます。
Mitton, et al. Informational [Page 63] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [63ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
1.4.6 Accounting Timestamps - T Another item for the "Information Model" author.
1.4.6、会計Timestamps--「情報モデル」作者のためのT Anotherの品目。
1.4.7 Dynamic Accounting - T Event and interim accounting can be supported.
1.4.7、ダイナミックなAccounting--T Eventと当座の会計をサポートできます。
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 Registration Messagesがコード化されて、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、ファイアウォールFriendly--P(Tであった)I推測。 それはTCPを使用して、知られている接続ポートで特定できるので。 しかし、一般的なファイアウォールポートを通り抜ける複雑なCOPSトラフィックの影響レベルに関して問題があります。
1.5.3 Allocation of Local Home Agent - P (was T) Just add another element to that "Information Model" definition.
1.5.3、Localホームのエージェントの配分--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.
COPSは、RSVPとDiffServeのために小さくて容易に会われたセットのデザイン目標と共に始めて、他の釘[COPSPR]を打つために新しいハンマーとして発展しています。 COPS作成者が、より操作上の経験を得るとき、フィックス/特徴がすばやくパッチされるのに得るより多くの信頼性を見るのはおもしろいです。
Understanding COPS requires that you read a number RFCs and drafts which do not readily integrate well together. Each application of COPS has spawned a number of drafts. It's not clear if one wants to or can implement a single COPS server that can service AAA and other application clients.
COPSを理解しているのは、あなたが容易によく一緒に統合されないRFCsと草稿を数に読み込むのを必要とします。 COPSの各アプリケーションは多くの草稿を生じさせました。 1つがそうしたいか、またはAAAにサービスを提供できるただ一つのCOPSサーバと他のアプリケーションクライアントを実装することができるかが、明確ではありません。
The COPS authors seem to overly believe in the goodness of TCP, and rely on it to solve all their transport problems, with concessions to application keep-alive messages to probe the connection status and sequence numbers to prevent replay attacks. This evaluator believes this type of approach may work for many networks but really doesn't
作者がTCPの善良をひどく信じて、彼らのすべての輸送問題を解決するためにそれを当てにするために思えるCOPSはアプリケーションへの譲歩で反射攻撃を防ぐために接続形態と一連番号を調べるメッセージを生かします。 この評価者は、しかし、このタイプのアプローチが本当に多くのネットワークで扱うかもしれないと信じています。
Mitton, et al. Informational [Page 64] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [64ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
scale well in larger configurations. End-to-end application acks are the only guaranteed delivery solution, particularly where distributed state is involved.
上手により大きい構成を計量してください。 終わりからエンドへのアプリケーションacksは特に分散状態がかかわるところの唯一の保証された配送対策です。
COPS falls into an in between place on encoding. It has small number of simple data object blobs which are concatenated ala RADIUS/Diameter TLVs to form a flexible message layout. However, they attempt to limit the number of objects by making them arbitrarily complex ala SNMP MIBs, and defining yet another data structuring language for these PIBs. There is a lot of computer science style grandstanding in [COPSAAA] Section 1.2, but no translation into how a set of data objects can be used to meet these wonderful features in operation. (or even if we needed them) This will be the crux of the interoperability issue. RADIUS implementations interoperate because they at least, understand a common set of functional attributes from the RFCs. And vendor extent ions can be simply customized in as needed via dictionaries. If PIB definitions are needed for every piece and version of access equipment, before you can use it, then the bar for ease of configuration and use has been raised quite high.
間のコネへの落下がコード化であることに置くCOPS。 それには、フレキシブルなメッセージレイアウトを形成する連結されたala RADIUS/直径TLVsである少ない数の簡単なデータ・オブジェクト一滴があります。 しかしながら、彼らは、それらを任意に複雑なala SNMP MIBsにして、これらのPIBsのために言語を構造化するさらに別のデータを定義することによってオブジェクトの数を制限するのを試みます。 [COPSAAA]セクション1.2でスタンドプレーする多くのコンピュータサイエンススタイルがありますが、稼働中であるこれらの素晴らしい特徴を満たすのにどう1セットのデータ・オブジェクトを使用できるかへのどんな翻訳もありません。 (私たちがそれらを必要としたとしても) これは相互運用性問題の要所になるでしょう。 RADIUS実装が共同利用する、それら、少なくとも、RFCsから一般的な機能的属性を理解してください。 必要に応じて辞書で単にイオンをカスタム設計できるベンダー範囲。 あなたがそれを使用できる前に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統合として同次にあって、Diameterの想定された複雑さの面目をつぶすでしょう。
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プロトコルとして機能させることができる構造があります、恐らくただRADIUSとDiameterの特徴をそれにコピーすることによって。 [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サービスがある相乗作用のいくつかが魅力的である間、この評価者はただ一つのサーバ実体における新しい現れているCOPSアプリケーションによるAAAサービスが導入する結合の負債に関して必要とされるより多くの複雑さと進歩を持つ機会が他のネズミの通る穴に入ったことを心配しています。 (例えば、方針フレームワーク)
Mitton, et al. Informational [Page 65] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [65ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
Appendix D - Meeting Notes
付録D--ミーティング注意
The minutes of the team meetings as recorded by various members.
様々なメンバーによる記録されるとしてのチーム会議の議事録。
D.1 Minutes of 22-Jun-2000 Teleconference
D.1分の2000年6月22日電子会議
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.
SNMPを支持したAAAプロトコルとしてのSNMPに対する議論を与えました。 スチュアート・バークリーはプロ議論の概要をしました。 マイク通りジョーンズはまやかし議論の概要をしました。 デーヴ・ネルソンは、取り組みにおける「陪審への指示」がどんな証拠は使用できて、決定をする際に使用できなかったかを決定するように頼みました。
The AAA evaluation criteria is weak in some areas and in others it appears to be written with what might be interpreted as undue influence from the NASREQ working group.
AAA評価基準はいくつかの領域で弱いです、そして、他のものでは、それは不当威圧としてNASREQワーキンググループから解釈されるかもしれないもので書かれているように見えます。
Mike St. Johns offered that we must restrict ourselves to considering only the evidence provided in the compliance documents and any supporting documents to which they may refer.
証拠だけを考える場合私たちが自分達を制限しなければならない提供されたマイク通りジョーンズはそれらが参照する承諾ドキュメントとどんなサポートドキュメントにも供給しました。
In summary: AAA evaluation criteria document, AAA evaluation criteria source documents, protocol response documents and reference documents.
概要で: AAA評価基準ドキュメント(AAA評価基準ソースドキュメント)は応答ドキュメントと参考書類について議定書の中で述べます。
The question as to what the group should do with malformed requirements came up. The consensus seemed to be that we would use the requirements as adjusted in our last meeting where the requirements made no sense.
グループが奇形の要件でするべきであることに関する質問は上りました。 コンセンサスは私たちが要件が意味をなさなかった私たちの前回のミーティングで調整されるように要件を使用するだろうということであるように思えました。
The floor was then given to Stuart Barkley for the pro SNMP argument.
そして、プロSNMP議論のためにスチュアート・バークリーに床を与えました。
Highlights:
ハイライト:
* In most areas the requirements are met by SNMP.
* Confidentiality and Certificate transport mechanisms may be weak,
but workable.
* With regard to Authentication, every technique can be supported
although support for PAP or cleartext passwords is weak.
* With regard to Authorization, there is nothing in the requirements
that cannot be supported.
* Accounting everything supported, although there is no specific
consideration for compact encoding. SNMP not as bloated as ASCII
or XML based encoding schemes. Requirement for compact encoding
weakly indicated in requirements anyway. Server-specific
attributes needed, but compact encoding preclude w/o tradeoffs.
* ほとんどの領域では、必要条件がSNMPによって満たされます。 * 秘密性とCertificate移送機構は、弱いのですが、実行可能であるかもしれません。 * Authenticationに関して、PAPかcleartextパスワードのサポートは弱いのですが、あらゆるテクニックをサポートできます。 * Authorizationに関して、サポートすることができない要件には何もありません。 * コンパクトなコード化のためのどんな特定の考慮もありませんが、サポートされたすべてを説明します。 ASCIIかXMLがコード化を基礎づけたほどむくんでいないSNMPは計画します。 要件でとにかく弱々しく示されたコンパクトなコード化のための要件。 必要な、しかし、コンパクトなコード化が見返りなしで排除するサーバ特有の属性。
Mitton, et al. Informational [Page 66] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [66ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
* 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は確かに会計スペースで役割を果たすことができましたが、それはAuthorizationとAuthenticationの領域で使用不可能です。 * 応答ドキュメントは問題がどう解決されるかを扱いません。 * それは、スケーラビリティがマネージャ兼エージェント運転モードからクライアントサーバモデルまでの変遷で起こるかもしれない問題であると扱いません。
The group then examined each requirement against SNMP in a line-by- line exercise.
そして、グループはSNMPに対してaで系列運動に立ち並んでいて各要件を調べました。
Mitton, et al. Informational [Page 67] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [67ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
D.2 Minutes of 27-Jun-2000 Teleconference
D.2分の2000年6月27日電子会議
Attendees - All (Mike St. John, Dave Mitton, Dave Nelson, Mark Stevens, Barney Wolff, Stuart Barkley, Steven Crain, Basavaraj Patil)
出席者--すべて(マイク・セント・ジョン、デーヴ・ミットン、デーヴ・ネルソン、マーク・スティーブンス、Barneyヴォルフ、スチュアート・バークリー、スティーブン・クレイン、Basavarajパティル)
Minutes recorded by : Basavaraj Patil
数分は記録しました: Basavarajパティル
Evaluation of RADIUS++ AAA Requirements
半径++AAA要件の評価
Pro : Mark Stevens Con : Dave Nelson
プロ: マーク・スティーブンスCon: デーヴ・ネルソン
- 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.
- デーヴ・ネルソンは、パットCalhounがAAA WGメーリングリストで評価チームによる要件ドキュメントにされた変更に応じたと言及しました。 パットの応答はevalチームによって削除されたいくつかの要件の包含のための議論を含んでいます。
- Mike concluded that we can reinstate these requirements after
reviewing Pat's comments in detail and the RFCs referenced. The
intent is to take Pat's comments/document and review it between
now and next Thursday (July 6th) and integrate the comments based
on the findings at that time.
- マイクは、詳細なパットのコメントと参照をつけられるRFCsを見直した後に私たちがこれらの要件を復職させることができると結論を下しました。 意図は、パットのコメント/ドキュメントを取って、現在の間と、そして、次の木曜日(7月6日)にそれを見直して、その時調査結果に基づくコメントを統合することです。
Voting Procedure for evaluation : No voting during the discussion. All votes MUST be submitted to Mike by COB, June 28th, 00.
評価のための票のProcedure: 議論の間の票でない。 COBは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.
- RADIUS++ 評価者が承諾声明と意見を異にするポイントの概要のためのCon声明のデーヴ・ネルソンの概要。
Conclusion from Dave : Not recommended (Details in the con
statement).
デーヴからの結論: お勧めではありません(まやかし声明の詳細)。
Q: Is it possible to use it for accounting?
A: Authentication and Authorization could be separated, but
Accounting is the weak link in this protocol and hence is not
suitable.
Q: 会計にそれを使用するのは可能ですか? A: 認証とAuthorizationを切り離すことができましたが、Accountingはこのプロトコルの弱いリンクであり、したがって、適当ではありません。
- 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
- 観測の大部分がデーヴ・ネルソンによって作られている状態で、Pro声明Agreedのスティーブンの概要にマークしてください。 それに行く最も大きいものはしばらくこの環境へ駆け込んでいて、必要条件の大部分を満たすということです。
Mitton, et al. Informational [Page 68] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [68ページ]情報のRFC3127AAAプロトコル評価プロセス2001年6月
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.
予備選挙、2番目、および第三のためのプロキシが存在する環境と氾濫の可能な影響の議論はフェイルオーバー検出の場合、通信します。
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.
セキュリティを近く跳ぶほど飛び越すために要件ドキュメントでタグを変える提案。
Mitton, et al. Informational [Page 69] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [69ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
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.
マイクはCryptographic Message Syntax(CMS--RFC2630)の概念について説明しました。 CMS終わることの使用に関する問題が指す何かがあります。 左右対称であるかAsymmetricキーを使用できます。
There does not seem to be a problem with the suggested usage of CMS in RADIUS++.
CMSの提案された使用法に関する問題はRADIUS++であるように思えません。
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--半径は、応用層で「再-トランスミッション」をすることによって、信頼性を提供します。 それで、信頼できる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
IPv4/6の上を走った1.1.9/10
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.
- この要件を支持するためにRADIUSを広げることができます、そして、承諾ドキュメントから、これはまだ完全に料理されているように見えません。
1.1.12 Auditability
1.1.12 監査能力
No Discussion
議論がありません。
Mitton, et al. Informational [Page 70] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [70ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
1.1.13 Shared Secret Not Required
1.1.13 共有秘密キーは必要ではありません。
This seems to be a trivial issue to be addressed in RADIUS++.
これはRADIUS++に記述されるべき些細な問題であるように思えます。
1.1.14 Ability to carry Service Specific Attributes
1.1.14 Service Specific Attributesを運ぶ能力
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/4EAP/乳首
No Discussion
議論がありません。
1.2.5 Reauthentication on Demand
1.2.5 オンデマンドのReauthentication
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--サーバはAccess-挑戦を発行するのによるreauthenticateをそうすることができるというクレームを記録してください。 州のマシンへの変化があります、そして、提案された解決法は安易過ぎます。 後方にも、互換性は問題でしょう。
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 静電気とDynamic 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 半径ゲートウェイ能力
This is a requirement written that is not applicable to RADIUS itself.
これは書かれたRADIUS自身に適切でない要件です。
Mitton, et al. Informational [Page 71] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [71ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
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にあります。 また、RADIUS WGはこの(コメント)について議論しています。 ここの考えはphonecallの進行中のタイプに関するメッセージの同等物を送ることであることができます。
Mobile IP Requirements:
モバイルIP要件:
1.5.1 Encoding of Mobile IP Reg. Messages
1.5.1 モバイルIPレッジメッセージのコード化
May be trivial. Discussion on what this requirement really is. Is it just the ability to carry the reg. message as payload? Does the AAA protocol have to delve into the reg. message and behave differently.
些細であるかもしれません。 議論この要件が本当に何であるかを。 それはただregを運ぶ能力ですか?ペイロードとして、通信してくれますか? AAAプロトコルは、異なって. メッセージをregに探究して、振る舞わなければなりませんか?
Mitton, et al. Informational [Page 72] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [72ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
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.
私が何か誤解されたものとしてここに記録したことに気付くなら、遠慮なく修正をしてください。
D.3 Minutes of 29-Jun-2000 Teleconference
D.3分の2000年6月29日電子会議
Attendees: Mike St. John, Dave Mitton, Dave Nelson, Barney Wolff, Stuart Barkley, Steven Crain, Basavaraj Patil. Missing: Mark Stevens.
出席者: マイク・セント・ジョン、デーヴ・ミットン、デーヴ・ネルソン、Barneyヴォルフ、スチュアート・バークリー、スティーブン・クレイン、Basavarajパティル。 取り逃がします: マーク・スティーブンス。
Minutes recorded by: Stuart Barkley
数分は記録しました: スチュアート・バークリー
Evaluation of Diameter AAA Requirements
直径AAA要件の評価
Advocates:
支持者:
Pro: Basavaraj Patil Con: Barney Wolff
プロ: BasavarajパティルCon: バーニー・ヴォルフ
Summary discussion:
概要議論:
PRO summary (Basavaraj Patil):
PRO概要(Basavarajパティル):
session based
lightweight base + extensions
has implementation experience
based upon radius
fixes specific problems with radius,
interoperates with radius
looks like requirements are written for diameter
実現がベースの軽量のベース+拡大で経験するセッションは、半径で特定の問題を半径フィックスに基礎づけて、要件が直径のために書かれているように半径面相で共同利用します。
CON summary (Barney Wolff):
CON概要(Barneyヴォルフ):
meets most needs, designed with requirements in mind
要件で念頭に設計されたほとんどの需要を満たします。
issues: scalability in small devices (strong crypto specifically)
問題: 小さい装置のスケーラビリティ(強い暗号、明確に)
failover (need guidance on failover recovery procedures)
フェイルオーバー(フェイルオーバーリカバリ手順における必要性指導)
Mitton, et al. Informational [Page 73] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [73ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
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提案に従って?)アプリケーション対輸送acksのサポート必要性分離にほとんどすべての拡大を必要とします。
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
議論がありません。
Mitton, et al. Informational [Page 74] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [74ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
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の暗号はいつ暗号One Time Passwordsを使用するかに関する知識を必要とします。
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
IPv4/6の上を走った1.1.9/10
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 Service Specific Attributesを運ぶ能力
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/4EAP/乳首
No Discussion
議論がありません。
Mitton, et al. Informational [Page 75] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [75ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
1.2.5 Reauthentication on Demand
1.2.5 オンデマンドのReauthentication
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 静電気とDynamic IP Addr課題
No Discussion
議論がありません。
1.3.2 RADIUS Gateway Capability
1.3.2 半径ゲートウェイ能力
Protocol requirement or implementation/application requirement?
Which RADIUS versions are to be supported? Which subset?
プロトコル要件ですかそれとも実現/アプリケーション要件ですか? どのRADIUSバージョンが支持されることですか? どの部分集合?
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、要求に応じて、Reauthorizeします。
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
サーバが制限More議論が必要とした時間和解Simultaneous用法で州のJustを返すために「世界について質問しなければならない」ので弱いように見えます。
Mitton, et al. Informational [Page 76] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [76ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
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)
わずかなバッチのための直径承認。 仕様は大きいバッチ転送に適当に思えません。(10万+記録)
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レッジメッセージのコード化
Taken of faith
信頼について取ります。
1.5.2 Firewall Friendly
1.5.2 ファイアウォール好意的です。
Issues with SCTP being supported initially through firewalls
初めはファイアウォールを通して支持されるSCTPの問題
Mitton, et al. Informational [Page 77] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [77ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
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.
日曜日に平らになるのにおいてDiameterの票があるべきです。 同じことは従来と同様フォーマットします。 マイクは大多数と平均した票の両方として計算するでしょう。
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.
ADsに従って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.
余分な数日を必要とするとレポートがグループの編集とレビューの必要性のため終わる可能性。 わずかな時間が拡大の可能性であると考えるようにADsに頼むマイク。
"No discussion" means that the topic was mentioned but there we no objections/issues raised on that requirement being met.
「議論がありません」が、しかし、話題がそこに言及されたことを意味する、私たち、問題は満たされるその必要条件で反論/提起されませんでした。
These are based upon my notes. Please send any corrections to the list.
これらは私の注意に基づいています。 あらゆる修正をリストに送ってください。
D.4 Minutes of 06-Jul-2000 Teleconference
D.4分の2000年7月6日電子会議
Minutes of AAA-Team Telecon 7/6/00 By: Barney Wolff
7/6/00の以下によるAAAチームテレコンの議事録 バーニー・ヴォルフ
Pro review of COPS - Dave Nelson
COPSのプロレビュー--デーヴ・ネルソン
Likes the object model.
No apparent showstoppers.
Will resend review with typos corrected.
オブジェクト・モデルは好きです。 見かけの名役者がありません。 誤植が修正されている状態で、レビューを再送するでしょう。
Mitton, et al. Informational [Page 78] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [78ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
Con review of COPS - Dave Mitton
COPSのレビューをだましてください--デーヴ・ミットン
Architecture is mostly there.
Strong dependency on info model, sceptical of object model.
Problem with info model in multi-vendor, multi-administration
environment.
How does server speak to multiple client flavors?
Will resend review with typos corrected.
構造がほとんどそこにあります。 オブジェクト・モデルで疑い深いインフォメーションモデルにおける強い依存。 マルチベンダのインフォメーションモデル、マルチ管理環境に関する問題。 サーバはどのように複数のクライアント風味に話しますか? 誤植が修正されている状態で、レビューを再送するでしょう。
Comment by Mike StJ "replace SNMP with COPS" - :) I think.
マイクStJによるコメントは「SNMPを巡査に取り替えます」--、:、) 私は考えます。
Per-Item discussion
1項目あたりの議論
1.1.1 Scalability - concern re always-on TCP. Direction to DM - add general issue of number of connections.
1.1.1 スケーラビリティ--reのいつもオンな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 熱いバックアップの、しかし、すべてのプロトコルに関して本当のフェイルオーバー--ノー。 (ie(即座に引き継ぐことができたように同時性におけるバックアップサーバを保つかもしれないサーバサーバプロトコルの明白な言及がありません))
1.1.3 Mutual Authentication - perhaps relies on TLS. Draft does not otherwise support this.
1.1.3、互いのAuthentication--恐らく、TLSを当てにします。 そうでなければ、草稿はこれを支持しません。
1.1.8 Reliable AAA Transport - TCP + appl heartbeat.
1.1.8、信頼できるAAA Transport--TCP+appl鼓動。
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 プロキシとルート設定Brokers--プロキシとのクライアントタイプ相互作用は疑わしいです。 (後の議論では、クライアントタイプが要求で分野であり、恐らくすべてのAAAが1つのタイプであるように見えて、問題もそうです。)
1.1.13 Shared secret not req'd - runs over TLS, no multiple levels of security.
1.1.13 どんな共有秘密キーreqもそうしないでしょう--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 RFC2459(X.509プロフィール)のこれへの影響に関する何らかの不確実性--何らかの方法でNAIを制限するかもしれないというNAI Support
1.2.3 EAP Support - multi-pass handshake needs work.
1.2.3、EAP Support--マルチパス握手の必要性は働いています。
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、Authenticationのない認可--要件が壊れているというマイクコメント。 BWコメント(ポストを満たす)--Access-要求におけるUser名を必要として、ある種のパスワードのために特にRADIUSを制裁することを意図して、あらかじめ接続していた状態で発信したとしても、要件は例えば、DNISを受け取り次第現れます。 確実に、愚かですが、それは本当に属性が欠けているか、または「なにもに」いっぱいにされる状態で重要ですか? これは、だれかの部分の上のRADIUS、imhoを不当に攻撃しながら、ただ不快でした。
1.3.2 RADIUS Gateway - skepticism was expressed.
1.3.2、RADIUSゲートウェイ--懐疑は述べられました。
Mitton, et al. Informational [Page 79] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [79ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
1.3.4 Preclude L2 Tunnels - too much handwaving.
1.3.4 L2Tunnelsを排除してください--あまりに多くのhandwaving。
1.3.6 Access Rules - lots of work needed.
1.3.6 Rulesにアクセスしてください--必要である仕事のロット。
1.3.7 State Reconciliation - multi-server coordination is an issue.
1.3.7 Reconciliationを述べてください--マルチサーバコーディネートは問題です。
1.4.4 Batch Accounting - for small batches, perhaps.
1.4.4 わずかなバッチのための恐らくバッチAccounting。
1.4.5 Guaranteed Delivery - application acks are an area of mystery.
1.4.5 Deliveryは保証されました--アプリケーションacksは神秘の領域です。
1.5.2 Firewall-Friendly - COPS like any Swiss-Army-Knife protocol (SNMP) requires the firewall to look inside the packets, because passing AAA may be allowed but not other protocol uses. So it would be a big help, for both COPS and SNMP, to define a different port for its AAA application.
1.5.2 ファイアウォール味方--スイスアーミーナイフのプロトコルの同様のいずれも(SNMP)が、ファイアウォールがパケットの中で見るのを必要とするCOPS、AAAを通過するのが許容されていますが、別に許されるかもしれないというわけではないので、用途について議定書の中で述べてください。 そのように、それ、COPSとSNMPの両方のための大きい助けでしょうAAAアプリケーションのために異なったポートを定義するために。
D.5 Minutes of 11-Jul-2000 Teleconference
D.5分の2000年7月11日電子会議
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とRADIUS++が「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を評価しました。 CMSの適用性に関して、NASesと他のエッジデバイスのために、質問しますか? 物の秘密性による物のための要件があります。3パーティーのシナリオを考えてください。
Mitton, et al. Informational [Page 80] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [80ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
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 服従ドキュメントのこのセクションが「t.b.d.」を示したので、SNMPは「F」を受けました。 直径はこの項目を完全に記述する唯一のプロトコル提案でした。
1.1.12 We treated this requirement as "non-repudiation". There is a concern that digital signatures are computationally expensive and are not globally available. COPS has more work to do on this item.
1.1.12 私たちは「非拒否」としてこの要件を扱いました。 デジタル署名が計算上高価であり、グローバルに利用可能でないという関心があります。 COPSには、この項目でしなければならないより多くの仕事があります。
1.1.13 Question that "no shared secrets" should be interpreted to mean that an alternative key management mechanism is available? We treated this as meaning that application-layer security could be turned off in deference to transport layer security. There had been discussion of the use of IKE in the AAA protocol.
1.1.13 「共有秘密キーがありません」が代替のかぎ管理メカニズムが利用可能であることを意味するために解釈されるべきであるという問題? トランスポート層セキュリティを重んじて応用層セキュリティをオフにすることができたことを意味するとして私たちはこれを扱いました。 AAAプロトコルにおけるIKEの使用の議論がありました。
1.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.
Itによる注意されて、すべてそんなに明瞭なパスワードがNASのクリアテキストかどんなAAAサーバやプロキシ以外のエッジデバイスで露出されるということでした。1.2.4 OTP、SecurID(et)などのサービスのためのクリアテキスト「パスワード」アルの必要がありますか?(より本来でないときに、エッジデバイスは信頼できます)。
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 私たちは、この要件が撞着語法であると断言しました。
Mitton, et al. Informational [Page 81] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [81ページ]情報のRFC3127AAAプロトコル評価過程2001年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 私たちは、Diameterの記法が弱いのがわかって、共通項自然についてそうしました。 一般に、しかし、構文が標準化されたとき相互運用性を達成することに関する心配がありました。
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プロトコルの一部としてバッチ会計に関する重要な懐疑がありました。 「バッチ」はどれくらい大きいですか? この必要条件は、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
1.5.2 ファイアウォール味方を構成することに関する何らかの議論がありました。 ファイアウォールがアプリケーション・プロトコルアドレスを多くの過去のパケットに見せたがっていない(例えば、UDPかTCPが数を移植する)と示唆されました。 AAA以外の用法を持っているSNMPやCOPSなどのプロトコルが不利な立場にあります、ファイアウォールがパケットの本来の目的を決定するためにアプリケーションPDUを深く調べなければならないので。 直径はSCTPの信用に苦しみます。(SCTPは広く配備されていないか、またはファイアウォールによって広く認識されています)。 ファイアウォールであるべきです
Mitton, et al. Informational [Page 82] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [82ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
also be AAA proxy engines? Has this issue anything to do with interoperability with NAT?
また、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.
各メンバーは、資格を与える人に伴う(会計、または変化するための努力)これにおける(許容できて、Not許容できる)の情報の形における彼らの評価が最終報告書にまとめられるのを示しました。
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のデーヴ・ミットンと共に働くでしょう。 私たちは、本当にIETF7月14日の服従締め切りに間に合う必要があります、私たちがAAA WGメーリングリストに関する最新情報を発行しなければならなくても。 すべてが、過程が公正にうまく行ったのに同意しました。 この種の今後の評価では、評価者が密接に要件ドキュメントに従って、submittersが正確で完全な順応ドキュメントを作成して、「再回転」サイクルが要件ドキュメントと順応ドキュメントにおける過失および怠慢を修正するのを許容するのは良いでしょう。
A discussion of the transport protocol was held.
トランスポート・プロトコルの議論が行われました。
The issue with transport is congestion control. There has been a problem with streams-oriented applications over TCP. The IESG is increasingly sensitive to this issue in new protocols. It was noted that AAA was a transaction-oriented application. Other request- response applications, such as DNS, seem to scale welt to Internet- scale using simple application-level retries and UDP transport. TCP has problems with head-of-line blocking, especially when multiple sessions are using a single TCP connection. AAA typically will send 3 or 4 iterations and then indicate a failure to the upper layers. It won't continue retransmissions in the face of congestion, like TCP. It was noted that bulk data transfer may not best be implemented in the AAA protocol. Concern was voiced that SCTP is not a widely implemented protocol. AAA will implement congestion control by limiting the number of outstanding requests. Some RADIUS implementations send lots of traffic when they encounter misconfigured shared secrets, but this is likely caused by a lack of proper error recovery. Diameter, as currently drafted, relies on SCTP. Can AAA run over UDP? The IESG didn't say "no"; their issue is addressing congestion control.
輸送の問題は輻輳制御です。 TCPの上の流れ指向のアプリケーションに関する問題がありました。 IESGはますます新しいプロトコルのこの問題に敏感です。 AAAが取引指向のアプリケーションであることに注意されました。 DNSなどの他の要求応答アプリケーションは簡単なアプリケーションレベル再試行とUDP輸送を使用することでインターネットスケールにみみず腫れについて合わせて調整するように思えます。 特に複数のセッションが単独のTCP接続を使用しているとき、TCPには、線のヘッドブロッキングに関する問題があります。 AAAは、通常3か4繰り返しを送って、次に、上側の層に失敗を示すでしょう。 それは混雑に直面してTCPのように「再-トランスミッション」を続けないでしょう。 AAAプロトコルでバルク・データ転送を実行しないかもしれないのが最も良いことに注意されました。 SCTPが広く実行されたプロトコルでないという関心は声に出されました。 AAAは、傑出している要求の数を制限することによって、輻輳制御を実行するでしょう。 それらがmisconfigured共有秘密キーに遭遇すると、いくつかのRADIUS実現が多くの交通を送りますが、これは適切なエラー回復の不足によっておそらく引き起こされます。 現在作成されているとして、直径はSCTPを当てにします。 AAAはUDPをひくことができますか? 「いいえ」と、IESGは言いませんでした。 それらの問題は輻輳制御を記述しています。
Mitton, et al. Informational [Page 83] RFC 3127 AAA Protocol Evaluation Process June 2001
ミットン、他 [83ページ]情報のRFC3127AAAプロトコル評価過程2001年6月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Mitton, et al. Informational [Page 84]
ミットン、他 情報[84ページ]
一覧
スポンサーリンク
