Subject: [MBONED] Responses to the maccnt requirement's draft discuss items

From: Hiroaki Sato <[email-masked]>
Date: Mon, 30 Jul 2007 13:49:38 +0900

Dear MBONED WG,

As I said in Chicago meeting,
I'm sending our proposed responses to IESG's discuss items of
draft-ietf-mboned-maccnt-req-04 (multiAAA requirements).
Do you have any comments and suggestions?

Best regards,
Hiroaki
======================
1)	Jari Arkko:
url:https://datatracker.ietf.org/idtracker/ballot/2087/

## Jari Arkko's Comment A: 
Discuss [2006-12-14]:
> However, multicasting 
> according to current standards (e.g., IGMPv3[1] and MLDv2[2]) has 
> drawbacks compared to unicasting when one applies it to commercial 
> services.  Accounting of each user's actions is not possible with 
> multicasting as it is with unicasting. 

This statement is not universally true. For instance,
in DSL or cellular or any other environment with a
point-to-point nature, it *is* possible to track
what each user does with multicast. More importantly,
however, there are application-level multicast
controls (such as access to the decryption keys)
that deal with the most pressing problems in
content delivery. Such tools appear to be
a much better fit to the problem at hand --
the ISP should be checking if they have a
subscriber X and whether that subscriber
is within his bandwidth limits, NOT whether
the subscriber is entitled to look at
football. This is the task of an application
provider. Of course, ISP and application provider
may exist in the same company... but marrying
the routing and forwarding technology to
end-to-end content authorization process
would make it impossible to separate them.

## Authors' proposed response:

We do not believe network access control should be replaced by content encryption.  Additional non-mutually exclusive alternatives should be available. They should both be able to coexist for more robust security.
For many content providers to provide their contents over IP networks they desire not only that illicit users can decrypt their data, they often do not even want them to have access to it in the encrypted form (in case they can go back and decrypt later if keys are somehow later compromised. ) 
NSP does not want to let ineligible users waste large amounts of bandwidth:  for example encryption protects against content viewing but NSP desires protection against DoS attacks of ineligible users wasting network resourcesven if it is encrypted

## Jari Arkko's Comment B: 
> The requirements defined in this memo apply to solutions that  
> provide user separation either through physical separation  
> provided by dedicated access media between the user and multicast 
> router  (see  Fig.  1) or else through logical separation in cases 
> of shared physical access media (e.g. using VLAN). However, IP 
> multicast solutions with shared Layer 2 access media between the 
> user and multicast router and no logical user separation (e.g. 
> Ethernet with shared links and no VLAN) are out of scope of this 
> memo. 
> ...
> With current protocols (IGMP/MLD), the sender cannot distinguish 
> which receivers (end hosts) are actually receiving the information.  

I do not understand why, given the scope, the first hop router
simply cannot look up which interface this message came from
and determine whether the customer behind that interface
is allowed to use multicast/this particular stream/this
much bandwidth?

## Authors' proposed response:
When the owner of the first hop router and content holders are different entities, it is not scalable that the first hop routers manage access control lists for a huge number of users.
Additionally, it does not address portability nor does it address multiple users accessing through the same gateway.

## Jari Arkko's Comment C: 
> Since the CP and NSP are different business entities, they need to 
> share the revenue. 

That would be only one of the many business models. The
NSP could also be operating as a bit pipe, for instance.

## Authors' proposed response:
Even as a bit pipe, NSP does not want to let ineligible users waste much bandwidth.
Proposed wording
An NSP may have different contractual agreements with various CPs or various legal obligations in different locations.  One possible business relationship between a CP and NSP is that of a revenue sharing which could be on a per content/usage-base.  A solution should support varied billing and charging methods to satisfy both common legal and business/financial requirements to deploy multicasting services:  this requires accurate and near real-time accounting information about the end user clients' activity accessing the content services.

======================
2)	Brian Carpenter:

Discuss [2006-12-14]:
url:https://datatracker.ietf.org/idtracker/ballot/2087/

## Brian Carpenter's Comment A: 
3.1  Accounting Issues
...
     In other words, the current standards do 
     not provide multicasting with authorization or access control 
     capabilities sufficient to meet the requirements of accounting. 
     ... 
     This is the major reason why multicasting is only used for cases 
     where no user-based accounting capabilities are necessary.    

This is a circular argument. It's perfectly reasonable to argue that
some multicast applications need AAA, but where is the evidence that
lack of IP-level AAA has been the blocking factor? 

