Internet Engineering Task Force Tsunemasa Hayashi, NTT Internet Draft Haixiang He, Nortel Networks October, 2003 Akihiro Tanabe, NTT Expires: April, 2004 Hiroaki Satou, NTT Teruki Niki, Matsushita Electric Industrial 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 the Multicast Listener Discovery Authentication protocol (MLDA). MLDA provides not only the functionality of multicast listener discovery between hosts and their first-hop routers as MLD does, with the addition of user authentication and accounting. MLDA is designed to be used in a controlled or managed IPv6 multicast environment, when authentication and accounting are required. The user authentication information in MLDA can enable a provider to control the distribution of the multicast traffic as well as to collect real time user accounting information. 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. Introduction IP multicast provides an efficient mechanism for delivering packets to multiple destinations. Unfortunately, IP multicast services, especially commercial IP multicast services, are not widely deployed. One of the important obstacles to its deployment is related to the Hayashi, He, Tanabe, Satou, Niki [Page 1] Internet Draft draft-hayashi-mlda-01.txt April, 2004 current IP multicast model. The current IP multicast model provides by nature a non-secure, non-controlled way for end systems attached to a network to access multicast traffic. Lack of access control in this model makes it difficult for a service provider to generate enough revenue to sustain multicast services such as IP multicast-based Internet TV. A provider can enforce such access control through static configuration on the last-hop network devices, including Ethernet switches or routers. There are two major disadvantages to this approach. First, static configuration does not fit into the environment where the access control policy changes dynamically. Second, the access control policy can only be based on physical ports, host's IP or MAC addresses, and hence it can not be used in an environment where user based access control policy is required. This leads to the need for a comprehensive way to authenticate and authorize end systems before they are granted access to some multicast groups. This need is met by the Multicast Listener Discovery Authentication protocol (MLDA). IGAP allows last-hop network devices to enforce multicast receiver access control in a non-shared access-control environment. MLDA provides not only multicast listener control but also user authentication and accounting. MLDA can be used when authentication and accounting are required for multicast data access by a multicast group, while MLD can be used when they are not required. MLDA is used only in an IPv6 environment. MLDA enables an IP multicast service provider to authenticate and authorize a host's requests to join a specific multicast group based on its user's authentication information and then to control the user's authentication information and then to control the user's access to the multicast traffic accordingly. MLDA employs a user-based authentication model rather than an authentication model based upon IP or MAC address. The benefits of a user-based model are well known: operational simplicity and flexibility, in particular with respect to adds, moves, and changes. Another issue that discourages the wide deployment of IP multicast services is the lack of multicast network management functions, especially an effective multicast accounting function. Effective user-based accounting information is critical in two aspects. On one hand, network providers of commercial multicast services need to accurately identify the users and collect their usage information to generate correct billing information. On the other hand, some content providers need to learn the content usage information. For example, in IP multicast based Internet TV services, network providers need to know which TV program is being watched and how long a user watches so that they can charge the user based on the value of the TV program. In addition, content providers and TV program owners need to know the Hayashi, He, Tanabe, Satou, Niki [Page 2] Internet Draft draft-hayashi-mlda-01.txt April, 2004 number of viewers of a TV program and how long they watch the TV program in order to generate appropriate advertisement revenue. MLDA combines user information, including user ID, with the multicast addresses that reflect the different content. Authenticated and authorized address listener requests enable providers to effectively collect the user usage information for different content. MLDA not only encourages the wide deployment of new commercial IP multicast services, but also can be used in non-commercial environments such as enterprises. For example, MLDA can be used for closed video broadcasting. MLDA provides a mechanism to allow the access to the video broadcasting, only if the user is an authenticated user who is allowed to start watching the video broadcasting. MLDA transactions flow between an MLDA host client and an MLDA router. The MLDA router is assumed to be 1 hop from the MLDA host, such that the host does not have a route that bypasses the MLDA router. An MLDA host must authenticate itself to an MLDA router in order to join a multicast group. 2. 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 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. Hayashi, He, Tanabe, Satou, Niki [Page 3] Internet Draft draft-hayashi-mlda-01.txt April, 2004 2.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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | * * | | * Source Address [1] * | | * * | | +- -+ | | * * | | * Source Address [2] * | | * * | | +- . -+ . . . . . . +- -+ | | * * | | * Source Address [N] * | | * * | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | # of Aux (N) | Challenge ID | Reserved-2 | Hayashi, He, Tanabe, Satou, Niki [Page 4] Internet Draft draft-hayashi-mlda-01.txt April, 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 2.1.1. Type 0x96 = MLDA Listener Query (MLDA Query) 0x97 = MLDA Listener Acknowledgement (MLDA ACK) 2.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]. 2.1.3. Checksum Checksum covers the MLDA message (covering fields are same as those of the MLD message as described in [MLDv2]. 2.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]. 2.1.5. Reserved-1 This field should be set to zero. It is ignored when received. 2.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. Hayashi, He, Tanabe, Satou, Niki [Page 5] Internet Draft draft-hayashi-mlda-01.txt April, 2004 2.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]. 2.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]. 2.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]. 2.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. 2.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]. 2.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 Hayashi, He, Tanabe, Satou, Niki [Page 6] Internet Draft draft-hayashi-mlda-01.txt April, 2004 0x22 : Accounting Message 0x23 : Notification Message 2.1.13. # of Aux (N) This field indicates the number of Auxiliary Data Record stored in a MLDA packet. 2.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. 2.1.15. Reserved-2 This field should be set to zero. It is ignored when received. 2.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. 2.1.16.1. Aux Type 0x01 = User Account 0x02 = User Password 0x03 = Message 0x10 = Challenge-Response ID (Challenge ID) 0xA0 ~ 0xBF = Vendor specific data 2.1.16.2. Aux Data Len This field indicates the Aux Data Len specifies the length of the Auxiliary Data. 2.2. MLDA Multicast Listener Report Message MLDA Multicast Listener Report are sent by MLDA hosts to report the Hayashi, He, Tanabe, Satou, Niki [Page 7] Internet Draft draft-hayashi-mlda-01.txt April, 2004 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] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 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 * | | * * Hayashi, He, Tanabe, Satou, Niki [Page 8] Internet Draft draft-hayashi-mlda-01.txt April, 2004 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | * * | | * Source Address [1] * | | * * | | +- -+ | | * * | | * Source Address [2] * | | * * | | +- -+ . . . . . . . . . +- -+ | | * * | | * Source Address [N] * | | * * | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.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]. 2.2.2. Checksum Checksum covers the MLDA message (covering fields are same as those of the MLD message as described in [MLDv2]. 2.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]. Hayashi, He, Tanabe, Satou, Niki [Page 9] Internet Draft draft-hayashi-mlda-01.txt April, 2004 2.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]. 2.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. 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 2.2.6. # of Aux (N) This field indicates the number of Auxiliary Data Record stored in a MLDA packet. 2.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. 2.2.8. Reserved-2 This field should be set to zero. It is ignored when received. 2.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. Hayashi, He, Tanabe, Satou, Niki [Page 10] Internet Draft draft-hayashi-mlda-01.txt April, 2004 2.2.9.1. Aux Type 0x01 = User Account 0x02 = User Password 0x03 = Message 0x10 = Challenge-Response ID (Challenge ID) 0xA0 ~ 0xBF = Vendor specific data 2.2.9.2. Aux Data Len This field indicates the Aux Data Len specifies the length of the Auxiliary Data. 2.2.10. Record Type It specifies the type of the Multicast Address Record. [MLDv2] 2.2.11. Not Used This field should be fill by null. In MLDA, the field is not used. 2.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. 2.2.13. Number of Sources (N) The Number of Sources (N) field specifies how many source addresses are present in this Multicast Address Record. 2.2.14. Multicast Address The Multicast Address field contains the multicast address to which this Multicast Address Record pertains. 2.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. Hayashi, He, Tanabe, Satou, Niki [Page 11] Internet Draft draft-hayashi-mlda-01.txt April, 2004 2.2.16. Multicast Address Record Types It specifies the type of the Multicast Address Record. [MLDv2] 3. 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. 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. 3.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 transfered 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 Hayashi, He, Tanabe, Satou, Niki [Page 12] Internet Draft draft-hayashi-mlda-01.txt April, 2004 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. 3.2 MLDA Host Protocol Description This section describes the MLDA host behavior. Based on the configured authentication mechanism, an MLDA host behaves differently. 3.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 Hayashi, He, Tanabe, Satou, Niki [Page 13] Internet Draft draft-hayashi-mlda-01.txt April, 2004 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 has two auxiliary 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. 3.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 Hayashi, He, Tanabe, Satou, Niki [Page 14] Internet Draft draft-hayashi-mlda-01.txt April, 2004 maner 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 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. 3.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]. Hayashi, He, Tanabe, Satou, Niki [Page 15] Internet Draft draft-hayashi-mlda-01.txt April, 2004 3.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. 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 ceasinng 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. 3.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 Hayashi, He, Tanabe, Satou, Niki [Page 16] Internet Draft draft-hayashi-mlda-01.txt April, 2004 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 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 linstening 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. 3.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. 3.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. Hayashi, He, Tanabe, Satou, Niki [Page 17] Internet Draft draft-hayashi-mlda-01.txt April, 2004 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 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. 3.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. Hayashi, He, Tanabe, Satou, Niki [Page 18] Internet Draft draft-hayashi-mlda-01.txt April, 2004 3.5 Validity Period For each multicast listener state, an MLDA router SHOULD maintain another timer: Validity Period timer. This timer indicates the valid 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. 4. List of Timers, Counters This section describes the parameters set in MLDA router and Host when supporting MLDA processes. 4.1. Robustness Variable It is the same meaning as MLDv2. 4.2. Timers and Counters for Host 4.2.1. Challenge-Timer It controls waiting time from sending Report message to receiving Challenge Message. 4.2.2. Host-Authentication-Timer It controls waiting time from sending Response Message to receiving Authentication Message (accept or reject) from MLDA router. Hayashi, He, Tanabe, Satou, Niki [Page 19] Internet Draft draft-hayashi-mlda-01.txt April, 2004 4.2.3. Host-Accounting-Timer It controls waiting time from sending Response Message to receiving Accounting Message (start or stop) from MLDA router. 4.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. 4.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. 4.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. 4.3. Timers and Counters for MLDA router 4.3.1. Response-Timer It controls waiting time from sending Challenge Message to receiving Response Message between client host. 4.3.2. Router-Authentication-Timer It controls waiting time from sending Authentication request to receiving Authentication Response between AAA server. 4.3.3. Router-Accounting-Timer It controls waiting time from sending Accounting request to receiving Accounting Response between AAA server. 4.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 20] Internet Draft draft-hayashi-mlda-01.txt April, 2004 4.3.5. Query-Interval-Timer It is the same meaning as MLDv2. The Query Interval is the interval between General Queries. 4.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. 4.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). 4.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. 4.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. 4.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. 4.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 21] Internet Draft draft-hayashi-mlda-01.txt April, 2004 4.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. 4.3.13 Accounting-Anyway When the value is true, accounting is carried out despite the expiration of Router-Accounting-Timer. 5. 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. 6. 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 provide their valuable suggestions. This document consists based on an important discussion with them. Hayashi, He, Tanabe, Satou, Niki [Page 22] Internet Draft draft-hayashi-mlda-01.txt April, 2004 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] 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 Hayashi, He, Tanabe, Satou, Niki [Page 23] Internet Draft draft-hayashi-mlda-01.txt April, 2004 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 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 24]