Re: Request for review of "AAA Framework for Multicasting"

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> A request for review has been received relating to the document "AAA
> Framework for Multicasting" which is under development within the MBONED
> WG.  The document is available for inspection here:
> http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework-04.txt

  One nit: The document formatting appears to be broken.  e.g. Page 12
is mostly blank.  This makes the document harder to read.

  I'm not sure why Section 2 defines the terms Accounting,
Authentication, and Authorization.  The document is already discussing
AAA issues, so familiarity with the three A's should be assumed.

  Perhaps the intent was to give examples of how AAA would be used in
this scenario?

  Section 4.1 is titled "Framework for multicast AAA".  This may lead
someone to conclude that the AAA protocol is being multicast.  I don't
think that's correct. The diagram in that section appears to confuse the
AAA process with the later multicast data.  My understanding is that the
request/response for AAA is unicast, and the data that is being accessed
is then sent via multicast.

  Perhaps a time-sequence diagram would be useful, to replace the
diagram in Section 4.1.

  The text in 4.1 is also awkward.  It contains a series of overlapping
conditionals for setting behavior.  The text should be expanded to
describe specific scenarios in detail from start to finish, rather than
discussing multiple scenarios simultaneously.  Adding a time-sequence
diagram for each scenario would be useful, too.

  Section 4.2 Multiple User IDs is confusing.  In AAA, each user id is
treated as a separate user.  This document should avoid the term "user
id", as it is easy to confuse with the term "user".  Instead, maybe
"access identifier" could be used.  The definition could be added to
Section 2.1.

  The relationships between the terms (1:N, M:N, etc.) should also be
included in the definitions in Section 2.1.  This lets the reader
immediately know the relationships, independent of their use-cases.  The
later discussion of use cases can then become clearer.

  Also, the document sometimes refers to "user", and sometimes to "user
id" in the same context.  (e.g. Section 4.1, "the user requests
content".)  Later, the document clarifies that the user may have
multiple user ID's.  This is confusing, because the document first talks
about users requesting content, and then switches to say no, it's not a
user, it's a user id.

  Instead, all discussion of access requests in the document should be
done using consistent terminology, such as "access identifier", rather
than "user".  In some cases, the user will map 1:1 with an access
identifier.  In others, it will be 1:N.

...
   The actual mapping rules for NSPs and CPs to map user IDs
   with the IDs in other provider domains is a matter for the
   providers.  A solution should provide an API between the
   providers to flexibly support various mapping methods.
...

  API's should be avoided.  Instead, the Chargeable-User-Identity (RFC
4372) should be used to map identifiers to users.  This is simpler,
scalable, and already deployed.

  Section 4.3:

...
   Standardization of the logs or messages to share content
   usage information is important to support a single NSP
   sharing accounting information with multiple CPs or a
   single CP receiving from multiple NSPs.
...

  The logs should not be standardized.  Instead, the contents on the AAA
messages should be standardized.

...
   This framework specifies an accounting API provided by the
   NSP and accessed by the CP to allow for sharing user-
   behavior and content-reception information between the NSP
   AAA and CP AAA. This accounting API should be configurable
   to allow the CP to request only the logging information it
   actually requires.
...

  Negotiation of the contents of accounting messages is not a normal
part of AAA.  This requirement may be unnecessary, OR it may be very
difficult to implement in existing AAA systems.

...
   When
   logging information is shared through the accounting API,
   it is important that the CP be able to match the user as
   described in the database operated by the NSP to the user
   as described in the database operated by the CP.
...

  This is already part of existing AAA systems.  I'm not sure it's
necessary to re-iterate this requirement here.

  Overall, Section 4.3 appears to re-state many common AAA requirements
for accounting.

  The document also spends a lot of time talking about "needs".  Is the
document a framework, a model, or a requirements document?  Or is it all
three?  The document should separate the model from the requirements
more explicitly.  The model should be discussed first, and then the
requirements listed second.

...
4.4 Access Control and CP selection by NSP

   When a NSP receives an access request from a user, it is
   necessary for the NSP to determine to which CP the request
   is to be directed. It is necessary for the NSP to ensure
   that it is not spoofed by an inappropriate CP or user.
...

  Doesn't AAA already do this?  What are the concrete requirements added
by this document?  Or is this document just introducing AAA concepts to
people more familiar with multicast issues?

...
4.5 API for Admission Control Information by NSP

   After authorizing a user request, the NSP may have further
   conditions for determining its admission control decision.
   MACCNT-REQ-draft defines requirements for providing the
   network capability to conduct admission control based on
   the network bandwidth usage status and bandwidth management
   policy. (MACCNT-REQ-draft, 4.2.2, 4.2.3 & 4.9) Such QoS
   measurement and policy mechanisms themselves are out of the
   scope of this memo.
...

  These mechanisms are defined (or are in the process of being defined)
in normal AAA.  This document could refer to AAA specifications that
meet its needs.

...
   However the NSP's AAA Server should be
   provided with an Admission control API that allows for
   interfacing so that additional conditions can be added to
   the admission control decision.
...

  I have no idea what this sentence means.  "allows for interfacing" is
extremely vague.  Also, AAA protocols do not provide for much in the way
of capability negotiation.  The authors should double-check the
requirements of this document against the functionality provided by an
existing AAA protocol such as RADIUS.  The requirements MAY be more than
existing protocols can satisfy.

  In general, AAA clients provide a set of information to the AAA server
in the access request, and the AAA server makes an accept/deny decision
based on that information.  AAA servers cannot negotiate for more
information.

  This document should define what information is available to the
participants.  It should discuss what information SHOULD be made
available by the AAA client to the AAA server, and what information MUST
be made available.

...
4.6 Access Control and Distinguishing of Users by CP

   The user ID and authentication information are forwarded
   transparently by the NSP so that the CP can distinguish the
   user, as well as authenticate and authorize the request.
...

  Does this impose requirements on the behavior of the AAA systems?  If
so, what?

...
4.7 Caching of AAA results

   An NSP should be able to cache AAA results based upon an
   agreement between the NSP and a CP.  The AAA cache would
   store information about permissions of a specific user to
   receive multicast data from specified channel(s) up to
   specified expiration date(s) and time(s).
...

  This is not a cache, and should not be referred to as a cache.
Instead, the NSP obtains a policy from the AAA server for a particular
session, and applies that policy to that session, for the duration of
the session.  The term "cache" should be deleted from the document entirely.

  Further:

...
   If such caching is implemented,
...

  The functionality described as a "cache" MUST be implemented.

...
   It should be possible for a CP to send unsolicited requests
   to the NSP to refresh or change the permissions for a user
   for specific channel(s).
...

  This is possible using existing AAA protocols.

...
   When a user is receiving multicast content and the
   permission is about to expire, the NSP may send a
   notification to the user client that his session is about
   to expire, and that he will need to re-connect. The user
   will have to reestablish a connection.
...

  In AAA terms, the user will have to re-authenticate, not re-connect.
There is no AAA "connection" between the user and the NSP.

  I have no comments at this time on Section 5.


  Overall, the document is very rough, and could use substantial
clarifications and editing.


  Recommendations:

- use consistent terminology throughout the document
- expand on the examples
- clearly separate model and requirements
- discuss model before requirements
- clarify requirements
- the authors need MUCH more familiarity with AAA systems
- the requirements need to be validated against AAA functionality

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>