Subject: mboned: comments on draft-ietf-mboned-maccnt-req-01

From: Pekka Savola <[email-masked]>
Date: Sun, 6 Nov 2005 20:02:13 +0200 (EET)

The division of work between this and the issues document is not yet clear. 
It seems that this one is meant to be a requirements document (with
application-specific example in section 5).  For that, there's quite a bit
text that's too assumptive of the solution, and this needs to be reworded or
removed (I've mentioned some of those in the editorial comments below).

I'd also like to see the word "requirements" or "goals" mentioned
in the title, abstract and the Introduction.

In the requirements, it might also be illustrating to describe briefly
(e.g., 1-2 sentences) how the requirement is satisfied in unicast content
distribution.

substantial
-----------

   3.2  Relationship with secure multicasting (MSEC)

      In many cases, content encryption (e.g. MSEC) is an effective
      method for preventing unauthorized access to original content (in
      other words, the ability to decode data to return it to its
      generally useable form.)  This I-D presents requirements for
      multicasting networks in the areas of 1) access control to prevent
      unauthorized access to the network, and 2) accounting to grasp user
      activity.  It is not the intention of this I-D to propose
      alternatives to encryption.   Access control, accounting and
      encryption are separate technologies.  The implementation of any of
      these technologies does not preclude the use of the others.

==> The two last sentences seem like a bit of hand-waving.  While encryption
and AAA in some level are separable, AAA functions are needed when figuring
out for whom to encrypt (i.e., you need to know something about the
recipients, which might or might not require AAA technology, etc.)  So, I
think the text needs a bit of tweaking.  Maybe something like the follows
could be a start?

      In many cases, content encryption (e.g. MSEC) is an effective
      method for preventing unauthorized access to original content (in
      other words, the ability to decode data to return it to its
      generally useable form.)

      This I-D presents requirements for
      multicasting networks in the areas of 1) access control to prevent
      unauthorized access to the network, and 2) accounting to grasp user
      activity.

      The functional requirements do not require content encryption
      although it might solve some of them.  At this point, it is not yet
      clear whether encryption would be part of a solution and if so, what
      other components (if any) would also be required.

...

      (2) Issue of network resource protection

      In order to guarantee certain QoS it is important for network
      providers to be able to protect their network resources from being
      wasted, (either maliciously or accidentally).

==> "What Would Unicast Do?"  It seems to me that content distribution using
unicast doesn't deal with this problem either -- if so, I don't think it
would be fair to require it for multicast.  If the user wants to waste
network bandwidth, there are plenty of unicast ways to do it...

      (2.3) Control mechanism of number of groups delivered from a
           physical port of edge router and switch

      In order to enable an NSP to guarantee a certain level of QoS to
      the CP and the receivers, it is important that the NSP can control
      the number of groups delivered from a physical port of an edge
      router and a switch so that the combined bandwidth between content
      servers and multicast routers can be within the limit.

==> the same as above: how is this achieved in unicast content distribution
today?  Is this a strict requirement?

      (4) User authorization

      The network should be able to authorize a user's access to content
      or a multicast group, so as to meet any demands by a CP to prevent
      content access by ineligible users.  Also, the NSP does not want to
      waste their network resources on ineligible users.

==> see above -- the users can waste network resources in so many ways that
having a strict requirement to preclude it here doesn't seem convincing.

      (9) Admission control for join action

      In order to maintain a predefined QoS level, an edge router should
      not accept a consequent "join" after a "leave" until the
      termination of the stream of the multicast group which was "left".
      This is essential to protect against e.g., multicast denial of
      service (DoS) attacks.

==> how is this handled in unicast content distribution?  Is the user
prevented from ordering multiple UDP feeds of content simultaneously?
As such, I don't think this is a DoS attack prevention mechanism -- if
anything, this is just a way to ensure that the user doesn't shoot itself in
the foot.  But in any case, this is a difficult requirement.  How do you
define, "consequent"?   Consider the case where one household has two people
watching different content -- is the text assuming that each house can only
get one stream at a time, otherwise the link fills up?

      (10)  Channel Leave Latency

