[6tisch] Warren Kumari's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)

Warren Kumari via Datatracker <noreply@ietf.org> Wed, 19 February 2020 22:10 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: 6tisch@ietf.org
Delivered-To: 6tisch@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D362E12083B; Wed, 19 Feb 2020 14:10:47 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-6tisch-enrollment-enhanced-beacon@ietf.org, Pascal Thubert <pthubert@cisco.com>, 6tisch-chairs@ietf.org, pthubert@cisco.com, 6tisch@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.118.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Warren Kumari <warren@kumari.net>
Message-ID: <158215024778.17684.13698521401379090423.idtracker@ietfa.amsl.com>
Date: Wed, 19 Feb 2020 14:10:47 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/hNIY8TFyom0DacOOIWpz8ZzJAV4>
Subject: [6tisch] Warren Kumari's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Feb 2020 22:10:48 -0000

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.