RFC 2748 a.k.a. 'the protocol' Ref  is the AAA evaluation criteria as modified by us. Ref  is "AAA Protocols: Comparison between RADIUS, Diameter, and COPS" work in progress. Ref  is "COPS Usage for AAA", work in progress. This document uses T to indicate total compliance, P to indicate partial compliance and F to indicate no compliance. Section 1 - Per item discussion 1.1 General Requirements 1.1.1 Scalability - The document  claims "T", and the evaluator concurs. 1.1.2 Fail-over - The document  claims "T", and the evaluator concurs. 1.1.3 Mutual Authentication - The document claims "T", and the evaluator concurs. 1.1.4 Transmission Level Security - The document  indicates that transmission layer security, as defined in , is provided in the protocol, using the mechanisms described in . It should be noted that this requirement is now a SHOULD in . The document claims "T", and the evaluator concurs. 1.1.5 Data Object Confidentiality - The document  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  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  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  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  claims "T", and the evaluator concurs. 1.1.10 Run over IPv6 - The document  claims "T", and the evaluator concurs. 1.1.11 Support Proxy and Routing Brokers - Reasonable detail of proxy operations is provided in . The document  claims "T", and the evaluator concurs. 1.1.12 Auditability - The document  alludes to a History PIB that would enable auditing without explaining how it would work. The AAA Extension  does not provide additional insight. The document claims "T", and the evaluator awards "P". 1.1.13 Shared Secret Not Required - The document  claims "T" and the evaluator concurs. 1.1.14 Ability to Carry Service Specific Attributes - The document  claims "T", and the evaluator concurs. 1.2 Authentication Requirements 1.2.1 NAI Support - The document  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  claims "T", and the evaluator concurs.
1.2.3 EAP Support - The document  claims "T", and the evaluator concurs. 1.2.4 PAP/Clear-text Passwords - The document  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  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  claims "T", and the evaluator concurs. 1.3 Authorization Requirements 1.3.1 Static and Dynamic IP Addr Assignment - The document  claims "T", and the evaluator concurs. 1.3.2 RADIUS Gateway Capability - The document  claims "T", and in the absence of any detailed discussion of how this is accomplished, in either  or , the evaluator awards "P". 1.3.3 Reject Capability - The document claims  "T" and the evaluator concurs. 1.3.4 Preclude Layer 2 Tunneling - The document  claims "T", and in the absence of any detailed discussion of how this is accomplished, in either  or , the evaluator awards "P". 1.3.5 Reauth on Demand - The document  claims "T", and the evaluator concurs. 1.3.6 Support for ACLs - The document  "T", and the evaluator concurs. 1.3.7 State Reconciliation - The document  "T", and the evaluator concurs. 1.3.8 Unsolicited Disconnect - The document  claims "T", and the evaluator concurs.
1.4 Accounting Requirements 1.4.1 Real Time Accounting - The document  claims "T", and the evaluator concurs. 1.4.2 Mandatory Compact Encoding - Note that the term "bloated" in  is somewhat subjective. The document  claims "T", and the evaluator concurs. 1.4.3 Accounting Record Extensibility - The document  claims "T", and the evaluator concurs. 1.4.4 Batch Accounting - The protocol   does not address how in detail this feature might be accomplished. The document  claims "T", and the awards "P". 1.4.5 Guaranteed Delivery - Guaranteed delivery is provided by TCP. The document  claims "T", and the evaluator concurs. 1.4.6 Accounting Timestamps - The document  claims "T", and the evaluator concurs. 1.4.7 Dynamic Accounting - The document  claims "T", and the evaluator concurs. 1.5 MOBILE IP Requirements 1.5.1 Encoding of MOBILE IP Registration Messages - The document  claims "T", and the evaluator concurs. 1.5.2 Firewall Friendly - The document  claims "T", and the evaluator concurs. 1.5.3 Allocation of Local Home Agent - The document  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 . First, this memo is a "PRO" brief, and as such reasonable benefit of doubt is to be given in favor of the protocol submission. Second, there is a fundamental conceptual issue at play. The COPS-PR model provides a sufficient set of basic operations and commands, a stateful model, the ability for either "peer" to initiate certain kinds of requests, as well as an extensible command set, to be able to support a wide variety of network and resource management protocols. The details of protocol specific messages is left to
Policy Information Base (PIB) data objects. Since no AAA PIB has been written, the evacuator can only (optimistically) assess the inherent capabilities of the base protocol to accomplish the intended requirements of , given a reasonable set of assumptions about what an AAA PIB might look like. In some sense, this akin to asserting that a given algorithm can be correctly implemented in a specific programming language, without actually providing the code. The PIB model used by COPS is a powerful and flexible model. The protocol document  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 , 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. 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. 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. That is it does have one application level ACK. Statements such as "TCP provides guaranteed delivery" are incorrect. COPS does attempt to identify outages by using a keep-alive message between TCP peers. 1.1.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 forward is not well understood by this evaluator. Does each client type require the Broker to make a different client Open request to it's upstream servers? What about routing brokers? 1.1.12 Auditability - P (was T) (based on our interpretation as non-repudiation, rather than the definition given in reqts) The explanation of a History PIB is incomplete and therefore inconclusive. 1.1.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. 256 Object "classes" or types, with 256 subtypes or versions. Client types are 16 bits long, where the high bit indicates "enterprise" specific values. But pertain to a COPS peer-
connection session. The client type seems to just identify the information model for the message. eg. it will be fixed to one value for AAA. 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 product differ in some way, each PIB will be different, and sharing common provisioning profiles will be a rather difficult mapping problem on the server. d) It's not clear the different client types can be mixed or that other objects definitions can be used from other defined client types. It's really unclear how the client type of a connection propagates in a proxy situation. 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 doesn't deliver much meat. Nonetheless, 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 here to indicate to 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 which 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 does believe that 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) 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. Because it uses TCP and can be identified by known connection port. But there is an issue with respect to the impact level of mixed COPS traffic coming through a common firewall port. 1.5.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 be somewhat flexible, but with a totally different set of assumptions on how many clients and requests would be funneled through the infrastructure and the acceptable overhead. This evaluator is not sure that it scales well to the fast evolving access market where every product doesn't implement a small set of common features, but a large set of overlapping ones. 3. General Requirements COPS started out with small and easily met set of design goals for RSVP and DiffServe, and is evolving as a new hammer to hit other nails [COPSPR]. As COPS implementors get more operational experience, it is interesting to see more reliability fixes/features quickly get patched in. Understanding COPS requires that you read a number RFCs and drafts which do not readily integrate well together. Each application of COPS has spawned a number of drafts. It's not clear if one wants to or can implement a single COPS server that can service AAA and other application clients. The COPS authors seem to overly believe in the goodness of TCP, and rely on it to solve all their transport problems, with concessions to application keep-alive messages to probe the connection status and sequence numbers to prevent replay attacks. This evaluator believes this type of approach may work for many networks but really doesn't
scale well in larger configurations. End-to-end application acks are the only guaranteed delivery solution, particularly where distributed state is involved. COPS falls into an in between place on encoding. It has small number of simple data object blobs which are concatenated ala RADIUS/Diameter TLVs to form a flexible message layout. However, they attempt to limit the number of objects by making them arbitrarily complex ala SNMP MIBs, and defining yet another data structuring language for these PIBs. There is a lot of computer science style grandstanding in [COPSAAA] Section 1.2, but no translation into how a set of data objects can be used to meet these wonderful features in operation. (or even if we needed them) This will be the crux of the interoperability issue. RADIUS implementations interoperate because they at least, understand a common set of functional attributes from the RFCs. And vendor extent ions can be simply customized in as needed via dictionaries. If PIB definitions are needed for every piece and version of access equipment, before you can use it, then the bar for ease of configuration and use has been raised quite high. Support for PIB definition and vendor extensions will be on the same order as MIB integration in SNMP management products and put the supposed complexity of Diameter to shame. 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 will introduce more complexity than needed and opportunities to have progress pulled into other rat-holes. (eg. Policy Frameworks)
* With regard to mobile IP requirement, everything works well, although firewall friendliness is a judgment call. * Proxy mechanisms of SNMPv3 mitigates problems w/ firewalls. * Scalability is ok. * Overall, meets most requirements and shortfalls are minor. * In some cases requirements seemed to expressed in a manner that "stacks" the odds against SNMP. * SNMP is deployed everywhere already. * The protocol has a well-understood behavior despite the tedium of MIB definition, so it has the advantage of not requiring the creation of a new infrastructure. * AAA response document is silent on architecture and MIB definition, but there is too much work to do at this stage of evaluation. Not having done the MIB definitions and architecture is not a limitation of the protocol. * SNMP is a good candidate. Mike St. Johns took the floor to give a summary of the con argument. * Neither the requirements, core documents nor response document specify the mechanism of operation. * Liberties were taken in the assertion that the server to server interaction requirements were met. * The scaling arguments are weak. * Fail-over arguments are weak. * Security aspects work well with the manager/server paradigm, but not well in bidirectional interactions among peers. * The authentication requirements not understood by authors of the response document. * SNMP is just data moving protocol. * Message formats not specified. * What is the method for supporting authentication? Storing the information is handled, but what do the nodes do with it? * 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.
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 is 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 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 tertiaries 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 reviewers 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 - 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 phonecall 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.
Data object confidentiality has been expressed as very important, diameter glosses over it referring to rfc2630, cost to run on NAS device ACL: filter style syntax seems inadequate state reconciliation: difficult over global multiple administrative domains batch accounting: implementation doesn't meet intended need firewall friendly: until firewalls support SCTP will be failure summary very close concerns: size and complexity needs almost all extensions to actually support needs separation of SCTP and data (as per IESG suggestion?) application vs transport acks Point-by-point Discussion: General (1.1): 1.1.1 Scalability Handles large number of requests SCTP reduces proxy needs (how? what is 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 NASREQ extension, but is very weak 1.3.7 State reconciliation Appears to be weak in that server must "query the world" to restore its state Just in time reconciliation Simultaneous usage limitations More discussion needed
1.3.8 Unsolicited disconnect 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 okay for small batches. 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 of faith 1.5.2 Firewall Friendly Issues with SCTP being supported initially through firewalls
1.5.3 Allocation of Local Home Agents Still 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 AAA requirements. Other matters: Votes on Diameter should be in by Sunday evening. Same format as before. Mike will tally up as both majority and average votes. Should different requirements have different weight? Possibility of SNMP reconsideration as per ADs? To close off our task in timeframe allocated, should not reopen submissions or discussions. Could cause to drag on for long time causing us to miss our July 15 date. Possibility of needing a few extra days to finish report due to editing and review needs of the group. Mike to ask ADs to consider slight time extension possibility. "No discussion" means that the topic was mentioned but there we no objections/issues raised on that requirement being met. These are based upon my notes. Please send any corrections to the list.
Con review of COPS - Dave Mitton Architecture is mostly there. Strong dependency on info model, sceptical of object model. Problem with info model in multi-vendor, multi-administration environment. How does server speak to multiple client flavors? Will resend review with typos corrected. Comment by Mike StJ "replace SNMP with COPS" - :) I think. 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 true of all protocols. (ie, no explicit mention of server-server protocol that might keep a backup server in sync so it could take over instantly.) 1.1.3 Mutual Authentication - perhaps relies on TLS. Draft does not otherwise support this. 1.1.8 Reliable AAA Transport - TCP + appl heartbeat. 1.1.11 Proxy & Routing Brokers - client-type interaction with proxy is questionable. (In later discussion, it appears client-type is a field in the request, and perhaps all AAA is one type, so may not be an issue.) 1.1.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 - may restrict NAI in some way? 1.2.3 EAP Support - multi-pass handshake needs work. 1.2.6 Authorization without Authentication - Mike comments the requirement is broken. BW comment (post-meeting) - the requirement appears intended specifically to chastise RADIUS for requiring User- Name and some sort of password in an Access-Request, even if it's sent pre-connect, on receipt of DNIS, for example. Sure it's silly, but does it really matter whether an attribute is absent or filled with "NONE"? This was just nasty sniping at RADIUS on somebody's part, imho. 1.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 but not other protocol uses. So it would be a big help, for both COPS and SNMP, to define a different port for its AAA application.
1.1.6 Question as to why SNMP did not rate the same as for item 1.1.5? The evaluation is based on what was contained in the submission documents, rather than capabilities of the protocol itself. Too much hand waving. 1.1.7 No comments. 1.1.8 Question as to meaning of "reliable"? Discussion of transport protocols was deferred to later in the meeting. 1.1.9 No comments. 1.1.10 SNMP received "P" because of hand waving in the submission documents. 1.1.11 SNMP received "F" because this section of the submission document indicated "t.b.d.". Diameter was the only protocol submission to completely address this item. 1.1.12 We treated this requirement as "non-repudiation". There is a concern that digital signatures are computationally expensive and are not globally available. COPS has more work to do on this item. 1.1.13 Question that "no shared secrets" should be interpreted to mean that an alternative key management mechanism is available? We treated this as meaning that application-layer security could be turned off in deference to transport layer security. There had been discussion of the use of IKE in the AAA protocol. 1.1.14 No comments. 1.2.1 No comments. 1.2.2 No comments. 1.2.3 No comments. 1.2.4 Is there a need for a clear-text "password" for service such as OTP, SecurID, et. al.? It was noted that all plain passwords are exposed in clear-text at the NAS or other edge device, which is no more inherently trustworthy than any AAA server or proxy. 1.2.5 We distinguished event-driven reauthentication from timer- driven (or lifetime-driven). How is this requirement to be met in a proxy environment? 1.2.6 We asserted that this requirement is an oxymoron.
1.3.1 We had difficulty in determining what "static" meant, and from which reference point it was measured. 1.3.2 We agreed that NAIs could be handled, possibly with some restrictions. 1.3.3 No comment. 1.3.4 The SNMP submission documents contained significant hand waving. 1.3.5 Similar comments as to item 1.2.5. The question was raised as to how the server knows when to send this request? 1.3.6 We found that the notation in Diameter was weak, and of a least common denominator nature. In general, there was concern about achieving interoperability when the syntax was standardized but the semantics were not. This area needs further work. 1.3.7 Question as to how this requirement is achieved via proxies? 1.4.1 No comment. 1.4.2 No comment. 1.4.3 No comment. 1.4.4 There was significant skepticism regarding batch accounting as part of the AAA protocol. How large are the "batches"? Should this requirement be met using FTP or something similar? 1.4.5 No comment. 1.4.6 No comment. 1.4.7 No comment. 1.5.1 No comment. 1.5.2 There was some discussion of what constitutes firewall friendly. It was suggested that the firewall didn't want to look into packets much past the application protocol address (e.g. UDP or TCP port number). Protocols such as SNMP and COPS that have usage other than AAA are at a disadvantage, since the firewall must look deep into the application PDU to determine the intended purpose of the packet. Diameter suffers from reliance of SCTP, which is not widely deployed or widely recognized by firewalls. Should firewalls
also be AAA proxy engines? Has this issue anything to do with interoperability with NAT? 1.5.3 We had some confusion as to what the requirement actually was. Raj seemed to be able to explain it, but the rest of us had to take it on faith. A poll was taken on overall acceptability and effort for each of the protocols submitted, for requirements conformance. Each member indicated their evaluation in the form of (Acceptable, Not-Acceptable) with qualifiers for (Accounting, or effort to change) This information will be summarized in the final report. A general wrap-up discussion was held. It was considered important that as much of the thought processes and rationales be placed in the final report as is feasible. Mike St. John will work with Dave Mitton on the ID. We really need to meet the IETF July 14 submission deadline, even if we have to issue an update on the AAA WG mailing list. All agreed that the process went fairly well. In future evaluations of this nature, it would be well for the evaluators to follow the requirements documents closely, for the submitters to create accurate and complete conformance documents, and to allow a "re-spin" cycle to correct errors and omissions in the requirements documents and conformance documents. A discussion of the transport protocol was held. The issue with transport is congestion control. There has been a problem with streams-oriented applications over TCP. The IESG is increasingly sensitive to this issue in new protocols. It was noted that AAA was a transaction-oriented application. Other request- response applications, such as DNS, seem to scale welt to Internet- scale using simple application-level retries and UDP transport. TCP has problems with head-of-line blocking, especially when multiple sessions are using a single TCP connection. AAA typically will send 3 or 4 iterations and then indicate a failure to the upper layers. It won't continue retransmissions in the face of congestion, like TCP. It was noted that bulk data transfer may not best be implemented in the AAA protocol. Concern was voiced that SCTP is not a widely implemented protocol. AAA will implement congestion control by limiting the number of outstanding requests. Some RADIUS implementations send lots of traffic when they encounter misconfigured shared secrets, but this is likely caused by a lack of proper error recovery. Diameter, as currently drafted, relies on SCTP. Can AAA run over UDP? The IESG didn't say "no"; their issue is addressing congestion control.
Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.