Subject: mboned: Comments to draft-ietf-mboned-rac-issues-03.txt (long message)

From: "JACQUENET Christian RD-TCH-REN" <[email-masked]>
Date: Wed, 3 May 2006 16:35:49 +0200

Dear mboners,

Please find herein some comments about the draft mentioned below.

1. General comments:

1.1. I must admit I'm quite confused about the actual goals of the draft, especially because: 

(1) it's closely related to another document (draft-ietf-mboned-maccnt-req-04), and I was wondering if the discussion could not take place in this other document instead of quoting sentences in the RAC draft (sections 4.1 to 4.7 in particular),

(2) I don't think the taxonomy effort on a per "architecture" basis is realistic not only from a *service* standpoint (where services that rely upon the activation of a set of elementary capabilities including multicast-inferred capabilities will be deployed over (network) infrastructures that will presumably mix the "architectures" depicted in the RAC draft), but also from a (network) *design* standpoint, where aggregation architectures generally rely upon a combination of L2 and L3 technbologies. Not to mention mobile users who may want to access TV broadcasting services, yielding additional access conditions and design issues. 

If the goal of the draft is to solicit the IETF community about the (security) issues raised by deploying multicast-based services, then I would rather encourage the publication of a ture, service-wide, requirements draft that would not only describe concerns about the identification and the authentication of receivers, but also global, systemic concerns about the design, the deployment and the operation of multicast-based services. This draft could be organized into 4 "meta-domains", such as "architectural considerations" (e.g. addressing, routing, tunneling issues), "QoS considerations" (from a forwarding standpoint (e.g. specification of a multicast-based DiffServ policy (PHB enforcement)), routing standpoint (e.g. specification of a multicast traffic engineering policy), and monitoring standpoint (e.g. specification of relevant metrics and their respective metrology to check how efficient a multicast-based policy is enforced), "security considerations" (which would probably encompass some of the material briefly described in this draft, including receiver-centric AAA policies), and "management considerations" (as per the classical FCAPS decomposition, including the specification of configuration policies that would allow dynamic/automated configuration tasks, as part of the enforcement of a set of policies applied to multicast-based services).

1.2. I think the notion of "non commercial situations" should deserve some elaboration, especially because I don't see in the RAC draft what's really specific to the so-called "commercial situations" that could not be applied to "non commercial situations" (if any).

2. Detailed comments:

2.1. Abstract section: 

* The notion of "common requirements" should deserve some elaboration, since the current wording seems to assume that such requirements are well-known or shared by the service providers' community. And I don't think this is the case, especially because such requirements may be service-specific (e.g. you don't design a VOD service like you would design a TV broadcasting services, even though both services may rely upon a multicast transmission scheme), if not network-specific (e.g. aggregation architectures may rely upon a wide set of technologies - xDSL, Gigabit Ethernet, packet-based mobile networks) hence yielding different requirements.

* This section already introduces potential options (so-called "architectures") that may address some issues/requirements which are yet to be defined/elaborated. I think such a (requirements) document should avoid the classical pitfall which consists in writing requirements having in mind the solutions that may address them. This is why I'm not too sure about the need for "analyzing" a set of architectures *separately*. Once again, I don't think this taxonomy effort is realistic, and my guess is that this is the kind of analysis that would rather favor the publication of an applicability statement draft.
* I don't understand the last sentence of the abstract section.

2.2. Section 1:

The notion of "receiver access control" should deserve some elaboration, especially because some of the following sections introduce accounting notions which, IMHO, are not strictly RAC-specific notions per se. Rather, my understanding of "receiver access control" is manifold, such as:
* The ability to check whether a given receiver is entitled to access a network/a service according to the contents of its profile, that is the information that defines the kind of service he has subsrcibed to (e.g. the TV bouquet the correspondign customer has selected, the thematic contents (movies, sports, etc.) such a customer can access, etc.),
* The ability to prevent any malicious attack that may not only jeopardize the quality of the service provided to the receiver, but also the receiver itself,
* The ability to check whether a given source is entitled to send traffic (especially within the context of a source/receiver heuristic),
* The ability to make sure that a filtering policy enforced by a receiver (IGMPv3-based, for example) is compatible with the filtering policy enforced by the service (or the content) provider,
* The ability to check whether the receiver is consuming the right amount of bandwidth (e.g. the access rate defined in his contract), vs. The natur eof the service he has subsrcibed to,
* Etc.

2.3. Section 2.1:

I can understand the difference between a receiver and a user, but it seems that the draft finally makes the confusion between the two notions (see for example sections 6.6 (I don't think the *user* is supposed to refresh the Join, rather the *receiver*, as per the definitions of section 2.1. Likewise, I don't think the *user* needs to be notified with the result of a Join request: the user needs to access the content he requested in the most efficient and reliable way instead).

2.4. Section 2.2:

* DRM stands for Digital Rights Management (as correctly put in section 4.8, BTW)

2.5. Section 3:

* What's a "commercial multicasting system"?: it seems there is a confusion between means (multicast) and goals (delivering contents with the appropriate level of quality). I would rather reword like "....of a commercial service that can benefit from the multicast transmission scheme, such as TV broadcasting, etc. Such requirements include (but are not necessarily limited to) the need for relibaly delivering contents to the receivers with the appropriate level of quality, the need for delivering contents to the receivers whatever the nature and the rate of their access technologies, the need for delivering contents to the receivers, may they be in motion.

* The notion of "responsibility" should deserve some elaboration. For example, I make a difference between an operator who's responsbile for managing a network device on a daily basis and a network provider who's the administrative entity entitled to manage a set of netwok devices at the scale of a BGP domain.

* There are some gratuitous assumptions ("Similarly commercial network...) which are highly arguable in a business context where operators tend to establish close partnerships (if not acquisitions) with content providers. I would get rid of this kind of wording, also because I don't think it's in the scope of this kind of document.

2.6. Section 4.1.

* Another gratuitous assumption about the need to control the number of groups. I think this is arguable from a service standpoint: e.g. in the case of TV broadcasting services, customers select one or more TV bouquets, and service providers are supposed to deliver the corresponding contents whatever the zapping behavior and:or the interest of the receivers. The point may be valid from a design standpoint but then, I don't think this is in the scope of this document.

* I would rather use the notion of "source" (or multicast source) rather than "multicast server".

2.7. Section 4.5.2.:

[not to mention I don't see the point of the previous sections that explicitly quote some sentences of the maccnt draft]

I don't think this is the role of the so-called "edge router" (what is it, BTW? A DSLAM? A DR? Else?) to *maintain* user-specific information. I would rather think about the support of some kind of AAA agent that would query a AAA server to retrieve such information.

2.8. Section 4.8:

On the contrary, I think DRM is one of the most curcial issues we're currently facing in France. And I think this is the kind of issue that deserves some elaboration (but maybe not in this draft as it is currently organized - see the "general comments" section of this meesage.

2.9. Section 5.1.:

I think the figure (which, BTW should be numbered, like the others) is oversimplifying the exchanges, and this may yield confusion.

2.10. Section 5.2.:

I don't think IGMP nor MLD were designed to perform receiver authorization. I therefore don't think the corresponding analysis is meaningful. I would rather focus on the *requirements*.

2.11. Section 5.3.:

IMHO, this example could be viewed as an instantiation of the case depicted in section 5.3.

2.12. Section 6.1. (last paragraph: "Multicast encryption"): 

This is the kind of scenario that yields serious scalability and performance sisues, and I think this should be mentioned somewhere.

2.13. Section 6.3:

It seems to me there is a confusion between "receiver" and "user" here (L2/L3 authentication and IGMP/MLD): I don't see *how* a switch or a router can actually distinguish between users. But I've got no concerns if we're talking about receivers instead (as per the definitions provided in section 2.2).

2.14. section 6.4:

This is the first "AAA server" occurrence of the draft. I think this is the kind of wording that should deserve some elaboration, and I also do not understand how the last sentence ("however...") of this paragraph can be so affirmative. I'm awrae of some technologies that provide this kind of capabilities to enforce a QoS policy in the access.

2.15. Section 6.6:

I don't see how an ACL can be *deactivated* (unless manually?), especialluy considering the Join Refresh trigger mentioned in the sentence.

2.16. Section 9:

[I dont see the point of section 6.7]

The notion of "security performance" should deserve some elaboration because the current wording is highly arguable at least from a scalability standpoint.

3. Conclusion:

* IMHO, this draft needs serious rewording before it can be submitted to the IESG for review.
* I'm ready to contribute to a requirements document as briefly described in section 1 of this message.

Cheers,

Christian.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Hiroshi Ohta
Envoyé : mardi 2 mai 2006 16:59
À : [email-masked]
Cc : Dan Romascanu; David Kessens; [email-masked]
Objet : mboned: WGLC for draft-ietf-mboned-rac-issues-03.txt

Working group,

This note starts the WG Last Call for comments on draft-ietf-mboned-rac-issues-03.txt, "Issues Related to Receiver Access Control in the Current Multicast Protocols".  
It can be found on 
	
http://www.ietf.org/internet-drafts/draft-ietf-mboned-rac-issues-03.txt

The document's proposed status is Informational.

Please review the document carefully, and send your feedback to the list.  Please also indicate whether or not you believe that this document is ready to go to the IESG. 

This Last Call will end on 17 May 2006 at 1400 EST (UTC/GMT-4).

Thank you.
Hiroshi and Marshall

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