IPv6 over BLUETOOTH(R) Low Energy
draft-ietf-6lo-btle-17

Thank you for all of your efforts and candid engagement to get my DISCUSS points resolved. I have cleared the DISCUSS. I did notice one last edit that should probably get made so that Section 5 is consistent with the new text in Section 3.2.2, but will leave it to you to decide whether you want to make the change.

In Section 5:

OLD
For non-link local
   addresses implementations have a choice to support, for example,
   [I-D.ietf-6man-default-iids], [RFC3315], [RFC3972], [RFC4941],
   [RFC5535], or [RFC7217].

NEW
For non-link local
   addresses, implementations are recommended not to embed
   the Bluetooth device address in the IID by default and instead support, for example,
   [RFC3315], [RFC3972], [RFC4941],
   [RFC5535], or [RFC7217].

Because of the history of this document, significant explanation was needed -- and provided -- in the shepherd writeup.  Thanks, Gabriel, for the good job on that.  The writeup says:

> This support from BT SIG should address the remaining DISCUSS on
> the original document.

It does, indeed (it was my DISCUSS), and this document looks great.  I'm glad things were sorted out with BT SIG, and thanks to everyone for all the work on this.

from opsdir review by niclas comstedt

Hi,

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document is for the Standards Track.

This document defines how IPv6 is transported over Low Energi Bluetooth leveraging 6LoWPAN techniques for 802.15.4.

I have no real feedback. The document is well written and makes sense to me. The compression details are a bit outside of my experience so didn’t get into all the details there. There are no real nits (one single referenced draft has a newer version) and my only semantical small change would be:

- 3.2.4 first paragraph, remove “in this document”. Header compression as defined … … is REQUIRED as the basis … … Those two first sentences are a little repetitive which adds to it

- 3.3, should this just be moved up under 3.2.1 or something? Its only referenced there unless I’m missing something and doesn’t need the context of what comes after.

I also fully support Alissa's discuss points on privacy.

As the draft says, 'when available' for the security and privacy options, so anything that can be done should be to improve this for IPv6 over bluetooth.  Having done some testing of the ability to monitor bluetooth, it can go up to 70' in certain conditions and much less in other conditions.  We were also able to monitor through windows.  This testing was done with an earlier bluetooth version monitoring point to point sessions in various conditions (it was a fun day at work).  People and their IoT devices are much more exposed than they realize especially since the security and privacy options hat can be implemented often are not.  That's just a long way of stating that I support Alissa's discuss.

In this text:

   New addresses are typically generated each time a
   device is powered on.  In random addresses all 48 bits are
   randomized.  Bluetooth LE does not support device address collision
   avoidance or detection.  However, these 48 bit random device
   addresses have a very small probability of being in conflict within a
   typical deployment.
   
is the working assumption that if a random device address conflict does arise, either a human will recycle power because that's what humans do with electronic devices that don't work, or if no impatient human is available, the device will power off and back on eventually and everything will be fine?

I'm looking at this text:

   In the rare case of Bluetooth LE random device address conflict, a
   6LBR can detect multiple 6LNs with the same Bluetooth LE device
   address, as well as a 6LN with the same Bluetooth LE address as the
   6LBR.  The 6LBR MUST ignore 6LNs with the same device address the
   6LBR has, and the 6LBR MUST have at most one connection for a given
   Bluetooth LE device address at any given moment.  This will avoid
   addressing conflicts within a Bluetooth LE network.
   
and guessing that the Bluetooth LE network doesn't have addressing conflicts, but does that mean that the device that's trying to use a random device address that would cause addressing conflicts if it wasn't being ignored will give up and choose another random device address?

- I strongly support Alissa's DISCUSS and would argue that we
ought really try hard to minimise any privacy leakage being
contributed to by this specification. We basically have one
chance to do this well, after which any leakage becomes yet
another reason to not do the job well in future in other places.
(Based on dodgy but often heard arguments like: "but IPv6/BTLE
already dos this badly, so there's no additional harm in
foo/IPv6/BTLE being just as bad.")

I also note that the fact that some of that leakage relates to
link local addresses doesn't really reduce the damage so much
with a radio based link layer. (Yes, good l2 crypto could help
there, but only if always used everywhere for all packets and I
don't know if BTLE requires that, I suspect it does not.)

- The secdir review in early June made a couple of points that
are worth addressing. [1] I have not seen any response to that
review. (Apologies if I missed it.) 

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05744.html