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

Hiroaki Sato <satou.hiroaki@lab.ntt.co.jp> Mon, 08 March 2010 07:46 UTC

Return-Path: <satou.hiroaki@lab.ntt.co.jp>
X-Original-To: mboned@core3.amsl.com
Delivered-To: mboned@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FECA3A693F for <mboned@core3.amsl.com>; Sun, 7 Mar 2010 23:46:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level:
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfqXjF5kr8Tn for <mboned@core3.amsl.com>; Sun, 7 Mar 2010 23:46:31 -0800 (PST)
Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id 6A2B63A68CF for <mboned@ietf.org>; Sun, 7 Mar 2010 23:46:31 -0800 (PST)
Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.3/8.14.3) with ESMTP id o287kVt8011462; Mon, 8 Mar 2010 16:46:31 +0900 (JST)
Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id ABA435E64; Mon, 8 Mar 2010 16:46:31 +0900 (JST)
Received: from imh.m.ecl.ntt.co.jp (imh0.m.ecl.ntt.co.jp [129.60.5.146]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 96CE25C66; Mon, 8 Mar 2010 16:46:31 +0900 (JST)
Received: from neho-PC ([129.60.182.11]) by imh.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id o287kL7Z002601; Mon, 8 Mar 2010 16:46:31 +0900 (JST)
Received: from 127.0.0.1 ([127.0.0.1]) by neho-PC (JAMES SMTP Server 2.3.1) with SMTP ID 478; Mon, 8 Mar 2010 16:42:36 +0900 (JST)
Date: Mon, 08 Mar 2010 16:42:35 +0900
From: Hiroaki Sato <satou.hiroaki@lab.ntt.co.jp>
To: "ALTOM, MARK W (ATTLABS)" <ma697r@att.com>
Message-ID: <4B94AA6B.3010006@lab.ntt.co.jp>
In-Reply-To: <3580159D7E3D824780C0B52AFC6D32E403264879@misout7msgusr7c.ugd.att.com>
References: <20090805044502.1510F3A6DA3@core3.amsl.com> <4A791383.9040503@lab.ntt.co.jp> <3580159D7E3D824780C0B52AFC6D32E40326481F@misout7msgusr7c.ugd.att.com> <3580159D7E3D824780C0B52AFC6D32E403264824@misout7msgusr7c.ugd.att.com> <4B7D2DF6.5050201@lab.ntt.co.jp> <3580159D7E3D824780C0B52AFC6D32E403264879@misout7msgusr7c.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
Cc: mboned@ietf.org
Subject: Re: [MBONED] I-D Action:draft-ietf-mboned-multiaaa-framework-10.txt
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mboned>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Mar 2010 07:46:32 -0000

Mark,

Thank you for your information.
I'm looking forward to hearing such information in the IETF.

It's difficult for NSP (L3 provider) to identify receivers.
NSP has receiver information only about source addresses of IGMP/MLD 
reports.
When a user has a home router, it looks like a receiver from NSP and NSP 
don't know actual receivers.
I think the NSP can only control of consuming NSP's network resources by 
a user.

Thank you,
Hiroaki

> Hiroaki,
>
> Please see below:
>
>>
>> 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)?
>>
>
> ->  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)?
>
> In investigating this issue, we uncovered some AT&T intellectual
> property that addresses preventing the sharing of authorization
> among end-users.  We are working with AT&T legal to determine
> the licensing conditions for this intellectual property.
> We will be filling an intellectual property disclosure as
> soon as possible with the IETF.
>
> Mark Altom
> Andy Huang
> Tom Imburgia
> Pat McCrink
> Han Nguyen
> Doug Nortz
> AT&T Labs
> (Contact Mark Altom: ma697r@att.com; +1 732 420 9073)
>
>
>


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