Bluetooth® Mesh Subnet Bridging
|Document Version :
|Last updated :
|September 19, 2023
Martin Woolley, Bluetooth SIG
September 19, 2023
Martin Woolley, Bluetooth SIG
The Bluetooth Mesh Profile Specification has been renamed and is now called the Bluetooth Mesh Protocol Specification. References in this and related papers will use this name when referring to the version 1.1 specification but continue to refer to the version 1.0 specification as the Bluetooth Mesh Profile Specification.
Subnet bridging was introduced in version 1.1 of the Bluetooth® Mesh protocol specification. To fully appreciate the capabilities and benefits of Bluetooth Mesh Subnet Bridging, it is necessary to understand certain aspects of Bluetooth Mesh version 1.0. This section provides context and background which will support the examination of the Bluetooth Mesh Subnet Bridging feature.
A Bluetooth® Mesh network constitutes the address space of all unicast addresses. A Bluetooth Mesh network may consist of one or more subnets sharing this common address space. Each subnet has a unique network key (NetKey), and if a node is provided with this NetKey when it is provisioned, then it is a member of that subnet.
A node can possess more than one NetKey and therefore be a member of more than one subnet, but at version 1.0 of the Bluetooth Mesh profile specification, there was no way in which messages can pass from one subnet to another. Subnets were completely isolated from each other.
The ability to isolate one part of a network from another by dividing the network into several different subnets offers a number of benefits.
Preventing devices in one subnet from being able to interact with devices in other subnets can be useful or perhaps even essential, for security reasons. Consider hotel rooms, where the smart devices in a room may communicate with other devices in the same room but not outside of it. Placing the devices in each hotel room in their own subnet isolates the devices in each room from those in other rooms and meets the hotel’s guest room security requirements.
Figure 1 – Hotel rooms and subnet area isolation
Subnets can also be used to contain network traffic to one area of a building. This can be particularly useful when relaying is required for messages to reach all intended destination nodes and Bluetooth Mesh Managed Flooding is in use. Subnets can be thought of as placing a boundary around groups of devices, such that messages cannot cross those boundaries even when being relayed, so that relaying irrelevant messages to parts of the network where none of the target devices reside is avoided.
This technique is commonly used to isolate one floor from another in offices, and this is shown in Figure 2. A message sent by the light switch on the third floor will be relayed by the relay nodes in the ceiling of that floor because they are part of the same subnet, but the relays on the floors above and below, which may receive the transmission from the switch will discard it immediately, and so the message will not propagate across floors.
Figure 2 – Subnets in an office
A malicious device could passively receive a message and retransmit it at a later time, perhaps causing an unauthorized change in the network. Such an attack is called a replay attack. Bluetooth® Mesh defines a replay protection mechanism which prevents replay attacks.
Replay protection involves all messages having an associated nonce value which includes a 24-bit sequence number (SEQ) which must be incremented by a source node for each new message it sends. If a node was to send a message once every five seconds, the SEQ value would take over two years before needing to wrap around. However, to prevent this from occurring, the SEQ value is extended by a 32-bit Initialization Vector (IV) value which is shared across the whole network. The IV gets automatically updated through a procedure called the IV Update procedure whenever there is a risk that SEQ values will be exhausted.
The 32-bit IV values themselves are not included in messages. Instead, a single bit field called IVI indicates which of two possible IV values that a network may be using at a time relate to the message.
Receiving devices keep track of the IV and SEQ values of last successfully processed message from each source address. If a message is received which does not have a numerically higher IV and SEQ value combination than the last message received from the same source unicast address, it is discarded as a probable replay attack.
Subnets, as defined in version 1.0 of the Bluetooth Mesh profile specification, provide some excellent security and network utilization efficiency benefits. But there are some requirements which are difficult to meet due to the absolute nature of the area isolation which subnets impose. And where subnets are to be used to limit the travel of messages to unrelated parts of the network for utilization efficiency reasons, network planners must think carefully about how to use them. Installers must set up the required subnets when the network is first created.
Bluetooth Mesh Directed Forwarding (see the Bluetooth Mesh Directed Forwarding Technical Overview paper) offers a superior approach to constraining the flow of traffic between nodes to those parts of the network that are relevant. Subnets can sometimes achieve similar results, but subnet area isolation cannot be used in as precisely targeted a way as Bluetooth Mesh Directed Forwarding can be, in terms of limiting only selected devices to the handling of messages. Bluetooth Mesh Directed Forwarding is now recommended as the way to address network utilization efficiency requirements.
Area isolation using subnets as a network security mechanism is a powerful capability. But imagine a hotel has used subnet area isolation for each of its rooms. Guests are delighted that their technologically smart hotel rooms allow manual and automated control of its devices and systems. The hotel management is satisfied that devices in one room cannot be used to interfere with devices in other rooms. But the hotel management would like to install a gateway to which sensors in each hotel room can report occupancy data, feeding a TCP/IP based GUI system which allows unobtrusive scheduling of room cleaning and laundry services. This cannot be accomplished without having a gateway node in every hotel room when Bluetooth® Mesh 1.0 subnets are in use.
Sometimes there are use cases where communication between devices in different subnets is required but without compromising the area isolation that the subnet provides. The Bluetooth Mesh Subnet Bridging capability makes this possible.
The Bluetooth Mesh Subnet Bridging feature allows networks to use subnets for area isolation but to also selectively allow communication between specific devices in different, adjacent subnets.
Network planners must decide which nodes in the network are to act as Subnet bridges, allowing controlled communication between certain nodes in two adjacent subnets. The presence of the Bridge Configuration Server model indicates that Bluetooth Mesh Subnet Bridging is supported by a node.
To make a node a Subnet bridge, a state called Subnet bridge must have its value set to enabled. A further state called the Bridging Table must then be populated with entries that configure the Bluetooth Mesh Subnet Bridging functionality of the node.
The Bridging Table is a state which contains entries defining source and destination addresses for which Bluetooth Mesh Subnet Bridging will be performed. An entry defines bridging to be available from one address to the other in one direction only or in both directions. In either case, the index values for the network keys of each of the two subnets is also included in each bridging table entry. Section 4.2.42 of the Bluetooth® Mesh protocol specification provides the full format of a bridging table entry and is repeated here in Figure 3.
Allowed directions for the bridged traffic
NetKey index of the first subnet
NetKey index of the second subnet
Address of the node in the first subnet
Address of the node in the second subnet
Figure 3 – The bridging table state entry format
The Directions field takes a value of 0x01 or 0x02.
0x01 means that only one direction of bridging is allowed, for messages which have a source address (SRC) equal to the Address1 bridging table entry and a destination address (DST) equal to Address2, allowing messages to be forwarded from the first subnet to the second.
0x02 means that bridging may be performed in either direction, including therefore from the second subnet to the first, for messages which have a source address (SRC) equal to Address2 and a destination address (DST) equal to Address1.
Subnets make it possible to isolate different parts of the network from each other, and this has a security benefit in some scenarios, preventing nodes in one subnet from communicating with nodes in another.
Bluetooth Mesh Subnet Bridging allows communication across subnets. But the bridging table ensures that this can only occur between specific source and destination address pairs and specific pairs of subnets. For example, in a hotel, a guest might be able to signal to the housekeeping team that they want their room cleaned by pressing a button that sends a message from the subnet their room belongs to across the hotel, using Bluetooth Mesh Subnet Bridging and Bluetooth Mesh Directed Forwarding, to the housekeeping team. But the other devices in the guest’s room will not be able to communicate with any other nodes outside of that subnet. Bluetooth Mesh Subnet Bridging allows selective and controlled communication across subnets but otherwise retains the security benefits afforded by area isolation.
Subnet bridges perform replay protection in the same way that destination nodes do, tracking IV and SEQ values against the source address in messages handled by the Subnet bridge. If the IV and SEQ value combination is not numerically higher than the last received for bridging from a particular source address, it is discarded. In this way, Subnet bridges perform replay protection before destination nodes in the next subnet by protecting the next subnet from denial-of-service attacks.
Bluetooth Mesh Subnet Bridging is performed at the network layer within Subnet bridge nodes. On receiving a message, the bridging table will be checked for an entry whose Address1 and Address2 fields match the source address and destination address of the message or for an entry for which Address2 contains the message SRC address and Address1 contains the message DST address and where the Directions field indicates bi-directional bridging to be supported. A further check is made to verify that the message network PDU was encrypted with the NetKey for the source subnet. If these conditions are met, the message is decrypted using the source subnet NetKey, re-encrypted with the destination subnet NetKey, and then retransmitted. A message can be retransmitted more than once and travel throughout multiple subnets if the appropriate configuration of Subnet bridge nodes is prepared.
A message whose source and destination address are not in the bridging table in either of the possible unidirectional or bidirectional bridging entry formats will not be retransmitted to other subnets. Relaying or Bluetooth Mesh Directed Forwarding may still cause the message to be retransmitted within the current subnet if appropriate.
Bluetooth Mesh Directed Forwarding (see the Bluetooth Mesh Directed Forwarding Technical Overview Paper) can be used with Bluetooth Mesh Subnet Bridging and involves two node dependency relationships.
The first dependency exists between the source node in the first subnet and the Subnet bridge as a member of the second subnet. The second exists between the Subnet bridge as a member of the first subnet and the destination node in the second subnet.
Subnet bridges act as supporting nodes in both node dependency relationships and will perform path discovery and maintenance procedures as well as message forwarding on behalf of its dependent nodes.
Bluetooth Mesh Subnet Bridging makes the use of subnets where cross-subnet is required much more flexible and easier to set up without compromising security.