| Mboned | M. Abrahamsson |
| Internet-Draft | T-Systems |
| Intended status: Best Current Practice | T. Chown |
| Expires: August 15, 2019 | Jisc |
| L. Giuliano | |
| Juniper Networks, Inc. | |
| T. Eckert | |
| Huawei | |
| February 11, 2019 |
Deprecating ASM for Interdomain Multicast
draft-ietf-mboned-deprecate-interdomain-asm-03
This document recommends deprecation of the use of Any-Source Multicast (ASM) for interdomain multicast. It recommends the use of Source-Specific Multicast (SSM) for interdomain multicast applications and that hosts and routers in these deployments fully support SSM. The recommendations in this document do not preclude the continued use of ASM within a single organisation or domain and are especially easy to adopt in existing intradomain ASM/PIM-SM deployments.
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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
The term IP and IP multicast are used to refer to both IPv4 and IPv6.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 15, 2019.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
IP Multicast has been deployed in various forms, within private networks, the wider Internet, and federated networks such as national or regional research networks. While a number of service models have been published, and in many cases revised over time, there has been no strong recommendation made by the IETF on the appropriateness of those models to certain scenarios, even though vendors and federations have often made such recommendations.
This document addresses this gap by making a BCP-level recommendation to deprecate the use of ASM for interdomain multicast, leaving SSM as the recommended interdomain mode of multicast. This recommendation thus also implicitly states that all hosts and routers that are expected to support interdomain multicast applications fully support SSM.
This document does not make any statement on the use of ASM within a single domain or organisation, and therefore does not preclude its use. Indeed, there are application contexts for which ASM is currently still widely considered well-suited within a single domain.
The main issue in most cases with moving to SSM is application support. Many applications are initially deployed for intradomain use and are later deployed interdomain. Therefore, this document recommends applications support SSM, even when they are initially intended for intradomain use. As explained below, SSM applications are readily compatible with existing intradomain ASM deployments as SSM is merely a subset of ASM.
Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) are the two multicast service models in use today. In ASM, as originally described in [RFC1112], receivers express interest in joining a multicast group address and routers use multicast routing protocols to deliver traffic from the sender(s) to the receivers. If there are multiple senders for a given group, traffic from all senders will be delivered to the receiver. Since receivers specify only the group address, the network, and therefore the multicast routing protocols, are responsible for source discovery.
In SSM, by contrast, receivers specify both group and source when expressing interest in joining a multicast stream. Source discovery in SSM is handled by some out-of-band mechanism (ie, the application layer), which drastically simplifies the network and how the multicast routing protocols operate.
IANA has reserved specific ranges of IPv4 and IPv6 address space for multicast addressing. Guidelines for IPv4 multicast address assignments can be found in [RFC5771], while guidelines for IPv6 multicast address assignments can be found in [RFC2375] and [RFC3307]. The IPv6 multicast address format is described in [RFC4291].
The most commonly deployed ASM routing protocol is Protocol Independent Multicast - Sparse Mode (PIM-SM), as detailed in [RFC7761]. PIM-SM, as the name suggests, was designed to be used in scenarios where the subnets with receivers are sparsely distributed throughout the network. Because receivers do not indicate sender addresses in ASM (but only group addresses), PIM-SM uses the concept of a Rendezvous Point (RP) as a ‘meeting point’ for sources and receivers, and all routers in a PIM-SM domain are configured to use specific RP(s), either explicitly or through dynamic RP discovery protocols.
To enable PIM-SM to work between multiple domains, an interdomain, inter-RP signalling protocol known as Multicast Source Discovery Protocol (MSDP) [RFC3618] is used to allow an RP in one domain to learn the existence of a source in another domain. Deployment scenarios for MSDP are given in [RFC4611]. MSDP floods information about all active sources for all multicast streams to all RPs in all the domains - even if there is no receiver for a given application in a domain. As a result of this key scalability and security issue, along with other deployment challenges with the protocol, MSDP was never extended to support IPv6 and remains an Experimental protocol.
To this day, there is no IETF Proposed Standard level interdomain solution for IPv4 ASM multicast because MSDP was the "best" component for the interdomain source discovery problem, and it is Experimental. Other protocol options where investigated at the same time but were never implemented or deployed and are now historic (e.g: [RFC3913]).
Due to the availability of more bits in an IPv6 address than in IPv4, an IPv6-specific mechanism was designed in support of interdomain ASM with PIM-SM leveraging those bits. Embedded-RP [RFC3956] allows routers supporting the protocol to determine the RP for the group without any prior configuration or discovery protocols, simply by observing the unicast RP address that is embedded (included) in the IPv6 multicast group address. Embedded-RP allows PIM-SM operation across any IPv6 network in which there is an end-to-end path of routers supporting this mechanism, including interdomain deployment.
Bidir-PIM [RFC5015] is another protocol to support ASM. There is no standardized option to operate Bidir-PIM interdomain. It is deployed intradomain for applications where many sources may want to sent traffic to the same IP multicast groups because unlike PIM-SM it does not create per-source state. Bidir-PIM is one of the important reasons for this document to not deprecate intradomain ASM.
SSM is detailed in [RFC4607]. It mandates the use of PIM-SSM for routing of SSM. PIM-SSM as it merely a subset of PIM-SM ([RFC7761]).
PIM-SSM expects that the sender’s source address(es) is known in advance by receivers through some out-of-band mechanism (typically in the application layer), and thus the receiver's designated router can send a PIM JOIN directly towards the source without needing to use an RP.
IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. See [RFC4607]. For IPv6, the address prefix FF3x::/32 is reserved for source-specific multicast use.
In enterprise and campus scenarios, ASM in the form of PIM-SM is likely the most commonly deployed multicast protocol. The configuration and management of an RP (including RP redundancy) within a single domain is a well understood operational practice. However, if interworking with external PIM domains is needed in IPv4 multicast deployments, interdomain MSDP is required to exchange information about sources between domain RPs. Deployment experience has shown MSDP to be a complex and fragile protocol to manage and troubleshoot (complex flooding RPF rules, state attack protection, filtering of undesired sources, ...).
PIM-SM is a general purpose protocol that can handle all use cases. In particular, it was designed for cases such as videoconferencing where multiple sources may come and go during a multicast session. But for cases where a single, persistent source for a group is used, and receivers can be configured to know of that source, PIM-SM has unnecessary complexity. Therefore, SSM removes the need for many of the most complex components of PIM-SM.
As explained above, MSDP was not extended to support IPv6. Instead, the proposed interdomain ASM solution for PIM-SM with IPv6 is Embedded-RP, which allows the RP address for a multicast group to be embedded in the group address, making RP discovery automatic for all routers on the path between a receiver and a sender. Embedded-RP can support lightweight ad-hoc deployments. However, it relies on a single RP for an entire group that could only be made resilient within one domain. While this approach solves the MSDP issues, it does not solve the problem of unauthorised sources sending traffic to ASM multicast groups; this security issue is one of biggest problems of interdomain multicast.
As stated in RFC 4607, SSM is particularly well-suited to dissemination-style applications with one or more senders whose identities are known (by some out-of-band mechanism) before the application starts running or applications that utilize some signaling to indicate the source address of the multicast stream (e.g., electronic programming guide in IPTV applications). PIM-SSM is therefore very well-suited to applications such as classic linear broadcast TV over IP.
SSM requires applications, host operating systems and the designated routers connected to receiving hosts to support IGMPv3 [RFC3376] and MLDv2 [RFC3810]. Support for IGMPv3 and MLDv2 has become widespread in common OSes for several years (Windows, MacOS, Linux/Android) and is no longer an impediment to SSM deployment.
This section describes the three key benefits that SSM with PIM-SSM has over ASM. These benefits also apply to intradomain deployment but are even more important in interdomain deployments. See [RFC4607] for more details.
A significant benefit of SSM is the reduced complexity that comes through eliminating the network-based source discovery required in ASM with PIM-SM. Specifically, SSM eliminates the need for RPs, shared trees, Shortest Path Tree (SPT) switchovers, PIM registers, MSDP, dynamic RP discovery mechanisms (BSR/AutoRP) and data-driven state creation. SSM simply utilizes a small subset of PIM-SM, alongside the integration with IGMPv3 / MLDv2, where the source address signaled from the receiver is immediately used to create (S,G) state. Eliminating network-based source discovery for interdomain multicast means the vast majority of the complexity of multicast goes away.
This reduced complexity makes SSM radically simpler to manage, troubleshoot and operate, particularly for backbone network operators. This is the main operator motivation for the recommendation to deprecate the use of ASM in interdomain scenarios.
Note that this discussion does not apply to Bidir-PIM, and there is (as mentioned above) no standardized interdomain solution for Bidir-PIM. In Bidir-PIM, traffic is forwarded to an RPs instead o building state as in PIM-SM. Even in the absence of receivers. Bidir-PIM therefore trades state complexity with (potentially large amounts) of unnecessary traffic.
In ASM, IP multicast group addresses need to be assigned to applications and instances thereof, so that two simultaneously active application instances will not share the same group address and receive each others IP multicast traffic.
In SSM, no such IP multicast group management is necessary. Instead, the IP multicast group address simply needs to be assigned locally on a source like a unicast transport protocol port number: No two independent applications on the host must use same IP multicast group number. This does not require any network operator involvement.
SSM is implicitly secure against unauthorized/undesired sources. Receivers only receive packets from the sources they explicitly specify in their IGMP/MLD membership messages, as opposed to ASM where any host can send traffic to a group address and have it transmitted to all receivers. With PIM-SSM, traffic from sources not requested by any receiver will be discarded by the first-hop router (FHR) of that source, minimizing source attacks against shared network bandwidth and receivers.
This benefit is particularily important in interdomain deployments because there are no standardized solutions for ASM control of sources and the most common intradomain operational practices such as Access Control Lists (ACL) on the sender's FHR are not feasible for interdomain deployments.
This topic is expanded upon in [RFC4609].
This document recommends that the use of ASM is deprecated for interdomain multicast, and thus implicitly, that hosts and routers that support such interdomain applications fully support SSM and its associated protocols. Best current practices for deploying interdomain multicast using SSM are documented in [RFC8313].
The recommendation applies to the use of ASM between domains where either MSDP (IPv4) or Embedded-RP (IPv6) is used.
An interdomain use of ASM multicast in the context of this document is one where PIM-SM with RPs/MSDP/Embedded-RP is run on routers operated by two or more separate administrative entities (domains, organisations).
The more inclusive interpretation of this recommendation is that it also extends to the case where PIM may only be operated in a single operator domain, but where user hosts or non-PIM network edge devices are under different operator control. A typical example of this case is an SP providing IPTV (single operator domain for PIM) to subscribers operating an IGMP proxy home gateway and IGMPv3/MLDv2 hosts (computer, tablets, set-top boxes).
This document recommends that all hosts, router platforms and security appliances used for deploying multicast support the components of IGMPv3 [RFC3376] and MLDv2 [RFC3810] necessary to support SSM (i.e., explicitly sending source-specific reports). The updated IPv6 Node Requirements RFC [I-D.ietf-6man-rfc6434-bis] states that MLDv2 support is a MUST in all implementations. Such support is already widespread in common host and router platforms.
Further guidance on IGMPv3 and MLDv2 is given in [RFC4604].
Multicast snooping is often used to limit the flooding of multicast traffic in a layer 2 network. With snooping, a L2 switch will monitor IGMP/MLD messages and only forward multicast traffic out on host ports that have interested receivers connected. Such snooping capability should therefore support IGMPv3 and MLDv2. There is further discussion in [RFC4541].
The recommendation to use SSM for interdomain multicast means that applications should properly trigger the sending of IGMPv3/MLDv2 source-specific report messages. It should be noted, however, there is a wide range of applications today that only support ASM. In many cases this is due to application developers being unaware of the operational concerns of networks. This document serves to provide clear direction for application developers to support SSM.
It is often thought that ASM is required for multicast applications where there are multiple sources. However, RFC 4607 also describes how SSM can be used instead of PIM-SM for multi-party applications:
Some useful considerations for multicast applications can be found in [RFC3170].
Applications with many-to-many communication patterns can create more (S,G) state than feasible for networks, whether the source discovery is done by ASM with PIM-SM or at the application level and SSM/PIM-SM. These applications are not best supported by either SSM/PIM-SSM or ASM/PIM-SM.
Instead, these applications are better served by routing protocols that do not create (S,G) such as Bidir-PIM. As of today, Unfortunately, many applications simply use ASM for service discovery, for example by clients sending IP multicast packets to elicit unicast replies from server(s). Deploying any form of IP multicast solely in support of such service discovery is in general not recommended (complexity, control, ...) but instead dedicated service discovery via DNS [RFC6763]
Best practices should be developed to explain when to use SSM in applications, when ASM without (S,G) state in the network is better, or when dedicated service-discovery mechanisms should be used.
If feasible, it is recommended for applications to use SSM even if they are initially only meant to be used in intradomain environments supporting ASM. Because PIM-SSM is a subset of PIM-SM, existing intradomain PIM-SM networks are automatically compatible with SSM applications. Thus, SSM applications can operate alongside existing ASM applications. SSM's benefits of simplified address management and significantly reduced operational complexity apply equally to intradomain use.
However, for some applications it may be prohibitively difficult to add support for source discovery, so intradomain ASM may still be appropriate.
In the case of existing ASM applications that cannot readily be ported to SSM, it may be possible to use some form of protocol mapping, i.e., to have a mechanism to translate a (*,G) join or leave to a (S,G) join or leave, for a specific source, S. The general challenge in performing such mapping is determining where the configured source address, S, comes from.
There are existing vendor-specific mechanisms deployed that achieve this function, but none are documented in IETF documents. This may be a useful area for the IETF to work on as an interim transition mechanism. However, these mechanisms would introduce additional administrative burdens, along with the need for some form of address management, neither of which are required in SSM. Hence, this should not be considered a long-term solution.
A key benefit of SSM is that the receiver specifies the source-group tuple when signaling interest in a multicast stream. Hence, the group address need not be globally unique, so there is no need for multicast address allocation as long the reserved SSM range is used.
Despite the deprecation of interdomain ASM, it is recommended that operators should not filter ASM group ranges at domain boundaries, as some form of ASM-SSM mappings may continue to be used for some time.
The use of ASM within a single multicast domain such as a campus or enterprise is still relatively common today. There are even global enterprise networks that have successfully been using PIM-SM for many years. The operators of such networks most often use Anycast-RP [RFC4610] or MSDP (with IPv4) for RP resilience, at the expense of the extra operational complexity. These existing practices are unaffected by this document.
In the past decade, Bidir-PIM too has seen deployments to scale interdomain ASM deployments beyond the capabilities of PIM-SM. This too is unaffected by this document, instead it is encouraged where necessary due to application requirements (see Section 4.4.
This document does also not preclude continued use of ASM with multiple PIM-SM domains inside organisations, such as with IPv4 MSDP or IPv6 Embedded-RP. This includes organizations that are federations and have appropriate, non-standardized mechanisms to deal with the interdomain ASM issues explained in Section 3.2.
Existing PIM-SM deployments can usually be used to run SSM/PIM-SM applications with no or little changes. In some widely available router implentations of PIM-SM, PIM-SSM is simply enabled by default in the designated SSM address spaces whener PIM-SM is configuring/enabled. In other implementations, simple configuration options exist to enable it. This allows to easily migrate ASM applications to SSM/PIM-SSM solely through application side development/configuration work: adding above mentioned source-signaling via IGMPv3/MLDv2 and using SSM addresses. No network actions are required for this transitioning: Unchanged ASM applications can continue to co-exist without issues.
When running PIM-SM, IGMPv3/MLDv2 (S,G) membership reports may also result in the desired PIM-SSM (S,G) operations and bypass any RP procedures, but this is not standardized but depends on implementation and may require additional configuration in available products. In general, it is recommended to always use SSM address space for SSM applications. For example, the interaction of IGMPv3/MLDv2 (S,G) membership reports and Bidir-PIM is undefined and may not result in forwarding of any traffic.
Note that these migration recommendations do not include the considerations when or how to evolve those intradomain applications best served by ASM/Bidir-PIM from PIM-SM to Bidir-PIM. This may also be important but is outside the scope of this document.
Future work may attempt to overcome current limitations of ASM solutions, such as interdomain deployment solutions for Bidir-PIM, or source access control mechaisms for IPv6 PIM-SM with embedded-RP. Such work could modify or amend the recommendations of this document (like any future IETF standards/BCP work).
Nevertheless, this document does not believe that any ASM solution, even with such future work, can ever provide the same intrinsic security and network and address management simplicity as SSM (see Section 3.2). Instead, this document believes that future work for general purpose interdomain IP multicast is better spent on the SSM items listed in Section 4.
This document adds no new security considerations. It instead removes security issues incurred by interdomain ASM with PIM-SM/MSDP such as infrastructure control plane attacks and application and bandwidth/congestion attacks from unauthorised sources sending to ASM multicast groups. RFC 4609 describes the additional security benefits of using SSM instead of ASM.
This document makes no request of IANA.
Note to RFC Editor: this section may be removed upon publication as an RFC.
The authors would like to thank members of the IETF mboned WG for discussions on the content of this document, with specific thanks to the following people for their contributions to the document: Hitoshi Asaeda, Dale Carder, Jake Holland, Albert Manfredi, Mike McBride, Per Nihlen, Greg Shepherd, James Stevens, Stig Venaas, Nils Warnke, and Sandy Zhang.
[RFC-Editor: Please remove this section.]
02 - Toerless: Attempt to document the issues brought up on the list and discussion by James Stevens re. use of Bidir-PIM intradomain and IGMP/MLD interop issues.
- NOTE: Text was not vetted by co-authors, so rev'ed just as discussion basis.
- more subsection to highlight content. Added more detailled discussion about downsides of ASM wrt. address management and intrinsic source-control in SSM. Added recommendation to work on guidance when apps are best suited for SSM vs. ASM/Bidir vs. service discovery. Added recommendation how to evolve from PIM-SM to SSM in existing deployments. Added section on possible future interdomain ASM work (and why not to focus on it).
01 - Lenny: cleanup of text version, removed redundancies.
00 - initial IETF WG version. See draft-acg-mboned-deprecate-interdomain-asm for work leading to this document.