RFC 7732

Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL)

📅 published February 2016, from ietf

Forwarder Policy for Multicast with Admin-Local Scope in MPL ✨

Part 1 of 3 🎀 Here's the title block tea ☕: this is RFC 7732, titled Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL). It was written by P. van der Stok (Consultant) and R. Cragie (ARM Ltd.) and published in February 2016. It's Informational (ISSN 2070-1721), and it doesn't obsolete or update any other RFCs 💅

Abstract 💖

Okay so the whole point of this doc is to specify an automated policy for routing MPL multicast messages that have Admin-Local scope, but only inside a border router 🌸

Status of This Memo 📜

This doc is not an Internet Standards Track spec, bestie. It's published for informational purposes only 🦋

This is a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 🙈

Want the current status, errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc7732 ✨

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 🫶

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the publication date. Please actually read these, because they spell out your rights and restrictions. Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 💅

Table of Contents 📚

   1. Introduction ....................................................2
      1.1. Requirements Language ......................................4
      1.2. Terminology and Acronyms ...................................4
   2. Network Identifier ..............................................4
      2.1. IEEE 802.15.4 ..............................................5
      2.2. IEEE 802.11 ................................................5
      2.3. ITU-T G.9959 ...............................................5
      2.4. BLUETOOTH(R) Low Energy ....................................5
   3. MPL4 Router .....................................................5
      3.1. MPL Interface Parameters ...................................6
      3.2. Determination of MPL4 Zone .................................6
   4. Admin-Local Policy ..............................................7
      4.1. Legal Multicast Messages ...................................7
      4.2. Forwarding Legal Packets ...................................8
           4.2.1. MPL Message .........................................8
           4.2.2. Multicast Messages without MPL Option ...............9
      4.3. Encryption Rules ...........................................9
   5. MPL Domains and Zones ...........................................9
   6. Default Parameter Values .......................................10
   7. Security Considerations ........................................11
   8. References .....................................................12
      8.1. Normative References ......................................12
      8.2. Informative References ....................................14
   Acknowledgements ..................................................15
   Authors' Addresses ................................................15

1. Introduction ✨

Okay, first things first: multicast scopes are defined in [RFC4291]. Then [RFC7346] adds this extra text to the scope definition 👑

"Interface-Local, Link-Local, and Realm-Local scope boundaries are automatically derived from physical connectivity or other non-multicast-related configurations. Global scope has no boundary. The boundaries of all other non-reserved scopes of Admin-Local or larger are administratively configured."

So the Admin-Local scope has to be administratively configured. Here, "administratively configured" doesn't mean a human doing a bunch of stuff beyond installing the protocol in this doc. It means an automatic derivation, as described in this doc 🦋

This doc describes an automated policy for forwarding MPL [RFC7731] multicast messages with Admin-Local scope inside a border router that sits between an MPL network and some other network. It's totally in line with the autonomous networking ideas from [RFC7576] 🧚

The Realm-Local multicast address is what MPL currently uses to propagate a multicast message to all receivers and forwarders in a mesh network. Propagation stays inside a mesh network with a common Layer 2. For example, a Low-Power Wireless Personal Area Network (LoWPAN) is defined by an IEEE 802.15.4 Layer 2 mesh made of all connected nodes that share the same Personal Area Network (PAN) ID [RFC4944] 🌸

Mesh network concepts differ between technologies, so this doc maps a general network identifier onto the specific network identifier of existing mesh technologies 💜

Now, in current and projected deployments, there's a requirement to propagate a multicast message beyond the boundaries of the mesh network it started in, no matter what mesh technology is involved 🔥

Let's say you're propagating over two mesh networks. In one example, each mesh network has its own border router, and the two border routers are connected with an Ethernet link. In another example, each mesh network connects to its own network interface on the same border router. In both cases, an Admin-Local multicast message that starts in one network needs to propagate into the other mesh network. The boundary of Admin-Local scope is administratively configured 🙈

This doc describes an "MPL4 router" that forwards MPL messages with an Admin-Local-scope multicast address to all interfaces connected to links that connect to other MPL-enabled interfaces. The MPL4 router enables all of its interfaces for MPL messages, and it allocates an extra variable, MPL_BLOCKED, that either permits or forbids forwarding of MPL messages ✨

