Bluetooth Mesh GATT Proxy Best Practices#

The GATT Proxy feature in Bluetooth Mesh is useful in allowing devices such as mobile phones access a Bluetooth Mesh network. Careless use of the feature may, however, adversely affect the performance of the network. This document describes best practices that can be used to configure GATT proxying in a way that does not burden the network. It also highlights some best practices related to security and privacy.

Consider the Effect of Proxy Service Advertisement on the Network#

GATT Proxy servers announce their availability to act as proxies by advertising the GATT Proxy service using connectable advertisements.

These advertisements occupy the same three advertisement channels that are used by Mesh data traffic, so care should be taken to not advertise too often. This is especially the case when there are multiple GATT Proxy servers in the radio range of each other. For example, ten GATT Proxy servers near each other, each advertising with a 100ms interval, produce 100 service advertisements each second in the area where their radio ranges overlap.

There are three ways to limit the number of GATT Proxy service advertisements:

The BGAPI call sl_btmesh_node_set_proxy_service_adv_interval can be used to set the advertisement timing locally on a node.
The Configuration Manager of the network can remotely toggle GATT Proxy service on or off on a node by using the BGAPI call sl_btmesh_config_client_set_gatt_proxy.
The On-demand Private Proxy Server can be used instead of the regular GATT Proxy server. The on-demand server only starts service advertising when it receives a Proxy Solicitation Request from a node. A solicitation request can be sent using sl_btmesh_proxy_send_solicitation BGAPI command.

Filter the Proxied Traffic#

Only the traffic that the proxy client needs from the network should be passed across the proxy connection. Even if the connection between the proxy client and the proxy server has more bandwidth than the advertisement-based Mesh bearer, a slow connection interval may result in a queue of PDUs building up on the proxy server side. Furthermore, the proxy server likely has other duties than just proxying, so it should not be burdened with proxying unneeded data to the client.

Proxy filtering controls what PDUs are passed over the proxy connection. It can be configured with the following BGAPI commands:

sl_btmesh_proxy_set_filter_type sets the type of filtering (an accept list or a reject list). An accept list is appropriate when the filtering should be done with a small number of addresses to allow traffic from, and to reject anything else; a reject list is appropriate when the filtering should be done with a small number of addresses to reject traffic from, and to allow anything else.
sl_btmesh_proxy_allow allow traffic from the given address. In the case of an accept list, the command adds the address to the list; in the case of a reject list, the command removes the address from the list.
sl_btmesh_proxy_deny block traffic from the given address. In the case of an accept list, the command removes the address from the list; in the case of a reject list, the command adds the address to the list.
sl_btmesh_proxy_optimisation_toggle provides an option to automatically allow unicast PDUs so that only those PDUs whose destination is the proxy client are passed over, regardless of the filter list contents.

Consider Proxy Privacy#

The regular GATT Proxy Server advertises the proxy service in a manner that can be tracked, due to both the Bluetooth address and the service data in the service advertisements containing unchanging information. A passive observer may keep track of the addresses and service data it sees, and deduce that it is seeing the same device again if the information remains constant. While this is maybe not an issue for stationary networks, such as lighting networks, that are bound to a fixed location, trackability of devices may be an issue in some contexts.

Private proxy service advertisements resolve this issue by use of private Bluetooth addresses that change from time to time, and by use of service data that changes from time to time. This means that passive tracking is only possible for the short period before the advertised address and data changes.

Proxy privacy can be remotely controlled on a proxy server by sl_btmesh_private_beacon_client_set_gatt_proxy and sl_btmesh_private_beacon_client_set_identity BGAPI calls available in the Private Beacon Client. The Private Beacon Server must be enabled on the proxy server node.

Proxy privacy can be combined with On-demand Private Proxy Server described in the following section.

Limit Proxy Visibility#

By its nature, a proxy server needs to allow LE connections from proxy clients, and it needs to advertise its presence and availability for connections using service advertisements so that clients know where to connect to.

This mechanism makes the presence of a proxy server visible to everyone, not just the legitimate proxy clients. Someone wanting to create nuisance can connect to a proxy (repeatedly, if the connection closes after a timeout) and keep the proxy server occupied so that it is not available to the legitimate users.

Outside of physical security, the best way to counter such troublemakers is to use the On-demand Private Proxy Server instead of the regular GATT Proxy server. The on-demand server only starts service advertising when it receives a Proxy Solicitation Request from a node, so it is not visible to anyone until that happens. A solicitation request can be sent using sl_btmesh_proxy_send_solicitation BGAPI command.

Solicitation requests are encrypted and can only be sent by nodes that know the network key. Furthermore, solicitation replay protection blocks attempts to record and later replay legitimate solicitation requests. These measures are put in place to help ensure that only nodes that are a part of the network can make proxy solicitation requests.