[6lo] Alissa Cooper's Discuss on draft-ietf-6lo-btle-14: (with DISCUSS and COMMENT)

["Alissa Cooper" <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-6lo-btle-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-btle/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

My understanding from the discussions surrounding
draft-ietf-6man-default-iids was that RFC 6282 constitutes an exception
to the main recommendation ("By default, nodes SHOULD NOT employ IPv6
address generation schemes that embed the underlying link-layer address
in the IID") because the header compression scheme in RFC 6282 requires
that the IID be based on the link layer address. I see no text that
justifies a similar requirement in this document. I think if this
document is going to specify generating the IID from the device address
as the only address generation scheme for link-local addresses, it needs
to provide a justification for that. Otherwise, the default address
generation scheme should be one that generates an opaque IID of limited
lifetime. The possibility that the device address is generated randomly
and refreshed on each power cycle is important to note, but is not by
itself sufficient justification given what I assume is the wider
deployment of static device addresses. If the v6 address can provide
better privacy protection than the device address, it should.

On that point, there also seems to be a discrepancy between Section 3.2.2
and Section 5. Section 3.2.2 states:

"(After a Bluetooth LE logical link has been established, it
   is referenced with a Connection Handle in HCI.  Thus possibly
   changing device addresses do not impact data flows within existing
   L2CAP channels.  Hence there is no need to change IPv6 link-local
   addresses even if devices change their random device addresses during
   L2CAP channel lifetime)."
   
Section 5 states:

"The IPv6 link-local address configuration described in Section 3.2.2
   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."

If the IID remains the same even when the device address changes, then
the IID can be used to correlate activities of the device for the full
lifetime of the IID, which goes beyond the lifetime of the device
address. So the "privacy level" afforded by the device address is not the
same as that of the IID. If this document is going to specify the
generation of IIDs based on device addresses, why not regenerate the IID
when the device address is regenerated?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Why does this draft reference v4.1 of the Bluetooth spec rather than
v4.2?

In 3.2.2, I think RFC 7217 should be added to the list in this sentence:

"A 6LN can also use a randomly
   generated IID (see Section 3.2.3), for example, as discussed in
   [I-D.ietf-6man-default-iids], or use alternative schemes such as
   Cryptographically Generated Addresses (CGA) [RFC3972], privacy
   extensions [RFC4941], Hash-Based Addresses (HBA, [RFC5535]), or
   DHCPv6 [RFC3315]."

Similarly, in Section 5, s/[I-D.ietf-6man-default-iids]/[RFC7217]/ in
this sentence:
"For non-link local
   addresses implementations have a choice to support, for example,
   [I-D.ietf-6man-default-iids], [RFC3972], [RFC4941] or [RFC5535]."