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
Network Working Group D. Mitton
Request for Comments: 3127 Nortel Networks
Category: Informational M. St.Johns
Rainmaker Technologies
S. Barkley
UUNET
D. Nelson
Enterasys Networks
B. Patil
Nokia
M. Stevens
Ellacoya Networks
B. Wolff
Databus Inc.
June 2001
Authentication, Authorization, and Accounting: Protocol Evaluation
身份验证、授权和记帐：协议评估
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This memo represents the process and findings of the Authentication, Authorization, and Accounting Working Group (AAA WG) panel evaluating protocols proposed against the AAA Network Access Requirements, RFC 2989. Due to time constraints of this report, this document is not as fully polished as it might have been desired. But it remains mostly in this state to document the results as presented.
本备忘录代表了认证、授权和会计工作组（AAA WG）小组根据AAA网络访问要求RFC 2989评估拟定协议的过程和结果。由于本报告的时间限制，本文件未如预期的那样充分完善。但它仍然主要停留在这种状态，以记录所呈现的结果。
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. Process Description . . . . . . . . . . . . . . . . . . . . . .3
1.1 WG Co-Chair's Note . . . . . . . . . . . . . . . . . . . . . .3
1.2 Chairman's Note . . . . . . . . . . . . . . . . . . . . . . . .4
1.3 Members Statements . . . . . . . . . . . . . . . . . . . . . .4
1.4 Requirements Validation Process . . . . . . . . . . . . . . . .6
1.5 Proposal Evaluation . . . . . . . . . . . . . . . . . . . . . .7
1.6 Final Recommendations Process . . . . . . . . . . . . . . . . .7
2. Protocol Proposals . . . . . . . . . . . . . . . . . . . . . . .8
3. Item Level Compliance Evaluation . . . . . . . . . . . . . . . 8
3.1 General Requirements . . . . . . . . . . . . . . . . . . . . . 9
3.2 Authentication Requirements. . . . . . . . . . . . . . . . . .11
3.3 Authorization Requirements . . . . . . . . . . . . . . . . . .12
3.4 Accounting Requirements . . . . . . . . . . . . . . . . . . .12
3.5 MOBILE IP Requirements . . . . . . . . . . . . . . . . . . . .13
4. Protocol Evaluation Summaries . . . . . . . . . . . . . . . . .14
4.1 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
4.2 Radius++ . . . . . . . . . . . . . . . . . . . . . . . . . . .14
4.3 Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . .14
4.4 COPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
4.5 Summary Recommendation . . . . . . . . . . . . . . . . . . .14
5. Security Considerations . . . . . . . . . . . . . . . . . . . .14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . .15
7. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . .15
A. Appendix A - Summary Evaluations . . . . . . . . . . . . . . .17
B. Appendix B - Review of the Requirements . . . . . . . . . . . .18
B.1 General Requirements. . . . . . . . . . . . . . . . . . . . . .18
B.2 Authentication Requirements . . . . . . . . . . . . . . . . . .19
B.3 Authorization Requirements. . . . . . . . . . . . . . . . . . .19
B.4 Accounting Requirements . . . . . . . . . . . . . . . . . . . .20
C. Appendix C - Position Briefs . . . . . . . . . . . . . . . . .21
C.1 SNMP PRO Evaluation . . . . . . . . . . . . . . . . . . . . .21
C.2 SNMP CON Evaluation . . . . . . . . . . . . . . . . . . . . .28
C.3 RADIUS+ PRO Evaluation . . . . . . . . . . . . . . . . . . . .33
C.4 RADIUS+ CON Evaluation . . . . . . . . . . . . . . . . . . . .37
C.5 Diameter PRO Evaluation . . . . . . . . . . . . . . . . . . .44
C.6 Diameter CON Evaluation . . . . . . . . . . . . . . . . . . .50
C.7 COPS PRO Evaluation . . . . . . . . . . . . . . . . . . . . .55
C.8 COPS CON Evaluation . . . . . . . . . . . . . . . . . . . . .59
D. Appendix D - Meeting Notes . . . . . . . . . . . . . . . . . .66
D.1 Minutes of 22-Jun-2000 Teleconference . . . . . . . . . . . .66
D.2 Minutes of 27-Jun-2000 Teleconference . . . . . . . . . . . .68
D.3 Minutes of 29-Jun-2000 Teleconference . . . . . . . . . . . .73
D.4 Minutes of 06-Jul-2000 Teleconference . . . . . . . . . . . .78
D.5 Minutes of 11-Jul-2000 Teleconference . . . . . . . . . . . .80
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .84
Due to time constraints, the original draft of this document was rushed to meet the publication deadline of the June 2000 Pittsburgh meeting. Since the meeting has passed, we do not wish to substantially revise the findings within this document, so that we don't give the appearance of changing information after the presentation. Only additional descriptions of the process, formatting, layout editing and errors of fact have been corrected in subsequent revisions.
由于时间限制，本文件的原稿被赶在2000年6月匹兹堡会议的出版截止日期之前。由于会议已经通过，我们不希望对本文件中的调查结果进行实质性修改，这样我们就不会在陈述后出现信息变化的情况。在随后的修订中，仅对流程、格式、布局编辑和事实错误进行了补充说明。
1.1. WG Co-Chair's Note:
1.1. 工作组共同主席的说明：
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工作组重新章程获得批准，网络接入要求文件通过AAA工作组最后一次通话后，于2000年4月13日发布了协议提交邀请函。征集被发送到AAA工作组邮件列表，以及与AAA相关的其他IETF工作组邮件列表，包括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工作组主席他们打算提交候选方案。建议在2000年5月1日前发出该通知。
Protocol submissions and compliance description documents were to be submitted in Internet Draft format by email to internet-drafts@ietf.org. The deadline for submissions was June 1, 2000. To be considered as a candidate, submissions needed to include an unqualified RFC 2026 statement, as described at: http://www.ietf.org/Sec10.txt
协议提交和合规性说明文件应以互联网草案格式通过电子邮件提交至互联网-drafts@ietf.org. 截止报名日期为二○○○年六月一日。要被视为候选人，提交文件需要包括一份无保留的RFC 2026声明，如以下所述：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工作组评估提交的方案和合规性说明文件，AAA工作组主席随后成立了一个评估小组，该小组于2000年5月20日宣布成立。该团队的工作是在互联网上起草一份草案，记录他们对协议提交的评估。目标是在IETF 48提交截止日期2000年7月14日之前提供初稿。
In composing the evaluation draft, the evaluation team was asked to draw from the protocol specifications, the compliance descriptions, and other relevant documents, the Network Access Requirements document, RFC 2989.
在编写评估草案时，要求评估小组参考协议规范、合规性说明和其他相关文件，即网络访问要求文件RFC 2989。
Mike St. Johns was asked to chair the evaluation team. The chairs of WGs related to AAA were also invited to join the team. These included Dave Mitton, co-chair of NASREQ WG, Basavaraj Patil, co-chair of Mobile IP WG, and Mark Stevens, co-chair of the RAP WG.
Mike St.Johns被邀请担任评估小组主席。与AAA相关的工作组主席也被邀请加入该小组。其中包括NASREQ工作组联席主席Dave Mitton、移动IP工作组联席主席Basavaraj Patil和RAP工作组联席主席Mark Stevens。
Additional members of the evaluation team were chosen to represent the interests of network operators as well as developers of AAA client and server software.
选择了评估小组的其他成员，以代表网络运营商以及AAA客户端和服务器软件开发人员的利益。
As usual, the IESG advised the evaluation team. IESG advisors included Randy Bush and Bert Wijnen, Directors of the Operations and Management Area.
与往常一样，IESG向评估小组提供了建议。IESG的顾问包括兰迪·布什（Randy Bush）和伯特·维恩（Bert Wijnen），他们是运营和管理领域的主管。
1.2. Chairman's Note:
1.2. 主席的说明：
This document is the result of 6 weeks of intense work by the panel listed below. Our mission was to evaluate the various AAA proposals and provide recommendations to the AAA working group and to the IESG on the viability of each of the proposals.
本文件是下文所列专家小组6周紧张工作的结果。我们的任务是评估各种AAA提案，并就每个提案的可行性向AAA工作组和IESG提供建议。
The evaluation process had three distinct phases. 1) Validate the AAA requirements document [AAAReqts] against the base requirements documents for NASREQ, MOBILEIP and ROAMOPS. 2) Evaluate each of the SNMP, Radius++, Diameter and COPS proposal claims against the validated requirements. 3) Provide final recommendations based on side by side comparison for each proposal on a requirement by requirement basis.
评价过程有三个不同的阶段。1） 根据NASREQ、MOBILEIP和ROAMOP的基本需求文件验证AAA需求文件[AAAReqts]。2） 根据经验证的要求评估SNMP、Radius++、Diameter和COPS提案索赔。3） 在逐项需求的基础上，根据对每个提案的并列比较，提供最终建议。
In general, the ONLY information the evaluators were allowed to use throughout the process was that provided in the source documents (the requirements document and the proposal) or documents referenced by the source documents. In other words, if it wasn't written down, it generally didn't exist. Our cutoff for acceptance of information was 1 June 2000 - any submissions after that time were not considered in the panel's deliberations.
一般来说，评估人员在整个过程中唯一允许使用的信息是源文件（需求文件和提案）或源文件引用的文件中提供的信息。换句话说，如果没有写下来，它通常是不存在的。我们接受资料的截止日期是2000年6月1日——在此之后提交的任何资料都没有在小组的审议中得到考虑。
The group was chaired by Michael St.Johns. David Mitton was the document editor. Following are the background statements and any conflicts of interest from them and the rest of the panel.
该小组由Michael St.Johns担任主席。大卫·米顿是文档编辑。以下是他们和小组其他成员的背景陈述和任何利益冲突。
Michael St. Johns, Rainmaker Technologies
Michael St.Johns，Rainmaker Technologies
I have no known conflicts of interest with respect to the AAA process. I have neither advocated nor participated in the creation of any of the submissions. My company is a service company (ISP) and will not be involved in the manufacture or sale of AAA enabled products. Other than my participation as the chair of the AAA evaluation process, I have not had any contact with the AAA standards process.
我对AAA流程没有已知的利益冲突。我既没有主张也没有参与任何意见书的创作。我的公司是一家服务公司（ISP），不会参与AAA产品的制造或销售。除了作为AAA评估过程的主席参与外，我没有与AAA标准过程有任何接触。
David Mitton, Nortel Networks
David Mitton，北电网络公司
I have been Nasreq WG co-chair and author of several Nasreq drafts. As well as, previously contributed to several RADIUS drafts.
我曾担任Nasreq工作组联合主席，并撰写了多份Nasreq草案。以及，以前参与了几个RADIUS草稿。
I have been a RADIUS NAS implementor and Technical Prime on our Server products, so know it extremely well. In my current job role I am involved with Nortel's IP Mobility products, which support Diameter.
我一直是RADIUS NAS的实施者和服务器产品的技术专家，因此非常了解它。在我目前的工作岗位上，我参与了北电的IP移动产品，该产品支持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.
我已经写过一份关于NASRQ会议的COPS和NASRQ要求的报告，但没有实施，也不认为自己是这个问题的专家。
Stuart Barkley, UUNET
斯图尔特·巴克利，UUNET
I've been working for 5 years at UUNET on various parts of our dialup network. I have extensive experience with designing, developing and operating our SNMP based usage data gathering system. I've also been involved in our radius based authentication and authorization systems in an advisory position.
我在UUNET工作了5年，负责我们拨号网络的各个部分。我在设计、开发和操作基于SNMP的使用数据采集系统方面拥有丰富的经验。我还以顾问的身份参与了我们基于radius的认证和授权系统。
I've participated in radius/roamops/nasreq/aaa groups for the past several years. I'm not an author or contributer on any of the requirements or protocol documents being presented although I have been peripherally involved in these working groups.
在过去的几年里，我参加了radius/roamops/nasreq/aaa小组。我不是提交的任何要求或协议文件的作者或贡献者，尽管我已经外围参与了这些工作组。
Dave Nelson, Enterasys Networks
Dave Nelson，Enterasys网络公司
Very active in the RADIUS WG, especially during the early years. No involvement in the AAA submission. Have not contributed to the development of Diameter.
在RADIUS WG中非常活跃，尤其是在早期。没有参与AAA提交。对直径的发展没有贡献。
No involvement with SNMPv3 or the AAA submission. David Harrington, a proponent, works in a different group within my company. We have not discussed the submission. No involvement with the COPS protocol.
不涉及SNMPv3或AAA提交。David Harrington，一位支持者，在我公司的另一个小组工作。我们尚未讨论提交的材料。与警察协议无关。
Basavaraj Patil, Nokia
诺基亚巴萨瓦拉吉·帕蒂尔
I am a contributor to the AAA requirements document (RFC 2977) submitted by the Mobile IP WG. I was a member of the team that was constituted to capture the Mobile IP requirements for AAA services.
我是移动IP工作组提交的AAA需求文档（RFC 2977）的贡献者。我是团队的一员，该团队旨在捕获AAA服务的移动IP需求。
As part of the co-chairing activity of the Mobile IP WG I have realized the need for AAA services by Mobile IP and hence closely followed the work done in the AAA WG, RADIUS, RoamOps and TR45.6.
作为移动IP工作组共同主持活动的一部分，我认识到移动IP需要AAA服务，因此密切关注AAA工作组、RADIUS、RoamOps和TR45.6中完成的工作。
My present work at Nokia does involve looking at AAA protocols (to some extent at least) for use in wireless networks. I have also done some work with AAA protocols such as Diameter in my previous job at Nortel Networks.
我目前在诺基亚的工作涉及研究无线网络中使用的AAA协议（至少在某种程度上）。在我以前在北电网络的工作中，我也做过一些AAA协议的工作，比如Diameter。
Mark Stevens, Ellacoya Networks
马克·史蒂文斯，埃拉科亚网络公司
I am the co-chair of the IETF RAP working group which is the working group that has developed the COPS protocol. I have not contributed to the documents describing how COPS can satisfy AAA requirements.
我是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工作组的早期会议，但自该工作组重组以来，我一直没有积极参与。目前雇用me构建设备的公司可能会从启用AAA中受益。
Barney Wolff, Databus Inc.
巴尼·沃尔夫，数据总线公司。
I have implemented RADIUS client, proxy and server software, under contract to AT&T. That software is owned by AT&T and I have no financial interest in it.
我已经根据与AT&T的合同实施了RADIUS客户端、代理和服务器软件。该软件归AT&T所有，我在其中没有任何经济利益。
I have been a member of the RADIUS WG for several years, and consider myself an advocate for RADIUS against what I consider unjustified attacks on it.
几年来，我一直是WAG的一个成员，我认为自己是RADIUS的倡导者，反对我认为不正当攻击。
I've never worked for any of the companies whose staff have produced any of the proposals, although I obviously might at some future time.
我从未为任何一家公司工作过，这些公司的员工提出过任何建议，尽管我很明显在将来某个时候可能会这样做。
For each of the base requirements documents, the chair assigned a team member to re-validate the requirement. The process was fairly mechanical; the evaluator looked at what was said in [AAAReqts], and verified that the references and supporting text in the basis document supported the requirement in [AAAReqts] as stated. Where the reference was wrong, too general, missing or otherwise did not support the requirement, the evaluator either deleted or downgraded the requirement. The results of that process were sent to the AAA mailing list and are also included in this document in the appendixes. The group's used [AAAReqts] as modified by our validation findings to evaluate the AAA proposals.
对于每个基本需求文件，主席指定一名团队成员重新验证需求。这个过程相当机械；评估人员查看了[AAREQTS]中的内容，并验证了基础文件中的参考文献和支持文本支持[AAREQTS]中所述的要求。如果参考错误、过于笼统、缺失或不支持要求，则评估人员会删除或降级要求。该过程的结果已发送至AAA邮件列表，并包含在本文件附录中。集团使用经我们验证结果修改的[AAAReqts]评估AAA提案。
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.
对于四项提案中的每一项，主席指定两名小组成员编写评估简报。一名成员被指派撰写“专业”简报，可以对提案做出最慷慨的解释；他可以表示怀疑。另一名成员被指派撰写“CON”简报，并要求在进行评估时使用最严格的标准。
Each brief looked at each individual requirement and evaluated how close the proposal came in meeting that requirement. Each item was scored as one of an 'F' for failed to meet the requirement, 'P' for partially meeting the requirement, or 'T' for totally meeting the requirement. The proposals were scored only on the information presented. This means that a particular protocol might actually meet the specifics of a requirement, but if the proposal did not state, describe or reference how that requirement was met, in might be scored lower.
每一份简报都会审视每一项要求，并评估提案在满足该要求方面的接近程度。对于不符合要求的每个项目，得分为“F”，对于部分符合要求的项目，得分为“P”，对于完全符合要求的项目，得分为“T”。这些提案仅根据所提供的信息评分。这意味着一个特定的协议实际上可能满足一项要求的细节，但如果提案没有说明、描述或提及该要求是如何满足的，那么可能会得到较低的分数。
The panel met by teleconference to discuss each proposal and the PRO and CON briefs. Each of the briefers discussed the high points of the brief and gave his summary findings for the proposal. We then discussed each individual requirement line-by-line as a group. At the conclusion, the members provided their own line-by-line evaluations which were used to determine the consensus evaluation for the specific requirement relative to that proposal. The meeting notes from those teleconferences as well as the individual briefs are included in the appendixes.
该小组通过电话会议讨论了每项提案以及赞成和反对意见摘要。每个简报人都讨论了简报的要点，并给出了他对提案的总结结果。然后，我们以小组的形式逐行讨论每个单独的需求。最后，成员们提供了自己的逐行评估，用于确定与该提案相关的具体要求的共识评估。这些电话会议的会议记录以及个人简报包含在附录中。
The panel met for one last time to compare the results for the four proposals and to ensure we'd used consistent evaluation criteria. We did a requirement by requirement discussion, then a discussion of each of the protocols.
小组最后一次开会，比较四项提案的结果，并确保我们使用了一致的评估标准。我们进行了一个需求一个需求的讨论，然后讨论了每个协议。
The final phase was for each member to provide his final summary evaluation for each of the protocols. Each proposal was scored as either Not Acceptable, Acceptable Only For Accounting, Acceptable with Engineering and Fully Acceptable. Where a proposal was acceptable with engineering, the member indicated whether it would be a small, medium or large amount.
最后一个阶段是每个成员对每个议定书进行最后总结评估。每个提案的得分为不可接受、仅会计可接受、工程可接受和完全可接受。如果工程部接受某一提案，则该成员应说明该提案是小金额、中金额还是大金额。
It should be noted that score indicated the opinion of the team member. And they may have taken into consideration background knowledge or additional issues not captured in the minutes presented here.
应该注意的是，分数表明了团队成员的意见。他们可能已经考虑到了背景知识或本文会议记录中未涉及的其他问题。
Each member's scores were used within the group to develop the group's consensus.
每个成员的分数在小组内使用，以形成小组共识。
The following proposal documents were submitted to the AAA WG for consideration by the deadline.
以下提案文件已在截止日期前提交AAA工作组审议。
- SNMP:
- SNMP：
[SNMPComp] "Comparison of SNMPv3 Against AAA Network Access Requirements", Work in Progress.
[SNMPComp]“SNMPv3与AAA网络接入要求的比较”，正在进行中。
- RADIUS Enhancements:
- 半径增强：
[RADComp] "Comparison of RADIUS Against AAA Network Access Requirements", Work in Progress.
[RADComp]“RADIUS与AAA网络接入要求的比较”，正在进行中。
[RADExt] "Framework for the extension of the RADIUS(v2) protocol", Work in Progress.
[RADExt]“RADIUS（v2）协议扩展框架”，正在进行中。
- Diameter
- 直径
[DIAComp] "Comparison of Diameter Against AAA Network Access Requirements", Work in Progress.
[DIAComp]“直径与AAA网络接入要求的比较”，正在进行中。
- COPS for AAA:
- 美国汽车协会的警察：
[COPSComp] "Comparison of COPS Against the AAA NA Requirements", Work in Progress.
[COPSComp]“COPS与AAA NA要求的比较”，正在进行中。
[COPSAAA] "COPS Usage for AAA", Work in Progress.
[COPSAAA]“AAA的COPS使用”，正在进行中。
For each requirement item, the group reviewed the proposal's level of compliance. Where the proposal was lacking, the evaluators may have made supposition on how hard it would be to resolve the problem. The following shows the consensus results for each requirement item.
对于每个需求项目，集团审查了提案的合规性水平。在缺少提案的情况下，评估人员可能会猜测解决问题的难度。以下显示了每个需求项的一致结果。
Key: T = Total Compliance, Meets all requirements fully P = Partial Compliance, Meets some requirements F = Failed Compliance, Does not meet requirements acceptably
关键：T=总符合性，完全满足所有要求P=部分符合性，满足部分要求F=不符合性，不符合可接受的要求
Where two are shown eg: P/T, there was a tie.
在显示两个的地方，例如：P/T，有一个平局。
The sub-section numbering corresponds to the requirements document section and item numbers. This relative numbering was also used in the Protocol Position presentations, here in the appendices.
子章节编号与要求文件章节和项目编号相对应。该相对编号也用于协议位置演示，见附录。
3.1.1 Scalability - SNMP:P, RADIUS:P, Diameter:T, COPS:T
3.1.1 Scalability - SNMP:P, RADIUS:P, Diameter:T, COPS:T
SNMP was downgraded due to a lack of detail of how the current agent model would be adapted to a client request based transaction. The RADIUS proposal did not address the problem adequately. There are open issues in all proposals with respect to webs of proxies.
由于缺乏当前代理模型如何适应基于客户端请求的事务的细节，SNMP被降级。RADIUS提案没有充分解决这个问题。关于代理网络的所有提案中都存在未决问题。
3.1.2 Fail-over - SNMP:P, RADIUS:P, Diameter:P, COPS:T/P
3.1.2 Fail-over - SNMP:P, RADIUS:P, Diameter:P, COPS:T/P
The group particularly noted that it didn't think any protocol did well in this requirement. Insufficient work has been done to specify link failure detection and primary server recovery in most submissions. COPS has some mechanisms but not all. How these mechanisms would work in a web of proxies has not been addressed.
专家组特别指出，它认为任何协议都不能很好地满足这一要求。在大多数提交中，没有完成足够的工作来指定链接故障检测和主服务器恢复。警察有一些机制，但不是全部。这些机制如何在代理网络中工作还没有得到解决。
3.1.3 Mutual Authentication - SNMP:T, RADIUS:T/P, Diameter:T, COPS:T
3.1.3 Mutual Authentication - SNMP:T, RADIUS:T/P, Diameter:T, COPS:T
Many of the submissions missed the point of the requirement. There should be a way for the peers to authenticate each other, end-to-end, or user-to-server. However, the group questions who really needs this feature, and if it could be done at a different level.
许多提交的材料没有达到要求的要点。应该有一种方法让对等方可以通过端到端或用户到服务器的方式相互验证。然而，小组询问谁真正需要这个功能，以及是否可以在不同的级别上实现。
Mutual authentication in RADIUS is only between hops.
RADIUS中的相互身份验证仅在跳之间进行。
3.1.4 Transmission Level Security - SNMP:T, RADIUS:P, Diameter:T,
COPS:T
3.1.4 Transmission Level Security - SNMP:T, RADIUS:P, Diameter:T,
COPS:T
All protocols have methods of securing the message data.
所有协议都有保护消息数据的方法。
3.1.5 Data Object Confidentiality - SNMP:P, RADIUS:P, Diameter:T,
COPS:T
3.1.5 Data Object Confidentiality - SNMP:P, RADIUS:P, Diameter:T,
COPS:T
This requirement usually comes from third-party situations, such as access outsourcing.
这一要求通常来自第三方情况，如访问外包。
Diameter and COPS both use CMS formats to secure data objects. The group is concerned if this method and it's support is perhaps too heavy weight for NAS and some types of edge systems.
Diameter和COPS都使用CMS格式来保护数据对象。该小组担心，对于NAS和某些类型的边缘系统来说，这种方法及其支持是否过重。
3.1.6 Data Object Integrity - SNMP:F, RADIUS:P, Diameter:T, COPS:T
3.1.6 Data Object Integrity - SNMP:F, RADIUS:P, Diameter:T, COPS:T
How to guard the data object from changes was not adequately described in the SNMP proposal. The RADIUS solution was not very strong either.
SNMP提案中没有充分描述如何保护数据对象免受更改。半径解也不是很强。
3.1.7 Certificate Transport - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.1.7 Certificate Transport - SNMP:T, RADIUS:T, Diameter:T, COPS:T
All protocols can figure out some way to transport a certificate.
所有协议都可以找到传输证书的方法。
3.1.8 Reliable AAA Transport - SNMP:P, RADIUS:P, Diameter:T, COPS:T
3.1.8 Reliable AAA Transport - SNMP:P, RADIUS:P, Diameter:T, COPS:T
The requirement does not give a definition of "how reliable" it must be.
该要求没有给出“可靠性”的定义。
The SNMP and RADIUS proposals lacked in providing solutions to message retransmission and recovery.
SNMP和RADIUS提案缺乏提供消息重传和恢复解决方案的能力。
3.1.9 Run over IPv4 - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.1.9 Run over IPv4 - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.1.10 Run over IPv6 - SNMP:P, RADIUS:T, Diameter:T, COPS:T
3.1.10 Run over IPv6 - SNMP:P, RADIUS:T, Diameter:T, COPS:T
The SNMP proposal indicated that this area is still in the experimental stages.
SNMP提案表明，该领域仍处于试验阶段。
3.1.11 Support Proxy and Routing Brokers - SNMP:F, RADIUS:P,
Diameter:T, COPS:P
3.1.11 Support Proxy and Routing Brokers - SNMP:F, RADIUS:P,
Diameter:T, COPS:P
The SNMP proposal did not address this requirement. COPS claims support, but does not work through some of the issues. Diameter was the only protocol that attempted to address this area to a fair extent.
SNMP提案没有满足这一要求。警察要求支持，但没有解决一些问题。Diameter是唯一一个试图在一定程度上解决这一问题的协议。
3.1.12 Auditability - SNMP:F, RADIUS:F, Diameter:T, COPS:P
3.1.12 Auditability - SNMP:F, RADIUS:F, Diameter:T, COPS:P
We treated this requirement as something like "non-repudiation". There is a concern that digital signatures may be too computationally expensive for some equipment, and not well deployed on those platforms.
我们将此要求视为“不可否认”。有一种担忧是，数字签名对于某些设备来说可能计算成本太高，并且没有很好地部署在这些平台上。
The SNMP and RADIUS proposals did not attempt to work this requirement. COPS suggests that a History PIB will help solve this problem but gives no description.
SNMP和RADIUS提案未尝试满足此要求。警察建议历史PIB将有助于解决这个问题，但没有给出描述。
3.1.13 Shared Secret Not Required - SNMP:P/T, RADIUS:T, Diameter:T,
COPS:T
3.1.13 Shared Secret Not Required - SNMP:P/T, RADIUS:T, Diameter:T,
COPS:T
The requirement is interpreted to mean that any application level security can be turned off in the presence of transport level security.
该要求被解释为，在存在传输级安全性的情况下，可以关闭任何应用程序级安全性。
Pretty much every protocol can use an enveloping secure transport that would allow them not to use an internal secret.
几乎每一个协议都可以使用一个封装的安全传输，这将允许它们不使用内部秘密。
3.1.14 Ability to Carry Service Specific Attributes - SNMP:T,
RADIUS:T, Diameter:T, COPS:T
3.1.14 Ability to Carry Service Specific Attributes - SNMP:T,
RADIUS:T, Diameter:T, COPS:T
3.2.1 NAI Support - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.2.1 NAI Support - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.2.2 CHAP Support - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.2.2 CHAP Support - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.2.3 EAP Support - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.2.3 EAP Support - SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.2.4 PAP/Clear-text Passwords - SNMP:T, RADIUS:T, Diameter:T,
COPS:T
3.2.4 PAP/Clear-text Passwords - SNMP:T, RADIUS:T, Diameter:T,
COPS:T
The requirement for clear-text passwords comes from one-time-password systems and hard-token (SecurID) systems.
对明文密码的要求来自一次性密码系统和硬令牌（SecurID）系统。
3.2.5 Reauthentication on demand - SNMP:T, RADIUS:P, Diameter:P,
COPS:T
3.2.5 Reauthentication on demand - SNMP:T, RADIUS:P, Diameter:P,
COPS:T
To supply this, the proposal must have asynchronous peer-to-peer capabilities, and there must defined operation for such state changes.
为此，提案必须具有异步对等功能，并且必须为此类状态更改定义操作。
We also distinguished event-driven Reauthentication from timer-driven (or lifetime-driven). Also concerned about how this would work in a proxy environment.
我们还将事件驱动的重新身份验证与计时器驱动的（或生存期驱动的）重新身份验证区分开来。还关心这在代理环境中如何工作。
3.2.6 Authorization w/o Authentication - SNMP:P, RADIUS:T/P,
Diameter:T, COPS:T
3.2.6 Authorization w/o Authentication - SNMP:P, RADIUS:T/P,
Diameter:T, COPS:T
This requirement really means authorization with trivial authentications (e.g. by assertion or knowledge).
这一要求实际上意味着使用琐碎的身份验证（例如，通过断言或知识）进行授权。
3.3.1 Static and Dynamic IP Addr Assignment - SNMP:P/F, RADIUS:T,
Diameter:T, COPS:T
3.3.1 Static and Dynamic IP Addr Assignment - SNMP:P/F, RADIUS:T,
Diameter:T, COPS:T
There is difficulty in interpreting what is static or dynamic with respect to the viewpoint of the client, server, administrator or user.
从客户机、服务器、管理员或用户的角度来解释什么是静态的或动态的是困难的。
3.3.2 RADIUS Gateway Capability - SNMP:P, RADIUS:P, Diameter:T/P,
COPS:P
3.3.2 RADIUS Gateway Capability - SNMP:P, RADIUS:P, Diameter:T/P,
COPS:P
It was noted that any new capability in a new AAA protocol would not be able to map directly back to RADIUS. But this is already a problem within a RADIUS environment.
有人指出，新AAA协议中的任何新功能都无法直接映射回RADIUS。但在RADIUS环境中，这已经是一个问题。
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?
一些评估人员想知道服务器如何知道应该进行重新授权？它会与外部的东西接口，还是有足够的内部结构？
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.
只有Diameter提案真正解决了这个问题，但该小组认为，所设计的规则太弱，没有用处。还有人担心在不定义语义的情况下标准化语法。
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.
在指定如何在代理网络的情况下实现这一点上，所有协议都很弱，甚至不存在。
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.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
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?
该小组的一些成员不确定这如何适用于AAA协议的其余部分，该协议主要是实时和事件驱动的。使用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.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.
关于“防火墙友好”的含义进行了大量讨论。有人建议不要让防火墙查看超出应用程序端口号的数据包。SNMP和COPS等协议处于劣势，因为您必须深入查看数据包以了解预期操作。直径将有SCTP的缺点，目前还没有很好地部署或认识到这一点。
SNMP and COPS also have the problem that they are used for other types of operations than just AAA.
SNMP和COP还有一个问题，即它们用于AAA以外的其他类型的操作。
Should firewalls have AAA Proxy engines?
防火墙应该有AAA代理引擎吗？
We didn't look at "NAT friendly" issues either.
我们也没有考虑“NAT友好”问题。
COPS:T
警察：T
The group is not clear on how this requirement impacts the actual protocol. Raj explained it to us, but we mostly took it on faith.
专家组不清楚该要求如何影响实际协议。拉杰向我们解释了，但我们基本上是凭信心接受的。
SNMP is generally not acceptable as a general AAA protocol. There may be some utility in its use for accounting, but the amount of engineering to turn it into a viable A&A protocol argues against further consideration.
SNMP作为一般AAA协议通常是不可接受的。它在会计上的应用可能有一定的实用性，但将其转化为可行的a&a协议的工程量不利于进一步考虑。
Radius++ is not considered acceptable as an AAA protocol. There is a fairly substantial amount of engineering required to make it meet all requirements, and that engineering would most likely result in something close to the functionality of Diameter.
Radius++被认为是不可接受的AAA协议。要使其满足所有要求，需要相当大量的工程设计，而该工程设计很可能会产生接近Diameter功能的结果。
Diameter is considered acceptable as an AAA protocol. There is some minor engineering required to bring it into complete compliance with the requirements but well within short term capabilities. Diameter might also benefit from the inclusion of a broader data model ala COPS.
直径被认为是可接受的AAA协议。有一些小工程需要使其完全符合要求，但在短期能力内。Diameter还可以从包含更广泛的数据模型ala COPS中获益。
COPS is considered acceptable as an AAA protocol. There is some minor to medium engineering required to bring it into complete compliance with the requirements.
COPS被视为AAA协议。需要一些小型到中型工程，以使其完全符合要求。
The panel expresses a slight preference for Diameter based on the perception that the work for Diameter is further along than for COPS. However, using SCTP as the transport mechanism for Diameter places SCTP on the critical path for Diameter. This may ultimately result in COPS being a faster approach if SCTP is delayed in any way.
专家组表示，基于对Diameter的工作比COP的工作更深入的认识，对Diameter有一点偏好。但是，使用SCTP作为Diameter的传输机制会将SCTP置于Diameter的关键路径上。如果SCTP以任何方式延迟，这可能最终导致COP成为更快的方法。
AAA protocols enforce the security of access to the Internet. The design of these protocols and this evaluation process took many security requirements as critical issues for evaluation. A candidate protocol must meet the security requirements as documented, and must be engineered and reviewed properly as developed and deployed.
AAA协议加强了访问互联网的安全性。这些协议的设计和评估过程将许多安全需求作为评估的关键问题。候选协议必须符合文件规定的安全要求，并且必须在开发和部署时进行适当设计和审查。
[AAAReqts] Aboba, B., Clahoun, P., Glass, S., Hiller, T., McCann, P., Shiino, H., Walsh, P., Zorn, G., Dommety, G., Perkins, C., Patil, B., Mitton, D., Manning, S., Beadles, M., Chen, X., Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu, R., Koo, H., Lipford, M., Campbell, E., Xu, Y., Baba, S. and E. Jaques, "Criteria for Evaluating AAA Protocols for Network Access", RFC 2989, April 2000.
[AAAReqts]Aboba，B.，Clahoun，P.，Glass，S.，Hiller，T.，McCann，P.，Shiino，H.，Walsh，P.，Zorn，G.，Dommety，G.，Perkins，C.，Patil，B.，Mitton，D.，Manning，S.，Beadles，M.，Chen，X.，Sivalingham，S.，Hameed，A.，Munson，M.，Jacobs，S.，Lim，B.，Hirschman，B.，Hsu，R.，Koo，H.，Lipford，M.，Campbell，E.，Xu，Y.，Y.，Baba，S.，E.Jaques，“评估网络接入AAA协议的标准”，RFC 2989，2000年4月。
[AAAComp] Ekstein, TJoens, Sales and Paridaens, "AAA Protocols: Comparison between RADIUS, Diameter and COPS", Work in Progress.
[AAAComp]Ekstein，TJoens，Sales和Paridaens，“AAA协议：半径、直径和COP之间的比较”，正在进行中。
[SNMPComp] Natale, "Comparison of SNMPv3 Against AAA Network Access Requirements", Work in Progress.
[SNMPComp]Natale，“SNMPv3与AAA网络访问要求的比较”，正在进行中。
[RADComp] TJoens and DeVries, "Comparison of RADIUS Against AAA Network Access Requirements", Work in Progress.
[RADComp]TJoens和DeVries，“RADIUS与AAA网络接入要求的比较”，正在进行中。
[RADExt] TJoens, Ekstein and DeVries, "Framework for the extension of the RADIUS (v2) protocol", Work in Progress,
[RADExt]TJoens、Ekstein和DeVries，“RADIUS（v2）协议扩展框架”，正在进行的工作，
[DIAComp] Calhoun, "Comparison of Diameter Against AAA Network Access Requirements", Work in Progress.
[DIAComp]Calhoun，“直径与AAA网络接入要求的比较”，正在进行中。
[COPSComp] Khosravi, Durham and Walker, "Comparison of COPS Against the AAA NA Requirements", Work in Progress.
[COPSComp]Khosravi、Durham和Walker，“COPS与AAA NA要求的比较”，正在进行中。
[COPSAAA] Durham, Khosravi, Weiss and Filename, "COPS Usage for AAA", Work in Progress.
[COPSAAA]Durham、Khosravi、Weiss和文件名，“AAA的COPS使用”，正在进行中。
David Mitton Nortel Networks 880 Technology Park Drive Billerica, MA 01821
David Mitton Nortel Networks马萨诸塞州比尔里卡科技园大道880号01821
Phone: 978-288-4570 EMail: dmitton@nortelnetworks.com
电话：978-288-4570电子邮件：dmitton@nortelnetworks.com
Michael StJohns Rainmaker Technologies 19050 Pruneridge Ave, Suite 150 Cupertino, CA 95014
Michael StJohns Rainmaker Technologies加利福尼亚州库比蒂诺市普鲁尼里奇大道19050号150室，邮编95014
Phone: 408-861-9550 x5735 EMail: stjohns@rainmakertechnologies.com
电话：408-861-9550 x5735电子邮件：stjohns@rainmakertechnologies.com
Stuart Barkley UUNET F1-1-612 22001 Loudoun County Parkway Ashburn, VA 20147 US
斯图尔特·巴克利UUNET F1-1-612 22001美国弗吉尼亚州阿什本市劳顿县公园路20147
Phone: 703-886-5645 EMail: stuartb@uu.net
电话：703-886-5645电子邮件：stuartb@uu.net
David B. Nelson Enterasys Networks, Inc. (a Cabletron Systems company) 50 Minuteman Road Andover, MA 01810-1008
David B.Nelson Enterasys Networks，Inc.（一家Cabletron系统公司）马萨诸塞州安多弗市民民路50号01810-1008
Phone: 978-684-1330 EMail: dnelson@enterasys.com
电话：978-684-1330电子邮件：dnelson@enterasys.com
Basavaraj Patil Nokia 6000 Connection Dr. Irving, TX 75039
Basavaraj Patil诺基亚6000连接德克萨斯州欧文博士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
马克·史蒂文斯·埃拉科亚网络公司，地址：新罕布什尔州麦里麦克亨利克莱大道7号，邮编：03054
Phone: 603-577-5544 ext. 325 EMail: mstevens@ellacoya.com
电话：603-577-5544分机325电子邮件：mstevens@ellacoya.com
Barney Wolff, Pres. Databus Inc. 15 Victor Drive Irvington, NY 10533-1919 USA
巴尼·沃尔夫，美国纽约州欧文顿维克多大道15号Databus有限公司总裁，邮编10533-1919
Phone: 914-591-5677 EMail: barney@databus.com
电话：914-591-5677电子邮件：barney@databus.com
Appendix A - Summary Evaluations Consensus Results by Requirement and Protocol
附录A-按要求和方案列出的共识结果总结评估
Requirement Section SNMP Radius++ Diameter COPS 1.1.1 P P T T 1.1.2 P P P T/P 1.1.3 T T/P T T 1.1.4 T P T T 1.1.5 P P T T 1.1.6 F P T T 1.1.7 T T T T 1.1.8 P P T T 1.1.9 T T T T 1.1.10 P T T T 1.1.11 F P T P 1.1.12 F F T P 1.1.13 P/T T T T 1.1.14 T T T T
要求章节SNMP Radius++Diameter COPS 1.1.1 P T T T T 1.1.2 P T T/P T 1.1.3 T T T/P T 1.1.4 T T T T T T T 1.1.5 P T T 1.1.6 F T T 1.1.7 T T T T T T 1.1.8 P T T 1.1.9 T T T 1.1.10 P T 1.11 F T 1.1.12 F T 1.1.13 P/T T T 1.14 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 1.2.2 T 1.2.3 T 1.2.4 T 1.2.5 T 1.2.6 T/P 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 1.3.2 P T/P 1.3.3 T/P/F T 1.3.4 F T 1.3.5 P/F P T/P 1.3.6 P T/P 1.3.7 F P/F P T/P 1.3.8 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.4.1 T 1.4.2 T 1.4.3 T 1.4.4 T F P 1.4.5 T 1.4.6 T 1.4.7 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 1.5.2 F T P 1.5.3 F P T
Appendix B - Review of the Requirements
附录B-要求审查
Comments from the Panel on then work in progress, "Criteria for Evaluating AAA Protocols for Network Access" now revised and published as RFC 2989. This became the group standard interpretation of the requirements at the time.
专家组关于“网络接入AAA协议评估标准”的评论意见正在进行中，现已修订并发布为RFC 2989。这成为当时集团对要求的标准解释。
Scalability - In clarification [a], delete "and tens of thousands of simultaneous requests." This does not appear to be supported by any of the three base documents.
可伸缩性-在澄清[a]中，删除“和数以万计的同时请求”。这似乎没有得到三个基本文档中任何一个的支持。
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.
传输级安全性-[表]删除ROAMOP“M”和脚注“6”。这似乎是对漫游协议要求的过度概括，不一定适用于AAA。
Data object confidentiality - [Table] Delete the MOBILE IP "S" and footnote "33". The base document text does not appear to support this requirement.
数据对象机密性-[表]删除移动IP“S”和脚注“33”。基本文档文本似乎不支持此要求。
Reliable AAA transport mechanism - In clarification [h] delete everything after the "...packet loss" and replace with a ".". The requirements listed here are not necessarily supported by the base document and could be mistakenly taken as requirements for the AAA protocol in their entirety.
可靠的AAA传输机制-在澄清[h]中，删除“…数据包丢失”后的所有内容，并替换为“.”。此处列出的要求不一定得到基础文档的支持，可能被误认为是AAA协议的全部要求。
Run over IPv4 - [Table] Replace the MOBILE IP footnote "17" with footnote "33". This appears to be a incorrect reference.
IPv4运行-[表]将移动IP脚注“17”替换为脚注“33”。这似乎是一个不正确的参考。
Run over IPv6 - [Table] Replace the MOBILE IP footnote "18" with a footnote pointing to section 8 of [8]. This appears to be an incorrect reference.
通过IPv6运行-[表]将移动IP脚注“18”替换为指向[8]第8节的脚注。这似乎是一个不正确的参考。
Auditability - Clarification [j] does not appear to coincide with the NASREQ meaning of Auditability. Given that NASREQ is the only protocol with an auditability requirement, this section should be aligned with that meaning.
可审计性-澄清[j]似乎与NASREQ的可审计性含义不一致。鉴于NASREQ是唯一具有可审核性要求的协议，本节应与该含义保持一致。
Shared secret not required - [Table] General - This section is misleadingly labeled. Our team has chosen to interpret it as specified in clarification [k] rather than any of the possible interpretations of "shared secret not required". We recommend the tag in the table be replaced with "Dual App and Transport Security Not Required" or something at least somewhat descriptive of [k]. Delete the NASREQ "S" and footnote "28" as not supported by the NASREQ document. Delete the MOBILE IP "O" and footnotes "34" and 39" as not supported.
不需要共享机密-[表]概述-此部分的标签有误导性。我们的团队选择按照澄清[k]中的规定解释，而不是对“不需要共享秘密”的任何可能解释。我们建议将表中的标签替换为“不需要双应用程序和传输安全”或至少某种程度上描述[k]的内容。删除NASREQ文件不支持的NASREQ“S”和脚注“28”。删除不支持的移动IP“O”和脚注“34”和39”。
NAI Support - [Table] Replace MOBILE IP footnote "38" with "39". This appears to be a more appropriate reference.
NAI支持-[表]将移动IP脚注“38”替换为“39”。这似乎是一个更合适的参考。
CHAP Support - [Table] Delete MOBILE IP "O" as unsupported.
CHAP支持-[表]删除不支持的移动IP“O”。
EAP Support - [Table] Delete MOBILE IP "O" as unsupported.
EAP支持-[表]删除不支持的移动IP“O”。
PAP/Clear-Text Support - [Table] Replace NASREQ footnote "10" with "26" as being more appropriate. Replace ROAMOPS "B" with "O". The reference text appears to not explicitly ban this and specifically references clear text for OTP applications. Delete MOBILE IP "O" as unsupported.
PAP/明文支持-[表]将NASREQ脚注“10”替换为“26”，认为更合适。将“B”替换为“O”。参考文本似乎没有明确禁止这一点，特别是在OTP应用中参考了明文。删除不支持的移动IP“O”。
Re-authentication on demand - Clarification [e] appears to go beyond the requirements in NASREQ and MOBILE IP. [Table] Delete MOBILE IP footnote "30" as inapplicable.
按需重新认证-澄清[e]似乎超出了NASREQ和移动IP的要求。[表]删除不适用的移动IP脚注“30”。
Authorization Only without Authentication - Clarification [f] does not include all NASREQ requirements, specifically that unneeded credentials MUST NOT be required to be filled in. Given that there are no other base requirements (after deleting the MOBILE IP requirement) we recommend that clarification [f] be brought in line with NASREQ. [Table] Delete MOBILE IP "O" and footnote "30". The referenced text does not appear to support the requirement.
仅授权而不进行认证-澄清[f]不包括所有NASREQ要求，特别是不需要填写不必要的凭证。鉴于没有其他基本要求（删除移动IP要求后），我们建议澄清[f]符合NASREQ。[表]删除移动IP“O”和脚注“30”。引用的文本似乎不支持该要求。
Static and Dynamic... - Clarification [a] appears to use a particularly strange definition of static and dynamic addressing. Recommend clarification here identifying who (e.g. client or server) thinks address is static/dynamic. [Table] ROAMOPS "M" appears to be a derived requirement instead of directly called out. The footnote "1" should be changed to "5" as being more appropriate. A text clarification should be added to this document identifying the derived requirement.
静态和动态…-澄清[a]似乎使用了静态和动态寻址的一个特别奇怪的定义。建议在此澄清谁（如客户端或服务器）认为地址是静态/动态的。[表]ROAMOP“M”似乎是一个派生需求，而不是直接调用。脚注“1”应改为“5”，以便更为恰当。应在本文件中添加文本澄清，以确定衍生需求。
RADIUS Gateway capability - [Table] Delete the MOBILE IP "O" and footnote "30". The referenced text does not appear to support the requirement.
RADIUS网关功能-[表]删除移动IP“O”和脚注“30”。引用的文本似乎不支持该要求。
Reject capability - [Table] Delete the NASREQ "M" and footnote "12". The NASREQ document does not appear to require this capability.
拒收能力-[表]删除NASREQ“M”和脚注“12”。NASREQ文档似乎不需要此功能。
Reauthorization on Demand - [Table] Delete the MOBILE IP "S" and footnotes "30,33" The referenced text does not support this requirement.
按需重新授权—[表]删除移动IP“S”和脚注“30,33”。参考文本不支持此要求。
Support for Access Rules... - Clarification [e] has a overbroad list of requirements. NASREQ only requires 5-8 on the list, and as The MOBILE IP requirement is not supported by its references, this clarification should match NASREQ requirements. [Table] Delete the MOBILE IP "O" and footnotes "30,37" as not supported.
对访问规则的支持…-澄清[e]有一份要求的详细清单。NASREQ仅要求列表中的5-8项，并且由于其参考文献不支持移动IP要求，此澄清应符合NASREQ要求。[表]删除不支持的移动IP“O”和脚注“30,37”。
State Reconciliation - Clarification [f] should be brought in line with NASREQ requirements. The clarification imposes overbroad requirements not required by NASREQ and NASREQ is the only service with requirements in this area.
国家对账-澄清[f]应符合NASREQ要求。该澄清规定了NASREQ不要求的超车要求，NASREQ是该地区唯一有要求的服务。
Real-Time accounting - [Table] Replace MOBILE IP footnote [39] with a footnote pointing to section 3.1 of [3] as being more appropriate.
实时计费-[表]将移动IP脚注[39]替换为指向[3]第3.1节的脚注，认为这更合适。
Mandatory Compact Encoding - [Table] Delete MOBILE IP "M" and footnote "33" as the reference does not support the requirement.
强制性紧凑编码-[表]删除移动IP“M”和脚注“33”，因为参考不支持该要求。
Accounting Record Extensibility - [Table] Delete NASREQ "M" and footnote "15" as the reference does not support the requirement.
会计记录扩展性-[表]删除NASREQ“M”和脚注“15”，因为参考不支持该要求。
Accounting Time Stamps - [Table] Delete MOBILE IP "S" and footnote "30" as they don't support the requirement. Replace MOBILE IP footnote "40" with a footnote pointing to section 3.1 of [3] as being more appropriate.
会计时间戳-[表]删除移动IP“S”和脚注“30”，因为它们不支持该要求。将移动IP脚注“40”替换为指向[3]第3.1节的脚注，认为这更合适。
Dynamic Accounting - [Table] Replace the NASREQ footnote "18" with a footnote pointing to section 8.4.1.5 of [3]. Delete the MOBILE IP "S" and footnote "30" as the reference does not support the requirement.
动态会计-[表]将NASREQ脚注“18”替换为指向[3]第8.4.1.5节的脚注。删除移动IP“S”和脚注“30”，因为参考不支持该要求。
Footnote section.
脚注部分。
[40] should be pointing to 6.1 of [4].
[41] should be pointing to 6.2.2 of [4].
[45] should be pointing to 6.4 of [4].
[46] should be pointing to 8 of [4].
[40] should be pointing to 6.1 of [4].
[41] should be pointing to 6.2.2 of [4].
[45] should be pointing to 6.4 of [4].
[46] should be pointing to 8 of [4].
Appendix C - Position Briefs
附录C-职位简介
Evaluation of SNMP AAA Requirements PRO Evaluation Evaluator - Stuart Barkley
SNMP AAA需求评估专业评估师-斯图尔特·巴克利
Ref [1] is "Comparison of SNMPv3 Against AAA Network Access Requirements", aka 'the document' Ref [2] is the aaa eval criteria as modified by us, aka 'the requirements'
参考文献[1]是“SNMPv3与AAA网络接入要求的比较”，又名“文件”，参考文献[2]是经我们修改的AAA评估标准，又名“要求”
The document uses T to indicate total compliance, P to indicate partial compliance and F to indicate no compliance. For each section I've indicated my grade for the section. If there is a change, I've indicated that and the grade given by the authors.
本文件使用T表示完全合规，P表示部分合规，F表示不合规。对于每个部分，我都指出了我在该部分的分数。如果有变化，我已经指出了这一点以及作者给出的分数。
1 Per item discussion
每项讨论1个
1.1 General Requirements
1.1 一般要求
1.1.1 Scalability - Grade T
1.1.1 可扩展性-T级
The document indicates that SNMP can adequately handle that scale from the requirements document. Since most current uses are ppp connections and SNMP is already capable of handling the interface table and other per session tables it is clear that basic capacity exists. Additions to support other tables and variables scales in a simple linear fashion with the number of additional variables and protocol interactions. Regardless of the final selected protocol handling the scaling required is not a trivial undertaking. SNMP can draw upon existing network management practices to assist in this implementation.
该文档表明SNMP可以充分处理需求文档中的这种规模。由于大多数当前使用的是ppp连接，并且SNMP已经能够处理接口表和其他每会话表，因此显然存在基本容量。支持其他表和变量的添加以简单的线性方式与附加变量的数量和协议交互进行缩放。无论最终选择何种协议，处理所需的扩展都不是一件小事。SNMP可以利用现有的网络管理实践来帮助实现。
1.1.2 Fail-over - Grade T
1.1.2 故障转移-T级
SNMP is of vital importance to the operation of most networks. Existing infrastructures can handle required failover or other redundant operations.
SNMP对大多数网络的运行至关重要。现有基础架构可以处理所需的故障切换或其他冗余操作。
1.1.3 Mutual Authentication - Grade T
1.1.3 相互认证-T级
The use of shared secrets described in the document is a well understood method of integrity control. Although shared secrets don't necessarily provide full authentication since other parties may also have the same secrets, the level of authentication is sufficient for the task at hand. In many cases the SNMP infrastructure will
使用文档中描述的共享机密是一种众所周知的完整性控制方法。虽然共享机密不一定提供完全身份验证，因为其他方也可能拥有相同的机密，但身份验证级别足以完成手头的任务。在许多情况下，SNMP基础结构将
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.
已经存在并且共享的秘密应该已经在可操作的网络上得到适当的管理。不管AAA协议如何，SNMP共享秘密方法的失败都可能导致设备和系统绕过任何更复杂的AAA身份验证而被严重滥用。
1.1.4 Transmission Level Security - Grade T
1.1.4 传输级安全性-T级
SNMPv3 provides many additional security options which were not available or were more controversial in previous SNMP versions.
SNMPv3提供了许多在以前的SNMP版本中不可用或更具争议的附加安全选项。
1.1.5 Data Object Confidentiality - New Grade P (from T)
1.1.5 数据对象机密性-新的P级（从T级开始）
The document discusses SNMPv3 which can provide data confidentially for data passing over the wire. There is substantial implied AAA architecture (brokers and proxies) in the requirements that full conformance is difficult to determine. In particular, the evaluator has difficulty with the concept of "the target AAA entity for whom the data is ultimately destined", but will concede that the desired requirement is only partially met (most especially with the transfer of a PAP password).
本文档讨论了SNMPv3，它可以为通过线路传输的数据提供机密数据。在很难确定完全一致性的需求中存在大量隐含的AAA体系结构（代理和代理）。尤其是，评估人员难以理解“最终为其发送数据的目标AAA实体”的概念，但会承认仅部分满足了预期要求（尤其是通过PAP密码的传输）。
1.1.6 Data Object Integrity - New Grade T (from P)
1.1.6 数据对象完整性-新等级T（来自P）
SNMP has full capabilities that allow the authentication of the data. Brokers, proxies or other intermediaries in the data chain can verify the source of the information and determine that the data has not been tampered with. The document downgrades the grade to P because of confusion over the integrity checking role of intermediaries.
SNMP具有允许对数据进行身份验证的完整功能。数据链中的代理、代理或其他中介可以验证信息来源，并确定数据未被篡改。由于对中介机构的完整性检查角色的混淆，该文件将等级降级为P。
1.1.7 Certificate Transport - Grade T
1.1.7 运输证书-T级
The requirements require the capability of transporting certificates but do not have any specific use for the certificates. The requirements make assumptions that the protocol selected will be dependent upon certificates, but this is not necessarily true. SNMP can transport arbitrary objects and can transport certificates if necessary. The document indicates some issues with size of certificates and current maximum practical data sizes, however if the compact encoding requirement extends to the internal certificate information this should be less of an issue.
这些要求要求能够传输证书，但没有证书的任何特定用途。这些要求假设所选择的协议将依赖于证书，但这不一定是真的。SNMP可以传输任意对象，必要时还可以传输证书。该文档指出了证书大小和当前最大实际数据大小方面的一些问题，但是，如果紧凑编码要求扩展到内部证书信息，这应该不是什么问题。
1.1.8 Reliable AAA Transport - New Grade T (from P)
1.1.8 可靠的AAA运输-新等级T（来自P）
The requirements is stated rather strongly and makes substantial assumptions of AAA protocol architecture and based upon current protocols and their failings. SNMP allows for great flexibility in retransmission schemes depending upon the importance of the data.
这些要求非常明确，对AAA协议体系结构进行了实质性假设，并基于当前协议及其故障。SNMP允许根据数据的重要性在重传方案中具有极大的灵活性。
1.1.9 Run over IPv4 - Grade T
1.1.9 在IPv4上运行-T级
SNMP has operated in this mode for many years.
SNMP已在这种模式下运行多年。
1.1.10 Run over IPv6 - New Grade T (from P)
1.1.10 通过IPv6运行-新等级T（来自P）
SNMP must support IPv6 for many other systems so support for this should be possible by the time the requirement becomes effective. The document indicates that experimental versions satisfying this requirement are already in existence.
SNMP必须为许多其他系统支持IPv6，因此在需求生效时，应该可以支持IPv6。文件表明，满足这一要求的实验版本已经存在。
1.1.11 Support Proxy and Routing Brokers - New Grade T (from P)
1.1.11 支持代理和路由代理-新的T级（来自P）
The requirements make significant assumptions about the final architecture. It is well within the capabilities of SNMP to provide intermediaries which channel data flows between multiple parties. The document downgrades SNMPs compliance with this requirement due to issues which are covered more specifically under "Data Object Confidentially" which the evaluator has downgraded to P.
需求对最终架构做出了重要的假设。SNMP完全可以提供中介，在多方之间传递数据流。由于“数据对象机密性”中更具体地涉及的问题，本文件降低了SNMPs对该要求的符合性，而评估者已将该问题降低到P。
1.1.12 Auditability - New Grade T (from F)
1.1.12 可审计性-新的T级（来自F级）
Data flows inside SNMP are easily auditable by having secondary data flows established which provide copies of all information to auxiliary servers. The document grades this as a failure, but this support is only minor additions within a more fully fleshed out set of data flows.
通过建立辅助数据流（向辅助服务器提供所有信息的副本），SNMP内部的数据流易于审核。文档将此分级为失败，但此支持只是更全面的数据流集合中的一个小补充。
1.1.13 Shared Secret Not Required - Grade T
1.1.13 不需要共享机密-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.
SNMP不需要共享机密。在许多较低级别不能提供必要能力的情况下，它们是可取的。该文档提供指向各种可用安全模式的指针。
1.1.14 Ability to Carry Service Specific Attributes - Grade T
1.1.14 具有服务特定属性的能力-T级
SNMP has long had the ability for other parties to create new unambiguous attributes.
SNMP长期以来一直能够让其他方创建新的明确属性。
1.2 Authentication Requirements
1.2 认证要求
1.2.1 NAI Support - Grade T
1.2.1 NAI支持-T级
SNMP easily supports this. NAIs were defined to be easily carried in existing protocols.
SNMP很容易支持这一点。NAI被定义为在现有协议中易于携带。
1.2.2 CHAP Support - Grade T
1.2.2 CHAP支架-T级
SNMP can easily provide objects to pass the necessary information for CHAP operation.
SNMP可以轻松地提供对象来传递CHAP操作所需的信息。
1.2.3 EAP Support - New Grade T (from P)
1.2.3 EAP支持-新等级T（来自P）
SNMP can easily provide objects to pass the necessary information for EAP operation. As with CHAP or PAP MIB objects can be created to control this operation thus the upgrade from the document grade.
SNMP可以方便地提供对象来传递EAP操作所需的信息。与CHAP或PAP一样，可以创建MIB对象来控制此操作，从而从文档级别进行升级。
1.2.4 PAP/Clear-text Passwords - New Grade P (from T)
1.2.4 PAP/明文密码-新的P级（来自T）
SNMP can easily provide objects to pass the necessary information for PAP operation. The requirement about non-disclosure of clear text passwords make assumptions about the protocol implementation. The choice to use clear text passwords is inherently insecure and forced protocol architecture don't really cover this. This requirement grade is downgraded to P (partial) because the document does not really address the confidentially of the data at application proxies.
SNMP可以方便地提供对象来传递PAP操作所需的信息。关于明文密码保密的要求对协议的实现做出了假设。选择使用明文密码本质上是不安全的，强制协议体系结构并没有真正涵盖这一点。此需求等级降级为P（部分），因为文档并未真正解决应用程序代理中数据的机密性问题。
1.2.5 Reauthorization on demand - Grade T
1.2.5 按需重新授权-T级
SNMP can easily provide objects to control this operation.
SNMP可以轻松地提供对象来控制此操作。
1.2.6 Authorization w/o Authentication - New Grade T (from T)
1.2.6 未经认证的授权-新T级（来自T级）
The document makes an incorrect interpretation of this requirement. However, SNMP makes no restriction which prevents to desired requirements. No actual change of grade is necessary, since both the actual requirements and the incorrect interpretation are satisfied by SNMP.
该文件对该要求的解释不正确。但是，SNMP没有限制，无法满足所需的要求。无需实际更改等级，因为SNMP满足实际要求和错误解释。
1.3 Authorization Requirements
1.3 授权要求
1.3.1 Static and Dynamic IP Addr Assignment - Grade T
1.3.1 静态和动态IP地址分配-T级
SNMP can easily provide objects to control this operation.
SNMP可以轻松地提供对象来控制此操作。
1.3.2 RADIUS Gateway Capability - Grade T
1.3.2 RADIUS网关能力-T级
As the document describes, with the addition of any necessary compatibility variables SNMP can be gatewayed to RADIUS applications.
如本文档所述，通过添加任何必要的兼容性变量，可以将SNMP网关连接到RADIUS应用程序。
1.3.3 Reject Capability - Grade T
1.3.3 拒收能力-T级
Any of the active components in the SNMP based structure could decide to reject and authentication request for any reason. Due to mixing different levels of requirements the document doesn't attempt to directly address this, instead indicating that a higher level application can cause this operation.
基于SNMP的结构中的任何活动组件都可以出于任何原因决定拒绝和验证请求。由于混合了不同级别的需求，文档不会试图直接解决这一问题，而是指出更高级别的应用程序可能导致此操作。
1.3.4 Preclude Layer 2 Tunneling - New Grade T (from ?)
1.3.4 排除第2层隧道-新等级T（从？）
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 按需重新授权-T级
SNMP can easily provide objects to control this operation.
SNMP可以轻松地提供对象来控制此操作。
1.3.6 Support for ACLs - Grade T
1.3.6 对ACL的支持-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可以提供允许活动组件重新获取丢失状态信息的方法。这些功能与可伸缩性问题直接交互，在期望此需求与可伸缩性需求同时得到满足时，需要小心。
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进行实时通信
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编码将被视为过度。与基于文本的形式（如某些现有radius日志文件实现中使用的）相比，SNMP BER编码的协议元素通常采用相当紧凑的编码形式。这与承载特定于服务的属性的一般要求和可扩展性的会计要求相互作用。通过仔细的MIB设计和SNMP有效负载压缩的未来工作，SNMP编码开销可以与其他可扩展性较差的协议相媲美。
1.4.3 Accounting Record Extensibility - Grade T
1.4.3 会计记录可扩展性-T级
SNMP has a strong tradition of allowing vendor specific data objects to be transferred.
SNMP具有允许传输特定于供应商的数据对象的传统。
1.4.4 Batch Accounting - Grade T
1.4.4 批量核算-T级
There are many methods which a SNMP based system could use for batch accounting. The document discusses SNMP parameters to control the batching process and indicates that certain existing MIBs contain examples of implementation strategies. SNMP log tables can provide accounting information which can be obtained in many methods not directly related to real time capabilities. The underlying system buffering requirements are similar regardless of the protocol used to transport the information.
基于SNMP的系统可以使用许多方法进行批量记帐。本文档讨论了用于控制批处理过程的SNMP参数，并指出某些现有MIB包含实施策略的示例。SNMP日志表可以提供记帐信息，这些信息可以通过许多与实时功能不直接相关的方法获得。无论用于传输信息的协议是什么，底层系统缓冲要求都是类似的。
1.4.5 Guaranteed Delivery - Grade T
1.4.5 保证交付-T级
SNMP is very amenable to providing guaranteed delivery. Particularly in a pull model (versus the often assumed push model) the data gatherer can absolutely know that all data has been transfered. In the common push model the data receiver does not know if the originator of the data is having problems delivering the data.
SNMP非常适合提供有保证的交付。特别是在拉式模型（与通常假设的推式模型相比）中，数据采集者完全可以知道所有数据都已传输。在公共推送模型中，数据接收方不知道数据的发起人是否在交付数据时遇到问题。
1.4.6 Accounting Timestamps - Grade T
1.4.6 会计时间戳-T级
Timestamps are used for many SNMP based operations. The document points at the DateAndTime textual convention which is available for use. As with all environments the timestamps accuracy needs evaluation before the information should be relied upon.
时间戳用于许多基于SNMP的操作。文档指向可供使用的日期和时间文本约定。与所有环境一样，在依赖信息之前，需要评估时间戳的准确性。
1.4.7 Dynamic Accounting - Grade T
1.4.7 动态会计-T级
As long as there is some way to relate multiple records together there are no problems resolving multiple records for the same session. This interacts with the scalability requirement and care must be taken when implementing a system with both of these requirements.
只要有某种方式将多条记录关联在一起，就可以解决同一会话中的多条记录。这与可伸缩性需求相互作用，在实现具有这两个需求的系统时必须小心。
1.5 MOBILE IP Requirements
1.5 移动IP要求
1.5.1 Encoding of MOBILE IP Registration Messages - Grade T
1.5.1 移动IP注册信息的编码-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级（从？）
SNMP is not concerned with the LHA. This can be under control of the Local network to meet its needs.
SNMP与LHA无关。这可以在本地网络的控制下满足其需求。
2. Summary Discussion
2. 简要讨论
SNMP appears to meet most stated requirements. The areas where the SNMP proposal falls short are areas where specific AAA architectures are envisioned and requirements based upon that architecture are specified.
SNMP似乎满足大多数规定的要求。SNMP提案的不足之处在于设想了特定的AAA体系结构，并指定了基于该体系结构的需求。
Scaling of the protocol family is vital to success of a AAA suite. The SNMP protocol has proved scalable in existing network management and other high volume data transfer operations. Care needs to be taken in the design of a large scale system to ensure meeting the desired level of service, but this is true of any large scale project.
协议系列的扩展对于AAA套件的成功至关重要。事实证明，SNMP协议在现有网络管理和其他大容量数据传输操作中具有可扩展性。在设计大型系统时需要谨慎，以确保满足所需的服务水平，但任何大型项目都是如此。
3. General Requirements
3. 一般要求
SNMP is well understood and already supported in many ISP and other operational environments. Trust models already exist in many cases and can be adapted to provide the necessary access controls needed by the AAA protocols. Important issues with previous versions of SNMP have been corrected in the current SNMPv3 specification.
SNMP在许多ISP和其他操作环境中都得到了很好的理解和支持。信任模型在许多情况下已经存在，并且可以进行调整以提供AAA协议所需的必要访问控制。在当前SNMPv3规范中，已更正了以前版本的SNMP的重要问题。
The SNMP proposal is silent on the specific data variables and message types to be implemented. This is largely due to the requirements not specifying the necessary data elements and the time constraints in extracting that information from the base document set. Such a data model is necessary regardless of the ultimate protocol selected.
SNMP提案对要实现的特定数据变量和消息类型没有说明。这主要是由于从基本文档集中提取信息时没有指定必要的数据元素和时间限制。无论选择哪种最终协议，这种数据模型都是必要的。
4. Summary Recommendation
4. 简要建议
SNMP appears to fully meet all necessary requirements for the full AAA protocol family.
SNMP似乎完全满足整个AAA协议系列的所有必要要求。
Evaluation of SNMP AAA Requirements CON Evaluation Evaluator - Michael StJohns
SNMP AAA需求评估CON评估评估器-Michael 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]是“SNMPv3与AAA网络接入要求的比较”，又称“文件”参考文献[2]是我们修改的AAA评估标准。
The document uses T to indicate total compliance, P to indicate partial compliance and F to indicate no compliance. For each section I've indicated my grade for the section. If there is no change, I've indicated that and the grade given by the authors.
本文件使用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系统中存在存在证明的论点似乎是假设一个管理器与多个代理联系，而多个代理（运行AAA）与一个AAA服务器联系。服务器驱动的系统与客户端驱动的系统具有显著不同的扩展特性，而SNMP无疑是服务器（管理器）驱动的系统。评估-F
1.1.2 Fail-over - The document indicates the use of application level time outs to provide this mechanism, rather than the mechanism being a characteristic of the proposed protocol. The protocol provides only partial compliance with the requirement. Eval - P
1.1.2 故障转移-该文档表明使用应用程序级超时来提供此机制，而不是作为拟议协议特征的机制。该协议仅部分符合要求。评估-P
1.1.3 Mutual Authentication - There is some slight handwaving here, but the protocol's USM mode should be able to support this requirement. Eval - No Change (T)
1.1.3 相互认证-这里有一些轻微的手动操作，但是协议的USM模式应该能够支持此要求。评估-无变化（T）
1.1.4 Transmission Level Security - The authors should elaborate on the specific use of the SNMPv3 modes to support these requirements, but the text is minimally acceptable. Eval - No Change (T)
1.1.4 传输级安全性-作者应详细说明SNMPv3模式的具体使用，以支持这些要求，但文本是最低限度可接受的。评估-无变化（T）
1.1.5 Data Object Confidentiality - The authors describe a mechanism which does not appear to completely meet the requirement. VACM is a mechanism for an end system (agent) to control access to its data based on manager characteristics. This mechanism does not appear to map well to this requirement. Eval - P
1.1.5 数据对象机密性——作者描述了一种似乎不完全满足要求的机制。VACM是一种终端系统（代理）基于管理者特征控制对其数据访问的机制。这种机制似乎不能很好地满足这一需求。评估-P
1.1.6 Data Object Integrity - There appears to be some handwaving going on here. Again, SNMP does not appear to be a good match to this requirement due to at least in part a lack of a proxy intermediary concept within SNMP. Eval - F
1.1.6 数据对象完整性-这里似乎有一些手工操作。同样，SNMP似乎并不符合这一要求，至少部分原因是SNMP中缺少代理中介概念。评估-F
1.1.7 Certificate Transport - The document does indicate compliance, but notes that optimization might argue for use of specialized protocols. Eval - No Change (T)
1.1.7 证书传输-该文档确实指出了遵从性，但注意到优化可能需要使用专门的协议。评估-无变化（T）
1.1.8 Reliable AAA Transport - The document indicates some confusion with the exact extent of this requirement. Given the modifications suggested by the eval group to the explanatory text in [2] for the related annotation, the point by point explanatory text is not required. The document does indicate that the use of SNMP is irrespective of the underlying transport and the support of this requirement is related at least partially to the choice of transport. However, SNMP over UDP - the most common mode for SNMP - does not meet this requirement. Eval - No Change (P)
1.1.8 可靠的AAA运输-文件表明与此要求的确切范围存在一些混淆。鉴于评估小组建议对[2]中相关注释的解释性文本进行修改，不需要逐点解释性文本。该文件确实指出，SNMP的使用与底层传输无关，并且该要求的支持至少部分与传输的选择有关。但是，UDP上的SNMP（SNMP最常见的模式）不满足此要求。评估-无变化（P）
1.1.9 Run over IPv4 - While the evaluator agrees that SNMPv3 runs over V4, the authors need to point to some sort of reference. Eval - No Change (T)
1.1.9 在IPv4上运行-虽然评估者同意SNMPv3在V4上运行，但作者需要指出某种参考。评估-无变化（T）
1.1.10 Run over IPv6 - The document indicates both experimental implementations and future standardization of SNMPv3 over IPv6. Eval - No Change (P)
1.1.10 在IPv6上运行-该文档说明了SNMPv3在IPv6上的实验性实现和未来的标准化。评估-无变化（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 支持代理和路由代理-文件（5.5.3）中标题应包含SNMP代理讨论的部分标记为TBD。本节指出，无法完全遵守数据对象保密性和完整性要求可能会影响本节的合规性，评估人同意。评估-F
1.1.12 Auditability - The document indicates no compliance with this requirement. Eval - No Change (F)
1.1.12 可审核性-文件表明不符合此要求。评估-无变化（F）
1.1.13 Shared Secret Not Required - Slight handwaving here, but SNMPv3 does not necessarily require use of its security services if other security services are available. However, the interaction with VACM in the absence of USM is not fully described and may not have good characteristics related to this requirement. Eval - P
1.1.13 不需要共享机密-此处略显手工操作，但如果有其他安全服务可用，则SNMPv3不一定需要使用其安全服务。然而，在没有USM的情况下，与VACM的交互作用没有完全描述，并且可能没有与该要求相关的良好特性。评估-P
1.1.14 Ability to Carry Service Specific Attributes - SNMP complies via the use of MIBs. Eval - No Change (T)
1.1.14 能够携带特定于服务的属性-SNMP通过使用MIB遵守。评估-无变化（T）
1.2 Authentication Requirements
1.2 认证要求
1.2.1 NAI Support - The document indicates that MIB objects can be created to meet this requirement, but gives no further information. Eval - P
1.2.1 NAI支持—该文档指出可以创建MIB对象以满足此要求，但没有提供进一步的信息。评估-P
1.2.2 CHAP Support - The document indicates that MIB objects can be created to meet this requirement, but gives no further information. Given the normal CHAP model, its unclear exactly how this would work. Eval - F
1.2.2 CHAP支持—文档指出可以创建MIB对象以满足此要求，但没有提供进一步的信息。考虑到正常的CHAP模型，目前尚不清楚这将如何工作。评估-F
1.2.3 EAP Support - The document notes that EAP payloads can be carried as specific MIB objects, but also notes that further design work would be needed to fully incorporate EAP. Eval - No Change (P)
1.2.3 EAP支持——该文件指出，EAP有效载荷可以作为特定的MIB对象携带，但也指出，需要进一步的设计工作来完全整合EAP。评估-无变化（P）
1.2.4 PAP/Clear-text Passwords - The document notes the use of MIB objects to carry the clear text passwords and the protection of those objects under normal SNMPv3 security mechanisms. Eval - No Change (T)
1.2.4 PAP/明文密码-本文档说明了使用MIB对象携带明文密码以及在正常SNMPv3安全机制下对这些对象的保护。评估-无变化（T）
1.2.5 Reauthorization on demand - While there's some handwaving here, its clear that the specific applications can generate the signals to trigger reauthorization under SNMP. Eval - No Change (T)
1.2.5 按需重新授权-虽然这里有一些手工操作，但很明显，特定的应用程序可以生成信号来触发SNMP下的重新授权。评估-无变化（T）
1.2.6 Authorization w/o Authentication - The author appears to be confusing the AAA protocol authorization with the AAA user authorization and seems to be over generalizing the ability of SNMP to deal with general AAA user authorization. Eval - F
1.2.6 授权不带身份验证-作者似乎混淆了AAA协议授权和AAA用户授权，似乎过度概括了SNMP处理一般AAA用户授权的能力。评估-F
1.3 Authorization Requirements
1.3 授权要求
1.3.1 Static and Dynamic IP Addr Assignment - The reference to MIB objects without more definite references or descriptions continues to be a negative. While the evaluator agrees that MIB objects can represent addresses, the document needs to at least lead the reader in the proper direction. Eval - F
1.3.1 静态和动态IP地址分配-对MIB对象的引用（没有更明确的引用或描述）仍然是否定的。虽然evaluator同意MIB对象可以表示地址，但文档至少需要引导读者走向正确的方向。评估-F
1.3.2 RADIUS Gateway Capability - The transport and manipulation of Radius objects appears to be only a part of what is required. Eval - P
1.3.2 RADIUS网关功能—RADIUS对象的传输和操作似乎只是所需功能的一部分。评估-P
1.3.3 Reject Capability - Again, a clarification of how SNMP might accomplish this requirement would be helpful. The overall document lacks a theory of operation for SNMP in an AAA role that might have clarified the various approaches. Eval - F
1.3.3 拒绝功能-再次说明SNMP如何实现此要求将很有帮助。整个文档缺少AAA角色中SNMP的操作理论，该理论可能阐明了各种方法。评估-F
1.3.4 Preclude Layer 2 Tunneling - Document indicates lack of understanding of this requirement. Eval - F
1.3.4 排除第2层隧道-文件表明不了解该要求。评估-F
1.3.5 Reauth on Demand - See response in 1.3.3 above. None of the text responding to this requirement, nor any other text in the document, nor any of the references describes the appropriate framework and theory. Eval - F
1.3.5 按需重新授权-见上文1.3.3中的响应。响应本要求的任何文本、文件中的任何其他文本或任何参考文献均未描述适当的框架和理论。评估-F
1.3.6 Support for ACLs - The response text again references MIB objects that can be defined to do this job. There is additional engineering and design needed before this is a done deal. Eval - P
1.3.6 支持ACL-响应文本再次引用可以定义用于执行此任务的MIB对象。在达成协议之前，还需要额外的工程和设计。评估-P
1.3.7 State Reconciliation - The text fails to address the basic question of how to get the various parts of the AAA system back in sync. Eval - F
1.3.7 国家和解-文本未能解决如何使AAA系统的各个部分恢复同步的基本问题。评估-F
1.3.8 Unsolicited Disconnect - Assuming that the NAS is an SNMP agent for an AAA server acting as an SNMP manager the evaluator concurs. Eval - No Change (T).
1.3.8 未经请求的断开连接-假设NAS是AAA服务器的SNMP代理，充当SNMP管理器，则评估者同意。评估-无变化（T）。
1.4 Accounting Requirements
1.4 会计要求
1.4.1 Real Time Accounting - SNMP Informs could accomplish the requirements. Eval - No Change (T)
1.4.1 实时记帐—SNMP通知可以满足要求。评估-无变化（T）
1.4.2 Mandatory Compact Encoding - This is a good and reasonable response. SNMP can vary the style and type of reported objects to meet specific needs. Eval - No Change (T).
1.4.2 强制压缩编码-这是一个好的、合理的响应。SNMP可以改变报告对象的样式和类型，以满足特定需要。评估-无变化（T）。
1.4.3 Accounting Record Extensibility - MIBs are extensible. Eval - No Change (T)
1.4.3 会计记录可扩展性—MIB是可扩展的。评估-无变化（T）
1.4.4 Batch Accounting - MIBs provide data collection at various times. Eval - No Change (T)
1.4.4 批量记帐-MIB在不同时间提供数据收集。评估-无变化（T）
1.4.5 Guaranteed Delivery - There's some weasel wording here with respect to what guaranteed means, but the description of mechanisms does appear to meet the requirements. Eval - No Change (T)
1.4.5 保证交付-关于保证意味着什么，这里有一些狡猾的措辞，但对机制的描述似乎符合要求。评估-无变化（T）
1.4.6 Accounting Timestamps - Accounting records can use the DateAndTime Textual Convention to mark their times. Eval - No Change (T)
1.4.6 会计时间戳-会计记录可以使用DateAndTime文本约定来标记其时间。评估-无变化（T）
1.4.7 Dynamic Accounting - The author may have partially missed the point on this requirement. While the number of records per session is not of great interest, the delivery may be. The author should go a little more into depth on this requirement. Eval - No Change (T)
1.4.7 动态会计-作者可能部分忽略了这一要求。虽然每个会话的记录数不太令人感兴趣，但交付过程可能会非常复杂。作者应该更深入地讨论这个要求。评估-无变化（T）
1.5 MOBILE IP Requirements
1.5 移动IP要求
1.5.1 Encoding of MOBILE IP Registration Messages - Registration messages can probably be encoded as SNMP messages. Eval - No Change (T)
1.5.1 移动IP注册消息的编码-注册消息可能被编码为SNMP消息。评估-无变化（T）
1.5.2 Firewall Friendly - There's a chicken and egg problem with the response to the requirement in that the author hopes that SNMP as an AAA protocol will encourage Firewall vendors to make SNMP a firewall friendly protocol. Eval - F
1.5.2 防火墙友好型-对该要求的响应存在鸡和蛋的问题，因为作者希望SNMP作为AAA协议将鼓励防火墙供应商使SNMP成为防火墙友好型协议。评估-F
1.5.3 Allocation of Local Home Agent - The author disclaims an understanding of this requirement. Eval - F
1.5.3 本地家庭代理的分配-作者否认理解此要求。评估-F
2. Summary Discussion
2. 简要讨论
The documents evaluation score was substantially affected by a lack of any document, reference or text which described a theory of operation for SNMP in AAA mode. Of substantial concern are the items relating to the AAA server to server modes and AAA client to server modes and the lack of a map to the SNMP protocol for those modes.
由于缺乏任何描述AAA模式下SNMP操作理论的文档、参考或文本，文档评估分数受到很大影响。主要关注的是与AAA服务器到服务器模式和AAA客户端到服务器模式相关的项目，以及这些模式缺乏到SNMP协议的映射。
The evaluator also notes that the scaling issues of SNMP in SNMP agent/manager mode are in no way indicative of SNMP in AAA client/server mode. This has a possibility to substantially impair SNMPs use in an AAA role.
评估人员还注意到，SNMP代理/管理器模式下的SNMP扩展问题绝不表示AAA客户端/服务器模式下的SNMP。这有可能严重影响SNMPs在AAA角色中的使用。
However, SNMP may have a reasonable role in the Accounting space. SNMP appears to map well with existing technology, and with the requirements.
但是，SNMP在记帐空间中可能具有合理的作用。SNMP似乎与现有技术和需求很好地匹配。
3. General Requirements
3. 一般要求
SNMP appears to meet the general requirements of an IP capable protocol, but may not have a proper field of use for all specific requirements.
SNMP似乎满足支持IP的协议的一般要求，但可能没有适用于所有特定要求的适当使用范围。
4. Summary Recommendation
4. 简要建议
Recommended in Part. SNMP is NOT RECOMMENDED for use as either an authentication or authorization protocol, but IS RECOMMENDED for use as an accounting protocol.
部分推荐。不建议将SNMP用作身份验证或授权协议，但建议将其用作记帐协议。
Evaluation of RADIUS AAA Requirements PRO Evaluation
RADIUS AAA需求评估PRO评估
Evaluator - Mark Stevens
评估员-马克·史蒂文斯
Ref [1] is "Comparison of RADIUS Against AAA Network Access Requirements" Ref [2] is "Framework for the extension of the RADIUS(v2) protocol" Ref [3] is the aaa eval criteria as modified by us.
参考文献[1]是“RADIUS与AAA网络接入要求的比较”，参考文献[2]是“RADIUS（v2）协议扩展框架”，参考文献[3]是我们修改的AAA评估标准。
The documents uses T to indicate total compliance, P to indicate partial compliance and F to indicate no compliance.
文件使用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++的声明不同。以下给出的评估等级可能不同于文件中规定的评估，该文件称为“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] 可伸缩性-协议的可伸缩性可以测量，协议似乎以相当有效的方式传输信息。因此，由于协议似乎不会消耗与其传输的数据相关的过多带宽，因此可以认为该协议是可伸缩的。但是，该协议在端点之间可以支持的并发会话数量上有限制。工作区已经存在并正在使用中。评估-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改为T）
1.1.3 [c] Mutual Authentication - The RADIUS++ protocol provides shared-secret as a built-in facility for mutual authentication. The authors of the document suggest the use of IPSec to obtain mutual authentication functions. The RADIUS++ protocol provides no road blocks to obtaining mutual authentication between instances of AAA applications, however the protocol provides no facilities for doing so.
1.1.3 [c] 相互身份验证-RADIUS++协议提供共享机密作为相互身份验证的内置工具。该文档的作者建议使用IPSec来获得相互身份验证功能。RADIUS++协议不提供在AAA应用程序实例之间获得相互身份验证的障碍，但是该协议不提供这样做的工具。
1.1.4 [d] Transmission Level Security - The RADIUS++ protocol provides no transmission level security features, nor does it preclude the use of IPSec to obtain transmission level security. Eval - P (no change)
1.1.4 [d] 传输级安全性-RADIUS++协议不提供传输级安全性功能，也不排除使用IPSec来获得传输级安全性。评估-P（无变化）
1.1.5 [e] Data Object Confidentiality - The document describes a RAIDUS++ message designed to server as an envelope in which encrypted RADIUS messages (attributes) may be enclosed. Eval - T (no change)
1.1.5 [e] 数据对象机密性-该文档描述了一个RAIDUS++消息，该消息被设计为服务器的信封，其中可能包含加密的RADIUS消息（属性）。评估-T（无变化）
1.1.6 [f] Data Object Integrity - Using visible signatures, the RADIUS++ protocol appears to meet this requirement. Eval - T (no change)
1.1.6 [f] 数据对象完整性-使用可见签名，RADIUS++协议似乎满足此要求。评估-T（无变化）
1.1.7 [g] Certificate Transport - The document indicates compliance through the use of the CMS-Data Radius Attribute (message). Eval - T (no change)
1.1.7 [g] 证书传输-该文档通过使用CMS数据半径属性（消息）表示符合性。评估-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传输-该文件指出，RADIUS++在第2层隧道协议的支持下可以被视为可靠的传输。协议本身不提供可靠性特征。可靠性仍然是应用程序或扩充协议的责任。评估-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地址数据类型。评估-T（无变化）
1.1.11 [k] Support Proxy and Routing Brokers - There is no mechanism for rerouting requests, but an extension can be made to do so. Eval - T (no change)
1.1.11 [k] 支持代理和路由代理-没有重新路由请求的机制，但可以进行扩展。评估-T（无变化）
1.1.12 [l] Auditability - The document indicates no compliance with this requirement. Eval - F (no change)
1.1.12 [l] 可审核性-文件表明不符合此要求。评估-F（无变化）
1.1.13 [m] Shared Secret Not Required - RADIUS++ can be configured to
run with empty shared secret values. Eval - T (no change)
1.1.13 [m] Shared Secret Not Required - RADIUS++ can be configured to
run with empty shared secret values. Eval - T (no change)
1.1.14 [n] Ability to Carry Service Specific Attributes - Vendor escape mechanism can be used for this purpose.. Eval - T (no change)
1.1.14 [n] 能够携带特定于服务的属性-供应商转义机制可用于此目的。。评估-T（无变化）
1.2 Authentication Requirements
1.2 认证要求
1.2.1 [a] NAI Support - Eval - T (no change)
1.2.1 [a] NAI支持-评估-T（无变化）
1.2.2 [b] CHAP Support - Subject to dictionary attacks. Eval - P (changed from T)
1.2.2 [b] CHAP支持-受到字典攻击。评估-P（由T更改）
1.2.3 [c] EAP Support - Eval - T (no change)
1.2.3 [c] EAP支持-评估-T（无变化）
1.2.4 [d] PAP/Clear-text Passwords - No end-to-end security, but potential for encapsulation exists within current paradigm of the protocol. - Eval -T (no change)
1.2.4 [d] PAP/明文密码-无端到端安全性，但在当前协议范例中存在封装的可能性。-评估-T（无变化）
1.2.5 [e] Reauthentication on demand - The RADIUS protocol supports re-authentication. In case re-authentication is initiated by the user or AAA client, the AAA client can send a new authentication request. Re-authentication can be initiated from the visited or home AAA server by sending a challenge message to the AAA client. Eval - T (no change)
1.2.5 [e] 按需重新验证-RADIUS协议支持重新验证。在用户或AAA客户端发起重新身份验证的情况下，AAA客户端可以发送新的身份验证请求。通过向AAA客户端发送质询消息，可以从访问的AAA服务器或家庭AAA服务器启动重新身份验证。评估-T（无变化）
1.2.6 [f] Authorization w/o Authentication - A new message type can
be created to enable RADIUS++ to support Aw/oA . Eval - T (no
change)
1.2.6 [f] Authorization w/o Authentication - A new message type can
be created to enable RADIUS++ to support Aw/oA . Eval - T (no
change)
1.3 Authorization Requirements
1.3 授权要求
1.3.1[a] Static and Dynamic IP Addr Assignment - Both supported. IPv6 would require the definition of a new address data type. Eval - P (no change)
1.3.1[a]静态和动态IP地址分配-均受支持。IPv6将需要定义新的地址数据类型。评估-P（无变化）
1.3.2 [b] RADIUS Gateway Capability - The transport and manipulation of RADIUS objects appears to be only a part of what is required. Requirement seems to be worded to preclude RADIUS. Eval - P (changed from T)
1.3.2 [b] RADIUS网关功能—RADIUS对象的传输和操作似乎只是所需功能的一部分。该要求的措辞似乎排除了半径。评估-P（由T更改）
1.3.3 [c] Reject Capability - Eval -T
1.3.3 [c] 拒绝能力-评估-T
1.3.4 [d] Preclude Layer 2 Tunneling - I do not see a definition in the AAA eval criteria document. Eval - ?
1.3.4 [d] 排除第2层隧道-我在AAA评估标准文档中没有看到定义。评估-？
1.3.5 [e] Reauthorization on Demand - Implementation in the field demonstrate that extensions to RADIUS can support the desired behavior. Re-authentication is currently coupled to re-authorization. Eval - P (no change)
1.3.5 [e] 按需重新授权-现场实施表明，对RADIUS的扩展可以支持所需的行为。重新认证当前与重新授权相耦合。评估-P（无变化）
1.3.6 [f] Support for ACLs - Currently done in the applications behind the RADIUS end points, not the within the protocol. RADIUS++ could define additional message types to deal with expanded access control within new service areas. Eval - P (no change)
1.3.6 [f] 对ACL的支持-当前在RADIUS端点后面的应用程序中完成，而不是在协议中完成。RADIUS++可以定义其他消息类型，以处理新服务区域内扩展的访问控制。评估-P（无变化）
1.3.7 [g] State Reconciliation - Eval - F (no change)
1.3.7 [g] 国家和解-评估-F（无变化）
1.3.8 [h] Unsolicited Disconnect - RADIUS++ extensions to support.
Eval - T. (no change)
1.3.8 [h] Unsolicited Disconnect - RADIUS++ extensions to support.
Eval - T. (no change)
1.4 Accounting Requirements
1.4 会计要求
1.4.1 [a] Real Time Accounting - Eval - T (no change)
1.4.1 [a] 实时会计-评估-T（无变化）
1.4.2 [b] Mandatory Compact Encoding - Eval - T (no change)
1.4.2 [b] 强制压缩编码-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] Batch Accounting - RADIUS++ offers no new features to
support batch accounting. Eval - F No change)
1.4.5 [e] Guaranteed Delivery - Retransmission algorithm employed. Eval - T (no change)
1.4.5 [e] 保证交付-采用重传算法。评估-T（无变化）
1.4.6 [f] Accounting Timestamps - RADIUS++ extensions support
timestamps. Eval - T (no change)
1.4.6 [f] Accounting Timestamps - RADIUS++ extensions support
timestamps. Eval - T (no change)
1.4.7 [g] Dynamic Accounting - RADIUS++ extensions to support. Eval - T (no change)
1.4.7 [g] 动态记帐-支持RADIUS++扩展。评估-T（无变化）
1.5 MOBILE IP Requirements
1.5 移动IP要求
1.5.1 [a] Encoding of MOBILE IP Registration Messages - RADIUS++ extensions can be made to include registration messages as an opaque payload. Eval - T (no change)
1.5.1 [a] 移动IP注册消息的编码-可以进行RADIUS++扩展，将注册消息作为不透明的有效负载包含在内。评估-T（无变化）
1.5.2 [b] Firewall Friendly - RADIUS is known to be operational in environments where firewalls acting as a proxy are active. Eval - T (no change)
1.5.2 [b] 防火墙友好型-已知RADIUS可在防火墙充当代理的环境中运行。评估-T（无变化）
1.5.3 [c] Allocation of Local Home Agent -Requirement statement needs some clarification and refinement. Eval - F (no change)
1.5.3 [c] 本地本地代理的分配-要求声明需要一些澄清和细化。评估-F（无变化）
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网络访问要求。但是，只要稍加努力，就可以扩展现有程序以满足中列出的要求，同时保持与广泛部署和安装的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++安装将更加容易。尽管会计仍然比其他方法弱，但该协议仍然是在授权和认证领域继续使用的有力竞争者。
Evaluation of RADIUS++ (sic) AAA Requirements CON Evaluation Evaluator - David Nelson
RADIUS++（sic）AAA要求评估CON评估师-David Nelson
Ref [1] is "Comparison of RADIUS Against AAA Network Access Requirements", a.k.a. 'the document' Ref [2] is "Framework for the extension of the RADIUS(v2) protocol", a.k.a. 'the protocol' Ref [3] is the AAA evaluation criteria as modified by us. Ref [4] is RFC 2869. Ref [5] is an expired work in progress "RADIUS X.509 Certificate Extensions". Ref [6] is RFC 2868
参考文献[1]是“RADIUS与AAA网络接入要求的比较”，也称为“文件”参考文献[2]是“RADIUS（v2）协议扩展框架”，也称为“协议”参考文献[3]是我们修改的AAA评估标准。参考文献[4]为RFC 2869。参考文献[5]是一份过期的在建工程“RADIUS X.509证书扩展”。参考文献[6]为RFC 2868
The document uses T to indicate total compliance, P to indicate partial compliance and F to indicate no compliance. Evaluator's Note: The document [1] pre-dates the protocol [2]. It is clear from reading [2], that some of the issues identified as short comings in [1] are now addressed in [2]. The evaluator has attempted to take note of these exceptions, where they occur.
本文件使用T表示完全合规，P表示部分合规，F表示不合规。评估者注：文件[1]的日期早于方案[2]。从阅读[2]中可以清楚地看出，在[1]中确定为缺点的一些问题现在在[2]中得到了解决。评估人员试图记录这些异常情况，这些异常情况发生的地方。
Section 1 - Per item discussion
第1节-每项讨论
1.1 General Requirements
1.1 一般要求
1.1.1 Scalability - The document [1] indicates partial compliance, largely in deference to the "tens of thousands of simultaneous requests" language in [3], that has been deprecated. The issue of simultaneous requests from a single AAA client is addressed in [1], indicating that the apparent limitation of 256 uniquely identifiable outstanding request can be worked around using well known techniques, such as the source UDP port number of the request. The document claims "P", and the evaluator concurs.
1.1.1 可伸缩性—文档[1]表明了部分遵从性，主要是遵从[3]中已被弃用的“数以万计的同时请求”语言。[1]中讨论了来自单个AAA客户端的同时请求的问题，表明可以使用众所周知的技术（例如请求的源UDP端口号）解决256个唯一可识别的未完成请求的明显限制。该文件称为“P”，评估人同意。
1.1.2 Fail-over - The document [1] indicates the use of application level time outs to provide the fail-over mechanism. Since the AAA protocol is indeed an application-layer protocol, this seems appropriate. There are significant issues of how to handle fail-over in a proxy-chain environment that have not been well addressed, however. The document claims "T", and the evaluator awards "P".
1.1.2 故障转移-文档[1]指出使用应用程序级超时来提供故障转移机制。由于AAA协议确实是一个应用层协议，因此这似乎是合适的。然而，关于如何在代理链环境中处理故障转移的一些重要问题尚未得到很好的解决。该文件称为“T”，评估人授予“P”。
1.1.3 Mutual Authentication - The document [1] indicates that mutual authentication exists in the presence of a User-Password or CHAP-Password attribute in an Access-Request packet or the Message-Authenticator [4] in any packet. Once again, this addresses hop-by-hop authentication of RADIUS "peers", but does not fully address proxy-chain environments, in which trust models would need to be established. The document further indicates that strong mutual authentication could be achieved using the facilities of IPsec. This claim would apply equally to all potential AAA protocols, and cannot be fairly said to be a property of the protocol itself. The document claims "T", and the evaluator awards "F".
1.1.3 相互认证-文档[1]指出，在访问请求数据包中存在用户密码或CHAP密码属性，或在任何数据包中存在消息认证器[4]的情况下，存在相互认证。同样，这解决了RADIUS“对等方”的逐跳身份验证问题，但没有完全解决需要建立信任模型的代理链环境问题。该文件进一步指出，使用IPsec的设施可以实现强大的相互认证。该声明将平等地适用于所有潜在的AAA协议，并且不能公平地说是协议本身的属性。该文件称为“T”，评估人授予“F”。
1.1.4 Transmission Level Security - The document [1] indicates that transmission layer security, as defined in [3], is provided in the protocol, using the mechanisms described in section 1.1.3. It should be noted that this requirement is now a SHOULD in [3]. The document claims "P", and the evaluator concurs.
1.1.4 传输级安全性-文件[1]指出，协议中使用第1.1.3节中描述的机制提供了[3]中定义的传输层安全性。应该注意的是，这一要求现在是[3]中的一个应该。该文件称为“P”，评估人同意。
1.1.5 Data Object Confidentiality - The document [1] indicates that end-to-end confidentiality is not available in RADIUS, but goes on to say that it could be added. The protocol [2] actually makes an attempt to specify how this is to be done, in section 4.3.2.2 of [2], using a CMS-data attribute, based in large part upon RFC 2630. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. The document claims "F", but in light of the specifics of the protocol [2], the evaluator awards "P".
1.1.5 数据对象机密性—文档[1]指出RADIUS中不提供端到端的机密性，但还说可以添加。在[2]的第4.3.2.2节中，协议[2]实际上试图使用CMS数据属性，在很大程度上以RFC 2630为基础，指定如何实现这一点。评估人员目前尚未调查RFC 2630对AAA工作的适用性。该文件声称为“F”，但根据方案[2]的具体规定，评估人授予“P”。
1.1.6 Data Object Integrity - The document [1] indicates that end-to-end integrity is not available in RADIUS, but goes on to say that it could be added. The protocol [2] actually makes an attempt to specify how this is to be done, in section 4.3.2.1 of [2], using a CMS-data attribute, based in large part upon RFC 2630. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. The document claims "F", but in light of the specifics of the protocol [2], the evaluator awards "P".
1.1.6 数据对象完整性—文档[1]指出RADIUS中不提供端到端的完整性，但还说可以添加。在[2]的第4.3.2.1节中，协议[2]实际上试图使用CMS数据属性，在很大程度上以RFC 2630为基础，指定如何实现这一点。评估人员目前尚未调查RFC 2630对AAA工作的适用性。该文件声称为“F”，但根据方案[2]的具体规定，评估人授予“P”。
1.1.7 Certificate Transport - The document [1] indicates that certificate transport is not available in RADIUS, but goes on to say that it could be added. The protocol [2] actually makes an attempt to specify how this is to be done, in section 4.3.2.3 of [2], using a CMS-data attribute, based in large part upon RFC 2630. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. Other relevant work in the area of certificate support in RADIUS may be found in an expired work in progress, "RADIUS X.509 Certificate Extensions" [5]. The document claims "F", but in light of the specifics of the protocol [2], the evaluator awards "P".
1.1.7 证书传输—文档[1]指出RADIUS中不提供证书传输，但还表示可以添加证书传输。在[2]的第4.3.2.3节中，协议[2]实际上试图使用CMS数据属性，在很大程度上以RFC 2630为基础，指定如何实现这一点。评估人员目前尚未调查RFC 2630对AAA工作的适用性。RADIUS证书支持领域的其他相关工作可在已过期的进行中工作“RADIUS X.509证书扩展”[5]中找到。该文件声称为“F”，但根据方案[2]的具体规定，评估人授予“P”。
1.1.8 Reliable AAA Transport - The document [1] indicates that RADIUS provides partial compliance with the requirements of the original AAA requirements document. However, in [3], the requirement has been simplified to "resilience against packet loss". Once again, the evaluator finds that the protocol [2] meets this criteria on a hop-by-hop basis, but fails to effectively address these issues in a proxy-chain environment. The document claims "P", and the evaluator awards "F".
1.1.8 可靠的AAA运输-文件[1]表明RADIUS部分符合原始AAA要求文件的要求。然而，在[3]中，该要求被简化为“抗数据包丢失的弹性”。评估者再次发现，协议[2]在逐跳的基础上满足此标准，但在代理链环境中无法有效解决这些问题。该文件称为“P”，评估人授予“F”。
1.1.9 Run over IPv4 - RADIUS is widely deployed over IPv4. The document claims "T", and the evaluator concurs.
1.1.9 在IPv4上运行-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]指出，采用数量有限的新RADIUS属性来支持IPv6是很简单的。这种讨论已经在RADIUS工作组的邮件列表中出现，尽管该工作组正在关闭。该文件称为“P”，评估人同意。
1.1.11 Support Proxy and Routing Brokers - The document [1] indicates that RADIUS is widely deployed in proxy-chains of RADIUS servers. This is equivalent to the Proxy Broker case, but the Routing Broker case is a different requirement. The protocol [2] does not describe any detail of how a Routing Broker might be accommodated, although it opens the door by indicating that the RADIUS++ protocol is peer-to-peer, rather than client/server. The document claims "P", and the evaluator awards "F".
1.1.11 支持代理和路由代理-文档[1]表明RADIUS广泛部署在RADIUS服务器的代理链中。这相当于代理代理代理案例，但路由代理案例是不同的需求。协议[2]没有描述如何容纳路由代理的任何细节，尽管它打开了大门，指出RADIUS++协议是对等的，而不是客户端/服务器。该文件称为“P”，评估人授予“F”。
1.1.12 Auditability - The document [1] indicates no compliance with this requirement. The document claims "F", and the evaluator concurs.
1.1.12 可审核性-文件[1]表明不符合此要求。文件要求“F”，评估人同意。
1.1.13 Shared Secret Not Required - The document [1] indicates that RADIUS may effectively skirt the requirement of application-layer security by using a value of "zero" for the pre-shared secret. While this is a bit creative, it does seem to meet the requirement. The document claims "T" and the evaluator concurs.
1.1.13 不需要共享机密-文件[1]指出，RADIUS可以通过对预共享机密使用“零”值来有效规避应用层安全性的要求。虽然这有点创造性，但它似乎符合要求。文件声称“T”，评估人同意。
1.1.14 Ability to Carry Service Specific Attributes - RADIUS has a well defined Vendor-Specific Attribute, which, when properly used, does indeed provide for the ability to transport service-specific attributes. The document claims "T", and the evaluator concurs.
1.1.14 携带特定于服务的属性的能力-RADIUS有一个定义良好的特定于供应商的属性，如果使用得当，它确实提供了传输特定于服务的属性的能力。文件声称“T”，评估人同意。
1.2 Authentication Requirements
1.2 认证要求
1.2.1 NAI Support - The document [1] indicates that RADIUS specifies the NAI as one of the suggested formats for the User-Name attribute. The document claims "T", and the evaluator agrees.
1.2.1 NAI支持—文档[1]指出RADIUS将NAI指定为用户名属性的建议格式之一。文件声称“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支持—在RADIUS中广泛部署CHAP支持。该文件声称[1]“T”，评估人同意。
1.2.3 EAP Support - The document [1] indicates that EAP support in RADIUS is specified in [4]. The document claims [1] "T", and the evaluator concurs.
1.2.3 EAP支持-文件[1]表明[4]中指定了半径范围内的EAP支持。该文件声称[1]“T”，评估人同意。
1.2.4 PAP/Clear-text Passwords - The document [1] indicates that RADIUS provides protection of clear-text passwords on a hop-by-hop basis. The protocol [2] indicates how additional data confidentiality may be obtained in section 4.3.2.2 of [2], using a CMS-data attribute, based in large part upon RFC 2630. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. The document claims [1] "F", but in light of the specifics of the protocol [2], the evaluator awards "P".
1.2.4 PAP/明文密码-文件[1]指出RADIUS提供逐跳明文密码保护。协议[2]说明了如何在[2]的第4.3.2.2节中使用CMS数据属性获得额外的数据机密性，该属性在很大程度上基于RFC 2630。评估人员目前尚未调查RFC 2630对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 按需重新验证-文档[1]表明RADIUS可以通过从服务器发送到客户端的访问质询消息按需完成重新验证。一旦客户端接收到Access Accept消息，evaluator不认为这可能适用于给定会话。该文件称为“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 不进行身份验证的授权-此要求适用于协议规范，要求在授权请求中不需要非必要的身份验证凭据。在中提供授权的实际决定
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 静态和动态IP地址分配-文档[1]表明RADIUS可以分配IPv4地址，并且可以轻松扩展以分配IPv6地址（请参阅第1.1.10节）。然而，更值得关注的是静态地址与动态地址的问题。如果动态地址的含义与DHCP相同，那么RADIUS传统上没有解决资源管理问题。该文件称为“P”，评估人同意。
1.3.2 RADIUS Gateway Capability - The document [1] maintains that a RADIUS++ to RADIUS gateway is pretty much a tautology. The document claims "T", and the evaluator concurs.
1.3.2 RADIUS网关功能—文档[1]认为RADIUS++到RADIUS网关几乎是一个同义反复。文件声称“T”，评估人同意。
1.3.3 Reject Capability - The document [1] maintains that RADIUS Proxy Servers, and potentially RADIUS++ Routing Brokers, have the ability to reject requests based on local policy. The document claims "T" and the evaluator concurs.
1.3.3 拒绝功能—文档[1]认为RADIUS代理服务器和潜在的RADIUS++路由代理能够基于本地策略拒绝请求。文件声称“T”，评估人同意。
1.3.4 Preclude Layer 2 Tunneling - The document [1] indicates that [6] defines support for layer two tunneling in RADIUS. The document claims "T", and the evaluator concurs.
1.3.4 排除第2层隧道-文件[1]指出[6]定义了对半径范围内第2层隧道的支持。文件声称“T”，评估人同意。
1.3.5 Reauth on Demand - The document [1] indicates that RADIUS provides this feature by means of the Session-Timeout and Termination- Action attributes. While this may, in fact, be sufficient to provide periodic re-authorization, it would not provide re- authorization on demand. The protocol [2] does not address this further. The document claims "P", and the evaluator awards "F".
1.3.5 按需重新授权-文档[1]指出RADIUS通过会话超时和终止操作属性提供此功能。事实上，这可能足以提供定期重新授权，但它不会根据需要提供重新授权。协议[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 对ACL的支持—文档[1]描述了RADIUS中用于传递[3]中描述的访问控制的属性。其中某些（如QoS）目前未在RADIUS中定义，但可以轻松定义为新的RADIUS属性。该文件称为“P”，评估人同意。
1.3.7 State Reconciliation - The document [1] addresses each of the sub- items, as listed in the original AAA requirements document. In reviewing the document against the modified requirements of [3], there is still an issue with server-initiated state reconciliation messages. While the protocol [2] makes provision for such messages, as servers are allowed to initiate protocol dialogs, no detailed
1.3.7 状态调节-文件[1]涉及原始AAA要求文件中列出的每个子项。根据[3]的修改要求审查文档时，服务器启动的状态调节消息仍然存在问题。虽然协议[2]对此类消息作出了规定，但由于允许服务器启动协议对话框，因此没有详细说明
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".
提供了消息格式。这是一个传统上半径很小的地区。该文件称为“P”，评估人授予“F”。
1.3.8 Unsolicited Disconnect - Much of the discussion from the previous section applies to this section. The document [1] claims "F", and the evaluator concurs.
1.3.8 主动断开-上一节的大部分讨论适用于本节。文件[1]声称为“F”，评估人同意。
1.4 Accounting Requirements
1.4 会计要求
1.4.1 Real Time Accounting - RADIUS Accounting is widely deployed and functions within the definition of real time contained in [3]. The document [1] claims "T", and the evaluator concurs.
1.4.1 实时记帐-RADIUS记帐被广泛部署，其功能在[3]中包含的实时定义范围内。文件[1]声称“T”，评估人同意。
1.4.2 Mandatory Compact Encoding - RADIUS Accounting contains TLVs for relevant accounting information, each of which is fairly compact. Note that the term "bloated" in [3] is somewhat subjective. The document [1] claims "T", and the evaluator concurs.
1.4.2 强制压缩编码-RADIUS Accounting包含用于相关会计信息的TLV，每个TLV都相当紧凑。请注意，[3]中的术语“膨胀”有些主观。文件[1]声称“T”，评估人同意。
1.4.3 Accounting Record Extensibility - RADIUS Accounting may be extended by means of new attributes or by using the Vendor-Specific attribute. While it has been argued that the existing attribute number space is too small for the required expansion capabilities, the protocol [2] addresses this problem in section 3.0, and its subsections, of [2]. The document [1] claims "T", and the evaluator concurs.
1.4.3 会计记录可扩展性-RADIUS会计可以通过新属性或使用特定于供应商的属性进行扩展。虽然有人认为现有的属性号空间对于所需的扩展能力来说太小，但协议[2]在[2]的第3.0节及其子节中解决了这个问题。文件[1]声称“T”，评估人同意。
1.4.4 Batch Accounting - RADIUS has no explicit provisions for batch accounting, nor does the protocol [2] address how this feature might be accomplished. The document [1] claims "F", and the evaluator concurs.
1.4.4 批次核算-RADIUS没有关于批次核算的明确规定，协议[2]也没有说明如何实现此功能。文件[1]声称为“F”，评估人同意。
1.4.5 Guaranteed Delivery - RADIUS Accounting is widely deployed and provides guaranteed delivery within the context of the required application-level acknowledgment. The document [1] claims "T", and the evaluator concurs.
1.4.5 保证交付-RADIUS 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 记帐时间戳-文档[1]表明此功能在[4]中指定为事件时间戳属性。该文件声称[1]“T”，评估人同意。
1.4.7 Dynamic Accounting - The document [1] indicates that this requirement is partially met using the accounting interim update message as specified in [4]. In addition, there was work in the RADIUS WG regarding session accounting extensions that has not been included in [4], i.e., some expired works in progress. The document claims [1] "P", and the evaluator concurs.
1.4.7 动态记帐-文档[1]表明，使用[4]中指定的记帐临时更新消息部分满足了此要求。此外，RADIUS工作组中有一项关于会话记帐扩展的工作未包含在[4]中，即一些已过期的工作正在进行中。文件声称[1]“P”，评估人同意。
1.5 MOBILE IP Requirements
1.5 移动IP要求
1.5.1 Encoding of MOBILE IP Registration Messages - The document [1] claims "F", and the evaluator concurs.
1.5.1 移动IP注册消息的编码-文件[1]声明为“F”，评估人同意。
1.5.2 Firewall Friendly - The document [1] indicates that RADIUS deployment is know to have occurred in fire-walled environments. The document claims "T", and the evaluator concurs.
1.5.2 防火墙友好型-文档[1]指出，已知RADIUS部署发生在防火墙环境中。文件声称“T”，评估人同意。
1.5.3 Allocation of Local Home Agent - The document [1] claims "F", and the evaluator concurs.
1.5.3 本地代理的分配-文件[1]声称为“F”，评估人同意。
2. Summary Discussion
2. 简要讨论
The document [1] and the protocol [2] suffer from having been written in a short time frame. While the protocol does provide specific guidance on certain issues, citing other relevant documents, it is not a polished protocol specification, with detailed packet format diagrams. There is a pool of prior work upon which the RADIUS++ protocol may draw, in that many of the concepts of Diameter were first postulated as works in progress within the RADIUS WG, in an attempt to "improve" the RADIUS protocol. All of these works in progress have long since expired, however.
文档[1]和协议[2]由于在短时间内编写而受到影响。虽然该协议引用了其他相关文件，但它并不是一个完善的协议规范，并附有详细的数据包格式图。RADIUS++协议可以借鉴之前的大量工作，因为许多直径的概念首先假设为RADIUS WG中正在进行的工作，以尝试“改进”RADIUS协议。然而，所有这些正在进行的工程早已过期。
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和NASREQ工作组的程序中得到了充分的记录。从技术上讲，改造RADIUS以解决这些问题是可能的。然而，将要提出的一个问题是：“完成的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.
部分推荐。从本次提交中可能学到的是，在直径方面采用更符合半径的半径兼容模式是可行的。
Evaluation of Diameter against the AAA Requirements PRO Evaluation Evaluator - Basavaraj Patil
根据AAA要求评估直径专业评估师-Basavaraj Patil
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]是“Diameter移动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
Evaluator's note : The Diameter compliance document [8] claims Total
"T" compliance with all the requirements except : - 1.2.5 - 1.5.2
Section 1 - Per item discussion
第1节-每项讨论
1.1 General Requirements
1.1 一般要求
1.1.1 Scalability
1.1.1 可伸缩性
Diameter is an evolution of RADIUS and has taken into consideration all the lessons learned over many years that RADIUS has been in service. The use of SCTP as the transport protocol reduces the need for multiple proxy servers (Sec 3.1.1 Proxy Support of [1]) as well as removing the need for application level acks. The use and support of forwarding and redirect brokers enhances scalability. Evaluator concurs with the "T" compliance on this requirement.
直径是RADIUS的一个演变过程，它考虑了RADIUS多年来的所有经验教训。使用SCTP作为传输协议减少了对多个代理服务器的需求（第3.1.1节[1]的代理支持），也消除了对应用程序级ACK的需求。转发和重定向代理的使用和支持增强了可伸缩性。评估人同意“T”符合此要求。
1.1.2 Fail-over
1.1.2 故障转移
Again with the use of SCTP, Diameter is able to detect disconnect indications upon which it switches to an alternate server (Sec 4.0 [6]). Also Requests and Responses do not have to follow the same path and this increases the reliability. Evaluator concurs with the "T" compliance on this requirement.
同样，通过使用SCTP，Diameter能够检测到断开指示，然后切换到备用服务器（第4.0[6]节）。此外，请求和响应不必遵循相同的路径，这提高了可靠性。评估人同意“T”符合此要求。
1.1.3 Mutual Authentication
1.1.3 相互认证
The compliance document quotes the use of symmetric transforms for mutual authentication between the client and server (Sec 7.1 of [6]). The use of IPSec as an underlying security mechanism and thereby use the characteristics of IPSec itself to satisfy this requirement is also quoted. Evaluator concurs with the "T" compliance on this requirement.
合规性文件引用了对称转换用于客户机和服务器之间的相互认证（第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节详细介绍了如何实现这一点。评估人同意“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.
这个要求似乎来自于直径。参考文献[7]详细解释了使用加密消息语法（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.
同样，通过使用CMS数据AVP，定义为这些类型属性的对象允许传输证书。评估人同意“T”符合此要求。
1.1.8 Reliable AAA Transport
1.1.8 可靠的AAA传输
Diameter recommends that the protocol be run over SCTP. SCTP provides the features described for a reliable AAA transport. Although the compliance is not a perfect fit for the definition of this tag item, it is close enough and the functionality achieved by using SCTP is the same. Evaluator concurs with the "T" compliance on this requirement.
Diameter建议协议在SCTP上运行。SCTP提供了所描述的用于可靠AAA传输的功能。尽管合规性并不完全适合此标记项的定义，但它已经足够接近了，并且通过使用SCTP实现的功能是相同的。评估人同意“T”符合此要求。
1.1.9 Run over IPv4
1.1.9 在IPv4上运行
Is an application layer protocol and does not depend on the underlying version of IP. Evaluator concurs with the "T" compliance on this requirement.
是一种应用层协议，不依赖于IP的底层版本。评估人同意“T”符合此要求。
1.1.10 Run over IPv6
1.1.10 在IPv6上运行
Is an application layer protocol and does not depend on the underlying version of IP. Evaluator concurs with the "T" compliance on this requirement.
是一种应用层协议，不依赖于IP的底层版本。评估人同意“T”符合此要求。
1.1.11 Support Proxy and Routing Brokers
1.1.11 支持代理和路由代理
Section 3.1.1/2 of the framework document [1] provides an explanation of how Diameter supports proxy and routing brokers. In fact it almost appears as though the requirement for a routing broker came from Diameter. Evaluator concurs with the "T" compliance on this requirement.
框架文件[1]第3.1.1/2节解释了Diameter如何支持代理和路由代理。事实上，似乎对路由代理的需求来自Diameter。评估人同意“T”符合此要求。
1.1.12 Auditability
1.1.12 可审计性
With the use of CMS-Data AVP [7] a trail is created when proxies are involved in the transaction. This trail can provide auditability. Evaluator concurs with the "T" compliance on this requirement.
通过使用CMS数据AVP[7]，当代理参与事务时，会创建一条跟踪。此跟踪可以提供可审核性。评估人同意“T”符合此要求。
1.1.13 Shared Secret Not Required
1.1.13 不需要共享秘密
With the use of IPSec as the underlying security mechanism, Diameter does not require the use of shared secrets for message authentication. Evaluator concurs with the "T" compliance on this requirement.
通过使用IPSec作为底层安全机制，Diameter不需要使用共享机密进行消息身份验证。评估人同意“T”符合此要求。
1.1.14 Ability to Carry Service Specific Attributes
1.1.14 能够携带特定于服务的属性
The base protocol [6] is defined by Diameter and any one else can define specific extensions on top of it. Other WGs in the IETF can design an extension on the base protocol with specific attributes and have them registered by IANA. Evaluator concurs with the "T" compliance on this requirement.
基本协议[6]由Diameter定义，任何其他协议都可以在其上定义特定的扩展。IETF中的其他工作组可以在基本协议上设计具有特定属性的扩展，并由IANA注册。评估人同意“T”符合此要求。
1.2 Authentication Requirements
1.2 认证要求
1.2.1 NAI Support
1.2.1 NAI支持
The base protocol [6] defines an AVP that can be used to support NAIs. Diameter goes one step further by doing Message forwarding based on destination NAI AVPs. Evaluator concurs with the "T" compliance on this requirement.
基本协议[6]定义了可用于支持NAI的AVP。Diameter更进一步，基于目标NAI AVP进行消息转发。评估人同意“T”符合此要求。
1.2.2 CHAP Support
1.2.2 CHAP支持
Reference [2] section 3.0 describes the support for CHAP. Evaluator concurs with the "T" compliance on this requirement.
参考文献[2]第3.0节描述了对第二章的支持。评估人同意“T”符合此要求。
1.2.3 EAP Support
1.2.3 EAP支持
Reference [2] section 4.0 describes the support for EAP. Evaluator concurs with the "T" compliance on this requirement.
参考文献[2]第4.0节描述了对EAP的支持。评估人同意“T”符合此要求。
1.2.4 PAP/Clear-text Passwords
1.2.4 PAP/明文密码
Reference [2] section 3.1.1.1 describes the support for PAP. Evaluator concurs with the "T" compliance on this requirement.
参考文献[2]第3.1.1.1节描述了PAP的支持。评估人同意“T”符合此要求。
1.2.5 Reauthentication on demand
1.2.5 按需重新验证
The use of Session-Timeout AVP as the mechanism for reauthentication is claimed by the compliance document. However no direct references explaining this in the base protocol [6] document were found.
合规性文档声称使用会话超时AVP作为重新验证的机制。然而，在基本协议[6]文件中未找到解释这一点的直接参考文献。
Evaluator deprecates the compliance on this to a "P"
Evaluator将此合规性不推荐为“P”
Note: However this is a trivial issue.
注意：然而，这是一个微不足道的问题。
1.2.6 Authorization w/o Authentication
1.2.6 不进行身份验证的授权
Diameter allows requests to be sent without having any authentication information included. A Request-type AVP is defined in [2] and it can specify authorization only without containing any authentication. Evaluator concurs with the "T" compliance on this requirement.
Diameter允许在不包含任何身份验证信息的情况下发送请求。[2]中定义了请求类型AVP，它只能指定授权，而不包含任何身份验证。评估人同意“T”符合此要求。
1.3 Authorization Requirements
1.3 授权要求
1.3.1 Static and Dynamic IP Addr Assignment
1.3.1 静态和动态IP地址分配
The base protocol includes an AVP for carrying the address. References [6.2.2 of 2] and [4.5 of 5] provide detailed explanations of how this can be done. Evaluator concurs with the "T" compliance on this requirement.
基本协议包括用于承载地址的AVP。参考文献[6.2.2/2]和[4.5/5]详细解释了如何实现这一点。评估人同意“T”符合此要求。
1.3.2 RADIUS Gateway Capability
1.3.2 RADIUS网关能力
One of the basic facets of Diameter is to support backward compatibility and act as a RADIUS gateway in certain environments. Evaluator concurs with the "T" compliance on this requirement.
Diameter的一个基本方面是支持向后兼容性，并在某些环境中充当RADIUS网关。评估人同意“T”符合此要求。
1.3.3 Reject Capability
1.3.3 拒绝能力
Based on the explanation provided in the compliance document for this requirement evaluator concurs with the "T" compliance on this requirement.
根据本要求合规文件中提供的解释，评估人员同意本要求的“T”合规性。
1.3.4 Preclude Layer 2 Tunneling
1.3.4 排除第2层隧道
Ref [2] defines AVPs supporting L2 tunnels Evaluator concurs with the "T" compliance on this requirement.
参考文献[2]定义了支持L2隧道的AVP，评估者同意“T”符合此要求。
1.3.5 Reauth on Demand
1.3.5 按需重新授权
A session timer defined in [6] is used for reauthorization. However Diameter allows reauthorization at any time. Since this is a peer-to-peer type of protocol any entity can initiate a reauthorization request. Evaluator concurs with the "T" compliance on this requirement.
[6]中定义的会话计时器用于重新授权。但是，直径允许在任何时候重新授权。由于这是一种对等类型的协议，任何实体都可以发起重新授权请求。评估人同意“T”符合此要求。
1.3.6 Support for ACLs
1.3.6 对ACL的支持
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.
直径定义了两种方法。一个支持RADIUS的向后兼容性，另一个支持使用标准AVP和编码在其中的过滤器。评估人同意“T”符合此要求。
1.3.7 State Reconciliation
1.3.7 国家和解
A long explanation on each of the points defined for this tag item in the requirements document. Evaluator concurs with the "T" compliance for this requirement.
在需求文档中对该标签项定义的每个点进行详细解释。评估人同意该要求的“T”合规性。
1.3.8 Unsolicited Disconnect
1.3.8 主动断开
The base protocol [6] defines a set of session termination messages which can be used for unsolicited disconnects. Evaluator concurs with the "T" compliance on this requirement.
基本协议[6]定义了一组会话终止消息，可用于主动断开连接。评估人同意“T”符合此要求。
1.4 Accounting Requirements
1.4 会计要求
1.4.1 Real Time Accounting
1.4.1 实时会计
Evaluator concurs with the "T" compliance based on explanations in [4].
根据[4]中的解释，评估人同意“T”合规性。
1.4.2 Mandatory Compact Encoding
1.4.2 强制压缩编码
Use of Accounting Data Interchange Format (ADIF)-Record-AVP for compact encoding of accounting data. Evaluator concurs with the "T" compliance.
会计数据交换格式（ADIF）的使用.会计数据压缩编码用记录AVP。评估人同意“T”合规性。
1.4.3 Accounting Record Extensibility
1.4.3 会计记录扩展性
ADIF can be extended. Evaluator concurs with the "T" compliance.
ADIF可以扩展。评估人同意“T”合规性。
1.4.4 Batch Accounting
1.4.4 批量核算
Sec 1.2 of [4] provides support for batch accounting.
[4]的第1.2节提供了对批量核算的支持。
1.4.5 Guaranteed Delivery
1.4.5 保证交货
Sections 2.1/2 of [4] describe messages that are used to guarantee delivery of accounting records. Evaluator concurs with the "T" compliance.
[4]第2.1/2节描述了用于保证会计记录交付的信息。评估人同意“T”合规性。
1.4.6 Accounting Timestamps
1.4.6 会计时间戳
Timestamp AVP [6] is present in all accounting messages. Evaluator concurs with the "T" compliance.
所有记帐消息中都存在时间戳AVP[6]。评估人同意“T”合规性。
1.4.7 Dynamic Accounting
1.4.7 动态会计
Interim accounting records equivalent to a call-in-progress can be sent periodically. Evaluator concurs with the "T" compliance.
可以定期发送相当于进行中的呼叫的临时会计记录。评估人同意“T”合规性。
1.5 MOBILE IP Requirements
1.5 移动IP要求
1.5.1 Encoding of MOBILE IP Registration Messages
1.5.1 移动IP注册信息的编码
Ref [5] provides details of how Diameter can encode MIP messages. Evaluator concurs with the "T" compliance.
参考文献[5]提供了Diameter如何编码MIP消息的详细信息。评估人同意“T”合规性。
1.5.2 Firewall Friendly
1.5.2 防火墙友好
Some handwaving here and a possible way of solving the firewall problem with a Diameter proxy server. Document claims "T", evaluator deprecates it to a "P"
这里有一些手工操作，这是使用Diameter代理服务器解决防火墙问题的可能方法。文档声明为“T”，评估者不推荐使用“P”
1.5.3 Allocation of Local Home Agent
1.5.3 本地家庭代理的分配
Diameter can assign a local home agent in a visited network in conjunction with the FA in that network. Evaluator concurs with the "T"
Diameter可以在访问的网络中与该网络中的FA一起分配本地归属代理。评估人同意“T”
Summary Recommendation
简要建议
Diameter is strongly recommended as the AAA protocol. The experience gained from RADIUS deployments has been put to good use in the design of this protocol. It has also been designed with extensibility in mind thereby allowing different WGs to develop their own specific extension to satisfy their requirements. With the use of SCTP as the transport protocol, reliability is built in. Security has been addressed in the design of the protocol and issues that were discovered in RADIUS have been fixed. Diameter also is a session based protocol which makes it more scalable. The support for forwarding and redirect brokers is well defined and this greatly improves the scalability aspect of the protocol.
强烈建议将直径作为AAA协议。从RADIUS部署中获得的经验在该协议的设计中得到了很好的应用。它的设计还考虑了可扩展性，从而允许不同的工作组开发自己的特定扩展以满足其需求。通过使用SCTP作为传输协议，可靠性是内在的。在协议的设计中已经解决了安全性问题，在RADIUS中发现的问题已经解决。Diameter也是一种基于会话的协议，它使其更具可扩展性。对转发和重定向代理的支持定义良好，这大大提高了协议的可伸缩性。
Lastly the protocol has been implemented by at least a few people and interop testing done. This in itself is a significant step and a positive point for Diameter to be the AAA protocol.
最后，该协议已经由至少几个人实现，并进行了互操作测试。这本身就是一个重要的步骤，也是Diameter成为AAA协议的一个积极点。
Evaluation of Diameter against the AAA Requirements CON Brief Evaluator: Barney Wolff
根据AAA要求对直径进行评估。简要评估人：Barney Wolff
Section 1 - Per item discussion
第1节-每项讨论
1.1 General Requirements
1.1 一般要求
1.1.1 Scalability - P (was T) The evaluator is concerned with scalability to the small, not to the large. Diameter/SCTP may prove difficult to retrofit to existing NAS equipment.
1.1.1 可伸缩性-P（wast）评估者关注的是小范围的可伸缩性，而不是大范围的可伸缩性。Diameter/SCTP可能难以改装到现有NAS设备。
1.1.2 Fail-over - P (was T) SCTP gives an indication of peer failure, but nothing in any Diameter or SCTP document the evaluator was able to find even mentions how or when to switch back to a primary server to which communication was lost. After a failure, the state machines end in a CLOSED state and nothing seems to trigger exit from that state. It was not clear whether a server, on rebooting, would initiate an SCTP connection to all its configured clients. If not, and in any case when the communication failure was in the network rather than in the server, the client must itself, after some interval, attempt to re-establish communication. But no such guidance is given.
1.1.2 故障转移-P（WAST）SCTP给出了对等故障的指示，但在任何Diameter或SCTP文档中，评估者都找不到任何内容，甚至没有提到如何或何时切换回失去通信的主服务器。故障发生后，状态机以关闭状态结束，并且似乎没有任何东西触发退出该状态。不清楚服务器在重新启动时是否会启动到其所有配置客户端的SCTP连接。如果不是，并且在任何情况下，当通信故障发生在网络中而不是服务器中时，客户端必须在一段时间间隔后尝试重新建立通信。但没有给出这样的指导。
Of course, the requirement itself fails to mention the notion of returning to a recovered primary. That is a defect in the requirement. The evaluator has had unfortunate experience with a vendor's RADIUS implementation that had exactly the defect that it often failed to notice recovery of the primary.
当然，需求本身没有提到返回到已恢复的主服务器的概念。这是要求中的一个缺陷。评估人员在供应商的RADIUS实施中有过不幸的经历，该实施存在经常未能注意到主服务器恢复的缺陷。
1.1.3 Mutual Authentication - T
1.1.3 相互认证-T
1.1.4 Transmission Level Security - T
1.1.4 传输级安全性-T
1.1.5 Data Object Confidentiality - P (was T). Yes, the CMS data type is supported. But the work in progress, "Diameter Strong Security Extension", says:
1.1.5 数据对象机密性-P（wast）。是，支持CMS数据类型。但正在进行的工作“Diameter Strong Security Extension”表示：
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.
考虑到非对称转换操作的成本很高，Diameter服务器可能只希望在处理域间服务器时使用它们，如图3所示。这种配置通常是可取的，因为给定管理域中的Diameter实体可能内在地相互信任。此外，希望将此功能移动到边缘，因为NASE不一定具有执行昂贵密码操作的CPU能力。
Given all the fuss that has been made about "end-to-end" confidentiality (which really means "NAS-to-home_server"), the evaluator finds it absurd that the proposed solution is acknowledged to be unsuited to the NAS.
考虑到人们对“端到端”保密性（实际上是指“NAS-to-home_服务器”）大惊小怪，评估人员认为所提出的解决方案不适合NAS是荒谬的。
1.1.6 Data Object Integrity - P (was T). See above.
1.1.6 数据对象完整性-P（wast）。见上文。
1.1.7 Certificate Transport - T
1.1.7 证书传输-T
1.1.8 Reliable AAA Transport - T
1.1.8 可靠的AAA传输-T
1.1.9 Run over IPv4 - T
1.1.9 在IPv4-T上运行
1.1.10 Run over IPv6 - T
1.1.10 在IPv6-T上运行
1.1.11 Support Proxy and Routing Brokers - T
1.1.11 支持代理和路由代理-T
1.1.12 Auditability - T (based on our interpretation as non-repudiation, rather than the definition given in reqts)
1.1.12 可审计性-T（基于我们对不可抵赖性的解释，而非需求中给出的定义）
1.1.13 Shared Secret Not Required - T
1.1.13 不需要共享秘密-T
1.1.14 Ability to Carry Service Specific Attributes - T
1.1.14 具有服务特定属性的能力-T
1.2 Authentication Requirements
1.2 认证要求
1.2.1 NAI Support - T
1.2.1 NAI支持-T
1.2.2 CHAP Support - T
1.2.2 CHAP支持-T
1.2.3 EAP Support - T
1.2.3 EAP支持-T
1.2.4 PAP/Clear-text Passwords - T
1.2.4 PAP/明文密码-T
1.2.5 Reauthentication on demand - P (was T). No mechanism was evident for the server to demand a reauthentication, based for example on detection of suspicious behavior by the user. Session-timeout is not sufficient, as it must be specified at the start.
1.2.5 按需重新验证-P（WAST）。服务器没有明显的机制要求重新验证，例如基于用户检测到的可疑行为。会话超时不足，因为必须在开始时指定。
1.2.6 Authorization w/o Authentication - T
1.2.6 不进行身份验证的授权-T
1.3 Authorization Requirements
1.3 授权要求
1.3.1 Static and Dynamic IP Addr Assignment - T
1.3.1 静态和动态IP地址分配-T
1.3.2 RADIUS Gateway Capability - P (was T). RADIUS has evolved from the version on which Diameter was based. EAP is a notable case where the convention that the Diameter attribute number duplicates the RADIUS one is violated. No protocol, not even RADIUS++, can claim a T on this.
1.3.2 RADIUS网关能力-P（WAST）。半径是从直径所基于的版本演变而来的。EAP是一个值得注意的案例，违反了直径属性编号与半径属性编号重复的约定。没有任何协议，即使是RADIUS++，可以在这个问题上声明T。
1.3.3 Reject Capability - T (The evaluator fails to understand how any AAA protocol could rate anything other than T on this.)
1.3.3 拒绝能力-T（评估者无法理解任何AAA协议如何在此基础上对除T以外的任何内容进行评级。）
1.3.4 Preclude Layer 2 Tunneling - T
1.3.4 排除第2层隧道-T
1.3.5 Reauth on Demand - P (was T). As with reauthentication, there is no evident mechanism for the server to initiate this based on conditions subsequent to the start of the session.
1.3.5 按需重新授权-P（WAST）。与重新身份验证一样，服务器没有明显的机制根据会话启动后的条件来启动此验证。
1.3.6 Support for ACLs - P (was T). The evaluator finds the Filter-Rule AVP laughably inadequate to describe filters. For example, how would it deal with restricting SMTP to a given server, unless all IP options are forbidden so the IP header length is known? No real NAS could have such an impoverished filter capability, or it would not survive as a product.
1.3.6 对ACLs-P（wast）的支持。评估者发现过滤器规则AVP可笑地不足以描述过滤器。例如，它将如何处理将SMTP限制到给定服务器的问题，除非所有IP选项都被禁止，以便知道IP头的长度？任何真正的NAS都不可能有如此贫乏的过滤能力，否则它将无法作为一种产品生存下来。
1.3.7 State Reconciliation - P (was T). It is difficult for the evaluator to understand how this is to work in a multi-administration situation, or indeed in any proxy situation. Furthermore, SRQ with no session-id is defined to ask for info on all sessions, not just those "owned" by the requester.
1.3.7 国家和解-P（was T）。评估人员很难理解这在多重管理情况下，或者在任何代理情况下是如何工作的。此外，没有会话id的SRQ被定义为询问所有会话的信息，而不仅仅是请求者“拥有”的会话。
1.3.8 Unsolicited Disconnect - T
1.3.8 主动断开-T
1.4 Accounting Requirements
1.4 会计要求
1.4.1 Real Time Accounting - T
1.4.1 实时会计-T
1.4.2 Mandatory Compact Encoding - T
1.4.2 强制压缩编码-T
1.4.3 Accounting Record Extensibility - T
1.4.3 会计记录扩展性-T
1.4.4 Batch Accounting - P (was T). The evaluator suspects that simply sending multiple accounting records in a single request is not how batch accounting should or will be done.
1.4.4 批量核算-P（wast）。评估人员怀疑，在一个请求中发送多个会计记录并不是批量会计应该或将要进行的方式。
1.4.5 Guaranteed Delivery - T
1.4.5 保证交货-T
1.4.6 Accounting Timestamps - T (The evaluator notes with amusement that NTP time cycles in 2036, not 2038 as claimed in the Diameter drafts. It's Unix time that will set the sign bit in 2038.)
1.4.6 记帐时间戳-T（计算器有趣地注意到，NTP时间周期为2036年，而不是Diameter草稿中声称的2038年。将在2038年设置符号位的是Unix时间。）
1.4.7 Dynamic Accounting - T
1.4.7 动态会计-T
1.5 MOBILE IP Requirements
1.5 移动IP要求
1.5.1 Encoding of MOBILE IP Registration Messages - T
1.5.1 移动IP注册消息的编码-T
1.5.2 Firewall Friendly - F (was T). Until such time as firewalls are extended to know about or proxy SCTP, it is very unlikely that SCTP will be passed. Even then, the convenient feature of being able
1.5.2 防火墙友好-F（wast）。在防火墙扩展到了解SCTP或代理SCTP之前，SCTP不太可能通过。即使如此，方便的特点是
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.
从任何端口发送请求，并将应答返回到该端口，这意味着简单的端口筛选器是不够的，需要状态性。真正的友谊需要源端口和目标端口都是1812。
1.5.3 Allocation of Local Home Agent - T
1.5.3 本地归属代理的分配-T
2. Summary Discussion
2. 简要讨论
In some areas, Diameter is not completely thought through. In general, real effort has gone into satisfying a stupendous range of requirements.
在某些领域，直径没有完全考虑清楚。总的来说，真正的努力是满足一系列巨大的需求。
3. General Requirements
3. 一般要求
Diameter certainly fails the KISS test. With SCTP, the drafts add up to 382 pages - well over double the size of RADIUS even with extensions. The evaluator sympathizes with the political instinct when faced with a new requirement no matter how bizarre, to say "we can do that" and add another piece of filigree. But the major places where Diameter claims advantage over RADIUS, namely "end-to-end" confidentiality and resource management, are just the places where some hard work remains, if the problems are not indeed intractable.
直径当然不能通过接吻测试。有了SCTP，草稿的总页数达到382页——即使有扩展，也大大超过了RADIUS的两倍。当面对一个新的要求时，无论多么离奇，评估者都会同情这种政治本能，说“我们可以做到”，然后再加上一条花边。但是，Diameter声称比RADIUS更具优势的主要领域，即“端到端”保密性和资源管理，如果这些问题确实不难解决的话，这些领域仍然存在一些艰苦的工作。
More specifically, the evaluator sees no indication that specifying the separate transport protocol provided any advantage to defray the large increase in complexity. Application acks are still required, and no benefit from the transport acks was evident to the evaluator. Nor was there any obvious discussion of why "sequenced in-order" delivery is required, when AAA requests are typically independent. SCTP offers out-of-order delivery, but Diameter seems to have chosen not to use that feature.
更具体地说，评估者看不到任何迹象表明指定单独的传输协议有助于支付复杂性的大幅增加。应用程序确认仍然是必需的，并且对评估人员来说，传输确认没有明显的好处。当AAA请求通常是独立的时，也没有任何明显的讨论为什么需要“按顺序排序”交付。SCTP提供无序交付，但Diameter似乎选择不使用该功能。
Whether TLV encoding or ASN.1/BER is superior is a religious question, but Diameter manages to require both, if the "strong" extension is implemented. The evaluator has a pet peeve with length fields that include the header, making small length values invalid, but that is a minor point.
TLV编码或ASN.1/BER是否更优越是一个宗教问题，但如果实现了“强”扩展，Diameter设法要求两者兼而有之。evaluator有一个包含标题的长度字段，使小长度值无效，但这是一个次要问题。
Finally, interoperability would be greatly aided by defining a standard "dictionary" format by which an implementation could adopt wholesale a set of attributes, perhaps from another vendor, and at least know how to display them. That is one of the advantages of MIBs.
最后，通过定义一个标准的“字典”格式，互操作性将得到极大的帮助，通过该格式，一个实现可以大量采用一组属性（可能来自另一个供应商），并且至少知道如何显示它们。这是MIB的优点之一。
4. Summary Recommendation
4. 简要建议
Diameter is clearly close enough to meeting the myriad requirements that it is an acceptable candidate, though needing some polishing. Whether the vast increase in complexity is worth the increase in functionality over RADIUS is debatable.
直径显然足够接近满足各种要求，是一个可接受的候选者，尽管需要一些抛光。复杂度的大幅增加是否值得RADIUS功能的增加值得商榷。
Evaluation of COPS AAA Requirements PRO Evaluation Evaluator - David Nelson
COPS AAA需求评估专业评估师-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.
参考文献[1]是“COP与AAA NA要求的比较”，也称为“在建工程”。参考文献[2]是RFC 2748 a.k.a.“协议”参考文献[3]是我们修改的AAA评估标准。参考文献[4]是正在进行的“AAA协议：半径、直径和COP之间的比较”。参考文献[5]是“AAA的COPS使用”，正在进行中。
This document uses T to indicate total compliance, P to indicate partial compliance and F to indicate no compliance.
本文件使用T表示完全合规，P表示部分合规，F表示不合规。
Section 1 - Per item discussion
第1节-每项讨论
1.1 General Requirements
1.1 一般要求
1.1.1 Scalability - The document [1] claims "T", and the evaluator concurs.
1.1.1 可伸缩性—文档[1]声称为“T”，评估者同意。
1.1.2 Fail-over - The document [1] claims "T", and the evaluator concurs.
1.1.2 故障转移-文件[1]声明为“T”，评估人同意。
1.1.3 Mutual Authentication - The document claims "T", and the evaluator concurs.
1.1.3 相互认证-文件声明为“T”，评估人同意。
1.1.4 Transmission Level Security - The document [1] indicates that transmission layer security, as defined in [3], is provided in the protocol, using the mechanisms described in [2]. It should be noted that this requirement is now a SHOULD in [3]. The document claims "T", and the evaluator concurs.
1.1.4 传输级安全性-文件[1]指出，协议中使用[2]中描述的机制提供了[3]中定义的传输层安全性。应该注意的是，这一要求现在是[3]中的一个应该。文件声称“T”，评估人同意。
1.1.5 Data Object Confidentiality - The document [1] indicates that end-to-end confidentiality is provided using a CMS-data attribute, based in large part upon RFC 2630. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. The document claims "T", and the evaluator concurs.
1.1.5 数据对象机密性-文件[1]指出，端到端机密性是使用CMS数据属性提供的，在很大程度上基于RFC 2630。评估人员目前尚未调查RFC 2630对AAA工作的适用性。文件声称“T”，评估人同意。
1.1.6 Data Object Integrity - The document [1] indicates that data object integrity is provided using a CMS-data attribute, based in large part upon RFC 2630. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. The document claims "T", and the evaluator concurs.
1.1.6 数据对象完整性-文档[1]指出，数据对象完整性是使用CMS数据属性提供的，在很大程度上基于RFC 2630。评估人员目前尚未调查RFC 2630对AAA工作的适用性。文件声称“T”，评估人同意。
1.1.7 Certificate Transport - The document [1] indicates that certificate transport is provided using a CMS-data attribute, based in large part upon RFC 2630 and RFC 1510. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. The document claims "T", and the evaluator concurs.
1.1.7 证书传输-文档[1]指出，证书传输是使用CMS数据属性提供的，在很大程度上基于RFC 2630和RFC 1510。评估人员目前尚未调查RFC 2630对AAA工作的适用性。文件声称“T”，评估人同意。
1.1.8 Reliable AAA Transport - The document [1] indicates that COPS uses TCP, which certainly meets the requirements for a reliable transport. The document claims "T", and the evaluator concurs.
1.1.8 可靠的AAA传输—文件[1]表明COPS使用TCP，这当然满足可靠传输的要求。文件声称“T”，评估人同意。
1.1.9 Run over IPv4 - The document [1] claims "T", and the evaluator concurs.
1.1.9 在IPv4上运行-文档[1]声明为“T”，并且评估者同意。
1.1.10 Run over IPv6 - The document [1] claims "T", and the evaluator concurs.
1.1.10 在IPv6上运行-文档[1]声明为“T”，评估者同意。
1.1.11 Support Proxy and Routing Brokers - Reasonable detail of proxy operations is provided in [5]. The document [1] claims "T", and the evaluator concurs.
1.1.11 支持代理和路由代理-代理操作的合理细节见[5]。文件[1]声称“T”，评估人同意。
1.1.12 Auditability - The document [1] alludes to a History PIB that would enable auditing without explaining how it would work. The AAA Extension [5] does not provide additional insight. The document claims "T", and the evaluator awards "P".
1.1.12 可审核性-文档[1]暗指历史PIB，该PIB将启用审核，而不解释其工作原理。AAA扩展[5]不提供额外的细节。该文件称为“T”，评估人授予“P”。
1.1.13 Shared Secret Not Required - The document [1] claims "T" and the evaluator concurs.
1.1.13 不需要共享秘密-文件[1]声明为“T”，评估人同意。
1.1.14 Ability to Carry Service Specific Attributes - The document [1] claims "T", and the evaluator concurs.
1.1.14 能够携带特定于服务的属性-文档[1]声称为“T”，评估者同意。
1.2 Authentication Requirements
1.2 认证要求
1.2.1 NAI Support - The document [1] indicates that NAI is to be supported in the Information Model, but notes that for cases where certificates are in use, the more restrictive syntax of RFC 2459 applies. The document claims "T", and the evaluator awards "P".
1.2.1 NAI支持—文档[1]指出信息模型中支持NAI，但注意，对于使用证书的情况，RFC 2459的更严格语法适用。该文件称为“T”，评估人授予“P”。
1.2.2 CHAP Support - The document [1] claims "T", and the evaluator concurs.
1.2.2 CHAP支持-文件[1]声明“T”，评估人同意。
1.2.3 EAP Support - The document [1] claims "T", and the evaluator concurs.
1.2.3 EAP支持——文件[1]声称“T”，评估人同意。
1.2.4 PAP/Clear-text Passwords - The document [1] indicates compliance, presumably using a CMS-data attribute, based in large part upon RFC 2630. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. The document claims "T", and the evaluator concurs.
1.2.4 PAP/明文密码-文档[1]表明符合性，可能使用CMS数据属性，大部分基于RFC 2630。评估人员目前尚未调查RFC 2630对AAA工作的适用性。文件声称“T”，评估人同意。
1.2.5 Reauthentication on demand - The document [1] claims "T", and the evaluator concurs.
1.2.5 按需重新验证-文件[1]声明“T”，评估人同意。
1.2.6 Authorization w/o Authentication - This requirement, as applied to the protocol specification, mandates that non- necessary authentication credentials not be required in a request for authorization. The actual decision to provide authorization in the absence of any authentication resides in the application (e.g. AAA server). The document [1] claims "T", and the evaluator concurs.
1.2.6 不进行身份验证的授权-此要求适用于协议规范，要求在授权请求中不需要非必要的身份验证凭据。在没有任何身份验证的情况下提供授权的实际决定取决于应用程序（例如AAA服务器）。文件[1]声称“T”，评估人同意。
1.3 Authorization Requirements
1.3 授权要求
1.3.1 Static and Dynamic IP Addr Assignment - The document [1] claims "T", and the evaluator concurs.
1.3.1 静态和动态IP地址分配-文件[1]声明为“T”，评估人同意。
1.3.2 RADIUS Gateway Capability - The document [1] claims "T", and in the absence of any detailed discussion of how this is accomplished, in either [1] or [5], the evaluator awards "P".
1.3.2 RADIUS网关能力——文件[1]声称为“T”，在没有详细讨论如何实现的情况下，评估人员在[1]或[5]中授予“P”。
1.3.3 Reject Capability - The document claims [1] "T" and the evaluator concurs.
1.3.3 拒绝能力-文件要求[1]“T”，评估人同意。
1.3.4 Preclude Layer 2 Tunneling - The document [1] claims "T", and in the absence of any detailed discussion of how this is accomplished, in either [1] or [5], the evaluator awards "P".
1.3.4 排除第二层隧道——文件[1]声称为“T”，并且在[1]或[5]中未详细讨论如何实现的情况下，评估人授予“P”。
1.3.5 Reauth on Demand - The document [1] claims "T", and the evaluator concurs.
1.3.5 按需重新授权-文件[1]声称“T”，评估人同意。
1.3.6 Support for ACLs - The document [1] "T", and the evaluator concurs.
1.3.6 对ACL的支持-文档[1]“T”，评估者同意。
1.3.7 State Reconciliation - The document [1] "T", and the evaluator concurs.
1.3.7 国家和解——文件[1]“T”，评估人同意。
1.3.8 Unsolicited Disconnect - The document [1] claims "T", and the evaluator concurs.
1.3.8 非请求断开-文件[1]声称“T”，评估人同意。
1.4 Accounting Requirements
1.4 会计要求
1.4.1 Real Time Accounting - The document [1] claims "T", and the evaluator concurs.
1.4.1 实时会计-文件[1]声称为“T”，评估人同意。
1.4.2 Mandatory Compact Encoding - Note that the term "bloated" in [3] is somewhat subjective. The document [1] claims "T", and the evaluator concurs.
1.4.2 强制压缩编码-注意[3]中的术语“膨胀”有点主观。文件[1]声称“T”，评估人同意。
1.4.3 Accounting Record Extensibility - The document [1] claims "T", and the evaluator concurs.
1.4.3 会计记录可扩展性-文档[1]声明为“T”，评估人同意。
1.4.4 Batch Accounting - The protocol [2] [5] does not address how in detail this feature might be accomplished. The document [1] claims "T", and the awards "P".
1.4.4 批量记帐-协议[2][5]未详细说明如何实现此功能。文件[1]要求赔偿“T”，赔偿金要求赔偿“P”。
1.4.5 Guaranteed Delivery - Guaranteed delivery is provided by TCP. The document [1] claims "T", and the evaluator concurs.
1.4.5 保证交付-保证交付由TCP提供。文件[1]声称“T”，评估人同意。
1.4.6 Accounting Timestamps - The document [1] claims "T", and the evaluator concurs.
1.4.6 会计时间戳-文件[1]声明“T”，评估人同意。
1.4.7 Dynamic Accounting - The document [1] claims "T", and the evaluator concurs.
1.4.7 动态会计-文件[1]声称为“T”，评估人同意。
1.5 MOBILE IP Requirements
1.5 移动IP要求
1.5.1 Encoding of MOBILE IP Registration Messages - The document [1] claims "T", and the evaluator concurs.
1.5.1 移动IP注册消息的编码-文件[1]声称为“T”，评估者同意。
1.5.2 Firewall Friendly - The document [1] claims "T", and the evaluator concurs.
1.5.2 防火墙友好-文件[1]声称“T”，评估者同意。
1.5.3 Allocation of Local Home Agent - The document [1] claims "T", and the evaluator concurs.
1.5.3 本地代理的分配-文件[1]声称为“T”，评估人同意。
2. Summary Discussion
2. 简要讨论
It may appear, upon initial inspection, that the evaluator has not lent a critical eye to the compliance assertions of the document [1]. First, this memo is a "PRO" brief, and as such reasonable benefit of doubt is to be given in favor of the protocol submission. Second, there is a fundamental conceptual issue at play. The COPS-PR model provides a sufficient set of basic operations and commands, a stateful model, the ability for either "peer" to initiate certain kinds of requests, as well as an extensible command set, to be able to support a wide variety of network and resource management protocols. The details of protocol specific messages is left to
在初步检查时，评估人员似乎没有对文件[1]的合规性主张给予批判性的关注。首先，本备忘录是一份“赞成”的摘要，因此，应给予有利于提交协议的合理怀疑利益。第二，有一个基本的概念问题在起作用。COPS-PR模型提供了足够的基本操作和命令集、有状态模型、任一“对等方”发起特定类型请求的能力，以及可扩展的命令集，以支持多种网络和资源管理协议。协议特定消息的详细信息留给
Policy Information Base (PIB) data objects. Since no AAA PIB has been written, the evacuator can only (optimistically) assess the inherent capabilities of the base protocol to accomplish the intended requirements of [3], given a reasonable set of assumptions about what an AAA PIB might look like.
策略信息库（PIB）数据对象。由于尚未编写AAA PIB，因此，如果对AAA PIB的外观进行合理的假设，疏散人员只能（乐观地）评估基本协议的固有能力，以实现[3]的预期要求。
In some sense, this akin to asserting that a given algorithm can be correctly implemented in a specific programming language, without actually providing the code.
在某种意义上，这类似于断言给定的算法可以在特定的编程语言中正确实现，而无需实际提供代码。
The PIB model used by COPS is a powerful and flexible model. The protocol document [5] spends a considerable amount of time enumerating and describing the benefits of this data model, and explaining its roots in Object Oriented (OO) design methodology. Analogies are made to class inheritance and class containment, among others. It's always hard to say bad things about OO.
COPS使用的PIB模型是一种功能强大且灵活的模型。协议文档[5]花费大量时间列举和描述此数据模型的优点，并解释其在面向对象（OO）设计方法中的根源。与类继承和类包含等类似。总是很难说OO的坏话。
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并评估其细节。
Evaluation of COPS against the AAA Requirements CON Evaluation Evaluator - David Mitton
根据AAA要求评估COP CON评估员-David Mitton
The Primary document discussed here is [COPSComp] and the arguments therein based on the proposal [COPSAAA].
这里讨论的主要文件是[COPSComp]，其中的论点基于提案[COPSAAA]。
[COPSComp] "Comparison of COPS Against the AAA NA Requirements", Work
in Progress.
[COPSAAA] "COPS Usage for AAA", Work in Progress.
[EksteinProtoComp] "AAA Protocols: Comparison between RADIUS,
Diameter, and COPS", Work in Progress.
[COPSComp] "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.
References: (in order of relevancy)
参考文献：（按相关性顺序）
[COPSBase] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The Common Open Policy Service Protocol", RFC 2748, January 2000.
[COPSBase]Durham，D.，Boyle，J.，Cohen，R.，Herzog，S.，Rajan，R.和A.Sastry，“共同开放政策服务协议”，RFC 2748，2000年1月。
[COPSFwork] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[COPSFwork]Yavatkar，R.，Pendarakis，D.和R.Guerin，“基于政策的准入控制框架”，RFC 2753，2000年1月。
[COPSPR] "COPS Usage for Policy Provisioning", Work in Progress.
[COPSPR]“策略供应的COPS使用”，正在进行中。
[COPSSPPI] "Structure of Policy Provisioning Information (SPPI)", Work in Progress.
[COPSSPI]“策略设置信息的结构（SPPI）”，正在进行中。
[COPSCMS] "COPS Over CMS", Work in Progress.
[COPSCMS]“COPS对CMS”，工作正在进行中。
[COPSTLS] "COPS Over TLS", Work in Progress.
[COPSTLS]“警察对TLS”，工作正在进行中。
[COPSGSS] "COPS Extension for GSS-API based Authentication Support", Work in Progress.
[COPSGSS]“基于GSS-API的认证支持的COPS扩展”，正在进行中。
Other COPS & RSVP RFCs & drafts not listed as not directly relevant.
未列为不直接相关的其他COP和RSVP RFC和草案。
Compliance: T==Total, P==Partial, F=Failed
Compliance: T==Total, P==Partial, F=Failed
Section 1 - Per item discussion
第1节-每项讨论
Initial Note: [COPSComp] claims "unconditional compliance" with all requirements.
初始注释：[COPSComp]声称“无条件遵守”所有要求。
1.1 General Requirements
1.1 一般要求
1.1.1 Scalability - P (was T) The evaluator is concerned with scalability of many always-on TCP connections to a server supporting a lot of clients, particularly with the heartbeat messages. The claim that the request handle is "unbounded" sounds fishy.
1.1.1 可伸缩性-P（WAST）evaluator关心到支持许多客户端的服务器的许多始终在线TCP连接的可伸缩性，特别是心跳消息。关于请求句柄是“无界”的说法听起来有些可疑。
1.1.2 Fail-over - P (was T) COPS gives an indication of peer failure, and has mechanisms to restart state, but there seems to be a bias toward a single state server. COPS has decided that synchronizing state between multiple hot servers is out of scope.
1.1.2 故障转移-P（WAST）COPS提供对等故障的指示，并具有重新启动状态的机制，但似乎偏向于单一状态服务器。COPS已确定多个热服务器之间的同步状态超出范围。
Because COPS uses TCP, it is at the mercy of the TCP timers of the implementation which can be significant. Connection timeout reporting to the application may be delayed beyond the client authentication timeouts. Tuning the Keep-Alive message to a tighter period will increase the session and system overhead.
因为COPS使用TCP，所以实现中的TCP定时器可能会起到重要作用。向应用程序报告的连接超时可能会延迟到客户端身份验证超时之后。将Keep-Alive消息调整到更紧的周期将增加会话和系统开销。
1.1.3 Mutual Authentication - P (was T) The explanation is sort of for message object integrity. It does not describe authentication techniques. The evaluator assumes that COPS peers would authenticate each other at Client-Open time. But cannot understand how this would work if proxies are involved.
1.1.3 相互身份验证-P（wast）这种解释有点像消息对象完整性。它没有描述身份验证技术。评估者假设COPS对等方将在客户端打开时相互验证。但无法理解如果涉及代理，这将如何工作。
1.1.4 Transmission Level Security - T
1.1.4 传输级安全性-T
1.1.5 Data Object Confidentiality - T Seems almost a carbon copy of the Diameter capabilities. This evaluator echoes the high overhead concerns of the Diameter evaluator for the CMS capability. TLS is not mentioned here, but is piled on later.
1.1.5 数据对象机密性-T几乎是Diameter功能的复制品。该评估器反映了直径评估器对CMS功能的高开销关注。此处未提及TLS，但稍后将继续讨论。
1.1.6 Data Object Integrity - T See above.
1.1.6 数据对象完整性-见上文。
1.1.7 Certificate Transport - T
1.1.7 证书传输-T
1.1.8 Reliable AAA Transport - T (maybe P) COPS meets this requirement as well as any other protocol we've evaluated. That is it does have one application level ACK. Statements such as "TCP provides guaranteed delivery" are incorrect. COPS does attempt to identify outages by using a keep-alive message between TCP peers.
1.1.8 可靠的AAA传输-T（可能是P）COPS符合此要求以及我们评估的任何其他协议。也就是说，它确实有一个应用程序级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 支持代理和路由代理-P（WAST）如何向前支持客户机类型，这个评估者还没有很好地理解。是否每种客户端类型都要求代理向其上游服务器发出不同的客户端打开请求？路由代理呢？
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（WAST）（基于我们对不可否认性的解释，而非需求中给出的定义）历史PIB的解释不完整，因此不确定。
1.1.13 Shared Secret Not Required - T Except this clause in [COPSAAA] 6.2 page 14 "COPS MUST be capable of supporting TLS"
1.1.13 不需要共享秘密-T除了[COPSAAA]6.2第14页“COPS必须能够支持TLS”中的条款外
1.1.14 Ability to Carry Service Specific Attributes - P (was T)
1.1.14 携带特定服务属性的能力-P（WAST）
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位，其中高位表示特定于“企业”的值。但与警察同行有关-
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将固定为一个值。
b) Service specific objects are not the same as Vendor Specific Objects. They pertain to objects within a client type.
b) 特定于服务的对象与特定于供应商的对象不同。它们与客户端类型中的对象相关。
c) The PIB model leads to a different model interoperability. Because most vendor product differ in some way, each PIB will be different, and sharing common provisioning profiles will be a rather difficult mapping problem on the server.
c) PIB模型带来了不同的互操作性模型。由于大多数供应商产品在某些方面有所不同，因此每个PIB都会有所不同，共享公共资源调配配置文件在服务器上是一个相当困难的映射问题。
d) It's not clear the different client types can be mixed or that other objects definitions can be used from other defined client types. It's really unclear how the client type of a connection propagates in a proxy situation.
d) 不清楚不同的客户机类型是否可以混合使用，或者是否可以从其他定义的客户机类型使用其他对象定义。目前还不清楚客户端类型的连接在代理情况下是如何传播的。
1.2 Authentication Requirements
1.2 认证要求
1.2.1 NAI Support - T The requirement that RFC 2459 (X.509 profiles) be met presumes that Auth servers would not have a mapping or local transformation.
1.2.1 NAI支持—满足RFC 2459（X.509配置文件）的要求假定身份验证服务器不会有映射或本地转换。
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支持—正在调用一个信息模型，我看不到它在任何地方都得到了充实。[COPSAAA]做了一些手工操作和定义，但没有提供多少肉。尽管如此，这是可以处理的。
1.2.3 EAP Support - P (was T) Again with the non-existent Information Model. To do EAP, this evaluator thinks another Request or Decision type is needed here to indicate to proxies that an extended message exchange is in progress.
1.2.3 EAP支持-P（WAST）再次使用不存在的信息模型。要执行EAP，此评估器认为此处需要另一个请求或决策类型，以向代理指示正在进行扩展消息交换。
1.2.4 PAP/Clear-text Passwords - T
1.2.4 PAP/明文密码-T
1.2.5 Reauthentication on demand - T
1.2.5 按需重新验证-T
1.2.6 Authorization w/o Authentication - T
1.2.6 不进行身份验证的授权-T
The comment "Please note: with existing algorithms, any authorization scheme not based on prior authentication is meaningless" is meaningless out of application context.
注释“请注意：对于现有算法，任何不基于先前身份验证的授权方案都是毫无意义的”，这在应用程序上下文之外是毫无意义的。
1.3 Authorization Requirements
1.3 授权要求
1.3.1 Static and Dynamic IP Addr Assignment - T
1.3.1 静态和动态IP地址分配-T
1.3.2 RADIUS Gateway Capability - P (was T). It would be interesting to see RADIUS attributes wrapped in some COPS "Information Model".
1.3.2 RADIUS网关能力-P（WAST）。在一些COP“信息模型”中看到RADIUS属性会很有趣。
1.3.3 Reject Capability - T
1.3.3 拒绝能力-T
1.3.4 Preclude Layer 2 Tunneling - T
1.3.4 排除第2层隧道-T
More work for the "Information Model" author!
更多的工作为“信息模型”的作者！
1.3.5 Reauthorization on Demand - T
1.3.5 按需重新授权-T
1.3.6 Support for Access Rules & Filters - P (was T) Yet more work for the "Information Model" author, including some design issues which alluded the RADIUS and Diameter designers. At least an attempt was made in Diameter. There is nothing here.
1.3.6 支持访问规则和过滤器-P（WAST）为“信息模型”作者做了更多的工作，包括一些暗指半径和直径设计师的设计问题。至少在直径上进行了一次尝试。这里什么都没有。
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（was 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 强制压缩编码-T此计算器不相信ADIF是压缩格式。但确实相信，信息模型作者可以设计一个包含会计统计信息的PIB，以满足这一要求。
1.4.3 Accounting Record Extensibility - P (was T) By defining a vendor/device specific PIB for additional elements.
1.4.3 会计记录扩展性-P（WAST），通过为其他元素定义特定于供应商/设备的PIB。
1.4.4 Batch Accounting - P (was T) Offered description does not seem to match the requirement.
1.4.4 批量核算-提供的P（WAST）说明似乎不符合要求。
1.4.5 Guaranteed Delivery - P (was T) TCP does NOT "guarantee delivery", only application Acks can do that. If these acks can be generated similar to the description here, then this requirement is met.
1.4.5 保证交付-P（WAST）TCP不“保证交付”，只有应用程序ACK可以做到这一点。如果可以生成类似于此处描述的这些ACK，则满足此要求。
1.4.6 Accounting Timestamps - T Another item for the "Information Model" author.
1.4.6 会计时间戳-T“信息模型”作者的另一项。
1.4.7 Dynamic Accounting - T Event and interim accounting can be supported.
1.4.7 支持动态核算-T事件和期中核算。
1.5 MOBILE IP Requirements
1.5 移动IP要求
1.5.1 Encoding of MOBILE IP Registration Messages - P (was T) Yet more work for the "Information Model" author. Hope he can handle it.
1.5.1 移动IP注册消息的编码——P（WAST）为“信息模型”作者做了更多的工作。希望他能处理好。
1.5.2 Firewall Friendly - P (was T) I guess. Because it uses TCP and can be identified by known connection port. But there is an issue with respect to the impact level of mixed COPS traffic coming through a common firewall port.
1.5.2 防火墙友好-我猜是P（T）。因为它使用TCP，并且可以通过已知的连接端口识别。但在通过公共防火墙端口的混合警察流量的影响级别方面存在一个问题。
1.5.3 Allocation of Local Home Agent - P (was T) Just add another element to that "Information Model" definition.
1.5.3 本地归属代理的分配-P（WAST）只是在“信息模型”定义中添加了另一个元素。
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.
理解COP要求您阅读一些RFC和草稿，这些RFC和草稿不能很好地集成在一起。COPS的每一个应用都产生了许多草稿。目前还不清楚是否想要或能否实现一个能够为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
COPS的作者似乎过分相信TCP的优点，并依赖它来解决所有的传输问题，并允许应用程序保持活动消息来探测连接状态和序列号，以防止重播攻击。该评估人员认为，这种方法可能适用于许多网络，但实际上并不适用
scale well in larger configurations. End-to-end application acks are the only guaranteed delivery solution, particularly where distributed state is involved.
在较大的配置中可以很好地扩展。端到端应用程序ACK是唯一有保证的交付解决方案，特别是在涉及分布式状态的情况下。
COPS falls into an in between place on encoding. It has small number of simple data object blobs which are concatenated ala RADIUS/Diameter TLVs to form a flexible message layout. However, they attempt to limit the number of objects by making them arbitrarily complex ala SNMP MIBs, and defining yet another data structuring language for these PIBs. There is a lot of computer science style grandstanding in [COPSAAA] Section 1.2, but no translation into how a set of data objects can be used to meet these wonderful features in operation. (or even if we needed them) This will be the crux of the interoperability issue. RADIUS implementations interoperate because they at least, understand a common set of functional attributes from the RFCs. And vendor extent ions can be simply customized in as needed via dictionaries. If PIB definitions are needed for every piece and version of access equipment, before you can use it, then the bar for ease of configuration and use has been raised quite high.
警察在编码上处于中间位置。它有少量简单的数据对象BLOB，这些BLOB连接在ala RADIUS/Diameter TLV上，以形成灵活的消息布局。然而，他们试图通过使对象变得任意复杂来限制对象的数量，并为这些PIB定义另一种数据结构语言。在[COPSAAA]第1.2节中有很多计算机科学风格的哗众取宠，但没有翻译成如何使用一组数据对象来满足操作中的这些奇妙功能。（或者即使我们需要它们）这将是互操作性问题的关键。RADIUS实现可以互操作，因为它们至少可以从RFC中了解一组通用的功能属性。而且，可以根据需要通过字典在中简单地自定义供应商范围。如果访问设备的每一个部件和版本都需要PIB定义，在您可以使用它之前，那么配置和使用的容易程度已经提高到相当高的水平。
Support for PIB definition and vendor extensions will be on the same order as MIB integration in SNMP management products and put the supposed complexity of Diameter to shame.
对PIB定义和供应商扩展的支持将与SNMP管理产品中的MIB集成顺序相同，并使DIAMER的假定复杂性相形见绌。
4. Summary Recommendation
4. 简要建议
COPS has a structure that could be made to serve as a AAA protocol, perhaps by just copying the features of RADIUS and Diameter into it. The author of [COPSAAA] and [COPSComp] has not done the whole job yet and some of the missing pieces are vexing even for those already in the field.
COPS有一个可以用作AAA协议的结构，也许只需将半径和直径的特征复制到其中即可。[COPSAAA]和[COPSComp]的作者还没有完成全部工作，一些缺失的部分甚至对那些已经在该领域工作的人来说也是令人烦恼的。
While some of the synergy with other COPS services is attractive, this evaluator is concerned about the liabilities of combining AAA services with the new emerging COPS applications in a single server entity will introduce more complexity than needed and opportunities to have progress pulled into other rat-holes. (eg. Policy Frameworks)
虽然与其他COPS服务的某些协同作用很有吸引力，但该评估员担心，将AAA服务与新出现的COPS应用程序结合在一个服务器实体中的责任将带来比所需更大的复杂性，并有机会将进展拉进其他老鼠洞。（如政策框架）
Appendix D - Meeting Notes
附录D-会议记录
The minutes of the team meetings as recorded by various members.
各成员记录的团队会议记录。
Recorded by: Mark Stevens
录音人：马克·史蒂文斯
Arguments for and against SNMP as an AAA protocol were given. Stuart Barkley gave a summary of the pro argument. Mike St. Johns gave a summary of the con argument. Dave Nelson asked for "instructions to the jury" in an effort to determine what evidence could and could not be used in making decisions.
给出了支持和反对SNMP作为AAA协议的论点。斯图尔特·巴克利总结了赞成的论点。迈克·圣约翰斯总结了这场骗局。戴夫·纳尔逊要求“向陪审团发出指示”，以确定哪些证据可以和不可以用于作出决定。
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.
Mike St.Johns提出，我们必须限制自己只考虑合规文件中提供的证据以及他们可能参考的任何支持文件。
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.
随后，斯图尔特·巴克利（Stuart Barkley）就支持SNMP的论点发言。
Highlights:
亮点：
* In most areas the requirements are met by SNMP. * Confidentiality and Certificate transport mechanisms may be weak, but workable. * With regard to Authentication, every technique can be supported although support for PAP or cleartext passwords is weak. * With regard to Authorization, there is nothing in the requirements that cannot be supported. * Accounting everything supported, although there is no specific consideration for compact encoding. SNMP not as bloated as ASCII or XML based encoding schemes. Requirement for compact encoding weakly indicated in requirements anyway. Server-specific attributes needed, but compact encoding preclude w/o tradeoffs.
* 在大多数领域，SNMP满足了这些要求。*机密性和证书传输机制可能较弱，但可行。*关于身份验证，尽管对PAP或明文密码的支持较弱，但每种技术都可以得到支持。*关于授权，要求中没有任何内容无法支持。*尽管没有具体考虑紧凑编码，但会计支持的一切。SNMP不像ASCII或基于XML的编码方案那样臃肿。紧凑编码的需求在需求中显示得很弱。需要特定于服务器的属性，但紧凑的编码排除了w/o权衡。
* 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?
* 要求、核心文件和响应文件均未规定运行机制。*在断言满足了服务器到服务器的交互要求时采取了自由。*缩放参数很弱。*故障转移参数很弱。*安全方面与manager/server范例配合良好，但在对等方之间的双向交互中效果不佳。*响应文件的作者不理解认证要求。*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肯定会在会计领域发挥作用，但在授权和身份验证领域无法使用。*响应文件未说明如何解决问题。*它没有解决从manager代理操作模式过渡到客户机-服务器模式时可能出现的可伸缩性问题。
The group then examined each requirement against SNMP in a line-by-line exercise.
然后，小组在逐行练习中对照SNMP检查了每个需求。
Attendees - All (Mike St. John, Dave Mitton, Dave Nelson, Mark Stevens, Barney Wolff, Stuart Barkley, Steven Crain, Basavaraj Patil)
所有与会者（迈克·圣约翰、戴夫·米顿、戴夫·纳尔逊、马克·史蒂文斯、巴尼·沃尔夫、斯图尔特·巴克利、史蒂文·克雷恩、巴萨瓦拉伊·帕蒂尔）
Minutes recorded by : Basavaraj Patil
会议记录人：Basavaraj Patil
Evaluation of RADIUS++ AAA Requirements
RADIUS++AAA需求评估
Pro : Mark Stevens Con : Dave Nelson
赞成：马克·史蒂文斯反对：戴夫·纳尔逊
- Question raised on if all meetings held so far have been recorded. Last week's meeting was recorded by Mark. Previous meetings have been recorded by Mike. All of these minutes should be available in the archive.
- 提出的问题是迄今为止举行的所有会议是否都有记录。马克记录了上周的会议。以前的会议由迈克录制。所有这些会议记录都应在存档中提供。
- Dave Nelson mentioned that Pat Calhoun has responded on the AAA WG mailing list to the changes made to the requirements document by the evaluation team. Pat's response includes arguments for inclusion of some of the requirements that were deleted by the eval team.
- Dave Nelson提到Pat Calhoun已经在AAA工作组邮件列表上对评估团队对需求文件所做的更改做出了回应。Pat的回答中包括了一些论点，要求将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.
- Mike得出结论，在详细审查Pat的意见和参考的RFC后，我们可以恢复这些要求。目的是从现在起到下周四（7月6日），采纳Pat的意见/文件，并对其进行审查，并根据当时的调查结果整合意见。
Voting Procedure for evaluation : No voting during the discussion. All votes MUST be submitted to Mike by COB, June 28th, 00.
评价表决程序：讨论期间不进行表决。所有投票必须于6月28日00由COB提交给Mike。
- Dave Nelson's summary of the Con statement for RADIUS++. Overview of the points on which the evaluator disagrees with the compliance statement.
- Dave Nelson对RADIUS++的Con声明的总结。评估人不同意合规性声明的要点概述。
Conclusion from Dave : Not recommended (Details in the con statement).
Dave得出的结论：不推荐（详情见con声明）。
Q: Is it possible to use it for accounting? A: Authentication and Authorization could be separated, but Accounting is the weak link in this protocol and hence is not suitable.
问：是否可以将其用于会计核算？答：身份验证和授权可以分开，但记帐是该协议中的薄弱环节，因此不适合。
- 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声明的总结与戴夫·纳尔逊的大部分观察结果一致。最重要的是，它已经在这个环境中运行了一段时间，并且确实满足了大多数需求
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.
基于麻省理工学院已退役的机器和网络中安装的同名新机器的网络的健壮性示例。
Discussion of environments where proxies for primary, secondary and tertiaries exist and the possible effect of flooding messages in the event of a fail-over detection.
讨论存在主代理、次代理和三代理的环境，以及故障转移检测时泛洪消息的可能影响。
1.1.3 Mutual Authentication
1.1.3 相互认证
No Discussion. Accepted as stated.
没有讨论。按规定接受。
1.1.4 Transmission level security
1.1.4 传输级安全
This requirement was deleted from the list by the evaluation team. It was deleted because it is an overgeneralization of Roam Ops.
评估小组从清单中删除了这项要求。它被删除了，因为它是对漫游操作的过度概括。
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-人们担心这到底意味着什么。提及Pat在清单上对此的看法以及恢复该清单的必要性。
Suggestion to change the tag in the requirements document to hop-by-hop security.
建议将需求文档中的标记更改为逐跳安全性。
Does the Roamops group use transmission level security to imply hop-by-hop security?
Roamops组是否使用传输级安全性来暗示逐跳安全性？
1.1.5 Data Object Confidentiality
1.1.5 数据对象机密性
Mike explained the concept of Cryptographic Message Syntax (CMS - RFC2630). There are some issues regarding the use of CMS at an end point. Symmetric or Asymmetric keys can be used.
Mike解释了加密消息语法（CMS-RFC2630）的概念。在终点使用CMS时存在一些问题。可以使用对称或非对称密钥。
There does not seem to be a problem with the suggested usage of CMS in RADIUS++.
在RADIUS++中建议使用CMS似乎没有问题。
1.1.6/7 Data Object Integrity/Certificate Transport
1.1.6/7数据对象完整性/证书传输
No discussion. (I guess everyone concurs with the statement in the compliance document and the reviewers comments).
没有讨论。（我想每个人都同意合规文件中的声明和审查员的意见）。
1.1.8 Reliable AAA Transport
1.1.8 可靠的AAA传输
BW - Radius provides reliability at the application layer by doing retransmissions. So why is there a need for a reliable AAA transport protocol?
BW-Radius通过重新传输在应用层提供可靠性。那么，为什么需要一个可靠的AAA传输协议呢？
- Is it packet loss that the protocol needs to be concerned about?
- 协议需要关注的是数据包丢失吗？
DN - This requirement is tied to the failover issue. Explanation of the negative impact of retransmissions in a network, especially in the case of a web of proxies.
DN-此要求与故障转移问题相关。解释网络中重新传输的负面影响，尤其是在代理网络的情况下。
Conclusion is that this requirement deals with packet loss.
结论是，该要求涉及数据包丢失。
1.1.9/10 Run over IPv4/6
1.1.9/10在IPv4/6上运行
Running over IPv6 should be a trivial issue.
在IPv6上运行应该是一个微不足道的问题。
1.1.11 Support Proxy and Routing Brokers
1.1.11 支持代理和路由代理
- Discussion on what this requirement means and analogy to DNS servers in a network.
- 讨论此要求的含义，并与网络中的DNS服务器进行类比。
- RADIUS can be extended to support this requirement and from the compliance document this does not appear to be fully cooked yet.
- RADIUS可以扩展以支持这一要求，从合规性文件来看，这似乎还没有完全成熟。
1.1.12 Auditability
1.1.12 可审计性
No Discussion
不讨论
1.1.13 Shared Secret Not Required
1.1.13 不需要共享秘密
This seems to be a trivial issue to be addressed in RADIUS++.
这似乎是RADIUS++中需要解决的一个小问题。
1.1.14 Ability to carry Service Specific Attributes
1.1.14 能够携带特定于服务的属性
No Discussion
不讨论
Authentication Requirements:
认证要求：
1.2.1 NAI Support
1.2.1 NAI支持
Trivial - Total compliance.
琐碎-完全遵从。
1.2.2 CHAP Support
1.2.2 CHAP支持
Comment : RADIUS support of CHAP could be better and the response needs to be encrypted.
注释：RADIUS对CHAP的支持可能更好，响应需要加密。
1.2.3/4 EAP/PAP
1.2.3/4 EAP/PAP
No Discussion
不讨论
1.2.5 Reauthentication on Demand
1.2.5 按需重新验证
DN - Document claims that the server can reauthenticate by issuing an Access-challenge. There is a change to the state machine and the suggested solution is too simplistic. Also backwards compatibility would be an issue.
DN-文档声明服务器可以通过发出访问质询来重新验证。状态机发生了变化，建议的解决方案过于简单。此外，向后兼容性也是一个问题。
1.2.6 Authorization w/o Authentication
1.2.6 不进行身份验证的授权
DN - This is trivial to fix, but this is not mentioned in the compliance document.
DN-这很容易修复，但合规性文档中没有提到。
Authorization Requirements:
授权要求：
1.3.1 Static and Dynamic IP Addr assignment
1.3.1 静态和动态IP地址分配
- RADIUS does not rise to the demands of being a resource manager - RADIUS assigns an address and it stays assigned for the session. There is no concept of leasing.
- RADIUS不能满足作为资源管理器的要求-RADIUS分配一个地址，并为会话保持分配状态。没有租赁的概念。
1.3.2 RADIUS Gateway Capability
1.3.2 RADIUS网关能力
This is a requirement written that is not applicable to RADIUS itself.
这是一项书面要求，不适用于RADIUS本身。
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工作组正在就这一要求进行讨论。RADIUS工作组也在讨论这一点（评论）。这里的想法是能够发送相当于电话呼叫进行中类型的消息。
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。信息和行为不同。
1.5.2 Firewall Friendly
1.5.2 防火墙友好
No Discussion
不讨论
1.5.3 Allocation of Local Home Agents
1.5.3 本地房屋代理的分配
This concept needs to be clarified as the author writing the compliance statement did not understand it either.
这一概念需要澄清，因为撰写合规性声明的作者也不理解。
If you notice anything that I recorded here as something misinterpreted, please feel free to make corrections.
如果您注意到我在这里记录的任何内容被误解，请随时更正。
Attendees: Mike St. John, Dave Mitton, Dave Nelson, Barney Wolff, Stuart Barkley, Steven Crain, Basavaraj Patil. Missing: Mark Stevens.
与会者：迈克·圣约翰、戴夫·米顿、戴夫·纳尔逊、巴尼·沃尔夫、斯图尔特·巴克利、史蒂文·克雷恩、巴萨瓦拉·帕蒂尔。失踪者：马克·史蒂文斯。
Minutes recorded by: Stuart Barkley
会议记录：斯图尔特·巴克利
Evaluation of Diameter AAA Requirements
直径AAA要求的评估
Advocates:
倡导者：
Pro: Basavaraj Patil Con: Barney Wolff
赞成：Basavaraj Patil反对：Barney Wolff
Summary discussion:
简要讨论：
PRO summary (Basavaraj Patil):
专业总结（Basavaraj Patil）：
session based lightweight base + extensions has implementation experience based upon radius fixes specific problems with radius, interoperates with radius looks like requirements are written for diameter
基于会话的轻量级base+扩展具有基于radius的实施经验修复了radius的特定问题，与radius的互操作看起来是针对diameter编写的要求
CON summary (Barney Wolff):
合同摘要（巴尼·沃尔夫）：
meets most needs, designed with requirements in mind
满足大多数需求，设计时考虑到需求
issues: scalability in small devices (strong crypto specifically)
问题：小型设备的可扩展性（特别是强加密）
failover (need guidance on failover recovery procedures)
故障切换（需要关于故障切换恢复过程的指导）
Data object confidentiality has been expressed as very important, diameter glosses over it referring to rfc2630, cost to run on NAS device
数据对象机密性已被表示为非常重要，diameter掩盖了这一点，参考rfc2630，即在NAS设备上运行的成本
ACL: filter style syntax seems inadequate
ACL:筛选器样式语法似乎不充分
state reconciliation: difficult over global multiple administrative domains
国家和解：难以跨越全球多个行政领域
batch accounting: implementation doesn't meet intended need
批量记帐：实现不满足预期需要
firewall friendly: until firewalls support SCTP will be failure
防火墙友好：在防火墙支持之前，SCTP将失败
summary very close
总结非常接近
concerns:
关注事项：
size and complexity needs almost all extensions to actually support needs separation of SCTP and data (as per IESG suggestion?) application vs transport acks
规模和复杂性需要几乎所有的扩展来实际支持SCTP和数据（根据IESG建议？）应用程序与传输ACK的分离
Point-by-point Discussion:
逐点讨论：
General (1.1):
一般（1.1）：
1.1.1 Scalability
1.1.1 可伸缩性
Handles large number of requests
处理大量请求
SCTP reduces proxy needs (how? what is justification for this statement?)
SCTP减少了代理需求（如何？该声明的理由是什么？）
Scalability in large
大规模可扩展性
1.1.2 Fail-over
1.1.2 故障转移
Recovery from SCTP failure needs discussion (Note to DM: Include in final document considerations)
从SCTP故障中恢复需要讨论（DM注意：包括在最终文件考虑事项中）
1.1.3 Mutual Authentication
1.1.3 相互认证
No Discussion
不讨论
1.1.4 Transmission level security
1.1.4 传输级安全
No Discussion
不讨论
1.1.5/6 Data Object Confidentiality/Data Object Integrity
1.1.5/6数据对象机密性/数据对象完整性
Crypto in NAS NAS needs knowledge of when to use crypto One Time Passwords
NAS中的加密NAS需要知道何时使用加密一次性密码
1.1.7 Certificate Transport
1.1.7 证书传输
No Discussion
不讨论
1.1.8 Reliable AAA Transport
1.1.8 可靠的AAA传输
No Discussion
不讨论
1.1.9/10 Run over IPv4/6
1.1.9/10在IPv4/6上运行
No Discussion
不讨论
1.1.11 Support Proxy and Routing Brokers
1.1.11 支持代理和路由代理
No Discussion
不讨论
1.1.12 Auditability
1.1.12 可审计性
No Discussion
不讨论
1.1.13 Shared Secret Not Required
1.1.13 不需要共享秘密
No Discussion
不讨论
1.1.14 Ability to carry Service Specific Attributes
1.1.14 能够携带特定于服务的属性
No Discussion
不讨论
Authentication Requirements:
认证要求：
1.2.1 NAI Support
1.2.1 NAI支持
No Discussion
不讨论
1.2.2 CHAP Support
1.2.2 CHAP支持
No Discussion
不讨论
1.2.3/4 EAP/PAP
1.2.3/4 EAP/PAP
No Discussion
不讨论
1.2.5 Reauthentication on Demand
1.2.5 按需重新验证
No Discussion
不讨论
1.2.6 Authorization w/o Authentication
1.2.6 不进行身份验证的授权
No Discussion
不讨论
Authorization Requirements:
授权要求：
1.3.1 Static and Dynamic IP Addr assignment
1.3.1 静态和动态IP地址分配
No Discussion
不讨论
1.3.2 RADIUS Gateway Capability
1.3.2 RADIUS网关能力
Protocol requirement or implementation/application requirement? Which RADIUS versions are to be supported? Which subset?
协议要求还是实施/应用要求？支持哪些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 按需重新授权
Raj to look at this again
拉杰想再看看这个
1.3.6 Support for ACLs
1.3.6 对ACL的支持
Standardizes syntax not semantics. Standardizes semantics in NASREQ extension, but is very weak
标准化语法而非语义。标准化NASREQ扩展中的语义，但非常弱
1.3.7 State reconciliation
1.3.7 国家和解
Appears to be weak in that server must "query the world" to restore its state Just in time reconciliation Simultaneous usage limitations More discussion needed
服务器必须“查询世界”才能及时恢复其状态，这一点似乎很薄弱。同时，还需要讨论使用限制
1.3.8 Unsolicited disconnect
1.3.8 主动断开
No Discussion
不讨论
Accounting Requirements:
会计要求：
1.4.1 Real time accounting
1.4.1 实时会计
No Discussion
不讨论
1.4.2 Mandatory compact encoding
1.4.2 强制压缩编码
Is ADIF compact? Is ADIF UTF-8 compatible?
ADIF紧凑吗？ADIF UTF-8兼容吗？
1.4.3 Accounting Record Extensibility
1.4.3 会计记录扩展性
No Discussion
不讨论
1.4.4 Batch Accounting
1.4.4 批量核算
Diameter okay for small batches. Specification doesn't seem suitable for large batch transfers (100,000+ records)
对于小批量，直径合适。规范似乎不适合大批量传输（100000多条记录）
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的问题
1.5.3 Allocation of Local Home Agents
1.5.3 本地房屋代理的分配
Still lack of understanding of the AAA protocol requirements here (versus just being a roaming attribute)
这里仍然缺乏对AAA协议要求的理解（与仅仅作为漫游属性相比）
Overall summary:
总体总结：
Diameter seems to meet most requirements and is a likely candidate to support AAA requirements.
直径似乎满足大多数要求，并且很可能支持AAA要求。
Other matters:
其他事项：
Votes on Diameter should be in by Sunday evening. Same format as before. Mike will tally up as both majority and average votes.
关于直径的投票应在星期天晚上之前进行。格式和以前一样。迈克将获得多数票和平均票。
Should different requirements have different weight?
不同的需求应该有不同的权重吗？
Possibility of SNMP reconsideration as per ADs? To close off our task in timeframe allocated, should not reopen submissions or discussions. Could cause to drag on for long time causing us to miss our July 15 date.
根据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.
由于团队的编辑和审查需要，可能需要额外几天来完成报告。迈克要求广告考虑轻微延长时间的可能性。
"No discussion" means that the topic was mentioned but there we no objections/issues raised on that requirement being met.
“无讨论”意味着提及了该主题，但我们没有对该要求提出异议/问题。
These are based upon my notes. Please send any corrections to the list.
这些是根据我的笔记写的。请将任何更正发送到列表。
Minutes of AAA-Team Telecon 7/6/00 By: Barney Wolff
AAA团队电视会议纪要7/6/00作者：Barney Wolff
Pro review of COPS - Dave Nelson
警察专业评论-戴夫·纳尔逊
Likes the object model. No apparent showstoppers. Will resend review with typos corrected.
喜欢对象模型。没有明显的阻碍。将重新发送已更正拼写错误的审阅。
Con review of COPS - Dave Mitton
警察的犯罪审查-戴夫·米顿
Architecture is mostly there. Strong dependency on info model, sceptical of object model. Problem with info model in multi-vendor, multi-administration environment. How does server speak to multiple client flavors? Will resend review with typos corrected.
建筑大多在那里。对信息模型依赖性强，对对象模型持怀疑态度。多供应商、多管理环境中的信息模型问题。服务器如何与多个客户机对话？将重新发送已更正拼写错误的审阅。
Comment by Mike StJ "replace SNMP with COPS" - :) I think.
Mike StJ的评论“用警察取代SNMP”-：）我认为。
Per-Item discussion
逐项讨论
1.1.1 Scalability - concern re always-on TCP. Direction to DM - add general issue of number of connections.
1.1.1 可伸缩性—始终基于TCP。DM方向-添加连接数的一般问题。
1.1.2 Failover - No hot backup, but true of all protocols. (ie, no explicit mention of server-server protocol that might keep a backup server in sync so it could take over instantly.)
1.1.2 故障转移—没有热备份，但适用于所有协议。（也就是说，没有明确提到可能保持备份服务器同步以便其能够立即接管的服务器协议。）
1.1.3 Mutual Authentication - perhaps relies on TLS. Draft does not otherwise support this.
1.1.3 相互认证-可能依赖于TLS。草案不支持这一点。
1.1.8 Reliable AAA Transport - TCP + appl heartbeat.
1.1.8 可靠的AAA传输—TCP+appl心跳。
1.1.11 Proxy & Routing Brokers - client-type interaction with proxy is questionable. (In later discussion, it appears client-type is a field in the request, and perhaps all AAA is one type, so may not be an issue.)
1.1.11 代理和路由代理-客户端类型与代理的交互有问题。（在后面的讨论中，客户端类型似乎是请求中的一个字段，可能所有AAA都是一种类型，因此可能不是问题。）
1.1.13 Shared secret not req'd - runs over TLS, no multiple levels of security.
1.1.13 不需要共享机密-在TLS上运行，没有多个安全级别。
1.2.1 NAI Support - some uncertainty on the impact of RFC 2459 (X.509 profiles) on this - may restrict NAI in some way?
1.2.1 NAI支持-RFC 2459（X.509配置文件）对此的影响存在一些不确定性-可能以某种方式限制NAI？
1.2.3 EAP Support - multi-pass handshake needs work.
1.2.3 EAP支持-多通道握手需要工作。
1.2.6 Authorization without Authentication - Mike comments the requirement is broken. BW comment (post-meeting) - the requirement appears intended specifically to chastise RADIUS for requiring User-Name and some sort of password in an Access-Request, even if it's sent pre-connect, on receipt of DNIS, for example. Sure it's silly, but does it really matter whether an attribute is absent or filled with "NONE"? This was just nasty sniping at RADIUS on somebody's part, imho.
1.2.6 未经身份验证的授权-Mike评论要求已被打破。BW评论（会后）-该要求似乎专门用于惩罚RADIUS在访问请求中要求用户名和某种密码的行为，即使是在收到DNIS后发送的预连接。当然这很愚蠢，但属性是否缺少或填充“无”真的很重要吗？这只是对某人的恶意狙击，伊姆霍。
1.3.2 RADIUS Gateway - skepticism was expressed.
1.3.2 有人表示怀疑。
1.3.4 Preclude L2 Tunnels - too much handwaving.
1.3.4 排除L2隧道-太多手动操作。
1.3.6 Access Rules - lots of work needed.
1.3.6 访问规则-需要大量工作。
1.3.7 State Reconciliation - multi-server coordination is an issue.
1.3.7 状态协调-多服务器协调是一个问题。
1.4.4 Batch Accounting - for small batches, perhaps.
1.4.4 批量核算——也许是小批量核算。
1.4.5 Guaranteed Delivery - application acks are an area of mystery.
1.4.5 保证交付-应用程序确认是一个神秘的领域。
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）一样，COP要求防火墙查看数据包内部，因为可能允许通过AAA，但不允许使用其他协议。因此，为AAA应用程序定义不同的端口对COPS和SNMP都有很大帮助。
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对NASE和其他边缘设备的适用性问题？需要对每个对象进行保密。考虑三方方案。
1.1.6 Question as to why SNMP did not rate the same as for item 1.1.5? The evaluation is based on what was contained in the submission documents, rather than capabilities of the protocol itself. Too much hand waving.
1.1.6 关于为什么SNMP的评分与第1.1.5项的评分不同的问题？评估是基于提交文件中包含的内容，而不是协议本身的能力。挥手太多了。
1.1.7 No comments.
1.1.7 没有评论。
1.1.8 Question as to meaning of "reliable"? Discussion of transport protocols was deferred to later in the meeting.
1.1.8 关于“可靠”的含义的问题？关于运输协议的讨论推迟到会议晚些时候进行。
1.1.9 No comments.
1.1.9 没有评论。
1.1.10 SNMP received "P" because of hand waving in the submission documents.
1.1.10 由于在提交文档中挥手，SNMP收到“P”。
1.1.11 SNMP received "F" because this section of the submission document indicated "t.b.d.". Diameter was the only protocol submission to completely address this item.
1.1.11 SNMP收到“F”，因为提交文件的这一部分显示“t.b.d.”。Diameter是唯一完全解决此问题的协议提交。
1.1.12 We treated this requirement as "non-repudiation". There is a concern that digital signatures are computationally expensive and are not globally available. COPS has more work to do on this item.
1.1.12 我们将此要求视为“不可否认”。有一个问题是，数字签名在计算上很昂贵，而且无法在全球范围内使用。警察在这件事上还有很多工作要做。
1.1.13 Question that "no shared secrets" should be interpreted to mean that an alternative key management mechanism is available? We treated this as meaning that application-layer security could be turned off in deference to transport layer security. There had been discussion of the use of IKE in the AAA protocol.
1.1.13 “无共享机密”是否应解释为存在替代密钥管理机制？我们认为这意味着可以关闭应用程序层安全性，而不是传输层安全性。已经讨论了在AAA协议中使用IKE的问题。
1.1.14 No comments.
1.1.14 没有评论。
1.2.1 No comments.
1.2.1 没有评论。
1.2.2 No comments.
1.2.2 没有评论。
1.2.3 No comments.
1.2.3 没有评论。
1.2.4 Is there a need for a clear-text "password" for service such as OTP, SecurID, et. al.? It was noted that all plain passwords are exposed in clear-text at the NAS or other edge device, which is no more inherently trustworthy than any AAA server or proxy.
1.2.4 OTP、SecurID等服务是否需要明文“密码”。？需要注意的是，所有普通密码在NAS或其他边缘设备上以明文形式公开，这并不比任何AAA服务器或代理更可靠。
1.2.5 We distinguished event-driven reauthentication from timer-driven (or lifetime-driven). How is this requirement to be met in a proxy environment?
1.2.5 我们将事件驱动的重新身份验证与计时器驱动（或生存期驱动）区分开来。在代理环境中如何满足这一要求？
1.2.6 We asserted that this requirement is an oxymoron.
1.2.6 我们断言这一要求是一种矛盾修饰法。
1.3.1 We had difficulty in determining what "static" meant, and from which reference point it was measured.
1.3.1 我们很难确定“静态”是什么意思，以及从哪个参考点进行测量。
1.3.2 We agreed that NAIs could be handled, possibly with some restrictions.
1.3.2 我们同意可以处理NAI，可能有一些限制。
1.3.3 No comment.
1.3.3 无可奉告。
1.3.4 The SNMP submission documents contained significant hand waving.
1.3.4 SNMP提交文件中包含大量的挥手行为。
1.3.5 Similar comments as to item 1.2.5. The question was raised as to how the server knows when to send this request?
1.3.5 关于第1.2.5项的类似意见。提出的问题是服务器如何知道何时发送此请求？
1.3.6 We found that the notation in Diameter was weak, and of a least common denominator nature. In general, there was concern about achieving interoperability when the syntax was standardized but the
1.3.6 我们发现直径的符号很弱，并且具有最小公分母的性质。一般来说，当语法标准化时，人们担心实现互操作性，但是
semantics were not. This area needs further work.
语义不是。这方面需要进一步的工作。
1.3.7 Question as to how this requirement is achieved via proxies?
1.3.7 关于如何通过代理实现此要求的问题？
1.4.1 No comment.
1.4.1 无可奉告。
1.4.2 No comment.
1.4.2 无可奉告。
1.4.3 No comment.
1.4.3 无可奉告。
1.4.4 There was significant skepticism regarding batch accounting as part of the AAA protocol. How large are the "batches"? Should this requirement be met using FTP or something similar?
1.4.4 对于将批量记帐作为AAA协议的一部分，存在着严重的怀疑。“批次”有多大？使用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端口号）的数据包。SNMP和COP等使用AAA以外的协议处于劣势，因为防火墙必须深入应用程序PDU以确定数据包的预期用途。Diameter受到SCTP的依赖，而SCTP并没有被广泛部署或被防火墙广泛认可。应该安装防火墙吗
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.
每个成员都以（可接受、不可接受）的形式表示了他们的评估，并带有（会计或变更努力）的限定词。该信息将在最终报告中总结。
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.
有人认为，重要的是，尽可能多的思维过程和理论依据应放在最终报告中。Mike St.John将与Dave Mitton在ID上合作。我们确实需要满足IETF 7月14日的提交截止日期，即使我们必须发布AAA WG邮件列表的更新。所有人都认为这个过程进行得相当顺利。在这种性质的未来评估中，评估人员应密切遵循需求文件，提交人应创建准确完整的合规性文件，并允许“重新旋转”周期来纠正需求文件和合规性文件中的错误和遗漏。
A discussion of the transport protocol was held.
对传输协议进行了讨论。
The issue with transport is congestion control. There has been a problem with streams-oriented applications over TCP. The IESG is increasingly sensitive to this issue in new protocols. It was noted that AAA was a transaction-oriented application. Other request-response applications, such as DNS, seem to scale welt to Internet-scale using simple application-level retries and UDP transport. TCP has problems with head-of-line blocking, especially when multiple sessions are using a single TCP connection. AAA typically will send 3 or 4 iterations and then indicate a failure to the upper layers. It won't continue retransmissions in the face of congestion, like TCP. It was noted that bulk data transfer may not best be implemented in the AAA protocol. Concern was voiced that SCTP is not a widely implemented protocol. AAA will implement congestion control by limiting the number of outstanding requests. Some RADIUS implementations send lots of traffic when they encounter misconfigured shared secrets, but this is likely caused by a lack of proper error recovery. Diameter, as currently drafted, relies on SCTP. Can AAA run over UDP? The IESG didn't say "no"; their issue is addressing congestion control.
交通问题是拥堵控制。TCP上面向流的应用程序存在一个问题。IESG在新协议中对这个问题越来越敏感。注意到AAA是一个面向事务的应用程序。其他请求-响应应用程序（如DNS）似乎使用简单的应用程序级重试和UDP传输将welt扩展到Internet规模。TCP存在行首阻塞问题，特别是当多个会话使用单个TCP连接时。AAA通常会发送3或4次迭代，然后向上层指示失败。它不会像TCP那样在拥塞情况下继续重新传输。有人指出，批量数据传输可能不是在AAA协议中实现的最佳方式。有人担心SCTP不是一个广泛实施的协议。AAA将通过限制未完成请求的数量来实施拥塞控制。一些RADIUS实现在遇到错误配置的共享机密时会发送大量流量，但这可能是由于缺乏正确的错误恢复造成的。目前起草的直径取决于SCTP。AAA可以通过UDP运行吗？IESG没有说“不”；他们的问题是解决拥塞控制问题。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。