Subject: mboned: Some more comments on mboned-rac-issues-03

From: [email-masked]
Date: Fri, 05 May 2006 11:41:32 +0100

Dear Authors,

I have some more comments on the draft regarding the comparisons of the
different architecture

1. In Section 6.1: “-L2/L3 authentication with ….with an ACL it is possible to
limit access of multicast group”.
By performing L2 authentication, a user only requests access to connect to the
network. This would not specify at any time that the user wants to either
Unicast or multicast. The ACL may be suitable only if it denoted whether a user
can access “any” multicast data or not, but may not be able to denote the access
rights for each multicast group/content (at the network side we would not know
who would like to access which multicast content).

2. In Section 6.1: The 2 architectures in 5.3 and 5.4 do not provide any access
control as the Routers cannot tap into the Unicast messages and hence it would
not limit any access when it receives any Join message. Also the paragraph for
Multicast encryption also holds true for the IGMP/MLD with Unicast control

3. In Section 6.2: “- L2/L3 authentication ….”.
This section surely needs to be rewritten. I am still confused as to who needs
to recognise the rceiver, is it the NSP or the CP/Sender. While for IGMP/MLD
case the document says that the sender cannot see the receiver, but for the
L2/L3 case it says that it is possible to recognise the receiver. I think there
should be uniformity in the sections. In the L2/L3 case also the sender cannot
see the receiver.

The document states “…but if there are multiple CPs a signle L2 Authorisation
server cannot distinguish among the CPs”. I am also not sure what do you mean
by this situation of multiple CPs. Why does the auth server needs to
distinguish among the CPs? The auth server should only restrict access for the
NSP?

4. I am very confused after reading section 6.2 and section 6.3. I think it is
firstly very important to mention why is there a needs to distinguish the
between the receivers and end users and who needs such capabilities. As there
is another section of surveillance of user by sender, so it seems that the
section 6.2 and section 6.3 refer to capabilities that should be present with
the NSP, primarily for accounting purposes? But there are lot of contradicting
statements, like in section 6.3, for L2/L3 it is stated that it is possible to
distinguish at user level, where this is only for the NSP, the CP would not
still know unless we have interaction between the AAA servers in the NSP and
the CP. On the other hand for multicast encryption it states that the CP would
know the user.

5. I am not sure why we need to address maintaining QoS in this document, where
neither of the multicast protocols nor the security protocols would address any
QoS issues.

6. For section 6.7, I think a notification should be sent to the user not only
at the time of joining, but also at the time of leaving. This is important as
this would indicate the end of the accounting.

Regards
Prashant

-- 
Prashant Pillai
Research Assistant
School of Engineering, Design and Technology
University of Bradford
Bradford, BD7 1DP
West Yorkshire
United Kingdom
Phone: 0044-1274-233720
email: [email-masked]
------------------------------------------------------------
This mail sent through IMP: http://webmail.brad.ac.uk
To report misuse from this email address forward the message
and full headers to [email-masked]
------------------------------------------------------------

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