Subject: RE: nasreq-criteria-03 and AAA

From: "Mark Anthony Beadles" <[email-masked]>
Date: Wed, 27 Oct 1999 15:17:30 -0400

From: D. Harrington
Thanks very much for the comments.  I will certainly try to clarify many of
the points in -criteria-04, after D.C.  Here are some responses:

>3) 8.1.2.2 says the transport for accounting MUST be reliable, but it
>doesn't define reliable. Does this mean it must be 100% reliable? no
>packet loss? must use message acknowledgements? must use a mechanism to
>check all data for integrity?

In this requirements document, I have deliberately avoided specifying
protocol implementations.  However, the intent is that it MUST be reliable
in the sense that TCP is reliable, and in the sense that RADIUS Accounting
is NOT.

>5) Most of the requirements specified in 8.1.x.x. have not been
>reflected in the AAA matrix for accounting: load balancing, not a single
>point of failure, fail-over, flow control, must support multiple domains

Yes, an oversight on my part, thanks.

>"Must not use a model that assumes a single domain of authority." - The
>accounting data must be able to contain references to multiple domains of
>authority, but can there be a single domain of authority over the
>accounting data collected? i.e. if SNAFU Communications collects
>accouting data about the resources used in their network, especially
>proprietary data, isn't SNAFU the single domain of authority over that
>data? Can they limit access to the collected data? Can they collect the
>data using a protocol which  "knows" that the collecting entity will be
>the single domain of authority over that collected data?

Certainly the AAA protocol must be able to handle the case where there is
really only a single domain of authority, as a degenerate case of the
multiple-domain scenario.  But I think the multiple domain case is going to
become much more common.  Even in your example, SNAFU may be leasing its
POPs from a reseller, and may be selling services to enterprise customers
who are responsible for authenticating their own users.

>An SNMP agent
>"owns" the data in its virtual database. Can an SNMP-based accounting
>solution ever be considered AAA compliant?

This is a question we must study.  Some of us are going to be writing a
document after D.C. attempting to answer this very question.

>"Years of experience with AAA protocols and NAS's has proven..." Is this
>incontrovertible proof? Who has this proof? Are there references I can
>use to find and review this proof?

"Proven" in the sense of "shown" or "demonstrated", not in the sense of
mathematical proof.  If you have some desire to convert the archives and
outputs of the RADIUS, NASREQ, and Roamops WGs over the years into a formal
calculus, feel free :)

>9) 8.1.3 defines some minimums. I don't understand the source of the
>numbers, and consequently what the requirement is: "minimum of 64K
>Attributes (minimum 16 bits), each with a ninimum length of 64K (minimum
>16 bits)."

Actually, I consider theses requirements to be fairly straightforward.  The
protocol has to support at least 65535 unique attributes.  A minimum 16 bits
are required to enumerate this many attributes.  The protocol must allow
each attribute to contain up to 65535 octets of data.  A minimum 16 bits are
required to encode this length.

>10) 8.1.3.1 AAA MUST provide some support for complex types. Why is this
>a MUST? Are there attributes that MUST be suported that MUST be
>represented using complex types? What if somebody defined a protocol
>that, using simple types in the protocol, could be used to convey all
>the information needed? Why MUST it also support complex types?

The best example that I can think of is
draft-ietf-radius-tunnel-auth-09.txt.  Check out the "tags".  Using complex
tagged types greatly simplifies the description of multiple tunnels.

>11) 8.1.3.2 "an extension to that protocol MUST be defined which
>supports this set." - why not make the requirement that AAA must be able
>to be extended to support the set of RADIUS attributes. We aren't
>defining other required attributes at this time, why are we making these
>required attributes? Can't we define them later, and separately, just
>like it appears is the plan for all other attributes?

An AAA protocol that does not support EVERY bit of functionality that RADIUS
currently does is 100% useless.  We can define them in a separate document,
yes, but unless they are defined, then the requirements for NASREQ are not
met.  I am not interested in a protocol which is merely elegant and
well-designed.  It must also be useful.  ISPs will never move to a new
protocol unless it does what they need it to.

>12) Throughout the industry, years of operational experience with <take
>your pick> protocols has proven that allowing vendor-specific attributes
>and data types can have a negative effect on interoperability.

=Grin= Do you have a copy of this proof that I can peruse?  Seriously, if we
do not provide standard support IN THE PROTOCOL for vendor-specifics, then
vendors will simply come up with their own non-standard extensions anyway.
That will have a very severe effect on interoperability.  Witness the
problem with RADIUS, where prior to VSA's (and for many years after),
certain vendors just picked parts of the standard attribute space and used
them in incompatible ways.

>22) 8.4.2 'the AAA protocol must support delivery of the following types
>of accounting/auditing data: ... All parameters used to authenticate a
>session ... Details of the authorization profile that was applied to the
>session..." - isn't this a potential security hole? The requirement
>should be very clear abut what data should and should NOT be passed in
>the accounting data.

Yes, I should have been more explicit.  Certainly things like user passwords
should not be sent in accounting data.

+        Mark Anthony Beadles         +
+    [email-masked]     +
+ Vox 614.565.1308 Pager 888.660.8427 +

---

From: "Bernard Aboba (Exchange)" <[email-masked]>
Date: Wed, 27 Oct 1999 12:39:06 -0700

>solution ever be considered AAA compliant?

This issue is partially addressed in draft-aboba-acct-02.txt. The
conclusion in that draft is that SNMP v3 (with the right MIBs) 
*can* meet accounting requirements for a number of scenarios, 
particularly with the NMRG extensions. As a result, it is expected
that SNMP will remain popular in accounting applications for
the foreseeable future. 

However, SNMP v3 cannot meet all the requirements -- particularly 
requirements for low-latency inter-domain event-driven accounting. See the
draft for a detailed explanation of what accounting capabilities
SNMP v3 can and cannot support.