Network Working Group R. Lehtonen Internet-Draft J. Soini Expires: August 12, 2003 Sonera Corporation J. Majalainen H. Vatiainen Tampere University of Technology February 11, 2003 Multicast Control Protocol (MCOP) draft-lehtonen-magma-mcop-02.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 August 12, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This draft introduces Multicast Control Protocol (MCOP) that may be used as a tool for multicast network management. MCOP provides multicast network remote management with centralized information database located at Multicast Control Server (MCS). It allows gradual, group and network specific multicast network deployment. MCOP protocol is used between MCS and routers that have directly connected multicast sources or receivers. The actual control is done by MCOP enabled routers based on the information received from the Lehtonen, et al. Expires August 12, 2003 [Page 1] Internet-Draft Multicast Control Protocol (MCOP) February 2003 MCS. MCOP router can filter IGMP/MLD reports and multicast 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 Server (MCS) . . . . . . . . . . . . . . . 5 2.4 MCOP Routers . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Applicability Statement . . . . . . . . . . . . . . . . . . 6 3.1 Threat Scenarios . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . 6 3.3 Limitations and Known Issues . . . . . . . . . . . . . . . . 7 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 9 5. MCOP Message Formats . . . . . . . . . . . . . . . . . . . . 11 5.1 Common Header . . . . . . . . . . . . . . . . . . . . . . . 11 5.2 MCOP Object Formats . . . . . . . . . . . . . . . . . . . . 11 5.2.1 Message Integrity Object . . . . . . . . . . . . . . . . . . 12 5.2.2 Group Range Object . . . . . . . . . . . . . . . . . . . . . 14 5.2.3 Group Member Object . . . . . . . . . . . . . . . . . . . . 16 5.2.4 Multicast Parameter Object . . . . . . . . . . . . . . . . . 17 6. MCOP Specification . . . . . . . . . . . . . . . . . . . . . 20 6.1 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2 Initialization . . . . . . . . . . . . . . . . . . . . . . . 20 6.3 Network Validation . . . . . . . . . . . . . . . . . . . . . 21 6.4 Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.5 Integrity checking . . . . . . . . . . . . . . . . . . . . . 24 7. MCOP Router Functionality . . . . . . . . . . . . . . . . . 25 7.1 Processing IGMP/MLD Messages . . . . . . . . . . . . . . . . 26 7.2 Processing Multicast Traffic . . . . . . . . . . . . . . . . 28 7.3 Creating Multicast Group Member Information . . . . . . . . 29 7.4 Removing Multicast Group Member Information . . . . . . . . 29 7.5 Updating Multicast Group Member Information . . . . . . . . 30 7.6 Connection between MCOP Router and MCS . . . . . . . . . . . 30 8. MCS Functionality . . . . . . . . . . . . . . . . . . . . . 31 8.1 General Description . . . . . . . . . . . . . . . . . . . . 31 8.2 MCS Database . . . . . . . . . . . . . . . . . . . . . . . . 31 9. Security Considerations . . . . . . . . . . . . . . . . . . 32 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 34 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 Normative References . . . . . . . . . . . . . . . . . . . . 36 Informative References . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37 Lehtonen, et al. Expires August 12, 2003 [Page 2] Internet-Draft Multicast Control Protocol (MCOP) February 2003 Intellectual Property and Copyright Statements . . . . . . . 38 Lehtonen, et al. Expires August 12, 2003 [Page 3] Internet-Draft Multicast Control Protocol (MCOP) February 2003 1. Introduction Currently IP multicast architecture has insufficient dynamic control management capabilities over the multicast networks. This draft introduces Multicast Control Protocol (MCOP) that may be used as a tool for multicast network management. MCOP provides access control to multicast networks by remote "access-lists" as well as with special purpose multicast parameters. MCOP is used between Multicast Control Server (MCS) and MCOP enabled routers that have directly connected multicast sources and receivers. The actual control is done by MCOP router based on the information received from the MCS. MCOP approaches multicast control by selectively filtering the IGMP/ MLD Reports and multicast traffic before multicast state information is created at the multicast routers. MCOP is designed for multicast control within one domain or autonomous system (AS). In addition, by controlling multicast receiving within one domain or AS operators can limit and control multicast traffic propagation into the area. On the other hand multicast sourcing control allows operators to control the multicast traffic that is originated from the domain or AS. MCOP allows gradual, group and network specific multicast network deployment. It may be used to block misbehaving host from sourcing traffic to certain multicast group. Lehtonen, et al. Expires August 12, 2003 [Page 4] Internet-Draft Multicast Control Protocol (MCOP) February 2003 2. Terminology 2.1 MCOP controlled groups and channels MCOP may be used to control some or all any-source multicast groups and source-specific multicast (SSM) channels. 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 We refer to all MCOP controlled groups and channels using term MCOP controlled multicast addresses. MCOP is not applicable to multicast addresses that belong to scopes that are equal or lower than link-local scope. 2.3 Multicast Control Server (MCS) MCS may be a standalone server or it may be built in a router. MCS defines the MCOP controlled multicast addresses and informs MCOP routers about them. MCS is also responsible for storing the multicast group information for MCOP controlled groups and channels. MCOP enabled routers use the MCOP protocol to query MCS whether or not the hosts in their directly connected networks are allowed to receive or send traffic to the MCOP controlled multicast addresses. MCS functionality can be divided to multiple servers for redundancy. 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 MCS. MCOP routers apply the control only to the directly connected networks. One MCOP router can connect to one and only one MCS at a given time. One MCS can be connected to multiple MCOP routers. Router implementations should allow to manually enable/disable MCOP functionality. Lehtonen, et al. Expires August 12, 2003 [Page 5] Internet-Draft Multicast Control Protocol (MCOP) February 2003 3. Applicability Statement 3.1 Threat Scenarios MCOP protects multicast groups from unwanted sources. This could be a DoS attack to a certain group or just a misbehaving source flooding traffic to a single or multiple multicast groups. MCOP protects also from unwanted multicast transmissions or groups (unintentional DoS e.g. receiving a high bandwidth stream by accident). Generally networks and hosts are not interested in receiving unwanted and unneeded traffic. That could be avoided by configuring certain multicast groups to be used only in certain networks (allow receiving for only some subnets). MCOP may be also used to restrict the multicast group state information in routers to a certain level by limiting the number of possible multicast groups that can be listened and send to (state information based DoS). MCOP may also be used to deliver rate limits to multicast sources, reducing the amount of sourced multicast traffic (traffic based DoS). Of cource group based control functions apply to MCOP controlled multicast addresses only. Therefore it is recommended to use MCOP for all multicast addresses. 3.2 Usage Scenarios MCOP is designed for intra-domain multicast network control. MCOP allows us to control both SSM and ASM multicast groups in intra-domain context. Operators may use MCOP to control their multicast network usage by selectively enabling multicast traffic receiving and sourcing. MCOP allows group and network based control and makes gradual multicast network deployment possible within the domain. In addition MCOP may be used to block unwanted sources/networks from sending traffic to specific multicast group or groups. MCOP may be used to control multicast parameters like maximum number of active groups that individual hosts can join or send traffic to. With centralized multicast control information (MCS) we have consistent multicast group information in our routers throughout the domain. This allows easy modifications to existing control information (e.g. block ASM within the domain). To sum up MCOP provides the following functions: Lehtonen, et al. Expires August 12, 2003 [Page 6] Internet-Draft Multicast Control Protocol (MCOP) February 2003 o 1. Group based control: which networks or hosts can or can't send traffic to a group. (applicable only to MCOP controlled groups and channels) o 2. Group based control: which networks can receive traffic from a group. (applicable only to MCOP controlled groups and channels) o 3. Network based control of the maximum number of groups that an individual host can receive traffic from. o 4. Network based control of the maximum number of groups that an individual host can send traffic to. o 5. Network based control of the total rate of traffic to multicast groups that an individual source can send. Items 1. and 2. can be implemented to some extent using normal access lists. However, access lists are difficult to manage and dynamic changes to access list information require a lot of work. The other items are more or less new control parameters that aid network management in various control needs. 3.3 Limitations and Known Issues If the source, which needs to be blocked for some reason, is outside of the controlled domain, it is not possible to filter that source with MCOP without implementing MSDP SA controlling at the MSDP Peer. MSDP SA controlling is not part of this specification. MCOP could be used to limit certain receivers from joining a specific multicast group, but the use of this functionality is limited, because the discrepancies in IGMP [1] and MLD [2] reporting mechanisms in different versions. This draft does not specify a protocol between MCSs (e.g. between domains). Control issues are based on local policies, which generally are not applicable to other domains. The control information is not immediately loaded to the routers, but only upon request because the multicast information database at MCS can be quite large and the control information can change dynamically. Multicast group join is postponed until receiver's network is validated. Use of MCOP may cause first multicast packets sent by the source be dropped, if validation information is not available locally at MCOP router yet (e.g. multicast source is the first active source/receiver for the multicast group). Lehtonen, et al. Expires August 12, 2003 [Page 7] Internet-Draft Multicast Control Protocol (MCOP) February 2003 Malicious host could make DoS attack by sending a large number of bogus IGMP/MLD Reports to the MCOP router. MCOP router should implement an IGMP/MLD Report rate limitation mechanism that notices these kind of attacks and filters all IGMP/MLD Reports with too high arrival rate. MCOP mechanisms don't prevent a malicious host from getting multicast traffic if one or more valid and active receivers locate on the same broadcast network segment (e.g. Ethernet). Some encryption framework for IP multicast should be considered, if that is a requirement. MCOP is limited to IP layer control. It can't validate upper layer information like UDP ports used on multicast group. Lehtonen, et al. Expires August 12, 2003 [Page 8] Internet-Draft Multicast Control Protocol (MCOP) February 2003 4. Protocol Overview MCOP uses UDP for the optional MCS autodiscovery protocol and TCP for the connection between MCOP router and its MCS. MCOP routers discover their MCSs either with static configuration or with a simple discovery protocol. The static configuration is done by configuring each MCOP router with its MCS's IP address. With static configuration the autodiscovery phase can be skipped altogether. The discovery is initiated by MCOP router by multicasting an MCOP Discover packet to the Multicast-Control-Agents multicast group. Potential MCSs 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 MCS. When the MCOP router has learned the address of its MCS, it will make a TCP connection to the MCS's address. Once the connection has been established, MCOP router sends Init Request message to MCS, where it lists all the connected networks that have directly connected hosts. After that the MCS informs the MCOP router about the MCOP controlled multicast addresses and multicast parameters with the MCOP Init message. MCOP router must control multicast traffic 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 MCS with a MCOP Validate message. A similar MCOP Validate is also sent if a multicast source for the group or the channel becomes active before a receiver. The MCS returns a MCOP Result message that contains information whether the hosts in the queried address ranges can send and/or receive traffic destined to the MCOP controlled group or channel. The information covers 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 MCS's MCOP controlled multicast addresses or receiver or source permissions are modified for MCOP controlled groups or channels, the MCS will notify the MCOP routers about the changes with an unsolicited MCOP Result message. If the list of MCOP Lehtonen, et al. Expires August 12, 2003 [Page 9] Internet-Draft Multicast Control Protocol (MCOP) February 2003 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 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 MCS with a MCOP Reset message. The Reset message tells the MCS that the MCOP router no longer needs updates for that combination. Lehtonen, et al. Expires August 12, 2003 [Page 10] Internet-Draft Multicast Control Protocol (MCOP) February 2003 5. MCOP Message Formats 5.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 0x05 Init Request TCP 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. 5.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 August 12, 2003 [Page 11] Internet-Draft Multicast Control Protocol (MCOP) February 2003 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, 2 = Group Member or 3 = Multicast Parameter. Subtype: 8 bits o Subtype identifies the subtype 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. 5.2.1 Message Integrity Object The text in this section is mostly taken from the COPS protocol [7] specification. 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 Lehtonen, et al. Expires August 12, 2003 [Page 12] Internet-Draft Multicast Control Protocol (MCOP) February 2003 The integrity object employs HMAC [3] (Keyed-Hashing for Message Authentication) to calculate the message digest based on a key shared between the MCOP router(s) and MCS. This Integrity object specifies a 32-bit Key ID used to identify a specific key shared between a particular MCOP router and MCS 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 MCS 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 [4] 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 [3]. The Keyed Message Digest MUST be 96-bits when HMAC-MD5-96 is used. The Message Integrity object can be used in MCOP Init Request, 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 August 12, 2003 [Page 13] Internet-Draft Multicast Control Protocol (MCOP) February 2003 5.2.1.1 Key Maintenance Key maintenance is outside the scope of this document, but MCOP implementations MUST at least provide the ability to manually configure keys and their parameters locally. The key used to produce the Integrity object's message digest is identified by the Key ID field. Thus, a Key ID parameter is used to identify one of potentially multiple simultaneous keys shared by the MCOP router and MCS. Each key must also be configured with lifetime parameters for the time period within which it is valid as well as an associated cryptographic algorithm parameter specifying the algorithm to be used with the key. At a minimum, all MCOP implementations MUST support the HMAC-MD5-96 cryptographic algorithm for computing a message digest for inclusion in the Keyed Message Digest of the Integrity object which is appended to the message. It is good practice to regularly change keys. Keys MUST be configurable such that their lifetimes overlap allowing smooth transitions between keys. At the midpoint of the lifetime overlap between two keys, senders should transition from using the current key to the next/longer-lived key. Meanwhile, receivers simply accept any identified key received within its configured lifetime and reject those that are not. 5.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 5.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. Lehtonen, et al. Expires August 12, 2003 [Page 14] Internet-Draft Multicast Control Protocol (MCOP) February 2003 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| 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 MCS 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 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. Reserved: 22 bits o The reserved bits MUST be set zero on transmission and ignored on reception. Lehtonen, et al. Expires August 12, 2003 [Page 15] Internet-Draft Multicast Control Protocol (MCOP) February 2003 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). 5.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 5.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. 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| Reserved | Address Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Multicast Group Address: 32 bits (IPv4) or 128 bits (IPv6) o Multicast Address of the multicast group G. The address MUST Lehtonen, et al. Expires August 12, 2003 [Page 16] Internet-Draft Multicast Control Protocol (MCOP) February 2003 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 [5] channel. If the multicast IP address does not belong to the SSM address range, the field MUST be 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. R: 1 bit o When Receiver bit is set, it indicates valid receiver. S: 1 bit o When Source bit is set, it indicates valid source. Reserved: 22 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). 5.2.4 Multicast Parameter Object The Multicast Parameter object contains parameters used by MCOP router for multicast control purposes. The parameters are intended to be used for all multicast groups and channels (not just for MCOP controlled groups and channels). Unfortunately, it is possible for hosts to circumvent these control mechanisms by changing source IP address. Type = 3, Lehtonen, et al. Expires August 12, 2003 [Page 17] Internet-Draft Multicast Control Protocol (MCOP) February 2003 Subtype = 0 (IPv4) or Subtype = 1 (IPv6) o Specifies the connected networks that have directly connected hosts. This subtype is used to aid MCS in sending the correct network specific multicast parameters to the MCOP router. This subtype MUST be included in MCOP Init Request message. Subtype = 2 (IPv4) or Subtype = 3 (IPv6) o Specifies network specific parameters that are applied to multicast receivers. This subtype SHOULD be included in MCOP Init message. Subtype = 4 (IPv4) or Subtype = 5 (IPv6) o Specifies network specific parameters that are applied to multicast sources. This subtype SHOULD be included in MCOP Init message. The parameters are carried in Address Range Parameter Blocks. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | One or More Address Range Parameter Blocks | . . . . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Range Parameters Block (IPv4): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Number of Groups per Host | Address Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Allowed Multicast Rate (kbits/s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP address and address mask specifies the network for which the parameters apply. For subtypes 0 and 1 the Number of Groups per Host field and Maximum Allowed Multicast Rate MUST be set to zero and ignored on reception. Lehtonen, et al. Expires August 12, 2003 [Page 18] Internet-Draft Multicast Control Protocol (MCOP) February 2003 Maximum Number of Groups per Host field specifies either the maximum number of groups that can be joined by a single host or the maximum number of groups that can be sent traffic to (within Source Timer). The meaning depends on the subtype in question. Maximum Number of Groups per Host field maximum value of 0xFFFFFF is interpreted as infinity. This is also the default value for all address ranges if no multicast parameter object is sent by MCS to the MCOP router. Maximum Allowed Multicast Rate is intended to be used for multicast sources. This parameter could be given to a rate limiting function within a router to restrict the amount of multicast traffic that an individual source can generate. Maximum Allowed Multicast Rate field maximum value of 0xFFFFFF is interpreted as infinity. This is also the default value for all address ranges if no multicast parameter object is sent by MCS to the MCOP router.This parameter has no meaning for multicast receivers because the rate for an individual host can not be explicitly measured. The Multicast Parameter object is used in MCOP Init Request and MCOP Init message. Lehtonen, et al. Expires August 12, 2003 [Page 19] Internet-Draft Multicast Control Protocol (MCOP) February 2003 6. MCOP Specification 6.1 Discovery MCOP routers must connect to MCS in order to be able to validate the status of the networks. When the TCP connection with the MCS is established the actual validation can begin. If the MCS's 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 MCS is to send a MCOP Discover message (type 0x00) to site local scope Multicast-Control-Servers multicast address on port Multicast-Control-Server-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 MCS 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 MCS it uses to validate multicast group information. For security reasons the whole discovery procedure may be disabled. 6.2 Initialization MCOP Init Request message (type 0x05) is sent by MCOP router to inform MCS about the connected networks that have directly connected hosts. MCOP Init message (type 0x10) is sent by MCS to inform MCOP router about MCOP controlled multicast addresses and general multicast parameters. When MCOP router has figured out the IP address of MCS, it creates TCP connection to selected MCS (to TCP port Multicast-Control-Agent-Port) and sends MCOP Init Request message. This message includes a Multicast Parameter object, in which the MCOP router lists all connected networks that have directly connected hosts. This information is used by MCS to reply with the correct multicast parameters, which can be network specific. If the Lehtonen, et al. Expires August 12, 2003 [Page 20] Internet-Draft Multicast Control Protocol (MCOP) February 2003 connected network information changes the MCOP router MUST send a new MCOP Init Request message to inform MCS about the update. MCS MUST keep track of reported networks per MCOP router to be able to send multicast parameter updates to correct routers. MCS responds with MCOP Init message, where it lists all MCOP controlled multicast addresses in that message by including Group Range object and general multicast parameters in Multicast Parameter object. MCS also informs MCOP routers, whether the control must be applied to multicast receivers, multicast sources or both. MCS sends the MCOP Init message again to the MCOP router if the address space for MCOP controlled multicast addresses or general multicast parameters changes. In that case the MCOP Init message updates the current information in MCOP Router. MCOP router MUST replace those MCOP controlled multicast addresses with new address blocks from the MCOP Init message that introduce overlap with the new MCOP Init message addresses. However, overlapping address blocks within one message are aggregated with longest match rules and applied as one update. MCOP Init message MUST NOT contain Group Member objects. The bits in the Group Address Block are interpreted as follows: o R=1, S=0 indicate that network and address mask is part of the MCOP controlled multicast addresses, but applies to multicast receivers only. o R=0, S=1 indicate that network and address mask is part of the MCOP controlled multicast addresses, but applies to multicast sources only. o R=1, S=1 indicate that network and address mask is part of the MCOP controlled multicast addresses and applies to both receivers and sources. o R=0, S=0 indicate that network and address mask is not part of the MCOP controlled multicast addresses. The TCP connection between MCOP router and MCS MUST be left open for 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 MCS. 6.3 Network 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 MCS. To reduce the number of Validate messages, the status of both receivers and sources for the subnet is requested with the same Lehtonen, et al. Expires August 12, 2003 [Page 21] Internet-Draft Multicast Control Protocol (MCOP) February 2003 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 cleared and ignored on reception at MCS. Validate message is used to query both receiver and source status at the same time. 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 MCS in response to the MCOP Validate message. 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, MCS MUST send unsolicited MCOP Result message to MCOP routers that have checked the group status earlier. Those unsolicited MCOP Result messages are treated as an update to the multicast group status. MCOP router MUST replace those already validated address blocks with new address blocks from the MCOP Result message that introduce overlap with the MCOP Result message addresses. However, overlapping address blocks within one Lehtonen, et al. Expires August 12, 2003 [Page 22] Internet-Draft Multicast Control Protocol (MCOP) February 2003 message are aggregated with longest match rules and applied as one update. 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 members in question. 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 MCS SHOULD aggregate the addresses if possible. The following network addresses and masks can be used to refer to whole multicast group: 0.0.0.0/0 indicate all IPv4 networks and ::/0 indicate all IPv6 networks. o R and S bits describe the validity or non-validity of a network or a host in question. If the MCS does not have information about the group or channel in question, it MUST set the network or host as non-valid. The individual bits are interpreted as follows: * R=1, S=0 indicate valid receiver. * R=0, S=1 indicate valid source. * R=1, S=1 indicate valid receiver and valid source. * R=0, S=0 indicate non-valid receiver and non-valid source. 6.4 Reset MCOP Reset message (type 0x13) is used by MCOP router to inform the MCS 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. MCOP router can also use 0.0.0.0/0 (IPv4) or ::/0 (IPv6) to remove all updates to the multicast group in question. Both R and S bits MUST be cleared and ignored on reception at MCS. Lehtonen, et al. Expires August 12, 2003 [Page 23] Internet-Draft Multicast Control Protocol (MCOP) February 2003 6.5 Integrity checking If MCOP router and MCS are configured to use Integrity checking (both MCOP router and MCS MUST be configured with proper keys) for MCOP messages, they MUST NOT process MCOP Init Request, MCOP Init, MCOP Validate, MCOP Result and MCOP Reset messages with invalid hash value in Integrity object or without Integrity object. If the integrity check fails, the packet MUST be discarded silently and the TCP connection MUST be closed. After that MCOP router SHOULD restart the discovery phase. Lehtonen, et al. Expires August 12, 2003 [Page 24] Internet-Draft Multicast Control Protocol (MCOP) February 2003 7. MCOP Router Functionality This chapter describes the functionality of a MCOP router including state machines for multicast receivers and sources. Multicast control performed by a MCOP router happens before multicast traffic is given to multicast traffic processing or before the router processes IGMP/MLD packets. See Figure 8. +-------+-------+-----+-------+---------------------------------+ |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 8: MCOP processing within MCOP router Multicast control is applied to a specific multicast address range that is specified by MCS 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 9. Lehtonen, et al. Expires August 12, 2003 [Page 25] Internet-Draft Multicast Control Protocol (MCOP) February 2003 +--------------+ | | | IP multicast | | router | | | +------+-------+ | | +--------------+ +---------+ | standalone | | | | MCOP | | MCS | | processing +-------> MCOP protocol <-------+ | | device | | | +------+-------+ +---------+ | +--------------------------| e.g. Ethernet segment Figure 9: MCOP processing with transparent filtering bridge 7.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 MCS is not needed. If the receiver is found from the list of valid receivers for this multicast group and the number of joined groups of the host is below the address range parameter value, 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 the 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 the receiver. MLD clients do not use global source address in MLD Reports, but instead link-local address is used. Implementations SHOULD use ICMP Node Information Query [6] to request the global scope source address of the host that sent the MLD Report. If the receiver is not found from the list of valid receivers. MCOP router starts to discard IGMP/MLD Reports. The Figure 10 depicts the state machine for individual receiver as maintained by MCOP router. The state machine is used for each MCOP Lehtonen, et al. Expires August 12, 2003 [Page 26] Internet-Draft Multicast Control Protocol (MCOP) February 2003 controlled multicast group and channel. +-------------++--------------------------------------------------------+ | || Event | | ++--------------+--------------+-------------+------------+ | State ||IGMP Report |MCOP Result |IGMP Leave |Query Timer | | || | | |Expires | +-------------++--------------+--------------+-------------+------------+ | ||start Query |Save Result |Drop Leave | - | | || Timer | | | | | ||if (max joins | | | | | || reached) | | | | | || Drop Report | | | | | || -> F state | | | | | ||else if (new | | | | | || group) | | | | | || Send MCOP | | | | | || Validate, | | | | |Init (I) || Buffer Report| | | | | || -> V state | | | | | ||else if (OK) | | | | | || Forward | | | | | || Report | | | | | || -> P state | | | | | ||else | | | | | || Drop Report | | | | | || -> F state | | | | +-------------++--------------+--------------+-------------+------------+ | ||restart |if (OK) |Flush Buffer,|Flush Buffer| | || Query Timer, | Forward |Drop Leave |-> I state | |Validate (V) ||Flush Buffer | Buffer.Report|-> I state | | | ||Buffer Report | -> P state | | | | ||-> V state |else | | | | || | Flush Buffer | | | | || | -> F state | | | +-------------++--------------+--------------+-------------+------------+ | ||Forward Report|if (OK) |Forward Leave|-> I state | | ||restart | -> state |-> I state | | |Pass (P) || Query Timer |else | | | | ||-> P state | Generate | | | | || | Leave | | | | || | -> F state | | | +-------------++--------------+--------------+-------------+------------+ | ||Drop Report, |if (OK) |Drop Leave |-> I state | | ||restart | -> P state |-> I state | | |Filter (F) || Query Timer |else | | | | ||-> F state | -> F state | | | +-------------++--------------+--------------+-------------+------------+ Lehtonen, et al. Expires August 12, 2003 [Page 27] Internet-Draft Multicast Control Protocol (MCOP) February 2003 Figure 10: State machine for receiver 7.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 MCS is not needed. During the remote validation MCOP router SHOULD discard multicast packets originated from the source. If the source is found from the list of valid sources for this multicast group and the number of groups the host is allowed to send is below the address range parameter, the traffic can be forwarded for further processing (multicast traffic forwarding). MCOP router continues forwarding the multicast traffic unless the group status changes for the source. If the source is not found from the list, the MCOP router MUST discard the multicast traffic originated from the source, which was sent to this multicast group. MCOP router continues to discard the traffic unless the group status changes for the source via unsolicited MCOP Result. The Figure 11 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. The state machine does not include rate limiting functionality, which should be handled by specific rate limiting functionality of the router. +-------------++-------------------------------------------------------+ | || Event | | ++-------------------+------------------+----------------+ | State || Multicast traffic | MCOP Result | Source Timer | | || arrival | | Expires | +-------------++-------------------+------------------+----------------+ | ||start Source Timer |Save Result | - | | ||if (max sends | | | | || reached) | | | | || -> F state | | | | ||else if (new group)| | | | || Send MCOP | | | |Init (I) || Validate | | | | || -> F state | | | | ||else if (OK) | | | | || Forward Traffic | | | | || -> P state | | | Lehtonen, et al. Expires August 12, 2003 [Page 28] Internet-Draft Multicast Control Protocol (MCOP) February 2003 | ||else | | | | || -> F state | | | +-------------++-------------------+------------------+----------------+ | ||restart |if (OK) |-> I state | | || Source Timer, | -> P state | | |Pass (P) ||Forward Traffic |else | | | ||-> P state | -> F state | | +-------------++-------------------+------------------+----------------+ | ||restart |if (OK) |-> I state | |Filter (F) || Source Timer, | -> P state | | | ||Drop Traffic |else | | | ||-> F state | -> F state | | +-------------++-------------------+------------------+----------------+ Figure 11: State machine for source 7.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 MCS by sending MCOP Validate message for the whole subnet where it received the traffic. The MCS 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 MCS updates the group status or the TCP connection to MCS is disconnected and MCOP lifetime expires. 7.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 600 seconds, which should allow low rate and bursty sources to operate. 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 MCS that it no longer needs updates for this combination. This is done by sending MCOP Reset Lehtonen, et al. Expires August 12, 2003 [Page 29] Internet-Draft Multicast Control Protocol (MCOP) February 2003 message for a that multicast group. Then the MCS can remove the corresponding MCOP router from its update list for this multicast 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 MCS is lost more than MCOP lifetime ago. 7.5 Updating Multicast Group Member Information The updating procedure is managed by MCS 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 clearing R and/or S bit(s) for those entries in the MCOP Result message. The MCOP router MUST replace its local member information according to information in the MCOP Result message. The MCOP router SHOULD aggregate the address blocks within MCOP Result message 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. 7.6 Connection between MCOP Router and MCS MCOP router MUST maintain the TCP connection to MCS with TCP Keep-alive messages. TCP Keep-alive timer SHOULD be set to 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 MCS can not be re-established. MCOP Lifetime is set by MCS and it is sent to MCOP router in MCOP Init message. MCOP router is responsible for re-establishing the connection to MCS. When the connection to the MCS is re-established (when a valid MCOP Init message is received), 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 August 12, 2003 [Page 30] Internet-Draft Multicast Control Protocol (MCOP) February 2003 8. MCS Functionality This chapter describes briefly the functionality of Multicast Control Server (MCS). It also covers the information that MUST be stored on the MCS's database in order to the MCOP mechanism to work. 8.1 General Description MCS 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 MCS. If information changes for MCOP controlled group or channel in MCS, MCS is responsible for updating the information to MCOP routers that have validated the group status earlier. The fact that MCS contains information about configured multicast groups prevents unwanted multicast state to be appearing in the multicast routers, because the multicast tree is not created if the multicast information is not found from the MCS (MCS MUST deny the access from receivers and sources by default for MCOP controlled multicast addresses). 8.2 MCS Database MCS 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 address range specific host group join and send limits 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, MCS may need MCOP connection related parameters like IP addresses of MCOP routers, Keys and Key IDs for authentication and integrity operations, etc. Lehtonen, et al. Expires August 12, 2003 [Page 31] Internet-Draft Multicast Control Protocol (MCOP) February 2003 9. Security Considerations It is possible to attack against the MCOP framework by adding fake MCSs to the network. This can be prevented by configuring the MCS connection manually to MCOP router. Maximum rate limit for an individual host, maximum number of joined multicast groups and maximum number of groups a host can send to can be circumvented using several IP addresses for a host. All MCOP connections that validate the status for networks 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 MCS. Current multicast model in the Internet is equal or more vulnerable to attacks than the worst-case model for controlled multicast. Lehtonen, et al. Expires August 12, 2003 [Page 32] Internet-Draft Multicast Control Protocol (MCOP) February 2003 10. IANA Considerations The IANA should assign the Multicast-Control-Servers multicast group address for both IPv4 and IPv6 from site-local scope. MCOP Multicast-Control-Server-Port should be assigned for both TCP and UDP. Lehtonen, et al. Expires August 12, 2003 [Page 33] Internet-Draft Multicast Control Protocol (MCOP) February 2003 11. Open Issues We should have a mechanism for hosts to learn about denied access. ICMP Administratively Prohibited can't be used according to current ICMP processing rules that prohibit MCOP router to send an ICMP error message to the host, because the IGMP/MLD Reports and multicast traffic are sent to a multicast group address. We would like to see an exception in the ICMP draft that makes the above procedure possible. The ICMP error messages could be sent with TTL/hop limit=1 and the maximum number of ICMP error messages received by the host would be the number of directly connected routers. This shouldn't be a problem for hosts. Lehtonen, et al. Expires August 12, 2003 [Page 34] Internet-Draft Multicast Control Protocol (MCOP) February 2003 12. Acknowledgements The authors would like to thank Miikka Tammi, Dave Thaler, Beau Williamson, Dan Forsberg, Brian Haberman and MAGMA WG for their valuable feedback. Lehtonen, et al. Expires August 12, 2003 [Page 35] Internet-Draft Multicast Control Protocol (MCOP) February 2003 Normative References [1] Cain, B., Deering, S., Fenner, B., Kouvelas, I. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [2] Vida, R., Costa, L., Fdida, S., Deering, S., Fenner, B., Kouvelas, I. and B. Haberman, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", work in progress, November 2002. [3] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [4] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [5] 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, November 2002. [6] Crawford, M., "IPv6 Node Information Queries", work in progress, May 2002. Lehtonen, et al. Expires August 12, 2003 [Page 36] Internet-Draft Multicast Control Protocol (MCOP) February 2003 Informative References [7] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. Authors' Addresses Rami Lehtonen Sonera Corporation Hatanpaan valtatie 20 Tampere 33100 Finland EMail: rami.lehtonen@sonera.com 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 August 12, 2003 [Page 37] Internet-Draft Multicast Control Protocol (MCOP) February 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). 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 assignees. 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 Lehtonen, et al. Expires August 12, 2003 [Page 38] Internet-Draft Multicast Control Protocol (MCOP) February 2003 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 August 12, 2003 [Page 39]