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

[Fernando Gont <[e-mail]>]

Folks,

I'm trying to catch up with this discussion. SO far, my two observations
are:

1) The issue of link-local addresses had been debated when we were
working on RFC7217. There are  number of reasons for which those
addresses might leak out: main one being through application layer
protocols.

2) I believe that any need to provide requirements for IID generation
whould be addressed by referencing draft-ietf-6man-defaul-iids. If
there's any need to go against the advice in default-iids, only the
advice and the rationale should be documented in the new document.

Thanks!

Best regards,
Fernando




On 07/18/2015 07:31 PM, Samita Chakrabarti wrote:
> Hi Alissa,
> 
>  
> 
> From the general L3 perspective, a valid IPv6 implementation does not
> forward Link-local addressing [ as we all know ].
> 
> It’s an operational issue when a rogue implementation does not follow
> the standards.
> 
> The only way it can “leak” the LL addresses is through applications,
> human reading of logs, snooping of LL-addresses in a link etc. as discussed.
> 
>  
> 
> I think we need to be careful about when we need to apply privacy and
> when not. In some cases, privacy is not desirable as the service
> provider might want to know who it is serving. If it is not IID based LL
> address – there is some sort of unique ID there.
> 
>  
> 
> The use-cases for privacy are quite application/usecase specific. Thus
> providing a guideline through the 6man-default-iid draft is the best way
> – as you propose below as well. I also don’t think that
> draft-ietf-6lo-*  is the right place to talk about  application behavior
> for default-iids.
> 
>  
> 
> If we want to prevent others to snoop LL-address in the local subnet,
> one can use encrypted L3 header or we should develop a tool to  prevent
> snooping in the local subnet without permission from the local
> router/administrative domain.
> 
>  
> 
> As far as I can tell, the scope of  draft-ietf-6lo-* documents are in
> the realm of 6lo domain and they are served by a 6lowpan-GW(6LBR) for
> that(foo) L2 technology.  Either 6LBR can assign random IIDs or the
> devices can generate random IID and generate new LL-addresses (for
> example, everytime they wake up). But, note that it will require more
> signaling, messaging in the network  and will  not  be desirable for the
> reduced function nodes or low energy networks. However, it could be an
> optional function which require further analysis from 6lo perspective.
> 
>  
> 
> Regards,
> 
> -Samita
> 
>  
> 
>  
> 
>  
> 
> *From:*Alissa Cooper [mailto:[e-mail]]
> *Sent:* Thursday, July 16, 2015 12:35 PM
> *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
> 
>      
> 
>  
> 
>  
> 


-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492