Network Working Group R. Lehtonen Internet-Draft J. Soini Expires: April 18, 2003 Sonera Corporation J. Majalainen H. Vatiainen Tampere University of Technology October 18, 2002 Multicast Control Protocol (MCOP) draft-lehtonen-magma-mcop-01.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 April 18, 2003. 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 introduces Multicast Control Protocol (MCOP) that makes it possible to selectively enable multicast receiving and sending. 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 Lehtonen, et al. Expires April 18, 2003 [Page 1] Internet-Draft Multicast Control Protocol (MCOP) October 2002 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 Agent (MCA) . . . . . . . . . . . . . . 5 2.4 MCOP Routers . . . . . . . . . . . . . . . . . . . . . . . 5 3. Applicability Statement . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8 5. MCOP Message Formats . . . . . . . . . . . . . . . . . . . 10 5.1 Common Header . . . . . . . . . . . . . . . . . . . . . . 10 5.2 MCOP Object Formats . . . . . . . . . . . . . . . . . . . 10 5.2.1 Message Integrity Object . . . . . . . . . . . . . . . . . 11 5.2.1.1 Key Maintenance . . . . . . . . . . . . . . . . . . . . . 13 5.2.2 Group Range Object . . . . . . . . . . . . . . . . . . . . 13 5.2.3 Group Member Object . . . . . . . . . . . . . . . . . . . 15 6. MCOP Specification . . . . . . . . . . . . . . . . . . . . 17 6.1 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2 Initialization . . . . . . . . . . . . . . . . . . . . . . 17 6.3 Source/Receiver Validation . . . . . . . . . . . . . . . . 18 6.4 Reset . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.5 Integrity checking . . . . . . . . . . . . . . . . . . . . 20 7. MCOP Router Functionality . . . . . . . . . . . . . . . . 21 7.1 Processing IGMP/MLD Messages . . . . . . . . . . . . . . . 22 7.2 Processing Multicast Traffic . . . . . . . . . . . . . . . 24 7.3 Creating Multicast Group Member Information . . . . . . . 25 7.4 Removing Multicast Group Member Information . . . . . . . 25 7.5 Updating Multicast Group Member Information . . . . . . . 26 7.6 Connection between MCOP Router and MCA . . . . . . . . . . 26 8. MCA Functionality . . . . . . . . . . . . . . . . . . . . 27 8.1 General Description . . . . . . . . . . . . . . . . . . . 27 8.2 MCA Database . . . . . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . 28 10. IANA Considerations . . . . . . . . . . . . . . . . . . . 30 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 31 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 32 References . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 33 Full Copyright Statement . . . . . . . . . . . . . . . . . 35 Lehtonen, et al. Expires April 18, 2003 [Page 2] Internet-Draft Multicast Control Protocol (MCOP) October 2002 1. Introduction Currently IP multicast architecture lacks dynamic and manageable control over the multicast receivers and sources. All hosts that join a multicast group (*, G) or (S, G) can receive the multicast traffic. This draft introduces Multicast Control Protocol (MCOP) that makes it possible to selectively enable multicast receiving and sending. MCOP is used between Multicast Control Agent (MCA) and routers that have directly connected multicast sources and receivers. The receiver and source control is done by MCOP enabled routers based on the information received from the MCA. MCA maintains an authorization database. 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 can be used as a multicast control tool by operators to control individual hosts or networks. By controlling multicast receivers within one domain or autonomous system operators can limit and control multicast traffic propagation into the area. On the other hand source control allows operators to control the multicast traffic that is originated from the domain or AS. Lehtonen, et al. Expires April 18, 2003 [Page 3] Internet-Draft Multicast Control Protocol (MCOP) October 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 April 18, 2003 [Page 4] Internet-Draft Multicast Control Protocol (MCOP) October 2002 3. Applicability Statement MCOP is designed for intra-domain multicast host and/or network control. Operators can use MCOP to control their multicast network usage by selectively enabling receiving and sourcing multicast traffic. Extensive inter-domain multicast control is not possible because individual domains can't control the flooding of MSDP SA messages. Thus domains that do not implement multicast control can join MCOP controlled groups and channels without authorization and resulted state information is propagated to MCOP controlled groups and channels via MSDP SA flooding. PIM Joins do not include any information about the host or network who wants to join the multicast group. It is however possible to run MCOP at RP and filter MSDP SA messages coming to our domain and MSDP SA messages originated from our domain, but this specific behaviour is not part of this specification. MCOP allows us to control both SSM and ASM multicast groups in intra- domain context. What comes to the inter-domain case with SSM, we can control traffic that comes to our domain by controlling IGMP/MLD Reports within our domain. If the source for SSM group is located in our domain, we can't control the receivers who can join that group. In case of ASM, we can control which multicast groups are active within our domain, but without MSDP SA control we can't control external sources who can send traffic to active controlled multicast group within our domain. We also lack external receiver control when the source is in our domain. This draft does not specify a protocol between MCAs. Authorization policy differs between operators and usually operators don't want to accept authorization information originated from other operators. MCOP does not directly offer any possibility for client applications to update information in MCA (e.g. in order to enable sources to control multicast receivers). This is however possible to implement but it is not part of this specification. Authentication of hosts that want to update information in MCA must be implemented if this kind of scenario is needed. The authorization information is not immediately loaded to the routers, but only upon request, because the multicast authorization database can be quite large and the authorization information can change dynamically. Multicast group join is postponed until receiver is validated. Use of MCOP may also cause first multicast packets be dropped before Lehtonen, et al. Expires April 18, 2003 [Page 5] Internet-Draft Multicast Control Protocol (MCOP) October 2002 sender is validated, if validation information is not available locally at MCOP router (e.g. multicast source is the first active source/receiver for the multicast group). MCOP messages may be implemented at some point over Diameter when the Diameter implementations are commonly available. At this point we have not specified the messages over Diameter in order to keep MCOP simple to implement. In this document IGMP and MLD refer to IGMPv3 [1] and MLDv2 [2], 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 receiver control MUST be done on subnet basis to work properly. In that case we don't have control over individual receivers, only over subnets. Lehtonen, et al. Expires April 18, 2003 [Page 6] Internet-Draft Multicast Control Protocol (MCOP) October 2002 4. 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 with a 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. Once 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 Lehtonen, et al. Expires April 18, 2003 [Page 7] Internet-Draft Multicast Control Protocol (MCOP) October 2002 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 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 April 18, 2003 [Page 8] Internet-Draft Multicast Control Protocol (MCOP) October 2002 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 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 April 18, 2003 [Page 9] Internet-Draft Multicast Control Protocol (MCOP) October 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 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 [3] 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 The integrity object employs HMAC [4] (Keyed-Hashing for Message Lehtonen, et al. Expires April 18, 2003 [Page 10] Internet-Draft Multicast Control Protocol (MCOP) October 2002 Authentication) to calculate the message digest based on a key shared between the MCOP router(s) and MCA. 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 [5] 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 [4]. 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 April 18, 2003 [Page 11] Internet-Draft Multicast Control Protocol (MCOP) October 2002 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 MCA. 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 April 18, 2003 [Page 12] Internet-Draft Multicast Control Protocol (MCOP) October 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 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 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 April 18, 2003 [Page 13] Internet-Draft Multicast Control Protocol (MCOP) October 2002 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 April 18, 2003 [Page 14] Internet-Draft Multicast Control Protocol (MCOP) October 2002 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 [6] 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). Lehtonen, et al. Expires April 18, 2003 [Page 15] Internet-Draft Multicast Control Protocol (MCOP) October 2002 6. MCOP Specification 6.1 Discovery MCOP routers must connect to MCA in order to be able to validate the status of the hosts. 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 Multicast-Control-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. 6.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 Multicast-Control-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. 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 Lehtonen, et al. Expires April 18, 2003 [Page 16] Internet-Draft Multicast Control Protocol (MCOP) October 2002 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 MCA 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 MCA. 6.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 Lehtonen, et al. Expires April 18, 2003 [Page 17] Internet-Draft Multicast Control Protocol (MCOP) October 2002 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 MCA. 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 MCA 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, MCA 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 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 Lehtonen, et al. Expires April 18, 2003 [Page 18] Internet-Draft Multicast Control Protocol (MCOP) October 2002 contain individual host entries (mask length = 32 or 128), but MCA 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. 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 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. 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 MCA. 6.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 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 April 18, 2003 [Page 19] Internet-Draft Multicast Control Protocol (MCOP) October 2002 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 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. Lehtonen, et al. Expires April 18, 2003 [Page 20] Internet-Draft Multicast Control Protocol (MCOP) October 2002 --------------------------------------------------------------------- +--------------+ | | | IP multicast | | router | | | +------+-------+ | | +--------------+ +---------+ | standalone | | | | MCOP | | MCA | | processing +-------> MCOP protocol <-------+ | | device | | | +------+-------+ +---------+ | +--------------------------| e.g. Ethernet segment Figure 8: 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 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 the receiver. MLD clients do not use global source address in MLD Reports, but instead link-local address is used. Implementations SHOULD use Inverse NDP [7] to get the global source address of the host that sent the MLD Report. If the receiver is not found from the list of valid receivers. MCOP Lehtonen, et al. Expires April 18, 2003 [Page 21] Internet-Draft Multicast Control Protocol (MCOP) October 2002 router starts to discard IGMP/MLD Reports. The Figure 9 depicts the state machine for individual receiver as maintained by MCOP router. The state machine is used for each MCOP 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 | | | +-------------++--------------+-------------+-------------+------------+ Lehtonen, et al. Expires April 18, 2003 [Page 22] Internet-Draft Multicast Control Protocol (MCOP) October 2002 Figure 9: 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 MCA is not needed. During the remote validation MCOP router SHOULD discard multicast packets originated from so far unauthorized source. 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 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 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 | | | Lehtonen, et al. Expires April 18, 2003 [Page 23] Internet-Draft Multicast Control Protocol (MCOP) October 2002 +-------------++-------------------+------------------+----------------+ | ||restart |if OK |-> I state | | ||Source Timer | -> P state | | |Validate (V) ||-> V state |else | | | || | -> F state | | +-------------++-------------------+------------------+----------------+ | ||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 --------------------------------------------------------------------- 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 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 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. Lehtonen, et al. Expires April 18, 2003 [Page 24] Internet-Draft Multicast Control Protocol (MCOP) October 2002 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 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. 7.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 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 MCA MCOP router MUST maintain the TCP connection to MCA 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 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 (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 April 18, 2003 [Page 25] Internet-Draft Multicast Control Protocol (MCOP) October 2002 8. 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. 8.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). 8.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 April 18, 2003 [Page 26] Internet-Draft Multicast Control Protocol (MCOP) October 2002 9. 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 Denial of Service attacks like sending unwanted traffic to a certain multicast group. However, control applies only to MCOP controlled multicast addresses. Thus we can't prevent DoS attacks done on the other multicast groups or multicast network in general. We can't also easily control external (outside of our domain/AS) sources from attacking multicast groups even if they are controlled by MCOP. One possibility is to enable multicast control in border routers and validate external sources also. However, this does not however prevent routers from building a state for the group since PIM Joins are not controlled. Other restriction is that we can't control external receivers from joining the multicast tree, if the internal sources are announced to external networks e.g. with MSDP SAs. PIM Joins do not have any information about the host/network who wants to join the multicast tree. Also the MSDP SAs are flooded to all parts of the Internet and control can't be applied to restrict the flooding. In general the MCOP suits best for intra domain/AS multicast network control. 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 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. 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 Lehtonen, et al. Expires April 18, 2003 [Page 27] Internet-Draft Multicast Control Protocol (MCOP) October 2002 the integrity of the messages sent over the connection between the MCOP router and MCA. 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 April 18, 2003 [Page 28] Internet-Draft Multicast Control Protocol (MCOP) October 2002 10. IANA Considerations The IANA should assign the Multicast-Control-Agents multicast group address for both IPv4 and IPv6 from site-local scope. MCOP Multicast-Control-Agent-Port should be assigned for both TCP and UDP. Lehtonen, et al. Expires April 18, 2003 [Page 29] Internet-Draft Multicast Control Protocol (MCOP) October 2002 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 April 18, 2003 [Page 30] Internet-Draft Multicast Control Protocol (MCOP) October 2002 12. Acknowledgements The authors would like to thank Miikka Tammi and MAGMA WG for their valuable feedback. Lehtonen, et al. Expires April 18, 2003 [Page 31] Internet-Draft Multicast Control Protocol (MCOP) October 2002 References [1] Cain, B., Deering, S., Fenner, B., Kouvelas, I. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", work in progress, May 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, June 2002. [3] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [4] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [6] 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. [7] Conta, A., "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", RFC 3122, June 2001. 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 Lehtonen, et al. Expires April 18, 2003 [Page 32] Internet-Draft Multicast Control Protocol (MCOP) October 2002 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 April 18, 2003 [Page 33] Internet-Draft Multicast Control Protocol (MCOP) October 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 April 18, 2003 [Page 34]