==> aside from the DoS attack, I think this requirement is pretty much
similar to (9) -- I'd remove 9 and put the text (if any) in this section.
In particular,

     Leave latency impacts :

      i. Acceptable end-user experience for fast channel surfing.

      In an IP-TV application, users are not going to be receptive to
      slow response time when changing channels.

==> you don't spell out why you're interested in leave latency instead of
join latency: you assume that to prevent user from shooting himself in the
foot, the old group needs to be left before joining the new one.

      The NSP-CP model represents a multi-domain AAA environment. There
      are plural cases of the model depending on the trust relationship
      between the NSP and CP, and additional service requirements such as
      a certain QoS level guarantee or service/terminal portability.

==> so, what's the solution here?  Who's doing AAA here?  Does the NSP have
an AAA server which is proxied to an AAA service of each CP or something?

editorial
---------

      This Internet Draft (I-D) describes problems in the area of
      accounting and access control for multicasting.  General
      requirements for accounting capabilities including quality-of-
      service (QoS) related issues are listed.  This I-D assumes that
      these capabilities can be realized by functions implemented at
      edges of a network based on IGMP or MLD.

==> remove the last sentence (and similar in Introduction) -- this sounds a
bit assumptive, and a requirements document shouldn't be that.

By such functions,
      information obtained from edge routers would be logged in a
      dedicated database.

==> same here, remove. (These same issues in Introduction)

      IP multicasting can be used to distribute free material efficiently,
      but there are limitations to multicasting in usage models where
      usage accounting is necessary, such as many commercial applications.
      Although multicasting has already been used in several applications,
      in many cases it is used in such a way that accounting is not
      necessary.

==> I think the second sentence just duplicates what the first one said but
from a different angle, and could be removed.

      On the other hand, in multicast communication as in Fig.1, the
      server just feeds its information to the multicast router.  Then,
      the multicast router replicates the information to distribute to
      the clients.  According to current standards (e.g., IGMPv3[1] or
      MLDv2[2]), the multicast router feeds the replicated information to
      any link which has at least one client requesting the information.

==> again, there's a lot of duplication and unnecessary (and even incorrect)
reference to IGMP/MLD, I'd reword this to:

      On the other hand, in multicast communication as in Fig.1, the
      server just feeds its information to the multicast router.  Then,
      the multicast router replicates the data to
      any link which has at least one client requesting the information.

...

   4. Functional general requirements for well managed IP multicasting

      It seems beneficial to use IGMP or MLD for access controlling in
      multicast networks.  However, from the considerations presented in
      section 3, there are issues in the following areas:

==> this is a requiremements doc, and there should not be such assumptions
or musing.  Remove or reword the first sentence.

     With current protocols, the sender cannot distinguish which
      receivers (end hosts) are actually receiving its information with
      current protocols (IGMP/MLD.)

==> some duplication, reword:

     With current protocols (IGMP/MLD), the sender cannot distinguish which
      receivers (end hosts) are actually receiving the information.
...

     In many commercial multicast situations, NSP would like to be able
      to precisely grasp network resource consumption and CP would like
      to be able to precisely grasp the content consumption by end-users.
      Such information might be used for "identifying highly viewed
      content"

==> remove " -marks

      Networks need database functions to realize user-based accounting
      through the accumulation of logs from edge routers.

==> this seems assumptive of a solution and should be removed.

      (14) Multicast replication
      The above requirements should also apply if multicast replication
      is
      being done on an access-node (e.g. DSLAMs or OLTs).

==> remove the extra line break

     give highest priority to the "first-come" users, and these should
     also be considered.
     In order to protect network resources against misuse/malicious
     access and maintain a QoS level, appropriate admission control

==> add line break.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/