Warren Kumari has entered the following ballot position for draft-ietf-6tisch-enrollment-enhanced-beacon-13: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6tisch-enrollment-enhanced-beacon/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [ Be ye not afraid - this should be easy to answer / address ] The Privacy Considerations says: "The use of a network ID may reveal information about the network." Good point - but it also goes on to say: "The use of a SHA256 hash of the DODAGID, rather than using the DODAGID (which is usually derived from the LLN prefix) directly provides some privacy for the the addresses used within the network, as the DODAGID is usually the IPv6 address of the root of the RPL mesh." I don't know if this is an issue, but how much entropy is in a DODAGID? From what I could find, the DODAGID is often just an IP address - and subnets are not randomly distributed, nor are L2 addresses (inputs to address generation) - if I know that many of the nodes come from vendor_A, and I know their L2 / MAC range, can I enumerate this, and by extension the DODAGID, and so the hash? I will happily admit that I haven't fully researched this / thought it through, so "Nah, won't work" or "Yes, will work, but we did say 'provides some privacy', not 'absolute privacy'" or all acceptable answers :-) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I found this document to be well written, and helpfully explained the background, issue, etc. Thank you! Question: "Pledges which have not yet enrolled are unable to authenticate the beacons, and will be forced to temporarily take the contents on faith. After enrollment, a newly enrolled node will be able to return to the beacon and validate it." Yes, this is true - a newly enrolled node will be able to do this -- but I don't see a suggestion / requirement that they actually *do* so. I'm perfectly capable of picking up my socks, but.... :-) Nit: "Although However, even in this case, a" - typo / redundancy. Please also see Qin Wu's Opsdir review (https://datatracker.ietf.org/doc/review-ietf-6tisch-enrollment-enhanced-beacon-08-opsdir-lc-wu-2020-01-21/), which has some useful questions / nits. _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
