Subject: mboned: comments on l-D: Access Right Distribution Protocol (ARDP)

From: Hiroaki Satou <[email-masked]>
Date: Sat, 29 Apr 2006 09:37:27 +0900

Alexandre and Marshall

I read the draft and have comments and questions as follows.

Higher-level Questions:

1) It would be helpful to have more detail on the requirements and 
assumptions that led to the creation of this protocol.
There must be a reason that this protocol chose multicast to deliver 
the access rights to the DSLAM instead of unicast.
Using multicast means that each DSLAM has to filter out the access 
rights for its relevant Client IDs from a potentially huge number of Client IDs.
There are questions to how large this can scale if there are frequent 
access rights changes (for example if there was a need to support a 
large number of on-demand types of subscriptions.
Or is a fine granularity to the timeslots for access rights for 
particular channels.

How does this scale if there are a large number of Operator ARDP 
Servers flooding access rights,  and each Operator ARDP Server has a 
large number of customers?
What are the processing implications for DSLAM ARDP Clients?

Is the reason for the choice of multicast related to a requirement of 
not wanting to share network related IDs/customer info with the TV 
operators? Or was it considered too complicated, expensive and slow 
for the TV operators to do a lookup of a table before granting Access Rights?

2)(Related to Q1 above) For trust reasons, it would seem that it 
should be mandatory that the multicasted Client IDs flooded by the 
Master ARDP and the multicast Access Rights from the OP_ARDP must not 
be received by the OP_ARDP servers. If this is so, it should be made explicit.

3)In section 2.3 Global operation flow, (b,c) is it correct that the 
purpose of flooding client IDs, is for the Master ARDP to distribute 
the association of client IDs and network physical IDs to the DSLAMs? 
If so, why is this not done by unicast to the appropriate DSLAM since 
the Master ARDP should know which DSLAM is responsible for which 
customer, and there should be no need for other DSLAMs to receive this info.

4)In section 2.3 Global operation flow, (b,c) what are the Access 
Rights that the Master ARDP is flooding?  Are these solely the 
Unencrypted TimeSlot Access Rights?

5)What is meant by "massive Access Rights" in Section 2. ARDP Overview

Detailed Comments/ Questions

----------

Introduction

"Set-Top-Box is considered as hostile equipement and the idea is to 
reduce to the max the action it may have"
Not sure what "hostile" means here.  I assume it means there is no 
trust? Needs more explanation

---------
2.2
"Only edge routing equipments can access the ARDP plane and 
Set-Top-Box one but without any routings nor forwardings rules 
between both planes"

possibly change to

"Only edge routing equipment can access the ARDP plane and Set-Top-Box plane;
  however no routings or forwardings rules may exist between the two planes."

---------
2.2
"One of its goales is to give full access to a TV Operator on streams 
it is responsible for."

suggested change

"One of the goals of the protocol is to give a TV Operator full 
control of access rights for the streams it is responsible for."

---------
3.2.7 "Formerly an Operator ID is a 32bit ..." and 3.3.2 "Specifies a 
TV Operator service, formerly these are ..."

I'm not sure what "formerly" means here

-------------

3.4.4. Unicast Source field, 3.4.5. Fallback Multicast Group field, & 
3.4.6. Fallback Unicast Source field

should specify if these are OPTIONAL or not

-------------
3.4.5. Fallback Multicast Group field, & 3.4.6. Fallback Unicast Source field

when are fallback addresses used?

-------------
5."- MUST sequencely flood ClientID before any Access Right related."

for me, meaning not clear

>Marshall,
>
> > Are you interested in having the Mboned WG adopt this draft as a WG
> > document ?
>
>Sure, in fact, I didn't found a dedicated place for TVoDSL, this is why
>I post into differents IETF WG having focus around draft topic.
>
>I submitted, after draft announcement, into the following IETF WG:
>mboned, msec, avt, magma, ipdvb.
>
> > I notice that you submitted it also to the IPDVB list, so I am cc'ing
> > the IPDVB chair.
> >
> > Are you familiar with the AAA access requirements draft :
> > http://www.ietf.org/internet-drafts/draft-ietf-mboned-maccnt-
> > req-04.txt  ?
>
>I will read it.
>
> > Upon a brief reading of your document, it seems that this document
> > and also
> > http://www.ietf.org/internet-drafts/draft-ietf-mboned-maccnt-req-04.txt
> > may impinge upon it.
>
>oh, maybe we can find a way to make all the work cohabit together. We
>just wanted to share the protocol we designed for TVoDSL access control.
>
>
>Best regards,
>Alexandre
>
>_______________________________________________________________
>user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
>web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Alexandre Cassen <[email-masked]>
Date: Thu, 11 May 2006 00:35:38 +0200 (CEST)

