Internet Engineering Task Force R. Lehtonen Internet-Draft TeliaSonera Expires: April 19, 2005 Oct 19, 2004 Dynamic Multi-Source Discovery for SSM using MSDP draft-lehtonen-mboned-multissm-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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 19, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This draft specifies dynamic multi-source discovery for source-specific multicast (SSM). The source discovery is handled by the end-hosts and multicast routing has to be only SSM aware. The source discovery is achieved by sending MSDP Source Active messages through the original SSM channel. The support can be implemented on the application level. Lehtonen Expires April 19, 2005 [Page 1] Internet-Draft Dynamic Multi-Source Discovery for SSM Oct 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of the operation . . . . . . . . . . . . . . . . . . 4 3.1 Source functionality . . . . . . . . . . . . . . . . . . . 4 3.2 Group controller functionality . . . . . . . . . . . . . . 4 3.3 Receiver functionality . . . . . . . . . . . . . . . . . . 5 4. MSDP functionality . . . . . . . . . . . . . . . . . . . . . . 5 4.1 IPv4 and IPv6 Source-Active for MSDP lite TLV . . . . . . 6 5. Comparison with ASM/MSDP and Embedded-RP approaches . . . . . 8 5.1 ASM/MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2 Embedded-RP . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 10 9.2 Informative References . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12 Lehtonen Expires April 19, 2005 [Page 2] Internet-Draft Dynamic Multi-Source Discovery for SSM Oct 2004 1. Introduction Operational experience and analysis [8] has shown that current ASM model [6] implemented with MSDP [2] for source discovery has severe scaling and security problems in inter-domain scale. SSM model [3] provides better scaling and security properties, but does not provide direct support for source discovery. This draft specifies dynamic multi-source discovery for SSM by adding source discovery possibility through the SSM channel, while not compromising the security and scaling properties of SSM. The source discovery is based on well-known MSDP protocol, while not all of its features are needed for multi-source support for SSM. The source discovery functionality will be implemented in end-hosts, which means that the multicast routing does not need any additional functionality than SSM support (meaning PIM-SM [1] without Register/Register-Stop messages). It also simplifies the source control, since the original source for SSM channel has the control over the other sources. 2. Terminology Original SSM channel The SSM channel (C, G) established prior any multi-source signalling. The original SSM channel is used for in-band source discovery for the logical multicast group. Logical multicast group As multi-source support for SSM is introduced, we have to talk about logical multicast groups, which are formed from separate SSM channels, but belonging logically to the same multicast group. At minimum the logical multicast group is one SSM channel (C, G) consisting of one source and number of receivers. The logical multicast group shares the same group address. Group controller Group controller is the original source C for the SSM channel (C, G), which functions as MSDP peer between other sources and receivers. The group controller is able to filter out unwanted MSDP messages coming from the other sources. Group controller itself doesn't need to be a data source for the logical multicast group. If dedicated group controllers are used, it also give better possibilities for group controller availability and redundancy. Lehtonen Expires April 19, 2005 [Page 3] Internet-Draft Dynamic Multi-Source Discovery for SSM Oct 2004 3. Overview of the operation Dynamic multi-source discovery for SSM requires that in addition to the SSM support, hosts MUST support some of the MSDP functionalities, see section Section 4 for detailed information. Routers don't need any additional functionality over SSM support. This means that no RPs are needed in the network, no embedded RP information in multicast addresses is needed and no PIM Register/Register-Stop functionality is needed at DRs. The source discovery for a logical multicast group builds upon established, original SSM channel (C, G), where C is the source and/or controller for multicast group G. Note that the original SSM channel carries this source discovery information together with the normal multicast traffic coming from the source C (in case the group controller acts also as data source). 3.1 Source functionality When new source, S1 wants to send to the same logical multicast group, G, it has to send MSDP SA message to the group controller, C. The message is sent to the unicast address of the group controller with TCP/IP using TCP port number 6639. The source address of the MSDP SA message MUST match with the source address reported in the MSDP SA message itself. MSDP SA message MUST contain the following information: Address of the group controller = C Address of the logical multicast group = G Address of the new active source = S1 All active sources MUST regurlarly refresh the MSDP SA information to the group controller. The default refresh period is 180 seconds. TCP connection is kept alive between refresh periods. 3.2 Group controller functionality Group controller functionality is tied to one interface address C of the group controller, which constructs the original SSM channel (C, G) together with a chosen logical group address G. When the group controller receives MSDP SA message from the source, it makes a policy/access control decision based on some internal criteria, whether to forward the MSDP SA message further to the original SSM channel. Part of the mandatory policy decision is to check that the source IP address matches with the source address Lehtonen Expires April 19, 2005 [Page 4] Internet-Draft Dynamic Multi-Source Discovery for SSM Oct 2004 contained in the MSDP SA message itself. If the policy decision is to forward the message, group controller sets the destination address of the MSDP SA message to the logical group address = G, sends the message using UDP/IP and also updates its MSDP SA cache. If the policy decision prohibits the sending of the MSDP SA message, it will be silently discarded and the connection with the source SHOULD be closed. If the MSDP SA cache entry times out or the connection to the source is lost the group controller MUST remove the corresponding cache entry. The default cache entry lifetime is 180 seconds. Group controller is responsible to periodically send the all active source information towards the receivers. That information is used by the receivers to join/prune the source tree accordingly. The default time for periodical control messages is 60 seconds. 3.3 Receiver functionality Receivers are able to discover information about new sources by listening MSDP SA messages coming from the original SSM channel. Receivers MUST check that the source IP address of the MSDP SA message matches with the group controller address in the message itself. The group controller address can be also used to differentiate between groups that are accidentally using the same logical multicast group address (e.g. in case no group address reservation mechanism is in place). Depending on the host implementation they can directly join the new source by sending IGMPv3 [4] or MLDv2 [5] Report to the DR or they can forward this decision to the application. Also receivers can maintain MSDP SA cache, if they want to dynamically remove unactive sources and related state information. If the MSDP SA cache entry times out the receivers MUST send IGMP/MLD Leave message to remove the state information related to that source. The default cache entry lifetime is 180 seconds, but the receiver SHOULD remove immediately the sources that are not included in the periodical reports from group controller. If the receiver want to leave the logical multicast group (and all related sources), it just sends IGMP/MLD Leave with the group address G. 4. MSDP functionality The functionality of MSDP peers for dynamic multi-source discovery for SSM is only a subset of the normal MSDP functionality [2]. This section highlights the differencies between the MSDP implementations. Normally MSDP protocol messages are processed by RPs, but now the processing takes place in the hosts. This takes the workload off from the network and as the MSDP messages are sent to only relevant multicast groups, the scalability problems with MSDP doesn't account, Lehtonen Expires April 19, 2005 [Page 5] Internet-Draft Dynamic Multi-Source Discovery for SSM Oct 2004 see more in section Section 5. We refer to MSDP lite when we are talking about the MSDP implementation for multi-source support for SSM. MSDP lite uses both UDP and TCP over IP in comparison to TCP/IP for normal MSDP. The same port number than with TCP is used with UDP. While operating with UDP (group controller -> receivers), MSDP lite doesn't contain Peer Hold Timer, KeepAlive Timer or ConnectRetry Timer. MSDP lite doesn't support encapsulation of data from the source. As the MSDP lite works only between specified source, group controller and receivers, there is no need to implement any of the MSDP Peer-RPF Forwarding issues. MSDP lite uses the same TLV format in messages than normal MSDP. MSDP lite only supports TLV type 8 and 9 (both are new TLV types defined for MSDP lite). The maximum size of SA message is 1240 octets. This does not include TCP, UDP, IP or layer-2 headers. 4.1 IPv4 and IPv6 Source-Active for MSDP lite TLV IPv4: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 8 | Length | Entry Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Controller Address, C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | > z +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lehtonen Expires April 19, 2005 [Page 6] Internet-Draft Dynamic Multi-Source Discovery for SSM Oct 2004 IPv6: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | Length | Entry Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Group Controller Address, C | | (16 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Group Address | | (16 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ | Source Address | \ | (16 bytes) | ) z | | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Type IPv4 Source-Active for MSDP lite TLV is type 8 and for IPv6 the TLV is type 9. Length Is the length of the control information in the message. Length is given in octets and is 12 octets plus 4 times Entry Count for IPv4 and 36 octets plus 16 times Entry Count for IPv6. Entry Count Is the count of source addresses e.g. z entries (note above) which follow the Group Address field. So multiple sources can be encoded efficiently for the same logical multicast group address. Group Controller Address, C The address of the original SSM channel source, which is the group controller. Lehtonen Expires April 19, 2005 [Page 7] Internet-Draft Dynamic Multi-Source Discovery for SSM Oct 2004 Group Address The address of the original SSM channel (C, G) group, G. Source Address The IP address of the active source for logical multicast group. 5. Comparison with ASM/MSDP and Embedded-RP approaches ASM model with MSDP and Embedded RP model [7] implement the source discovery for multicast as a network feature. In this section a comparison to these approaches is presented. 5.1 ASM/MSDP Dynamic multi-source discovery for SSM differs from ASM/MSDP in radical way, as it uses MSDP lite, a subset of MSDP functionality, between hosts that are willing to support multi-source functionality. In ASM model, the MSDP is used between RPs in different domains to inform about active sources. The ASM model has severe scalability and security problems as the control of sources is distributed among the RPs and information about all active sources is flooded to every RP. Our model does this flooding only for the interest group, which is formed from the actual receivers of the new sources. Also the source control is centralized to the group controller, which means easier control properties. Also no multicast state information is built to routers, before the receiver actually joins the new source. Our models also gives the possibility to remove non-active sources from the distribution tree if the host uses MSDP SA cache. 5.2 Embedded-RP The functionality and characteristics of dynamic multi-source discovery for SSM is quite similar to Embedded-RP. The biggest difference is that with our approach there is no need to have RPs or PIM Register/Register-Stop messages, which makes our approach stronger against denial of service attacks. Our approach does not use the multicast traffic for source discovery purposes, but introduces special MSDP-based signaling to do that task. This means that the traffic always utilizes the best path in the network. The multicast network level simplicity is also a big advantage for dynamic multi-source discovery approach and there is no need to upgrade the routers. Our approach also gives the possibility for receivers to not join the new source for certain reasons. The dynamic multi-source discovery can be done on application level and Lehtonen Expires April 19, 2005 [Page 8] Internet-Draft Dynamic Multi-Source Discovery for SSM Oct 2004 therefore the speed of development and deployment could be fast. If some hosts doesn't want to implement the support, they can do so and co-exist with the hosts with such support. 6. Security Considerations To be safe against denial of service attacks, SA filter and limits SHOULD be used with MSDP lite to limit the number of announced sources for the logical multicast group. The mechanisms are similar to normal MSDP. However, those filters and limits provide better scalability in MSDP lite as the SA information is sent only to the original SSM channel receivers. Group controller SHOULD make use of IPSec for MSDP peer authentication to make sure that the MSDP peer is the same source that is contained in the MSDP SA message itself. The mechanism itself doesn't currently support the change of the group controller or the concept of backup group controller. The intention was to keep the protocol as simple as possible. If needed the redundancy and availability could be also guaranteed with other mechanisms (e.g. those that are used to secure the operation of WWW-servers). If support was backup controller is needed for some reason, we need to consider the fact that there could be also some access lists implemented within the group controller that allows only some hosts to source traffic to the multicast group. That makes it harder to change the group controller functionality to some other source, because you have to share also additional policy information. In cases where there is no source control, this could be possible to implement, but it complicates the overall functionality quite a lot. One problem is that receivers perhaps only trust to the group controller that they have specified in their (C, G) joins from the application (C meaning group controller address) and they are not willing to accept any signalling from the other hosts (possible DoS attack here as well). Then we have to extend the policy definition to include nodes that are "trusted" controllers. This could be admistratively configured within the domain or the policy information could be transferred between original and backup controller e.g. using IPSec. 7. IANA Considerations IANA should reserve TCP and UDP port number 6639 for MSDP lite purposes. In addition IANA should allocate a new MSDP TLV values 8 (IPv4 Source-Active for MSDP lite) and 9 (IPv6 Source-Active for MSDP lite) for MSDP lite. Lehtonen Expires April 19, 2005 [Page 9] Internet-Draft Dynamic Multi-Source Discovery for SSM Oct 2004 8. Acknowledgements Thanks to Beau Williamson, Stig Venaas, Pekka Savola, Jyrki Soini, Thomas Eriksson and Alex Jantunen for constructive comments and discussion. 9. References 9.1 Normative References [1] Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode PIM-SM): Protocol Specification (Revised)", draft-ietf-pim-sm-v2-new-10 (work in progress), July 2004. [2] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [3] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003. [4] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [5] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 9.2 Informative References [6] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [7] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", draft-ietf-mboned-embeddedrp-07 (work in progress), July 2004. [8] Rajvaidya, P., Ramachandran, K. and K. Almeroth, "Detection and Deflection of DoS Attacks Against the Multicast Source Discovery Protocol", IEEE Infocom 2003. Lehtonen Expires April 19, 2005 [Page 10] Internet-Draft Dynamic Multi-Source Discovery for SSM Oct 2004 Author's Address Rami Lehtonen TeliaSonera Hataanpaan valtatie 20 Tampere 33100 Finland EMail: rami.lehtonen@teliasonera.com Lehtonen Expires April 19, 2005 [Page 11] Internet-Draft Dynamic Multi-Source Discovery for SSM Oct 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lehtonen Expires April 19, 2005 [Page 12]