subsys: bluetooth: host: Method for application to know if address will be resolved

[koffes]

Summary

In some application scenarios, and for some profiles/services (ref. @Thalley), it is required/beneficial to know if the address of a peer device will change or not.
That is, one may want to defer some operation until the address has been resolved in case of an RPA being used.

After discussions with @alwa-nordic, @Thalley and more, it seems there is no definitive way for an application to know for sure if the address will be resolved or not using public APIs.

As an example, we want to know in the security_changed callback:

zephyr/include/zephyr/bluetooth/conn.h

Line 1843 in 27fa721

struct bt_conn_cb {

if we will later get a identity_resolved callback.

Describe the solution you'd like

Ideally, we would like another callback on some form addr_operations_done(struct bt_conn *conn, const bt_addr_le_t *identity, bt_security_t level) or similar.
This will then be called after security_changed and (if applicable) after identity_resolved , letting the application know that this address will not change for the lifetime of this connection. This could then be because either the RPA has been resolved or the device uses a public device address which does not get resolved.

Alternatives

No response

Additional Context

No response

[Thalley]

To elaborate with a use case when privacy is enabled:
We want to connect a bond with a remote device, and store some information about that device after disconnection. This could for example be whether a GATT service characteristic has changed while disconnected, in which case many GATT services are required to notify the remote device about the change when reconnected. The only way to determine if a device is the same, is the compare the identity address. It is, however, not possible for the application to reliably know when the identity address is available.

Case 1: Connecting to a remote unbonded device for the first time

In this case, the remote device may use any type of address (including an NRPA). The address reported from the controller will always be the on-air address. During pairing, the identity address and IRK may be distributed (if not, then we cannot store anything information about the remote device after disconnect), even if the remote device uses a public or static random address.

Case 1A: Remote using a static address

If the remote is connecting to use with a public or static random address (remote not using privacy), we could store that information as the address, and use that for future comparison. This case is OK.

Case 1B: Remote using an RPA

If the remote is using an RPA and the identity information is distributed, then the identity_resolved callback will be called. If that is the case, then when we reach the pairing_complete callback, we know that bt_conn_get_dst will contain the identity address, and we can use that for future comparison, however this is not documented, and attempting to use e.g. bt_conn_get_dst during the connected or teh security_changed callbacks won't work. This case is kind of OK (need additional documentation).

Case 1C: Remote using an NRPA and distributes identity information

If the remote is using an NRPA then even if the identity information is distributed, then the identity_resolved callback will not be be called. If that is the case, then when we reach the pairing_complete callback, we will see the address type of BT_ADDR_LE_RANDOM, but do not have any immediate way of getting the identity address in the application. Additionally, to known whether this is an NRPA or a random static address, the application can/should use BT_ADDR_IS_STATIC to determine if this is a static random address or not, and if it is not, then it cannot store any address for future comparison. This case is not OK.

Case 1D: Remote using an NRPA and does not distribute identity information

If the remote is using an NRPA without distributing the identity information, then we cannot/should not store any information (arguably, we should disallow bonding with such devices), as we cannot rely on the same address being used in the future for comparison. However, the application is unaware of whether the identity information is distributed. This case is not OK.

Overall, Case 1 has issues with identity_resolved not being completely reliable (not called every time we do have the identity address). Implementing handling of storing the address for future comparison needs to be done in the pairing_complete callback, but will only work if the remote is not using an NRPA.

Case 2: Subsequent connections with controller privacy enabled

In the case that the remote device used an NRPA for the first connection, then we cannot perform any direct comparisons with the addresses coming the HCI events. For all other cases it is possible, if not just slightly complex to determine when/if an address can be stored.

From an applications perspective, it would be nice to have a generic callback that basically tells the application: "At this point you can identity the remote device using this address" (which should be the same address that we use for storing the LTKs). This does imply that bonding with devices with NRPAs without identity address being distributed, is not possible.

[PavelVPV]

I am probably missing something, but. The address resolution (if the address will ever be resolved) will happen right before the identity_resolved callback is called. The callback will always be called before the pairing_complete callback (if pairing completes (of course). After this, the identity_resolved callback will never be called.

There is a pairing_accept callback. If enabled, it will among the other things tell if the remote peer will exchange IRK and Peer Identity Address through resp_key_disp field. There is no public API to extract information from this field unfortunately, but the content of this field is defined in spec Ver 6.0, Vol 3, Part H, section 3.6.1, figure 3.11:

If IdKey filed is set to 1, the peer will send Identity Information and identity address information commands that are used to resolve the peer address.

Later, e.g. after reboot, the application can iterate over each bond devices using bt_foreach_bond and use bt_addr_le_is_identity to find all bonded peers whose address was resolved.

I could of course miss many corner cases here.

[Thalley]

@PavelVPV I'll refer to Case 1C here: It's possible to establish the connection using an NRPA and distribute the identity information, but the application is unable to get the identity address in this case. We update the conn->le.dst for RPAs, but not NRPAs: https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/host/smp.c#L4199-L4223

So until we reconnect, the application is only exposed to the NRPA, and if we reconnect, the application is unable to couple the NRPA that it knew from the first connection to the resolved address in the second connection. The application need the identity address, if any, once pairing has completed, which we are missing today.

To fix this, we either need to copy the identity address received in all cases (not sure if it's allowed/makes sense to share an identity address if using a static random address?) to conn->le.dst, or add another field to conn->le that contains the identity address received. An interesting corner case here is if we pair with a remote device and we get identity_addr_a, but then we repair (for any reason) and the next time the remote device gives up identity_addr_b.

[PavelVPV]

So until we reconnect, the application is only exposed to the NRPA, and if we reconnect, the application is unable to couple the NRPA that it knew from the first connection to the resolved address in the second connection. The application need the identity address, if any, once pairing has completed, which we are missing today.

I see. Host could probably trigger the identity_resolved callback in this case as well and update le.dst field, but I don't know what part of spec the behavior can brake.

Do you in application need to treat the peer with NRPA (the one you paired with) and the peer with the resolved address (after you reconnect) as the same device? Same for the corner case you mentioned with identity_addr_a and identity_addr_b. Why should application think that this is the same device?

[Thalley]

Do you in application need to treat the peer with NRPA (the one you paired with) and the peer with the resolved address (after you reconnect) as the same device? Same for the corner case you mentioned with identity_addr_a and identity_addr_b. Why should application think that this is the same device?

Yes. If A device_0 connects with NRPA_0 and distributes ID_ADDR_0, then we need to store ID_ADDR_0 so that when device_0 may connect later with RPA_0 (resolvable to ID_ADDR_0), we know that it is the same device. Not sure if a device may connect to use with a static random address, and distribute ID_ADDR_0, and then later connect to use with RPA resolveable to ID_ADDR_0 as well, so maybe we should just always replace conn->le.dst with the identity address?

Semantically, identity_resolved is somewhat oddly name if we use that to replace the NRPA with the identity address, but it is effectively what happens :)

[PavelVPV]

Yes. If A device_0 connects with NRPA_0 and distributes ID_ADDR_0, then we need to store ID_ADDR_0 so that when device_0 may connect later with RPA_0 (resolvable to ID_ADDR_0), we know that it is the same device. Not sure if a device may connect to use with a static random address, and distribute ID_ADDR_0, and then later connect to use with RPA resolveable to ID_ADDR_0 as well, so maybe we should just always replace conn->le.dst with the identity address?

I just don't understand how this can happen because spec says:

The privacy-enabled Peripheral shall use a resolvable private address as the
advertiser's device address when in connectable mode

The privacy-enabled Central shall use a resolvable private address as the initiator's
device address

Peripheral can advertise with NRPA, but should use RPA when wants to connect:

A Peripheral shall use non-resolvable or resolvable private addresses when in non-
connectable mode as defined in Section 9.3.2

What am I missing from spec perspective?

[Thalley]

What am I missing from spec perspective?

Thanks - Was not aware of the 2 above. So a connection cannot be established with an NRPA? In that case, then cases 1C and 1D are non-existing, in which case we either have a public device address, a static random address or a resolved identity address when we reach the pairing_complete callback, assuming that we always get the identity address when remote is using an RPA (and if not, then we need to treat it as an NRPA, in which case 1D is still valid).

Might be missing some implicit check, but can't find any checks in Zephyr that prevents BT_LE_ADV_OPT_USE_NRPA and BT_LE_ADV_OPT_CONN to be set at the same time.
Not too familiar with the PAWR feature, but I guess similar restrictions apply there?

@koffes @alexsven correct me if I'm wrong, but didn't you experience a device at the recent UPF connecting with an NRPA as well?

[PavelVPV]

So a connection cannot be established with an NRPA?

It can and Private Proxy feature in Bluetooth Mesh does so:

zephyr/subsys/bluetooth/mesh/proxy_srv.c

Lines 45 to 46 in d494f86

	#define ADV_OPT_ADDR(private) (IS_ENABLED(CONFIG_BT_MESH_DEBUG_USE_ID_ADDR) ? \
	BT_LE_ADV_OPT_USE_IDENTITY : (private) ? BT_LE_ADV_OPT_USE_NRPA : 0)

zephyr/subsys/bluetooth/mesh/proxy_srv.c

Lines 48 to 49 in d494f86

	#define ADV_OPT_PROXY(private) \
	(BT_LE_ADV_OPT_CONN | BT_LE_ADV_OPT_SCANNABLE | ADV_OPT_ADDR(private))

But this is not privacy-enabled device then. It shall not exchange the identity information. There could still be some loopholes in the spec that I'm missing.

[PavelVPV]

But this is not privacy-enabled device then. It shall not exchange the identity information.

And Zephyr Bluetooth Host does not send identity info if the CONFIG_BT_PRIVACY Kconfig option, which enables its own privacy, is disabled:

zephyr/subsys/bluetooth/host/smp.c

Lines 62 to 66 in d494f86

	#if defined(CONFIG_BT_PRIVACY)
	#define ID_DIST BT_SMP_DIST_ID_KEY
	#else
	#define ID_DIST 0
	#endif

zephyr/subsys/bluetooth/host/Kconfig

Lines 469 to 473 in d494f86

	config BT_PRIVACY
	bool "Device privacy"
	help
	Enable privacy for the local device. This makes the device use Resolvable
	Private Addresses (RPAs) by default.

(though it does not mean it is correct)