Subject: Re: [Dime] Request for review of "AAA Framework for Multicasting"

From: Hiroaki Sato <[email-masked]>
Date: Thu, 13 Mar 2008 03:58:24 +0900

Hi all,

I'm resending the previous response to RADEXT comments for our 
draft,draft-ietf-mboned-multiaaa-framework-xx, because it may be dropped.

Thank you,
Hiroaki

> Mr Dekok,
> 
> Thank you for your detailed feedback on the "AAA Framework for 
> Multicasting" draft.  Last week we submitted a revised version of the 
> draft reflecting many of your suggestions.
> http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework-05.txt 
> 
> 
> A summary of changes:
> * In section 4.1 we broke explanations down into the different use cases 
> of multiple CP - multiple NSPs, single to multiple, etc.   The most 
> general case multiple CPs to mulitple  NSPs was described as a time 
> sequence and the other cases where compared to this most general case.
> 
> * Section 4.2 elaboration of NSP assigned userID vs CP assigned userID 
> was added.
> 
> * In sections 4.3, 4.4 and 4.5 were largely rewritten to clarify AAA 
> characteristics specific to multicasting
> 
> Below we respond to your feedback inline:
> 
>  > (1)  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?
> 
> Indeed, the intent is to give multicast-inferred examples so we have 
> decided to leave these definitions.
> 
>  > (2)  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.
>  >
> Agreed.  We propose to rename the section "AAA Framework in 
> Multicast-Enabled Envrionments" in a future revision.
> 
>  > (3)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.
>  >
> We removed the label "multicast data" as suggested.
> 
>  >
>  > (4)  Perhaps a time-sequence diagram would be useful, to replace the
>  > diagram in Section 4.1.
>  > (4)  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.
>  >
> 
> 4.1 was reorganized and rewritten to describe the following cases: 
> multiple CPs connected multiple NSPS, multiple CPs to a single NSP, 
> single CP to multiple NSPs and single CP to multiple NSPs. The most 
> general case multiple CPs to mulitple  NSPs was described as a time 
> sequence. Then the other cases were compared to the general case.
> 
> 
>  > (5)  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.
>  >
> 
> We revised this section to better explain what we mean by multiple UIDs 
> and distinguish between NSP assigned userIDs and CP assigned userIDs. 
> Security considerations about handling the IDs are also addressed.
> 
>  > (6)  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.
>  >
> 
> We added separate sections for each use case to section 4.1 to better 
> describe the relationships.
> 
>  > (7)  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.
>  > (8)  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.
>  >
> where appropriate we used the term userID
> furthermore we elaborated on CP-assigned user ID and NSP-assigned user 
> ID in section 4.2
> 
>  > (9)...
>  >    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.
>  >
> 
> Agreed.  We removed mention of the API from the framework in section 4.2
> 
>  >
>  > (10)
>  >   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.
>  >
> 
> Agreed, we deleted any definitions of the log format from section 4.3 
> and instead further clarified the contents of the messages themselves.
> 
>  > (11)...
>  >    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.
> 
> As indicated above 4.3 was rewritten.  The section now specifies 
> accounting issues specific to multicasting such as recording multicast 
> join and leave.
> 
>  > (12)
>  > ...
>  >    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.
>  >
> 
> this text was deleted.
> 
>  >
>  > (13)...
>  > 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?
>  >
> This section was revised to mention CP selection as a responsiblity of 
> the NSP.
> 
>  > (14)
>  > ...
>  > 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.
>  >
> 
> This section was greatly revised.  Mention of an API was removed.  More 
> detailed discussion of multicast-inferred bandwidth management was added 
> including traffic parameters of a multicast channel for admission 
> control which the NSP needs to know and the case of multicast and 
> unicast being provided on the same network.
> 
>  >
>  > (15)
>  > ...
>  >    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.
> 
> The text referred to above was deleted. Instead elaboration of 
> establishment of the connection conditioned on network resources and 
> channel requirements was added to section 4.5.
> 
>  > (16)
>  >   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.
>  >
> 
> We agree that such info needs to be provided but not necessarily in this 
> draft as it is not a Requirements document.
> 
> 
>  > (17)...
>  > 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?
>  >
> This does not introduce additional requirement for the AAA server.
> 
>  >
>  > (18)...
>  > 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.
>  >
> 
> We changed "caching" terminology to proxy terminology throughout the 
> document.
> 
>  > (19)
>  > ...
>  >    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.
>  >
> Agreed. We changed to "re-authenticate"
> 
> Thank you
> Hiroaki
> 

-- 
************************************
NTT Network Service Systems Lab.
Hiroaki Sato
TEL:0422-59-4683 (+81-422-59-4683)
FAX:0422-59-5636 (+81-422-59-5636)
************************************

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime