NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 03-Aug-00
Paul Krumviede <Paul@mci.net>
Bernard Aboba <firstname.lastname@example.org>
Operations and Management Area Director(s):
Randy Bush <email@example.com>
Bert Wijnen <firstname.lastname@example.org>
Operations and Management Area Advisor:
Randy Bush <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: subscribe aaa-wg
Description of Working Group:
The Authentication, Authorization and Accounting Working Group focused on the development of requirements for Authentication, Authorization and Accounting as applied to network access. Requirements were gathered from NASREQ, MOBILE IP, and ROAMOPS Working Groups as well as TIA 45.6.
This incarnation of the AAA Working Group will focus on selection of a AAA protocol to be developed. We will solicit submission of protocols and compliance descriptions, will evaluate them against the requirements and will decide whether one of them meets the requirements sufficiently to become the basis of the subsequent design phase, or whether it is necessary to design one from scratch.
In this process, it is to be understood that the IETF does not function as a rubber stamp. A protocol, if accepted, will likely be changed significantly during the process of development.
Authors of candidate protocols must be willing to give up change control to the IETF, so as to allow modification of the candidate protocols to AAA WG needs.
The immediate goals of the AAA working group are to:
- Request submission of candidate protocols and compliance descriptions.
- Publish a draft comparing candidate protocols against the requirements.
- Decide whether any of the candidate protocols meet the requirements sufficiently to become the basis of the subsequent design phase, or whether it is necessary to design a new protocol.
Goals and Milestones:
Produce the first draft of a document comparing the candidates against the requirements
Submit comparison document as an Internet-Draft
Select a protocol, or decide to start from scratch. If the former, submit the Protocol Internet-Draft as a WG Work Item.
Working group closes and a new working group is formed to design a new protocol or to finish development of a proposal
No Request For Comments
Chairs: Bernard Aboba email@example.com
Paul Krumviede, firstname.lastname@example.org
Minute Taker: Dave Nelson
Editor: Bernard Aboba
Tuesday, August 1, Afternoon session
Announcement of the AAAARG from 3-5 meeting tomorrow.
Agenda bashing - protocol evaluation was put first on the agenda. Other items:
- Mailing list issues
- Discussion of latest version of AAA requirements draft.
- Some editorial changes have been proposed.
- Discussion of protocol evaluation draft.
- Presentations by protocol sponsors.
- What happens next?
There was discussion on the recent problems with the AAA WG mailing list. Some members are not getting all the posts, others are getting duplicates. How many people have seen the evaluation draft? Some positive response.
Mike St. Johns presented the evaluation team process. He introduced the participants: B. Patil, Dave Nelson, Barney Wolff, Mark Stevens, Dave Mitton, Stuart Barkley, Mike St. Johns. Mike came into the evaluation with no preconceptions - he had not had much experience with RADIUS prior to this. Each participant provided a conflict of interest statement. The first task was to scrub the requirements document. The team wrote a list of exceptions - items not substantiated in underlying requirements documents.
Mike went on to describe the process. Two briefs were assigned for each proposal: pro/con. The Pro position assumed an optimistic interpretation, the Con position a strict interpretation of the requirements.
Submission results were compared on a line by line basis to ensure consistent evaluation. Final result was taken by the team consensus, not numeric averaging. The final step was to vote on each proposal using the final results matrix. Votes were Acceptable, Acceptable for [Accounting], Acceptable with Engineering, Not Acceptable. The Engineering effort level required to remedy any deficiencies was estimated. The protocol evaluation document includes within it all documentation generated during the evaluation process, including the conflict of interest statements.
The results of the evaluation:
SNMP was judged NOT ACCEPTABLE. The submission did not provide enough detail to figure out how to use SNMP for authentication. However, SNMP may be used for accounting
RADIUS++ was judged NOT ACCEPTABLE. It would take a lot of work to bring RADIUS++ up to the requirements, and by the time this was done, it would most likely end up look a lot like DIAMETER. However, RADIUS++ did offer improved RADIUS backward compatibility and this is a feature worth incorporating into the final protocol.
COPS was judged ACCEPTABLE for AAA. It includes support for a data model, which is a plus. However, COPS is used for several purposes, which creates an issue with firewalls which will have to search inside the COPS packets to tell if they should be passed or not. Otherwise, you might end up allowing an external party to configure the QoS of your routers when all you wanted to do was to allow in AAA traffic. This is a problem with all multiple use protocols such as SNMP.
DIAMETER was judged ACCEPTABLE for AAA, and was MILDLY PREFERRED to COPS since more of the engineering work was done on DIAMETER. DIAMETER was also judged potentially more firewall friendly than COPS, although most firewalls will not be prepared to handle SCTP transport at this time. The evaluation committee had other issues with the use of SCTP transport as well. SCTP implementation is expected to be slow. TCP has been around a long time. So even though SCTP is going forward as a draft standard, that doesn't mean that it will be widely available any time soon, and if DIAMETER were to require SCTP transport, this could delay or even prevent its acceptance.
Given this evaluation result, where do we go from here? Concern with prolonging the process was expressed. We will not second guess the evaluation, but will go through the last call process on the evaluation team draft, incorporating working group comments. The evaluation process was designed to use outside/neutral evaluation.in order to avoid deadlock between the two camps.
Question: has there been an official choice of protocol? Or should we assume there is not a choice and go forward with a "merged" protocol? Answer: The milestones of the AAA WG say that the WG will select a protocol during August and that the WG will shut down by September. The decision on which protocol to choose is the responsibility of the Working Group. The evaluation team draft is a recommendation.
So the question is whether the AAA WG chooses to adopt the evaluation team recommendation. Question: Should we make the decision (one or more) now rather than later? Answer: Take the consensus of those present. Attendees were asked to hum if believed that Diameter is insufficient to met the requirements so that a second protocol is needed? No humming. Sentiment that both protocols should be pursued? A few. How many feel Diameter should be pursued? Many. Among the attendees at IETF48, there appeared to be consensus for choosing Diameter as a starting point. However, the issue will also be taken to the mailing list, to see if the WG membership agrees with the IETF 48 attendees in going forward to design a protocol based on the DIAMETER submission.
In terms of next steps, the evaluation Internet draft will be brought to AAA WG last call to allow the formal IETF process to continue. Dissenting opinions may be added in the Appendix. The evaluation team draft also addresses the perceived deficiencies of the submissions. The requirements draft -06 will also be brought to last call ASAP. Once these documents are done, the milestones of this incarnation of the AAA WG will be complete and the working group will re-charter.
The next incarnation of the AAA WG will focus on protocol design. As part of the protocol design process, it probably makes sense to work on another Internet-draft focusing on the ways in which the chosen protocol can be improved. This can include incorporation of ideas and concepts from the other submissions. The evaluation team draft is a good start at this. Randy suggested that a design team be formed to assist with this process, on a short timeline (potentially as short as 4 weeks). Having a period of design to end up with a better product is prudent. Open issues from the design team can then be made goals of the next incarnation of the AAA WG.
There was discussion of the fate of the other protocol submissions. Protocols were judged only with respect to applicability in AAA for Network Access. No judgement was made as to their applicability in other areas or working groups. For example, SNMP continues to widely used in network management, RADIUS has moved to draft standard, efforts are underway to utilize COPS for accounting elsewhere in the IETF. Should these efforts stop? Of course not.
There was discussion as to whether picking one protocol is really the right thing to do (Dave Harrington and Dave Durham have made this point on several occasions). The WG Chair does not see AAA WG interest in working on the formalization/development/specification of more than one protocol. However, this decision does not affect what goes on in other WGs relating to applications other than network access.
It was pointed out that it is likely that SNMP will continue to be widely used for accounting, regardless of what the AAA WG does. There is nothing wrong with this. COPS will continue to be used for policy outsourcing as well as provisioning and this is fine too. The new AAA protocol will be deployed and applied wherever its new network access AAA functionality is needed. Given that RADIUS is very widely deployed today and works perfectly well in many situations, it may take quite a while for a new AAA protocol to catch on. But that will eventually happen, provided that the requirements identified in the network access requirements document are real ones which customers want to pay money to solve, and provided that the AAA protocol really does meet those requirements. Our hope is that the new AAA protocol will satisfy those requirements better than any other protocol and in addition will be elegant and easy to deploy. But if you don't need to satisfy those requirements in a particular circumstance - or if you have another application altogether -- well then, feel free to use another tool.
There was a question on how to offer AAA for applications other than Network Access. That is an IESG issue; and there are several working groups that are looking at this, including the newly formed Kerberos WG and the CAT WG. Within the IRTF there is also the AAA RG to look at future issues. Those interested in AAA Research are urged to attend the AAA RG meeting during IETF48.
There was an opinion that during the last call process, it should be made clear that there will be only one "winner". A final decision of one or more protocols would best be part of the process of chartering for a follow-on WG. A new charter will likely be very specific on these points.
There was also a question about the difference between authorization and policy. During the first incarnation of the AAA WG, we actually had a work item to explain the difference. Unfortunately, we did not complete this work item so that we are still waiting for the answer. If anyone understands this, they are urged to write a draft, explaining it to everyone else. This would be an excellent topic for discussion in the AAA RG.
Document status review
Accounting Attributes draft in the RFC editor queue.
Accounting management draft completed last call and was sent to the IESG where it resides in the IESG queue.
Draft-ietf-aaa-na-requirements-05.txt went through WG last call and IESG review and was sent to the RFC editor. However, the evaluation team found some problems, and there seemed to be consensus on some of their suggested changes based on WG mailing list discussion. Bad references were found because of revisions to underlying documents. Those underlying documents are now close to completed - Dave Mitton noted that the -05 version of NASREQ criteria has completed NASREQ WG last call and is on its way to the IESG. Mobile IP AAA requirements went through WG last call and is on its way to the IESG. The TIA 45.6 document should be sent to the RFC editor to be published as an Informational RFC soon.
The plan is to make final -06 revisions to our AAA requirements document and post those on the archive ASAP, at which time we will initiate AAA WG last call again. Question about 10's of thousands of simultaneous requests. Question about the validity of the AAA requirements "scrub" process. This WG should be able to add or subtract requirements are it sees fit. Possibly problems with lack of documentation from the interim meeting. These issues will be resolved during the -06 draft last call.
Subir Das presented the proposal for a Basic User Registration Protocol (BURP). An Internet-Draft on BURP will be announced shortly.
Today we have Network to Network Interface (NNI) protocols: RADIUS, DIAMETER, COPS.
We also have User Network Interface (UNI) protocols: PPP and Mobile IP. A standard UNI is needed for environments in which neither PPP nor Mobile IP is in play. This is the problem that BURP attempts to solve, to develop a generic UNI that interacts with the Local Registration Agent, which may in turn interface to the back-end AAA server. BURP Is an application layer protocol, which can work with any configuration protocol (DHCP, Ipv6), in order to provide better information and control of network usage.
In terms of AAA requirements, BURP does not impose any new requirements or require any additional protocol support beyond what is already in the network access requirements. It is thus complementary to AAA protocols, increasing the applicability of AAA beyond PPP and Mobile IP. In terms of the AAA interaction with BURP, what is required is that the AAA server send back a "yes"/"no" answer.
There was a question as to whether DHCP is required prior to sending the BURP request. This can be an issue since the user has not yet authenticated to the network prior to making the DHCP request. The answer is yes, BURP will run over IP.
There was a suggestion that perhaps BURP should be explored within the AAAARG.
Milestones and roadmap
Tomorrow's agenda was displayed. Randy Bush proposed to discus milestones and road map. The existing document set will be run through the IETF process, in parallel. One goal should be to have an initial shot at a new charter by Thursday, which will get us on the IESG agenda, a four week process. By the next IETF meeting it would be highly desirable to have a stable protocol draft. A small design team might be used to assist the process of improving the protocol in specific areas. The new incarnation of the AAA WG will have a charter to finalize the design and supervise the specification. The working group will have one milestone - the protocol draft. Discussion of the time constraints for the design team? As we have done previously, the working group will be on a tight timeline.
Done for the day.
Wednesday, August 2 - Afternoon Session
milestones and roadmap
status review and closing remarks
We are at the beginning of the design of a protocol and there may be important issues and lessons to learn. That's why we need to hear the individual protocol submissions. Specific ideas have not been discarded (yet). Focus on technical issues.
AAA v6 Presentation
Charlie Perkins discussed the AAA v6 draft, providing us with an update on issues in the draft. The basic issue arises because Mobile IPv6 does not include support for a Foreign Agent. So the question is: how do Mobile Nodes authenticate for use of the service and how does AAA work? Should requests be authorized at the Ipv6 router based on the nature of service desired by the host. Should AAA IPv6 be network authentication only or should it go into specific services? And should IPv6 hosts speak the AAA protocol directly or do they use another protocol (such as BURP)?
Yves Tjoens of Alcatel presented the case for RADIUS ++.
Why are we here? RoamOps WG in August 99 saw a comparison of AAA protocols draft. That group was closed. Submitted similar draft to NASREQ WG. That group closed. Now brought to AAA group.
In May 2000, decided to submit RADIUS++ as AAA candidate protocol..
Provided a framework for needed protocol changes in RADIUS. The AAA evaluation draft indicated that medium to major engineering required for RADIUS++.
We discussed the issue of better backwards compatibility to RADIUS. What is needed in backward compatibility to RADIUS? Does it need to detect extensions and whether client understands them?
One issue is concatenations of legacy proxy implementations. For example, you can have a NAS speaking RADIUS, one proxy speaking DIAMETER, another proxy speaking RADIUS and a DIAMETER server. How do you discover what the server is capable of? How do you discover what the nodes along the path are capable of? This is not currently addressed in an elegant way in DIAMETER. Today capability negotiation in DIAMETER is only hop by hop - don't want to implement extensions to work with a routing proxy broker. It would be better to enable pass through capabilities in routing broker proxies (RADIUS/DIAMETER).
There is a need for a RADIUS/DIAMETER interworking Internet Draft. It is suggested that for the purpose of interworking that nested TLVs work better than tagged TLVs. For example, nested TLVs allow encapsulation of bundles of RADIUS attributes within DIAMETER, enabling the syntax and semantics of RADIUS to be carried within DIAMETER, rather than changing the semantics as the RADIUS AVPs within DIAMETER do today. There is also a need for error messages specific to RADIUS fallback.
Question: Please explain nested TLVs.? Answer: Groups of tagged TLVs have can't have special semantics when placed together, because there is no additional semantics for the grouping. Diameter allows this (nested) using <inaudible>. Support for hierarchy for CMS support could be generalized. Comments on the list regarding compatibility when some features are not supported in either of the protocols. In broker environments, we may have the "demotion" scenario in which and ISP is still running RADIUS servers.
David Durham of Intel presented the case for COPS Usage for AAA.
The proposal described changes that would be required in COPS to support AAA. COPS could be part of an overall solution. COPS contributes a robust Data Model. COPS data transport defines TLVs only for defining what the protocol is and does. It also defines the messaging which support the Information Model (PIBs). Open messages, sync messages, requests, decisions, reports are the basic message types. COPS uses a stateful request response model. State is installed on the Policy enforcement Point (PEP). State is removed when no longer applicable. Requests are uniquely identified by a handle. COPS messages can be proxied. Enhancements to COPS objects were reviewed. COPS security considerations cover data integrity and confidentiality, using COPS over TLS, on a hop-by-hop basis, and using CMS over COPS for end-to-end security. COPS data representation is based on SMI and BER, thus leveraging experience with SNMP MIBs. Improvements for efficiency (over SNMP) were made in the COPS SPPI. For example, OIDs are transmitted with redundancy removed, and the use of TCP enables transport of large messages, decreasing latency. The data model lives outside of the protocol. It is possible to set up classes, and use class inheritance, facilitating reuse of data model for extended areas of application. One can extend, augment and deprecate values in SPPI tables. COPS uses the same data representation to send accounting information. Both real time and batch accounting are supported. It is an advantage to separate TLVs in the protocol from the data model and information model.
Comment: Suggest that we learn from data model of COPS and consider creating drafts to provide a framework for standardized usage of AAA attributes (e.g Diameter AVPs) for various classes of provisioned network access services. This may lead to better interoperability.
Question: Why not use the outsourcing model of COPS? The COPS PR model was used instead for COPS AAA. Answer: There is an issue of resolving stateless and stateful models. The COPS provisioning model seemed to match the requirements better. The COPS-PR model better handles event driven requests as opposed to provisioning at boot up time.
David Harrington of Enterasys presented the case for SNMPv3.
As Chair of SNMPv3 WG, Dave requested that an SNMPv3 AAA submission be made. He concurs with protocol evaluation draft, given the specific process rules that were used. SNMP has been used for a lot of things, some that it is not well designed for. SNMP did not fit some of the requirements, as stated in the evaluation draft. SNMP is well designed for collecting accounting data. It meets the accounting requirements, as indicated by the evaluation team. SNMP should be considered as an accounting protocol. SNMP is the most widely utilized accounting protocol in the Internet today. AAA can be considered a special case of network management. There are some valuable lessons to learn for AAA protocol design. Keep it simple. Make it modular. Separate transport from the protocol. Separate the protocol from the data model. Design for growth and migration. Requiring a massive protocol version switchover doesn't work well. Make it flexible so that it can be configured to the environment. Make it work in small environments as well as large (e.g. set top box for SNMP). Make it possible to upgrade pieces of the architecture as the network changes. Costs for features should be borne only by those applications that need them.
Question: Please give specific examples of how SNMP is widely used as an accounting protocol? Answer: SNMP is not used only specific to NAS accounting, but used for accounting in general. There are about 4 or 5 drafts that use it. For example, many ISPs collect interface traffic statistics off routers via SNMP and use this to calculate the 95th percentile for billing purposes.
Pat Calhoun of Sun Labs presented the case for Diameter. His presentation highlighted issues with AAA evaluation draft, on an item by item basis.
Diameter was built on a RADIUS heritage.
Item: fail-over = "P". SCTP provides node to node fail-over. Diameter includes a Destination-AVP that allows a proxy chain to be different in either direction, which allows more resilient service. All pending packets are to be sent to an alternate node upon failure of the primary node. The specific issue that the evaluation committee had was not failover per se, but fail back.
Item: Re-authentication on demand = "P". Session lifetime attributes combined with EAP provisions for re-authentication should suffice. It may be that the draft text is not really clear.
Item: RADIUS Gateway = "P/T". Comments were made that it is impossible to create a totally compliant RADIUS gateway function, however the RADIUS gateway will only try translate items that it was designed to translate. What is the issue?
Item: Access rules and filters - "P". Diameter specifies a commonly used format for filters. If richer syntax is desired, that could be documented in a follow on draft.
Item: State reconciliation = "P". This is a really hard problem, so that grade is probably deserved.
Item: Firewall friendly = "P". This is probably valid based on SCTP deployment issues. Firewall issues are not well agreed, as to what constitutes a firewall vs. a gateway and what firewall "friendly" really means.
Item: Batch accounting = "P" There may be some disagreement of what batch accounting means. Diameter does have AVPs that specify how often accounting data is to be sent.
Item: The overall evaluation rating is [only] slightly preferred. Deployment of SCTP was mentioned as a potential roadblock. SCTP is now in the RFC editor queue and has had successful bake-offs.
Question: Is use of SCTP for Diameter mandated by the IESG? Is the issue technical or political? Could UDP be considered? Answer: Refer to RFC 2309 section 4. The IAB and IESG have said that building yet another reliable transport protocol based on UDP is unacceptable. Protocols should use SCTP instead. TCP has been seen to have problems with congestion management. There are also issues on a macro scale with packet loss and congestion even with things like DNS running over UDP.
Question: In configurations in which home servers are reached though intermediate devices, and the home server desires to initiate re-authentication on demand, what happens if the intermediate devices become inoperative? Is there a path discovery problem? Answer: Probably.
We will be bringing the AAA protocol evaluation document to WG last call. Please post comments to the list. Also post comments on the 06 version of AAA requirements document. Then we will begin a re-chartering discussion on the mailing list. Send any suggestions for protocol improvements to AAA list.
DIAMETER Protocol Evaluation
SNMPv3 and AAA