IETF 49 - Minutes of the AAA Working Group Dec 11 & 13, 2000, San Diego Recorded by: John Vollbrecht Edited by: David Mitton Monday, 11th, 1:00pm Agenda bashing (none) Document Status: draft-ietf-aaa-proto-eval-01.txt (Mitton) has few comments, in WG last call draft-hiller-cdma2000-aaa-02.txt (Hiller) ready to send to RFC editor ------------------------------------ AAA Milestone Review: - Development of AAA protocol based on Diameter - need results soon!! Process: - Solicit Issues on current specifications and document - Solicit Solutions proposals and document - Discuss Proposals, reach consensus - Check in accepted solutions to Diamter drafts Solutions Doc is scheduled for Feb 1 Rework into protocol submission - Jan 15? April 1 submission of protocol docs as proposed standard RFC ------------------------------------- Diameter Issues Review -- Pat Calhoun draft-ietf-aaa-issues-03.txt draft-ietf-aaa-solutions-01.txt Pat reviewed the issues laid out in this draft and any discussion of the solutions proposed. An issue was raised with the Result-Code AVP, and whether proxies could add values and if multiple were allowed. This was not completely resolved. A rough consensus was reached that ADIF descriptino of accounting data should be dropped from Diameter documents, dues to issues of definition and efficiency. This implies significant cleanup of the solutions draft Accounting polling, has significant problems, particularly with scale in proxy situations, but is required, in some form, to support resource management. (this seems to tie in with the tight state consistency issue) Batched accounting is no longer supported as part of the Diameter message format. Transport level batching may be supported and this may be dealt wit as a transport issue. End-to-end security was discussed for a fair while. Secure key distribution is still a major problem, particularly if there is a proxy chain. There was some suggestion if this could be layered into the protocol at a later time. There is some disagreement as to whether we need ETE from the NAS or the user's accessing system. This topic is still being discussed on the mailing list. Issues with transport have been taken outside of this draft. See Bernard's presentation. There has been a suggestion to add an AVP to indicate if a Diameter message has been translated from RADIUS, as an aide to upstream systems. Issues relating to the Data model have not be put in this draft, but are being discussed in later presentations. The Mandatory AVP flag bit was discussed. Some do not see the purpose or think the issue can be solved by definition. Randy made the point that Mbit does not force the receiver to implement a feature (known or unknown), but could allow the receiver to nak the request without prejudice to the receiver's implementation. It was also pointed out that the word extensions is overloaded. There is a difference between diameter extensions for a service, and vendor specific extensions. Discussion also pointed out that future systems might include situation where sender must know that the receiver is able to deal with an attribute, and may have an alternate strategy if the receiver does not understand the attribute. A hum overwhelmingly indicated consensus for retaining the M flag. There is no progress on a MIB at this time, as protocol objects have not been identified. Should each extension have its own MIB? How are how are sensitive objects transferred in MIB? e.g. passwords, shared secrets, etc. The MIB definition can be deferred until other parts of protocol definition are complete. The solutions draft introduces the concepts of tight and loose consistency state across client/proxy/server systems. Pat would like to drop tight state, but there was some push back and the suggestion that a problem statement should be made. Non-IP filters are a descriptive problem, no one seemed to care. They will be dropped from protocol requirements. IANA will need to create a new registry for Diameter identifiers. We will have to recommend a procedure for future allocation. We also need to figure out when it makes sense to start this process. Paul Funk raised an issue with Identifiers, which was decided to be discussed on the the mailing list. ------------------------------- Proxies Draft -- Dave Mitton draft-ietf-aaa-proxies-01.txt This document describes a number of proxy issues, and defines terminology and motivation. Dave presented an overview of it's topics. The types of proxies; routing, policy and brokers were defined. Proxies need to handle some state information to do their job. The types of state information required depends on the reliability and transactional role. By retaining state proxies require help from the protocol to reliably track the network operation, in the face of network failures, failover, and shutdowns. Generic problems with transport reliability and congestion are amplified by proxies --------------------------- Diameter API- James Kempf draft-kempf-diameter-api-03.txt A C language API that supports both client and server, is now complete. Java implementation now well in progress. ------------------------------------ IPV6 implications - Charlie Perkins draft-perkins-aaav6-01.txt This draft proposes a way for IPv6 notes to automatically offer credentials to a local AAA server to access the network. The document presumes that routers and DHCP servers will help perform this task. The handling of Mobile IPv6 nodes is also included. Some discussion as to were this fits in this or other working groups. Clearly working on ICMP messages is not. The work is currently an individual submission, looking for appropriate place to land. ------------------------------------ Transport issues -- Bernard Aboba draft-ietf-aaa-transport-00.txt Goal was to understand how transport and AAA protocols interact with each other. RADIUS had single NAS AAA connection, some had a connection per port, implication that a NAS could send multiple uncorrelated packets. AAA must use a congestion friendly transport, and pipelining is highly desirable. Firewall issues need to be examined; that is DNS and AAA traffic must be allowed, but Denial-of-services attacks prevented. Perhaps we need port specific rate limiting on router or built-in DoS solution. Potential problem with lots of NASs may create a traffic problem for a single AAA server, because for all of them might create traffic and cause congestion and packet loss near AAA. Because NAS is unaware of downstream proxy issues, it can't rate limit. Possible solutions: Send a "busy" indicator - tell NAS or proxy to stop for a while because;(it is too busy, or because next AAA server is not responding, additionally: can't locate server, can't forward, waiting to get sufficient info to reply). Conclusion: this message resolves a lot of the problems. Application vs Network driven message timing: Time between AAA requests is much larger than rtt by a lot. (e.g. small nas 20 minute sessions) Network driven (e.g. 8am office startup) would like to piggyback acks rather than have delayed acks. Rtt times are not necessarily reflective of actual response because of the TCP could run without delayed acks. This would fix rtt. A good discussion of TCP congestion control and slow start interactions with AAA sequences was held. Conclusions: TCP feasible, SCTP feasible, UDP not so much. Discussion: turning off delayed acks in TCP requires immediate ack, therefore doesn't it increase number of packets? Not if TCP acks are piggybacked on AAA acks. This requires some investigation. ------------------------------------------------------------------------------ Second Meeting; Wed, Dec 13th, 1:00pm Due to a time conflict, people interested a presentation on CMS, are encouraged to attend Stephen Farrel's presentation in the SMIME WG. ---------------------------------- CHAP Improvements - Uri Blumenthal Uri briefly presented improvements in CHAP challenge processing that would improve security across AAA. He will write them up in a draft and bring to the mailing list's attention. --------------------------------- Transport Issues - Bernard Aboba draft-ietf-aaa-transport-00.txt Continued discussion on prior day's presentation. Some problems were found in piggy-back ACK assumptions that were corrected. Acks will happen and contribute to RTO measure. May want to adjust ack delay from proxy to optimise, but it is hard to predict server latency. Application level re-transmits are a different issue. We should try to keep transport connection problems separate from upper level problems. Networks problems should not happen too often and some loss may be acceptable. Race conditions may arise if a NAS attempts to failover while a proxy is also trying to find a working server. Server state could become incorrectly over subscribed. Ideally, we'd like the connections to be end-to-end self-clocking/regulating. Application feedback messages may be the only good and practical solution for this. Discussions: Can we write off UDP as too problematic? Can we characterize single connect vs multi-threaded implementations? (Some RADIUS implementations use multiple sockets as clients and send/receive without any centralized queueing or coordination on the host system. Does Diameter have different requirements that cannot support this?) [OT] Acct-Start message sent before PPP NCP finish is not good. Will Diameter define this? -------------------------------------------------- Kerberos for End-to-End Security - Kaushik Narayan draft-kaushik-radius-sec-ext-04.txt Presentation of method to use Kerberos for AAA security. Issues with proxies and multiple domains. Can this be used for End-to-end encryption? There is also discussion of these issues in the IRTF AAAarch group. ------------------------------------------ Service Discovery Protocol - Erik Guttman Consider: 1) a static list 2) Use SLP protocol for local servers 3) Use DNS SRV RRs (requires domain name) Looking for interest --------------------------------------- Data Modeling: Requirements and Issues - Erik Guttman draft-ietf-aaa-issues-03.txt draft-ietf-aaa-solutions-01.txt Attempting to separate data description from actual messages. Type of message now indicated in header flags. Type of AVPs simplied and extended to allows complex data to be built out of primary types. Develop a formal notation for Diameter AVPs: We now have three proposals; XML, SMIng, and UML. The XML is attached to the current solutions draft --------------------------------------------- Data Modeling Proposal - Jurgen Schoenwaelder draft-schoenw-sming-diameter-00.txt Jurgen has developed an approach to describe Diameter AVPs using the new SMI language. -------------------------------- AAA Data Modelling - Dave Spence draft-spence-aaa-nas-data-model-00.txt This model complements SMIng, and includes a PIB. Diameter/RADIUS AVPs are grouped according to message role (Auth Request/Response, Accounting) and service type, and represented in a UML model schema. This notation allows one to describe the AVPs in different types of requests and responses as well. It does not describe on-wire format. [The meeting ran over into the break about 20 some minutes.] Due to lack of time, the 3GPP Accounting and the IRTF AAAarch presentations were not given, but are in the minutes. -------------