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

[Brian Haberman <[e-mail]>]

I believe that Alissa's points are valid and should be documented
somewhere. However, I think those points are globally valid (i.e., well
beyond the scope of this draft).

Alissa's suggestion of putting the context and the recommendations in a
more generic draft, like default-iids, makes more sense to me than
trying to wordsmith them into this document and then having to do the
same thing for every new ipv6-over-foo draft.

Does the above work for everyone?  Do we need to set some time aside in
Prague to talk about this?

Brian

On 7/17/15 3:38 AM, Savolainen Teemu (Nokia-TECH/Tampere) wrote:
> Hi Alissa,
> 
> I would say that by definition people can build whatever they want on
> top of IPv6 over BLE. Furthermore, nothing limits using IPv6 over BLE
> only by most constrained devices. The Bluetooth LE is a nice radio
> and is being supported by large number of devices, such as
> smartphones, tablets, and PCs. And these potentially could start
> supporting also IPv6 over BLE (no HW changes required). Hence even if
> Bluetooth LE radio is designed for constrained devices,
> non-constrained devices might find it useful as well (usefulness of
> that on different scenarios of course depends and can be debated).
> Thus we cannot limit applications, and probably this document is not
> the right place to guide application developers about not leaking
> device identity information via addresses.
> 
> So, while general guidance probably is needed elsewhere, do we agree
> that 6lo-btle-15 should nevertheless say: "However, the 6LBR MUST NOT
> send the 6LN's link-local address outside of the local link."? . . .
> What it the 6LBR logs connections and the logs are collected by
> remote entity? This log would probably include device address of
> connected devices, thus the link-local address, and hence would
> violate "sending 6LN's link-local address outside of the local
> link.".. our would that kind of activity be an allowed exception to
> MUST NOT?
> 
> I have been previously thinking that use of random device addresses
> would be implementation decision, but would it help if in this
> document we would recommend implementations to use random Bluetooth
> device addresses (RECOMMENDED or SHOULD wording, perhaps)? I think
> this could be added, for example, at the first paragraph of Section 3
> like this (the last two sentences of the paragraph are new): -- At
> network interface initialization, both 6LN and 6LBR SHALL generate 
> and assign to the Bluetooth LE network interface IPv6 link-local 
> addresses [RFC4862] based on the 48-bit Bluetooth device addresses 
> (see Section 2.3) that were used for establishing the underlying 
> Bluetooth LE connection. A 6LN and a 6LBR are RECOMMENDED to use
> random Bluetooth device addresses. A 6LN SHOULD pick a different
> Bluetooth device address for every Bluetooth LE connection with a
> 6LBR, and a 6LBR SHOULD periodically change its random Bluetooth 
> device address. --
> 
> Best regards,
> 
> Teemu
> 
> From: ext Alissa Cooper [mailto:[e-mail]] Sent: 16.
> heinäkuuta 2015 22:35 To: Savolainen Teemu (Nokia-TECH/Tampere);
> Fernando Gont; Dave Thaler; Will Cheng Cc: ext Kerry Lynn;
> [e-mail]; [e-mail];
> [e-mail];
> [e-mail]; [e-mail]; IESG;
> [e-mail] Subject: Re: [6lo] Alissa Cooper's
> Discuss on draft-ietf-6lo-btle-14: (with DISCUSS and COMMENT)
> 
> + Dave, Fernando and Will, my co-authors on
> draft-ietf-6man-default-iids and
> draft-ietf-6man-ipv6-address-generation-privacy
> 
> When we were writing draft-ietf-6man-ipv6-address-generation-privacy
> we had a discussion about whether the analysis should apply to
> link-locals as well as non-link-locals. The conclusion was yes
> because link-locals leak out via higher layer protocols (the example
> given is leakage in email headers). So my suggestion was in the vein
> Teemu described, using "sending" in a broader sense than just
> forwarding. As to why a node would send an unreachable address in a
> higher layer protocol, it probably depends on the protocol and the
> implementation and may happen by mistake or for no good reason other
> than the fact that protocol calls for an address to be filled in and
> the implementation chooses a link-local address to fill it.
> 
> It's true that what I suggested can't be enforced at layer 3, so
> maybe this recommendation needs some more context around it and
> belongs somewhere else (draft-ietf-6man-default-iids?). But I do feel
> that if we're going to write down the recommendations in
> draft-ietf-6man-default-iids and then create an exception whenever a
> case comes up where link-locals are expected not to leak, we should
> be clear about both recommending against leakage and the reasons for
> the exception. I'd like to understand if it's the case that you don't
> expect applications to be built on top of BLTE that could have the
> leakage problem (because of how constrained the devices are, etc.),
> or if it's just unknown since people can build whatever they want on
> top.
> 
> Thanks, Alissa
> 
> On Jul 14, 2015, at 2:31 PM, Savolainen Teemu (Nokia-TECH/Tampere)
> <[e-mail]<mailto:[e-mail]>>
> wrote:
> 
> 
> 
> True. I'd like to hear Alissa's comment, as she proposed this
> addition.
> 
> Best regards,
> 
> Teemu On Jul 15, 2015 12:09 AM, ext Kerry Lynn
> <[e-mail]<mailto:[e-mail]>> wrote: On Tue, Jul 14, 2015
> at 4:58 PM, Savolainen Teemu (Nokia-TECH/Tampere)
> <[e-mail]<mailto:[e-mail]>>
> wrote:
> 
> Hi,
> 
> I understood the sending to be about wider scope than merely
> forwarding of packets. I.e. it would include sending of link-local
> addresses of connected nodes as part of some other protocol payload
> (e.g. hypothetically in ICE negotiations or so). But I'm not sure if
> that was the original intent. I can see this would be a potential
> privacy concern but worse, it seems like a waste of bandwidth since
> such an address could not be reached from outside the local network.
> How could any IP-over-foo scheme enforce this for arbitrary L4
> protocols?
> 
> Regards, Kerry
> 
> Best regards,
> 
> Teemu On Jul 14, 2015 11:22 PM, ext Kerry Lynn
> <[e-mail]<mailto:[e-mail]>> wrote: On Tue, Jul 14, 2015
> at 1:53 AM, Savolainen Teemu (Nokia-TECH/Tampere)
> <[e-mail]<mailto:[e-mail]>>
> wrote: Hi Alissa,
> 
> Thank you for your reply, understanding, and spending time to create
> actual text proposals. The proposed pieces of text are good
> improvements, in my opinion, and I didn't really have any objections
> or comments. If no other opinions arise, these will be included in
> -15 as you proposed.
> 
> For 3.2.1 the proposed sentence is currently drafted to be added to
> the end of the section like this: -- ....The 6LBR ensures address
> collisions do not occur (see Section 3.2.3) and forwards packets sent
> by one 6LN to another. However, the 6LBR MUST NOT send the 6LN's
> link-local address outside of the local link.
> 
> The definition of link-local address is given in RFC 4291, Section
> 2.5.6: "Routers must not forward any packets with Link-Local source
> or destination addresses to other links."
> 
> It seems unnecessary and perhaps confusing to repeat it here.  If it
> is not universally understood that 6LBRs work in this fashion, then
> we should clarify it in some architectural document (like RFC 4291) 
> so we don't have to spell it out in each 6lo proposal.
> 
> Regards, Kerry Lynn
> 
> --
> 
> Best regards,
> 
> Teemu
> 
> -----Original Message----- From: ext Alissa Cooper
> [mailto:[e-mail]<mailto:[e-mail]>] Sent: 14.
> heinäkuuta 2015 2:37 To: Savolainen Teemu (Nokia-TECH/Tampere) Cc:
> IESG;
> [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]> Subject: Re: Alissa Cooper's
> Discuss on draft-ietf-6lo-btle-14: (with DISCUSS and COMMENT)
> 
> Hi Teemu,
> 
> Thanks for your reply. Comments inline.
> 
> On Jul 7, 2015, at 10:59 PM, Savolainen Teemu (Nokia-TECH/Tampere)
> <[e-mail]<mailto:[e-mail]>>
> wrote:
> 
>> Hi Alissa,
>> 
>> Thank you for your review. I'll try to address your comments
>> below:
>> 
>>> 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.
>> 
>> This document uses the same RFC 6282 for header compression
>> (normative reference) and requires IID to be derivable from
>> somewhere. Hence I would see that this document is under the
>> RFC6282 exception on that regard, and we would not need to repeat
>> all justifications? Furthermore, if the IID cannot be derived from
>> the Bluetooth LE connection itself, I don't really see from where
>> it could be derived..
>> 
>>> 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.
>> 
>> Well the RFC 6282 requires IID to be computable from somewhere,
>> when fully elided and we need that for best power efficiency, so
>> isn't that already enough of justification?
>> 
>> Furthermore, the subnet model (Section 3.2.1) restricts link-local
>> addresses to be used only between 6LN and 6LBR. Hence the IID
>> should not leak any further than to 6LBR. If the LE device is not
>> changing its device address but is switching between different
>> 6LBRs, the 6LBRs can already track the LE device based on its
>> device address, and changing IPv6 IID for link-local addresses just
>> adds complexity/loses efficiency, but does not provide privacy
>> benefits. Right?
> 
> I chatted with Brian about this during the telechat and he reaffirmed
> that link-locals are not expected to leak outside the 6LN-6LBR
> connection in this case. So I'm ok to clear the bulk of my discuss
> with that assurance. But I would suggest being totally explicit about
> it, e.g. by adding text to 3.2.1 such as:
> 
> The 6LBR MUST NOT send the 6LN's link-local address outside of the
> local link.
> 
> With that said, this text about non-link-locals is not consistent
> with the recommendations in draft-ietf-6man-default-iids:
> 
> For non-link-local addresses a 64-bit IID MAY be formed by utilizing 
> the 48-bit Bluetooth device address.  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].
> 
> To be consistent with draft-ietf-6man-default-iids I think it would
> have to say something more along these lines:
> 
> For non-link-local addresses, 6LNs SHOULD NOT be configured to embed
> the Bluetooth device address in the IID by default. Alternative
> schemes such as Cryptographically Generated Addresses (CGA)
> [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses (HBA,
> [RFC5535]), DHCPv6 [RFC3315], or static, semantically opaque addreses
> [RFC7217] SHOULD be used by default. In situations where the
> Bluetooth device address is known to be randomly generated and/or the
> header compression benefits of embedding the device address in the
> IID are required to support deployment constraints, 6LNs MAY form a
> 64-bit IID by utilizing the 48-bit Bluetooth device address.
> 
>> 
>> Even more, if device vendors choose to use static Bluetooth device
>> addresses, *everybody* in vicinity will be able to track such
>> devices simply by listening Bluetooth LE advertisements those
>> devices broadcast for Bluetooth LE service discovery purposes. If
>> they then use IPv6 link-local address that are only used between
>> Bluetooth LE device and it's router, no additional information
>> leaks out. It is of course another matter if the 6LN uses the
>> static device address for global address generation.
>> 
>> When it comes to assumption, I would assume static Bluetooth LE
>> device addresses are actually not to be used that much, at least
>> for Bluetooth LE nodes that are expected to be mobile. This is
>> because in Bluetooth LE random addresses are inbuilt to
>> specification and very easy to use, on the contrary to basic
>> Bluetooth (BR/EDR) that does not have as good privacy features as
>> the LE. So I don't really see need for LE device vendors not to use
>> random device addresses. (If Bluetooth LE devices have been paired,
>> they can choose to use random resolvable addresses in their
>> advertisements, which the paired devices can recognize to indicate
>> known device by using Identity Resolving Key, please see BLE specs
>> for more).
>> 
>> For non-link-local addresses variety of means for privacy are
>> documented.
>> 
>>> 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?
>> 
>> The Bluetooth LE device address change does not impact ongoing
>> sessions. So the IID will remain the same during an established LE
>> L2CAP connection lifetime - the possible device address change is
>> not impacting existing connections! However, for Bluetooth LE
>> service discovery and for new connections the new device address
>> *does* impact, and hence new IPv6 IID would be used for new
>> connections. Actually, no matter what kind of IPv6 address changes
>> the 6LN performs, the 6LBR that has ongoing L2CAP connection to 6LN
>> will always know it is the same 6LN that is sending data. Hence
>> there's no point in changing IPv6 link-local address within ongoing
>> L2CAP connection.
> 
> Ok, understood. I would suggest a slight modification to the text so
> it gets more to the point:
> 
> OLD 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.
> 
> NEW The IPv6 link-local address configuration described in Section
> 3.2.2 only reveals information about the 6LN to the 6LBR that the
> 6LBR already knows from the link layer connection. This means that a
> device using Bluetooth privacy features reveals the same information
> in its IPv6 link-local addresses as in its device addresses.
> 
>> 
>> If the 6LN having connection up would wish to change its link-local
>> address so that the 6LBR cannot track it, the 6LN has to: - Tear
>> down BLE connection (disconnect L2CAP and so on) - Change device
>> address - Start advertising IPSP service - Wait for 6LBR to
>> establish BLE connection to it - Start using IP with new link-local
>> address
>> 
>>> Why does this draft reference v4.1 of the Bluetooth spec rather
>>> than v4.2?
>> 
>> This draft requires Bluetooth 4.1 or newer. We wanted to have
>> reference to the minimum version of the Bluetooth spec that is
>> required.
>> 
>>> In 3.2.2, I think RFC 7217 should be added to the list in this
>>> sentence: Similarly, in Section 5,
>>> s/[I-D.ietf-6man-default-iids]/[RFC7217]/ in this sentence:
>> 
>> That sound be fine, as long as we don't need to start defining how
>> to select things like Network_ID?
> I don't think that's necessary - it's not as if this has been defined
> for other network types, and it's optional.
> 
> Thanks, Alissa
> 
>> 
>> Best regards,
>> 
>> Teemu
>> 
> 
> _______________________________________________ 6lo mailing list 
> [e-mail]<mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/6lo
> 
> 
> 
>