Subject: Re: [MBONED] I-D Action:draft-ietf-mboned-multiaaa-framework-10.txt

From: "ALTOM, MARK W (ATTLABS)" <[email-masked]>
Date: Sat, 13 Feb 2010 07:39:39 -0500

Hiroaki,
Here a few notes that we had on AAA and Admission Control Framework for
Multicasting (draft-ietf-mboned-multiaaa-framework-10).

1.  Is there a mechanism to prevent the sharing of authorization (e.g.,
sharing an S,G among end users)?

2.  Section 4.1.1 states that "...NSP will forward multicast traffic
towards the user only when the NSP has 1) made sure the user is entitled
to access the network resources operated by the NSP, 2) received a
confirmation from the CP that the user is entitled to access the content
and (possibly) 3) determined that the network resources (e.g.,
bandwidth) are sufficient to deliver the multicast traffic to the user
with the relevant level of quality."  When the third condition is not
satisfied and an end-user is prevented from joining the multicast
stream, should the CP be notified as part of accounting?

3.  The heading to Section 4.1.3 is incorrect.  It should be "A single
CP is connected to multiple NSPs."

4.  On page 19, the reference in the text to Figure 3 should be to
Figure 4.  The text should read:  "In the fully enabled model (Figure 4)
resource management and admission control is provided by MACF (Multicast
Admission Control Function)."

Please let us know if you have questions or if you need additional
details.
Thanks,
Mark Altom
Andy Huang
Tom Imburgia
Pat McCrink
Han Nguyen
Doug Nortz
AT&T Labs
(Contact Mark Altom: [email-masked]; +1 732 420 9073)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hiroaki Sato
Sent: Wednesday, August 05, 2009 1:07 AM
To: [email-masked]
Subject: Re: [MBONED] I-D
Action:draft-ietf-mboned-multiaaa-framework-10.txt

Marshall and all,

I submitted the muliticast AAA framework draft.
As I said at IETF75, we just extend the expire date and the cotent is
not changed.
We'd like chairs to check it again as Marshall told at the mboned
meeting.

Thank you
Hiroaki

> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the MBONE Deployment Working Group of the
IETF.
> 
> 
> 	Title           : AAA and Admission Control Framework for
Multicasting
> 	Author(s)       : T. Hayashi, et al.
> 	Filename        : draft-ietf-mboned-multiaaa-framework-10.txt
> 	Pages           : 22
> 	Date            : 2009-08-04
> 
> IP multicast-based services, such as TV broadcasting or
> videoconferencing raise the issue of making sure that potential
> customers are fully entitled to access the corresponding contents.
> There is indeed a need for service and content providers to identify
> users (if not authenticate, especially within the context of
> enforcing electronic payment schemes) and to retrieve statistical
> information for accounting purposes, as far as content and network
> usage are concerned.  This memo describes the framework for
> specifying the Authorization, Authentication and Accounting (AAA)
> capabilities that could be activated within the context of the
> deployment and the operation of IP multicast-based services.  This
> framework addresses the requirements presented in "Requirements for
> Accounting, Authentication and Authorization in Well Managed IP
> Multicasting Services" [I-D.ietf-mboned-maccnt-req].  The memo
> provides a basic AAA enabled model as well as an extended fully
> enabled model with resource and admission control coordination.
> 
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework
-10.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
>
------------------------------------------------------------------------
> 
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

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

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

---

From: Hiroaki Sato <[email-masked]>
Date: Thu, 18 Feb 2010 21:09:26 +0900

Mark,

Thank you for your draft review and feedback.  I will respond inline.

Hiroaki

> sharing an S,G among end users)?

-> Our assumption is that the NSP identifies the user on L2 (such as 
VLAN or PPP) And it would be
problematic for NSP if more than two receivers for the same user 
accessed the same channel and one
is accepted but the other is rejected on L2 or L3.   Prevention of 
unauthorized content sharing could be
handled on the application layer by the CP: e.g. could distinguish among 
receivers and distribute encryption
keys so that non-authorized receivers can not make use of the content.

Do you have any ideas related to preventing the sharing of 
authorization?  Do you have any proposals of
how the NSP might effectively distinguish among receivers on the same 
line (is it necessary)?

> stream, should the CP be notified as part of accounting?

-> Content delivery starts after 2 conditions are met 1) the CP confirms
authorization and NSP confirm admission control (possibly including
network resource check, etc.)
Our assumption is that NSP will send an accounting start notification
once the traffic delivery starts. Therefore as the draft is now no
notification would be sent in the case of access being denied because of
access resource issues. Do you think a notification in the third case
should be included?

> CP is connected to multiple NSPs."

->It's a typo. we will correct it.

> Admission Control Function)."

->It's a typo. we will correct it.