Network Working Group R. Lehtonen Internet-Draft J. Soini Expires: December 5, 2002 Sonera Corporation J. Majalainen H. Vatiainen Tampere University of Technology June 6, 2002 Multicast Control Protocol (MCOP) draft-lehtonen-magma-mcop-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with 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. This Internet-Draft will expire on December 5, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract In IP multicast all hosts that join a multicast group (*, G) or (S, G) can receive the multicast traffic. This draft adds possibility to selectively enable multicast receiving and sending by introducing Multicast Control Protocol (MCOP). MCOP is used between multicast control agent (MCA) and routers that have directly connected multicast sources or receivers. The receiver and source control is done by MCOP enabled routers based on the information received from the MCA. MCOP enabled routers filter IGMP/MLD reports and multicast Lehtonen, et al. Expires December 5, 2002 [Page 1] Internet-Draft Multicast Control Protocol (MCOP) June 2002 packets before they reach the IGMP/MLD processing layer or multicast routing stack of the router. MCOP is independent of multicast routing protocols. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 MCOP controlled groups and channels . . . . . . . . . . . . 5 2.2 MCOP controlled multicast addresses . . . . . . . . . . . . 5 2.3 Multicast Control Agent (MCA) . . . . . . . . . . . . . . . 5 2.4 MCOP Routers . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6 4. MCOP Message Formats . . . . . . . . . . . . . . . . . . . . 8 4.1 Common Header . . . . . . . . . . . . . . . . . . . . . . . 8 4.2 MCOP Object Formats . . . . . . . . . . . . . . . . . . . . 8 4.2.1 Message Integrity Object . . . . . . . . . . . . . . . . . . 9 4.2.2 Group Range Object . . . . . . . . . . . . . . . . . . . . . 11 4.2.3 Group Member Object . . . . . . . . . . . . . . . . . . . . 12 5. MCOP Specification . . . . . . . . . . . . . . . . . . . . . 15 5.1 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2 Initialization . . . . . . . . . . . . . . . . . . . . . . . 15 5.3 Source/Receiver Validation . . . . . . . . . . . . . . . . . 16 5.4 Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.5 Integrity checking . . . . . . . . . . . . . . . . . . . . . 17 6. MCOP Router Functionality . . . . . . . . . . . . . . . . . 19 6.1 Processing IGMP/MLD Messages . . . . . . . . . . . . . . . . 20 6.2 Processing Multicast Traffic . . . . . . . . . . . . . . . . 22 6.3 Creating Multicast Group Member Information . . . . . . . . 23 6.4 Removing Multicast Group Member Information . . . . . . . . 23 6.5 Updating Multicast Group Member Information . . . . . . . . 24 6.6 Connection between MCOP Router and MCA . . . . . . . . . . . 24 7. MCA Functionality . . . . . . . . . . . . . . . . . . . . . 25 7.1 General Description . . . . . . . . . . . . . . . . . . . . 25 7.2 MCA Database . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27 References . . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 Full Copyright Statement . . . . . . . . . . . . . . . . . . 30 Lehtonen, et al. Expires December 5, 2002 [Page 2] Internet-Draft Multicast Control Protocol (MCOP) June 2002 1. Introduction Currently in IP multicast a source for a multicast group does not have control over the receivers for that multicast group. SIM [1] and XCAST [2] try to solve this problem by including a receiver list in multicast packets. This limits the number of receivers, because the receiver list and the multicast data share the same IP packet. These solutions also add heavy packet processing requirements for routers. SGMv6 [3] defines cryptographic mechanisms to control multicast group joins. SGMv6 does not currently suit for dynamic source-specific groups, because it does not have a possibility to remove members that have already registered as a valid receivers in the multicast tree. It also requires modifications to MLDv2 [4]. If we encrypt the multicast traffic, we can be sure that only valid receivers (who have the key) can decrypt those packets, but we have no control over the multicast state creation in routers and thus all interested hosts can join the multicast group and start receiving the encrypted multicast traffic. Unnecessary state information will be created in routers when a host joins an imaginary multicast group (DoS attacks). In some cases it might be wise to have some control over the multicast sources and let only the selected sources for a certain multicast group to send multicast traffic. MCOP approaches multicast control by selectively filtering the IGMP/ MLD and multicast traffic before it has possibility to create multicast state information in the multicast routers. Lehtonen, et al. Expires December 5, 2002 [Page 3] Internet-Draft Multicast Control Protocol (MCOP) June 2002 2. Terminology 2.1 MCOP controlled groups and channels Not all any-source multicast groups and source-specific multicast (SSM) channels are intended to be controlled by MCOP. Those any- source multicast groups that are controlled by MCOP are called MCOP controlled groups. Those SSM channels that are controlled by MCOP are called MCOP controlled channels. When the specification refers collectively to both any-source groups and SSM channels, they are called MCOP controlled groups and channels. 2.2 MCOP controlled multicast addresses If we refer to all MCOP controlled groups and channels that are controlled by MCOP, we talk about MCOP controlled multicast addresses. 2.3 Multicast Control Agent (MCA) MCA can be located in a router or it can be a standalone host. MCA defines the MCOP controlled multicast addresses and informs MCOP routers about them. MCA is also responsible for storing the multicast source and receiver information for MCOP controlled groups and channels. MCOP enabled routers use the MCOP protocol to query MCA whether or not the hosts in their directly connected networks are allowed to receive or send traffic to the MCOP controlled multicast addresses. 2.4 MCOP Routers The first hop multicast routers that support MCOP are called MCOP routers. MCOP routers control multicast traffic destined to the MCOP controlled multicast addresses. The MCOP controlled multicast addresses are sent to MCOP routers by MCA. MCOP routers validate the receive and send permission only for their directly connected hosts. One MCOP Router can connect to one and only one MCA at a given time. One MCA can be connected to multiple MCOP Routers. Lehtonen, et al. Expires December 5, 2002 [Page 4] Internet-Draft Multicast Control Protocol (MCOP) June 2002 3. Protocol Overview MCOP uses UDP for the optional MCA autodiscovery protocol and TCP for the connection between MCOP Router and its MCA. MCOP routers discover their MCAs either with static configuration or simple autodiscovery protocol. The static configuration is done by configuring each MCOP router with its MCA's IP address. With static configuration the autodiscovery phase can be skipped altogether. The autodiscovery is initiated by MCOP router by multicasting an MCOP Discover packet to the Multicast-Control-Agents multicast group. Potential MCAs reply with MCOP Offer packet which is sent as unicast to the source address of the Discover packet. The MCOP router can then select a MCA. When the MCOP router has learned the address of its MCA, it will make a TCP connection to the MCA's address. When the connection has been established, the MCA informs the MCOP router about the MCOP controlled multicast addresses with the MCOP Init message. MCOP router must control receivers and sources for those addresses. When a directly connected host desires to receive multicast traffic destined to a MCOP controlled multicast group (*,G) or channel (S,G), it will send a IGMP/MLD report indicating so. If the MCOP router that receives the report does not know about the allowed sources and receivers for that group in the host's subnet, it will query its MCA with a MCOP Validate message. A similar MCOP Validate is also sent if a multicast source for the group becomes active before a receiver. The MCA returns a MCOP Result message that contains a list of unicast address ranges with the information whether the hosts in the address ranges can send and/or receive traffic destined to the MCOP controlled group or channel. The list covers all the information about the MCOP controlled group or channel that is available for the subnet where the receiver or source resides. When a subsequent source or receiver activates in the same subnet for that MCOP controlled group or channel, the MCOP router already has the required information to make the filtering decision. If changes are made to MCA's MCOP controlled multicast addresses or receiver or source permissions are modified (membership change) for MCOP controlled groups or channels, the MCA will notify the MCOP routers about the changes with an unsolicited MCOP Result message. If the list of MCOP controlled multicast addresses is modified, every connected MCOP router will be notified. In case of membership change, only those MCOP routers that have previously validated networks for the changed MCOP controlled groups or channels will be Lehtonen, et al. Expires December 5, 2002 [Page 5] Internet-Draft Multicast Control Protocol (MCOP) June 2002 notified. When a MCOP router no longer has active sources or receivers to a MCOP controlled group or channel in one of its directly connected subnets, it will notify the MCA with a MCOP Reset message. The Reset message tells the MCA that the MCOP router no longer needs updates for that combination. Lehtonen, et al. Expires December 5, 2002 [Page 6] Internet-Draft Multicast Control Protocol (MCOP) June 2002 4. MCOP Message Formats 4.1 Common Header Each MCOP message consists of the MCOP header followed by a number of typed objects. All values in MCOP messages are unsigned. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Res | Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version: 4 bits o Current version number is 1. Reserved: 4 bits o The reserved bits MUST be set zero on transmission and ignored on reception. Message Type: 8 bits o There are six message types currently specified for MCOP: Type number (hex) Message name Transport Protocol ----------------- ------------ ------------------ 0x00 Discover UDP 0x01 Offer UDP 0x10 Init TCP 0x11 Validate TCP 0x12 Result TCP 0x13 Reset TCP Message Length: 16 bits o The size of message in octets, which includes the common MCOP header and all encapsulated objects. 4.2 MCOP Object Formats All the objects follow the same object format, where each object begins with a four-octet header: Lehtonen, et al. Expires December 5, 2002 [Page 7] Internet-Draft Multicast Control Protocol (MCOP) June 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Length (octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ... Object contents ... : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 8 bits o Type field identifies the object class contained in the object. 0 = Message Integrity, 1 = Group Range or 2 = Group Member Subtype: 8 bits o Subtype identifies the subtype or version of the information contained in the object. Length: 16 bits o The length field is a two-octet value that describes the number of octets (including the object header) that compose the object. On the receiving side, a subsequent object boundary can be found by simply rounding up the previous stated object length to the next 32-bit boundary. 4.2.1 Message Integrity Object The integrity object contains a key id, a sequence number and a message digest for authenticating and validating the integrity of MCOP message. When used, integrity is provided at the end of a MCOP message as the last MCOP object. The digest is then computed over all of a particular MCOP message up to but not including the digest value itself. The sender of a MCOP message will compute and fill in the digest portion of the Integrity object. The receiver of a MCOP message will then compute a digest over the received message and verify it matches the digest in the received Integrity object. Type = 0 and Subtype = 0, HMAC digest The integrity object employs HMAC [6] (Keyed-Hashing for Message Authentication) to calculate the message digest based on a key shared between the MCOP router and MCA. Lehtonen, et al. Expires December 5, 2002 [Page 8] Internet-Draft Multicast Control Protocol (MCOP) June 2002 This Integrity object specifies a 32-bit Key ID used to identify a specific key shared between a particular MCOP router and MCA and the cryptographic algorithm to be used. The Key ID allows for multiple simultaneous keys to exist on the MCOP router with corresponding keys on the MCA for each MCOP router. The key identified by the Key ID was used to compute the message digest in the Integrity object. All implementations, at a minimum, MUST support HMAC-MD5-96, which is HMAC employing the MD5 Message-Digest Algorithm [7] truncated to 96- bits to calculate the message digest. This object also includes a sequence number that is a 32-bit unsigned integer used to avoid replay attacks. The sequence number is initiated to contain a pseudo-random value with a MCOP Init message and is then incremented by one each time a new message is sent over the TCP connection in the same direction. If the sequence number reaches the value of 0xFFFFFFFF, the next increment will simply rollover to a value of zero. The variable length digest is calculated over a MCOP message starting with the MCOP common header up to the Integrity object (which MUST be the last object in a MCOP message) INCLUDING the Integrity object's Key ID and Sequence Number. The Keyed Message Digest field is not included as part of the digest calculation. In the case of HMAC-MD5- 96, HMAC-MD5 will produce a 128-bit digest that is then to be truncated to 96-bits before being stored in or verified against the Keyed Message Digest field as specified in HMAC [6]. The Keyed Message Digest MUST be 96-bits when HMAC-MD5-96 is used. The Message Integrity object can be used in MCOP Init, MCOP Validate, MCOP Result and MCOP Reset messages. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | ...Keyed Message Digest... | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lehtonen, et al. Expires December 5, 2002 [Page 9] Internet-Draft Multicast Control Protocol (MCOP) June 2002 4.2.2 Group Range Object The Group Range object contains the MCOP controlled multicast addresses in zero or more Group Address Blocks. Type = 1, Subtype = 0 (IPv4) or Subtype = 1 (IPv6) The length of the IP address in the Group Address field in Group Address Blocks depends on the subtype value defined in Section 4.2. For IPv4 the size of the address field is 32 bits while for IPv6 the size is 128 bits. The Group Range object is used in MCOP Init message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MCOP Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zero or More Group Address Blocks | . . . . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Group Address Block (IPv4): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S|E| Reserved | Address Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MCOP Lifetime: 32 bits o The field specifies the lifetime of MCOP controlled multicast addresses and MCOP controlled group and channel information in case the connection to MCA is disconnected. The value is in seconds and the default is 3600 seconds. The maximum value (0xFFFFFFFF) of this field is interpreted as infinity. Group Address: 32 bits (IPv4) or 128 bits (IPv6) o The Group Address specifies the MCOP controlled multicast address. R: 1 bit Lehtonen, et al. Expires December 5, 2002 [Page 10] Internet-Draft Multicast Control Protocol (MCOP) June 2002 o If Receiver bit is set, information in this Group Address Block applies to multicast receivers. S: 1 bit o If Source bit is set, information in this Group Address Block applies to multicast sources. E: 1 bit o If Exclude bit is set, the Group Address Block specified by the group address and address mask is not part of the MCOP controlled multicast addresses. Reserved: 21 bits o The reserved bits MUST be set zero on transmission and ignored on reception. Address Mask: 8 bits o The Address Mask specifies the address mask length for the MCOP controlled multicast address. For a single any-source multicast group or SSM channel the mask length is 32 (IPv4) or 128 (IPv6). 4.2.3 Group Member Object The Group Member object contains information about receivers and sources for one MCOP controlled group or channel. The object can be used to validate either single hosts or entire subnets. Type = 2, Subtype = 0 (IPv4) or Subtype = 1 (IPv6) The length of IP address fields in this object depends on the subtype value defined in Section 4.2. For IPv4 the size of the address field is 32 bits while for IPv6 the size is 128 bits. The Group Member object is used in MCOP Validate, MCOP Result and MCOP Reset messages. Lehtonen, et al. Expires December 5, 2002 [Page 11] Internet-Draft Multicast Control Protocol (MCOP) June 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address for Source-Specific Group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zero or More Address Blocks | . . . . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Block (IPv4): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S|E| Reserved | Address Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Multicast Group Address: 32 bits (IPv4) or 128 bits (IPv6) o Multicast Address of the multicast group G. The address MUST belong to the MCOP controlled multicast addresses, which were previously specified with Group Range object. Source Address for Source-Specific Group: 32 bits (IPv4) or 128 bits (IPv6) o The IP address of the source for source-specific group. The field is used only with source-specific multicast channels, which are identified by the multicast group address field. Together with the multicast group address it specifies a source-specific multicast [8] channel. If the multicast IP address does not belong to the SSM address range, the field is set to 0. IP Address: 32 bits (IPv4) or 128 bits (IPv6) o IP Address specifies the address of the IP network for which the Address Block contains MCOP information for. R: 1 bit o If Receiver bit is set, information in this Address Block applies to multicast receivers. Lehtonen, et al. Expires December 5, 2002 [Page 12] Internet-Draft Multicast Control Protocol (MCOP) June 2002 S: 1 bit o If Source bit is set, information in this Address Block applies to multicast sources. E: 1 bit o If Exclude bit is set, the Address Block specified by the IP address and address mask is not valid for group membership. Reserved: 21 bits o The reserved bits MUST be set zero on transmission and ignored on reception. Address Mask: 8 bits o The Address Mask specifies the address mask length of the IP network. For a single host the mask length is 32 (IPv4) or 128 (IPv6). Lehtonen, et al. Expires December 5, 2002 [Page 13] Internet-Draft Multicast Control Protocol (MCOP) June 2002 5. MCOP Specification 5.1 Discovery To be able to validate the status of the hosts, MCOP routers must connect to a MCA. When the TCP connection with the MCA is established the actual validation can begin. If the MCA IP address is not configured manually, it can be discovered automatically by using multicast. For security reasons, the recommended method is to use manual configuration. The procedure to find MCA is to send a MCOP Discover message (type 0x00) to site local scope Multicast-Control-Agents multicast address on port Agent-Port. MCOP Discover message uses UDP transport. MCOP Discover message MUST NOT include any objects after the common header. The Discover procedure SHOULD be repeated if no answer is received (MCOP Offer) within a certain time (retransmission_time). The time to wait before sending new MCOP Discover message can be calculated from the following formula: retransmission_time = min (2^(retransmission_number+1), 60) seconds. MCOP Offer message (type 0x01) is sent by MCA in response to MCOP Discover message. MCOP Offer is sent to unicast address of the sender of the MCOP Discover message using UDP. Destination port for MCOP Offer is copied from the Source port (UDP) in MCOP Discover message. MCOP Offer messages MUST NOT include any objects after the common header. MCOP router can receive multiple MCOP Offer messages and it can freely select the MCA it uses to validate multicast group information. For security reasons the whole discovery procedure may be disabled. 5.2 Initialization MCOP Init message (type 0x10) is sent by MCA to inform MCOP router about MCOP controlled multicast addresses. When MCOP router has figured out the IP address of MCA, it creates TCP connection to selected MCA (to TCP port Agent-Port) and waits for MCOP Init message. MCA lists all MCOP controlled multicast addresses in that message by including Group Range object. MCA also informs MCOP routers, whether the control must be applied to multicast receivers, multicast sources or both. MCA sends the MCOP Init message again to the MCOP router if the address space for MCOP controlled multicast addresses changes. MCOP Init message MUST NOT contain Group Member objects. The TCP connection between MCOP router and MCA MUST be left open for Lehtonen, et al. Expires December 5, 2002 [Page 14] Internet-Draft Multicast Control Protocol (MCOP) June 2002 future messages. The TCP connection is used by the MCOP router to validate the status of the directly connected hosts and to issue updates to the group status by the MCA. 5.3 Source/Receiver Validation MCOP Validate message (type 0x11) is used by MCOP router to check the status of the directly connected subnet for some multicast group from MCA. To reduce the number of Validate messages, the status of both receivers and sources for the subnet is requested with the same Validate message. When a MCOP router receives new multicast traffic sent to a MCOP controlled group or channel, the MCOP router initiates the validating procedure before it passes any traffic up the protocol stack. When a MCOP router receives an IGMP/MLD Report from a new host wishing to join a MCOP controlled group or channel, the MCOP router initiates the validating procedure before it passes the packet to IGMP/MLD processing. In both source and receiver case if the MCOP router does not know about the MCOP controlled group's or channel's valid receivers and sources already, it MUST retrieve this information by sending MCOP Validate message. This message is used to fetch multicast status information concerning one or more directly connected subnets to the MCOP router. If a new source or receiver becomes active for the same MCOP controlled group or channel, the MCOP router has the control information stored locally. The Group Member object is defined as follows: o Multicast Group Address specifies the multicast group that is validated with this Group Member object. o Source Address for Source-Specific Group identifies the IP address of the source if the multicast group is source-specific. If the address does not identify a source-specific multicast group, it is set to 0. o The address of the directly connected network of MCOP router, where the multicast traffic or IGMP Report was received from. The MCOP router can validate one or more subnets by listing them in Address Blocks. The R and S bits MUST be set to indicate that both receiver and source status are queried. MCOP Result message (type 0x12) is used to inform the MCOP routers about the current status of multicast sources and receivers. The message is sent by the MCA in response to the MCOP Validate message. Lehtonen, et al. Expires December 5, 2002 [Page 15] Internet-Draft Multicast Control Protocol (MCOP) June 2002 Even though the validation MUST be done for the whole subnet behind the MCOP router interface, the result may still contain individual host entries. If the group status changes, MCA MUST send unsolicited MCOP Result message to MCOP routers that have checked the group status earlier. Those unsolicited MCOP Result messages include only the changes to the multicast group status. The Group Member object for the MCOP Result message is defined as follows: o Multicast Address specifies the multicast group related to this Group Member object. o Source Address for Source-Specific Group identifies the IP address of the source if the multicast group is source-specific. o Address Blocks contain the network addresses and masks for valid members. For source-specific groups a valid source must be explicitly mentioned in the Address Block. Address Block can contain individual host entries (mask length = 32 or 128), but MCA SHOULD aggregate the addresses if possible. o The individual bits are interpreted as follows: R=1, S=0 and E=0 indicate valid receiver. R=0, S=1 and E=0 indicate valid source. R=1, S=1 and E=0 indicate valid receiver and source. R=1, S=0 and E=1 indicate non-valid receiver. R=0, S=1 and E=1 indicate non- valid source. R=1, S=1 and E=1 indicate non-valid receiver and source. 5.4 Reset MCOP Reset message (type 0x13) is used by MCOP router to inform the MCA that it no longer needs updates for a specific MCOP controlled group or channel. This is done by sending MCOP Reset message with Group Member object where the Multicast Group Address field specifies the multicast group in question and in case of source-specific group the Source Address field contains the multicast source in question. Address Blocks contain the subnets that don't need updates anymore. Both R and S bits MUST be set to indicate that this information refers to both receivers and sources. 5.5 Integrity checking If MCOP router and MCA are configured to use Integrity checking (both MCOP router and MCA MUST be configured with proper keys) for MCOP messages, they MUST NOT process MCOP Init, MCOP Validate, MCOP Result and MCOP Reset messages with invalid hash value in Integrity object Lehtonen, et al. Expires December 5, 2002 [Page 16] Internet-Draft Multicast Control Protocol (MCOP) June 2002 or without Integrity object. If the integrity check fails, the packet MUST be discarded silently and the TCP connection MUST be closed. Lehtonen, et al. Expires December 5, 2002 [Page 17] Internet-Draft Multicast Control Protocol (MCOP) June 2002 6. MCOP Router Functionality This chapter describes the functionality of a MCOP router including state machines for multicast receivers and sources. Multicast control that is performed by a MCOP router can be considered as an operation that is done before multicast traffic is given to multicast traffic processing or before the router processes IGMP/MLD packets. See Figure 7. --------------------------------------------------------------------- +-------+-------+-----+-------+---------------------------------+ |PIM-SM |PIM-DM | CBT | MOSPF |other multicast routing protocol | +-------+-------+-----+-------+---------------------------------+ | IGMP/MLD processing or multicast traffic forwarding | +---------------------------------------------------------------+ | MCOP processing (filtering layer) | +---------------------------------------------------------------+ | IP packet processing | +---------------------------------------------------------------+ Figure 7: MCOP processing within MCOP router --------------------------------------------------------------------- Multicast control is applied to a specific multicast address range that is specified by MCA in MCOP Init message. The MCOP router behavior discussed within this chapter is applied only to the multicast groups that belong to the MCOP controlled multicast address space. MCOP processing can be extracted from the router operation and implemented as a transparent filtering bridge between router and directly connected hosts, see Figure 8. This feature is useful for testing purposes and it shows that MCOP processing does not affect the behavior of IP multicast routing protocols. Lehtonen, et al. Expires December 5, 2002 [Page 18] Internet-Draft Multicast Control Protocol (MCOP) June 2002 --------------------------------------------------------------------- +--------------+ | | | IP multicast | | router | | | +------+-------+ | | +--------------+ +---------+ | standalone | | | | MCOP | | MCA | | processing +-------> MCOP protocol <-------+ | | device | | | +------+-------+ +---------+ | +--------------------------| e.g. Ethernet segment Figure 8: MCOP processing with transparent filtering bridge --------------------------------------------------------------------- 6.1 Processing IGMP/MLD Messages When MCOP router receives IGMP/MLD Report from a directly connected host sent to a multicast group that is configured as a MCOP controlled group or channel, MCOP router MUST validate the status of this new receiver. If the multicast group status exists in MCOP router the remote validation procedure with MCA is not needed. If the receiver is found from the list of valid receivers for this multicast group, the IGMP/MLD Report is passed for further IGMP/MLD processing. MCOP router continues passing IGMP/MLD Reports from that receiver unless the group status changes for that receiver. If the status changes the MCOP layer MUST generate IGMP/MLD Leave for that host and then start to discard further IGMP/MLD packets for this multicast group originating from that receiver. If the receiver is not found from the list of valid receivers. MCOP router starts to discard the IGMP/MLD Reports unless the group status changes for that source via unsolicited MCOP Result. The Figure 9 depicts the state machine for individual receiver as maintained by MCOP router. The state machine is used for each MCOP Lehtonen, et al. Expires December 5, 2002 [Page 19] Internet-Draft Multicast Control Protocol (MCOP) June 2002 controlled multicast group and channel. --------------------------------------------------------------------- +-------------++-------------------------------------------------------+ | || Event | | ++--------------+-------------+-------------+------------+ | State ||IGMP Report |MCOP Result |IGMP Leave |Query Timer | | || | | |Expires | +-------------++--------------+-------------+-------------+------------+ | ||start Query | - | - | - | | ||Timer | | | | | ||if new group | | | | | || {Send MCOP | | | | | || Validate | | | | |Init (I) || -> V state} | | | | | ||else if OK | | | | | || {Send IGMP | | | | | || Report (R) | | | | | || -> P state} | | | | | ||else | | | | | || -> F state | | | | +-------------++--------------+-------------+-------------+------------+ | ||restart |if OK |-> I state |-> I state | | ||Query Timer | {Send IGMP | | | |Validate (V) ||-> V state | Report (R) | | | | || | -> P state} | | | | || |else | | | | || | -> F state | | | +-------------++--------------+-------------+-------------+------------+ | ||Send IGMP |if NOT OK |Send IGMP |-> I state | | ||Report (R) | {Send IGMP |Leave (R) | | |Pass (P) ||restart | Leave (R) |-> I state | | | ||Query Timer | -> F state} | | | | ||-> P state |else | | | | || | -> P state | | | +-------------++--------------+-------------+-------------+------------+ | ||restart |if OK |-> I state |-> I state | |Filter (F) ||Query Timer | -> P state | | | | ||-> F state |else | | | | || | -> F state | | | +-------------++--------------+-------------+-------------+------------+ Figure 9: State machine for receiver --------------------------------------------------------------------- Lehtonen, et al. Expires December 5, 2002 [Page 20] Internet-Draft Multicast Control Protocol (MCOP) June 2002 6.2 Processing Multicast Traffic When MCOP router receives multicast traffic from a directly connected host to a MCOP controlled group or channel, MCOP router MUST validate the status of this new source. If the multicast group status exists in MCOP router the remote validation procedure with MCA is not needed. If the source is found from the list of valid sources for this multicast group, the traffic can be forwarded for further processing (multicast traffic forwarding). MCOP router continues forwarding the multicast traffic unless the group status changes for that source. If the source is not found from that list, the MCOP router MUST discard the multicast traffic originated from that source, which was sent to this multicast group. MCOP router continues to discard the traffic unless the group status changes for that source via unsolicited MCOP Result. The Figure 10 depicts the state machine for individual source as maintained by MCOP router. The state machine is used for each MCOP controlled multicast group and channel. --------------------------------------------------------------------- +-------------++-------------------------------------------------------+ | || Event | | ++-------------------+------------------+----------------+ | State || Multicast traffic | MCOP Result | Source Timer | | || arrival | | Expires | +-------------++-------------------+------------------+----------------+ | ||restart Source | - | - | | ||Timer | | | | ||if new group | | | | || {Send MCOP | | | | || Validate | | | | || -> V state} | | | |Init (I) ||else if OK | | | | || -> P state | | | | ||else | | | | || -> F state | | | +-------------++-------------------+------------------+----------------+ | ||restart |if OK |-> I state | | ||Source Timer | -> P state | | |Validate (V) ||-> V state |else | | | || | -> F state | | +-------------++-------------------+------------------+----------------+ Lehtonen, et al. Expires December 5, 2002 [Page 21] Internet-Draft Multicast Control Protocol (MCOP) June 2002 | ||restart |if NOT OK |-> I state | | ||Source Timer | -> F state | | |Pass (P) ||-> P state |else | | | || | -> P state | | +-------------++-------------------+------------------+----------------+ | ||restart |if OK |-> I state | |Filter (F) ||Source Timer | -> P state | | | ||-> F state |else | | | || | -> F state | | +-------------++-------------------+------------------+----------------+ Figure 10: State machine for source --------------------------------------------------------------------- 6.3 Creating Multicast Group Member Information If MCOP router does not have any status information about MCOP controlled group or channel members (new group or channel), the MCOP router MUST validate the status from the MCA by sending MCOP Validate message for the whole subnet where it received the traffic. The MCA replies with MCOP Result message, which contains information about the valid receivers and sources for that multicast group. The multicast group information is created by storing this information locally in MCOP router. The multicast group information is valid unless MCA updates the group status or the TCP connection to MCA is disconnected. 6.4 Removing Multicast Group Member Information Any individual source information MUST always be removed if the MCOP router has not received any multicast traffic from a directly connected source within time that is specified by the source timer. The default value for source timer is 300 seconds. The individual receiver information is removed when the receiver leaves the group (active or passive leaving). The query timer specifies the time limit for passive leaving (host does not send IGMP/MLD Leave message), which is 125 seconds by default. The whole multicast group member information is removed, when there are no active receivers and sources for that multicast group. When the whole multicast group member information is removed, MCOP router MUST inform the MCA that it no longer needs updates for this combination. This is done by sending MCOP Reset message for a that multicast group. Then the MCA can remove the corresponding MCOP router from its update list for this multicast Lehtonen, et al. Expires December 5, 2002 [Page 22] Internet-Draft Multicast Control Protocol (MCOP) June 2002 group. MCOP router may still get updates for this multicast group, if there are active members in other directly connected subnets for the MCOP router. MCOP router MUST also remove all multicast group information for MCOP controlled multicast addresses if the TCP connection to MCA is lost more than MCOP lifetime ago. 6.5 Updating Multicast Group Member Information The updating procedure is managed by MCA by sending an unsolicited MCOP Result message. This message MUST contain changes to valid sources and receivers for that multicast group in the respective fields. The removal of hosts from the list of valid hosts can be done by setting the exclude bit for those entries in the MCOP Result message. The MCOP router MUST update its local member information according to information in the MCOP Result message. The MCOP router SHOULD aggregate the address blocks according to longest match rules. The change in group member information affects directly the management of active receivers and sources, which are either set to passing or filtering state by this message. 6.6 Connection between MCOP Router and MCA MCOP router MUST maintain the TCP connection to MCA with TCP Keep- alive messages. TCP Keep-alive messages MUST be sent every 120 seconds. If the TCP connection is disconnected, all multicast group information for MCOP controlled multicast addresses MUST be removed from MCOP router after MCOP Lifetime seconds if the connection to MCA can not be re-established. MCOP Lifetime is set by MCA and it is sent to MCOP router in MCOP Init message. MCOP router is responsible for re-establishing the connection to MCA. When the connection to the MCA is re-established, all multicast group information for MCOP controlled multicast addresses MUST be removed and gathered again (from MCOP Init and MCOP Result messages). This is because the multicast group information (including the MCOP controlled multicast addresses) may have changed while the connection was disconnected. Lehtonen, et al. Expires December 5, 2002 [Page 23] Internet-Draft Multicast Control Protocol (MCOP) June 2002 7. MCA Functionality This chapter describes briefly the functionality of Multicast Control Agent (MCA). It also covers the information that MUST be stored on the MCA's database in order to the MCOP mechanism to work. 7.1 General Description MCA contains information about MCOP controlled multicast addresses and valid receivers and sources for MCOP controlled groups and channels. MCOP router validates the group members against the information stored within MCA. If information changes for MCOP controlled group or channel in MCA, MCA is responsible for updating the information to MCOP routers that have validated the group status earlier. The fact that MCA contains information about active multicast groups prevents unwanted multicast states to be appearing in the multicast routers, because the multicast tree is not created if the multicast information is not found from the MCA (MCA MUST deny the access from receivers and sources by default for MCOP controlled multicast addresses). 7.2 MCA Database MCA database information for each multicast group consists of the following parameters: o multicast group address o multicast source address (only for source-specific groups) o valid receivers (default = none) o valid sources (default = none) o connected MCOP routers and validated subnets, which are needed to update the multicast group status to MCOP routers (unsolicited MCOP Result). In addition to these multicast group specific parameters, MCA may need static, MCOP connection related parameters like IP addresses of MCOP routers, Keys and Key IDs for authentication and integrity operations, etc. Lehtonen, et al. Expires December 5, 2002 [Page 24] Internet-Draft Multicast Control Protocol (MCOP) June 2002 8. Security Considerations MCOP mechanisms allow us to control the hosts who are able to join or send traffic to a certain multicast group. This effectively prevents malicious hosts from joining a certain multicast group and it significantly reduces unnecessary multicast state information in routers (non-existing multicast group, invalid receiver, etc.). It also prevents other Denial of Service attacks like sending unwanted traffic to a certain multicast group. MCOP mechanisms can be used together with some encryption framework for IP multicast. This gives us even better possibilities to forward the multicast traffic towards valid receivers only, because MCOP framework has no mechanism to prevent a malicious host from getting the multicast traffic if one or more valid and active receivers locate on the same broadcast network segment (e.g. Ethernet). What comes to the automatic discovery of MCA, we should be aware that it is possible to attack against the MCOP framework by adding fake MCAs to the network. This can be prevented by configuring the MCA connection manually to MCOP router. All MCOP connections that validate the status for hosts are TCP connections and SHOULD use Integrity object to authenticate and check the integrity of the messages sent over the connection between the MCOP router and MCA. However, it should be noted that the current multicast model in the Internet is equal or more vulnerable to attacks than the worst-case model for controlled multicast. In this document IGMP and MLD refer to IGMPv3 and MLDv2, correspondingly. Hosts and routers SHOULD support IGMPv3/MLDv2 in order to have full support of MCOP mechanisms. The IGMP/MLD Report suppression mechanism that is used by earlier protocol versions does not give individual information about host's activity, which is needed to correctly manage the multicast group status in MCOP router. If one or more hosts in subnet support only IGMPv1/IGMPv2/MLDv1 the multicast control MUST be done on subnet basis to work properly. Then we don't have control over individual hosts, only over subnets. Lehtonen, et al. Expires December 5, 2002 [Page 25] Internet-Draft Multicast Control Protocol (MCOP) June 2002 9. IANA Considerations The IANA should assign the Multicast-Control-Agents multicast group address for both IPv4 and IPv6 from site-local scope. MCOP Agent- Port should be assigned for both TCP and UDP. Lehtonen, et al. Expires December 5, 2002 [Page 26] Internet-Draft Multicast Control Protocol (MCOP) June 2002 References [1] Visoottiviseth, V., Takahashi, Y. and N. Demizu, "Sender Initiated Multicast (SIM)", work in progress, July 2001. [2] Boivie, R., Feldman, N., Imai, Y., Livens, W., Ooms, D. and O. Paridaens, "Explicit Multicast (Xcast) Basic Specification", work in progress, October 2001. [3] Castelluccia, C. and G. Montenegro, "Securing Group Management in IPv6 with Cryptographically Generated Addresses", work in progress, February 2002. [4] Vida, R., Costa, L., Zara, R., Fdida, S., Deering, S., Fenner, B., Kouvelas, I. and B. Haberman, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", work in progress, January 2002. [5] Cain, B., Deering, S., Fenner, B., Kouvelas, I. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", work in progress, May 2002. [6] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [7] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [8] Bhattacharyya, S., Diot, C., Giuliano, L., Rockell, R., Meylor, J., Meyer, D., Shepherd, G. and B. Haberman, "An Overview of Source-Specific Multicast (SSM)", work in progress, March 2002. Authors' Addresses Rami Lehtonen Sonera Corporation Hatanpaan valtatie 20 Tampere 33100 Finland EMail: rami.lehtonen@sonera.com Lehtonen, et al. Expires December 5, 2002 [Page 27] Internet-Draft Multicast Control Protocol (MCOP) June 2002 Jyrki Soini Sonera Corporation Kumpulantie 3 Sonera 00051 Finland EMail: jyrki.soini@sonera.com Juha Majalainen Tampere University of Technology Korkeakoulunkatu 1 Tampere 33720 Finland EMail: majis@cs.tut.fi Heikki Vatiainen Tampere University of Technology Korkeakoulunkatu 1 Tampere 33720 Finland EMail: hessu@cs.tut.fi Lehtonen, et al. Expires December 5, 2002 [Page 28] Internet-Draft Multicast Control Protocol (MCOP) June 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Lehtonen, et al. Expires December 5, 2002 [Page 29]