I’ve just published -15 incorporating the remaining feedback from your COMMENT points. I also moved RFC5869 to normative references, we forgot to do this in the previous revision. Take a look and let me know if you see anything out of the ordinary.
Mališa > On 9 Dec 2019, at 19:21, Benjamin Kaduk <[email protected]> wrote: > > Whoops, this got lost in my inbox; thanks for the (out-of-band) reminder. > Luckily, basically all of it is include in the -14 and looks good, so I > have very little left to say :) > > On Thu, Nov 07, 2019 at 05:23:37PM +0100, Mališa Vučinić wrote: >> >> Many thanks for the in-depth review. In this email I am responding inline to >> most of the COMMENT points, in order to converge on those first. For the >> rest, I created bitbucket issues that we will discuss as part of the WG >> meeting in Singapore and get back to you. >> >> The resulting changes discussed here can be found at: >> >> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/bb94ea9108855f99ad9ac11bdf8d2d7ea7d5f7a6 >> >> <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/bb94ea9108855f99ad9ac11bdf8d2d7ea7d5f7a6> >> >> The list of remaining issues is available at: >> >> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues?status=new&status=open >> >> <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues?status=new&status=open> >> >> Mališa >> >> >>> On 31 Oct 2019, at 07:24, Benjamin Kaduk via Datatracker <[email protected]> >>> wrote: >> … >> >>> Section 10 >>> >>> scanning and device-specific vulnerability exploitation. Since the >>> join process occurs rarely compared to the network lifetime, long- >>> term threats that arise from using EUI-64 as the pledge identifier >>> are minimal. In addition, the Join Response message contains a short >>> >>> I suspect I just failed to internalize things properly, but isn't the >>> pledge identifier used with the network IPv6 prefix to form the global >>> IPv6 address of the joined node? So in that sense, using the EUI-64 as >>> the pledge ID transfers into the long-lived address and the privacy >>> threats are long-term as well. >> >> Not necessarily. If the short identifier is returned as part of the join, >> the pledge can configure its IPv6 address using that. > > But it might happen sometimes? We could probably still mention the privacy > consideration for that case. > >> >>> >>> Once the join process completes, the new node uses the short >>> addresses for all further layer 2 (and layer-3) operations. This >>> >>> My understanding is that this is the usual case but not strictly >>> required by any protocol spec. >> >> That’s correct, we don’t go into this sort of configuration description in >> minimal-security. > > (I was trying to say that "the new node uses the short address for all > further" is declarative, but may not be 100% true. That said, this is only > a COMMENT, so I'm not going to follow up on anything.) > >>> >>> reduces the aforementioned privacy risks as the short layer-2 address >>> (visible even when the network is encrypted) is not traceable between >>> locations and does not disclose the manufacturer, as is the case of >>> >>> Why is it not traceable between locations? >> >> Because the assumption is that each network will assign a different short >> identifier to the pledge, with the identifiers being uncorrelated among >> networks and therefore not traceable. Does that make sense? > > Ah, I was reading this as being different locations within the same > network. If different locations necessitate different networks, then I > agree. > >>> Section 13.2 >>> >>> I agree with Barry that RFC 8505 is probably more appropriately >>> categorized as a normative reference, and further suggest doing so for >>> draft-ietf-core-stateless, IEEE802.15.4, and RFC 5869. >> >> >> Done by Michael on another thread. > > (I didn't find discussion of RFC 5869, but may have been sloppy in my > search.) > > Thanks! > > -Ben _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
