INTERNET DRAFT Janne Lundberg June 2002 Helsinki University of Technology Expires December 2002 Unidirectional link support for MLDv2 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This memo specifies an experimental extension to MLDv2 that enables the protocol to operate over unidirectional links. Protection against Denial of service attacks is provided by a simple cookie mechanism. This extension is intended for mobile hosts which use a unidirectional link technology to receive multicast data and need to frequently change their unidirectional point of attachment to the network. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2. Overview of the Protocol . . . . . . . . . . . . . . . . . . . 2.1. Multicast listening state maintained by nodes.. . . . . . 3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 3.1. Unidirectional Multicast Listener Query Message (UMLQD) . 3.2. Unidirectional Multicast Listener Report Message (UMLRM). 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 1. Introduction Unidirectional wireless links which are capable of transmitting IPv6 packets could be used to send multicast packets effectively. However, current versions of IGMP [2] and MLDv2 [3] assume that all links between hosts and last-hop routers are bidirectional. A solution to the problem is provided by RFC 3077 [1] which enables hosts and to communicate over unidirectional links as if the links were bidirectional, using a mechanism that tunnels packets at the link-layer. MLDv2 assumes that since the communication between hosts and routers is done using link-local addresses, only hosts that are located at the link are able to send packets to the router. If the tunneling protocol from RFC 3077 is used to make the unidirectional link appear bidirectional, this assumption no longer holds, and any host in the Internet is able to send packets to the router as if it was physically located at the link. This opens, for example, a DoS attack where any host in the network can spoof a request for a multicast group for which, no listeners actually reside on the link. IPsec could be used to authenticate MLDv2 messages, but it requires that Security Associations are configured, which cannot be done if hosts need to move to areas whose routers it does not know in advance. This draft introduces and extension for MLDv2 which enables MLDv2 to operate over unidirectional links, but does not introduce the same type of DoS vulnerability as using RFC3077 would. This document should be considered as an extension to or an appendix of [3] and it should be read together with it. 1.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4]. 1.2. Terminology Unidirectional multicast router A router which has at least one unidirectional interface which can be used to deliver IP-multicast packets to clients. Unidirectional Multicast Listener Discovery (UMLD) The extension to MLDv2 that is specified in this memo. UMLD router A router which implements UMLD. UMLD client A multicast lister which implements UMLD. 2. Overview of the protocol The extension maintains the basic operation of [2], but because the link is unidirectional, the upstream communication from the client to the router is directed through another network interface. Also a cookie exchange is added to protect against Denial of Service attacks. For bidirectional links, this UMLD maintains the normal operation of MLDv2. The protocol from this memo is to be operated only on links without bidirectionality. This memo only specifies the differences between UMLD and MLDv2. If some aspect of the protocol is not specified in this memo, it is to be implemented as is specified in [3]. A UMLD router periodically broadcasts the UMLQD message over its unidirectional links to announce its presence to clients. The UMLQD message is a modified Multicast Listener Query Message, which in addition to its functionality in MLDv2 is also used by the UMLD router to announce its contact address and current requester cookie to clients. A client that wishes to receive multicast data over the unidirectional link sends Unidirectional Multicast Listener Report Messages (UMLRM) to UMLD routers when normal MLDv2 would send a Multicast Listener Report Message. The UMLRM message has an additional Requester cookie field, which is filled with the last requester cookie that was received from the destination UMLD router. 2.1. Multicast listening state maintained by nodes UMLD does not require any new socket level state. At interface level the client MUST be able to additionally store the cookie that was receive most recently from the UMLD-router. The UMLD- server MUST store the per interface data needed to confirm valid cookie that may be sent by clients. That is, all cookies for the period of the Maximum Response Delay. 3. Message formats Header fields which have same names as in [3], are to be processed as specified in the draft. 3.1. Unidirectional Multicast Listener Query Message (UMLQD) Multicast Listener Queries are sent by multicast routers to query the multicast listening state of neighboring interfaces. Queries have the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBA | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Response Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | * * | | * Multicast Address * | | * * | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | * * | | * Router Contact Address * | | * * | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv |S| QRV | QQIC | Number of Sources (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requester Cookie | | | *---------------------------------------------------------------* | | * * | | * Source Address [1] * | | * * | | +- -+ | | * * | | * Source Address [2] * | | * * | | +- . -+ . . . . . . +- -+ | | * * | | * Source Address [N] * | | * * | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The existing fields in the request message remain the same as in MLDv2, except for the Type field which is given number (TBA by IANA). 3.1.1. Type To be allocated by IANA. 3.1.2. Requester Cookie A random value chosen by the sender of the message. Sender MUST store the sent values of this field with the multicast addresses it is sent with for the time indicated by the Maximum Response Code field. 3.1.3. Router Contact Address The destination address the receiver uses to send packets to the UMLD router. 3.2. Unidirectional Multicast Listener Report Message (UMLRM) The source and destination addresses in this packet may be of any scope that was received in the Router Contact Address field of the UMLQD message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBA | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |Nr of Mcast Address Records (M)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requester Cookie | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast Address Record [1] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast Address Record [2] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . . . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast Address Record [M] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.1. Type To be allocated by IANA. 3.2.2. Reserved SHOULD be set to zero by sender, and MUST be ignored by receiver. 3.2.3. Requester cookie The latest Requester Cookie that has been received from the UMLD router to which this packet is being sent. 4. Security Considerations The cookie mechanism is only used to protect unidirectional routers from reports that are received from hosts that do not reside within radio coverage of the router. MLDv2 protects against forged multicast delivery requests by accepting only requests which are sent using a link local address. This makes it impossible to send malicious MLDv2 request packets from outside the local link. UMLD routers allow clients to send request packet using global addresses and therefore would enable malicious client to request multicast delivery to a link where it does not reside. In UMLD the attack is defended against with the requester cookie. In order to send a valid requester cookie to the UMLD router, a client must have been able to recently receive a UMLRM message from the router, and must therefore be present on the link. The cookie mechanism does not limit attacks that are coming from within the link that is being attacked. References [1] Duros, E., A Link-Layer Tunneling Mechanism for Unidirectional Links, RFC 3077, March 2001. [2] Cain, B., Internet Group Management Protocol, Version 3. Work in progress, expires November 2002. [3] Vida, R., Multicast Listener Discovery Version 2 (MLDv2) for IPv6. Work in progress, expires December 2002. [4] Bradner, S., Key words for use in RFCs to Indicate Requirement Level, RFC 2409, November 1998. Author's Address Janne Lundberg Helsinki University of Technology Laboratory for Theoretical Computer Science P.O. Box 9201 02015 HUT Finland Phone: +358 40 588 6546 Email: jlu@tcs.hut.fi