## Authors' proposed response:
Content delivery is the primary use case for multicasting. Content providers require accounting information from network service providers for their business.

Proposed new text:
It is envisioned that there are many large-scale content distribution applications transferred over IP-based networks that can leverage multicasting technologies to meet their scalability requirements for clients and data volume, and that some of these applications require user-based accounting capabilities similar to available with unicast networks. For example, accounting is needed if one wants to charge for distributed information on a non-flat-fee basis.

## Brian Carpenter's Comment B: 
I believe that the picture drawn in Fig. 2 is very restrictive.
The users need a AAA relationship with the content providers, but
it is not always correct to show the content providers inside
peer networks, with an NNI to the customers' NSP; they may well 
be outside all peer networks, with no network being part of the 
customer/provider relationship.

In summary I don't believe that this document describes generic
requirements; it describes requirements for a subset of deployment
models for which a network-based AAA solution may be appropriate.
Somehow this needs to be made clear in the title, abstract and
introduction. ## Authors' proposed response:

Agreed that not the case described in this document is 100% gener, however we believe that the case is common enough to warrant standards. We propose to clarify that these are not generic requirements by adding the following clarifications.

Proposals
Proposed new title: Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s)

Proposed new Abstract:
This memo presents requirements in the area of accounting and access control for IP multicasting.  The scope of the requirements is limited to cases that AAA functions are coordinated between Content Provider(s) and Network Service Provider(s). General requirements for accounting and admission control 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.  Finally, cases for Content Delivery Services (CDS) are described as application examples which could benefit from multicasting accounting and access control capabilities as described in the memo.
Proposed new first sentence to Intro: This memo defines requirements related to accounting, authentication and authorization (AAA) issues for multi-entity provider models in which the network service provider and content provider share a network node interface and cooperate to provide various AAA functions for purposes such as protecting and accounting for the access to content and network resources.  The requirements are generally not relevant to cases in which there is not a reason to share AAA functions between separate entities.

## Brian Carpenter's Comment C [2006-12-14]:
1. Introduction 
...
     It is proposed that this I-D be used as a 
     starting point for a discussion on these issues. 

This sentence seems unnecessary in an RFC. It also occurs
in the Abstract.

## Authors' proposed response:

We will strike that sentence from both the Abstract and Intro.

======================
3)	Ted Hardie:
 url:https://datatracker.ietf.org/idtracker/ballot/2087/

## Ted Hardie's Comment A:
Discuss [2006-12-13]:
The document says:

     In many commercial multicast situations, NSPs would like to be 
     able to precisely grasp network resource consumption and CPs would 
     like to be able to precisely grasp the content consumption by end-
     users.  Such information might be used for identifying highly 
     viewed content for advertising revenue, ratings calculations, 
     programming decisions, etc., as well as billing and auditing 
     purposes. Also content and network providers may wish to provide 
     users with access to their usage history. 

     To assemble such an understanding of end-user behavior, it is 
     necessary to precisely log information such as who (host/user) is 
     accessing what content at what time (join action) until what time 
     (leave action). 

The examples given (highly viewed content for advertising revenue, ratings
calculations,
programming decisions) do not match necessarily match the need to track
this information by user.  These decisions are commonly made in other
environments
based on aggregate data, which does not reveal individual user preferences.
This document  recommends this more extensive tracking rather than aggregrated
data,
but it does not justify the more intrusive tracking.  If the authors wish to
retain
this aspect of the recommendations, a section on privacy considerations should
be added to the security considerations.  Those should cover both authorization
models described in the follow-on sections.

## Authors' proposed response:

Proposed additional section
9.  Privacy considerations
     Any solution which meets these requirements should weigh the benefits of user-based accounting with the privacy considerations of the end user. For example solutions are encouraged when applicable to consider encryption of the content data between the content provider and the user in such a way that the Network Provider does not know the contents of the channel.

======================
4)	Bernard Aboba:

(Refered to by Russ Housley on https://datatracker.ietf.org/idtracker/ballot/2087/)

[AAA-DOCTORS] Review of draft-ietf-mboned-maccnt-req-04.txt
By From: Bernard Aboba <aboba at internaut.com>
Review of draft-ietf-mboned-maccnt-req-04.txt

## Bernard Aboba's Comment A:

Overall:  

Although this document mentions MSEC in Section 3.2, 
in a number of places it makes assertions that seem to 
ignore MSEC, or imply that it is deficient in some way,
without explaining why this is true. ## Authors' proposed response:

It is certainly not our intention to replace MSEC.  Indeed we see no reason that encryption can not and should not be done in addition to user-level access control.  One of our major concerns is the encryption alone does not prevent access to the data and the networks themselves.  

Proposed new section

8. Security Considerations 
      
Accounting capabilities can be used to enhance the security of  multicast networks by excluding ineligible clients from the networks.

These requirements are not meant to address encryption issues.  Any solution meeting these requirements should allow for the implementation of encryption such as MSEC on the multicast data.

## Bernard Aboba's Comment B:

One of the reasons that MSEC was developed was because
of the security issues inherent in attempting to authenticate
and account for usage via IGMP.   Since any listener on the 
path can access multicast traffic,  access to content can't be
controlled by authenticating IGMP, it can only be controlled 
by encrypting the content.  While Section 3.3 talks about
why the document does not apply to shared media,  the
use of shared media multicast is quite widespread so that
this restriction seems quite severe. 

This document talks about usage-based billing. As noted in RFC 2975, 
there may be legal requirements associated with usage-based billing, 
such as requirements on the reliability of accounting transport as well
as the accuracy of usage determination.  It was not clear that  this 
document takes those issues into account, and as a result, solutions based 
on this requirements document may not pass scrutiny. 

## Authors' proposed response:

Propose adding this  to  "5.1.2.1 Accounting Requirements"
Any solution addressing the requirements of this draft should consider the Interdomain accounting issues presented in rfc2975.  It is especially important to the CP and NSP as separate administrative entities can not be assumed to trust one another.  The solution should be robust enough to handle packet loss between entity domains and assure for data integrity. In addition any solution should take into consideration common legal or financial requirements requiring confidential archiving of usage data.

## Bernard Aboba's Comment C:

More detailed comments
----------------------------------

"    IP multicasting is becoming widely used as a method to save 
     network resources such as bandwidth or CPU processing power of the 
     sender's server for cases where a large volume of information 
     needs to be distributed to a large number of receivers."

While IP multicasting always saves resources on the sender, on wireless
link it does not necessarily save network resources, because multicast 
traffic may  have to be sent at lower rate than unicast traffic.   For example, in 
IEEE 802.11 networks an Access Point will send multicast/broadcast traffic 
at the lowest supported rate, in order to be assured of reaching all 
potential receivers, whereas unicast traffic can be sent at the highest rate that 
can be supported by link conditions.   As a result, sending a packet via 
link layer multicast may consume more resources than replicating the same packet via 
link layer unicast.  

As an example, consider an IEEE 802.11n network with a minimum supported 
rate of 1 Mbps, and a maximum supported rate of 200 Mbps.  In this 
situation, a frame sent via link layer multicast would consume as much network 
resources as 100 frames sent at the maximum rate.  Unless there were 100 potential 
receiver, it would therefore make more sense to send the packet via 
unicast.  Of course these considerations do not apply on wired links where multicast traffic is sent at the same rate as unicast traffic. 

     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. These limitations have prevented the
    widespread deployment of multicasting.
    
## Authors' proposed response:

We agree that not all applications are so, however, we believe there are many cases, such as IPTV, in which the quality demand from consumers requires equivalent data rates whether using unicast or multicast.  Furthermore these applications have far more than 100 potential receivers in our experience and from what we have heard discussed by others in mboned.

Proposed text:
"    IP multicasting is becoming widely used as a method to save 
     network resources such as bandwidth or CPU processing power of the 
     sender's server for cases where a large volume of information 
     needs to be distributed to a very large number of receivers at a given data speed."

## Bernard Aboba's Comment D:
I believe that it is an exaggeration to state that accounting issues are 
the primary reason why multicast has not been deployed on a widespread 
basis.   I say this as someone who was involved in one of the earliest 
commercial multicast service offerings.   In my experience, there were 
quite a few issues that were as or more important, including problems of 
traffic engineering, diagnostics, user-interest, etc.  Later on the 
document does talk about the "on demand" versus other multicast delivery 
mechanisms, but I think the document could be more balanced here. 

    Then, the 
     multicast router replicates the data to any link which has at 
     least one client requesting the information.    In this process, no 
     eligibility check is conducted.  Any client can receive information 
     just by requesting it.  In other words, the current standards do 
     not provide multicasting with authorization or access control 
     capabilities sufficient to meet the requirements of accounting. 

Given the discussion of MSEC in Section 3.2 I do not understand
this statement.   If MSEC is used, why wouldn't it be possible to
authenticate receivers and account for usage? 

    This is the major reason why multicasting is only used for cases 
     where no user-based accounting capabilities are necessary.    

I also don't understand this statement given the discussion of MSEC. 
Are you saying that MSEC is inadequate or undeployable?  If so, then
the reasons should be stated.

## Authors' proposed response:

See response to Russ Housley regarding MSEC.  We do not wish to replace MSEC.  This could be in addition.  MSEC prevents the usage of data by encryption but not the actual access to data and access to the network.  With just MSEC a malicious user or device with faulty software could prevent users who have the right to access data from access it by a DOS attack.

## Bernard Aboba's Comment E:

Section 3.3

    "However, IP 
     multicast solutions with shared Layer 2 access media between the 
     user and multicast router and no logical user separation (e.g. 
     Ethernet with shared links and no VLAN) are out of scope of this 
     memo. "

Why is this out of scope?  As I understand it, virtually all wireless 
media fit within this category, as do technologies such as EPON.   Earlier 
an argument is made that the accounting functionality is more or less the
same for MSEC as opposed to other methods, so why not just say that
the IGMP-based 

## Authors' proposed response:
In our experiences, commercial NSPs separate users physically or logically. e.g. in the EPON case, users are separated by logical channels.
Therefore we put other cases out of scope.

## Bernard Aboba's Comment F:

Section 4

     Also, it is necessary to identify the source 
     (user) of each request (e.g., join/leave) for user accounting 
     purposes. 

Identifying the IP address originating a request is not the same thing as 
determining
the user.   

     With current protocols (IGMP/MLD), the sender cannot distinguish 
     which receivers (end hosts) are actually receiving the information.  
     The sender must rely on the information from the multicasting 
     routers. This can be complicated if the sender and routers are 
     maintained by different entities. 

I think you need to distinguish the inability to determine which 
receivers are receiving the information on a shared media (which will be
the case even with authentication).

## Authors' proposed response

Proposed additional text:
(1) User and receiver identification 
      
     The network should be able to identify each user when they attempt 
     to access the service so that necessary access controlling actions 
     can be applied.  Also, it is necessary to identify the user's receiver host information (e.g. IP) of each request (e.g., join/leave) for per host tracking 
     purposes. 

## Bernard Aboba's Comment G:

     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). 
      
     For comparisons sake, in the case of unicast this issue can be 
     resolved e.g. by using RSVP. 

