Internet Engineering Task Force Haixiang He, Nortel Networks INTERNET-DRAFT Brad Cain, Cereva Networks Thomas Hardjono, Verisign Expire: May, 2002 November, 2001 Upload Authentication Information Using IGMPv3 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 document describes the changes of Internet Group Management Protocol(IGMP) version 3 that enable a host to upload the authentication information to its neighboring multicast routers. 1. Introduction The Internet Group Management Protocol (IGMP) [1, 2, 3] is used in IPv4 environment to communicate IP multicast group membership subscriptions from a host to its neighboring multicast routers. The current multicast model allows any host to join the multicast group by issuing IGMP join message. In some scenarios such as He, Cain, Hardjono [Page 1] Internet Draft draft-he-magma-igmpv3-auth-00.txt May, 2002 security attack protection, a host's IGMP requests needs to be authenticated before a router triggers the multicast routing protocol. In some other scenarios such as group access control, a host needs to be authorized before it can receive the multicast traffic. Some solutions to these problems require a host to provide authentication information such as access token [4, 5] accompanying its IGMP requests. They also require the host's neighboring routers to periodically query for authentication information and authenticate those IGMP requests before taking related actions about IGMP requests. This document defines the necessary changes of IGMPv3 to support the use of IGMP to communicate the authentication information, in particular access token. 2. Solution Goal, Approach, and Rationale The IGMP state records maintained by a multicast router are used to trigger the multicast routing protocol that will cause the multicast traffic being delivered to that router. They are also used to forward the traffic downstream. The goal of a solution that protects the multicast router is to protect the IGMP state records. To achieve this goal, the IGMP requests should be authenticated. One approach is to require authentication information such as access token accompanying an IGMP request. Once a router receives the request, it will use the authentication information to authenticate the request. And according to the authentication results, it will take appropriate actions to update the IGMP state records. One simple and easy solution is to authenticate every IGMP request. In another word, this solution requires authentication information accompanying every IGMP request. This solution has some disadvantages. Authentication information is not needed if an IGMP request does not cause any change of the IGMP state records. So the extra authentication information is a waste of the bandwidth usage of network and it is also an extra burden of the host's processing power. One the router side, there is also some cost of providing authentication. The cost maybe very high. So authentication should be minimized. In some circumstances, it may be tolerable to update the timers associated with the IGMP state records that have already been created without authenticating those IGMP requests for a certain period of time. A solution should provide a router with an option of when to use the authentication. He, Cain, Hardjono [Page 2] Internet Draft draft-he-magma-igmpv3-auth-00.txt May, 2002 Based on the rationale above, this document proposes two new IGMPv3 authentication messages, Authentication Query and Authentication Report. These two new message coexist with the current IGMPv3 messages. A host uses the normal IGMPv3 report message to report its interest. When it receives an authentication query, it will reply an authentication report. Besides the normal IGMPv3 query, a router also sends authentication query in some conditions described in section 5. 3. Authentication Message Formats The new Authentication Messages follow the requirements for normal IGMP message specified in IGMPv3 document [3]. There are two Authentication Messages: Type Number (hex) Message Name ----------------- ------------ 0x31 Authentication Membership Query 0x32 Authentication Membership Report 3.1. Authentication Membership Query The Authentication Membership Queries are sent by multicast router. The format is the same as IGMPv3 query except that the message type field is 0x31 instead of 0x11. There are also three variants of the Authentication Query message: General Authentication Query, Group-Specific Authentication Query, Group-and-Source-Specific Authentication Query. In a General Authentication Query, both the Group Address field and the Number of Sources (N) field are zero. In a Group-Specific Authentication Query, the Group Address field contains the multicast address of interest, and the Number of Sources (N) field contains zero. In a Group-and- Source-Specific Authentication Query, the Group Address field contains the multicast address of interest, and the Source Address [i] fields contain the source address(es) of interest. 3.2. Authentication Membership Report The Authentication Membership Reports are sent by IP systems. Besides the message type field which is 0x32 and the changes in Group Record, the format is the same as IGMPv3 report message. The new Group Record has the following internal format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ He, Cain, Hardjono [Page 3] Internet Draft draft-he-magma-igmpv3-auth-00.txt May, 2002 | Record Type | Aux Data Len | Number of Sources (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address [1] | +- -+ | Source Address [2] | +- -+ . . . . . . . . . +- -+ | Source Address [N] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Auxiliary Data Record [1] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Auxiliary Data Record [2] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . . . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Auxiliary Data Record [Q] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each Auxiliary Data Record has the following internal format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aux Type | Aux Rec Len | Auth Type | Auth Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Authentication Data . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ He, Cain, Hardjono [Page 4] Internet Draft draft-he-magma-igmpv3-auth-00.txt May, 2002 3.2.1. Aux Type The Aux Type field unambiguously specifies the type of the Auxiliary Data. This document only specifies one type of Auxiliary Data: Authentication Information, Aux Type = 0x01. 3.2.2. Aux Rec Len The Aux Rec Len field contains the length of the Auxiliary Data Record, in the units of 32-bits words. The length of the Auxiliary Data Record is not fixed. Besides the Aux Type and Aux Rec Len fields, the rest of the record is interpreted according to the value of the Aux Type field, Authentication Information in this document. 3.2.3. Auth Type The Auth Type field indicates the authentication mechanism being used. 3.2.4 Auth Data Len The Auth Data Len field contains the length of the useful Authentication Data. 3.2.5. Authentication Data The Authentication Data field contains the authentication information as well as extra padding that makes the whole Auxiliary record into the units of 32-bits words. 3.2.6. Record Type There are only two types of Group Records that may be included in an Authentication Report message. They are all "Current-State Record" as specified in IGMPv3 document. An Authentication Report is only sent by a system in response to an Authentication Query. 4. Host Behavior A host takes the same actions as described in IGMPv3 document in response to the event: a change of the interface reception state, caused by a local invocation of IPMulticastListen. He, Cain, Hardjono [Page 5] Internet Draft draft-he-magma-igmpv3-auth-00.txt May, 2002 A host will receive only General Query, General Authentication Query, Group Specific Authentication Query, Group-and-Source Specific Authentication Query. If all multicast routers in the same networks support this document, a host should not receive Group Specific Query, Group-and-Source Specific Query as described in section 5. To schedule a response to an Authentication Query, the system must maintain one more state in addition to the three states it has already maintained as described in IGMPv3 document. The new state is: A timer per interface for scheduling responses to General Authentication Queries. This timer is identified as Authentication Interface Timer to differentiate itself from interface timer used for scheduling response to General Queries. The group timer and the source-list are now used to schedule responses to Group Specific Authentication Queries and Group-and- Source Specific Queries. The interface timer is still used to schedule responses to General Queries. The rules used to determine if a Report needs to be scheduled and the type of Report to schedule are the same as in IGMPv3 document except a few changes. First, new rules are added to process General Authentication Queries. These rules are the same as rules used to process General Queries. Second, rules used process Group Specific and Group-and-Source Specific Queries are instead used to process Group Specific and Group-and-Source Specific Authentication Queries. When the interface timer expires, a normal Report message is sent. When the Authentication Interface Timer expires, an Authentication Report message is sent. Except the authentication information, this message contains the same information as the normal Report message used to response the General Queries. When the group timer expires, an Authentication Report message is sent. Except the authentication information, the message contains the same information as the normal Report message used to response the Group Specific and Group-and- Source Specific Queries. 5. Router Behavior Multicast routers maintain the same IGMP group membership state as specified in IGMPv3. They also follow the IGMPv3 Source-Specific forwarding rules. To protect the IGMP state records, routers maintain extra authentication state and there are few changes about the router behavior. He, Cain, Hardjono [Page 6] Internet Draft draft-he-magma-igmpv3-auth-00.txt May, 2002 5.1. IGMP Authentication State Maintained by Multicast Routers Multicast routers maintain a set of authentication state records per attached networks. Each authentication state record conceptually is of the form: (multicast address, authentication timer) for group specific authentication state record or of the form: (multicast address, source address, authentication timer) for group-and-source specific authentication state record. Records are created when multicast routers send Authentication Query. And their authentication timers are set to the Last Member Authentication Query Interval (LMAQI). A record is deleted when the authentication timer time out or when an authentication current-state record is received that contains the record's multicast address (and source address in scenarios) before timer time out. 5.2. IGMP Queries Multicast routers use 4 types of queries: General Query, General Authentication Query, Group Specific Authentication Query, and Group-and-Source Specific Authentication Query. They SHOULD not send Group Specific Query and Group-and-Source Specific Query. Multicast routers still send General Queries periodically to request group membership information. These queries are used to refresh the group membership state of the systems on attached networks. Multicast routers also send General Authentication Queries periodically to request group membership information as well as its associated authentication information. These queries are also used to refresh the group membership state. The interval between two General Authentication Queries SHOULD be larger than the interval between two General Queries. When sending a General Authentication Query, routers also create a group specific authentication state record with only multicast address for each IGMP state record. And the record's non zero timers including group and source timers are set to LMAQI. Multicast routers send Group Specific Authentication Queries when a group record needs to be created, when a group's filter-mode needs to be changed from INCLUDE to EXCLUDE, or when a system is leaving the group. A group specific authentication state record is created using the group record's multicast address. He, Cain, Hardjono [Page 7] Internet Draft draft-he-magma-igmpv3-auth-00.txt May, 2002 Multicast routers send Group-and-Source Specific Authentication Queries when traffic from a new source record is needed or a system expresses interest in not receiving traffic from particular sources. A group-and-source specific authentication state record is created using the group record's multicast and source addresses. 5.3. Action on Reception of Reports If all hosts in a network support this documents, multicast routers SHOULD receive Membership Reports with Current-State records and State-Change records as well as Authentication Membership Reports with only Current-State records. 5.3.1. Reception of Current-State Records When receiving Current-State records, a router updates the related timers. If a new group state record needs to be created or the group record's filter mode needs to be changed from INCLUDE to EXCLUDE, a router sends a Group Specific Authentication Query. If traffic from a new source is needed, a router sends a Group-and-Source Specific Authentication Query. The table below describes the modified actions upon reception of Current-State Records. The notation 'AQ(G)" is used to describe a Group Specific Authentication Query to G. The notation 'AQ(G,A)' is used to describe a Group-and-Source Specific Query to G with source- list A. Every time a router send an AQ(G) or AQ(G,A), it creates related authentication state records. Router State Report Rec'd New Router State Actions ------------ ------------ ---------------- ------- INCLUDE (A) IS_IN (B) INCLUDE (A) (A*B)=GMI Send AQ(G,B-A) INCLUDE (A) IS_EX (B) INCLUDE (A) Send AQ(G) EXCLUDE (X,Y) IS_IN (A) EXCLUDE (X+(A-Y),Y) (A-Y)=GMI Send AQ(G,A*Y) EXCLUDE (X,Y) IS_EX (A) EXCLUDE (A-Y,Y) Send AQ(G,Y-A) (A-X-Y)=GMI Delete (X-A) Group Timer=GMI He, Cain, Hardjono [Page 8] Internet Draft draft-he-magma-igmpv3-auth-00.txt May, 2002 5.3.2. Reception of State-Change Records When receiving State-Change records, a router updates its records and may change its state to reflect the new desired membership state of the network. If some sources are requested to be no longer forwarded to a group, a router sends a Group-and-Source Specific Authentication Query to query sources. It lowers the source timers for those sources to Last Member Query Interval (LMQI). Similarly, when a router sends Group Specific Authentication Query, it lowers the group timer for that group to LMQI. Also if a new group state record needs to be created or the group record's filter mode needs to be changed from INCLUDE to EXCLUDE, a router sends a Group Specific Authentication Query. If traffic from a new source is needed, a router sends a Group-and-Source Specific Authentication Query. The table below describes the modified actions upon reception of State-Change Records. Router State Report Rec'd New Router State Actions ------------ ------------ ---------------- ------- INCLUDE (A) ALLOW (B) INCLUDE (A) (B*A)=GMI Send AQ(G,B-A) INCLUDE (A) BLOCK (B) INCLUDE (A) Send AQ(G,A*B) (A*B)=LMQI INCLUDE (A) TO_EX (B) INCLUDE (A) Send AQ(G) INCLUDE (A) TO_IN (B) INCLUDE (A) (A*B)=GMI Send AQ(G,A-B) (A-B)=LMQI Send AQ(G,B-A) EXCLUDE (X,Y) ALLOW (A) EXCLUDE (X+(A-Y),Y) (A-Y)=GMI Send AQ(G,A*Y) EXCLUDE (X,Y) BLOCK (A) EXCLUDE (X+(A-Y),Y) (A-X-Y)=Group Timer Send AQ(G,A-Y) EXCLUDE (X,Y) TO_EX (A) EXCLUDE (A-Y,Y) Send AQ(G,Y-A) (A-X-Y)=Group Timer Delete (X-A) Send AQ(G,A-Y) Group Timer=GMI He, Cain, Hardjono [Page 9] Internet Draft draft-he-magma-igmpv3-auth-00.txt May, 2002 EXCLUDE (X,Y) TO_IN (A) EXCLUDE (X+(A-Y),Y) (A-Y)=GMI Send AQ(G,A*Y) Send AQ(G,X-A) (X-A)=LMQI Send AQ(G) Group Timer=LMQI 5.3.3. Reception of Authentication Current-State Records When receiving Authentication Current-State records, a router triggers the authentication module through the authentication APIs described in section 7. For each record that is authenticated, the related IGMP state record is updated. When updating the IGMP state records, a router takes the same actions as the actions a normal IGMP router takes upon reception of Current- State records. The same table is used. Router State Report Rec'd New Router State Actions ------------ ------------ ---------------- ------- INCLUDE (A) IS_IN (B) INCLUDE (A+B) (B)=GMI INCLUDE (A) IS_EX (B) EXCLUDE (A*B,B-A) (B-A)=0 Delete (A-B) Group Timer=GMI EXCLUDE (X,Y) IS_IN (A) EXCLUDE (X+A,Y-A) (A)=GMI EXCLUDE (X,Y) IS_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y)=GMI Delete (X-A) Delete (Y-A) Group Timer=GMI 6. Group-and-Source Specific Authentication Information In some scenarios especially in SSM [6,7], Group-and-Source Specific authentication information is required. Without changing the format and interpretation of the current IGMPv3 report, a group record with a single source address has to be used to upload Group-and-Source Specific authentication information. But this method does not apply to a group if the group's filter mode is EXCLUDE since a record whose record type is MODE_IS_EXCLUDE cannot be split into multiple records. He, Cain, Hardjono [Page 10] Internet Draft draft-he-magma-igmpv3-auth-00.txt May, 2002 7. The API for Authenticating IGMP Requests Within a router, there is an Application Programming Interface or API that is used by the IGMP module to authenticate the IGMP requests. The API must support the following operation or any logical equivalent: bool IGMPAllowed(multicast-address, source-list, auth record) where the "auth record" contains the authentication information that is in the IGMP request. 8. New Timer This document introduces one new timer. It is configurable. 8.1. Authentication Query Interval The Authentication Query Interval is the interval between General Authentication Queries. Default: 300 seconds. The Authentication Query Interval should be larger than Query Interval since authentication is more expensive and should be used less. References [1] Deering, S., "Host Extension for IP Multicasting", RFC 1112, August 1989. [2] Fenner, W., "Internet Group Management Protocol, Version2", RFC 2236, November 1997. [3] Cain, B., Deering, S., Fenner, W., Kouvelas, I., Thyagarajan, A., "Internet Group Management Protocol, Version 3", Internet-Draft, January 2001. [4] He, H., Hardjono, T., and Cain, B., "Simple Multicast Receiver Access Control", Internet-Draft, work in progress. [5] Hardjono, T. and Cain, B., "Key Establishment for IGMP Authentication in IP Multicast", IEEE European Conference on Universal Multiservice Networks (ECUMN), CERF, Colmar, France, September 2000. [6] Holbrook, H., and Cain, B., "Using IGMPv3 For Source-Specific Multicast", draft-holbrook-idmr-igmpv3-ssm-01.txt, March 2001. [7] Holbrook, H., and Cain, B., "Source-Specific Multicast for IP", Internet-Draft, work in Progress. He, Cain, Hardjono [Page 11] Internet Draft draft-he-magma-igmpv3-auth-00.txt May, 2002 Author's Address: Haixiang He Nortel Networks 600 Technology Park Drive Billerica, MA 01821 Phone: 978-288-7482 Email: haixiang@nortelnetworks.com Brad Cain Cereva Networks Email: bcain@cereva.com Thomas Hardjono Verisign 401 Edgewater Place, Suite 208 Wakefield, MA 01880 Email: thardjono@verisign.com He, Cain, Hardjono [Page 12]