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

[Kerry Lynn <[e-mail]>]

On Tue, Jul 14, 2015 at 4:58 PM, Savolainen Teemu (Nokia-TECH/Tampere) <
[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]> wrote:
>
>   On Tue, Jul 14, 2015 at 1:53 AM, Savolainen Teemu (Nokia-TECH/Tampere) <
> [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]]
> Sent: 14. heinäkuuta 2015 2:37
> To: Savolainen Teemu (Nokia-TECH/Tampere)
> Cc: IESG; [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [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]> 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]
> https://www.ietf.org/mailman/listinfo/6lo
>
>
>