Present: Mike, Bernard, Paul, Bert, Raj, Dave N., Dave M., Barney,
Stuart, Mark
Recorded By: Dave Nelson
Mike St. Johns set the ground rules.
An item by item review of the summary results was held.
1.1.1 Question as to why SNMP and RADIUS++ are "P"? There are issues
regarding scaling of retries in a web of proxies (multi-layer proxy;
primary, secondary tertiary servers at each level).
1.1.2 No protocol did very well. Similar issues as above, e.g. web
of proxies. Recovery of state from a previously failed primary
server?
1.1.3 Question as to how serious is the need for this requirement?
May be some legitimate requirements from Mobile IP. Is this
requirement an AAA-level issue?
1.1.4 Called hop-by-hop or transmission level?
1.1.5 Most protocols evaluated used CMS to meet this requirement.
Question as to applicability of CMS for NASes and other edge devices?
There is a requirement for object by object confidentiality.
consider three-party scenarios.
1.1.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 RFCEditor function is currently provided by the
Internet Society.