Tsunemasa Hayashi, NTT
Internet Draft Haixiang He, Nortel Networks
Document: draft-hayashi-mlda-02.txt Akihiro Tanabe, NTT
Expires: October 2004 Hiroaki Satou, NTT
Teruki Niki, Panasonic
April 2004
Multicast Listener Discovery Authentication protocol (MLDA)
<draft-hayashi-mlda-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-
Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo documents a multicast CDN (Content Delivery Network) issues,
and describes requirement and discussion points when we solve them.
Here, we need a method of precise user accounting (logging) of a user
activity to a multicast group and of user access control to a
multicast group to protect to subscribe from an illegal access. In
this case, it is needed to authorize a user access to a multicast
group on the CDN, and to get information of user action (Join/Leave)
to a multicast group. The key is how a control process of group
membership synchronizes with an AAA process (authentication,
authorization and accounting), because we can get a user access
information at an AAA server. This depends on the network model of
the multicast CDN service. Last of all, we introduce an example of
solution MLDA (Multicast Listener Discovery Authentication protocol).
Hayashi, He, Tanabe, Satou, Niki [Page 1]
Internet Draft draft-hayashi-mlda-02 October, 2004
MLDA provides MLD's protocol framework between hosts and their first-
hop routers, with AAA information. MLDA can be divided into two
parts: One is the header part which specifies IP layer information,
and another part is the data part which can transfer information for
AAA operation. The function of transferring AAA information enables a
provider to control the distribution of the multicast traffic as well
as to collect real time user access log (accounting) information at
the last-hop access networks. In this mechanism, we can protect to
subscribe a multicast data from an illegal user. MLDA just transfers
information for AAA besides of multicast access control, and has
framework that any method of authentication and accounting can be
used with MLDA between a client and AAA server. MLDA also use same
ICMPv6 [ICMPv6] (IP Protocol 58) message types, rather than IGMP (IP
Protocol 2) message types as same as that of IGMP.
1. Terminology
Accounting
The act of collecting information on resource usage for the purpose
of trend analysis, auditing, billing, or cost allocation.
Administrative Domain
An internet, or a collection of networks, computers, and databases
under a common administration. Computer entities operating in a
common administration may be assumed to
share administratively created security associations.
Attendant
A node designed to provide the service interface between a client and
the local domain.
Authentication
The act of verifying a claimed identity, in the form of a pre-
existing label from a mutually known name space, as the originator of
a message (message authentication) or as the end-point of a channel
(entity authentication).
Authorization
The act of determining if a particular right, such as access to some
resource, can be granted to the presenter of a particular credential.
Billing
The act of preparing an invoice.
Broker
A Broker is an entity that is in a different administrative domain
from both the home AAA server and the local ISP, and which provides
services, such as facilitating payments between the local ISP and
Hayashi, He, Tanabe, Satou, Niki [Page 2]
Internet Draft draft-hayashi-mlda-02 October, 2004
home administrative entities. There are two different types of
brokers; proxy and routing.
Client
A node wishing to obtain service from an attendant within an
administrative domain.
Real-time Accounting
Real-time accounting involves the processing of information on
resource usage within a defined time window. Time constraints are
typically imposed in order to limit financial risk.
2. Requirements summery
The multicast CDN model and requirement to group management protocol
for real-time accounting of client activity to a multicast group are
summarized below.
2.1 Requirements of Multicast CDN model
The basic CDN network model consists of three different types of
players. The first player is content service provider (CSP) who
provides its content. The second one is network service provider
(NSP) which controls network resources and delivers the content to an
end user client. The last player is end user client who subscribes
the content. Generally, CSP(s) are different administrative domains
(business entities) from NSP. Each content is transferred on a
multicast (S,G) from CSP to a client through NSP. Each provider
manages own data base of its customer (client) and keep it itself.
+-------------+ +-------------+ +-------------+
| CSP | | CSP | | CSP |
| #1 | | #2 | | #3 |
| +---------+ | | +---------+ | | +---------+ |
| | content | | | | content | | | | content | |
| | server | | | | server | | | | server | |
| +-------+-+ | | +----+----+ | | +-+-------+ |
+----------\--+ +------|------+ +--/----------+
\ | /
\ | / <- network/network interface
\ | /
+------------- \ ------ | ------ / ----+
| \ | / |
| NSP +-+-----+-----+-+ |
| | Provider Edge | |
| +-------+-------+ |
| | |
| \ | |
Hayashi, He, Tanabe, Satou, Niki [Page 3]
Internet Draft draft-hayashi-mlda-02 October, 2004
| +--+------+---+ |
| | User Edge | |
| +--+---+---+--+ |
| / | \ |
+------------- / --- | --- \ ----------+
/ | \
/ | \ <- user/network interface
/ | \
+---------++ +-----+----+ ++---------+
|client #a | |client #b | |client #c |
+----------+ +----------+ +----------+
End user A End user B End user C
There are two important things when we consider this model: The first
one is that basically CSP judges an access request from a client to a
multicast group, and that both CSP and NSP need to correctly account
a user access to a multicast group (a user access log by a group, by
when, by user). Another is that we need to protect network resources
from the illegal client (what we deliver a multicast data to just a
not-granted client).
A user accesses a multicast group on this CDN anywhere, and the user
does not have a restriction of location and client terminal (devices).
NSP needs to support plural network services (e.g. VoIP, Internet
connection) besides of the CDN delivering service at the same time.
Many different CSP may deliver their content to the multicast CDN.
CSP can not directory control the NSP resources (routers and network
switches).
This CDN model supports the case when NSP includes every CSPs.
2.2 Accounting Requirements
CSP needs to correctly account a user access to their content
(multicast group), and authenticate before a user access to a (S,G).
In many cases, we need to operate the accounting in real-time. Each
CSP keeps a user information for authentication itself, and the
information is different from that NSP has. In multicast network,
just NSP can get user access information: When does a user
starts/stop to access? Which multicast group? NSP can transfer the
information to a CSP. An end user wants to access CDN from anywhere.
The NSP-CSP model represents multi-domain AAA environment. There are
plural cases of the model depending on trust relationship between NSP
and CSP, and additional service requirement such as QoS for NSP or
ubiquitous for users.
Hayashi, He, Tanabe, Satou, Niki [Page 4]
Internet Draft draft-hayashi-mlda-02 October, 2004
We need a mechanism that CSP and NSP can affirm a user access log to
a multicast independently.
2.3 Authentication Requirements
When NSP supports plural network services at the same time, we can
not use an authentication mechanism of physical layer like an 802.1X.
Because NSP needs to independently operate (authenticate) each
service. NSP authenticate a user request to multicast network
resources, and CSPs independently authenticate a user request to
their content (multicast group). Each provider (NSP and CSP) has own
AAA server. Then we need a synchronization mechanism between
authorization and group management.
Each provider (NSP and CSPs) may have own authentication server. NSP
authenticate a client access to use a network resource, and a CSP
authenticate a client request to access to a multicast group.
2.4 Authorization Requirements
QoS control, e.g. priority control or admission control, is important
for multicast CDN because there is no-reliability to keep a
transferring quality. Especially for video streaming, video quality
is sensitive to a packet loss. Function to protect network resources
from misuse of network resources is needed there. When NSP controls
QoS, user²s access request has to be authorized by NSP after
aforementioned authentication.
3. MLDA protocol
MLDA is derived from MLDv2. MLDA adds authentication steps to each
group membership state transition in order to control the user access
and collect real-time accounting information. This is accomplished
via the user using IGAP to offer credentials (e.g. user id and
password) to the first hop multicast router as part of group
membership requests.
MLDA assumes a subscription model between the user and the multicast
group owner. How the user obtains the appropriate credentials is out
of scope of this memo.
4. MLDA Message Formats
MLDA is a sub-protocol of ICMPv6, that is, MLDA message types are a
subset of the set of ICMPv6 messages, and MLDA messages are
Hayashi, He, Tanabe, Satou, Niki [Page 5]
Internet Draft draft-hayashi-mlda-02 October, 2004
identified in IPv6 packets by a preceding Next Header value of 58.
All MLDA messages described in this document are sent with a link-
local IPv6 Source Address, an IPv6 Hop Limit of 1, and an IPv6
Router Alert option [RTR-ALERT] in a Hop-by-Hop Options header. (The
Router Alert option is necessary to cause routers to examine MLDA
messages sent to multicast addresses in which the routers themselves
have no interest.)
All MLDA message packets have the following format. The fields from
Type to Source Address [N] consist of the same fields as MLDv2
[MLDv2]. An Auxiliary Data is following.
There are three types of MLDA messages.
0x96 = MLDA Listener Query (MLDA Query)
0x97 = MLDA Listener Acknowledgement (MLDA ACK)
0x98 = MLDA Listener Report (MLDA Report)
All multicast groups should categorized into one of MLD access
control and MLDA's. Unrecognized message types to a multicast group
for MLDA should be silently ignored. Other message types may be used
by newer versions or extensions of MLD, by multicast routing
protocols, or for other uses.
4.1 Multicast Listener Query Message
Multicast Listener Queries are sent by multicast routers to query the
multicast listening state of neighboring interfaces Query have the
following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1(bit)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Response Delay | Reserved-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Multicast Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv |S| QRV | QQIC | Number of Sources (N) |
Hayashi, He, Tanabe, Satou, Niki [Page 6]
Internet Draft draft-hayashi-mlda-02 October, 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Source Address [1] *
| |
* *
| |
+- -+
| |
* *
| |
* Source Address [2] *
| |
* *
| |
+- . -+
. . .
. . .
+- -+
| |
* *
| |
* Source Address [N] *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | # of Aux (N) | Challenge ID | Reserved-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auxiliary Data Records
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
where each Auxiliary Data Record has the following format:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Aux Type | Aux Data Len | Aux Data (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
4.1.1. Type
0x96 = MLDA Listener Query (MLDA Query)
0x97 = MLDA Listener Acknowledgement (MLDA ACK)
Hayashi, He, Tanabe, Satou, Niki [Page 7]
Internet Draft draft-hayashi-mlda-02 October, 2004
4.1.2. Code
The meaning and the usage of Code are the same as those of the MLD
messages as described in draft-vida-mld-v2-XX [MLDv2].
4.1.3. Checksum
Checksum covers the MLDA message (covering fields are same as those
of the MLD message as described in [MLDv2].
4.1.4. Maximum Response Delay
The meaning and the usage of Maximum Response Delay are the same as
those of the MLD messages as described in [MLDv2].
4.1.5. Reserved-1
This field should be set to zero. It is ignored when received.
4.1.6. Multicast Address
For a General Query, the Multicast Address field is set to zero. For
a User-Specific Query, it is set to the multicast address being
queried. For a MLDA ACK message, the Multicast Address field holds
the IP multicast address of interest.
4.1.7. Resv
The meaning and the usage of Resv are the same as those of the MLD
messages as described in draft-vida-mld-v2-XX [MLDv2].
4.1.8. S
The meaning and the usage of S are the same as those of the MLD
messages as described in draft-vida-mld-v2-XX [MLDv2].
4.1.9. QQIC
The meaning and the usage of QQIC are the same as those of the MLD
messages as described in draft-vida-mld-v2-XX [MLDv2].
Hayashi, He, Tanabe, Satou, Niki [Page 8]
Internet Draft draft-hayashi-mlda-02 October, 2004
4.1.10. Number of Sources (N)
The Number of Sources (N) field specifies how many source addresses
are present in the Query. This number is zero in a General Query. For
User-Specific Query, the value is non-zero. The meaning and the usage
of this value for MLD are the same as those of the MLD messages as
described in draft-vida-mld-v2-XX [MLDv2], but we must care the
Auxiliary field not to exceed an MTU of the link.
4.1.11. Source Address [i]
The Source Address [i] fields are a vector of n unicast addresses,
where n is the value in the Number of Sources (N) field. The meaning
and the usage of this value are the same as those of the MLD messages
as described in draft-vida-mld-v2-XX [MLDv2].
4.1.12. Subtype
This field indicates the subtype of message transferred within the
MLDA packet. Usage of this field is described later.
In Type 0x96 (MLDA Query), there are three Subtypes as follows.
0x01 : General Query
0x02 : User-Specific Query for Re-authentication (User Query)
0x11 : Challenge-Response Mechanism Challenge (Challenge)
In Type 0x97 (MLDA ACK), there are three Aux Types as follows.
0x21 : Authentication Message
0x22 : Accounting Message
0x23 : Notification Message
4.1.13. # of Aux (N)
This field indicates the number of Auxiliary Data Record stored in a
MLDA packet.
4.1.14 Challenge ID
This field is meaningful only when Challenge-Response authentication
mechanism is used. The value is set according to the Challenge-
Response protocol. If this field is not used, it is set to the
default value of zero.
Hayashi, He, Tanabe, Satou, Niki [Page 9]
Internet Draft draft-hayashi-mlda-02 October, 2004
4.1.15. Reserved-2
This field should be set to zero. It is ignored when received.
4.1.16. Auxiliary Data Records
An MLDA packet can contain zero or more numbers of Auxiliary Data
Records. The Aux Type field is 1 byte long and specifies the type of
the Auxiliary Data Record. The Aux Data Len field is 1 byte long and
specifies the length of the auxiliary data in units of bytes. The Aux
Data field contains the appropriate data. This document only
specifies the following Auxiliary Data Records.
4.1.16.1. Aux Type
0x01 = User Account
0x02 = User Password
0x03 = Message
0x10 = Challenge-Response ID (Challenge ID)
0xA0 ~ 0xBF = Vendor specific data
4.1.16.2. Aux Data Len
This field indicates the Aux Data Len specifies the length of the
Auxiliary Data.
4.2. MLDA Multicast Listener Report Message
MLDA Multicast Listener Report are sent by MLDA hosts to report the
current multicast listening state, or changes in the multicast
listening state, of their interfaces. Report have the following
format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1(bit)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x98 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Nr of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [1] .
. .
Hayashi, He, Tanabe, Satou, Niki [Page 10]
Internet Draft draft-hayashi-mlda-02 October, 2004
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | # of Aux (N) | Challenge ID | Reserved-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auxiliary Data Records
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Each Multicast Address Record has the following internal format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Type | Not Used | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Multicast Address *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Source Address [1] *
| |
* *
| |
+- -+
| |
* *
| |
* Source Address [2] *
Hayashi, He, Tanabe, Satou, Niki [Page 11]
Internet Draft draft-hayashi-mlda-02 October, 2004
| |
* *
| |
+- -+
. . .
. . .
. . .
+- -+
| |
* *
| |
* Source Address [N] *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2.1. Code
The meaning and the usage of Code are the same as those of the MLD
messages as described in draft-vida-mld-v2-XX [MLDv2].
4.2.2. Checksum
Checksum covers the MLDA message (covering fields are same as those
of the MLD message as described in [MLDv2].
4.2.3. Nr of Mcast Address Records (M)
The meaning and the usage of Nr of Mcast Address Records (M) are the
same as those of the MLD messages as described in [MLDv2].
4.2.4. Multicast Address Record (M)
The Nr of Mcast Address Records (M) field specifies how many
Multicast Address Records are present in this Report. This fields is
specified in [MLDv2].
4.2.5. Subtype
This field indicates the subtype of message transferred within the
MLDA packet. Usage of this field is described later.
In Type 0x98 (MLDA Report), there are four Subtypes as follows.
Hayashi, He, Tanabe, Satou, Niki [Page 12]
Internet Draft draft-hayashi-mlda-02 October, 2004
0x31 : Password Mechanism Report (Password Report)
0x32 : Challenge-Response Mechanism Report Challenge Request
(Challenge-Response Report Request)
0x33 : Challenge-Response Mechanism Report Response
(Challenge-Response Report Response)
0x34 : Basic Report
4.2.6. # of Aux (N)
This field indicates the number of Auxiliary Data Record stored in a
MLDA packet.
4.2.7 Challenge ID
This field is meaningful only when Challenge-Response authentication
mechanism is used. The value is set according to the Challenge-
Response protocol. If this field is not used, it is set to the
default value of zero.
4.2.8. Reserved-2
This field should be set to zero. It is ignored when received.
4.2.9. Auxiliary Data Records
An MLDA packet can contain zero or more numbers of Auxiliary Data
Records. The Aux Type field is 1 byte long and specifies the type of
the Auxiliary Data Record. The Aux Data Len field is 1 byte long and
specifies the length of the auxiliary data in units of bytes. The Aux
Data field contains the appropriate data. This document only
specifies the following Auxiliary Data Records.
4.2.9.1. Aux Type
0x01 = User Account
0x02 = User Password
0x03 = Message
0x10 = Challenge-Response ID (Challenge ID)
0xA0 ~ 0xBF = Vendor specific data
4.2.9.2. Aux Data Len
This field indicates the Aux Data Len specifies the length of the
Auxiliary Data.
Hayashi, He, Tanabe, Satou, Niki [Page 13]
Internet Draft draft-hayashi-mlda-02 October, 2004
4.2.10. Record Type
It specifies the type of the Multicast Address Record. [MLDv2]
4.2.11. Not Used
This field should be fill by null. In MLDA, the field is not used.
4.2.12. Aux Data Len
The Aux Data Len field contains the length of the Auxiliary Data
Field in this Multicast Address Record, in units of 8-bit words. It
may contain zero, to indicate the absence of any auxiliary data.
4.2.13. Number of Sources (N)
The Number of Sources (N) field specifies how many source addresses
are present in this Multicast Address Record.
4.2.14. Multicast Address
The Multicast Address field contains the multicast address to which
this Multicast Address Record pertains.
4.2.15. Source Address [i]
The Source Address [i] fields are a vector of n unicast addresses,
where n is the value in this record's Number of Sources (N) field.
4.2.16. Multicast Address Record Types
It specifies the type of the Multicast Address Record. [MLDv2]
5. Protocol Description
MLDA is used for controlled or managed multicast services. MLD is not
useded for the same group address for MLDA. An MLDA router should
handle a multicast group if it is for MLDA or MLD. MLDA message can
be differentiated from MLDA messages by the values of the "type"
fields specified above.
Hayashi, He, Tanabe, Satou, Niki [Page 14]
Internet Draft draft-hayashi-mlda-02 October, 2004
MLDA tracks an individual host's multicast listener information, in
order to implement "fast leave" feature. In other words, MLDA does
not implement Multicast-Address-Specific (or Multicast-Address and
Source-Specific) Query feature of MLDv2. When a MLDA router receives
a MLDA report message to cease lintening, it deletes the
corresponding state information instead of sending an Multicast-
Address-Specific Query of MLDv2. To facilitate tracking information
of individual host's listening IP-multicast, MLDA does not support
the Host suppression feature of MLD.
MLDA is used for controlled or managed multicast services. A user
must use MLDA to access such multicast services.
MLDA specifies different behaviors for MLDA hosts and for MLDA
routers. If an MLDA router needs to listen some IP multicast address,
it can perform both parts of the protocol.
5.1 User Authentication Mechanisms
Currently MLDA supports two user authentication mechanisms for Report
operation: simple and basic password authentication mechanism [PAP],
and more advanced challenge-response authentication mechanism [CHAP].
These mechanisms are not used at the same time. Only one mechanism
may be configured for use in a specific network. An MLDA
implementation must support the password authentication mechanism,
while the Challenge-response authentication mechanism is optional.
Any encrypted user information can be transferred on the password
mechanism between a MLDA host and a AAA server, where MLDA transfers
the encrypted date on a Report message.
MLDA is intended for use with standard AAA servers such as RADIUS
[RADIUS] servers, which, with necessary extensions, can be used to
achieve the authentication, authorization and accounting functions
described in this document. However, MLDA is not limited to use with
standard AAA servers. It can be used with any back-end
Authentication, Authorization, and Accounting functions or
mechanisms. These functions or mechanisms can be located in different
servers, within one server, or even within the MLDA routers. In this
document, we use AAA servers as an example for these functions or
mechanisms.
MLDA router must support to transfer any Auxiliary Data Record of a
Vendor specific data (0x20, 0xA0~ 0xBF) on MLDA packet to an
attribute data for Authentication or Accounting process between AAA
server. The rule depends on a network service. For example, when the
encrypted data as a user information is transfered to a MLDA router,
the client may use User Encrypted Information as an Auxiliary Type,
and the information may be transfered to a AAA server with a vendor
specific attribute.
Hayashi, He, Tanabe, Satou, Niki [Page 15]
Internet Draft draft-hayashi-mlda-02 October, 2004
5.2 MLDA Host Protocol Description
This section describes the MLDA host behavior. Based on the
configured authentication mechanism, an MLDA host behaves
differently.
5.2.1 Password Authentication Mechanism
When an MLDA host starts listening to a multicast address on an
interface, it should immediately transmit an unsolicited MLDA Report
that has a Subtype field of 0x31 (Password Report) to the
corresponding address. The Report must have two auxiliary data of
User Account (Aux Type of 0x01), and User Password (Aux Type of 0x02)
or Message (Aux Type of 0x03) at least. The Aux Data field of User
Account is filled with the user account (user ID) while the Aux Data
Len field is set to the length of the user account. The Aux Data
field of User Password is filled with the user password while the Aux
Data Len field is set to the length of the password. The Aux Data
field of Message is filled with a authentication information
substitute for the password.
When a host receives an MLDA Query of Query that has a Subtype field
of 0x01 or 0x02, it sets delay timers as described in [MLDv2]. If a
timer for the multicast address is already running, it is reset to
the random value only if the requested Maximum Response Delay is less
than the remaining value of the running timer. When a multicast
address's timer expires, the host sends a Password Report that has a
Subtype field of 0x31. This message must have an auxiliary data of
User Account at least for General Query that has a Subtype field of
0x01. On the other hand, this message must have an auxiliary data of
User Account and User password at least for User-Specific Query for
Re-authentication that has a Subtype field of 0x02. The Aux Data
field is filled with the user account (user ID) while the Account
Size field is set to the length of the user account. When the MLDA
Query is User-Specific Query for Re-authentication that has a Subtype
field of 0x02, the host must send a Password Report with auxiliary
data of both User Account and Password.
When an MLDA host ceases to listen to a multicast address, it sends
an MLDA message to the all-routers multicast address which will be
specified in [MLDv2]. The maner of message format should be followed
[MLDv2]. The Report has a auxiliary data of User Account at least.
The Aux Data field is filled with the user account (user ID) while
the Aux Data Len field is set to the length of the user account. In
scenarios where authentication is required, an MLDA host can send the
Report message that has a Subtype field of 0x31 (Password Report) for
any ceasing operation. The Password Report must have two auxiliary
Hayashi, He, Tanabe, Satou, Niki [Page 16]
Internet Draft draft-hayashi-mlda-02 October, 2004
data of User Account and Account Size at least. The Aux Data of User
Account is set to the values as in Basic Report. The Aux Data of User
Password field is filled with the user password while the Aux Data
Len field is set to the length of the password.
5.2.2 Challenge-Response Authentication Mechanism
When an MLDA host starts listening to a multicast address, it sends a
Challenge-Request Report Request that has a Subtype field of 0x32
(Challenge-Response Mechanism Report Challenge Request) to the
corresponding multicast address. The Request must have a auxiliary
data of User Account at least. The Aux Data field is filled with the
user account (user ID) while the Aux Data Len field is set to the
length of the user account.
When the MLDA host receives a Challenge that has a Subtype of 0x11
(Challenge-Response Mechanism Challenge) as a response to the, the
MLDA client sends a Challenge-Response Report Response that has a
Subtype of 0x33 (Challenge-Response Mechanism Report Response). The
Report Response must have three auxiliary data of User Account, User
Password, and Challenge ID. The Aux Data field of Challenge ID is set
to the same value of Challenge ID on the Challenge. The Aux Data
field of User Account is filled with the user account (user ID) while
the Aux Data Len field is set to the length of the user account. The
Aux Data field of User Password is set the results of MD5 calculation.
The Aux Data Len field is set to 0x10.
When a host receives an MLDA Query, it follows the behavior described
above to set the delay timer. When a address's timer expires, the
host sends a MLDA Report that has a Subtype field of 0x32. This
message must have a auxiliary data of User Account at least. The Aux
Data field is filled with the user account (user ID) while the Aux
Data Len field is set to the length of the user account.
When an MLDA host ceases to listen to a multicast address, it sends
an MLDA Report message to the all-routers multicast address which
will be specified in [MLDv2]. Normally an MLDA host sends a Basic
Report message for ceasing to listen as described above. The detail
manner of message format should be follow [MLDv2]. In scenarios where
the Report message authentication is required, an MLDA host can send
a Report message that has a Subtype field of 0x32 (Challenge-Response
Mechanism Report Challenge Request). The message must have a
auxiliary data of User Account at least. The Aux Data field is filled
with the user account (user ID) while the Aux Data Len field is set
to the length of the user account. When the MLDA host receives a
Challenge that has a Subtype of 0x11 (Challenge-Response Mechanism
Challenge) as a response to the Challenge-Response Report Request, it
sends a Report message that has a Subtype field of 0x43 (Challenge-
Response Mechanism Report Response) with a Multicast Address Record
Hayashi, He, Tanabe, Satou, Niki [Page 17]
Internet Draft draft-hayashi-mlda-02 October, 2004
for ceasing to listen. The message must have three auxiliary data of
User Account, User Password, and Challenge ID at least. The Aux Data
field of User Password is set to the results of MD5 calculation. The
Aux Data Len field is set to 0x10.
An MLDA implementation must support Basic Report. Challenge-Response
Authentication Mechanism Report is optional.
5.3 MLDA Router Protocol Description
MLDA routers use MLDA to learn which multicast address have listeners
on each of their interfaces. They can be physical interfaces or
virtual interfaces such as VLANs. Same as MLD, an MLDA router keeps a
listener list of multicast address for each attached network, and a
timer for each address. Each address state has the conceptual
following format:
(socket, interface, IPv6 multicast address, filter mode, source
list, user-id, client IP address, timer(s))
MLDA routers periodically [Query Interval] send an MLDA Query on each
attached network to solicit listener information. On startup, a
router SHOULD send [Startup Query Count] MLDA Queries spaced closely
together [Startup Query Interval] in order to quickly and reliably
determine listener information. [Query Interval], [Startup Query
Count] and [Startup Query Interval] are same as [MLDv2].
An General Query is addressed to the all-systems multicast address
(FF02::1), has a Multicast Address field of Zero, has a Maximum
Response Delay of [Query Response Interval], and has a MLDA Type
field of 0x01 (General-Query). [Query Response Interval] is same as
[MLDv2].
An User Query is addressed to the unicast IP address of the client
host, has a Multicast Address field of the multicast address the
client listen, and has a MLDA Type field of 0x02 (User-Specific Query
for Re-authentication). A Maximum Response Delay of [Query Response
Interval] is same to that of General Query. [Query Response Interval]
is same as [MLDv2].
5.3.1 Password Authentication Mechanism
When an MLDA router receives a Password Mechanism Report (an MLDA
Report that has a Subtype field of 0x31), if the router already has
the corresponding listener state of a multicast address, it refreshes
the associated timer.
Hayashi, He, Tanabe, Satou, Niki [Page 18]
Internet Draft draft-hayashi-mlda-02 October, 2004
If the router does not have listener state of the multicast address,
it forwards the user's listener Response request as well as its user
authentication information, including its user account and password,
to the back-end AAA server. Based on the AAA server's authentication
and authorization results, the MLDA router grants or denies the
user's access request. When the MLDA router grants the request, it
adds the multicast being reported to the listener list of a multicast
address on the interface on which it received the Report and sets the
timer for the address to the [Multicast Listener Interval].
When an MLDA router receives an MLDA Report message to cease
listening a multicast group that has listeners on the reception
interface, it deletes the corresponding multicast address state.
If an authentication is required in the ceasing operation, an MLDA
Report must have a Subtype field of 0x31, and includes a user
authentication information which is same to a user authentication on
Password Report, and the router forwards the user's cease information
as well as the user authentication information to the back-end AAA
server. If the cease request is authenticated and authorized, the
router deletes the corresponding listener state of a multicast
address. Otherwise, the cease request is ignored.
5.3.2 Challenge-Response Authentication Mechanism
When an MLDA router receives a Challenge-Response Report Request has
a Subtype field of 0x32, the router tries to establish Challenge-
Response communication for a Report process, then the router sends a
Challenge-Response Mechanism Challenge (a Challenge that has a Type
field of 0x96, a Subtype field of 0x11). The Challenge must have
three auxiliary data of User Account, User Password, and Challenge ID.
The Aux Data field of User Account is set to the same user ID in the
Challenge-Response Report Request, the Aux Data field of User
Password set to a Challenge value [CHAP], and the Aux Data field of
Challenge ID set to an ID [CHAP].
When the MLDA router receives a Challenge-Response Report Response
that has a Subtype field of 0x33), if the router already has the
corresponding multicast address listener state, it refreshes the
associate timer.
If the router does not have the listener state of a multicast address,
it forwards the user's listen request information as well as its user
authentication information including its user account and password to
the back-end AAA server. Based on the AAA server's results of
authentication and authorization processes, the MLDA router grants or
denies the user's access request. When the MLDA router grants the
request, it adds the multicast address being reported to the listener
list of multicast address on the interface on which it received the
Hayashi, He, Tanabe, Satou, Niki [Page 19]
Internet Draft draft-hayashi-mlda-02 October, 2004
Report and sets the timer for the listener to the [Multicast Listener
Interval].
When an MLDA router receives an MLDA Report message to cease
listening to a multicast address that has multicast listeners on the
reception interface, it deletes the corresponding multicast listener
state.
If an authentication is required in the ceasing operation, a host
oriented Challenge-Response communication is establish between a host
and the MLDA router. When a MLDA router receives an Challenge-
Response Report Request to cease listening a multicast group that has
a Subtype field of 0x32, the router sends a Challenge-Response
Mechanism Challenge (a Challenge that has a Type field of 0x96, a
Subtype field of 0x11, a Challenge ID field of an ID [CHAP], a User
Account set to a user ID in the Challenge-Request-Report, and a
Message set to a Challenge value [CHAP]).
When the MLDA router receives a Challenge-Response Report Response to
cease listening to the multicast address that has a Subtype field of
0x33. The message must have three auxiliary data of User Account,
User Password, and Challenge ID at least. Both Aux Data fields of
User Account and User Password are the same. The Aux Data field of
User Password is set to the results of MD5 calculation. The Aux Data
Len field of User Password is set to 0x10, and the router forwards
the user's multicast address cease information as well as the user
authentication information to the back-end AAA server. If the address
cease request is authenticated and authorized, the router deletes the
corresponding multicast listener state. Otherwise, the cease request
is ignored.
5.4 Status Notifications
In controlled or managed multicast environments, it is very important
to notify a user of its service statuses. MLDA supports the following
status notifications.
5.4.1 Authentication Result Notification
When an MLDA router receives the authentication result from the
back-end AAA server, it notifies the user of the result by unicasting
an Authentication message to the client.
The Authentication message has a Type field of 0x97 (MLDA ACK) and a
Subtype field of 0x21. The Multicast Address field contains the
corresponding multicast address for authentication. The Maximum
Response Delay field is not used and is ignored by MLDA clients. It
can be set to any value. The message has two auxiliary data of User
Hayashi, He, Tanabe, Satou, Niki [Page 20]
Internet Draft draft-hayashi-mlda-02 October, 2004
Account and Message at least. The Aux Data field of User Account
contains the user account (user ID) for authentication and the Aux
Data Len field is set the length of the user account.
The Aux Data field of Message has the following values at least:
0x11: Authentication success.
0x21: Authentication failure.
The Message Size field is set to the length of the Aux Data. An MLDA
implementation must support the above mandatory values. It supports
the any other vendor specific values. Appropriate value is chosen to
reflect the result from the AAA server as well as other vendor
specific processes. The process adopted by the MLDA clients upon
receiving this packet type is up to implementation. However, it must
not affect other MLDA process.
5.4.2 Accounting Status Notification
An MLDA router informs the accounting server to start accounting when
it starts forwarding related multicast traffic into the client's
network. When the MLDA client ceases to listen to the multicast
address (either via silent departure or an explicit leave), the
router informs the accounting server to stop accounting. Once it
receives the response from the accounting server, it notifies the
MLDA client by unicasting an Accounting message.
The Accounting message has a Type field of 0x97 (MLDA ACK) and a
Subtype field of 0x22. The Multicast Address field, the Maximum
Response Delay field, the User Account field, and the Account Size
field are the same as those in the Authentication message described
in section 3.4.1.
The Message field has the following values at least:
0x11: Accounting start
0x12: Accounting stop
The Message Size field is set to the length of the Aux Data. An MLDA
implementation must support the above mandatory values. It supports
the any other vendor specific values. The process adopted by the MLDA
client upon receiving this packet type is up to implementation.
However, it must not affect other MLDA process.
5.5 Validity Period
For each multicast listener state, an MLDA router SHOULD maintain
another timer: Validity Period timer. This timer indicates the valid
Hayashi, He, Tanabe, Satou, Niki [Page 21]
Internet Draft draft-hayashi-mlda-02 October, 2004
period of an accounting to a multicast listener. When the timer is
expired, an MLDA router needs to re-authenticate the multicast
listener, then the router sends a MLDA host User-Specific Query for
Re-authentication besides of General Query. The value of the
"Validity Period" can be statically configured or dynamically set
based on the results from the AAA server.
When "Validity Period" is enforced, an MLDA router checks this timer
when it receives an MLDA Report. If the timer does not expire, the
MLDA router send a MLDA host a General Query, and does not ask the
AAA server a user authentication by a MLDA Report response. If the
timer expires, it follows the procedures for initial authentication
described above to re-authenticate the listen request. During the re-
authentication period, an MLDA router continues forwarding the
multicast traffic and does not stop accounting. If the re-
authentication succeeds, an MLDA router resets the multicast address
timer and the Validity Period timer. If the re-authentication fails,
an MLDA router stops accounting and deletes the multicast address
listener state.
6. List of Timers, Counters
This section describes the parameters set in MLDA router and Host
when supporting MLDA processes.
6.1. Robustness Variable
It is the same meaning as MLDv2.
6.2. Timers and Counters for Host
6.2.1. Challenge-Timer
It controls waiting time from sending Report message to receiving
Challenge Message.
6.2.2. Host-Authentication-Timer
It controls waiting time from sending Response Message to receiving
Authentication Message (accept or reject) from MLDA router.
6.2.3. Host-Accounting-Timer
It controls waiting time from sending Response Message to receiving
Accounting Message (start or stop) from MLDA router.
Hayashi, He, Tanabe, Satou, Niki [Page 22]
Internet Draft draft-hayashi-mlda-02 October, 2004
6.2.4. Delaying-Timer
It controls waiting time from receiving Query to sending Report
Message to MLDA router. It is calculated from Max Resp Time.
6.2.5. Cease-Retransmission-Counter
The Cease-Retransmission-Counter is the number of Report messages a
host retransmits after sending the first Report message. The default
value is zero.
6.2.6. Unsolicited-Report-Interval-Timer
It is the same meaning as MLDv2. The Unsolicited Report Interval is
the time between repetitions of a node's initial report of interest
in a multicast address. Default: 1 second.
6.3. Timers and Counters for MLDA router
6.3.1. Response-Timer
It controls waiting time from sending Challenge Message to receiving
Response Message between client host.
6.3.2. Router-Authentication-Timer
It controls waiting time from sending Authentication request to
receiving Authentication Response between AAA server.
6.3.3. Router-Accounting-Timer
It controls waiting time from sending Accounting request to receiving
Accounting Response between AAA server.
6.3.4. Validity-Timer
This is an integer multiple of General-Query Interval in units of
second, and used by MLDA router to determine whether user
authentication is necessary or not.
Hayashi, He, Tanabe, Satou, Niki [Page 23]
Internet Draft draft-hayashi-mlda-02 October, 2004
6.3.5. Query-Interval-Timer
It is the same meaning as MLDv2. The Query Interval is the interval
between General Queries.
6.3.6. Query-Response-Interval-Timer
It is the same meaning and takes the same default value as MLDv2. The
Max Response Time inserted into the periodic General Queries.
6.3.7. Multicast-Address-Listener-Interval-Timer
It is the same meaning as MLDv2. The Multicast Address Listener
Interval is the amount of time that must pass before a MLDA router
decides there are no more users of a multicast address on a link.
This value MUST be ((the Robustness Variable) times (the Query
Interval)) plus (one Query Response Interval).
6.3.8. Startup-Query-Interval-Timer
It is the same meaning and takes the same default value as MLDv2. The
Startup Query Interval is the interval between General Queries sent
by a Querier on startup.
6.3.9. Startup-Query-Count
It is the same meaning and takes the same default value as MLDv2. The
Startup Query Count is the number of Queries sent out on startup,
separated by the Startup Query Interval.
6.3.10 Accounting-Retransmission-Counter
The Accounting-Retransmission-Counter is the number of Accounting
messages a router retransmits after sending the first accounting
message to a host. The default value is zero.
6.3.11 Immediate-Accounting
The Immediate-Accounting indicates whether a router will start the
accounting immediately after a MLDA Report is authenticated and
authorized or start the accounting when the subscribed multicast data
starts being forwarded. The values are TRUE and FALSE. The default
value is FALSE.
Hayashi, He, Tanabe, Satou, Niki [Page 24]
Internet Draft draft-hayashi-mlda-02 October, 2004
6.3.12 Free-Ride
When the value is true, when Router-Authentication-Timer is expired,
the group is free to access. This variety depends on provider²s
service.
6.3.13 Accounting-Anyway
When the value is true, accounting is carried out despite the
expiration of Router-Accounting-Timer.
7. Security Considerations
MLDA is based around an asymmetrical trust model in which the MLDA
router does not trust the MLDA client, but the MLDA client trusts the
MLDA router. Therefore, it may not be suitable for use in isolation
where mutual authentication is required. MLDA supports password and
challenge-response authentication mechanisms and inherits the
security concerns of each. For multicast content encryption related
technology, please refer to other IETF work. MLDA does not obstruct
snooping of multicast traffic by unauthorized client that have access
to media shared with multicast traffic.
Some of the security issues discussed in MLD document also apply here.
Please refer to MLDv2 document [MLDv2] for details.
8. IANA Considerations
This document introduces the following new version and Types of ICMP
message that require allocation by IANA:
Type:
0x96: MLDA Listener Query (MLDA Query)
0x97: MLDA Listener Acknowledgment (MLDA ACK)
0x98: MLDA Listener Report (MLDA Report)
Acknowledgments
Portions of this document are copied from [MLDv2]. The authors would
like to thank Takashi Shimizu, Hiroshi Ohta, and Yuji Chikahiro for
their valid advice, patience, and time to review the document and to
Hayashi, He, Tanabe, Satou, Niki [Page 25]
Internet Draft draft-hayashi-mlda-02 October, 2004
provide their valuable suggestions. This document consists based on
an important discussion with them.
Appendix 1. Example of AAA server interface using Radius authentication
and accounting
This section provides an example of the interface between Radius
server and MLDA router to transfer the information dedicated MLDA.
Here, these inforomation are transfered on the vender specific
attribute of Radius protocol, and these nay be transfered on other
attribute in future. The example is for illustration purposes only.
Implementations of the MLDA protocol are suggested but not required
to follow the example. However they should comply with the
specifications presented earlier in this document.
The below shows the attribute numbers.
Type26 (Vendor Specific Attribute)
Vendor Type90 : Accounting-multicast-group-address
Multicast group address
Vendor Type91 : Auth-Info
When a MLDA router gets a Report packet
which has three Auxes (User Account,
User Password, and Message), the
Message data should be put in the "Auth
Info".
Vendor Type92 : Auth-source-address
Source address of Source list
Vendor Type93 : Validity-period
Vendor Type94 : change-flag-sequence-number
When a MLDA router get the Change packet,
the router will care two different
sequences for BLOCK_OLD_SOURCES and
ALLOW_NEW_SOURCES. For
BLOCK_OLD_SOURCES: the MLDA router
should operate an accounting stop
sequence between a Radius server. And a
new attributes, which is change-flag-
sequence-number, is transfered to the
Radius server. The value of change-flag-
Hayashi, He, Tanabe, Satou, Niki [Page 26]
Internet Draft draft-hayashi-mlda-02 October, 2004
sequence-number is generated at the MLDA
router.
For ALLOW_NEW_SOURCES: the MLDA router
should operate an operation of
authentication and accounting start with
the same change-flag-sequence-numner on
the BLOACK_OLD_SOURCES in the previous
operation.
Vendor Type110: User-MAC-address
When a user authentication is operated
with a MAC address of MLDA client, the
MAC address information is transfered on
the attribute of User-MAC-address.
References
[ICMPv6]
A. Conta and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998
[RFC 2710]
Deering, S., Fenner, W., Haberman, B., "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, November 1999.
[MLDv2]
Hayashi, He, Tanabe, Satou, Niki [Page 27]
Internet Draft draft-hayashi-mlda-02 October, 2004
S. Deering, W. Fenner, and B. Haberman, "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", draft-vida-mld-v2-XX.
[IPRA]
D. Katz, "IP Router Alert Option", RFC 2113, February 1997.
[RTR-ALERT] C. Partridge and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
[MD5]
R. Rivest, S. Dusse, "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.
[RADIUS]
C. Rigney, S. Willens, A. Rubens, W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
Author's Addresses
Tsunemasa Hayashi
NTT Network Innovation Laboratories
1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan
Phone : +81 46 859 8790
Email : hayashi.tsunemasa@lab.ntt.co.jp
Haixiang He
Nortel Networks
600 Technology Park Drive
Billerica, MA 01801, USA
Phone : +1 978 288 7482
Email : haixiang@nortelnetworks.com
Akihiro Tanabe
NTT Access Network Service Systems Laboratories
1-6 Nakase Mihiama-ku, Chiba-shi, Chiba, 261-0023 Japan
Phone : +81 43 211 2115
Email : dandou@ansl.ntt.co.jp
Hiroaki Satou
NTT Network Service Systems Laboratories
3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan
Phone : +81 422 59 4683
Email : satou.hiroaki@lab.ntt.co.jp
Hayashi, He, Tanabe, Satou, Niki [Page 28]
Internet Draft draft-hayashi-mlda-02 October, 2004
Teruki Niki
Matsushita Electric Industrial Co.,Ltd
Multimedia Systems Research-Laboratory
4-5-15 Higashi-Shinagawa Shinagawa-ku, Tokyo, 140-8632 Japan
Phone : +81 3 5460 2741
Email : niki.teruki@jp.panasonic.com
Hayashi, He, Tanabe, Satou, Niki [Page 29]