Hiroaki,

On Sat, 29 Apr 2006, Hiroaki Satou wrote:
> There must be a reason that this protocol chose multicast to deliver the 
> access rights to the DSLAM instead of unicast.

We chose multicast as ARDP vector for simplicity and scalability reasons. 
If we consider that a customer can roam from DSLAM to DSLAM it is a labor 
to maintain a central information system with updated customers DSLAM 
associations. Next if we consider that we run a very large number of DSLAM
(in our case thousands of them), unicast lake of scalability since we will
need to increase ARDP unicast server ressources according to the number of 
receivers, if we can loadbalance this part this introduce administration 
complexity and information system maintance task.

Previous paragraph are administration considerations, but one of the main 
reason is that we dont want to provide OP_ARDP with our backbone topology
(DSLAM). (which can give business informations with the number of current 
customers). OP_ARDP are just aware of ServiceID, ClientID and any other 
service plane informations they are running. We can imagine to introduce a 
third party ARDP server receiving OP_ARDP datagram and demuxing them via 
unicast to all backbone DSLAM, but this will be a labor to maintain such 
an architecture.

As simplicity adorators we chose multicast vector.

> Using multicast means that each DSLAM has to filter out the access rights for 
> its relevant Client IDs from a potentially huge number of Client IDs.

Yes, this was one of our main interrogation with the multicast design 
especially if we consider to use RSA signature to each datagram this will 
charge DSLAM CPU with sending point bandwidth. But on reveiving point, 
with a proper software design this is really not a problems. We are 
running RSA signature on all datagrams and ARDP plane vehicule around 10 
millions of right a day. The most consuming is RSA verify, but security 
has a cost :), otherwise can use other authentication (No auth or 
HMAC-MD5). The bottleneck is much more the information system database in 
charge with access right management.

> There are questions to how large this can scale if there are frequent access 
> rights changes (for example if there was a need to support a large number of 
> on-demand types of subscriptions.
> Or is a fine granularity to the timeslots for access rights for particular 
> channels.

In our use, we are playing with on demand subscription, customer request a 
channel subscription via TV and instantly an ARDP datagram is generated to 
the DSLAM, the operation is quite real-time.

> How does this scale if there are a large number of Operator ARDP Servers 
> flooding access rights,  and each Operator ARDP Server has a large number of 
> customers?

If I use the abbreviation used in draft-ietf-mboned-rac-issues-02.txt, CP 
are using NSP ressources. So potential CP customer range is borned by NSP 
customer. The bottleneck is much more the authentication used than 
protocol lookup.

> What are the processing implications for DSLAM ARDP Clients?

most consuming task is datagram authentication, ClientID filtering is 
really not a big deal since software design pattern can provide very 
efficient lookup.

> Is the reason for the choice of multicast related to a requirement of not 
> wanting to share network related IDs/customer info with the TV operators?

my words. For security and customer confidentiality, TV operator doesn't 
need to know the association between ClientID and low-level IP-Address (in 
my case). So ClientID flooding is done from master Operator side runing 
ARDP root server, then TV Operator just need to flood right to ClientID. 
TV Operator identify customer by ClientID into their namespace.

> Or 
> was it considered too complicated, expensive and slow for the TV operators to 
> do a lookup of a table before granting Access Rights?

NSP trust CP with PoP in its backbone, but for security reasons it 'must' 
protect its low-level topology. Especially when we consider that a 
customer can roam from dslam to dslam and that way change IP address. This 
is the job of NSP (Master ARDP server) to keep an updated ClientID<->IP 
Address association without the need to synchronize other CP (TV Operator) 
system. IMHO, CP job is CDS centralized, thus it manage customer 
informations needed to run its business so ClientID and ServiceID.

> 2)(Related to Q1 above) For trust reasons, it would seem that it should be 
> mandatory that the multicasted Client IDs flooded by the Master ARDP and the 
> multicast Access Rights from the OP_ARDP must not be received by the OP_ARDP 
> servers. If this is so, it should be made explicit.

