Internet Engineering Task Force Daisuke Andou, NTT INTERNET-DRAFT Takako Sato, NTT June, 2002 Tsunemasa Hayashi, NTT Expires: December, 2002 Akihiro Tanabe, NTT Kaori Izutsu, NTT Yoshinori Goto, NTT Yukikuni Nishida, NTT Wataru Inoue, NTT IGMP for user Authentication Protocol (IGAP) Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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 describes IGAP, which allows user IP user clients and IP routers or network access servers to verify whether they can participate in a multicast group they hope and transport some information about it. IGAP is derived from IGMPv2, which can make users join a multicast group, who has the claim to participate a multicast group in a service. It's important for service providers to protect their revenue source. 1. Introduction IGMP for user Authentication Protocol (IGAP) allows user clients to connect to network gateways for access-controlled multicast services. These gateways (such as routers and called "authGW" hereafter) have the ability to authenticate the user client's authority to join/leave a multicast group. The security functions offered by IGAP will Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 1] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 encourage the development of new commercial services. This memo describes only the operations between user client and authGW, and omits those about between authGW and authentication servers. 2. Aspects of IGAP IGAP is designed to transport the information for user authentication and accounting, based on IGMPv2 [IGMPv2], for IP Multicast services. IGAP basically adopts the IGMPv2 message format and extends it only slightly. Details not clearly specified in this document are taken to follow the IGMPv2 equivalents. For example, all IGAP messages described in this document are sent via IP TTL 1, and use the IP Router Alert option [IPRA] in their IP header as per the IGMPv2 requirements. IGAP messages are encapsulated in IP datagrams the same as IGMPv2, and the IP protocol number in the IP header is 2, the same as IGMPv2. Note that the value in the IGAP Type field in the header, which is also used by IGMPv2, differs from that of IGMPv2. User clients and routers can distinguish IGAP from IGMPv2 by this field. IGAP can support the use of any security/authentication system. As an example, the user authentication information can include encrypted user passwords. IGAP supports both PAP [PAP] and CHAP [CHAP] mechanisms. IGAP must be implemented on all user clients wishing to join a protected multicast service and all authGWs. AuthGWs support both IGMPv2 and IGAP. The processing of IGAP packets has no impact on the processing of IGMPv2 packets. 3. IGAP Header Format IGAP messages 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 | Max Resp Time | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Report Type | Reserved | CHAP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Account Size | Message Size | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | User Account | | | Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 2] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Upper 8 bytes of the header are equal to those of IGMPv2. This part is called "IGMPv2 compatible part". Lower 40 bytes are the fields that include new information defined in IGAP. Upper 2 bytes of this area, called the "IGAP standard part", are used by all IGAP packet types and carry Version, Report Type, Reserved, and CHAP ID field. Lower 38 bytes are used to carry the information needed for authentication and accounting. This part is called "IGAP optional part". Some IGAP header fields are not used in some processes. Note that IGAP messages may be longer than 48 bytes, especially future versions of IGAP. Any future IGAP implementation must recognize the first ten bytes. The IGAP checksum is always computed over the whole IP payload, not just the first 48 bytes. This chapter describes all of the fields. 3.1. Type Currently, there are three types of IGAP messages. 0x40 = IGAP Membership Report (IGAP Join) This type, sent from user client to authGW, is used to join a multicast group, and to reply to a IGAP Membership Query sent from authGW. Source address of IP header is IP address of the user client sending the packet, and destination address of IP header is desired Group Address. Other details basically follow those of IGMPv2 Membership report. 0x41 = IGAP Membership Query This type, sent from authGW to user client, asks for the current status of multicast packet reception and Group Address. As in IGMPv2, there are two sub-types: General Query and Group Specific Query. The destination address of the former is the all-system multicast group (224.0.0.1). For the latter, it's Group Address which user clients are now receiving. The features of these sub-types are same as per IGMPv2. Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 3] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 0x42 = IGAP Leave Group This type, sent from user client to authGW, is used to leave a multicast group. The IP Header includes source address (IP address of the user client sending the packet), and destination address (224.0.0.2). Other details basically follow those of IGMPv2 Membership report. 3.2. Max Response Time The Max Response Time field is meaningful only for Membership Query messages (Type 0x41), and specifies the maximum allowed time before sending a response; the units are 0.1 seconds. In all other messages, it is set to zero by the sender and ignored by receivers. To prevent excessive burstiness of IGAP traffic on a subnet, the user clients on the subnet should choose a random delay time less than the Max Response Time, and send their Membership Report after this time. 3.3. Checksum The checksum is the 16-bit one's complement of the one's complement sum of the whole IGAP message (the entire IP payload). This algorithm equals that of IGMPv2. 3.4. Group Address In a Membership Query message, the group address field is set to the group address being queried. In a Membership Report or Leave Group message, the group address field holds the IP multicast group address of interest or the group being left. 3.5. Version Version field is set to 0x10 as the value to identify IGAP packets. 3.6. Report Type Report Type field indicates the type of message transferred within the IGAP packet. Usage of this field is described in Chapter 4. In Type 0x40 (IGAP Join), there are four Report Types as follows. 0x01 : Basic Join 0x02 : PAP Join Authentication Request 0x03 : CHAP Join Challenge Request Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 4] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 0x04 : CHAP Join Response In Type 0x41 (IGAP Query), there are seven Report Types as follows. 0x21 : Basic Query 0x22 : User-Specific Query 0x23 : CHAP Challenge 0x24 : Authentication Message 0x25 : Accounting Message 0x26 : Notification Message 0x27 : Error Message In Type 0x42 (IGAP Leave), there are four Report Types as follows. 0x41 : Basic Leave 0x42 : PAP Leave Authentication Request 0x43 : CHAP Leave Challenge Request 0x44 : CHAP Leave Response 3.7. Reserved This field is set to 0xff unless used in a service. 3.8. CHAP ID CHAP ID field is meaningful only when CHAP Authentication is used. AuthGW sets it when sending a CHAP Challenge packet to a user client. User client uses the value in this field in order to create the CHAP Response to reply to the CHAP Challenge. AuthGWs use the value of this field to check the correspondence between CHAP Response and CHAP Challenge. If this field is not used, it is set to the default value of 0x00. 3.9. Account Size This field indicates the size of User Account field in units of bytes. If this field is not used, it is set to the default value of 0x00. 3.10. Message Size This field indicates the size of Message field in units of bytes. If this field is not used, it is set to the default value of 0x00. 3.11. Reserved Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 5] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 This field is set to 0xff unless used in a service. 3.12. User Account This field indicates the user account to be authenticated. The size of this field is 16 bytes. If the size value occupies less than 16 bytes, the value is followed by 0xff. 3.13 Message This field is used according to Report Type. If this field is used for authentication, it carries user password. If CHAP is used, the password is encrypted. The size of this field is 16 bytes. If the value of the size of a message occupies less than 16 bytes, the value is followed by 0xff. 4. IGAP Packet Type IGAP Packet type is determined by the Report Type field. In the following descriptions, fields that are not specifically mentioned are assumed to be "unused". Regardless of the values in unused fields, authGWs should process the packet correctly. Chapter.3 provides details about the fields not shown in this chapter. 4.1. Basic Join Type : 0x40 Group Address : connected group address Report Type : 0x01 User Account : user ID Message : (unused) This packet type is used in the case which the join process does not require the authentication process. 4.2. PAP Join Authentication Request Type : 0x40 Group Address : connected group address Report Type : 0x02 User Account : user ID Message : user password (not encrypted) This packet type is used in the case which the join process require PAP authentication process. Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 6] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 4.3. CHAP Join Challenge Request Type : 0x40 Group Address : connected group address Report Type : 0x03 User Account : user ID Message : (unused) This packet type is used to initiate the challenge process for CHAP authentication. AuthGW received this packet issues CHAP Challenge packet described in Chapter 4.7. 4.4. CHAP Join Response Type : 0x40 Group Address : connected group address Report Type : 0x04 User Account : user ID Message : Response Value This packet type is used to respond to the CHAP Challenge issued by the authGW. The Response Value is determined from two parameters. One is the Challenge Value, which is in the CHAP Challenge packet, described in chapter 4.7. The other is the value calculated from the user password by MD5 [MD5]. 4.5. Basic Query This packet type is used in the case which authGW checks whether the user client(s) are receiving multicast traffic at regular intervals, and authGW confirms the user client's request to leave a multicast group. There are two sub-types of Basic Query, as described in section 3.1. In the case of General Query, i.e. destination address of IP header is the all-systems multicast group (224.0.0.1), it's called the General-and-Basic Query. In this sub-type, the value of Group Address field is set to zero. In the case of Group Specific Query, i.e. destination address of IP header is the desired group address, it's called the Group-Specific-and-Basic Query. In this sub-type, the value of Group Address field is equal to the value of the desired destination address. This packet type doesn't have to have IGAP optional part. 4.5.1. General-and-Basic Query Type : 0x41 Group Address : (set to zero) MaxRespTime : given value (default : 0x64) Report Type : 0x21 Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 7] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 IGAP optional part : (unused) 4.5.2. Group-Specific-and-Basic Query Type : 0x41 Group Address : connected group address MaxRespTime : given value (default : 0x64) Report Type : 0x21 IGAP optional part : (unused) 4.6. User-Specific Query This packet type is used on similar case of Basic Query, but this packet type has IGAP optional part, so authGW can identify the user(s) who is receiving a multicast packet, or leaving. There are also two sub-types as Basic Query. For General Query the first sub-type is called the General-and-User-Specific Query. In this sub-type, the value of Group Address field is set to zero. For Group Specific Query, the sub-type is called the Group-and-User-Specific Query. In this sub-type, the value of Group Address field is equal to the value of the desired destination address. 4.6.1. General-and-User-Specific Query Type : 0x41 Group Address : (set to zero) MaxRespTime : given value (default : 0x64) Report Type : 0x22 User Account : user ID Message : (unused) 4.6.2. Group-and-User-Specific Query Type : 0x41 Group Address : connected group address MaxRespTime : given value (default : 0x64) Report Type : 0x22 User Account : user ID Message : (unused) 4.7. CHAP Challenge Type : 0x41 MaxRespTime : given value (default : 0x64) Group Address : connected group address Report Type : 0x23 Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 8] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 User Account : user ID Message : Challenge Value This packet type is used in the case which authGW responds to CHAP Join Challenge Request from user client. AuthGW sends this packet to notify Challenge Value. User client received this packet issues CHAP Join Response packet described in Chapter 4.4. 4.8. Authentication Message Type : 0x41 MaxRespTime : given value (default : 0x64) Group Address : connected group address Report Type : 0x24 User Account : user ID Message : 0x11 (Authentication Success) or 0x21 (Authentication Reject) or other value (vendor specific) This packet type is used in the case which authGW provides information about the result of authentication. The Message field holds one of two values: either authentication succeed or authentication reject. The process adopted by the user client upon receiving this packet type is up to implementation, however, neither value must impact other IGAP process. Vendors may add their own specific values to the Message field, but the values used must not impact any other IGAP process. 4.9. Accounting Message Type : 0x41 MaxRespTime : given value (default : 0x64) Group Address : connected group address Report Type : 0x25 User Account : user ID Message : 0x11 (Accounting Start) or 0x21 (Accounting Stop) or other value (vendor specific) This packet type is used in the case which authGW provides information about accounting status. The Message field holds one of two values: one indicates the start of accounting, and the other indicates the termination of accounting. The process adopted by the user client upon receiving this packet type is up to implementation, however, neither value must impact other IGAP process. The same is true for the vendor-specified values. 4.10. Notification Message Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 9] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 Type : 0x41 MaxRespTime : given value (default : 0x64) Group Address : connected group address Report Type : 0x26 User Account : user ID Message : vendor specific value This packet type is used in the case which authGW provides information about an correct status in IGAP process, except authentication and accounting. The process adopted by the user client upon receiving this packet type is up to implementation, however, neither value must impact other IGAP process. The value of Message field in this packet type isn't defined in this document. Vendors may add their own specific values to the Message field, but the values used must not impact any other IGAP process. 4.11. Error Message Type : 0x41 MaxRespTime : given value (default : 0x64) Group Address : connected group address Report Type : 0x27 User Account : user ID Message : vendor specific value This packet type is used in the case which authGW provides information about an error status in IGAP process, except authentication and accounting. The process adopted by the user client upon receiving this packet type is up to implementation, however, neither value must impact other IGAP process. The value of Message field in this packet type isn't defined in this document. The same is true for the vendor-specified values. 4.12. Basic Leave Type : 0x42 Group Address : connected group address Report Type : 0x41 User Account : user ID Message : (unused) This packet type is used in the case which the leave process does not require the authentication process. 4.13. PAP Leave Authentication Request Type : 0x42 Group Address : connected group address Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 10] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 Report Type : 0x42 User Account : user ID Message : user password (not encrypted) This packet type is used in the case which the leave process require PAP authentication process. 4.14. CHAP Leave Challenge Request Type : 0x42 Group Address : connected group address Report Type : 0x43 User Account : user ID Message : (unused) This packet type is used to initiate the challenge process for CHAP authentication. AuthGW received this packet issues CHAP Challenge packet described in Chapter 4.7. 4.15. CHAP Leave Response Type : 0x42 Group Address : connected group address Report Type : 0x44 User Account : user ID Message : Response Value This packet type is used to respond to the CHAP Challenge issued by the authGW. The algorithm used to calculate the Response value is the same method of CHAP Join Response. References [IGMPv2] W. Fenner, "Internet Group Management Protocol, Version 2", RFC 2236, Xerox PARC, November 1997. [PAP] B.Lloyd, W. Simson, "PPP Authentication Protocols", RFC 1334, Octover, 1992. [CHAP] W. Simson, "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [IPRA] D. Katz, "IP Router Alert Option", RFC 2113, Cisco Systems, Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 11] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 February 1997. [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. [RADACCT] C. Rigney, "RADIUS Accounting", RFC 2866, Livingston, June 2000. Author's Addresses Daisuke Andou, Takako Satou, Akihiro Tanabe, Kaori Izutsu, Yoshinori Gotou NTT Access Network Service Systems Laboratories 1-6 Nakase Mihiama-ku, Chiba-shi, Chiba, 261-0023 Japan Phone : +81 43 211 2115 Email : {dandou, t-sato, atanabe, izutsu, goto}@ansl.ntt.co.jp Tsunemasa Hayashi NTT Network Innovation Laboratories 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan Phone : +81 468 59 8790 Email : hayashi@exa.onlab.ntt.co.jp Yukikuni Nishida, Wataru Inoue NTT Cyber Solutions Laboratories 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan Phone : +81 468 59 3496 Email : {nishida.yukikuni, inoue.wataru}@lab.ntt.co.jp Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 12] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 Appendix 1. Examples of Vendor Specific Authentication Messages This appendix provides examples of Message field contents as specified by the vendor for Authentication Message (see Chapter 4.8). The vendor must enter the appropriate values in each message except for the values specified by this document, i.e. 0x11 (Authentication Success) and 0x21 (Authentication Reject). The cases wherein the user can't receive the multicast packets requested are described below. These messages indicate the reason for the failure of authentication, and they are sent instead of the Authentication Reject message (0x21). 0x31 : Unknown User Account When the user ID in the User Account field (Chapter 3.12) is not registered on the Authentication server, authGW sends this message packet to user client. 0x32 : Unknown Group Address When authGW receives notification that the group address in the Group Address field (Chapter 3.4) is not used in the service requested from authentication server, authGW sends this message packet to user client. 0x33 : Request to participate in a multicast group rejected When the user doesn't have a valid claim to participate in the multicast group specified in the Group Address field, authGW sends this message packet to user client. 0x41 : Invalid Group Address When the group address in the Group Address field is not registered with the address list in authGW, authGW sends this message packet to user client. In this case, authGW doesn't send any packet to the authentication server. The usage of this message is described in Appendix 9. Appendix 2. Examples of Vendor Specific Accounting Messages This appendix provides examples of Message field values entered by the vendor into the Accounting Message (see Chapter 4.9). The vendor must enter the appropriate values in each message except for the values specified by this document, i.e. 0x11 (Accounting Start) and Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 13] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 0x21 (Accounting Stop). 0x31 : Notification of charge-free When the accounting process is not needed, authGW sends this message packet to user client. 0x32 : Notification of excess time In the case where there is a time limit to participate in a multicast group and the user client sending an IGAP join packet has already reached the time limit, authGW sends this message packet to user client. Appendix 3. Examples of Vendor Specific Notification Message This appendix provides examples of Message field values entered by the vendor into Notification Message (see Chapter 4.10). 0x11 : Notification of delivery When authGW starts or continues to send multicast packets, authGW sends this message packet to user client. 0x12 : Notification of delivery stop When authGW stops sending multicast packets, authGW sends this message packet to user client. 0x13 : Notification of time out If there is a time limit to participate in a multicast group and time out been triggered while user client is participating in the multicast group, authGW sends this message packet to user client. Appendix 4. Examples of Vendor Specific Error Messages This appendix describes the examples of Message field values entered by the vendor into Error Message (see Chapter 4.11). 0x11 : Response time out of authentication server When the response packet indicating acceptance or rejection didn't Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 14] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 arrive at authGW from the authentication server in authentication process, authGW determines that authentication server is "dead", and sends this message packet to user client. The usage of this message is described in Chapter A-3 of Appendix 5. 0x12 : Multicast packets not being delivered When authGW doesn't receive multicast packets of the desired group address, e.g. router due to network accident, authGW sends this message packet to user client. The usage of this message is described in Chapter A-4 of Appendix 5. Appendix 5. IGAP sequence with PAP mechanism This appendix describes examples of IGAP sequences with PAP mechanism. In the figures in this appendix, IGAP packet types are abbreviated as follows. IGAP Join (Type:0x40) PAP Join Authentication Request (Report Type:0x02) : PAP Join IGAP Membership Query (Type:0x41) General-and-Basic Query (Report Type:0x21) : G&B Query Group-Specific-and-Basic Query (Report Type:0x21) : GS&B Query Authentication Message (Report Type:0x24) : Auth Message Accounting Message (Report Type:0x25) : Acct Message Notification Message (Report Type:0x26) : Ntf Message Error Message (Report Type:0x27) : Err Message IGAP Leave (Type:0x42) Basic Leave (Report Type:0x41) : Bsc Leave In the examples of this appendix, destination address of IP header in Authentication Message, Accounting Message, Notification Message and Error Message, is IP address of user client. RADIUS is used as authentication with PAP and accounting mechanism. User client should have a function to display notification message depending on Message packet received, so the user can know what happened in IGAP process. In the figures in this appendix, transferred packet has the following form. Type Name[Type (No.)] (Report Type Name [Report Type (No.)]) (Message[(No.)]) (Message[(No.)]) is described for the cases where Report Type is Authentication Message, Accounting Message, Notification Message or Error Message. Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 15] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 Arrowheads in the figure have the following meanings. -----> : IGAP packet ====>> : Multicast packet Types of Packet transferred between AuthGW and RADIUS server are fully compliant with RADIUS specifications. A. Process for user client to start receiving multicast packets This chapter describes the process whereby user client can start (or not to start) to receive multicast packets. In the process, user client sends IGAP Join message to authGW, and authGW asks authentication (RADIUS) server whether desired multicast packets can be transferred to the user client, if authentication is needed, and notifies the result to the user client via one of the IGAP Membership Query messages. The decision whether authentication is needed or not in the process is entrusted to authGW. Details of the decision are described in Appendix.9. A-1. Access accept client AuthGW RADIUS server v v v | Join[0x40] | | | (PAP Join[0x02]) | Access | |--------------------->| Request | | |----------------->| | Query[0x41] | Access | | (Auth Message[0x24]) | Accept | | (Message[0x11]) |<-----------------| |<---------------------| | | Multicast traffic | Accounting | |<<====================| Request(Start) | | |----------------->| | Query[0x41] | Accounting | | (Acct Message[0x25]) | Response | | (Message[0x11]) |<-----------------| |<---------------------| | | | | Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 16] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 A-2. Access reject client AuthGW RADIUS server v v v | Join[0x40] | | | (PAP Join[0x02]) | Access | |--------------------->| Request | | |----------------->| | Query[0x41] | Access | | (Auth Message[0x24]) | Reject | | (Message[0x21]) |<-----------------| |<---------------------| | | | | A-3. No response (time out) of RADIUS server client AuthGW RADIUS server v v v | Join[0x40] | | | (PAP Join[0x02]) | Access | |--------------------->| Request | | |----------------->| | Query[0x41] | | |(Error Message[0x27]) | (No Response) | | (Message[0x11]) | | |<---------------------| | | | | AuthGW sets three parameters for communication with the authentication server: RADIUS Retrying Count, RADIUS Transmit Interval and RADIUS Waiting Interval. These parameters are described in Appendix 8. If the response packet from the RADIUS server indicating acceptance or rejection fails to arrive at authGW, authGW resends Access Request at intervals of RADIUS Retrying Interval until the number of retransmissions reaches RADIUS Retrying Count. When RADIUS Transmit Waiting Interval expires, authGW determines that the authentication server is dead, and sends IGAP Error Message packet to user client. A-4. Access to invalid address client AuthGW RADIUS server v v v | Join[0x40] | | | (PAP Join[0x02]) | | |--------------------->| | | Query[0x41] | | | (Auth Message[0x24]) | | | (Message[0x41]) | | |<---------------------| | | | | Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 17] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 AuthGW can identify whether multicast address sent from user client is available. (described in Appendix 9). If the multicast address is not registered with the address list in authGW, authGW determines that this address is invalid, and sends IGAP Error Message packet to user client. A-5. Multicast packets not being delivered to authGW client AuthGW RADIUS server v v v | Join[0x40] | | | (PAP Join[0x02]) | Access | |--------------------->| Request | | |----------------->| | | Access | | | Accept | | |<-----------------| |(No Multicast Packet) | | | | | | query[0x41] | | |(Error Message[0x27]) | | | (Message[0x12]) | | |<---------------------| | | | | When authGW can't send multicast packets of the desired group address even though authGW has received Access Accept, authGW sends IGAP Error Message packet to user client. Even if authentication is not needed, authGW sends the same error message. A-6. Neither authentication nor accounting is needed (e.g. Free Channel) client AuthGW RADIUS server v v v | Join[0x40] | | | (PAP Join[0x02]) | | |--------------------->| | | Multicast traffic | | |<<====================| | | | | | Query[0x41] | | | (Ntf Message[0x26]) | | | (Message[0x11]) | | |<---------------------| | | | | AuthGW doesn't have to send Authentication Message and Accounting Message and instead sends Notification Message instead. Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 18] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 B. Process to continue receiving multicast packet for user client This chapter describes the process whereby the user client who has already received multicast packets, continues to receive them or not. In the process, authGW sends IGAP Membership Query message (described in Chapter 3.1) to user client to query whether it is receiving the multicast packets or not, as is done in IGMPv2. The Query message is sent at regular intervals, the period of which is decided by Query Interval [IGMPv2]. Upon receiving IGAP Membership Query message, user client sends IGAP Join message to authGW as the reply. User client set the interval randomly in replying to IGAP Membership Query message, but the value is always less than Max Resp Time (described in Chapter 3.2). In some processes, user client is re-authenticated. The interval of re-authentication depends on Validity Period. This value is set in authentication (RADIUS) server, and is sent to authGW. The value of Validity Period is an integer multiple of Query Interval in units of second. For example, if the value of Query Interval is 60 and the value of Validity Period is 600, authGW asks the authentication (RADIUS) server every 10 processes as to whether requested multicast packets should be transferred to the user client. Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 19] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 B-1. Access accept client AuthGW RADIUS server v v v | Multicast traffic | | |<<====================| | | | | | Query[0x41] | | | (G&B Query[0x21]) | | |<---------------------| | | Join[0x40] | | | (PAP Join[0x02]) | Accounting | |--------------------->| Request(Stop) | | |----------------->| | | Accounting | | Query[0x41] | Response | | (Acct Message[0x25]) |<-----------------| | (Message[0x21]) | | |<---------------------| Access | | | Request | | |----------------->| | Query[0x41] | Access | | (Auth Message[0x24]) | Accept | | (Message[0x11]) |<-----------------| |<---------------------| Accounting | | | Request(Start) | | |----------------->| | Query[0x41] | Accounting | | (Acct Message[0x25]) | Response | | (Message[0x11]) |<-----------------| |<---------------------| | | | | | Continue to cast | | | Multicast traffic | | |<<====================| | | | | Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 20] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 B-2. Access reject client AuthGW RADIUS server v v v | Multicast traffic | | |<<====================| | | | | | Query[0x41] | | | (G&B Query[0x21]) | | |<---------------------| | | Join[0x40] | | | (PAP Join[0x02]) | Accounting | |--------------------->| Request(Stop) | | |----------------->| | | Accounting | | Query[0x41] | Response | | (Acct Message[0x25]) |<-----------------| | (Message[0x21]) | | |<---------------------| Access | | | Request | | |----------------->| | Query[0x41] | Access | | (Auth Message[0x24]) | Reject | | (Message[0x21]) |<-----------------| |<---------------------| | | | | | Traffic Stop | | | X<<======| | | | | Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 21] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 B-3. No response (time out) of RADIUS server client AuthGW RADIUS server v v v | Multicast traffic | | |<<====================| | | | | | Query[0x41] | | | (G&B Query[0x21]) | | |<---------------------| | | Join[0x40] | | | (PAP Join[0x02]) | Accounting | |--------------------->| Request(Stop) | | |----------------->| | Query[0x41] | | |(Error Message[0x27]) | (No Response) | | (Message[0x11]) | | |<---------------------| | | | | | Query[0x41] | | | (Acct Message[0x25]) | | | (Message[0x21]) | | |<---------------------| | | | | | Continue to cast | | | Multicast traffic | | |<<====================| | | | | AuthGW sets three parameters when communicating with the authentication server as is described in Chapter A-3 of Appendix 5. These parameters are described in Appendix 9. Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 22] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 B-4. Multicast packets not being delivered to authGW client AuthGW RADIUS server v v v | Multicast traffic | | |<<====================| | | | | | Query[0x41] | | | (G&B Query[0x21]) | | |<---------------------| | | join[0x40] | | | (PAP join[0x02]) | | |--------------------->| | | Query[0x41] | | | (Ntf Message[0x26]) | | | (Message[0x11]) | | |<---------------------| | | | | | Continue to cast | | | Multicast traffic | | |<<====================| | | | | B-5. Network down client AuthGW RADIUS server v v v | Network down | | | X<<======| | | Query[0x41] | | |(Error Message[0x27]) | | | (Message[0x12]) | | |<---------------------| | | | | If multicast packets are not being transferred to authGW, authGW indicates this by releasing IGAP Error Message. C. Process to stop receiving multicast packets for user client There are two ways of leaving a multicast group: Basic Leave Process and Fast Leave Process. Basic Leave Process basically equals the leave process of IGMPv2. When AuthGW receives IGAP Leave message from the user client, it responds by sending Group-Specific Query to the user client (described in Chapter 3.1). Details of the Query message basically follow those of IGMPv2 Membership Query. If authGW doesn't receive any IGAP Join packets from the user client, it determines that the user client no longer desires to be a multicast group member, and stops sending multicast packets. On the other hand, Fast Leave Process dispenses with IGAP Query packets. When AuthGW receives IGAP Leave message from the user Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 23] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 client, it stops sending multicast packets without sending IGAP Query packet. Fast Leave Process is recommended when fast response for IGAP Leave is needed. User client should be able to set resend number of IGAP Leave message and resend interval. These values improve the robustness of IGAP process, e.g. second leave packet reaches authGW, even if first leave packet is lost, which ensures completion of the leave process. In both processes, the decision whether authentication is needed or not is entrusted to authGW. For simplicity, none of the examples in this appendix use authentication. C-1. Success of Basic Leave Process client AuthGW RADIUS server v v v | Multicast traffic | | |<<====================| | | | | | Leave[0x42] | | | (Bsc Leave[0x41]) | | |--------------------->| | | Query[0x41] | | | (GS&B Query[0x21]) | | |<---------------------| | | Query[0x41] | | | (GS&B Query[0x21]) | | |<---------------------| | | (No Response) | | | | | | Traffic Stop | Accounting | | X<<======| Request(Stop) | | |----------------->| | | Accounting | | Query[0x41] | Response | | (Acct Message[0x25]) |<-----------------| | (Message[0x21]) | | |<---------------------| | | | | Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 24] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 C-2. Success of Fast Leave Process client AuthGW RADIUS server v v v | Multicast traffic | | |<<====================| | | | | | Leave[0x42] | | | (Bsc Leave[0x41]) | | |--------------------->| | | Traffic Stop | Accounting | | X<<======| Request(Stop) | | |----------------->| | | Accounting | | Query[0x41] | Response | | (Acct Message[0x25]) |<-----------------| | (Message[0x21]) | | |<---------------------| | | | | C-3. No response (time out) of user client client AuthGW RADIUS server v v v | Multicast traffic | | |<<====================| | | | | | Query[0x41] | | | (G&B Query[0x21]) | | |<---------------------| | | Query[0x41] | | | (G&B Query[0x21]) | | |<---------------------| | | Query[0x41] | | | (G&B Query[0x21]) | | |<---------------------| | | (No Response) | | | | | | Traffic Stop | Accounting | | X<<======| Request(Stop) | | |----------------->| | | Accounting | | Query[0x41] | Response | | (Acct Message[0x25]) |<-----------------| | (Message[0x21]) | | |<---------------------| | | | | General-and-Basic Query Interval is described in Chapter B of Appendix 5. The number of resent Query messages is described in Appendix 8. Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 25] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 C-4. No response (time out) of RADIUS server in Basic Leave Process client AuthGW RADIUS server v v v | Multicast traffic | | |<<====================| | | | | | Leave[0x42] | | | (Bsc Leave[0x41]) | | |--------------------->| | | Query[0x41] | | | (GS&B Query[0x21]) | | |<---------------------| | | Query[0x41] | | | (GS&B Query[0x21]) | | |<---------------------| | | (No Response) | | | | | | Traffic Stop | Accounting | | X<<======| Request(Stop) | | |----------------->| | Query[0x41] | | |(Error Message[0x27]) | (No Response) | | (Message[0x11]) | | |<---------------------| | | | | | Query[0x41] | | | (Acct Message[0x25]) | | | (Message[0x21]) | | |<---------------------| | | | | AuthGW sets three parameters when communicating with the authentication server as is described in Chapter A-3 of Appendix 5. These parameters are described in Appendix 9. Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 26] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 C-5. No response (time out) of RADIUS server in Fast Leave Process client AuthGW RADIUS server v v v | Multicast traffic | | |<<====================| | | | | | Leave[0x42] | | | (Bsc Leave[0x41]) | | |--------------------->| | | Traffic Stop | Accounting | | X<<======| Request(Stop) | | |----------------->| | Query[0x41] | | |(Error Message[0x27]) | (No Response) | | (Message[0x11]) | | |<---------------------| | | | | | Query[0x41] | | | (Acct Message[0x25]) | | | (Message[0x21]) | | |<---------------------| | | | | AuthGW sets three parameters when communicating with the authentication server as is described in Chapter A-3 of Appendix 5. These parameters are described in Appendix 9. Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 27] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 C-6. No response (time out) of user client if neither authentication nor accounting is needed (e.g. Free Channel) in Basic Leave Process client AuthGW RADIUS server v v v | Multicast traffic | | |<<====================| | | | | | Leave[0x42] | | | (Bsc Leave[0x41]) | | |--------------------->| | | Query[0x41] | | | (GS&B Query[0x21]) | | |<---------------------| | | Query[0x41] | | | (GS&B Query[0x21]) | | |<---------------------| | | (No Response) | | | | | | Traffic Stop | | | X<<======| | | Query[0x41] | | | (Ntf Message[0x26]) | | | (Message[0x12]) | | |<---------------------| | | | | C-7. No response (time out) of user client if neither authentication nor accounting is needed (e.g. Free Channel) in Fast Leave Process client AuthGW RADIUS server v v v | Multicast traffic | | |<<====================| | | | | | Leave[0x42] | | | (Bsc Leave[0x41]) | | |--------------------->| | | Traffic Stop | | | X<<======| | | Query[0x41] | | | (Ntf Message[0x26]) | | | (Message[0x12]) | | |<---------------------| | | | | Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 28] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 C-8. No response (time out) of user client if neither authentication nor accounting is needed (e.g. Free Channel) client AuthGW RADIUS server v v v | Multicast traffic | | |<<====================| | | | | | Query[0x41] | | | (G&B Query[0x21]) | | |<---------------------| | | Query[0x41] | | | (G&B Query[0x21]) | | |<---------------------| | | Query[0x41] | | | (G&B Query[0x21]) | | |<---------------------| | | (No Response) | | | | | | Traffic Stop | | | X<<======| | | Query[0x41] | | | (Ntf Message[0x26]) | | | (Message[0x12]) | | |<---------------------| | | | | Appendix 6. IGAP sequence with CHAP mechanism This appendix provides examples of IGAP sequence with CHAP mechanism. In the figures in this appendix, in addition to IGAP packet types used in Appendix.5, the following packet type abbreviations are used. IGAP Join (Type:0x40) CHAP Join Challenge Request (Report Type:0x03) : CHAP Join CHAP Join Response (Report Type:0x04) : CHAP Join Resp IGAP Membership Query (Type:0x41) CHAP Challenge (Report Type:0x23) : CHAP Chllng In the figures in this appendix, the transferred packets have the following form. Type Name[Type (No.)] (Report Type Name [Report Type (No.)]) (Message[(No.)]) This appendix describes only the case of access accept. In the case of access reject, CHAP process is replaced by PAP process. Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 29] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 client AuthGW RADIUS server v v v | Join[0x40] *1 | | | (CHAP Join[0x03]) | | |--------------------->| | | | | | (Making "S") *2 | | | | | Query[0x41] *3 | | | (CHAP Chllng[0x23]) | | |<---------------------| | | | | (A=fMD5(S,PW)) *4 | | | | | | Join[0x40] *5 | | |(CHAP Join Resp[0x04])| | |--------------------->| | | | Access | | | Request *6 | | |----------------->| | | (A'=fMD5(S,PW)) *7 | | (A'=A?) *8 | Query[0x41] | Access | | (Auth Message[0x24]) | Accept *9 | | (Message[0x11]) |<-----------------| |<---------------------| | | Multicast traffic | Accounting | |<<====================| Request(Start) | | |----------------->| | Query[0x41] | Accounting | | (Acct Message[0x25]) | Response | | (Message[0x11]) |<-----------------| |<---------------------| | | | | | | | Explanation of the sequence in the figure *1 : CHAP Join Challenge Request User client sends CHAP Join Challenge Request message to authGW. *2 : Making "S" AuthGW creates a random digit S. *3 : CHAP Challenge AuthGW makes a CHAP ID, and sends CHAP Challenge message to user client. *4 : A=fMD5(S, PW) User client calculates Hash Value A from S and user password using Hash Function MD5. *5 : CHAP Join Response User Client sends CHAP Join Response message to authGW. *6 : Access Request AuthGW sends Access Request with A and S to RADIUS server. Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 30] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 *7 : A'=fMD5(S, PW) RADIUS server calculates Hash Value A' from S and user password configured in RADIUS server using Hash Function MD5. *8 : A'=A? If A' equals A, Join request of user is accepted. *9 : Access Accept RADIUS server sends Access Accept. The steps after *9 are the same as in the PAP process. Appendix 7. RADIUS Attribute Appendix.5 and 6 provide examples of using the RADIUS server. This chapter describes the attributes needed. In addition to existing attributes, defined in RFC2865 and 2866, two attributes are defined as vendor specific values. They are Auth-Multicast-Address and Validity-Period. Other details basically follow the specifications of RFC2865 and 2866. Auth-Multicast-Address (Type:26, Vendor Type:90) This value is the desired multicast address as is sent by AuthGW to RADIUS server. RADIUS server knows the multicast addresses that each user can receive. If this address is not one of the approved addresses, Access Reject is sent to authGW. Validity-Period (Type:26, Vendor Type:93) RADIUS server sends this attribute to authGW to notify Validity-Period described in Appendix 8. Needed attributes are as follows. (1) Access Request User-Name (Type:1) User-Password (Tvpe:2) notice : used with PAP CHAP-Password (Type:3) notice : used with CHAP NAS-IP-Address (Type:4) NAS-Port (Type:5) Auth-Multicast-Address (Type:26, Vendor Type:90) CHAP Challenge (Tvpe:60) notice : used with CHAP (2) Access Accept User-Name (Type:1) Auth-Multicast-Address (Type:26, Vendor Type:90) Validity-period (Type:26, Vendor Type:93) (3) Access Reject No attribute is used. Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 31] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 (4) Accounting Request (Start) User-Name (Type:1) NAS-IP-Address (Type:4) NAS-Port (Type:5) Auth-Multicast-Address (Type:26, Vendor Type:90) Acct-Status-Type (Start) (Tvpe:40) Acct-Session-ID (Tvpe:44) (5) Accounting Request (Stop) User-Name (Type:1) NAS-IP-Address (Type:4) NAS-Port (Type:5) Auth-Multicast-Address (Type:26, Vendor Type:90) Acct-Status-Type (Stop) (Tvpe:40) Acct-Output-Octets (Type:43) Acct-Session-ID (Type:44) Acct-Session-Time (Type:46) Acct-Output-Packets (Type:48) Acct-Terminate-Cause (Type:49) (6) Accounting Response No attribute is used. Appendix 8. Parameters set in authGW and user client when supporting IGAP This appendix describes the parameters set in authGW and/or user client when supporting IGAP processes. "Reference list" details the chapters that explain the usage of each parameter in the IGAP process. 8-1. RADIUS Retrying Count Range : 1~100 (Default : 3) Implemented : AuthGW Reference list: A-3, B-3, C-4, C-5 This is the limitation value for the number of user request (Access Request or Accounting Request) at the same time, when AuthGW sends the request to RADIUS server. See also chapters 8-2 and 8-3. 8-2. RADIUS Retrying Interval Range : 1~100 seconds (Default : 5) Implemented : AuthGW Reference list: A-3, B-3, C-4, C-5 This is the interval for sending Access Request or Accounting Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 32] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 Request to RADIUS server in units of seconds. See also chapters 8-1 and 8-3. 8-3. RADIUS Waiting Interval Implemented : AuthGW Reference list: A-3, B-3, C-4, C-5 This is the product Radius Transmit Count and Radius Retrying Interval in units of seconds, and used by authGW in determining whether RADIUS server is alive or not. 8-4. General-and-Basic Query Count Range : 1~10 (Default 3) Implemented : AuthGW Reference list: B-1 ~ B-4, C-3, C-8 This is the limitation value for number of General-and-Basic Query at the same time, when AuthGW sends it to user client. See the chapter 8-5, 8-6 and 8-7, too. 8-5. General-and-Basic Query Interval Range : 1~647 seconds (Default : 125) Implemented : AuthGW Reference list: B-1 ~ B-4, C-3, C-8 This is the interval for sending General-and-Basic Query to user client. See also chapters 8-4, 8-6 and 8-7. 8-6. General-and-Basic Query Max Resp Time Implemented : AuthGW Reference list : B-1 ~ B-4, C-3, C-8 This is equal to Max Resp Time in IGAP packet, and used by authGW to calculate General-and-Basic Query Waiting Interval. See also chapter 8-7. 8-7. General-and-Basic Query Waiting Interval Implemented : AuthGW Reference list: B-1 ~ B-4, C-3, C-8 This is calculated as follows. Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 33] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 (General-and-Basic Query Waiting Interval) = (General-and-Basic Query Count) X (General-and-Basic Query Interval) + (General-and-Basic Query Max Resp Time) It's used by authGW to determine whether user clients under authGW are alive or not. This process is almost same as the IGMPv2 equivalent. 8-8. Group-Specific-and-Basic Query Count Range : 0~10 seconds (Default : 2) Implemented : AuthGW Reference list: C-2, C-5, C-7 This is the limitation value for number of Group-Specific-and-Basic Query at the same time, when AuthGW sends it to user client. See also chapters 8-9 and 8-10. 8-9. Group-Specific-and-Basic Query Max Resp Time Range : 0~100 seconds (Default : 5) Implemented : AuthGW Reference list: C-2, C-5, C-7 This is equal to Max Resp Time in IGAP packet, and used by authGW to determine whether user client participating in a multicast group is alive or not. See also chapters 8-8 and 8-10. 8-10. Group-Specific-and-Basic Query Waiting Interval Implemented : AuthGW Reference list: C-2, C-5, C-7 This is calculated as follows. It's used by authGW to determine whether user clients under authGW are alive or not in Basic Leave Process. This process is almost the same as the IGMPv2 equivalent. It is calculated as follows. (Group-Specific-and-Basic Query Waiting Interval) = (Group-Specific-and-Basic Query Count) X (Group-Specific-and-Basic Query Max Resp Time) 8-11. Validity Period Range : 0~10,000 seconds (Default : 0) Implemented : AuthGW Reference list: B-1 ~ B-4, C-3, C-8 This is an integer multiple of Query Interval in units of second, and used by authGW to determine whether user authentication is necessary or not. See also chapter B of Appendix.5. Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 34] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 8-12. Basic Leave Count Range : 1~15 (Default 2) Implemented : user client Reference list: C-2, C-5, C-7 This is the maximum number of times Basic Leave can be sent to authGW. 8-13. Join Interval Range : 0.1~3 (Default 0.1) Implemented : AuthGW, user client This is used as the interval authGW waits to receive IGAP Join message from user client. If authGW receives more than two IGAP Join messages from the same user client during this interval, it must discard all Join messages, except the first one. In addition, user client must not send more than two IGAP Join messages to authGW during this interval. 8-14. AuthGW Response Waiting Interval Range : 0~100 (Default 10) Implemented : AuthGW, user client This is used as the interval user client waits for IGAP Membership Query message packet. When user client didn't receive any message from authGW during this interval, it may determine authGW is dead, but this determination must not impact the other IGAP processes. Appendix 9. Configuration of Group Address in authGW The decision whether authentication is needed or not depends on desired group address. AuthGW has a list of those group addresses or subnet addresses associated with each group address. Each group address or subnet address has a flag indicating the necessity of authentication. For example, the authGW list may look like this. 239.192.1.0/24 : Auth 239.192.2.0/24 : No-Auth 239.192.3.1 : Auth 239.192.3.2 : No-Auth Notice : List file should not be a text file. Flag "Auth" means that authentication is needed, and "No-Auth" means that authentication is not needed. When authGW receives IGAP Join Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 35] Internet Draft draft-andou-igmp-auth-01.txt June, 2002 message, if the value in Group Address field is 239.192.1.* (from 239.192.1.0 to 239.192.1.255) or 239.192.3.1, authentication process (PAP or CHAP) is performed between authGW and authentication server, for example, using RADIUS server, authGW sends Access Request to RADIUS server (see Chapter A-1 of Appendix 5). If the value in Group Address field is 239.192.2.* (from 239.192.2.0 to 239.192.2.255) or 239.192.3.2, the authentication process is not run, and authGW sends the multicast packets to the user client at once (see Chapter A-6 of Appendix 5). If the value in Group Address field is not in the list, e.g. 239.192.4.1, authGW may determine that this value is invalid, at which point it would send Error Message with 0x41 set in the Message field to the user client (see Appendix 1 and Chapter A-4 of Appendix 5). Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 36]