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) 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]