Why is RSVP not relevant to the multicast case (particularly since it
supports authentication)? 

## Authors' proposed response

Further study in solution development is necessary to clarify if modified RSVP is suitable for use in multicast AAA. CP can not receive user information by current RSVP because RSVP messages are merged.

## Bernard Aboba's Comment H:

     The network may need to control the combined bandwidth for all 
     groups at the physical port of the edge router or switch so that 
     these given physical entities are not overflowed with traffic. 

Why is this a AAA requirement and not a QoS requirement? 

## Authors' proposed response
The stated purpose of this memo is protect both content and network resources.

## Bernard Aboba's Comment H:

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

Why is this a AAA requirement (as opposed to a requirement for
management functionality on a switch or router)?  

     To assemble such an understanding of end-user behavior, it is 
     necessary to precisely log information such as who (host/user) is 
     accessing what content at what time (join action) until what time 
     (leave action).  The result of the access-control decision (e.g. 
     results of authorization) would also be valuable information.

## Authors' proposed response:

It is up to the solution as to what servers or devices on the network would provide this logging function.  No matter what role a AAA plays it is AAA related functionality (authentication for user identification and accounting logging) 

## Bernard Aboba's Comment I:

If we are talking about usage-based billing, we will need more than 
this.  We will need some assurance that the accounting data itself
is being transported reliably.  There may be also issues arising
from loss of IGMP join/leave messages.  For example, if a leave
is lost, will a user be charged inappropriately? 

## Authors' proposed response:

Same as above we propose adding this  to  "5.1.2.1 Accounting Requirements"
Any solution addressing the requirements of this draft should consider the Interdomain accounting issues presented in rfc2975.  It is especially important to the CP and NSP as separate administrative entities can not be assumed to trust one another.  The solution should be robust enough to handle packet loss between entity domains or for loss of join/ leave messages and assure for data integrity. In addition any solution should take into consideration common legal or financial requirements requiring confidential archiving of usage data.

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

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