Yes good point. OP_ARDP is just using multicast ressource for sending.

> 3)In section 2.3 Global operation flow, (b,c) is it correct that the purpose 
> of flooding client IDs, is for the Master ARDP to distribute the association 
> of client IDs and network physical IDs to the DSLAMs? If so, why is this not 
> done by unicast to the appropriate DSLAM since the Master ARDP should know 
> which DSLAM is responsible for which customer, and there should be no need 
> for other DSLAMs to receive this info.

this is an alternative yes. But for simplicity reasons and because 
ClientID flooding are marginal and small message we chosse multicast 
channel. As presented into section 5 ARDP Server, Master ARDP server can 
schedule a massive (all customer) ClientID flooding, for this need 
multicast is better (since we don't need to introduce complex lookup and 
mecanism to distribute ClientID to each DSLAM). For simplicity reasons we 
chose to use the same design as a reply to DSLAM flooding request.

> 4)In section 2.3 Global operation flow, (b,c) what are the Access Rights that 
> the Master ARDP is flooding?  Are these solely the Unencrypted TimeSlot 
> Access Rights?

Master ARDP has got a Master role, divided into Ordinary TV Operator and 
Root TV Operator. Master ARDP server is the NSP ARDP server and in our 
case a NSP can be a CP too :) for business deal it may run in proper.

> 5)What is meant by "massive Access Rights" in Section 2. ARDP Overview

hmm, yes, massive can be removed. Just didnt find a better term to 
illustrate the fact that Master ARDP server can flood right and right 
request to other OP_ARDP server.

> "Set-Top-Box is considered as hostile equipement and the idea is to reduce to 
> the max the action it may have"
> Not sure what "hostile" means here.  I assume it means there is no trust? 
> Needs more explanation

Yes, for us the security end on final equipment customer cant access, 
DSLAM in our case. "Hostile" is probably not the better term, this is just 
to illustrate that Set-Top-Box intelligence can be emulated by any other 
equipment, so if stream is received by Set-Top-Box inconditionnally 
(standard satellite model) and then Set-Top-Box perform security stream 
handling to present or not content to customer, this presentation decision 
can be emulated by any reversed engenired equipement or soft. If customer 
only receives streams it subscribed to, then there is no more possibility 
to reverse engenire any mecanism since there is no more mecanism (this is 
the concept of ARDP).

> ---------
> 2.2
> "Only edge routing equipments can access the ARDP plane and Set-Top-Box one 
> but without any routings nor forwardings rules between both planes"
>
> possibly change to
>

better yes.

> ---------
> 2.2
> "One of its goales is to give full access to a TV Operator on streams it is 
> responsible for."
>
> suggested change
>
> "One of the goals of the protocol is to give a TV Operator full control of 
> access rights for the streams it is responsible for."

Agreed

> ---------
> 3.2.7 "Formerly an Operator ID is a 32bit ..." and 3.3.2 "Specifies a TV 
> Operator service, formerly these are ..."
>

hmm... can be removed

> -------------
>
> 3.4.4. Unicast Source field, 3.4.5. Fallback Multicast Group field, & 3.4.6. 
> Fallback Unicast Source field
>

Agreed, they are OPTIONAL.

If a customer request a channel and DSLAM detect there is no access right 
for this customer, then DSLAM can choose to subscribe any advertising or 
teasing multicast ressource we refer to as "Fallback".

hmm yes, must reword this, just wanted to high light that a ClientID MUST 
be sent before any Access Right refering to this ClientID (if no ClientID, 
Access Right will not be stored).

Thanks a lot for your comments. As marshall suggested I read draft on 
rac-issues and multiaaa-framework. The current ARDP draft is too much 
centralized to DSLAM and need to be much more generic as most of people 
suggested here. I can make it more generic without any DSLAM/DSL related 
and using the abbreviations and term used in rac-issues and 
multiaaa-framework draft ? what do you think ?

Best regards,
Alexandre