Here's how the MPL4 router figures out which links MPL4 messages must be forwarded over. It listens on its interfaces for arriving MPL4 messages. When MPL4 messages arrive over an interface, the router records that interface in the set of interfaces over which incoming MPL4 messages are forwarded. It also regularly sends MPL4 messages over its interfaces to provoke the return of MPL4 messages, which keeps that set of forwarding interfaces up to date 💅

It's expected that the private network of an organization, building, or home connects to the Internet through edge routers provided by an ISP. The intention is that MPL messages with Admin-Local-scope multicast addresses are freely forwarded inside the private network, but edge routers never forward them outside it 🏠

1.1. Requirements Language

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 [RFC2119] 📖

1.2. Terminology and Acronyms

This doc uses terms defined in [RFC7731] and [RFC7346]. On top of those, these terms show up too 🌈

  • MPL4: basically MPL with Admin-Local scope 4.
  • MPL4 message: an MPL Data Message with a destination multicast address of scope 4.
  • MPL4 zone: a convex zone of interconnected interfaces that MPL messages with Admin-Local scope propagate over. An MPL4 zone is bounded by a zone as defined in [RFC4007].
  • MPL4 router: automatically determines the MPL4 zone in which MPL messages with Admin-Local scope can be propagated.

2. Network Identifier 🦋

Links can have a concept of a channel. In wireless networks, for example, a channel is tied to a communication frequency. For some link technologies, several networks can coexist on the same channel, and for those, a network identifier exists. The link technology specification determines the network identifier. When a link has no network identifier, its network identifier has the value "any" 💖

2.1. IEEE 802.15.4

IPv6 over IEEE 802.15.4 is described in [RFC4944]. A LoWPAN is made of the nodes connected by an IEEE 802.15.4 mesh that share the same PAN ID. The PAN ID identifies a network in the IEEE 802.15.4 mesh. Several networks with different PAN IDs can coexist on the same channel [IEEE802.15.4]. The PAN ID of an interface is defined when the interface is enabled. The value of the network identifier of an IEEE 802.15.4 link is the value of the PAN ID 🧚

2.2. IEEE 802.11

IP over IEEE 802.11 is described in [RFC5416]. The Service Set Identifier (SSID) identifies a network in the IEEE 802.11 link. Several networks with different SSIDs can coexist on the same channel [IEEE802.11]. The SSID of an interface is defined when the interface is switched on. The value of the network identifier of an IEEE 802.11 link is the value of the SSID 📶

2.3. ITU-T G.9959

IPv6 over ITU-T G.9959 is specified in [RFC7428]. The HomeID identifies a network of connected nodes [G.9959]. Several HomeIDs can coexist within communication range, but nodes adhering to a network with a given HomeID cannot communicate with nodes adhering to a network with a different HomeID. The value of the network identifier of a G.9959 link is the value of the HomeID 🏡

2.4. BLUETOOTH(R) Low Energy

IPv6 over Bluetooth low energy (BTLE) is specified in [RFC7668]. The medium is specified in [BTLE]. BTLE doesn't know the concept of multiple networks in one channel. The value of the network identifier of a BTLE link is "any" 💙

3. MPL4 Router 👑

The MPL4 router concept exists to automatically determine the MPL4 zone where MPL messages with a scope 4 multicast address can propagate. The MPL4 router periodically runs an algorithm that checks whether MPL Interfaces are present on the links connected to its interfaces. When no MPL Interfaces are present on a given link, the corresponding MPL Interface gets signaled as not being part of the MPL4 zone 🌸

3.1. MPL Interface Parameters

One parameter is associated with every MPL Interface in the MPL4 router, and two parameters are associated with the behavior of the MPL4 router as a whole. Here they are 🎀

  • MPL_BLOCKED: Boolean value that indicates whether or not the associated interface belongs to the MPL4 zone.
  • MPL_CHECK_INT: Integer that indicates the time interval between successive activations of the MPL4 router algorithm, in seconds.
  • MPL_TO: Integer that indicates the interval in which MPL messages are expected to be received, in seconds.

(part 1 of 3, more coming!) 💜

3.2. Determination of MPL4 Zone

