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

[AbdurRashidSangi <[e-mail]>]

Dear all & Samita,

We have submitted a first draft regarding this approach. Looking forward to get the comments.

Thanks.
Rashid Sangi.

A new version of I-D, draft-rashid-6lo-iid-assignment-00.txt
has been successfully submitted by Abdur Rashid Sangi and posted to the IETF repository.

Name:		draft-rashid-6lo-iid-assignment
Revision:	00
Title:		Designating 6LBR for IID Assignment
Document date:	2016-03-16
Group:		Individual Submission
Pages:		9
URL:            https://www.ietf.org/internet-drafts/draft-rashid-6lo-iid-assignment-00.txt
Status:         https://datatracker.ietf.org/doc/draft-rashid-6lo-iid-assignment/
Htmlized:       https://tools.ietf.org/html/draft-rashid-6lo-iid-assignment-00


Abstract:
   In IPv6 Stateless Address Autoconfiguration (SLAAC), use of a random
   interface identifier (IID) is a common practice to promote privacy.
   If there are a very large number of nodes, as has been discussed in
   several use cases, the effect will to proportionately increase the
   number of IIDs.  A duplicate address detection (DAD cycle) is needed
   for each configured IID, introducing more and more overhead into the
   network.  Each failed DAD requires the initiating node to regenerate
   a new IID and undergo the DAD cycle again.  This document proposes an
   optimized approach that requires 6LBR (6LoWPAN Border Router) to
   provide a unique IID, avoiding the potential duplication.

                                                                                  


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.


-----Original Message-----
From: Samita Chakrabarti [mailto:[e-mail]] 
Sent: 2016年2月27日 4:33
To: AbdurRashidSangi; [e-mail]
Subject: RE: IID Assignment [ Was Re: [6lo] Alissa Cooper's Discuss on draft-ietf-6lo-btle-14: (with DISCUSS and COMMENT)]


Hi Rashid,

I have changed the subject to IID assignment as 6lo-btle document has long become RFC 7668.
Please see in-line.

-----Original Message-----
From: 6lo [mailto:[e-mail]] On Behalf Of AbdurRashidSangi
Sent: Thursday, February 25, 2016 7:50 PM
To: [e-mail]
Subject: Re: [6lo] Alissa Cooper's Discuss on draft-ietf-6lo-btle-14: (with DISCUSS and COMMENT)

Hi Samita,

With reference to the last paragraph of your email thread:

“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.”

Do you see it more effective if the 6LBR generates an IID on behalf of LN?
[SC>]  I must say that when I commented the above, I did not plan a solution. But it was a possibility -- through extending functionality of DHCP or 6lowpan-ND.  But the problem is that IID must be required in order to form the IP-address and DAD etc. and DHCP or ND depends on L3 communication and assign prefix to form the IP-address or assign the whole Ip-address.

Thus some initial communication needs to happen using the classic Ipv6 link-local address formation and then the new Prefix+IID must be assigned and changed periodically for tighter privacy. That also then require 6LBR or the address-assigner entity  to be responsible for ensuring uniqueness of the IID -- or generating the IID based on the principle described in RFC 7217.
[SC>] 


Suppose if a particular use case requires more frequently the arbitrary use of randomly generated IIDs then enormous amount of DAD cycle would be created.

Although, MAC driven IIDs (RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4338, RFC4391, RFC5121 and RFC5072) needs less or no amount of DAD but in practice such IID generation is discouraged "draft-ietf-6man-default-iids-09 AND I-D.ietf-6man-ipv6-address-generation-privacy" as the privacy concerns (Network activity correlation, Location tracking, Address scanning and Device-specific vulnerability exploitation) still persist. More preferred approach is to use RFC7217 for same purpose. 
[SC>]
[SC>]
The position for 6lo is that our documents must provide alternative mechanisms for address generation for privacy, however due to different deployment requirements, battery efficiencies, network noise and device capabilities, that option may not be the default option.

RFC 7428-- describes some of the potential issues in the Zwave networks -- I think the same applies to many 6lo networks today.
 "  For enhanced privacy, the
   DHCP-assigned addresses should be logged only for the duration of the
   lease, provided the implementation also allows logging for longer
   durations as per the operational policies.

   It should be noted that privacy and frequently changing address
   assignments come at a cost.  Non-link-layer-derived IIDs require the
   use of address registration.  Further, non-link-layer-derived IIDs
   cannot be compressed; this leads to longer datagrams and increased
   link-layer segmentation.  Finally, frequent prefix changes
   necessitate more Context Identifier updates; this not only leads to
   increased traffic but also may affect the battery lifetime of
   sleeping nodes."

However, if 6loWPAN stack is someday used over 802.11 networks (for example), then those cases will be different from constrained node networks views/requirements when communicating with larger IoT or other devices.
[SC/]

Unlike for DAD the 6LBR, providing status (= 1) and needs the LN (usually a resource constraint device) to regenerate an IID which ultimately require another DAD cycle, 6LBR (according to RFC7217) suggest a unique IID for LNs using its own (6LBR) secret key?
[SC>]
[SC>]  As I mentioned it is a possibility for a new solution. If the WG is interested in such a solution after considering pros and cons -- it probably makes sense as an approach of address assignment.

Wouldn't it be a better approach?
[SC>] It's too early to compare :-)



[SC>]
Thanks,
-Samita
-----Original Message-----
Subject: Re: [6lo] Alissa Cooper's Discuss on draft-ietf-6lo-btle-14: (with DISCUSS and COMMENT)

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


_______________________________________________
6lo mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lo