Internet Engineering Task Force Tsunemasa Hayashi, NTT Internet Draft Haixiang He, Nortel Networks June, 2003 Akihiro Tanabe, NTT Expires: December, 2003 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, but also user authentication and accounting functionalities. MLDA is designed to be used in a controlled or managed IPv6 multicast environment. It provides with a viable alternative to MLD in IP multicast networks 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 collecting 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 MLD. 1. Introduction IP multicast provides an efficient mechanism for delivering packets to multiple destinations. Unfortunately, IP multicast services, Hayashi, He, Tanabe, Satou, Niki [Page 1] Internet Draft draft-hayashi-mlda-00.txt June, 2003 especially commercial IP multicast services, are not widely deployed. One of the important reasons that discourage the deployment is related to the 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 in 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. The Multicast Listener Discovery Authentication protocol (MLDA) is designed to allow last-hop network devices to enforce multicast receiver access control in a non-shared access networks environment. MLDA provides not only multicast listener communication but also user authentication and accounting functionalities. MLDA can be used when authentication and accounting are required for multicast data access 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 uses a user-based authentication model rather than IP or MAC address based authentication model. The benefits of a user-based model are well known. It offers 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 who provide 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 watched and how long a Hayashi, He, Tanabe, Satou, Niki [Page 2] Internet Draft draft-hayashi-mlda-00.txt June, 2003 user watches so that they can charge the user differently based on the values of the TV programs. In such services, content providers and TV program owners need to know how many viewers for a TV program and how long they watch the TV program so they can generate appropriate advertisement revenue. MLDA combines the 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. The 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 first 24 octets consist of the same fields of MLDv1 [MLDv1]. An Auxiliary Data is following. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | Hayashi, He, Tanabe, Satou, Niki [Page 3] Internet Draft draft-hayashi-mlda-00.txt June, 2003 + Multicast Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Subtype | # of Aux (N) | 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) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 2.1. Type There are four types of MLDA messages. 0x96 = MLDA Listener Query (MLDA Query) 0x97 = MLDA Listener Acknowledgement (MLDA ACK) 0x98 = MLDA Listener Report (MLDA Report) 0x99 = MLDA Listener Done (MLDA Done) Unrecognized message types should be silently ignored. 2.2. Code The meaning and the usage of Code are the same as those of the MLD messages as described in RFC 2710 [MLDv1]. 2.3. Checksum Checksum covers the MLDA message (covering fields are same as those of the MLD message as described in RFC 2710 [MLDv1]. 2.4. Maximum Response Delay Hayashi, He, Tanabe, Satou, Niki [Page 4] Internet Draft draft-hayashi-mlda-00.txt June, 2003 The meaning and the usage of Maximum Response Delay are the same as those of the MLD messages as described in RFC 2710 [MLDv1]. 2.5. Reserved-1 This field should be set to 0x00. It is ignored when received. 2.6. Multicast Address In a MLDA Query message, the Multicast Address field is set to zero when sending a General Query, and set to the IP multicast address of interest when the User-Specific Query is sent out as a Multicast-Address-Specific Query. In a MLDA ACK message, the Multicast Address field holds the IP multicast address of interest. In a MLDA Report or Done message, the Multicast Address field holds the IP multicast address of interest or the address being ceasing to listen. 2.7. Version This field indicates the version of MLDA. It is set to 0x10 to indicate the MLDA version 1. 2.8. 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 In Type 0x98 (MLDA Report), there are four Subtypes as follows. Hayashi, He, Tanabe, Satou, Niki [Page 5] Internet Draft draft-hayashi-mlda-00.txt June, 2003 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 In Type 0x99 (MLDA Done), there are four Subtypes as follows. 0x41 : Password Mechanism Done (Password Done) 0x42 : Challenge-Response Mechanism Done Challenge Request (Challenge-Response Done Request) 0x43 : Challenge-Response Mechanism Done Response (Challenge-Response Done Response) 0x44 : Basic Done 2.9. # of Aux (N) This field indicates the number of Auxiliary Data Record stored in a MLDA packet. 2.10. Reserved-2 This field should be set to 0x00. It is ignored when received. 2.11 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. 0x01 = User Account 0x02 = User Password 0x03 = Message 0x10 = Challenge-Response ID (Challenge ID) 0x20 = No-blackout 0xA0 ~ 0xBF = Vendor specific data 3. Protocol Description MLDA is used for controlled or managed multicast services. MLD is not needed when MLDA is used. An MLDA router should ignore all MLD messages received on interfaces where MLDA is configured. The MLDA Hayashi, He, Tanabe, Satou, Niki [Page 6] Internet Draft draft-hayashi-mlda-00.txt June, 2003 message can be differentiated from the MLDA messages by the values of the "type" fields as specified above. MLDA tracks individual host's multicast listener information. This feature allows an MLDA router to implement "fast leave" feature. In another word, MLDA does not implement Multicast-Address-Specific Query feature that MLDv1 has. When a MLDA router receives a MLDA Done message, it will not send Multicast-Address-Specific Query. Instead it will just delete corresponding state information. To facilitate tracking individual host's listening IP multicast information, Host Suppression feature is not allowed in MLDA. The current version of MLDA does not support source filter features and such feature will be supported in the future version of MLDA. MLDA is used for controlled or managed multicast services. A user must use MLDA to access such multicast services. MLD is not needed when MLDA is used. An MLDA router will ignore all MLD messages. MLDA specifies different behaviors for MLDA hosts and for MLDA routers. If an MLDA router attempts 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 is configured to be used in a network. An MLDA implementation must support password authentication mechanism. Challenge-response authentication mechanism is optional. MLDA is intended for use with standard AAA servers such as RADIUS [RADIUS] servers that with necessary extensions can be used to achieve the authentication, authorization and accounting functions described in this document. However, MLDA is not limited for use with only 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 No-blackout and any 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. 3.2 MLDA Host side Protocol Description Hayashi, He, Tanabe, Satou, Niki [Page 7] Internet Draft draft-hayashi-mlda-00.txt June, 2003 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 RFC 2710 [MLDv1]. 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 0x03, 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 Done message to the all-routers multicast address (FF02::2). Normally an MLDA host sends a Done message that has a Subtype field of 0x41 (Basic Done). The Basic Done 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 Done message authentication is required, an MLDA host can send a Done message that has a Subtype field of 0x42 (Password Done). The Password Done 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 Done. 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. When an Hayashi, He, Tanabe, Satou, Niki [Page 8] Internet Draft draft-hayashi-mlda-00.txt June, 2003 MLDA host sends a MLDA Report after sending a DONE, the host may send the MLDA Report with Aux. Record of No-blackout for indicating the sending Report action. The value of the Aux. Record is a random number of 2 bytes. In this case the MLDA should send the DONE with the same value of the Aux. Record. An MLDA implementation must support Basic Done. Password Done is optional. 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 Done message to the all-routers multicast address (FF02::2). Normally an MLDA host sends a Basic Done message as described above. In scenarios where Done message authentication is required, an MLDA host can send a Done message that has a Subtype field of 0x42 (Challenge-Response Mechanism Done 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 Done Request, it sends a Done message that has a Subtype field of 0x43 (Challenge-Response Mechanism Done Response). The message must have three auxiliary data of User Account, User Hayashi, He, Tanabe, Satou, Niki [Page 9] Internet Draft draft-hayashi-mlda-00.txt June, 2003 Password, and Challenge ID at least. The Aux Data field of User Account and the Aux Data Len field are the same to those of Challenge-Response Done Request. The Aux Data field of User Password is set to the results of MD5 calculation. The Aux Data Len field is set to 0x10. When an MLDA host sends a MLDA Report after sending a DONE, the host may send any MLDA Report with Aux. Record of No-blackout for indicating the sending Report action. The value of the Aux. Record is a random number of 2 bytes. In this case the MLDA should send any DONE with the same value of the Aux. Record. An MLDA implementation must support Basic Done. Challenge-Response Authentication Mechanism Done is optional. 3.3 MLDA Router side 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: (multicast address, user-id, client IP, 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 RFC 2710 [MLDv1]. An Basic Query is addressed to the all-systems multicast address (FF02::1), has a Multicast Address field of 0, 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 RFC 2710 [MLDv1]. 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 0x03 (User-Specific Query for Re-authentication). A Maximum Response Delay of [Query Response Interval] is same to that of Basic Query. [Query Response Interval] is same as RFC 2710 [MLDv1]. When an MLDA router receives an MLDA Report or an MLDA Done, it takes different actions based on the configured authentication mechanism. Hayashi, He, Tanabe, Satou, Niki [Page 10] Internet Draft draft-hayashi-mlda-00.txt June, 2003 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 associate timer. If the router does not have the listener state of the multicast address, it forwards the user's listener Response 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 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 Done message for an address that has listeners on the reception interface, it deletes the corresponding multicast address state. If Done message authentication is required, an MLDA Done (Password Done) must have a Subtype field of 0x41, 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 (Done) 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 Hayashi, He, Tanabe, Satou, Niki [Page 11] Internet Draft draft-hayashi-mlda-00.txt June, 2003 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 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 Done message to a multicast address that has multicast listeners on the reception interface, it deletes the corresponding multicast listener state. If Done message authentication is required, a host oriented Challenge-Response communication is establish between a host and the MLDA router. When a MLDA router receives an Challenge-Response Done Request that has a Subtype field of 0x42, 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 the same user ID in the Challenge-Request-Done, and a Message set to a Challenge value [CHAP]). When the MLDA router receives a Challenge-Response Done Response that has a Subtype field of 0x44. 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 (Done) request is ignored. An MLDA implementation must support Basic Done. Challenge-Response Authentication Mechanism Done is optional. 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 Hayashi, He, Tanabe, Satou, Niki [Page 12] Internet Draft draft-hayashi-mlda-00.txt June, 2003 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 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 13] Internet Draft draft-hayashi-mlda-00.txt June, 2003 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. MLDA Finite State Machines on Password authentication This section provides an example of MLDA Finite State Machines (FSMs) when Password authentication mechanism is used. In this example, the value of Validity-Period is set to infinity, and the Basic-Done is used. We also assume that an AAA server is used and the Authentication and Accounting packets are operated between MLDA routers and AAA servers. 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. 4.1. FSM for Client PC1[Non Listener]: if listen multicast{ send Password-Report; start Host-Authentication-Timer; transition PC2; } PC2[Waiting Authentication Message Listener]: if Authentication-Message(Reject) received or Host-Authentication-Timer expired{ Hayashi, He, Tanabe, Satou, Niki [Page 14] Internet Draft draft-hayashi-mlda-00.txt June, 2003 stop Host-Authentication-Timer; transition PC1; } else if Authentication-Message(Success) received{ stop Host-Authentication-Timer; transition PC3; } PC3[Idle Listener]: if General-Query received{ start Delaying-Timer; transition PC4; } else if cease to listen multicast{ send Basic-Done; transition PC5; } PC4[Delaying Listener]: if cease to listen multicast{ send Basic-Done; stop Delaying-Timer; start Host-Accounting-Timer; set Cease-Retransmission-Counter; transition PC5; } else(Delaying-Timer expired){ send Password-Report; stop Delaying-Timer; transition PC2; } PC5[Waiting Accounting Message Listener]: if Accounting-Message(Stop) received{ stop Host-Accounting-Timer; transition PC1; } else if General-Query received{ if (Cease-Retransmission-Counter > 0) { Cease-Retransmission-Counter--; send Basic-Done; continue(no transition); } } else(Host-Accounting-Timer expired){ if (Cease-Retransmission-Counter > 0) { Cease-Retransmission-Counter--; send Basic-Done; restart Host-Accounting-Timer; continue(no transition); } Hayashi, He, Tanabe, Satou, Niki [Page 15] Internet Draft draft-hayashi-mlda-00.txt June, 2003 else{ stop Host-Accounting-Timer; transition PC1; } } 4.2. FSM for MLDA router PR1[No Transfer Present]: if Password-Report received{ send Authentication Request to AAA server; start Router-Authentication-Timer; transition PR2; } else if Basic-Done received{ if (Accounting-Retransmission-Counter > 0) { Accounting-Retransmission-Counter--; send Accounting-Request(Stop) to AAA server; transition PR5; } } PR2[Waiting Authentication-Response]: if Access-Reject received{ send Authentication-Message(Reject); stop Router-Authentication-Timer; transition PR1; } else if Access-Accept received{ if (Immediate-Accounting == true) { send Accounting-Request(Start) to AAA server; send Authentication-Message(Success); stop Router-Authentication-Timer; start Router-Accounting-Timer; transition PR3; } else { start Multicast-Listener-Interval-Timer; send Authentication-Message(Success); stop Router-Authentication-Timer; transition PR6; } } else(Router-Authentication-Timer expired){ if (Free-Ride == true) { stop Router-Authentication-Timer; start Multicast-Listener-Interval-Timer; transition PR4; } else { Hayashi, He, Tanabe, Satou, Niki [Page 16] Internet Draft draft-hayashi-mlda-00.txt June, 2003 stop Router-Authentication-Timer; transition to PR1; } } PR3[Waiting Accounting-Response(Start)]: if Accounting-Response received from AAA server{ send Accounting-Message(Start); stop Router-Accounting-Timer; start Multicast-Listener-Interval-Timer; transition PR4; } else(Router-Accounting-Timer expired){ stop Router-Accounting-Timer; if ( Accounting-Anyway == true){ start Multicast-Listener-Interval-Timer; } transition PR4; } PR4[Transfer Present]: if Password-Report received{ restart Multicast-Listener-Interval-Timer; continue(no transition); } else if Basic-Done received{ send Accounting-Request(Stop) to AAA server; set Accounting-Retransmission-Counter; stop Multicast-Listener-Interval-Timer; start Router-Accounting-Timer; transition PR5; } else(Multicast-Listener-Interval-Timer expired){ send Accounting-Request(Stop); start Router-Accounting-Timer; transition PR5; } PR5[Waiting Accounting-Response(Stop) for Done]: if Accounting-Response received from AAA server{ send Accounting-Message(stop); stop Router-Accounting-Timer; transition PR1; } else(Router-Accounting-Timer expired){ if (Accounting-Retransmission-Counter > 0){ Accounting-Retransmission-Counter--; send Accounting-Request(Stop) to AAA server; start Router-Accounting-Timer; continue(no transition); } Hayashi, He, Tanabe, Satou, Niki [Page 17] Internet Draft draft-hayashi-mlda-00.txt June, 2003 else{ stop Router-Accounting-Timer; transition PR1; } } PR6[Waiting Data transmission]: if Data for listened multicast received{ send Accounting-Request(start) to AAA server; start Router-Accounting-Timer; transition PR3; } else if Basic-Done received{ send Accounting-Request(Stop) to AAA server; stop Multicast-Listener-Interval-Timer; start Router-Accounting-Timer; transition PR5; } 5. MLDA Finite State Machines on Challenge-Response This section provides an example of MLDA Finite State Machines (FSMs) when Challenge-Response authentication mechanism is used. In this example, the value of Validity-Period is set to a finite value, and the Basic-Done is used. We also assume that an AAA server is used and the Authentication and Accounting packets are operated between MLDA routers and AAA servers. 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. 5.1. FSM for Client CC1[Non Listener]: if listen multicast{ send Challenge-Request-Report; start Challenge-Timer; transition CC2; } CC2[Waiting Challenge Listener]: if Challenge received{ send Challenge-Response-Report; stop Challenge-Timer; start Host-Authentication-Timer; transition CC3; } else(Challenge-Timer expired){ Hayashi, He, Tanabe, Satou, Niki [Page 18] Internet Draft draft-hayashi-mlda-00.txt June, 2003 stop Challenge-Timer; transition CC1; } CC3[Waiting Authentication Message Listener]: if Authentication-Message(Reject) received or Host-Authentication-Timer expired{ stop Host-Authentication-Timer; transition CC1; } else if Authentication-Message(Success) received stop Host-Authentication-Timer; transition CC4; } CC4[Idle Listener]: if General-Query received{ start Delaying-Timer; transition CC5; } else if cease to listen multicast{ send Basic-Done; start Host-Accounting-Timer; transition CC6; } CC5[Delaying Listener]: if cease to listen multicast{ send Basic-Done; stop Delaying-Timer; start Host-Accounting-Timer; set Cease-Retransmission-Counter; transition CC6; } else(Delaying-Timer expired){ send Challenge-Request-Report; stop Delaying-Timer; start Challenge-Timer; transition CC2; } CC6[Waiting Accounting Message Listener]: if Accounting-Message(Stop) received{ stop Host-Accounting-Timer; transition CC1; } else if General-Query received{ if (Cease-Retransmission-Counter > 0) { Cease-Retransmission-Counter--; send Basic-Done; continue(no transition); Hayashi, He, Tanabe, Satou, Niki [Page 19] Internet Draft draft-hayashi-mlda-00.txt June, 2003 } } else(Host-Accounting-Timer expired){ if (Cease-Retransmission-Counter > 0) { Cease-Retransmission-Counter--; send Basic-Done; restart Host-Accounting-Timer; continue(no transition); } else{ stop Host-Accounting-Timer; transition CC1; } } 5.2. FSM for MLDA router CR1[No Transfer Present]: if Challenge-Request-Report received{ send Challenge; start Response-Timer; transition CR2; } else if Basic-Done received{ if (Accounting-Retransmission-Counter > 0){ Accounting-Retransmission-Counter--; send Accounting-Request(Stop); to AAA server transition CR7; } } CR2[Waiting Challenge-Response]: if Challenge-Response-Report received{ send Authentication Request; stop Response-Timer; start Router-Authentication-Timer; transition CR3; } else(Response-Timer expired){ stop Response-Timer; transition CR1; } CR3[Waiting Authentication-Response]: if Access-Reject received from AAA server{ send Authentication-Message(Reject); stop Router-Authentication-Timer; transition CR1; } else if Access-Accept received{ Hayashi, He, Tanabe, Satou, Niki [Page 20] Internet Draft draft-hayashi-mlda-00.txt June, 2003 if (Immediate-Accounting == true){ send Accounting-Request(Start) to AAA server; send Authentication-Message(Success); stop Router-Authentication-Timer; start Router-Accounting-Timer; transition CR4; } else{ start Multicast-Listener-Interval -Timer; send Authentication-Message(Success); stop Router-Authentication-Timer; transition CR8; } } else(Router-Authentication-Timer expired){ if (Free-Ride == true){ stop Router-Authentication-Timer; start Multicast-Listener-Interval-Timer; start Validity-Timer; transition CR5; } else{ stop Router-Authentication-Timer; transition to CR1; } } CR4[Waiting Accounting-Response(Start)]: if Accounting-Response received from AAA server{ send Accounting-Message(Start); stop Router-Accounting-Timer; start Multicast-Listener-Interval-Timer; start Validity-Timer; transition CR5; } else(Router-Accounting-Timer expired){ stop Router-Accounting-Timer; if (Accounting-Anyway == true){ start Multicast-Listener-Interval-Timer; } start Validity-Timer; transition CR5; } CR5[Transfer Present]: if Challenge-Request-Report received{ if Validity-Timer < Validity-Period{ restart Multicast-Listener-Interval-Timer; continue(no transition); } else(Validity-Timer expired){ Hayashi, He, Tanabe, Satou, Niki [Page 21] Internet Draft draft-hayashi-mlda-00.txt June, 2003 send Accounting-Request(Stop); stop Validity-Timer; stop Multicast-Listener-Interval-Timer; start Router-Accounting-Timer transition CR6; } } else if Basic-Done received{ if (Accounting-Retransmission-Counter > 0){ Accounting-Retransmission-Counter--; send Accounting-Request(Stop) to AAA server; stop Multicast-Listener-Interval-Timer; stop Validity-Timer; start Router-Accounting-Timer; transition CR7; } else{ transition CR1; } } else(Multicast-Listener-Interval-Timer expired){ send Accounting-Request(Stop) to AAA server; stop Validity-Timer; start Router-Accounting-Timer; transition CR7; } CR6[Waiting Accounting-Response(Stop)]: if Accounting-Response received from AAA server{ send Accounting-Message(Stop); send Challenge; stop Router-Accounting-Timer; start Response-Timer; transition CR2; } else(Router-Accounting-Timer expired){ stop Router-Accounting-Timer; start Validity-Timer; transition CR5; } CR7[Waiting Accounting-Response(Stop) for Done]: if Accounting-Response received{ send Accounting-Message(stop); stop Router-Accounting-Timer; transition CR1; } else(Router-Accounting-Timer expired){ if (Accounting-Retransmission-Counter > 0){ Accounting-Retransmission-Counter--; send Accounting-Request(Stop); Hayashi, He, Tanabe, Satou, Niki [Page 22] Internet Draft draft-hayashi-mlda-00.txt June, 2003 start Router-Accounting-Timer; continue(no transition); } else{ stop Router-Accounting-Timer; transition CR1; } } CR8[Waiting Data transmission]: if Data for listened multicast received{ send Accounting-Request(start) to AAA server; start Router-Accounting-Timer; transition CR4; } else if Basic-Done received{ if (Accounting-Retransmission-Counter > 0){ Accounting-Retransmission-Counter--; send Accounting-Request(Stop) to AAA server; stop Multicast-Listener-Interval-Timer; start Router-Accounting-Timer; transition CR7; } else{ transition CR1; } } 6. MLDA State Machines of Query Process This Section describes an example of MLDA State Machines on Query Process. QR1[Initial]: start MLDA{ send General-Query; start Startup-Query-Interval-Timer; start Startup-Query-Counter; transition QR2; } QR2[Startup] if Startup-Query-Interval-Timer expired{ if Startup-Query-Counter < Startup-Query-Count{ send General-Query; restart Startup-Query-Interval-Timer; continue(no transition) } else{ send General-Query; Hayashi, He, Tanabe, Satou, Niki [Page 23] Internet Draft draft-hayashi-mlda-00.txt June, 2003 stop Startup-Query-Counter; start Query-Interval-Timer; transition QR3; } } QR3[Affirmed Connection]: if Query-Interval-Timer expired{ if re-authentication is needed send User-Specific-Query; else send General-Query; restart Query-Interval-Timer; continue(no transition); } 7. List of Timers, Counters This section describes the parameters set in MLDA router and Host when supporting MLDA processes. 7.1. Robustness Variable It is the same meaning as MLDv1. 7.2. Timers and Counters for Host 7.2.1. Challenge-Timer It controls waiting time from sending Report message to receiving Challenge Message. 7.2.2. Host-Authentication-Timer It controls waiting time from sending Response Message to receiving Authentication Message (accept or reject) from MLDA router. 7.2.3. Host-Accounting-Timer It controls waiting time from sending Response Message to receiving Accounting Message (start or stop) from MLDA router. 7.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. 7.2.5. Cease-Retransmission-Counter The Cease-Retransmission-Counter is the number of Done messages a Hayashi, He, Tanabe, Satou, Niki [Page 24] Internet Draft draft-hayashi-mlda-00.txt June, 2003 host retransmits after sending the first Done message. The default value is 0. 7.3. Timers and Counters for MLDA router 7.3.1. Response-Timer It controls waiting time from sending Challenge Message to receiving Response Message. 7.3.2. Router-Authentication-Timer It controls waiting time from sending Authentication request to receiving Authentication Response. 7.3.3. Router-Accounting-Timer It controls waiting time from sending Accounting request to receiving Accounting Response. 7.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. 7.3.5. Query-Interval-Timer It is the same meaning as MLDv1. The Query Interval is the interval between Basic Queries. 7.3.6. Query-Response-Interval-Timer It is the same meaning as MLDv1. The Max Response Time inserted into the periodic Basic Queries. 7.3.7. Multicast-Listener-Interval-Timer The Multicast 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). 7.3.8. Startup-Query-Interval-Timer It is the same meaning as MLDv1. The Startup Query Interval is the interval between General Queries sent by a Querier on startup. 7.3.9. Startup-Query-Counter Hayashi, He, Tanabe, Satou, Niki [Page 25] Internet Draft draft-hayashi-mlda-00.txt June, 2003 It is the same meaning as MLDv1. The Startup Query Count is the number of Queries sent out on startup, separated by the Startup Query Interval. 7.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 0. 7.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. 7.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. 7.3.13 Accounting-Anyway When the value is true, accounting is carried out despite the expiration of Router-Accounting-Timer. 8. 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 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 MLDv1 document [MLDv1] for details. 9. IANA Considerations This document introduces the following new version and Types of ICMP message that require allocation by IANA: Hayashi, He, Tanabe, Satou, Niki [Page 26] Internet Draft draft-hayashi-mlda-00.txt June, 2003 Version: 0x10: MLDA Type: 0x96: MLDA Listener Query (MLDA Query) 0x97: MLDA Listener Acknowledgment (MLDA ACK) 0x98: MLDA Listener Report (MLDA Report) 0x99: MLDA Listener Done (MLDA Done) References [ICMPv6] A. Conta and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998 [MLDv1] S. Deering, W. Fenner, and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [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 Hayashi, He, Tanabe, Satou, Niki [Page 27] Internet Draft draft-hayashi-mlda-00.txt June, 2003 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 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 28]