Multicast Considerations over IEEE 802 Wireless Media
Summary: Has 3 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
Alissa Cooper Discuss
Section 8: Are there plans for the IETF community to develop the guidelines mentioned? I'm wary of publishing an RFC that says the IETF should do something if there are in fact no plans for the IETF to do the thing. RFCs are not necessarily good motivators. Overall this is an interesting document, but it seems to be written in an overly casual way and assumes readers have a lot of context that is not included in the document itself. The Gen-ART review pointed out a number of bits of text that left this impression. It was posted in October and never responded to. I've picked out some bits of the review and added a few more of my own -- collectively addressing these would get the document into publishable shape for a wider audience I think. General: (1) On first use, please add citations for all the protocols mentioned in the document, as well as a few words to describe what each protocol does. For IETF readers, this will help them understand the implications of various 802 specifications without having to go look them up right away. (2) The IETF meeting network may be interesting as an example to contemplate, but to make this document broadly valuable it would be better to generalize the problem descriptions than to focus on the IETF meeting network. Section 3.1.4 seems a little thin to this non-expert. It is certainly true that "every station has to be configured to wake up to receive the multicast", but it seems like only a poorly designed protocol would create the situation where "the received packet may ultimately be discarded" on any kind of regular basis. If there are a class of packets that the receiver will ultimately discard, that sounds like they should be on a separate multicast address, or the sender should be determining if the packet will be discarded before sending it. Perhaps what this section is driving at is that multicast protocols are often designed without taking power-saving considerations into account, but then *that's* what this section should probably talk about. As it is, it sounds like the old joke about saying to the doctor, "My arm hurts when I do this" and the doctor replying, "The stop doing that". In section 3.2.1, the last paragraph is missing a bunch of information: "It's often the first service that operators drop": What is "it"? "Multicast snooping" is not defined. In what scenario are devices "registering"? Section 5.1: "...and sometimes the daemons just seem to stop, requiring a restart of the daemon and causing disruption." What a strange thing to say. Does this simply mean "and the current implementations are buggy"? Also section 5.1: "The distribution of users on wireless networks / subnets changes from one IETF meeting to the next". This document doesn't seem to be about the IETF meeting network. This sentence seems inappropriately specific. The "NAT" and "Stateful firewalls" sections are also overly specific to the IETF meeting network. Generalizing would help. Section 8: The first paragraph has too little useful comment. There is no reference for 802.1ak, the reference to 802.1Q is inline instead of in the references section, and the content of neither of these standards is explained in this document. The paragraph doesn't really lay out what the topic of discussion is, at least for someone like myself who is not versed in the topic.
Please respond to the rest of the Gen-ART review.
Roman Danyliw Discuss
** Section 9. Section 7 appears to recommend using an ARP sponge per Section 5.1. Please provide some general caution about ARP poisoning/false advertising that could undermine (DoS) this approach (that is being deployed to save battery power).
I support Alissa’s DISCUSS. My related comments on Section 5.1 are: -- Section 5.1 Firewall unused space. Per “… The distribution of users on wireless networks/subnets changes from one IETF meeting to the next …”, this text seems unnecessary and it strikes me as odd to base guidance on a single network. -- Section 5.1. NAT. Per “To NAT the entire … attendee networks”, what is the “attendee network” in this context? -- Section 5.1. Stateful firewalls. Per “But this conflicts with the need and desire of the IETF and other organizations to have the network as open as possible and to honor the end-to-end principle. An attendee on the meeting network should be an Internet host …”, this text appears to be written about the IETF meeting network. Honoring the end-to-end principle and network nodes between Internet hosts is not universal architecture for all organizations. Recommend rewording or removing these two sentences. ** Section 5. This section states that it is describing optimizations to address the issue discussion in Section 3. It would be clearer if this section notes which items from Section 3 are addressed. ** Section 5.1. Per “… and sometimes the daemons just seem to stop” seems to be an implementation issue, not a reflection on the technique or associated architecture. If this is the case, I recommend removing this text. ** Section 7. This section would be clearer if the explicitly activities in Section 4 and 5 being recommended were referenced. ** Section 9. The first paragraph makes references to RFC4601 and RFC5796 which is helpful -- thanks. I wasn’t sure what this meant in the context of this document which discusses multicast over wireless. This guidance doesn’t appear to be wireless specific. Assuming you meant that “all the usual multicast security guidance applies whether you are using wireless or not”, please include clarifying text of the rough form (edit as required): OLD: Multicast is made more secure in a variety of ways. NEW: Multicast deployed on wired or wireless networks as discussed in this document can be made more secure in a variety of ways. ** Editorial Nits: -- Section 3.1.2. Typo. s/techiques/techniques/ -- Section 3.2.1. Typo. s/utlize/utilize/ -- Section 4.7. s/AP has do the/AP has to do the/ -- Section 5.1. Typo. s/listen for ARP requests/listens for ARP requests/ -- Section 5.1. Typo. s/to an machine/to a machine/ -- IdNits reports: -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761)
Benjamin Kaduk Discuss
Section 9 says that "[RFC4601], for instance, mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol" but I could not find where such use of IPsec was mandated. (I do recognize that a similar statement appears almost verbatim in RFC 5796, but RFC 5796 seems focused on extending PIM-SM to support ESP in additon to the AH usage that was the main focus of the RFC 4601 descriptions, and does not help clarify the RFC 4601 requirements for me.) The closest I found was in Section 6.3.1 of RFC 4601: "The network administrator defines an SA and SPI that are to be used to authenticate all link-local PIM protocol messages (Hello, Join/Prune, and Assert) on each link in a PIM domain" but I do not think that applies to all usage of PIM-SM. Am I missing something obvious?
To what extent would it be wrong to use the common "BUM" abbreviation ("Broadcast/Unknown-Unicast/Multicast" to discuss the classes of traffic discussed in this hdocument? That is, we say "multicast" a lot but in several places the discussion suggests that broadcast is treated similarly, and it would be nice to have a uniform treatment for the cases where broadcast and multicast are effectively equivalent, so that it's easier to call out when there is an actual distinction between the handling for the two. (I guess that the "unknown unicast" case doesn't really apply at the MAC layer...) I have very little background on IEEE radio technologies, or radio technologies in general; my apologies in advance for the many questions I ask that betray my ignorance. I understand that I'm not exactly the target audience for this document and that it's not going to be appropriate to add clarifying text at all locations where I ask for help understanding the content. Abstract This document describes the problems of known limitations with wireless (primarily 802.11) Layer-2 multicast. Also described are nit: this doesn't flow very well; maybe just "describes the known limitations of wireless" would suffice? Section 1 send duplicate data to each recipient. With broadcast traffic, data is sent to every device regardless of their interest in the data. nit: maybe "expressed interest"? I expect there are some infrastructure-type broadcast traffic that is of interest to all participants in many IP networks. problem. Wi-Fi traffic classes may help. This document is intended to help make the determination about what problems should be solved by the IETF and what problems should be solved by the IEEE (see Section 8). Do we need formal IEEE buy-in before making this kind of statement? rates, no acknowledgements, and low data rate. It also explains some enhancements that have been designed at the IETF and IEEE 802.11 to ameliorate the effects of multicast traffic. Recommendations are I suggest clarifying whether this is "ameliorate the effects of multicast traffic on other users of the spectrum" or "ameliorate the effects of the radio medium on multicast traffic". Section 2 I agree with the TSV-art reviewer that a more precise definition of what the "packet error rate" is measuring would be useful. Section 3.1.1 traffic. Since multicast makes point-to-multipoint communications, multiple acknowledgements would be needed to guarantee reception at all recipients. Since there are no ACKs for multicast packets, it is nit: there seems to be an implicit "but that would be highly inefficient and is not done" between "multiple acks would be needed" and "there are no acks". Section 3.1.2 Multicast over wired differs from multicast over wireless because transmission over wired links often occurs at a fixed rate. Wi-Fi, on the other hand, has a transmission rate that varies depending upon the STA's proximity to the AP. The throughput of video flows, and the capacity of the broader Wi-Fi network, will change and will impact the ability for QoS solutions to effectively reserve bandwidth and provide admission control. nit: rhetorically, this sentence doesn't say when/why the throughput will change, but rather treats it as a spontaneous and independent event. For wireless stations associated with an Access Point, the power nit: I assume "associated with" refers to the current radio traffic, and not some administrative or organizational grouping, as a naive reader might expect using the default meaning of "associated"; some additional lead-in might be helpful. In fact, backward compatibility and multi-stream implementations mean that the maximum unicast rates are currently up to a few Gbps, so there can be more than 3 orders of magnitude difference in the transmission rate between multicast / broadcast versus optimal unicast forwarding. Some techiques employed to increase spectral nit: I think "backward compatibility" is only applicable to the 3 orders of magnitude difference in tx rate, and is not applicable to the maximum unicast rates being a few Gbps. Section 3.1.3 communications and degrade the overall capacity. Furthermore, transmission at higher power, as is required to reach all multicast STAs associated to the AP, proportionately increases the area of interference. nit: it's most precise when talking about interference to say what interferes with what else; in this case it would be (IIUC) the area in which multicast traffic causes interference with other consumers of the radio spectrum. Section 3.1.4 One of the characteristics of multicast transmission is that every station has to be configured to wake up to receive the multicast, even though the received packet may ultimately be discarded. This This seems like something of a non sequitur -- the text would work if we were discussing broadcast traffic, but for multicast aren't the intended recipients known? o Both unicast and multicast traffic can be delayed by power-saving mechanisms. Just to check my understanding: this is "works poorly" just because of the additional latency? (Is this effect more pronounced for multicast than for unicast?) o A unicast packet is delayed until an STA wakes up and requests it. Unicast traffic may also be delayed to improve power save, efficiency and increase probability of aggregation. o Multicast traffic is delayed in a wireless network if any of the STAs in that network are power savers. All STAs associated to the AP have to be awake at a known time to receive multicast traffic. These kind-of feel like sub-bullets of the previous point. Section 3.2.1 o ARP o DHCP o mDNS [RFC6762] o uPnP [RFC6970] After initial configuration, ARP (described in more detail later) and DHCP occur much less commonly, but service discovery can occur at any time. Some widely-deployed service discovery protocols (e.g., for finding a printer) utilize mDNS (i.e., multicast). It's often the nit: doesn't uPnP also fall under the "service discovery protocol" mantle? It's a little weird rhetorically to only mention the one but not the other, and leaves the uninformed reader wondering what the story is about uPnP. first service that operators drop. Even if multicast snooping is nit: rhetorically, this is missing some causality for "first of what". Section 3.2.3 On the whole this section is hard for me to follow. I make a couple specific points, but a broader rewrite may be in order. Multicast Listener Discovery (MLD) [RFC4541] is used to identify members of a multicast group that are connected to the ports of a switch. Forwarding multicast frames into a Wi-Fi-enabled area can use such switch support for hardware forwarding state information. Er, what switch support -- where did we previously discuss this? However, since IPv6 makes heavy use of multicast, each STA with an IPv6 address will require state on the switch for several and possibly many multicast solicited-node addresses. Multicast Am I supposed to know what a "solicited-node address" is based on the references already provided? Section 4.1 Is there an actual specification for Proxy ARP that can be referenced in addition to the powerpoint deck? I note that the toplevel Section 4 describes this content as "has been specified", which would seem to exclude speculative proposals. The AP knows the MAC address and IP address for all associated STAs. In this way, the AP acts as the central "manager" for all the 802.11 STAs in its basic service set (BSS). Proxy ARP is easy to implement at the AP, and offers the following advantages: Does it make sense to lead in this passage with "In Proxy Arp,"? Section 4.3 I'm not sure how accessible this content will be to readers that do not already have some background knowledge on wifi operation -- there are some logical connections between sentences that are left fairly implicit. Section 5.1 Some routers (often those based on Linux) implement a "negative ARP cache" daemon. Simply put, if the router does not see a reply to an ARP it can be configured to cache this information for some interval. Unfortunately, the core routers in use often do not support this. When a host connects to a network and gets an IP address, it will ARP for its default gateway (the router). The router will update its cache with the IP to host MAC mapping learned from the request (passive ARP learning). nit: the transition between first three and last two sentences seems a bit lacking. Firewall unused space The distribution of users on wireless networks / subnets changes from one IETF meeting to the next (e.g SSIDs are renamed, some SSIDs lose favor, etc). This makes utilization for particular SSIDs difficult to predict ahead of time, but usage can be monitored as attendees use the different networks. nit: I don't think the reference to the IETF meeting network adds any value here; the operational practice can be equally well described without such reference. NAT The broadcasts are overwhelmingly being caused by outside scanning / backscatter traffic. To NAT the entire (or a large portion) of the attendee networks would eliminate NAT translation entries for unused addresses, and so the router would never ARP for them. However, there are many reasons to avoid using NAT in such a blanket fashion. "attendee networks" seems to be another (implicit) reference to IETF meeting networks; I suggest rewording. Stateful firewalls Another obvious solution would be to put a stateful firewall between the wireless network and the Internet. This firewall would block incoming traffic not associated with an outbound request. But this conflicts with the need and desire of the IETF and other organizations to have the network as open as possible and to honor the end-to-end principle. An attendee on the meeting network should be an Internet host, and should be able to receive unsolicited requests. Unfortunately, keeping Again, a focus on the (IETF) meeting network that is not justified by the scope presented in the Abstract and Introduction. Section 5.2 Is there more that could be said about how this constraining is to be done? Are there well-known techniques to "segment off" (pun intended) small areas of service-discovery traffic within a larger multicast domain, that fall short of just blocking mDNS entirely? (Also, why is this section indented at the level of the sub-topics of the previous section, instead of normal section-level indentation?) Section 7 Future protocol documents utilizing multicast signaling should be carefully scrutinized if the protocol is likely to be used over wireless media. It's not entirely clear that this advice is going to make it to the authors of such future protocol documents, given the current intended status of this document. I might consider rephrasing in terms of the potential consequences if such future protocols do not take into account the considerations for wireless media, though that would of course make the statement fit less well into a section entitled "Recommendations". Proxy methods should be encouraged to conserve network bandwidth and power utilization by low-power devices. The device can use a unicast nit: I think this should be something like "The use of proxy methods should be encouraged"; right now the text has to be parsed as having "proxy methods" as the subject that is getting encouraged to conserve resources. Alternately, just add a comma. Multicast signaling for wireless devices should be done in a way compatible with low duty-cycle operation. Is there any further guidance to give on how this is to be done? Do any previous sections of this document offer specific advice that is relevant to this point? Section 8 The IETF should determine guidelines by which it may be decided that multicast packets are to be sent wired. For example, 802.1ak works on ethernet and Wi-Fi. 802.1ak has been pulled into 802.1Q as of 802.1Q-2011. If a generic solution is not found, guidelines for multicast over Wi-Fi should be established. I don't understand how these sentences are related to each other. The first one seems to be suggesting that the IETF should be telling protocols that use IP multicast that those protocols need to differentiate their behavior based on the physical layer in use, which seems (AFAIK) antithetical to the idea of the Internet Protocol. The second and third sentences seem to be making statements about particular IEEE technologies, I guess saying that they are available for both wired and wireless use, but doesn't tell me much about what features the IETF might be using from those technologies or why I should care about them. The last sentence talks of a "generic solution", but I don't know what problem it's supposed to be a solution for and how it relates to the previously mentioned technologies. There is no need to support 2^24 groups to get solicited node multicast working: it is possible to simply select a number of trailing bits that make sense for a given network size to limit the number of unwanted deliveries to reasonable levels. IEEE 802.1, What are "trailing bits"? issues. In reality, Wi-Fi provides a broadcast service, not a multicast service. On the physical medium, all frames are broadcast except in very unusual cases in which special beamforming transmitters are used. Unicast offers the advantage of being much This observation seems like it would be very useful to have much earlier in the document. Section 9 It might be worth mentioning the common issue with security protocols for multicast or group communications where there's a tradeoff between (expensive) per-message asymmetric cryptography and (cheap) symmetric cryptography where the shared group key allows any group member to impersonate the expected sender. We also discuss several mechanisms for improving efficiency that in effect involve a proxy acting on behalf of wireless stations (whether in the AP or a separate entity); such proxy methods in general have security considerations that require the proxy to be trusted to not misbehave. Similarly, when using mechanisms that convert multicast traffic to unicast traffic for traversing radio links, the AP (or other entity) is forced to explicitly track which subscribers care about what multicast traffic. This is generally a reasonable tradeoff, but does result in another entity that is tracking what entities subscribe to which multicast traffic. While such information is already (by necessity) tracked elsewhere, this does present an expansion of the attack surface for that potentially privacy-sensitive information. There are probably some privacy considerations worth mentioning for the "backbone router" model discussed in Section 4.2. Multicast is made more secure in a variety of ways. [RFC4601], for Would it be accurate to rephrase this more like "There are a variety of security mechanisms defined for multicast control- and data-plane traffic"? The current formulation feels confusing to me on two axes: whether it describes current or future specifications, and the nature of security improvements provided. (Actually, are the listed mechanisms only really applicable to control-plane traffic but not data-plane?)
Éric Vyncke Yes
Deborah Brungard No Objection
(Suresh Krishnan) No Objection
* Section 3.1.4. Is this really the case? I thought multicast was best effort. Can you add a reference to the relevant section of the 802.11* spec for this "Multicast traffic is delayed in a wireless network if any of the STAs in that network are power savers. All STAs associated to the AP have to be awake at a known time to receive multicast traffic." * Section 3.2.2. -> What does PIM have to do with IPv6 to be listed here? It applies just as well to IPv4. Can you clarify? -> What is "Geographic Routing"? -> Please add a reference to RFC4941 for this IPv6 privacy addresses in this sentence "IPv6 node will typically use multiple addresses, and may change them often for privacy reasons" * Sections 3.2.3. and 3.2.4. For the "solicited-node addresses" I think a reference to RFC4291 Section 2.7.1. would be extremely useful since this term is not used widely known outside hardcore IPv6 circles. * Section 3.2.4. -> The correct reference for IPv6 Neighbor Discovery should be RFC4861. RFC2461 has been obsolete for more than a decade now. Is there a specific reason you are referring to the older version of ND here while the rest of the document uses the right reference? -> I think it might be better to separate out the ARP issues into a separate section instead of lumping into this one titled "Spurious ND" * Section 8 "The IETF should determine guidelines by which it may be decided that multicast packets are to be sent wired..." I had the same question as Benjamin and would like to see this clarified.
(Mirja Kühlewind) No Objection
As TSV-ART reviewer, Gorry Fairhurst provided an extensive review of this doc in Last Call and a re-review of the current version just recently (Thanks!). There are still a large number of comments that have not been addressed and no response was provided from the authors so far. While many of his comments are mostly editorial, I believe that this doc could really benefit from addressing them. There are a couple of relevant references that Gorry provides in his review which I think should be cited by this document. Further as Gorry mentioned, there are congestion control schemes for multicast and also high-layer mechanism to make use of multicast support more reliable. This is not discussed at all. So I'm not even sure if the conclusion in section 8 is correct that multicast on 2-layer must be reliable. Given the number and details of problems listed, I find the discussion in section 8 way to high level anyway. Also probably editorial: I find it a bit confusion that section 5.1. suddenly speak all about the IETF network while the rest of the doc seems more general. Is that on purpose or is that a left over from merging two docs? I'm not raising any points on the Discuss-level as I believe most (TSV-ART) points are rather editorial (also some may touch technical points well), however, I also support the points raised by Alissa and the GEN-ART review and would really like to see them addressed before publication (ideally they would have been addressed before IESG evaluation...).
Barry Leiba No Objection
(Alexey Melnikov) No Objection
Alvaro Retana No Objection
I support Alissa's DISCUSS. Documentation nit: this document should be tagged in the Datatracker as also replacing draft-perkins-intarea-multicast-ieee802 .  https://mailarchive.ietf.org/arch/msg/mboned/PdwqOiMseSmeJiLnCl8JgLAOlE0
(Adam Roach) No Objection
Martin Vigoureux No Objection
Hi, thank you. Interesting read. However, a bit like Alissa, I'm not sure what the IETF should do (in terms of protocol design/extension), if anything. In fact, it seems that some solutions exist / have been standardized but are simply not yet implemented.
Warren Kumari Recuse
I'm an author, and so am recusing myself from the ballot. Thanks to Eric for being willing to be the responsible AD.