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

[Alissa Cooper <[e-mail]>]

> On Jul 17, 2015, at 1:48 PM, Brian Haberman <[e-mail]> wrote:
> 
> 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? 

Yes

> Do we need to set some time aside in
> Prague to talk about this?

Yes. Brian, could you arrange this with people's schedules?

Thanks,
Alissa

> 
> 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
> 
>