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

[Alexandru Petrescu <[e-mail]>]

Le 14/07/2015 22:22, Kerry Lynn a écrit :
> 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.

Kerry - let me comment on this.

That definition of link-locals non-propagation across routers (RFC4291) 
is valid in a world where we know what a subnet is.

But in 6lo (RPL, 6lowpan) we know less what a subnet is, and routers 
have a single interface.  There is no multicast scope, yet IPv6 subnets 
are very tightly depending on that.

For example, the BLE document has no address mapping scheme ("address 
mapping" in terms of RFC2464).

Moreover, the BLE document states "In the Bluetooth LE case, the 
benefits of treating the collection of point-to-point links between a 
central and its connected peripherals as a single multilink subnet 
rather than a multiplicity of separate subnets are considered to 
outweigh the multilink model's drawbacks as described in [RFC4903]."

This consideration of BLE subnets makes it that we dont know what an 
IPv6 subnet is, and hence we dont know what is "local" in link-local. 
And so, link-local addresses can easily be forwarded out of places that 
we dont know what they are.

Alex

>
> 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
>
>
>
>
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo
>