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

Warren Kumari <> Fri, 21 February 2020 16:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6837B1208BE for <>; Fri, 21 Feb 2020 08:31:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eM94xc-aeP89 for <>; Fri, 21 Feb 2020 08:31:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::f36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B8381208C7 for <>; Fri, 21 Feb 2020 08:31:45 -0800 (PST)
Received: by with SMTP id ff2so1239402qvb.3 for <>; Fri, 21 Feb 2020 08:31:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E+lHKgt4KO7br6y2CW9Nf3kpsHzIYDSiu6Ub+XYZjNM=; b=Gq5Lm62UeHOTdoDBAIS3nWM5UCH/w7IeSSjoqMRUtQIehMedodiHuOghtQmzuerDJM ymrIcM0Ojum9eC6KPXDS4EKoNB0tUsl29vms9M64DHwRIWVzjGeuCz3o9VK398RCRXq3 caZlEFfEC/v0+01UWhSqt5E66CExy0fqNNQ5XvTDiVN08WXp9wpUQWHcydYatYrsDkNg F4uoqluepxdvdK04Fv9EGWuuETcZcCGql2L5Trx6A0sYMZnQkm+Wik4hVZC0pWEpnfHb bXpoW2tfa3pyc6oj8C42c3/fYRMNT2vX0DxpGXUzUPyQiAZaptjqf30i0eedkeYmMDkd EZyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E+lHKgt4KO7br6y2CW9Nf3kpsHzIYDSiu6Ub+XYZjNM=; b=Yqczz9L+1xLIegoRSVVrPxlgUVfCKDpqgRhcp/A07sV+7QPkDAAFWTMHjFiBT+7iCh bvKoElryyFsjD8Q1yIWLgaGs1LfkG+jwh3AZ9zLqR29Cj8VtKEhDquclEVltSo7lvGf/ DxnbRBV0ehN3YQ7dH6GvV3AM1ZzWrZKs1lk1/sUcK9ShSwN2hjRNaVXID9cKiVpYqiHj CxR4rdo3Sq4cVpEj8U3DTi2ga0UqcO7kdqp3FvzlVvLA/En4ait/iN0vMHLGm8cbIgPM 7fww0LuKHEcU46+dYEhGaaETOrHnCRKBdgpI9wezMhgZcYT+a1y4fyZas6MhoULnLD6n VdiQ==
X-Gm-Message-State: APjAAAW1r7ScbaKUQGLnxLCiP14zSaDXsIMLIIpJy3oaxIxFMuyQ8pHt XBywNb0PyK4ixz+hlVb6vzGaxDExFobkH86bWEYb5Q==
X-Google-Smtp-Source: APXvYqwwSKeIOoqgeuMADO9g1+uuII1C49cOW8WwpZrLC8LZMLBUrML/DiEbYpLLRj3KYN1JnxJGBE1PqhJR4c+JEbc=
X-Received: by 2002:a0c:edc3:: with SMTP id i3mr31495537qvr.29.1582302704234; Fri, 21 Feb 2020 08:31:44 -0800 (PST)
MIME-Version: 1.0
References: <> <2595.1582224894@dooku>
In-Reply-To: <2595.1582224894@dooku>
From: Warren Kumari <>
Date: Sat, 22 Feb 2020 03:31:33 +1100
Message-ID: <>
To: Michael Richardson <>
Cc:,, The IESG <>,,
Content-Type: multipart/alternative; boundary="0000000000009d0d4c059f188e5e"
Archived-At: <>
Subject: Re: [6tisch] Warren Kumari's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
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" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Feb 2020 16:31:53 -0000

On Fri, Feb 21, 2020 at 11:39 PM Michael Richardson <>

> Warren Kumari via Datatracker <> wrote:
>     > [ 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
>     > 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?
> The point of a good hash is to spread whatever entropy there is in the
> input
> all over the output.   If there are a very few number of inputs, then akin
> to
> the /etc/passwd dictionary attacks, an attacker can just pre-calculate a
> bunch of things.
> So, can you enumerate the DODAGIDs?  Maybe.
> The 6LBR address which is usually used as the DODAGID is an IPv6 address.
> So there is some ~32-bits of space assuming that the RIR assigned prefix
> (e.g. 2001:db8::/32) is discoverable by looking up
> This assumes that you know who you are trying learn about.
> The next 32-bits will be operator or DHCPv6-PD assigned, and maybe not
> guess
> that part.  And then the IID could be assigned via any number of our
> RFC8064,
> or might be ::1.
> So if you know what network you are looking for, you can probably find it.
> The operator is allowed to generate the NetworkID with a random number
> generator, btw.
> But, if you observe ten LLNs the hash makes it hard to trivially map them
> back to a specific operator.
> Do you feel that I need to add this to the document?
> I feel that it distracts: SHA256 is just a suggestion.

Fair ‘enough; I just wanted to make sure y’all had considered it. I think a
single sentence noting the above would be helpful, but that’s just an

I’m at an airport, will clear my position when I have more bits...


>     > 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 :-)
> Some privacy.
>     >
> ----------------------------------------------------------------------
>     > 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.... :-)
> You want to read draft-ietf-6tisch-minimal-security section 5 and section
> 9,
> last paragraph.
> Doing so is somewhat optional: if the pledge doesn't verify the beacon it
> saw
> then it will verify the next beacon.
> If the beacon was bogus, then the 6tisch-CoJP likely also failed, or the
> pledge won't get to the Join Proxy at all, since it will not have a
> workable
> TSCH schedule.
>     > Nit: "Although However, even in this case, a" - typo / redundancy.
>     > Please also see Qin Wu's Opsdir review
>     > (
> ),
>     > which has some useful questions / nits.
> I thought I had, but I don't have anything in my outbox, so I'll grab it
> when
> I land.
> --
> Michael Richardson <>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of