Okay bestie, every interface on the MPL4 router MUST be associated with these MPL protocol parameters from [RFC7731] 🎀: PROACTIVE_FORWARDING, DATA_MESSAGE_IMIN, DATA_MESSAGE_IMAX, DATA_MESSAGE_K, and DATA_MESSAGE_TIMER_EXPIRATIONS. When the MPL4 router starts up, every interface gets PROACTIVE_FORWARDING = TRUE and MPL_BLOCKED = false ✨. Also, all interfaces MUST subscribe to the multicast addresses ALL_MPL_FORWARDERS scope 3 and scope 4 💜.

The MPL4 router runs this algorithm for each interface 🦋:

  • With a frequency set by MPL_CHECK_INT, the MPL4 router sends an MPL4 message on each interface. The header includes the MPL Option [RFC7731], and the message goes to multicast address ALL_MPL_FORWARDERS with scope 4.
  • When no MPL message is received within an interval set by MPL_TO, MPL_BLOCKED is set to TRUE.
  • When an MPL4 message is received, MPL_BLOCKED on the receiving interface is set to false.

The result is so clean 😭: for each interface, MPL_BLOCKED is false if and only if MPL-enabled interfaces are connected to the link that the interface is on. When an MPL message is submitted to an MPL-enabled interface called "Interface A" in the MPL router, the Trickle algorithm [RFC6206] kicks in to send it 🚀. The MPL4 message with multicast address ALL_MPL_FORWARDERS scope 4 gets accepted by every interface on the link that has subscribed to ALL_MPL_FORWARDERS with scope 4. When an interface called "Interface B" accepts the MPL4 message, the message gets sent back out over Interface B with Trickle. So Interface A ends up receiving its own message, and after that, MPL_BLOCKED is set to false 💅.

When a new node joins the link, it can send an MPL4 message right away, or it can wait to receive an MPL4 message first and then announce that it wants to be part of the MPL4 zone 🧚.

4. Admin-Local Policy ✨

This section starts by defining which types of multicast messages arriving at an interface are legal 🌸. Then it explains how legal Admin-Local multicast messages get forwarded over other MPL Interfaces 🔥.

The policy for automatically forwarding Admin-Local multicast messages to an MPL Interface depends on two things: the state of the MPL Interface and the multicast message itself 💖. The state of the message comes from whether the MPL Option [RFC7731] is present and what the destination multicast address is. The state of the MPL Interface comes from its subscribed multicast addresses, its zone index [RFC4007], and the values of its PROACTIVE_FORWARDING and MPL_BLOCKED parameters 🎀.

When the zone is undefined or not enabled, all interfaces have the same zone index 🌈.

Multicast messages can be created inside the node by an application, or they can arrive at an interface 💅.

A multicast message created at a source (MPL Seed) is legal when it follows the properties described in Section 9.1 of [RFC7731] ✨.

A multicast message that arrives at a given interface is legal when:

  • The message carries an MPL Option (MPL message), and the incoming MPL Interface is subscribed to the destination multicast address 💜.
  • The message does not carry an MPL Option, and the interface has said it wants to receive messages for that multicast address through Multicast Listener Discovery (MLD) [RFC3810] or IGMP [RFC3376]. The message was also forwarded according to Protocol Independent Multicast - Dense Mode (PIM-DM) [RFC3973] or Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601] 🦋.

Illegal multicast messages get discarded 🗑️💀.

A legal multicast message that arrives at a given interface gets the network identifier of the interface's incoming link 🌸. A message created inside the node gets the network identifier "any" ✨.

Section 4.1 considers two types of legal multicast messages: (1) MPL messages and (2) multicast messages that don't carry the MPL Option 🫶.

4.2.1. MPL Message

MPL messages get forwarded on MPL Interfaces using the Trickle parameter values assigned to each MPL Interface, following these rules 🔥:

  • Link-Local (scope 2) MPL messages are not forwarded 🙈.
  • Realm-Local (scope 3) MPL messages are forwarded on all MPL Interfaces where all of the following are true:
    • The multicast address that the MPL Interface subscribes to is the same as the multicast address of the MPL message.
    • The zone index of the MPL Interface is the same as the zone index of the MPL Interface where the MPL message was received.
    • The MPL Interface has PROACTIVE_FORWARDING set to TRUE.
    • The assigned network identifier of the MPL message is "any", or it equals the network identifier of the MPL Interface 🌈.
  • Admin-Local (scope 4) MPL messages are forwarded on all MPL Interfaces that subscribe to the same multicast address, have the same zone index, have PROACTIVE_FORWARDING set to TRUE, and have MPL_BLOCKED set to false 👑.
  • MPL messages that encapsulate a message with a multicast scope of 5 or higher get decapsulated and forwarded over the interface when the interface is subscribed to the multicast address of the decapsulated message 🧚.

