RFC 3127
Authentication, Authorization, and Accounting: Protocol Evaluation
RFC 3127: Authentication, Authorization, and Accounting: Protocol Evaluation 🎀
Okay bestie, this is RFC 3127 🦋 It's an Informational document from June 2001, and it came out of the Network Working Group. Seven authors wrote it, and they all came from different places: D. Mitton from Nortel Networks, M. St.Johns from Rainmaker Technologies, S. Barkley from UUNET, D. Nelson from Enterasys Networks, B. Patil from Nokia, M. Stevens from Ellacoya Networks, and B. Wolff from Databus Inc. 💅 The header doesn't list anything it obsoletes or updates.
Status of this Memo
This memo gives information to the Internet community 💖 It is not an Internet standard of any kind, and it can be distributed freely with no limits. 🌸
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. 🫶
Abstract
So this memo is basically the write-up of the AAA Working Group's panel evaluating the protocols that were pitched against the AAA Network Access Requirements, which is RFC 2989 ✨ The timeline was super tight, so the doc isn't as polished as it could've been 😭 It mostly stays that way so the results are recorded just as they were presented.
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 . . . . . . . . . . . . . . . . . . . . .841. Process Description ✨
Okay so the first draft of this doc got rushed to hit the June 2000 Pittsburgh meeting deadline 😭 Since that meeting already happened, the panel didn't want to substantially change the findings, so nobody looks like they changed info after presenting it 🙈 Only the process descriptions, formatting, layout, and factual errors got fixed in later revisions 💅
1.1. WG Co-Chair's Note:
Once the AAA WG re-charter was approved and the Network Access Requirements document passed AAA WG Last Call, a Solicitation of Protocol Submissions went out on 4/13/2000 🦋 It got sent to the AAA WG mailing list and to other related IETF WG lists: NASREQ, Mobile IP, RAP, and SNMPv3.
Submissions were open effective immediately. Authors of candidate protocols were asked to tell the AAA WG chairs they planned to submit, and it was suggested they do that by May 1, 2000.
Protocol submissions and compliance description documents had to be sent in Internet Draft format by email to internet-drafts@ietf.org. The deadline was June 1, 2000. To count as a candidate, a submission needed an unqualified RFC 2026 statement, described at http://www.ietf.org/Sec10.txt 🎀
The AAA WG chairs then formed an evaluation team to help the WG go through the submissions and compliance documents, announced on May 20, 2000 🧚 That team was supposed to write an Internet Draft documenting its evaluation of the protocol submissions. The goal was a first draft ready before the July 14, 2000 submission deadline for IETF 48 ✨
The evaluation team was asked to pull from the protocol specifications, the compliance descriptions, and other relevant documents, plus the Network Access Requirements document, RFC 2989 💜
Mike St. Johns was asked to chair the team. The chairs of AAA-related WGs were also invited to join: Dave Mitton, co-chair of the NASREQ WG, Basavaraj Patil, co-chair of the Mobile IP WG, and Mark Stevens, co-chair of the RAP WG 👑 More team members were picked to represent network operators and the developers of AAA client and server software 🌈
As usual, the IESG advised the team. The IESG advisors were Randy Bush and Bert Wijnen, Directors of the Operations and Management Area 🫶
1.2. Chairman's Note:
This document is the result of 6 weeks of intense work by the panel listed above 😭 Their mission was to evaluate the various AAA proposals and give the AAA working group and the IESG recommendations on how viable each proposal was ✨
The evaluation 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 a side by side comparison of each proposal, requirement by requirement 🦋
Here's the tea: the evaluators were ONLY allowed to use information in the source documents (the requirements document and the proposal) or in documents those source documents referenced. In other words, if it wasn't written down, it generally didn't exist 💀 The cutoff for accepting information was 1 June 2000, so anything submitted after that wasn't considered in the panel's deliberations 🙈
1.3. Members Statements ✨
okay so the group was chaired by Michael St.Johns 👑, and David Mitton was the document editor 🖊️. Here's everyone's background statement, plus any conflicts of interest they flagged, from them and the rest of the panel 💅.
Michael St. Johns, Rainmaker Technologies 🌸
I have no known conflicts of interest with respect to the AAA process. I have neither advocated nor participated in the creation of any of the submissions. My company is a service company (ISP) and will not be involved in the manufacture or sale of AAA enabled products. Other than my participation as the chair of the AAA evaluation process, I have not had any contact with the AAA standards process.
David Mitton, Nortel Networks 🦋
I have been Nasreq WG co-chair and author of several Nasreq drafts. As well as, previously contributed to several RADIUS drafts.
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.
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.
Stuart Barkley, UUNET 🎀
I've been working for 5 years at UUNET on various parts of our dialup network. I have extensive experience with designing, developing and operating our SNMP based usage data gathering system. I've also been involved in our radius based authentication and authorization systems in an advisory position.
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.
Dave Nelson, Enterasys Networks 🧚
Very active in the RADIUS WG, especially during the early years. No involvement in the AAA submission. Have not contributed to the development of Diameter.
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.
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.
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.
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.
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.
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.
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.
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.
I've never worked for any of the companies whose staff have produced any of the proposals, although I obviously might at some future time.
1.4. Requirements Validation Process ✨
okay so 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 🌈.
1.5. Proposal Evaluation ✨
so 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.
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 🙈.
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 💖.
1.6. Final Recommendations Process ✨
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 ⭐.
2. Protocol Proposals 📦
The following proposal documents were submitted to the AAA WG for consideration by the deadline.
- SNMP:
- [SNMPComp] "Comparison of SNMPv3 Against AAA Network Access Requirements", Work in Progress.
- RADIUS Enhancements:
- [RADComp] "Comparison of RADIUS Against AAA Network Access Requirements", Work in Progress.
- [RADExt] "Framework for the extension of the RADIUS(v2) protocol", Work in Progress.
- Diameter
- [DIAComp] "Comparison of Diameter Against AAA Network Access Requirements", Work in Progress.
- COPS for AAA:
- [COPSComp] "Comparison of COPS Against the AAA NA Requirements", Work in Progress.
- [COPSAAA] "COPS Usage for AAA", Work in Progress.
3. Item Level Compliance Evaluation 🎯
okay so 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 acceptablyWhere two are shown eg: P/T, there was a tie.
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 General Requirements 💅
3.1.1 Scalability ✨
SNMP:P, RADIUS:P, Diameter:T, COPS:T
Okay so SNMP got downgraded 🥺 because nobody explained how the current agent model would adapt to a client request based transaction. RADIUS didn't handle it well either. And every proposal still has open issues around webs of proxies 🕸️
3.1.2 Fail-over 🔄
SNMP:P, RADIUS:P, Diameter:P, COPS:T/P
The group literally said they didn't think any protocol did well on this one 😭 Most submissions didn't do enough work on link failure detection and primary server recovery. COPS has some mechanisms, just not all of them. And nobody has addressed how these would work in a web of proxies.
3.1.3 Mutual Authentication 🫶
SNMP:T, RADIUS:T/P, Diameter:T, COPS:T
Lowkey a lot of the submissions missed the point here. The idea is that peers should be able to authenticate each other, either end-to-end or user-to-server. BUT the group is asking who actually needs this feature, and whether it could be done at a different level 🤔
Mutual authentication in RADIUS is only between hops.
3.1.4 Transmission Level Security 🔐
SNMP:T, RADIUS:P, Diameter:T, COPS:T
Every protocol has a way to secure the message data. Slay 💖
3.1.5 Data Object Confidentiality 🤫
SNMP:P, RADIUS:P, Diameter:T, COPS:T
This requirement usually comes from third-party situations, like access outsourcing.
Diameter and COPS both use CMS formats to secure data objects. The group is a little worried that this method, and the support for it, might be too heavy for NAS and some types of edge systems 🥹
3.1.6 Data Object Integrity 🛡️
SNMP:F, RADIUS:P, Diameter:T, COPS:T
The SNMP proposal didn't really describe how to protect the data object from changes 💀 The RADIUS solution wasn't very strong either.
3.1.7 Certificate Transport 📜
SNMP:T, RADIUS:T, Diameter:T, COPS:T
Every protocol can figure out some way to transport a certificate. Easy 🌸
3.1.8 Reliable AAA Transport 📦
SNMP:P, RADIUS:P, Diameter:T, COPS:T
The requirement never defines "how reliable" it has to be 🙈
The SNMP and RADIUS proposals were lacking when it came to solutions for message retransmission and recovery.
3.1.9 Run over IPv4 🌐
SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.1.10 Run over IPv6 🌍
SNMP:P, RADIUS:T, Diameter:T, COPS:T
The SNMP proposal said this area is still in the experimental stages 🧪
3.1.11 Support Proxy and Routing Brokers 🔀
SNMP:F, RADIUS:P, Diameter:T, COPS:P
The SNMP proposal didn't address this requirement at all. COPS claims support, but it doesn't work through some of the issues. Diameter was the only one that really tried to tackle this area, and it did a fairly good job 👑
3.1.12 Auditability 🧾
SNMP:F, RADIUS:F, Diameter:T, COPS:P
The group treated this requirement as something like "non-repudiation" 🦋 There's a concern that digital signatures might be too computationally expensive for some equipment, and not well deployed on those platforms.
The SNMP and RADIUS proposals didn't attempt this requirement. COPS suggests that a History PIB will help solve the problem, but it doesn't give any description.
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 when transport level security is present ✨
Pretty much every protocol can use an enveloping secure transport, which means they wouldn't need an internal secret. Iykyk 💜
3.1.14 Ability to Carry Service Specific Attributes 🎀
SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.2 Authentication Requirements 🔑
3.2.1 NAI Support 🪪
SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.2.2 CHAP Support 🧩
SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.2.3 EAP Support 🌈
SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.2.4 PAP/Clear-text Passwords 🔓
SNMP:T, RADIUS:T, Diameter:T, COPS:T
This clear-text password requirement comes from one-time-password systems and hard-token (SecurID) systems 🔢
3.2.5 Reauthentication on demand 🔁
SNMP:T, RADIUS:P, Diameter:P, COPS:T
To supply this, the proposal has to have asynchronous peer-to-peer capabilities, and there must be a defined operation for those state changes. Not optional bestie 🥺
We also split event-driven Reauthentication from timer-driven (or lifetime-driven) Reauthentication. The group is also still side-eyeing how this would work in a proxy environment 👀
3.2.6 Authorization w/o Authentication 🪄
SNMP:P, RADIUS:T/P, Diameter:T, COPS:T
This requirement really means authorization with trivial authentications, like by assertion or knowledge.
3.3 Authorization Requirements 🎟️
3.3.1 Static and Dynamic IP Addr Assignment 📍
SNMP:P/F, RADIUS:T, Diameter:T, COPS:T
It's hard to tell what counts as static or dynamic, because it depends on whether you're looking from the client, server, administrator or user's point of view 🤯
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 wouldn't be able to map directly back to RADIUS. But honestly, that's already a problem inside a RADIUS environment 🙃
3.3.3 Reject Capability 🚫
SNMP:T/P/F, RADIUS:T, Diameter:T, COPS:P
3.3.4 Preclude Layer 2 Tunneling 🕳️
SNMP:F, RADIUS:T, Diameter:T, COPS:T
3.3.5 Reauthorization on Demand 🔄
SNMP:P/F, RADIUS:P, Diameter:T/P, COPS:T
Some evaluators wondered how the server would know that re-authorization is supposed to happen 🤔 Would it interface with something external, or does it have enough internal smarts to handle it?
3.3.6 Support for Access Rules & Filters 🧱
SNMP:P, RADIUS:P, Diameter:P, COPS:T/P
Only the Diameter proposal actually tackled this, but the group felt the rules, as designed, were too weak to be useful. There was also concern about standardizing syntax without defining semantics 😬
3.3.7 State Reconciliation 🧮
SNMP:F, RADIUS:P/F, Diameter:P, COPS:T/P
All of the protocols were weak to non-existent on how this would work in a web of proxies 🕸️
3.3.8 Unsolicited Disconnect 📴
SNMP:T, RADIUS:P, Diameter:T, COPS:T
3.4 Accounting Requirements 📊
3.4.1 Real Time Accounting ⏱️
SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.4.2 Mandatory Compact Encoding 🗜️
SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.4.3 Accounting Record Extensibility 🧩
SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.4.4 Batch Accounting 📚
SNMP:T, RADIUS:F, Diameter:P, COPS:P
Some group members aren't sure how this fits into the rest of the AAA protocol, which is mostly real-time and event driven. Would FTP be a better fit for this? 🤷♀️
3.4.5 Guaranteed Delivery 📬
SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.4.6 Accounting Timestamps 🕰️
SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.4.7 Dynamic Accounting 💫
SNMP:T, RADIUS:T, Diameter:T, COPS:T
3.5 MOBILE IP Requirements 📱
3.5.1 Encoding of MOBILE IP Registration Messages 📝
SNMP:T, RADIUS:T/P, Diameter:T, COPS:T
3.5.2 Firewall Friendly 🧱💖
SNMP:F, RADIUS:T, Diameter:P, COPS:P
There was a LOT of discussion about what "firewall friendly" actually means 😭 One suggestion was that the firewall shouldn't have to look into packets much beyond the application port number. Protocols like SNMP and COPS are at a disadvantage, because you have to look far into the packet to understand the intended operation. Diameter will have the disadvantage of SCTP, which isn't well deployed or recognized at the moment.
SNMP and COPS also have the problem that they're used for other types of operations besides AAA.
Should firewalls have AAA Proxy engines? 👀
We didn't look at "NAT friendly" issues either.
COPS:T
The group isn't clear on how this requirement impacts the actual protocol. Raj explained it to us, but we mostly took it on faith 🙏
4. Protocol Evaluation Summaries 📋
4.1. SNMP 🫠
SNMP is generally not acceptable as a general AAA protocol. It could have some use for accounting, but the amount of engineering needed to turn it into a viable A&A protocol argues against further consideration.
4.2. Radius++ 🚧
Radius++ is not considered acceptable as an AAA protocol. It would need a fairly substantial amount of engineering to meet all requirements, and that engineering would most likely end up with something close to the functionality of Diameter 🤭
4.3. Diameter 👑
Diameter is considered acceptable as an AAA protocol. It needs some minor engineering to reach complete compliance with the requirements, but that's well within short term capabilities ✨ Diameter might also benefit from a broader data model, à la COPS.
4.4. COPS 🌸
COPS is considered acceptable as an AAA protocol. It needs some minor to medium engineering to reach complete compliance with the requirements.
4.5. Summary Recommendation 🏆
The panel has a slight preference for Diameter, because the work on Diameter seems further along than the work on COPS. However, using SCTP as the transport mechanism for Diameter puts SCTP on the critical path for Diameter. That could ultimately make COPS the faster approach if SCTP gets delayed in any way ⏳
5. Security Considerations 🚨💀
AAA protocols enforce the security of access to the Internet 🔐 This is seriously high stakes, bestie. The design of these protocols and this evaluation process treated many security requirements as critical issues for evaluation. A candidate protocol must meet the security requirements as documented, and it must be engineered and reviewed properly as it's developed and deployed. No shortcuts 😤
6. References 📚
[AAAReqts] Aboba, B., Clahoun, P., Glass, S., Hiller, T., McCann, P., Shiino, H., Walsh, P., Zorn, G., Dommety, G., Perkins, C., Patil, B., Mitton, D., Manning, S., Beadles, M., Chen, X., Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu, R., Koo, H., Lipford, M., Campbell, E., Xu, Y., Baba, S. and E. Jaques, "Criteria for Evaluating AAA Protocols for Network Access", RFC 2989, April 2000.
[AAAComp] Ekstein, TJoens, Sales and Paridaens, "AAA Protocols: Comparison between RADIUS, Diameter and COPS", Work in Progress.
[SNMPComp] Natale, "Comparison of SNMPv3 Against AAA Network Access Requirements", Work in Progress.
[RADComp] TJoens and DeVries, "Comparison of RADIUS Against AAA Network Access Requirements", Work in Progress.
[RADExt] TJoens, Ekstein and DeVries, "Framework for the extension of the RADIUS (v2) protocol", Work in Progress,
[DIAComp] Calhoun, "Comparison of Diameter Against AAA Network Access Requirements", Work in Progress.
[COPSComp] Khosravi, Durham and Walker, "Comparison of COPS Against the AAA NA Requirements", Work in Progress.
[COPSAAA] Durham, Khosravi, Weiss and Filename, "COPS Usage for AAA", Work in Progress.
7. Authors' Addresses ✨
okay so here are the squad members who made this happen 🫶 I've kept every phone number and email exactly as written
David Mitton
Nortel Networks
880 Technology Park Drive
Billerica, MA 01821
Phone: 978-288-4570
EMail: dmitton@nortelnetworks.com
Michael StJohns
Rainmaker Technologies
19050 Pruneridge Ave, Suite 150
Cupertino, CA 95014
Phone: 408-861-9550 x5735
EMail: stjohns@rainmakertechnologies.com
Stuart Barkley
UUNET
F1-1-612
22001 Loudoun County Parkway
Ashburn, VA 20147 US
Phone: 703-886-5645
EMail: stuartb@uu.net
David B. Nelson
Enterasys Networks, Inc. (a Cabletron Systems company)
50 Minuteman Road
Andover, MA 01810-1008
Phone: 978-684-1330
EMail: dnelson@enterasys.com
Basavaraj Patil
Nokia
6000 Connection Dr.
Irving, TX 75039
Phone: +1 972-894-6709
EMail: Basavaraj.Patil@nokia.com
Mark Stevens
Ellacoya Networks
7 Henry Clay Drive
Merrimack, NH 03054
Phone: 603-577-5544 ext. 325
EMail: mstevens@ellacoya.com
Barney Wolff, Pres.
Databus Inc.
15 Victor Drive
Irvington, NY 10533-1919 USA
Phone: 914-591-5677
EMail: barney@databus.comAppendix A - Summary Evaluations Consensus Results by Requirement and Protocol 🌈
this is the big scoreboard 📊 every requirement, every protocol, and who got a T (total), P (partial), or F (fail) 💅
Requirement Section SNMP Radius++ Diameter COPS
1.1.1 P P T T
1.1.2 P P P T/P
1.1.3 T T/P T T
1.1.4 T P T T
1.1.5 P P T T
1.1.6 F P T T
1.1.7 T T T T
1.1.8 P P T T
1.1.9 T T T T
1.1.10 P T T T
1.1.11 F P T P
1.1.12 F F T P
1.1.13 P/T T T T
1.1.14 T T T T
1.2.1 T T T T
1.2.2 T T T T
1.2.3 T T T T
1.2.4 T T T T
1.2.5 T P P T
1.2.6 P T/P T T
1.3.1 P/F T T T
1.3.2 P T T/P P
1.3.3 T/P/F T T P
1.3.4 F T T T
1.3.5 P/F P T/P T
1.3.6 P P P T/P
1.3.7 F P/F P T/P
1.3.8 T P T T
1.4.1 T T T T
1.4.2 T T T T
1.4.3 T T T T
1.4.4 T F P P
1.4.5 T T T T
1.4.6 T T T T
1.4.7 T T T T
1.5.1 T T/P T T
1.5.2 F T P P
1.5.3 F P T TAppendix B - Review of the Requirements 🔍
so the panel had a bunch of comments on the work in progress, "Criteria for Evaluating AAA Protocols for Network Access," which later got revised and published as RFC 2989 💖 this became the group's standard way of reading the requirements at the time, so these notes are the tea ☕
B.1 General Requirements
Scalability: in clarification [a], delete "and tens of thousands of simultaneous requests." none of the three base documents seem to back that up 🙈
Transmission level security: in the table, delete the ROAMOPS "M" and footnote "6". this looks like an overgeneralization of the roaming protocol requirement, and it's not necessarily something that applies to AAA 💅
Data object confidentiality: in the table, delete the MOBILE IP "S" and footnote "33". the base document text doesn't seem to support this one 💀
Reliable AAA transport mechanism: in clarification [h], delete everything after the "...packet loss" and replace it with a ".". the requirements listed here aren't necessarily supported by the base document, and people could mistakenly read them as requirements for the AAA protocol as a whole 😭
Run over IPv4: in the table, replace the MOBILE IP footnote "17" with footnote "33". this looks like an incorrect reference 🫠
Run over IPv6: in the table, replace the MOBILE IP footnote "18" with a footnote pointing to section 8 of [8]. this also looks like an incorrect reference 🙃
Auditability: clarification [j] doesn't seem to match the NASREQ meaning of Auditability. NASREQ is the only protocol with an auditability requirement, so this section should be aligned with that meaning ✨
Shared secret not required: this section is misleadingly labeled, honestly 😤 our team interpreted it the way clarification [k] describes, not any of the other possible readings of "shared secret not required." we recommend renaming the table tag to "Dual App and Transport Security Not Required" or something at least somewhat descriptive of [k]. also delete the NASREQ "S" and footnote "28", since the NASREQ document doesn't support it. and delete the MOBILE IP "O" and footnotes "34" and "39" because they're not supported either 🧚
B.2 Authentication Requirements
NAI Support: in the table, replace MOBILE IP footnote "38" with "39". that's a more appropriate reference 🎀
CHAP Support: in the table, delete MOBILE IP "O" because it's unsupported 🙅♀️
EAP Support: in the table, delete MOBILE IP "O" because it's unsupported 🙅♀️
PAP/Clear-Text Support: in the table, replace NASREQ footnote "10" with "26" since that's more appropriate. replace ROAMOPS "B" with "O". the reference text doesn't explicitly ban this, and it specifically mentions clear text for OTP applications 🔐 also delete MOBILE IP "O" because it's unsupported.
Re-authentication on demand: clarification [e] seems to go beyond what NASREQ and MOBILE IP require 👀 in the table, delete MOBILE IP footnote "30" since it doesn't apply.
Authorization Only without Authentication: clarification [f] doesn't include all the NASREQ requirements. specifically, unneeded credentials MUST NOT be required to be filled in 🚫 since there are no other base requirements left (once the MOBILE IP requirement is deleted), we recommend bringing clarification [f] in line with NASREQ. in the table, delete MOBILE IP "O" and footnote "30", because the referenced text doesn't seem to support the requirement.
B.3 Authorization Requirements
Static and Dynamic...: clarification [a] uses a really strange definition of static and dynamic addressing 😵💫 we recommend adding a clarification that says who (e.g. client or server) thinks the address is static or dynamic. in the table, ROAMOPS "M" looks like a derived requirement rather than one that's directly called out. footnote "1" should change to "5" since that's more appropriate. a text clarification should also be added to this document that identifies the derived requirement 🧩
RADIUS Gateway capability: in the table, delete the MOBILE IP "O" and footnote "30", because the referenced text doesn't seem to support the requirement 💅
Reject capability: in the table, delete the NASREQ "M" and footnote "12". the NASREQ document doesn't seem to require this capability 🙅♀️
Reauthorization on Demand: in the table, delete the MOBILE IP "S" and footnotes "30,33", because the referenced text doesn't support this requirement 💀
Support for Access Rules...: clarification [e] has an overbroad list of requirements. NASREQ only requires items 5-8 on that list. since the MOBILE IP requirement isn't supported by its references, this clarification should match the NASREQ requirements 🫶 in the table, delete the MOBILE IP "O" and footnotes "30,37" since they're not supported.
State Reconciliation: clarification [f] should be brought in line with the NASREQ requirements. right now it imposes overbroad requirements that NASREQ doesn't need, and NASREQ is the only service with requirements in this area 🌸
B.4 Accounting Requirements
Real-Time accounting: in the table, replace MOBILE IP footnote [39] with a footnote pointing to section 3.1 of [3], since that's more appropriate ⏱️
Mandatory Compact Encoding: in the table, delete MOBILE IP "M" and footnote "33", because the reference doesn't support the requirement 🗜️
Accounting Record Extensibility: in the table, delete NASREQ "M" and footnote "15", because the reference doesn't support the requirement 🧾
Accounting Time Stamps: in the table, delete MOBILE IP "S" and footnote "30", because they don't support the requirement. also replace MOBILE IP footnote "40" with a footnote pointing to section 3.1 of [3], which is more appropriate 🕰️
Dynamic Accounting: in the table, replace NASREQ footnote "18" with a footnote pointing to section 8.4.1.5 of [3]. delete MOBILE IP "S" and footnote "30" as well, since the reference doesn't support the requirement ✨
Footnote section: a few footnotes need fixing up too 🛠️
[40]should point to 6.1 of [4].[41]should point to 6.2.2 of [4].[45]should point to 6.4 of [4].[46]should point to 8 of [4].
Appendix C - Position Briefs 🎀
C.1 SNMP PRO Evaluation
this is the SNMP evaluation by Stuart Barkley, and it's giving detailed and thorough 🧐 the header info is below
Evaluation of SNMP AAA Requirements
PRO Evaluation
Evaluator - Stuart Barkley
Ref [1] is "Comparison of SNMPv3 Against AAA Network Access
Requirements", aka 'the document'
Ref [2] is the aaa eval criteria as modified by us, aka 'the
requirements'so the document uses T for total compliance, P for partial compliance, and F for no compliance 💜 for each section, Stuart shares their grade, and if it changed, they show that along with the grade the authors gave 📝
1 Per item discussion
1.1 General Requirements
1.1.1 Scalability - Grade T 🌈 the document says SNMP can handle that scale based on the requirements document. most current uses are PPP connections, and SNMP already handles the interface table and other per-session tables, so basic capacity is clearly there ✨ adding support for other tables and variables scales in a simple linear way, based on how many extra variables and protocol interactions there are. no matter which protocol gets picked, handling the scaling is not a small job 😤 SNMP can lean on existing network management practices to help with the implementation.
1.1.2 Fail-over - Grade T 💖 SNMP is super important to how most networks run 🫶 existing infrastructures can handle the required failover or other redundant operations.
1.1.3 Mutual Authentication - Grade T
The shared secret stuff is a totally well-understood way to do integrity control, bestie 🔐. It's not full authentication, since other parties might also have the same secrets 👀, but the level of authentication is good enough for the job ✨. In lots of cases the SNMP infrastructure already exists, and the shared secrets should already be properly managed on a live network 🌸. If the shared secret approach fails, no matter which AAA protocol you're using, equipment and systems are gonna be wide open to serious misuse, and any fancier AAA authentication gets bypassed 💀. Not okay!
1.1.4 Transmission Level Security - Grade T 🎀
SNMPv3 comes with a bunch of extra security options that weren't around, or were way more controversial, in older SNMP versions 🧁.
1.1.5 Data Object Confidentiality - New Grade P (from T) 🫣
SNMPv3 can give data confidentiality for data passing over the wire 🔒. The requirements have a lot of implied AAA architecture (brokers and proxies) in them, so full conformance is hard to pin down 😩. The evaluator struggles with the concept of "the target AAA entity for whom the data is ultimately destined," but concedes the requirement is only partially met, especially when it comes to transferring a PAP password 🙈.
1.1.6 Data Object Integrity - New Grade T (from P) 🛡️
SNMP has full capabilities for authenticating the data ✅. Brokers, proxies, or other intermediaries in the data chain can verify where the info came from and check that nobody tampered with it 🕵️♀️. The document downgrades the grade to P because of confusion over the integrity checking role of intermediaries 🤷♀️.
1.1.7 Certificate Transport - Grade T 📜
The requirements call for the ability to transport certificates, but they don't have any specific use for them 🤔. They assume the protocol chosen will depend on certificates, and that's not necessarily true. SNMP can transport arbitrary objects, and it can transport certificates if needed 📦. The document flags some issues with certificate size and current maximum practical data sizes, but if the compact encoding requirement covers the internal certificate information, this should be less of an issue 💅.
1.1.8 Reliable AAA Transport - New Grade T (from P) 🚚
The requirement is stated pretty strongly and makes big assumptions about AAA protocol architecture, based on current protocols and their failings 😬. SNMP allows for great flexibility in retransmission schemes, depending on how important the data is ⭐.
1.1.9 Run over IPv4 - Grade T 🌐
SNMP has been running this way for many years 👑.
1.1.10 Run over IPv6 - New Grade T (from P) 🌍
SNMP must support IPv6 for lots of other systems, so support for it should be possible by the time the requirement takes effect 🧚. The document notes that experimental versions satisfying this requirement already exist 🧪.
1.1.11 Support Proxy and Routing Brokers - New Grade T (from P) 🔀
The requirements make significant assumptions about the final architecture 🏗️. It's well within SNMP's capabilities to provide intermediaries that channel data flows between multiple parties 💖. The document downgrades SNMP's compliance with this requirement because of issues covered more specifically under "Data Object Confidially," which the evaluator has downgraded to P 🙃.
1.1.12 Auditability - New Grade T (from F) 🔍
Data flows inside SNMP are easily auditable, since you can set up secondary data flows that give copies of all information to auxiliary servers 📋. The document grades this as a failure, but that support is only minor additions within a more fully fleshed-out set of data flows 😤.
1.1.13 Shared Secret Not Required - Grade T 🗝️
SNMP doesn't require shared secrets 🙌. They're desirable in many instances where a lower level doesn't provide the necessary capabilities 🍓. The document supplies pointers to various security modes that are available 📚.
1.1.14 Ability to Carry Service Specific Attributes - Grade T 🧩
SNMP has long had the ability for other parties to create new unambiguous attributes 💜.
1.2 Authentication Requirements ✨
1.2.1 NAI Support - Grade T 🪪
SNMP easily supports this. NAIs were defined to be easy to carry in existing protocols 🥰.
1.2.2 CHAP Support - Grade T 🎫
SNMP can easily provide objects that pass the information needed for CHAP operation 🧁.
1.2.3 EAP Support - New Grade T (from P) 🌈
SNMP can easily provide objects that pass the information needed for EAP operation. Just like with CHAP or PAP, MIB objects can be created to control this operation, which is why it gets upgraded from the document's grade 🆙.
1.2.4 PAP/Clear-text Passwords - New Grade P (from T) 🙈
SNMP can easily provide objects that pass the information needed for PAP operation 💁♀️. The requirement about non-disclosure of clear text passwords makes assumptions about the protocol implementation. Choosing clear text passwords is inherently insecure, and the forced protocol architecture doesn't really cover this 😬. The grade gets downgraded to P (partial) because the document doesn't really address the confidentiality of data at application proxies 💀.
1.2.5 Reauthorization on demand - Grade T 🔁
SNMP can easily provide objects to control this operation 🎛️.
1.2.6 Authorization w/o Authentication - New Grade T (from T) 🤓
The document makes an incorrect interpretation of this requirement 🧐. However, SNMP doesn't restrict anything that would stop the desired requirements, so SNMP satisfies both the actual requirement and the incorrect interpretation 🫶. No actual change of grade is necessary 💅.
1.3 Authorization Requirements 🦋
1.3.1 Static and Dynamic IP Addr Assignment - Grade T 📍
SNMP can easily provide objects to control this operation 🎀.
1.3.2 RADIUS Gateway Capability - Grade T 🚪
As the document describes, with the addition of any necessary compatibility variables, SNMP can be gatewayed to RADIUS applications 🌉.
1.3.3 Reject Capability - Grade T 🙅♀️
Any of the active components in the SNMP based structure could decide to reject an authentication request for any reason 🚫. Because the requirement levels get mixed up, the document doesn't try to address this directly, and instead says a higher level application can cause this operation 🤷♀️.
1.3.4 Preclude Layer 2 Tunneling - New Grade T (from ?) 🕳️
Nothing in SNMP explicitly interacts with the selection of any tunneling mechanisms the client may choose 🫠. The document author was unclear about what the needs are here 🤔.
1.3.5 Reauth on Demand - Grade T 🔄
SNMP can easily provide objects to control this operation 🎚️.
1.3.6 Support for ACLs - Grade T 🧱
The document indicates that, should it be desired, SNMP can provide objects to control these operations 🛠️. On top of that, active components can apply substantial further configurable access controls 🔐.
1.3.7 State Reconciliation - Grade T 🧠
The requirements describe an overly broad set of required capabilities 😵💫. The document is concerned about incompatibilities in the requirements, but SNMP can provide methods that let active components reacquire lost state information ♻️. These capabilities directly interact with scalability concerns, so care needs to be taken if you expect this requirement and the scalability requirements to be met at the same time ⚖️.
1.3.8 Unsolicited Disconnect - Grade T 👋
The document indicates that SNMP can easily provide objects to control this operation 💫.
1.4 Accounting Requirements 📊
1.4.1 Real Time Accounting - Grade T ⏱️
SNMP can provide this mode of operation ⚡. The document outlines methods that work fully within SNMP and methods that use SNMP to interface with other transfer methods 🔌. Many providers already use SNMP for real time notification of other network events 📣. This capability can directly interact with scalability concerns, and implementation care needs to be taken to make it interact properly in large scale environments 🏔️.
1.4.2 Mandatory Compact Encoding - Grade T 🗜️
The document points out 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 fairly compact compared with text based forms (like the ones 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 🌟.
1.4.3 Accounting Record Extensibility - Grade T 🧾
SNMP has a strong tradition of allowing vendor specific data objects to be transferred 🎁.
1.4.4 Batch Accounting - Grade T 📦
There are lots of methods an SNMP based system could use for batch accounting 🧺. The document discusses SNMP parameters that control the batching process and indicates that certain existing MIBs contain examples of implementation strategies 🗂️. SNMP log tables can provide accounting information that can be obtained in many ways not directly related to real time capabilities 🕰️. The underlying system buffering requirements are similar no matter which protocol is used to transport the information 🧱.
1.4.5 Guaranteed Delivery - Grade T 💌
SNMP is very amenable to providing guaranteed delivery 💯. Especially 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 doesn't know if the originator of the data is having problems delivering it 😰.
1.4.6 Accounting Timestamps - Grade T ⏰
Timestamps are used for lots of SNMP based operations 🕑. The document points at the DateAndTime textual convention, which is available for use 📅. As with all environments, the timestamp accuracy needs to be evaluated before the information should be relied upon 🔍.
1.4.7 Dynamic Accounting - Grade T 🔗
As long as there's some way to relate multiple records together, there are no problems resolving multiple records for the same session 🧵. This interacts with the scalability requirement, so care must be taken when implementing a system with both of these requirements 🙏.
1.5 MOBILE IP Requirements 📱
1.5.1 Encoding of MOBILE IP Registration Messages - Grade T 📝
SNMP can easily provide objects to transfer this information 🚀.
1.5.2 Firewall Friendly - New Grade T (from P) 🔥
SNMP is already deployed in many operational networks 🏢. SNMPv3 addresses most of the concerns people had with previous versions 💪. True SNMPv3 proxies (as opposed to AAA proxies) should become commonplace components in firewalls for organizations that require firewalls 🧱✨.
1.5.3 Allocation of Local Home Agent - New Grade T (from ?) 🏠
SNMP isn't concerned with the LHA. That can be under control of the local network to meet its needs 🗝️.
2. Summary Discussion 🌟
SNMP appears to meet most stated requirements 🥇. The areas where the SNMP proposal falls short are the areas where specific AAA architectures are envisioned, and requirements based upon that architecture are specified 🫶.
Scaling is everything for a whole AAA suite, bestie 💖 and honestly SNMP has been crushing it in network management and other high-volume data transfer stuff ✨. You still have to design a big system carefully to hit the service level you want, but that's true of any big project 🫶
3. General Requirements
SNMP is well understood and already supported in tons of ISP and other operational environments 🌸. Trust models already exist in a lot of cases and can be adapted to give the AAA protocols the access controls they need 🔐. The big issues with older SNMP versions got fixed in the current SNMPv3 spec, so we're giving it a glow-up 💅
The SNMP proposal doesn't say which specific data variables and message types to implement 🙈. That's mostly because the requirements never spelled out the necessary data elements, and there wasn't time to dig that info out of the base document set ⏰. A data model is still needed no matter which protocol ends up getting picked 📊
4. Summary Recommendation
SNMP seems to fully meet all the necessary requirements for the full AAA protocol family 👑
C.2 SNMP CON Evaluation
Evaluation of SNMP AAA Requirements 💜 CON Evaluation 💜 Evaluator - 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 🎀
The document uses T to mean total compliance, P to mean partial compliance, and F to mean no compliance. For each section, I've written down my grade. If nothing changed, I've said so and kept the grade the authors gave 🦋
Section 1 - Per item discussion
1.1 General Requirements
1.1.1 Scalability - Although the document says it complies with the requirement, it's unclear how SNMP actually meets it. The document neither discusses how SNMP will scale nor provides applicable references. The argument that there's an existence proof, given the deployed SNMP systems, seems to assume that one manager contacting many agents maps to many agents (running AAA) contacting one AAA server. A server-driven system has very different scaling properties than a client-driven system, and SNMP is most definitely a server (manager) driven system 💀 Eval - F
1.1.2 Fail-over - The document uses application-level time outs to provide this mechanism, rather than making it a characteristic of the proposed protocol 🙃 The protocol only gets partial compliance with the requirement. Eval - P
1.1.3 Mutual Authentication - There's some slight handwaving here, but the protocol's USM mode should be able to support this requirement 🫶 Eval - No Change (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.5 Data Object Confidentiality - The authors describe a mechanism that doesn't 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, and that doesn't map well to this requirement 😭 Eval - P
1.1.6 Data Object Integrity - There appears to be some handwaving going on here. Again, SNMP doesn't look like a good match for this requirement, partly because SNMP lacks a proxy intermediary concept 💀 Eval - F
1.1.7 Certificate Transport - The document does indicate compliance, but it notes that optimization might argue for specialized protocols 🦋 Eval - No Change (T)
1.1.8 Reliable AAA Transport - The document shows some confusion about the exact extent of this requirement. Given the modifications the eval group suggested to the explanatory text in [2] for the related annotation, the point-by-point explanatory text isn't required. The document does say that using SNMP is irrespective of the underlying transport, and support for this requirement is at least partly related 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.9 Run over IPv4 - The evaluator agrees that SNMPv3 runs over V4, but the authors need to point to some sort of reference 📚 Eval - No Change (T)
1.1.10 Run over IPv6 - The document mentions both experimental implementations and future standardization of SNMPv3 over IPv6 ✨ Eval - No Change (P)
1.1.11 Support Proxy and Routing Brokers - The section of the document that, by its title, should discuss the 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 compliance here, and the evaluator agrees. Eval - F
1.1.12 Auditability - The document indicates no compliance with this requirement. Eval - No Change (F)
1.1.13 Shared Secret Not Required - Slight handwaving here, but SNMPv3 doesn't necessarily require its security services if other security services are available 🔥 However, the interaction with VACM in the absence of USM isn't fully described and may not have good characteristics related to this requirement. Eval - P
1.1.14 Ability to Carry Service Specific Attributes - SNMP complies through the use of MIBs 👑 Eval - No Change (T)
1.2 Authentication Requirements
1.2.1 NAI Support - The document says MIB objects can be created to meet this requirement, but gives no further information. Eval - P
1.2.2 CHAP Support - The document says MIB objects can be created to meet this requirement, but gives no further information. With the normal CHAP model, it's unclear exactly how this would work 💀 Eval - F
1.2.3 EAP Support - The document notes that EAP payloads can be carried as specific MIB objects, but also notes that further design work would be needed to fully incorporate EAP. Eval - No Change (P)
1.2.4 PAP/Clear-text Passwords - The document notes the use of MIB objects to carry clear-text passwords, and says those objects are protected under normal SNMPv3 security mechanisms 🔐 Eval - No Change (T)
1.2.5 Reauthorization on demand - There's some handwaving here, but it's clear that specific applications can generate the signals to trigger reauthorization under SNMP ✨ Eval - No Change (T)
1.2.6 Authorization w/o Authentication - The author seems to be confusing AAA protocol authorization with AAA user authorization, and appears to be overgeneralizing SNMP's ability to handle general AAA user authorization 😭 Eval - F
1.3 Authorization Requirements
1.3.1 Static and Dynamic IP Addr Assignment - The reference to MIB objects, without more definite references or descriptions, is still a negative 🙃 The evaluator agrees MIB objects can represent addresses, but the document needs to at least point the reader in the right direction. Eval - F
1.3.2 RADIUS Gateway Capability - The transport and manipulation of RADIUS objects looks like only part of what's required 🎀 Eval - P
1.3.3 Reject Capability - Again, a clarification of how SNMP might accomplish this requirement would help. The overall document lacks a theory of operation for SNMP in an AAA role, which could have clarified the various approaches 💅 Eval - F
1.3.4 Preclude Layer 2 Tunneling - The document shows a lack of understanding of this requirement 😭 Eval - F
1.3.5 Reauth on Demand - See the 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.6 Support for ACLs - The response text again references MIB objects that could be defined to do this job. There's additional engineering and design needed before this is a done deal 🛠️ Eval - P
1.3.7 State Reconciliation - The text fails to address the basic question of how to get the various parts of the AAA system back in sync 😵 Eval - F
1.3.8 Unsolicited Disconnect - Assuming the NAS is an SNMP agent for an AAA server acting as an SNMP manager, the evaluator concurs 🫶 Eval - No Change (T).
1.4 Accounting Requirements
1.4.1 Real Time Accounting - SNMP Informs could accomplish the requirements 🚀 Eval - No Change (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.3 Accounting Record Extensibility - MIBs are extensible 🌈 Eval - No Change (T)
1.4.4 Batch Accounting - MIBs provide data collection at various times ⏰ Eval - No Change (T)
1.4.5 Guaranteed Delivery - There's some weasel wording here about what "guaranteed" means, but the description of mechanisms does appear to meet the requirements 🙈 Eval - No Change (T)
1.4.6 Accounting Timestamps - Accounting records can use the DateAndTime Textual Convention to mark their times ⏰ Eval - No Change (T)
1.4.7 Dynamic Accounting - The author may have partly missed the point on this requirement. The number of records per session isn't of great interest, but the delivery may be. The author should go into more depth on this requirement 🧐 Eval - No Change (T)
1.5 MOBILE IP Requirements
1.5.1 Encoding of MOBILE IP Registration Messages - Registration messages can probably be encoded as SNMP messages ✨ Eval - No Change (T)
1.5.2 Firewall Friendly - There's a chicken-and-egg problem here. The author hopes that SNMP, as an AAA protocol, will encourage firewall vendors to make SNMP a firewall-friendly protocol 🔥 Eval - F
1.5.3 Allocation of Local Home Agent - The author disclaims any understanding of this requirement 😭 Eval - F
2. Summary Discussion
The document's evaluation score was substantially affected by the lack of any document, reference, or text describing a theory of operation for SNMP in AAA mode 💅 Of substantial concern are the items relating to AAA server-to-server modes and AAA client-to-server modes, and the lack of a map to the SNMP protocol for those modes.
The evaluator also notes that the scaling issues of SNMP in agent/manager mode are in no way indicative of SNMP in AAA client/server mode. That has a possibility of substantially impairing SNMP's use in an AAA role 😬
However, SNMP may have a reasonable role in the Accounting space 🎀 SNMP appears to map well to existing technology and to the requirements 💖
3. General Requirements
SNMP appears to meet the general requirements of an IP-capable protocol, but it may not have a proper field of use for all the specific requirements 🦋
4. Summary Recommendation
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 👑
C.3 RADIUS+ PRO Evaluation 🎀
Evaluation of RADIUS AAA Requirements PRO Evaluation ✨
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. 📚
The document uses T to indicate total compliance, P to indicate partial compliance, and F to indicate no compliance. 🌈
For each section, I've put down my grade for that section. I've also marked whether my evaluation differs from the statements made about RADIUS++. The ratings below may differ from the ones in the document referred to as "Comparison of RADIUS Against AAA Network Access Requirements" without any indication. 🙈
1.1 General Requirements
1.1.1 [a] Scalability - As far as a protocol's scalability can be measured, this one seems to send information in a fairly efficient way. It doesn't seem to eat an inordinate amount of bandwidth for the data it's carrying, so it could be considered scalable 🦋. However, the protocol has a limit on how many concurrent sessions it can support between endpoints. Workarounds exist and are in use. Eval - P (no change)
1.1.2 [b] Fail-over - The document says fail-over is handled with application-level timeouts, rather than being a characteristic of the proposed protocol. The fail-over requirement says the protocol must provide the mechanism, not the application. The implication is that the application doesn't need to be aware that fail-over and the subsequent correction happen. With RADIUS++, the application is involved in fail-over recovery activities, and the protocol layer of the software doesn't seem to have that capability built in. Given the wording of the requirement: Eval - P (changed from T)
1.1.3 [c] Mutual Authentication - The RADIUS++ protocol provides shared-secret as a built-in facility for mutual authentication. The authors of the document suggest using IPSec to get mutual authentication functions. RADIUS++ puts no roadblocks in the way of mutual authentication between instances of AAA applications, but the protocol doesn't provide any facilities for doing so. 🫶
1.1.4 [d] Transmission Level Security - RADIUS++ provides no transmission level security features, but it also doesn't rule out using IPSec to get transmission level security. Eval - P (no change)
1.1.5 [e] Data Object Confidentiality - The document describes a RAIDUS++ message designed to serve as an envelope in which encrypted RADIUS messages (attributes) may be enclosed. Eval - T (no change) 🔐
1.1.6 [f] Data Object Integrity - Using visible signatures, the RADIUS++ protocol appears to meet this requirement. Eval - T (no change) ✨
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.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 doesn't provide reliability features, so reliability is still the responsibility of the application or an augmenting protocol. Eval - P (no change)
1.1.9 [i] Run over IPv4 - Eval - T (no change) 🌸
1.1.10 [j] Run over IPv6 - An IPv6 Address data type must be defined. Eval - T (no change) 🧚
1.1.11 [k] Support Proxy and Routing Brokers - There's no mechanism for rerouting requests, but an extension can be made to do so. Eval - T (no change) 🔥
1.1.12 [l] Auditability - The document indicates no compliance with this requirement. Eval - F (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 - A vendor escape mechanism can be used for this purpose. Eval - T (no change) 👑
1.2 Authentication Requirements
1.2.1 [a] NAI Support - Eval - T (no change) 🦋
1.2.2 [b] CHAP Support - Subject to dictionary attacks. Eval - P (changed from T) 😭
1.2.3 [c] EAP Support - Eval - T (no change) ✨
1.2.4 [d] PAP/Clear-text Passwords - No end-to-end security, but there's potential for encapsulation within the current paradigm of the protocol. Eval - T (no change) 🙈
1.2.5 [e] Reauthentication on demand - The RADIUS protocol supports re-authentication. If the user or AAA client starts re-authentication, the AAA client can send a new authentication request. Re-authentication can also be started from the visited or home AAA server by sending a challenge message to the AAA client. Eval - T (no change) 🌈
1.2.6 [f] Authorization w/o Authentication - A new message type can be created so that RADIUS++ supports Aw/oA. Eval - T (no change) 💅
1.3 Authorization Requirements
1.3.1 [a] Static and Dynamic IP Addr Assignment - Both are supported. IPv6 would require defining a new address data type. Eval - P (no change) 🎀
1.3.2 [b] RADIUS Gateway Capability - Transporting and manipulating RADIUS objects appears to be only part of what's required. The requirement seems to be worded to rule out RADIUS. Eval - P (changed from T) 😬
1.3.3 [c] Reject Capability - Eval - T ✅
1.3.4 [d] Preclude Layer 2 Tunneling - I don't see a definition for this in the AAA eval criteria document. Eval - ? 🤔
1.3.5 [e] Reauthorization on Demand - Field implementations show that extensions to RADIUS can support the desired behavior. Re-authentication is currently coupled to re-authorization. Eval - P (no change) 🔁
1.3.6 [f] Support for ACLs - This is currently done in the applications behind the RADIUS end points, not within the protocol. RADIUS++ could define additional message types to deal with expanded access control in new service areas. Eval - P (no change) 🛡️
1.3.7 [g] State Reconciliation - Eval - F (no change) 💔
1.3.8 [h] Unsolicited Disconnect - RADIUS++ extensions support this. Eval - T (no change) 🚪
1.4 Accounting Requirements
1.4.1 [a] Real Time Accounting - Eval - T (no change) ⏰
1.4.2 [b] Mandatory Compact Encoding - Eval - T (no change) 📦
1.4.3 [c] Accounting Record Extensibility - Eval - T (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 - A retransmission algorithm is employed. 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 support this. Eval - T (no change) ⭐
1.5 MOBILE IP Requirements
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.2 [b] Firewall Friendly - RADIUS is known to work in environments where firewalls acting as proxies are active. Eval - T (no change) 🧱
1.5.3 [c] Allocation of Local Home Agent - The requirement statement needs some clarification and refinement. Eval - F (no change) 🌀
2. Summary Discussion
The RADIUS protocol, and its associated extensions, is presently not fully compliant with the AAA Network Access requirements. However, it's possible, with a small effort, to extend present procedures to meet the requirements as listed, while keeping a high level of interoperability with the wide deployment and installed base of RADIUS clients and servers. 🌷
3. General Requirements
RADIUS++, the protocol and the application, meets the majority of the requirements and can be extended to meet the rest where necessary. 💪
4. Summary Recommendation
RADIUS++ as it could be developed would offer a level of backward compatibility that other protocols can't achieve. By extending RADIUS in the simple ways described in the documents listed above, the move from existing RADIUS-based installations to RADIUS++ installations would be easier. Although accounting remains weaker than other approaches, the protocol is a strong contender for continued use in Authorization and Authentication. 👑✨
C.4 RADIUS+ CON Evaluation 🌩️
Evaluation of RADIUS++ (sic) AAA Requirements CON Evaluation 🧐
Evaluator - 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. 📚
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] predates the protocol [2]. It's clear from reading [2] that some of the shortcomings identified in [1] are now addressed in [2]. The evaluator has tried to note these exceptions wherever they occur. 📝
Section 1 - Per item discussion
1.1 General Requirements
1.1.1 Scalability - The document [1] indicates partial compliance, largely out of deference to the "tens of thousands of simultaneous requests" language in [3], which has been deprecated. The issue of simultaneous requests from a single AAA client is addressed in [1], which says the apparent limit of 256 uniquely identifiable outstanding requests 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.2 Fail-over - The document [1] says fail-over is provided by application-level timeouts. Since AAA is indeed an application-layer protocol, this seems appropriate. There are significant issues with how to handle fail-over in a proxy-chain environment, though, and those haven't been well addressed. The document claims "T", and the evaluator awards "P". 😅
1.1.3 Mutual Authentication - The document [1] says mutual authentication exists when a User-Password or CHAP-Password attribute is present in an Access-Request packet, or when the Message-Authenticator [4] is in any packet. Once again, this addresses hop-by-hop authentication of RADIUS "peers", but it doesn't fully cover proxy-chain environments, where trust models would need to be established. The document further says strong mutual authentication could be achieved using the facilities of IPsec. This claim would apply equally to all potential AAA protocols, so it can't fairly be called a property of the protocol itself. The document claims "T", and the evaluator awards "F". 🚫
1.1.4 Transmission Level Security - The document [1] says transmission layer security, as defined in [3], is provided by the protocol, using the mechanisms described in section 1.1.3. It's worth noting that this requirement is now a SHOULD in [3]. The document claims "P", and the evaluator concurs. 🔒
That's the whole evaluation, bestie 🎀
1.1.5 Data Object Confidentiality 🔐
okay so the document [1] says end-to-end confidentiality is not available in RADIUS 🥺 but then it's like "it could be added!" 💅 and the protocol [2] actually tries to spell out how, in section 4.3.2.2 of [2], using a CMS-data attribute that's mostly based on RFC 2630. the evaluator hasn't looked into whether RFC 2630 actually fits the AAA work yet 🤔. the document claims "F", but given the specifics of the protocol [2], the evaluator gives it a "P" ✨
1.1.6 Data Object Integrity 🧩
the document [1] says end-to-end integrity is not available in RADIUS, but adds that it could be added later 🌸. the protocol [2] makes an attempt at it in section 4.3.2.1 of [2], again with a CMS-data attribute that's largely borrowed from RFC 2630. the evaluator hasn't checked whether RFC 2630 applies to the AAA work yet. the document claims "F", but with the specifics of the protocol [2] in mind, the evaluator awards "P" 💖
1.1.7 Certificate Transport 📜
the document [1] says certificate transport is not available in RADIUS, but it could be added 🙈. the protocol [2] tries to describe how in section 4.3.2.3 of [2], using a CMS-data attribute based in large part on RFC 2630. the evaluator hasn't investigated RFC 2630's fit for the AAA work. there's also other stuff about certificate support in RADIUS in an expired work in progress called "RADIUS X.509 Certificate Extensions" [5], which is giving old-school vibes 🕰️. the document claims "F", but given the specifics of the protocol [2], the evaluator awards "P" 🎀
1.1.8 Reliable AAA Transport 🚚
the document [1] says RADIUS partially meets the requirements of the original AAA requirements document. but in [3], the requirement got simplified to "resilience against packet loss" 🫶. the evaluator finds that the protocol [2] handles this on a hop-by-hop basis, but it doesn't really handle it in a proxy-chain environment 😬. the document claims "P", and the evaluator awards "F".
1.1.9 Run over IPv4 🌐
RADIUS is widely deployed over IPv4, no notes 💅. the document claims "T", and the evaluator concurs ✨
1.1.10 Run over IPv6 🌍
the document [1] says adopting a limited number of new RADIUS attributes to support IPv6 is straightforward. that conversation happened on the RADIUS WG mailing list, though the WG is in the process of shutting down 😭. the document claims "P", and the evaluator concurs.
1.1.11 Support Proxy and Routing Brokers 🔀
the document [1] notes that RADIUS is widely deployed in proxy-chains of RADIUS servers. that's equivalent to the Proxy Broker case, but the Routing Broker case is a different requirement 🧐. the protocol [2] doesn't describe how a Routing Broker might be accommodated, although it opens the door a little by saying RADIUS++ is peer-to-peer rather than client/server 🚪. the document claims "P", and the evaluator awards "F".
1.1.12 Auditability 🕵️
the document [1] indicates no compliance with this requirement 💀. the document claims "F", and the evaluator concurs.
1.1.13 Shared Secret Not Required 🤫
the document [1] says RADIUS may effectively skirt the requirement of application-layer security by using a value of "zero" for the pre-shared secret. it's a bit creative, ngl 😂, but it does seem to meet the requirement. the document claims "T" and the evaluator concurs.
1.1.14 Ability to Carry Service Specific Attributes 🎁
RADIUS has a well-defined Vendor-Specific Attribute, which, when properly used, does provide the ability to transport service-specific attributes 💖. the document claims "T", and the evaluator concurs.
1.2 Authentication Requirements 🔑
1.2.1 NAI Support 🪪
the document [1] says 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.2 CHAP Support 🧁
CHAP support is widely deployed in RADIUS. the document claims [1] "T", and the evaluator concurs.
1.2.3 EAP Support 🧷
the document [1] says EAP support in RADIUS is specified in [4]. the document claims [1] "T", and the evaluator concurs 🫶
1.2.4 PAP/Clear-text Passwords 🙊
the document [1] says RADIUS protects clear-text passwords on a hop-by-hop basis. the protocol [2] shows how additional data confidentiality may be obtained in section 4.3.2.2 of [2], using a CMS-data attribute based in large part on RFC 2630. the evaluator hasn't investigated RFC 2630's applicability to the AAA work yet 🤓. the document claims [1] "F", but given the specifics of the protocol [2], the evaluator awards "P".
1.2.5 Reauthentication on demand 🔁
the document [1] says RADIUS may accomplish re-authentication on demand by sending an Access-Challenge message from a server to a client. the evaluator doesn't think that's likely to work for a given session once the client has received an Access-Accept message 🙅♀️. the document claims "T", and the evaluator awards "F".
1.2.6 Authorization w/o Authentication 🚪
this requirement, as applied to the protocol specification, says non-necessary authentication credentials must not be required in a request for authorization. the actual decision to provide authorization with no authentication at all lives in the application (e.g. AAA server) 🧠. RADIUS does require some form of credential in request messages, though 😬. the document [1] claims "F", and the evaluator concurs.
1.3 Authorization Requirements 🛡️
1.3.1 Static and Dynamic IP Addr Assignment 🏠
the document [1] says RADIUS can assign IPv4 addresses, and can easily be extended to assign IPv6 addresses (see section 1.1.10). the bigger concern is static vs. dynamic addresses 👀. if dynamic address has the same meaning it does for DHCP, then there are resource management issues that RADIUS has traditionally not addressed. the document claims "P", and the evaluator concurs.
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.3 Reject Capability 🚫
the document [1] maintains that RADIUS Proxy Servers, and potentially RADIUS++ Routing Brokers, can reject requests based on local policy. the document claims "T" and the evaluator concurs 💅
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.5 Reauth on Demand 🔄
the document [1] says RADIUS provides this feature by means of the Session-Timeout and Termination-Action attributes. that may be enough for periodic re-authorization, but it would not provide re-authorization on demand 😤. the protocol [2] doesn't address this further. the document claims "P", and the evaluator awards "F".
1.3.6 Support for ACLs 📋
the document [1] describes the attributes in RADIUS used to convey the access controls described in [3]. some of these (e.g. QoS) aren't currently defined in RADIUS, but they could easily be defined as new RADIUS attributes 🎀. the document claims "P", and the evaluator concurs.
1.3.7 State Reconciliation 🔍
the document [1] addresses each of the sub-items listed in the original AAA requirements document. but when you review the document against the modified requirements of [3], there's still an issue with server-initiated state reconciliation messages 😭. the protocol [2] makes provision for such messages, since servers are allowed to initiate protocol dialogs, but no detailed message formats are provided. this has traditionally been a short coming of RADIUS 💔. the document claims "P", and the evaluator awards "F".
1.3.8 Unsolicited Disconnect 📴
a lot of the discussion from the previous section applies here too 🫠. the document [1] claims "F", and the evaluator concurs.
1.4 Accounting Requirements 🧾
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.2 Mandatory Compact Encoding 🗜️
RADIUS Accounting contains TLVs for relevant accounting information, and each one is fairly compact. the term "bloated" in [3] is kind of subjective though 🙄. the document [1] claims "T", and the evaluator concurs.
1.4.3 Accounting Record Extensibility 🧩
RADIUS Accounting can be extended with new attributes or by using the Vendor-Specific attribute. some people have argued the existing attribute number space is too small for the expansion required, but the protocol [2] addresses this in section 3.0, and its subsections, of [2] 🌈. the document [1] claims "T", and the evaluator concurs.
1.4.4 Batch Accounting 📦
RADIUS has no explicit provisions for batch accounting, and the protocol [2] doesn't address how this could be done either 🥲. the document [1] claims "F", and the evaluator concurs.
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.6 Accounting Timestamps ⏰
the document [1] says this feature is specified in [4] as the Event-Timestamp attribute. the document claims [1] "T", and the evaluator concurs ✨
1.4.7 Dynamic Accounting 📈
the document [1] says this requirement is partially met using the accounting interim update message specified in [4]. there was also work in the RADIUS WG on session accounting extensions that isn't in [4], meaning some expired works in progress 🕰️. the document claims [1] "P", and the evaluator concurs.
1.5 MOBILE IP Requirements 📡
1.5.1 Encoding of MOBILE IP Registration Messages 📝
the document [1] claims "F", and the evaluator concurs.
1.5.2 Firewall Friendly 🧱
the document [1] says RADIUS deployment is known to have happened in firewalled environments 🔥. the document claims "T", and the evaluator concurs.
1.5.3 Allocation of Local Home Agent 🏡
the document [1] claims "F", and the evaluator concurs.
2. Summary Discussion 📝
okay so the document [1] and the protocol [2] both suffer from having been written in a short time frame ⏳. the protocol does give specific guidance on certain issues and cites other relevant documents, but it's not a polished protocol specification, and it doesn't have detailed packet format diagrams 😅. there is a pool of prior work the RADIUS++ protocol can draw from, since 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 those works in progress have long since expired, though 🥀.
3. General Requirements ✨
The RADIUS++ question is basically the main character plot 💅. RADIUS is already the current de facto AND de jure standard for AAA 👑, so it meets a lot of the requirements. It also has long-standing deficiencies 🙈, and the RADIUS and NASREQ WG proceedings have documented them super well. Revamping RADIUS to fix them is technically possible ✨. The question everyone will ask, though, is: "What significant differences would there be between a finished RADIUS++ protocol and the Diameter protocol?" 🤔 iykyk.
4. Summary Recommendation
Recommended in part 🎀. The big takeaway from this submission? It's feasible to have a more RADIUS-compliant RADIUS-compatibility mode in Diameter 🦋.
C.5 Diameter PRO Evaluation
Okay bestie, here's the Diameter PRO evaluation 🧚
Evaluation of Diameter against the AAA Requirements PRO Evaluation Evaluator - Basavaraj Patil
Here are the refs we're working with 📚:
- 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".
The doc uses T for total compliance, P for partial compliance, and F for no compliance 🌈.
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 General Requirements
1.1.1 Scalability
Diameter is an evolution of RADIUS and it took all the lessons learned over many years of RADIUS being in service 🙌. Using SCTP as the transport protocol reduces the need for multiple proxy servers (Sec 3.1.1 Proxy Support of [1]) and also removes the need for application level acks ✨. Forwarding and redirect brokers are used and supported, which enhances scalability 💖. The evaluator agrees with the T compliance on this one.
1.1.2 Fail-over
SCTP strikes again 💅. Diameter can detect disconnect indications, and when it does, it switches to an alternate server (Sec 4.0 [6]). Also, Requests and Responses don't have to follow the same path, which boosts reliability 🫶. The evaluator agrees with the T compliance here too.
1.1.3 Mutual Authentication
The compliance document says symmetric transforms are used for mutual authentication between the client and server (Sec 7.1 of [6]) 🔐. It also points to IPSec as the underlying security mechanism, and says IPSec's own characteristics satisfy this requirement. The evaluator agrees with the T compliance.
1.1.4 Transmission Level Security
Okay so this requirement has been deprecated by the AAA evaluation team 🙃, but the document still complies with it based on the definition, which refers to hop-by-hop security. Section 7.1 of [6] has the details of how Diameter does this. The evaluator agrees with the T compliance.
1.1.5 Data Object Confidentiality
This requirement seems to have come from Diameter, lowkey 👀. Ref [7] explains in detail how Cryptographic Message Syntax (CMS) is used for data object confidentiality. A CMS-Data AVP is defined in [7]. The evaluator agrees with the T compliance.
1.1.6 Data Object Integrity
Same argument as above, plus the hop-by-hop security feature in the protocol 🔒. This requirement is completely met by Diameter. The evaluator agrees with the T compliance.
1.1.7 Certificate Transport
Again, the CMS-Data AVP comes through 🎀. Objects defined as these types of attributes allow the transport of certificates. The evaluator agrees with the T compliance.
1.1.8 Reliable AAA Transport
Diameter recommends running the protocol over SCTP 🦋, and SCTP provides the features described for a reliable AAA transport. The fit isn't perfect for the definition of this tag item, ngl, but it's close enough, and the functionality SCTP gives is the same ✨. The evaluator agrees with the T compliance.
1.1.9 Run over IPv4
It's an application layer protocol, so it doesn't depend on the underlying version of IP 🌸. The evaluator agrees with the T compliance.
1.1.10 Run over IPv6
Same deal: application layer protocol, not dependent on the underlying IP version 🌸. The evaluator agrees with the T compliance.
1.1.11 Support Proxy and Routing Brokers
Section 3.1.1/2 of the framework document [1] explains how Diameter supports proxy and routing brokers 🧚. Honestly it almost looks like the requirement for a routing broker came from Diameter 👑. The evaluator agrees with the T compliance.
1.1.12 Auditability
With the CMS-Data AVP [7], a trail gets created when proxies are involved in the transaction 📜. That trail can provide auditability. The evaluator agrees with the T compliance.
1.1.13 Shared Secret Not Required
With IPSec as the underlying security mechanism, Diameter doesn't require shared secrets for message authentication 🔑. The evaluator agrees with the T compliance.
1.1.14 Ability to Carry Service Specific Attributes
The base protocol [6] is defined by Diameter, and any one else can define specific extensions on top of it 🛠️. Other WGs in the IETF can design an extension on the base protocol with specific attributes and have them registered by IANA. The evaluator agrees with the T compliance.
1.2 Authentication Requirements
1.2.1 NAI Support
The base protocol [6] defines an AVP that supports NAIs 🪪. Diameter goes one step further by doing message forwarding based on destination NAI AVPs ✨. The evaluator agrees with the T compliance.
1.2.2 CHAP Support
Reference [2] section 3.0 describes the support for CHAP. The evaluator agrees with the T compliance.
1.2.3 EAP Support
Reference [2] section 4.0 describes the support for EAP. The evaluator agrees with the T compliance.
1.2.4 PAP/Clear-text Passwords
Reference [2] section 3.1.1.1 describes the support for PAP. The evaluator agrees with the T compliance.
1.2.5 Reauthentication on demand
The compliance document claims this is done through the Session-Timeout AVP as the reauthentication mechanism 🤨. However, no direct references explaining this were found in the base protocol [6] document.
The evaluator downgrades the compliance on this to a P.
Note: However this is a trivial issue 🙈.
1.2.6 Authorization w/o Authentication
Diameter allows requests to be sent without any authentication information included 🙌. A Request-type AVP is defined in [2], and it can specify authorization only without containing any authentication. The evaluator agrees with the T compliance.
1.3 Authorization Requirements
1.3.1 Static and Dynamic IP Addr Assignment
The base protocol includes an AVP for carrying the address 📍. References [6.2.2 of 2] and [4.5 of 5] provide detailed explanations of how this can be done. The evaluator agrees with the T compliance.
1.3.2 RADIUS Gateway Capability
One of the basic facets of Diameter is supporting backward compatibility and acting as a RADIUS gateway in certain environments 🔄. The evaluator agrees with the T compliance.
1.3.3 Reject Capability
Based on the explanation in the compliance document for this requirement, the evaluator agrees with the T compliance 💅.
1.3.4 Preclude Layer 2 Tunneling
Ref [2] defines AVPs supporting L2 tunnels 🚇. The evaluator agrees with the T compliance.
1.3.5 Reauth on Demand
A session timer defined in [6] is used for reauthorization ⏱️. Diameter allows reauthorization at any time, though. Since this is a peer-to-peer type of protocol, any entity can initiate a reauthorization request 🫶. The evaluator agrees with the T compliance.
1.3.6 Support for ACLs
Diameter defines two methods 🧩. One supports backward compatibility for RADIUS, and the other uses a standard AVP with the filters encoded in it. The evaluator agrees with the T compliance.
1.3.7 State Reconciliation
There's a long explanation for each of the points defined for this tag item in the requirements document 📝. The evaluator agrees with the T compliance for this requirement.
1.3.8 Unsolicited Disconnect
The base protocol [6] defines a set of session termination messages that can be used for unsolicited disconnects 👋. The evaluator agrees with the T compliance.
1.4 Accounting Requirements
1.4.1 Real Time Accounting
The evaluator agrees with the T compliance based on the explanations in [4] ⏰.
1.4.2 Mandatory Compact Encoding
Compact encoding of accounting data uses the Accounting Data Interchange Format (ADIF)-Record-AVP 📦. The evaluator agrees with the T compliance.
1.4.3 Accounting Record Extensibility
ADIF can be extended 🌱. The evaluator agrees with the T compliance.
1.4.4 Batch Accounting
Sec 1.2 of [4] provides support for batch accounting 🧺.
1.4.5 Guaranteed Delivery
Sections 2.1/2 of [4] describe the messages used to guarantee delivery of accounting records 💌. The evaluator agrees with the T compliance.
1.4.6 Accounting Timestamps
The Timestamp AVP [6] is present in all accounting messages ⏳. The evaluator agrees with the T compliance.
1.4.7 Dynamic Accounting
Interim accounting records, equivalent to a call-in-progress, can be sent periodically 📈. The evaluator agrees with the T compliance.
1.5 MOBILE IP Requirements
1.5.1 Encoding of MOBILE IP Registration Messages
Ref [5] provides details of how Diameter can encode MIP messages 📡. The evaluator agrees with the T compliance.
1.5.2 Firewall Friendly
Some handwaving here 😭, plus a possible way of solving the firewall problem with a Diameter proxy server. The document claims T, but the evaluator downgrades it to a P.
1.5.3 Allocation of Local Home Agent
Diameter can assign a local home agent in a visited network in conjunction with the FA in that network 🏠. The evaluator agrees with the T.
Summary Recommendation
Diameter is strongly recommended as the AAA protocol 🏆. The experience gained from RADIUS deployments was put to good use in the design of this protocol 💜. It was also designed with extensibility in mind, which lets different WGs develop their own specific extensions to satisfy their requirements 🌈. With SCTP as the transport protocol, reliability is built in ✨. Security was addressed in the design of the protocol, and issues discovered in RADIUS were fixed 🔐. Diameter is also a session based protocol, which makes it more scalable 📶. The support for forwarding and redirect brokers is well defined, and it greatly improves the scalability of the protocol 🚀.
Lastly, the protocol has been implemented by at least a few people, and interop testing has been done 🥹. That in itself is a significant step and a positive point for Diameter to be the AAA protocol 👑.
C.6 Diameter CON Evaluation 💜
Evaluation of Diameter against the AAA Requirements CON Brief Evaluator: Barney Wolff
Section 1 - Per item discussion ✨
1.1 General Requirements
1.1.1 Scalability - P (was T) 🌸 The evaluator is worried about scalability to the small, not to the large. Diameter/SCTP may prove difficult to retrofit to existing NAS equipment. 🙈
1.1.2 Fail-over - P (was T) 😭 SCTP gives an indication of peer failure, but nothing in any Diameter or SCTP document the evaluator was able to find even mentions how or when to switch back to a primary server to which communication was lost. After a failure, the state machines end in a CLOSED state and nothing seems to trigger exit from that state. It was not clear whether a server, on rebooting, would initiate an SCTP connection to all its configured clients. If not, and in any case when the communication failure was in the network rather than in the server, the client must itself, after some interval, attempt to re-establish communication. But no such guidance is given. 💀
Of course, the requirement itself fails to mention the notion of returning to a recovered primary. That is a defect in the requirement. The evaluator has had unfortunate experience with a vendor's RADIUS implementation that had exactly the defect that it often failed to notice recovery of the primary. 😤
1.1.3 Mutual Authentication - T ✅
1.1.4 Transmission Level Security - T ✅
1.1.5 Data Object Confidentiality - P (was T) 🔐 Yes, the CMS data type is supported. But the work in progress, "Diameter Strong Security Extension", says:
Given that asymmetric transform operations are expensive, Diameter
servers MAY wish to use them only when dealing with inter-domain
servers, as shown in Figure 3. This configuration is normally
desirable since Diameter entities within a given administrative
domain MAY inherently trust each other. Further, it is desirable
to move this functionality to the edges, since NASes do not
necessarily have the CPU power to perform expensive cryptographic
operations.Given all the fuss that has been made about "end-to-end" confidentiality (which really means "NAS-to-home_server"), the evaluator finds it absurd that the proposed solution is acknowledged to be unsuited to the NAS. 🙃
1.1.6 Data Object Integrity - P (was T) 🫶 See above.
1.1.7 Certificate Transport - T ✅
1.1.8 Reliable AAA Transport - T ✅
1.1.9 Run over IPv4 - T ✅
1.1.10 Run over IPv6 - T ✅
1.1.11 Support Proxy and Routing Brokers - T ✅
1.1.12 Auditability - T 🧐 (based on our interpretation as non-repudiation, rather than the definition given in reqts)
1.1.13 Shared Secret Not Required - T ✅
1.1.14 Ability to Carry Service Specific Attributes - T ✅
1.2 Authentication Requirements
1.2.1 NAI Support - T ✅
1.2.2 CHAP Support - T ✅
1.2.3 EAP Support - T ✅
1.2.4 PAP/Clear-text Passwords - T ✅
1.2.5 Reauthentication on demand - P (was T) 🚩 No mechanism was evident for the server to demand a reauthentication, based for example on detection of suspicious behavior by the user. Session-timeout is not sufficient, as it must be specified at the start.
1.2.6 Authorization w/o Authentication - T ✅
1.3 Authorization Requirements
1.3.1 Static and Dynamic IP Addr Assignment - T ✅
1.3.2 RADIUS Gateway Capability - P (was T) 🤔 RADIUS has evolved from the version on which Diameter was based. EAP is a notable case where the convention that the Diameter attribute number duplicates the RADIUS one is violated. No protocol, not even RADIUS++, can claim a T on this.
1.3.3 Reject Capability - T (The evaluator fails to understand how any AAA protocol could rate anything other than T on this.) 💅
1.3.4 Preclude Layer 2 Tunneling - T ✅
1.3.5 Reauth on Demand - P (was T) 🙄 As with reauthentication, there is no evident mechanism for the server to initiate this based on conditions subsequent to the start of the session.
1.3.6 Support for ACLs - P (was T) 💀 The evaluator finds the Filter-Rule AVP laughably inadequate to describe filters. For example, how would it deal with restricting SMTP to a given server, unless all IP options are forbidden so the IP header length is known? No real NAS could have such an impoverished filter capability, or it would not survive as a product. 📦
1.3.7 State Reconciliation - P (was T) 🌀 It is difficult for the evaluator to understand how this is to work in a multi-administration situation, or indeed in any proxy situation. Furthermore, SRQ with no session-id is defined to ask for info on all sessions, not just those "owned" by the requester. 👀
1.3.8 Unsolicited Disconnect - T ✅
1.4 Accounting Requirements
1.4.1 Real Time Accounting - T ✅
1.4.2 Mandatory Compact Encoding - T ✅
1.4.3 Accounting Record Extensibility - T ✅
1.4.4 Batch Accounting - P (was T) 🍓 The evaluator suspects that simply sending multiple accounting records in a single request is not how batch accounting should or will be done.
1.4.5 Guaranteed Delivery - T ✅
1.4.6 Accounting Timestamps - T 😂 (The evaluator notes with amusement that NTP time cycles in 2036, not 2038 as claimed in the Diameter drafts. It's Unix time that will set the sign bit in 2038.)
1.4.7 Dynamic Accounting - T ✅
1.5 MOBILE IP Requirements
1.5.1 Encoding of MOBILE IP Registration Messages - T ✅
1.5.2 Firewall Friendly - F (was T) 🧱 Until such time as firewalls are extended to know about or proxy SCTP, it is very unlikely that SCTP will be passed. Even then, the convenient feature of being able to send a request from any port, and get the reply back to that port, means that a simple port filter will not be sufficient, and statefulness will be required. Real friendship would require that both source and dest ports be 1812. 🥲
1.5.3 Allocation of Local Home Agent - T ✅
2. Summary Discussion 🌈
In some areas, Diameter is not completely thought through. In general, real effort has gone into satisfying a stupendous range of requirements. 🫶
3. General Requirements 💖
Diameter certainly fails the KISS test. 🙃 With SCTP, the drafts add up to 382 pages - well over double the size of RADIUS even with extensions. The evaluator sympathizes with the political instinct when faced with a new requirement no matter how bizarre, to say "we can do that" and add another piece of filigree. But the major places where Diameter claims advantage over RADIUS, namely "end-to-end" confidentiality and resource management, are just the places where some hard work remains, if the problems are not indeed intractable. 🛠️
More specifically, the evaluator sees no indication that specifying the separate transport protocol provided any advantage to defray the large increase in complexity. Application acks are still required, and no benefit from the transport acks was evident to the evaluator. Nor was there any obvious discussion of why "sequenced in-order" delivery is required, when AAA requests are typically independent. SCTP offers out-of-order delivery, but Diameter seems to have chosen not to use that feature. 🤷♀️
Whether TLV encoding or ASN.1/BER is superior is a religious question, but Diameter manages to require both, if the "strong" extension is implemented. The evaluator has a pet peeve with length fields that include the header, making small length values invalid, but that is a minor point. 🙈
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. 📚✨
4. Summary Recommendation 👑
Diameter is clearly close enough to meeting the myriad requirements that it is an acceptable candidate, though needing some polishing. Whether the vast increase in complexity is worth the increase in functionality over RADIUS is debatable. 🎀
C.7 COPS PRO Evaluation ✨
Okay bestie, this one is the PRO brief for COPS, and David Nelson is giving the protocol the benefit of the doubt 🥹💖 Here's the lineup of what he's looking at:
Evaluation of COPS AAA Requirements PRO Evaluation Evaluator - David Nelson
Ref [1] is "Comparison of COPS Against the AAA NA Requirements", work in progress, a.k.a. 'the document' 📄 Ref [2] is RFC 2748 a.k.a. 'the protocol' 🦋 Ref [3] is the AAA evaluation criteria as modified by us. 💅 Ref [4] is "AAA Protocols: Comparison between RADIUS, Diameter, and COPS" work in progress. 🌸 Ref [5] is "COPS Usage for AAA", work in progress. 🧚
The grading key here is T for total compliance, P for partial, and F for no compliance. Simple, iconic. 👑
Section 1 - Per item discussion
1.1 General Requirements
1.1.1 Scalability - The document [1] claims "T", and the evaluator concurs. ✨
1.1.2 Fail-over - The document [1] claims "T", and the evaluator concurs. ✨
1.1.3 Mutual Authentication - The document claims "T", and the evaluator concurs. 🫶
1.1.4 Transmission Level Security - The document [1] indicates that transmission layer security, as defined in [3], is provided in the protocol, using the mechanisms described in [2]. It should be noted that this requirement is now a SHOULD in [3]. The document claims "T", and the evaluator concurs. 🔒
1.1.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.6 Data Object Integrity - The document [1] indicates that data object integrity is provided using a CMS-data attribute, based in large part upon RFC 2630. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. The document claims "T", and the evaluator concurs. 💜
1.1.7 Certificate Transport - The document [1] indicates that certificate transport is provided using a CMS-data attribute, based in large part upon RFC 2630 and RFC 1510. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. The document claims "T", and the evaluator concurs. 🎀
1.1.8 Reliable AAA Transport - The document [1] indicates that COPS uses TCP, which certainly meets the requirements for a reliable transport. The document claims "T", and the evaluator concurs. 🌈
1.1.9 Run over IPv4 - The document [1] claims "T", and the evaluator concurs. 💖
1.1.10 Run over IPv6 - The document [1] claims "T", and the evaluator concurs. 💖
1.1.11 Support Proxy and Routing Brokers - Reasonable detail of proxy operations is provided in [5]. The document [1] claims "T", and the evaluator concurs. 🧚
1.1.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". 🙈 Not me saying "alludes" like it's a vibe and not a plan.
1.1.13 Shared Secret Not Required - The document [1] claims "T" and the evaluator concurs. 🔥
1.1.14 Ability to Carry Service Specific Attributes - The document [1] claims "T", and the evaluator concurs. ⭐
1.2 Authentication Requirements
1.2.1 NAI Support - The document [1] indicates that NAI is to be supported in the Information Model, but notes that for cases where certificates are in use, the more restrictive syntax of RFC 2459 applies. The document claims "T", and the evaluator awards "P". 🦋
1.2.2 CHAP Support - The document [1] claims "T", and the evaluator concurs. 🌸
1.2.3 EAP Support - The document [1] claims "T", and the evaluator concurs. 🌸
1.2.4 PAP/Clear-text Passwords - The document [1] indicates compliance, presumably using a CMS-data attribute, based in large part upon RFC 2630. The evaluator has not, at this time, investigated the applicability of RFC 2630 to the AAA work. The document claims "T", and the evaluator concurs. 💅
1.2.5 Reauthentication on demand - The document [1] claims "T", and the evaluator concurs. 👑
1.2.6 Authorization w/o Authentication - This requirement, as applied to the protocol specification, mandates that non-necessary authentication credentials not be required in a request for authorization. The actual decision to provide authorization in the absence of any authentication resides in the application (e.g. AAA server). The document [1] claims "T", and the evaluator concurs. 🧠
1.3 Authorization Requirements
1.3.1 Static and Dynamic IP Addr Assignment - The document [1] claims "T", and the evaluator concurs. 🌷
1.3.2 RADIUS Gateway Capability - The document [1] claims "T", and in the absence of any detailed discussion of how this is accomplished, in either [1] or [5], the evaluator awards "P". 🥲
1.3.3 Reject Capability - The document claims [1] "T" and the evaluator concurs. 🚫
1.3.4 Preclude Layer 2 Tunneling - The document [1] claims "T", and in the absence of any detailed discussion of how this is accomplished, in either [1] or [5], the evaluator awards "P". 🥲
1.3.5 Reauth on Demand - The document [1] claims "T", and the evaluator concurs. 👑
1.3.6 Support for ACLs - The document [1] "T", and the evaluator concurs. 🍓
1.3.7 State Reconciliation - The document [1] "T", and the evaluator concurs. 🍓
1.3.8 Unsolicited Disconnect - The document [1] claims "T", and the evaluator concurs. 💜
1.4 Accounting Requirements
1.4.1 Real Time Accounting - The document [1] claims "T", and the evaluator concurs. ⏰
1.4.2 Mandatory Compact Encoding - Note that the term "bloated" in [3] is somewhat subjective. The document [1] claims "T", and the evaluator concurs. 😭
1.4.3 Accounting Record Extensibility - The document [1] claims "T", and the evaluator concurs. 🌈
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.5 Guaranteed Delivery - Guaranteed delivery is provided by TCP. The document [1] claims "T", and the evaluator concurs. 🫶
1.4.6 Accounting Timestamps - The document [1] claims "T", and the evaluator concurs. 🕰️
1.4.7 Dynamic Accounting - The document [1] claims "T", and the evaluator concurs. ✨
1.5 MOBILE IP Requirements
1.5.1 Encoding of MOBILE IP Registration Messages - The document [1] claims "T", and the evaluator concurs. 📦
1.5.2 Firewall Friendly - The document [1] claims "T", and the evaluator concurs. 🧱
1.5.3 Allocation of Local Home Agent - The document [1] claims "T", and the evaluator concurs. 🏠
2. Summary Discussion 🦋
It may appear, upon initial inspection, that the evaluator has not lent a critical eye to the compliance assertions of the document [1]. First, this memo is a "PRO" brief, and as such reasonable benefit of doubt is to be given in favor of the protocol submission. Second, there is a fundamental conceptual issue at play. The COPS-PR model provides a sufficient set of basic operations and commands, a stateful model, the ability for either "peer" to initiate certain kinds of requests, as well as an extensible command set, to be able to support a wide variety of network and resource management protocols. The details of protocol specific messages is left to Policy Information Base (PIB) data objects. Since no AAA PIB has been written, the evaluator 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.
In some sense, this is 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. 💀
3. General Requirements 📋
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.
4. Summary Recommendation 🌟
Recommended with reservation. Before final acceptance of COPS-AAA, someone is going to have to write the AAA PIB and evaluate its details. 🫠
C.8 COPS CON Evaluation 🌶️
Okay, switching sides now, and David Mitton is NOT being nice about it 😤 Same protocol, totally different energy.
Evaluation of COPS against the AAA Requirements CON Evaluation Evaluator - David Mitton
The Primary document discussed here is [COPSComp] and the arguments therein based on the proposal [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.
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.
- [COPSFwork] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
- [COPSPR] "COPS Usage for Policy Provisioning", Work in Progress.
- [COPSSPPI] "Structure of Policy Provisioning Information (SPPI)", Work in Progress.
- [COPSCMS] "COPS Over CMS", Work in Progress.
- [COPSTLS] "COPS Over TLS", Work in Progress.
- [COPSGSS] "COPS Extension for GSS-API based Authentication Support", Work in Progress.
Other COPS & RSVP RFCs & drafts not listed as not directly relevant. 📚
Compliance: T==Total, P==Partial, F=Failed 🎯
Section 1 - Per item discussion
Initial Note: [COPSComp] claims "unconditional compliance" with all requirements. 🚩 Bold claim, no cap.
1.1 General Requirements
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.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. 😬
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. ⏳
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.4 Transmission Level Security - 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.6 Data Object Integrity - T See above. 🙄
1.1.7 Certificate Transport - T 🎀
1.1.8 Reliable AAA Transport - T (maybe P) 🦋 COPS meets this requirement as well as any other protocol we've evaluated, bestie. Like, it does have one application level ACK ✨. Statements like "TCP provides guaranteed delivery" are incorrect, no cap 💀. COPS does try to spot outages with a keep-alive message between TCP peers 🫶.
1.1.9 Run over IPv4 - T 🌸
1.1.10 Run over IPv6 - T 🌸
1.1.11 Support Proxy and Routing Brokers - P (was T) 🤔
How client types are supported going forward is not well understood by this evaluator, so it's giving confusion 😭. Does each client type make the Broker send a different client Open request to its upstream servers? What about routing brokers?
1.1.12 Auditability - P (was T) 📝
This is based on our interpretation as non-repudiation, rather than the definition given in reqts. The explanation of a History PIB is incomplete, so the result is inconclusive 🙈.
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.14 Ability to Carry Service Specific Attributes - P (was T) 🧩
- a) COPS only allows a small number of unique objects to be added. There are 256 Object "classes" or types, with 256 subtypes or versions. Client types are 16 bits long, and the high bit indicates "enterprise" specific values. These pertain to a COPS peer-connection session. The client type seems to just identify the information model for the message, eg. it will be fixed to one value for AAA. 💅
- b) Service specific objects are not the same as Vendor Specific Objects. They pertain to objects within a client type. ✨
- c) The PIB model leads to a different model interoperability. Because most vendor products differ in some way, each PIB will be different, and sharing common provisioning profiles will be a rather difficult mapping problem on the server. 😩
- d) It's not clear whether the different client types can be mixed, or whether other object 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. 🌀
1.2 Authentication Requirements 🔑
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.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 it doesn't deliver much meat. Still, this could be handled ala RADIUS 🙃.
1.2.3 EAP Support - P (was T) 🫠
Again with the non-existent Information Model. To do EAP, this evaluator thinks another Request or Decision type is needed to tell proxies that an extended message exchange is in progress.
1.2.4 PAP/Clear-text Passwords - T 🍓
1.2.5 Reauthentication on demand - T 🍓
1.2.6 Authorization w/o Authentication - 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 Static and Dynamic IP Addr Assignment - T 🌈
1.3.2 RADIUS Gateway Capability - P (was T). 🌉
It would be interesting to see RADIUS attributes wrapped in some COPS "Information Model" 👀.
1.3.3 Reject Capability - T 🚫
1.3.4 Preclude Layer 2 Tunneling - T 🔒
More work for the "Information Model" author! 😭
1.3.5 Reauthorization on Demand - T 🔁
1.3.6 Support for Access Rules & Filters - P (was T) 🧱
Yet more work for the "Information Model" author, including some design issues that alluded the RADIUS and Diameter designers. At least an attempt was made in Diameter. There is nothing here 💀.
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.8 Unsolicited Disconnect - T 👋
1.4 Accounting Requirements 🧾
1.4.1 Real Time Accounting - T ⏱️
1.4.2 Mandatory Compact Encoding - T 📦
This evaluator does not believe that ADIF is a compact format. But it does believe the Information Model author can design a PIB with accounting statistics that will satisfy this requirement 🤓.
1.4.3 Accounting Record Extensibility - P (was T) 🧩
By defining a vendor/device specific PIB for additional elements.
1.4.4 Batch Accounting - P (was T) 📚
The offered description does not seem to match the requirement 🙃.
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.6 Accounting Timestamps - T ⏰
Another item for the "Information Model" author 😩.
1.4.7 Dynamic Accounting - T 📈
Event and interim accounting can be supported ✨.
1.5 MOBILE IP Requirements 📡
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.2 Firewall Friendly - P (was T) 🔥
I guess 🤷♀️. It uses TCP and can be identified by a 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.3 Allocation of Local Home Agent - P (was T) 🏠
Just add another element to that "Information Model" definition 💅.
2. Summary Discussion 💭
COPS was designed to do some things similar to what we want, and to be somewhat flexible. But it has a totally different set of assumptions about how many clients and requests would be funneled through the infrastructure, and about 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 🌪️.
3. General Requirements 📚
COPS started out with a small and easily met set of design goals for RSVP and DiffServe, and it is evolving into a new hammer to hit other nails [COPSPR] 🔨. As COPS implementors get more operational experience, it is interesting to see more reliability fixes and features quickly get patched in ✨.
Understanding COPS requires that you read a number of RFCs and drafts that do not readily integrate well together. Each application of COPS has spawned a number of drafts 📑. It's not clear whether one wants to, or can, implement a single COPS server that can service AAA and other application clients 🤔.
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 it really doesn't scale well in larger configurations. End-to-end application acks are the only guaranteed delivery solution, particularly where distributed state is involved 💯.
COPS falls into an in-between place on encoding 🧃. It has a 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 by 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. Vendor extensions 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 😬.
Support for PIB definition and vendor extensions will be on the same order as MIB integration in SNMP management products, and it puts the supposed complexity of Diameter to shame 💀.
4. Summary Recommendation 🏁
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 😤.
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. It will introduce more complexity than needed, and opportunities to have progress pulled into other rat-holes (eg. Policy Frameworks) 🐀.
Appendix D - Meeting Notes 🗒️
The minutes of the team meetings as recorded by various members 📝✨.
D.1 Minutes of 22-Jun-2000 Teleconference ✨
Recorded by: Mark Stevens 🎀
okay so the arguments for and against SNMP as an AAA protocol got laid out here 💅. Stuart Barkley gave the pro summary and Mike St. Johns gave the con summary. Dave Nelson asked for "instructions to the jury" so everyone could figure out what evidence could and could not be used in making decisions 🧚.
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 🙈.
Mike St. Johns offered that we must restrict ourselves to considering only the evidence provided in the compliance documents and any supporting documents to which they may refer.
In summary: AAA evaluation criteria document, AAA evaluation criteria source documents, protocol response documents and reference documents 📚.
The question of 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 then went to Stuart Barkley for the pro SNMP argument 🌸.
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 is everything supported, although there is no specific consideration for compact encoding. SNMP is not as bloated as ASCII or XML based encoding schemes. The requirement for compact encoding is weakly indicated in the requirements anyway. Server-specific attributes are needed, but compact encoding precludes them without tradeoffs.
- With regard to the mobile IP requirement, everything works well, although firewall friendliness is a judgment call.
- Proxy mechanisms of SNMPv3 mitigate problems with firewalls.
- Scalability is ok.
- Overall, it meets most requirements and the shortfalls are minor.
- In some cases the requirements seemed to be expressed in a manner that "stacks" the odds against SNMP.
- SNMP is deployed everywhere already. 🌈
- The protocol has well-understood behavior despite the tedium of MIB definition, so it has the advantage of not requiring the creation of a new infrastructure.
- The 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. ⭐
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.
- The 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 were not understood by the authors of the response document.
- SNMP is just a data moving protocol.
- Message formats are not specified.
- What is the method for supporting authentication? Storing the information is handled, but what do the nodes do with it?
- 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.
The group then examined each requirement against SNMP in a line-by-line exercise 🔍.
D.2 Minutes of 27-Jun-2000 Teleconference 🦋
Attendees - All (Mike St. John, Dave Mitton, Dave Nelson, Mark Stevens, Barney Wolff, Stuart Barkley, Steven Crain, Basavaraj Patil)
Minutes recorded by: Basavaraj Patil
Evaluation of RADIUS++ AAA Requirements
Pro: Mark Stevens Con: Dave Nelson
- Question raised on whether 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.
- Mike concluded that we can reinstate these requirements after reviewing Pat's comments in detail and the RFCs referenced. The intent is to review Pat's comments/document between now and next Thursday (July 6th) and integrate the comments based on the findings at that time. 🗓️
Voting Procedure for evaluation: No voting during the discussion. All votes MUST be submitted to Mike by COB, June 28th, 00. 🗳️
- Dave Nelson's summary of the Con statement for RADIUS++. Overview of the points on which the evaluator disagrees with the compliance statement.
Conclusion from Dave: Not recommended (Details in the con statement).
Q: Is it possible to use it for accounting? A: Authentication and Authorization could be separated, but Accounting is the weak link in this protocol and hence is not suitable. 💀
- Mark Steven's summary of the Pro statement. Agreed with most of the observations made by Dave Nelson. The biggest thing going for it is that it has been running in this environment for a while and it does meet most of the requirements in the document. Transition will be easy, and backwards compatibility is a key plus point. 💜
Point-by-point Discussion:
General (1.1):
1.1.1 Scalability
BW - There is no actual limit on the number of outstanding requests. The protocol itself does not limit the number.
DN - Simultaneous requests are not the same as outstanding requests.
Discussion of workarounds that have been implemented to overcome this problem.
1.1.2 Fail-over
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 the round-trip timer in 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 tertiary exist, and the possible effect of flooding messages in the event of a fail-over detection.
1.1.3 Mutual Authentication
No Discussion. Accepted as stated.
1.1.4 Transmission level security
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.
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?
1.1.5 Data Object Confidentiality
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.
There does not seem to be a problem with the suggested usage of CMS in RADIUS++.
1.1.6/7 Data Object Integrity/Certificate Transport
No discussion. (I guess everyone concurs with the statement in the compliance document and the reviewer's comments.)
1.1.8 Reliable AAA Transport
BW - RADIUS provides reliability at the application layer by doing retransmissions. So why is there a need for a reliable AAA transport protocol?
- 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.
Conclusion is that this requirement deals with packet loss.
1.1.9/10 Run over IPv4/6
Running over IPv6 should be a trivial issue. 🌐
1.1.11 Support Proxy and Routing Brokers
- Discussion on what this requirement means, and analogy to DNS servers in a network.
- RADIUS can be extended to support this requirement, and from the compliance document this does not appear to be fully cooked yet.
1.1.12 Auditability
No Discussion
1.1.13 Shared Secret Not Required
This seems to be a trivial issue to be addressed in RADIUS++.
1.1.14 Ability to carry Service Specific Attributes
No Discussion
Authentication Requirements:
1.2.1 NAI Support
Trivial - Total compliance. ✅
1.2.2 CHAP Support
Comment: RADIUS support of CHAP could be better, and the response needs to be encrypted.
1.2.3/4 EAP/PAP
No Discussion
1.2.5 Reauthentication on Demand
DN - The 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.
1.2.6 Authorization w/o Authentication
DN - This is trivial to fix, but this is not mentioned in the compliance document.
Authorization Requirements:
1.3.1 Static and Dynamic IP Addr assignment
- 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.
1.3.2 RADIUS Gateway Capability
This is a requirement written that is not applicable to RADIUS itself.
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
No dissent. No discussion.
1.4.2 Mandatory compact encoding
Comment made regarding ASN.1 and XML in this context.
1.4.3 Accounting Record Extensibility
No discussion
1.4.4 Batch Accounting
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
No Discussion
1.4.7 Dynamic Accounting
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 phone call in progress type of messages. 📱
Mobile IP Requirements:
1.5.1 Encoding of Mobile IP Reg. Messages
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?
1.5.2 Firewall Friendly
No Discussion
1.5.3 Allocation of Local Home Agents
This concept needs to be clarified, as the author writing the compliance statement did not understand it either. 🤔
If you notice anything that I recorded here as something misinterpreted, please feel free to make corrections. 🫶
D.3. Minutes of 29-Jun-2000 Teleconference ✨
okay bestie, this one is the 29-Jun call 🎀
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 💅
Advocates:
- Pro: Basavaraj Patil 💖
- Con: Barney Wolff 🙈
Summary discussion
PRO summary (Basavaraj Patil):
- session based
- lightweight base + extensions
- has implementation experience
- based upon radius
- fixes specific problems with radius
- interoperates with radius
- looks like requirements are written for diameter
CON summary (Barney Wolff):
- 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, but diameter glosses over it by referring to rfc2630, and the cost to run it on a NAS device is a concern 😬
- ACL: the filter style syntax seems inadequate
- state reconciliation: difficult over global multiple administrative domains
- batch accounting: the implementation doesn't meet the intended need
- firewall friendly: until firewalls support SCTP, this will be a failure 🧱
Summary very close 🫶
Concerns:
- size and complexity: almost all extensions are needed to actually support the requirements
- needs separation of SCTP and data (as per IESG suggestion?)
- application vs transport acks
Point-by-point Discussion
General (1.1):
- 1.1.1 Scalability
- Handles large number of requests
- SCTP reduces proxy needs (how? what is the justification for this statement?) 🤔
- Scalability in large
- 1.1.2 Fail-over
- Recovery from SCTP failure needs discussion (Note to DM: include in final document considerations)
- 1.1.3 Mutual Authentication: No Discussion
- 1.1.4 Transmission level security: No Discussion
- 1.1.5/6 Data Object Confidentiality/Data Object Integrity
- Crypto in NAS
- NAS needs knowledge of when to use crypto
- One Time Passwords
- 1.1.7 Certificate Transport: No Discussion
- 1.1.8 Reliable AAA Transport: No Discussion
- 1.1.9/10 Run over IPv4/6: No Discussion
- 1.1.11 Support Proxy and Routing Brokers: No Discussion
- 1.1.12 Auditability: No Discussion
- 1.1.13 Shared Secret Not Required: No Discussion
- 1.1.14 Ability to carry Service Specific Attributes: No Discussion
Authentication Requirements:
- 1.2.1 NAI Support: No Discussion
- 1.2.2 CHAP Support: No Discussion
- 1.2.3/4 EAP/PAP: No Discussion
- 1.2.5 Reauthentication on Demand: No Discussion
- 1.2.6 Authorization w/o Authentication: No Discussion
Authorization Requirements:
- 1.3.1 Static and Dynamic IP Addr assignment: No Discussion
- 1.3.2 RADIUS Gateway Capability
- Protocol requirement or implementation/application requirement?
- Which RADIUS versions are to be supported? Which subset?
- 1.3.3 Reject Capability: No Discussion
- 1.3.4 Preclude L2TP: No Discussion
- 1.3.5 Reauthorize on demand: Raj to look at this again 🙋
- 1.3.6 Support for ACLs
- Standardizes syntax, not semantics.
- Standardizes semantics in the NASREQ extension, but that is very weak
- 1.3.7 State reconciliation
- Appears weak, in that the server must "query the world" to restore its state
- Just in time reconciliation
- Simultaneous usage limitations
- More discussion needed
- 1.3.8 Unsolicited disconnect: No Discussion
Accounting Requirements:
- 1.4.1 Real time accounting: No Discussion
- 1.4.2 Mandatory compact encoding
- Is ADIF compact?
- Is ADIF UTF-8 compatible?
- 1.4.3 Accounting Record Extensibility: No Discussion
- 1.4.4 Batch Accounting: Diameter is okay for small batches. The specification doesn't seem suitable for large batch transfers (100,000+ records) 📦
- 1.4.5 Guaranteed Delivery: No Discussion
- 1.4.6 Accounting Timestamps: No Discussion
- 1.4.7 Dynamic Accounting: No Discussion
Mobile IP Requirements:
- 1.5.1 Encoding of Mobile IP Reg. Messages: Taken on faith
- 1.5.2 Firewall Friendly: Issues with SCTP being supported initially through firewalls
- 1.5.3 Allocation of Local Home Agents: Still a lack of understanding of the AAA protocol requirements here (versus just being a roaming attribute)
Overall summary
Diameter seems to meet most requirements and is a likely candidate to support the AAA requirements. ✨👑
Other matters
- Votes on Diameter should be in by Sunday evening. Same format as before. Mike will tally them 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 the timeframe allocated, we should not reopen submissions or discussions. Doing so could drag on for a long time and cause us to miss our July 15 date. 😵
- Possibility of needing a few extra days to finish the report, due to editing and review needs of the group. Mike to ask the ADs to consider a slight time extension.
"No discussion" means that the topic was mentioned, but there were no objections or issues raised on that requirement being met.
These are based upon my notes. Please send any corrections to the list. 💌
D.4. Minutes of 06-Jul-2000 Teleconference 🌸
Minutes of AAA-Team Telecon 7/6/00 By: Barney Wolff
Pro review of COPS - Dave Nelson 💜
- Likes the object model.
- No apparent showstoppers.
- Will resend the 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 the server speak to multiple client flavors?
- Will resend the review with typos corrected.
Comment by Mike StJ: "replace SNMP with COPS" - :) I think. 😂
Per-Item discussion
- 1.1.1 Scalability: concern re always-on TCP. Direction to DM: add general issue of number of connections.
- 1.1.2 Failover: No hot backup, but that is true of all protocols. (I.e., no explicit mention of a server-server protocol that might keep a backup server in sync so it could take over instantly.)
- 1.1.3 Mutual Authentication: perhaps relies on TLS. The draft does not otherwise support this.
- 1.1.8 Reliable AAA Transport: TCP + application heartbeat.
- 1.1.11 Proxy & Routing Brokers: client-type interaction with the proxy is questionable. (In later discussion, it appeared the client-type is a field in the request, and perhaps all AAA is one type, so it may not be an issue.)
- 1.1.13 Shared secret not req'd: runs over TLS, no multiple levels of security.
- 1.2.1 NAI Support: some uncertainty on the impact of RFC 2459 (X.509 profiles) on this. It may restrict NAI in some way?
- 1.2.3 EAP Support: multi-pass handshake needs work.
- 1.2.6 Authorization without Authentication: Mike comments that 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.3.2 RADIUS Gateway: skepticism was expressed.
- 1.3.4 Preclude L2 Tunnels: too much handwaving.
- 1.3.6 Access Rules: lots of work needed.
- 1.3.7 State Reconciliation: multi-server coordination is an issue.
- 1.4.4 Batch Accounting: for small batches, perhaps.
- 1.4.5 Guaranteed Delivery: application acks are an area of mystery. 🕵️
- 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 while other protocol uses are not. So it would be a big help, for both COPS and SNMP, to define a different port for their AAA application. 🔥
D.5 Minutes of 11-Jul-2000 Teleconference ✨
Okay bestie, here's the 11-Jul-2000 call 📞🎀 Present: Mike, Bernard, Paul, Bert, Raj, Dave N., Dave M., Barney, Stuart, and Mark. Dave Nelson took notes 📝
Mike St. Johns set the ground rules first 👑 Then everyone went through the summary results item by item 💅
- 1.1.1 Why are SNMP and RADIUS++ marked "P"? 🤔 Scaling retries across a web of proxies is a mess, since every level has a primary, secondary, and tertiary server.
- 1.1.2 Nobody did amazing here 😭 Same web-of-proxies problems as above. Also, how do you recover state from a primary server that already failed?
- 1.1.3 How serious is this requirement, really? 🧐 Mobile IP might have some legit needs for it. Is this even an AAA-level issue?
- 1.1.4 Is this hop-by-hop or transmission level? 🤷♀️
- 1.1.5 Most of the protocols used CMS for this one 💖 People asked if CMS even works for NASes and other edge devices. There's also a need for object-by-object confidentiality, so think about three-party scenarios too.
- 1.1.6 Why did SNMP get a different rating than 1.1.5? The evaluation was based on the submission documents, not what the protocol can actually do. So much hand waving 🙈
- 1.1.7 No comments 🫠
- 1.1.8 What does "reliable" even mean here? ✨ The transport protocol talk got pushed to later in the meeting.
- 1.1.9 No comments 🫠
- 1.1.10 SNMP got a "P" because of all the hand waving in its submission docs 🌸
- 1.1.11 SNMP got an "F" because its section just said "t.b.d." 💀 Diameter was the only submission that fully covered this item 👑
- 1.1.12 We read this requirement as "non-repudiation" 🔥 People worried that digital signatures are expensive to compute and aren't available everywhere. COPS still has work to do here.
- 1.1.13 Does "no shared secrets" mean an alternative key management mechanism is available? 🔑 We took it to mean application-layer security could be turned off in favor of transport layer security. There was also talk about using IKE in the AAA protocol.
- 1.1.14 No comments 🫠
- 1.2.1 No comments 🫠
- 1.2.2 No comments 🫠
- 1.2.3 No comments 🫠
- 1.2.4 Do we need a clear-text "password" for things like OTP, SecurID, and friends? 🤨 Everyone agreed 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.5 We split event-driven reauthentication from timer-driven (or lifetime-driven) reauthentication 🦋 How does this work in a proxy environment?
- 1.2.6 We said this requirement is an oxymoron 💅
- 1.3.1 We couldn't figure out what "static" meant, or what it was measured from 😵💫
- 1.3.2 We agreed NAIs could be handled, maybe with some restrictions 🧚
- 1.3.3 No comment 🫠
- 1.3.4 The SNMP submission documents had a lot of hand waving 🙈
- 1.3.5 Similar comments to 1.2.5 💜 How does the server know when to send this request?
- 1.3.6 Diameter's notation was weak and kind of least-common-denominator 😬 People were worried about interoperability when the syntax gets standardized but the semantics don't. This area needs more work 🛠️
- 1.3.7 How is this requirement met through proxies? 🤔
- 1.4.1 No comment 🫠
- 1.4.2 No comment 🫠
- 1.4.3 No comment 🫠
- 1.4.4 Lots of skepticism about batch accounting as part of the AAA protocol 😒 How big are the "batches"? Should this just use FTP or something similar?
- 1.4.5 No comment 🫠
- 1.4.6 No comment 🫠
- 1.4.7 No comment 🫠
- 1.5.1 No comment 🫠
- 1.5.2 We talked about what "firewall friendly" actually means 🔥 The idea was that firewalls don't want to look past the application protocol address, like a UDP or TCP port number. SNMP and COPS have uses beyond AAA, so they're at a disadvantage because firewalls have to dig deep into the application PDU to find out what the packet is for. Diameter relies on SCTP, which isn't widely deployed or widely recognized by firewalls 💀 Should firewalls also be AAA proxy engines? And does any of this affect interoperability with NAT?
- 1.5.3 We were kinda confused about what this requirement actually was 😭 Raj could explain it, but everyone else had to take it on faith 🙏
Next up was a poll on overall acceptability and effort for each submitted protocol, for requirements conformance 📊 Each member gave an evaluation as (Acceptable, Not-Acceptable), with qualifiers for (Accounting, or effort to change). This info will be summarized in the final report 🎀
After that came a general wrap-up discussion 🌈 It was considered really important to get as much of the thought process and rationale into the final report as possible ✨ Mike St. John is going to work with Dave Mitton on the ID. We really need to hit the IETF July 14 submission deadline, even if that means issuing an update on the AAA WG mailing list 😤 Everyone agreed the process went fairly well 🫶 For future evaluations like this, evaluators should follow the requirements documents closely, submitters should write accurate and complete conformance documents, and there should be a "re-spin" cycle to fix errors and omissions in both the requirements and conformance documents 🔁
Then we talked about the transport protocol 🚊 The big issue is congestion control 🚨 Streams-oriented apps over TCP have been a problem, and the IESG is getting more and more sensitive to this in new protocols 👀 AAA is a transaction-oriented application, and it was pointed out that other request-response apps, like DNS, scale well to Internet scale using simple application-level retries over UDP 🦋 TCP has head-of-line blocking problems, especially when multiple sessions share one TCP connection 😩 AAA typically sends 3 or 4 iterations and then reports a failure to the upper layers 💅 It doesn't keep retransmitting into congestion the way TCP does. It was also noted that bulk data transfer may not be best handled inside the AAA protocol 📦 People were worried SCTP isn't widely implemented 🫠 AAA will handle congestion control by limiting the number of outstanding requests 🚦 Some RADIUS implementations blast lots of traffic when they hit misconfigured shared secrets, but that's probably because of poor error recovery 🙄 Diameter, as drafted, relies on SCTP. Can AAA run over UDP? The IESG didn't say no 🤞 Their real issue is addressing congestion control 🌸
Full Copyright Statement 💖
Copyright (C) The Internet Society (2001). All Rights Reserved. 🎀
Anyone can copy this document and share it with others 📄 You can also make derivative works that comment on or explain it, or help people implement it, and publish and distribute those however you like, in whole or in part, no restrictions. The one catch is that the copyright notice and this paragraph have to stay on every copy and derivative work 🔒 The document itself can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed to develop Internet standards, in which case you have to follow the copyright procedures in the Internet Standards process, or when it gets translated into languages other than English 🌍
These permissions are perpetual and the Internet Society (or its successors or assigns) won't ever revoke them 🦋
The document and the info in it are provided "AS IS", 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 ✨
📦 where this page comes from
- ietf: rfc3127 2001-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms