Subject: Re: [6lo] IIDs and IPv6 over Bluetooth LE

From: <[email-masked]>
Date: Fri, 1 Aug 2014 10:44:11 +0000

>> I'm thinking whether we should actually mandate an IPv6 link-local 
>> address for Bluetooth LE link to be generated based on the Bluetooth 
>> LE device address - which is guaranteed to be locally unique in the 
>> established Bluetooth LE piconet. It's worth noting that the
>Is the device address guaranteed to be unique due to L-2 negotiation?
>If so, I could see where that would allow us to bypass DAD.

I thought so, but I found it isn't so... There's very small change of collision.. I'm thinking how to solve that as I'd really want to avoid DAD for Link-Local addresses.

Best regards,

	Teemu

---

From: <[email-masked]>
Date: Wed, 6 Aug 2014 07:34:22 +0000

Brian, All,

There's been discussion about this topic in BT SIG and there's a thought how to go forward. Please let me know how does it sound for you.

Firstly, the IPSP works so that a 6LN (Node) that wishes to obtain IPv6 connectivity will start advertising it's need. The router (6LBR, center of the star) receives these advertisements and then establishes Bluetooth connection to said node.

Now, as was said, if the Bluetooth node is using random address, it in rare cases may be in conflict with other nearby nodes, as there's no duplicate device address detection procedure in play.

The proposed solution on the table is the following: the router (6LBR) SHALL NOT establish more than one Bluetooth connection for each Bluetooth address it sees in use. Hence, after the 6LBR has established a Bluetooth connection to a node with an address, it will not establish connection to another node that happens to advertise IPv6 support with the same address.  Furthermore, the node MUST generate its IPv6 Link-Local address based on the device address used for establishing Bluetooth connection with the router.

This means that:
-> In the case of conflict only one device of those with conflicting address gets to join the 6LBR. Other nodes with conflicting address will be left stranded, until the moment they change their random device address (action that some perform at every boot, some perform periodically, if I understood it right).

-> IPv6 Link-Local address for a node is generated from the Bluetooth address used for the Bluetooth connection (and for the duration of the connection, in case the address is random and changing). Hence the router will know what will be, and is, the link-local address of the node it is about to connect. 

-> As router ensures every Bluetooth node it serves is using different Bluetooth address, the 1:1 generated IPv6 Link-Local addresses must then be locally unique.

With the above, do you agree that we can optimize away joining to solicited-node multicast address and avoid performing DAD for the link-local address?

When it comes to privacy, the link-local address privacy will go 1:1 with the Bluetooth device address privacy = if Bluetooth node uses IEEE 802 address at Bluetooth level, the corresponding link-local address will be IEEE 802-based. If Bluetooth node uses random device address, the corresponding link-local address will be random as well.

If this approach is acceptable, we'll update the internet-draft accordingly.

Best regards,

	Teemu

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: 1. elokuuta 2014 13:44
To: [email-masked]; [email-masked]
Subject: Re: [6lo] IIDs and IPv6 over Bluetooth LE

Best regards,

	Teemu

_______________________________________________
6lo mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lo

---

From: Brian Haberman <[email-masked]>
Date: Fri, 08 Aug 2014 09:47:11 -0400

Hi Teemu,

On 8/6/14 3:34 AM, [email-masked] wrote:
> Brian, All,
> 
> There's been discussion about this topic in BT SIG and there's a
> thought how to go forward. Please let me know how does it sound for
> you.
> 
> Firstly, the IPSP works so that a 6LN (Node) that wishes to obtain
> IPv6 connectivity will start advertising it's need. The router (6LBR,
> center of the star) receives these advertisements and then
> establishes Bluetooth connection to said node.
> 
> Now, as was said, if the Bluetooth node is using random address, it
> in rare cases may be in conflict with other nearby nodes, as there's
> no duplicate device address detection procedure in play.
> 
> The proposed solution on the table is the following: the router
> (6LBR) SHALL NOT establish more than one Bluetooth connection for
> each Bluetooth address it sees in use. Hence, after the 6LBR has
> established a Bluetooth connection to a node with an address, it will
> not establish connection to another node that happens to advertise
> IPv6 support with the same address.  Furthermore, the node MUST
> generate its IPv6 Link-Local address based on the device address used
> for establishing Bluetooth connection with the router.
> 
> This means that: -> In the case of conflict only one device of those
> with conflicting address gets to join the 6LBR. Other nodes with
> conflicting address will be left stranded, until the moment they
> change their random device address (action that some perform at every
> boot, some perform periodically, if I understood it right).

In essence, DAD is performed at the BT level.

> 
> -> IPv6 Link-Local address for a node is generated from the Bluetooth
> address used for the Bluetooth connection (and for the duration of
> the connection, in case the address is random and changing). Hence
> the router will know what will be, and is, the link-local address of
> the node it is about to connect.

It also means that a new BT association (and corresponding IPv6 LL
address) will be needed each time a device changes its BT address.  If
that occurs at random rather than at start up time, a device could lose
connectivity in the middle of application flows.  That is, unless BT
won't allow a new address while data is flowing.

> 
> -> As router ensures every Bluetooth node it serves is using
> different Bluetooth address, the 1:1 generated IPv6 Link-Local
> addresses must then be locally unique.

Yes.

> 
> With the above, do you agree that we can optimize away joining to
> solicited-node multicast address and avoid performing DAD for the
> link-local address?

I believe we can avoid DAD in the above scenario.  I would ask that the
document clearly explain the tradeoffs, especially any security issues
that may arise.

> 
> When it comes to privacy, the link-local address privacy will go 1:1
> with the Bluetooth device address privacy = if Bluetooth node uses
> IEEE 802 address at Bluetooth level, the corresponding link-local
> address will be IEEE 802-based. If Bluetooth node uses random device
> address, the corresponding link-local address will be random as
> well.

Yes, and that should be documented as well.

> If this approach is acceptable, we'll update the internet-draft

Seems logical to me.

Regards,
Brian

---

From: <[email-masked]>
Date: Sun, 10 Aug 2014 15:43:43 +0000

Hi Brian,

>In essence, DAD is performed at the BT level.

Well, perhaps strictly speaking not at the BT level, if you think about BT's protocol layers, but rather by support software that decides about establishing BT connections. I clarified this to the draft.

>> address used for the Bluetooth connection (and for the duration of the 
>> connection, in case the address is random and changing). Hence the 
>> router will know what will be, and is, the link-local address of the 
>> node it is about to connect.
>address) will be needed each time a device changes its BT address. 
>If that occurs at random rather than at start up time, a device could lose
>connectivity in the middle of application flows.  That is, unless BT won't 
>allow a new address while data is flowing.

After the Bluetooth LE logical channel between devices has been created, it is referred with Connection Handle (in the HCI interface). Even if a device changes its random device address used for sending BT advertisements, the logical channel stays in place. Hence 6LN and 6LBR can and should keep using the link-local addresses generated from the device addresses used at the time of connection establishment as long as the L2CAP channel stays up.

>I believe we can avoid DAD in the above scenario.  I would ask that the document clearly explain the tradeoffs, especially any security issues that may arise.

I added some discussion about tradeoffs, but I'm not sure what security new issues might arise from this (except privacy, see below)?

>> address, the corresponding link-local address will be random as well.

I was planning to add text like this:
---
   The IPv6 link-local address configuration described in Section 3.2.1
   strictly binds the privacy level of IPv6 link-local address to the
   privacy level device has selected for the Bluetooth LE.  This means
   that a device using Bluetooth privacy features will retain the same
   level of privacy with generated IPv6 link-local addresses.
   Respectively, device not using privacy at Bluetooth level will not
   have privacy at IPv6 link-local address either.  For non-link local
   addresses implementations have a choice to support
   [I-D.ietf-6man-default-iids].
---

Thank you,
	
	Teemu

---

From: Brian Haberman <[email-masked]>
Date: Mon, 11 Aug 2014 07:52:47 -0400

Hi Teemu,

On 8/10/14 11:43 AM, [email-masked] wrote:
> Hi Brian,
> 
>>> This means that: -> In the case of conflict only one device of
>>> those with conflicting address gets to join the 6LBR. Other nodes
>>> with conflicting address will be left stranded, until the moment
>>> they change their random device address (action that some perform
>>> at every boot, some perform periodically, if I understood it
>>> right).
> Well, perhaps strictly speaking not at the BT level, if you think
> about BT's protocol layers, but rather by support software that
> decides about establishing BT connections. I clarified this to the
> draft.

Ok.

> 
>>> -> IPv6 Link-Local address for a node is generated from the
>>> Bluetooth address used for the Bluetooth connection (and for the
>>> duration of the connection, in case the address is random and
>>> changing). Hence the router will know what will be, and is, the
>>> link-local address of the node it is about to connect.
>>  If that occurs at random rather than at start up time, a device
>> could lose connectivity in the middle of application flows.  That
>> is, unless BT won't allow a new address while data is flowing.
> 
> After the Bluetooth LE logical channel between devices has been
> created, it is referred with Connection Handle (in the HCI
> interface). Even if a device changes its random device address used
> for sending BT advertisements, the logical channel stays in place.
> Hence 6LN and 6LBR can and should keep using the link-local addresses
> generated from the device addresses used at the time of connection
> establishment as long as the L2CAP channel stays up.

Given that we are talking only about link-local addresses, this seems fine.

>>>  solicited-node multicast address and avoid performing DAD for
>>> the link-local address?
>> I believe we can avoid DAD in the above scenario.  I would ask that
>> the document clearly explain the tradeoffs, especially any security
>> issues that may arise.
> 
> I added some discussion about tradeoffs, but I'm not sure what
> security new issues might arise from this (except privacy, see
> below)?
> 
>>> When it comes to privacy, the link-local address privacy will go
>>> 1:1 with the Bluetooth device address privacy = if Bluetooth node
>>> uses IEEE 802 address at Bluetooth level, the corresponding
>>> link-local address will be IEEE 802-based. If Bluetooth node uses
>>> random device address, the corresponding link-local address will
>>> be random as well.
> I was planning to add text like this: --- The IPv6 link-local address
> configuration described in Section 3.2.1 strictly binds the privacy
> level of IPv6 link-local address to the privacy level device has
> selected for the Bluetooth LE.  This means that a device using
> Bluetooth privacy features will retain the same level of privacy with
> generated IPv6 link-local addresses. Respectively, device not using
> privacy at Bluetooth level will not have privacy at IPv6 link-local
> address either.  For non-link local addresses implementations have a
> choice to support [I-D.ietf-6man-default-iids]. ---

Seems reasonable on first read.

Regards,
Brian