4.2.2. Multicast Messages without MPL Option

Multicast messages without the MPL Option get forwarded on MPL Interfaces following these rules 💖:

  • Link-Local (scope 2), Realm-Local (scope 3), and Admin-Local (scope 4) multicast messages are not forwarded 💀.
  • Multicast messages with a multicast scope of 5 or higher get encapsulated in an MPL message with destination address ALL_MPL_FORWARDERS with scope 4. The resulting message is then handled as described in Section 4.2.1 ✨.

4.3. Encryption Rules

An incoming message protected at Layer 2 MUST then be re-protected at Layer 2 on all outgoing interfaces 🔐. Incoming messages get integrity checked and optionally decrypted at the incoming interface at Layer 2, using the keys and protection algorithm that fit that interface's network. Then they get re-protected at the outgoing interface, using the keys and protection algorithm that fit the outgoing interface's network 🫧. It may be necessary to compare the protection levels on the respective interfaces and apply policy rules. For example, you'd want to avoid downgrading security when one network has a lower level of security than another 😤.

An incoming MPL4 message that is not protected at Layer 2 MUST NOT be re-protected at Layer 2 on any outgoing interface 🙅‍♀️.

5. MPL Domains and Zones

An MPL Domain is a scope zone where MPL Interfaces subscribe to the same MPL Domain Address [RFC7731] 🗺️. Following [RFC4007], a zone boundary passes through a node 🧱. For example, a small Low-Power and Lossy Network (LLN) node usually has one MPL mesh interface that subscribes to the ALL_MPL_FORWARDERS multicast address with a scope value of 3 (Realm-Local) [RFC7346]. That node interface belongs to the zone, and the zone boundary does not pass through this node 🌸. On a border router where MPL Interfaces subscribe to the multicast address ALL_MPL_FORWARDERS with scope value 3, the zone usually includes this one interface and leaves out all the others 💅. There's a notable exception: a node where MPL Interfaces of the same technology share the same network identifier. Those interfaces belong to the same MPL4 zone when they share the same zone index 🫶.

In an MPL4 router, every MPL Interface subscribes to the Admin-Local ALL_MPL_FORWARDERS multicast address, as well as the Realm-Local ALL_MPL_FORWARDERS address 💜.

Every interface that belongs to an MPL Domain extending over border routers MUST be subscribed to the Admin-Local ALL_MPL_FORWARDERS address 👑.

The MPL4 zone that goes with the MPL multicast address ALL_MPL_FORWARDERS with scope 4 (Admin-Local) applies to border routers with multiple interfaces. At least one of those interfaces has to be MPL enabled and subscribed to the multicast address ALL_MPL_FORWARDERS with scope 4 🔥. On a border router, all MPL-enabled interfaces that subscribe to the ALL_MPL_FORWARDERS address with scope 4 and have MPL_BLOCKED set to false belong to the same MPL4 zone, as long as they share the same zone index 🌈.

MPL4 messages stay bounded within a zone, as defined in [RFC4007] 🧱. That means MPL4 messages cannot be routed between interfaces that belong to different zones 🚫. When the concept of zone is unknown or disabled in a router, all interfaces belong to the same zone 🌸. For example, take a router with five interfaces, where Interfaces A and B belong to zone 1, and Interfaces C, D, and E belong to zone 2. MPL4 messages can be routed freely between Interfaces A and B, and freely between Interfaces C, D, and E 🦋. However, an MPL4 message MUST NOT be routed from Interface A to Interface D 🙅‍♀️.

6. Default Parameter Values

This document creates three parameters, and their values are related to the Trickle timer intervals ⏱️.

  • MPL_TO = DATA_MESSAGE_IMAX times 2, which leaves enough time to receive the second response message 🎀.
  • MPL_CHECK_INT = 5 minutes, which means a reaction to a network malfunction happens within 5 minutes 🍓.
  • MPL_BLOCKED = TRUE, which means the interface has not received MPL-enabled messages that would include it in the MPL4 zone 🫧.

7. Security Considerations 🔐✨

Okay bestie, the security considerations of [RFC7731] also apply to MPL4 routers 💅. Everything from that RFC comes along for the ride 🫶.

Sending MPL4 messages from a malicious node can have unwanted consequences 😭. Picture this: it's super common for a wired link, like Ethernet, to connect two floors or sections of an LLN, because radio signals through reinforced concrete are generally poor 🧱. So the MPL4 zone can wrap around multiple routers, meshes, and links 🌐. A malicious node could plug into a wired link where no MPL-enabled nodes are expected 👀. Then it can send MPL4 messages to the MPL4 router interfaces. If nothing is done, the MPL4 routers will happily pass MPL4 messages from one mesh over the wired link to the next mesh, even though that wired link was never meant to carry MPL4 messages at all 💀.

To understand the consequences of this unwanted behavior, we need to tell apart these cases:

  • The source mesh uses Layer 2 encryption.
  • The MPL4 router can be managed.

The four possible combinations are discussed below 🦋:

Layer 2 unsecured, router unmanaged: MPL4 messages are freely distributed across meshes and links that are interconnected by MPL4 routers within a zone 🌊. MPL-enabled malicious nodes can read all MPL4 messages and distribute MPL4 messages over a network limited by a zone. This can be acceptable for an isolated network within a clearly defined space, where the connection of nodes is tightly controlled 🔒. A completely wired LLN, such as the ones seen in BACnet (a protocol for building automation and control networks) [BACnet], is an example of an unencrypted LLN that would be considered physically secure 🏢.

Layer 2 secured, router unmanaged: MPL4 messages are freely distributed across meshes and links that are interconnected by MPL4 routers within a zone 🌊. Following the rules of Section 4.3, MPL4-enabled malicious nodes cannot read the MPL4 messages, and MPL4 messages sent by the malicious node are not accepted by other nodes 🙅‍♀️. This is acceptable for a home network or a managed network extending over precisely one zone, occupying a clearly defined physical space, where ease of installation matters 🏡. In such a network, the presence of the malicious node is no different from any other malicious node that tries to send messages over Layer 2 protected links. Because the network occupies exactly one zone, the MPL4 message distribution cannot be extended outside the network 🧱✨.

Layer 2 unsecured, router managed: The distribution of MPL4 messages over MPL4 router interfaces can be limited to the interfaces for which a manager has enabled MPL, as well as a set of multicast addresses 🎯. The malicious node cannot extend the distribution of MPL4 messages over unwanted interfaces 🙌. It is important that the handling of the interfaces by the manager is protected 🛡️. However, MPL4 messages sent over the mesh can be interpreted by malicious nodes, and malicious messages can be injected into the set of meshes and links connected by the MPL4 routers for which the manager enabled the interfaces 😱. This can be practical for interconnected links and meshes that are connected to a LAN over a limited period, for example during installation of the interconnected meshes and links 🛠️.

Layer 2 secured, router managed: The distribution of MPL4 messages over MPL4 router interfaces can be limited to the interfaces for which a manager has enabled MPL, as well as a set of multicast addresses 🎯. Following the rules of Section 4.3, the malicious node cannot extend the distribution of MPL4 messages over unwanted interfaces, and MPL4 messages sent by the malicious node are not accepted by other nodes 🙅‍♀️. It is important that the handling of the interfaces by the manager is protected 🛡️. The MPL-enabled (malicious) nodes cannot read the MPL4 messages, and MPL4 messages sent by the malicious node are not accepted by other nodes 🔐. Depending on the number of managed interfaces, the network can progressively go from autoconfigured to fully administratively controlled 👑✨.

8. References 📚

8.1. Normative References

8.2. Informative References

Acknowledgements 🫶

This document reflects discussions and remarks from several individuals, including (in alphabetical order) Scott Bradner, Esko Dijk, Adrian Farrel, Matthew Gillmore, Joel Halpern, Steve Hanna, Michael Richardson, and Pascal Thubert 💜.

Authors' Addresses 🖋️

Peter van der Stok Consultant

Email: consultancy@vanderstok.org

Robert Cragie ARM Ltd. 110 Fulbourn Road Cambridge CB1 9NJ United Kingdom

Email: robert.cragie@arm.com 🌸

📦 where this page comes from