Re: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 21 February 2020 12:39 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9A0120639; Fri, 21 Feb 2020 04:39:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.85
X-Spam-Level:
X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVHnPgJ70Z0Z; Fri, 21 Feb 2020 04:39:31 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49CEF1200D6; Fri, 21 Feb 2020 04:39:31 -0800 (PST)
Received: from dooku.sandelman.ca (CPEbc4dfbbcd553-CMbc4dfbbcd550.cpe.net.cable.rogers.com [99.230.57.100]) by relay.sandelman.ca (Postfix) with ESMTPS id 9CC0E1F487; Fri, 21 Feb 2020 12:39:29 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 567CB1A3B7A; Thu, 20 Feb 2020 20:22:59 +0100 (CET)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Benjamin Kaduk <kaduk@mit.edu>
cc: "The IESG" <iesg@ietf.org>, pthubert@cisco.com, 6tisch-chairs@ietf.org, 6tisch@ietf.org, draft-ietf-6tisch-enrollment-enhanced-beacon@ietf.org
In-reply-to: <158206755196.14101.10514108989438939697.idtracker@ietfa.amsl.com>
References: <158206755196.14101.10514108989438939697.idtracker@ietfa.amsl.com>
Comments: In-reply-to Benjamin Kaduk via Datatracker <noreply@ietf.org> message dated "Tue, 18 Feb 2020 15:12:31 -0800."
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.2.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Thu, 20 Feb 2020 20:22:59 +0100
Message-ID: <3706.1582226579@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/oyb50xbCEhPp-Njka69uO2tp1xE>
Subject: Re: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with COMMENT)
X-BeenThere: 6tisch@ietf.org
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" <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: Fri, 21 Feb 2020 12:39:34 -0000

Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------

    > Where is PAN/PANID defined?  I did not find it in RFC 6550, 8180, or
    > draft-ietf-6tisch-architecture, nor in the RFC Editor's list
    > (https://www.rfc-editor.org/materials/abbrev.expansion.txt).

PAN/PANID is an IEEE thing, and I've added a reference and explanation:

          These are called Personal Area Networks (PAN).
          Each instance will have a separate Layer-2 security profile, and
          will be distinguished by a different PANID.

          The PANID is part of the {{ieee802154}} layer-2 header: it is a
          16-bit value which is chosen to be unique, and it contributes context to the
          layer-2 security.

          The PANID provides a context similar to the ESSID does in 802.11
          networking, and can be conceived of in a similar fashion as the
          802.3 ethernet VLAN tag in that it provides context for all layer-2
          addresses.

    > Section 1.3

    >    Although However, even in this case, a unicast RS may be transmitted
    > in response[RFC6775] reduces the amount of multicast necessary to do
    > address resolution via Neighbor Solicitation (NS) messages, it still
    > requires multicast of either RAs or RS.  This is an expensive

    > nits: two capitalized words in a row, also some further rewording is
    > needed (and maybe s/unicast RS/unicast RA/?).

fixed.

    > Section 2

    > We should probably say something about the 'res' bits being reserved,
    > set to zero, and ignored by recipients.

done.

    >       In most cases, every node sending a beacon will set this flag,
    > and in a typical mesh, this will be every single node.  When this bit
    > is not set, it indicates that this node may be under provisioned, or
    > may have no additional slots for additional nodes.  This could make
    > this node more interesting to an attacker.

    > nit: this phrasing suggests that the list is an exhaustive list of
    > reasons why the flag could be unset; I'd suggest "it might indicate"
    > instead.

agreed.

    >       This value MUST be ignored by pledges, it is to help enrolled
    > devices only to compare different connection points.

    > nit: comma splice.  Maybe also reword to "It is only to help enrolled
    > devices to compare different connection points"?

fixed.

    >       This field communicates an Interface ID bits that should be used
    > for this nodes' layer-3 address, if it should not be derived from

    > nit: singular/plural mistmatch in "an Interface ID bits" nit:
    > s/nodes'/node's/

done.

    >       the layer-2 address.  Communication with the Join Proxy occurs in
    > the clear, this field avoids the need for an additional service
    > discovery process for the case where the L3 address is not derived from
    > the L2 address.  An attacker will see both L2 and L3

    > nit: comma splice.  I'd also hyphenate "service-discovery".

fixed.

    >       once.  That is just a suggestion for a default algorithm: it may
    > be set in any convenience way that results in a non-identifing value.
    > In some LLNs where multiple PANIDs may lead to the same

    > nits: I suggest "Per [RFC6550], that is just a suggestion",
    > s/convenience/convenient/, and s/identifing/identifying/ (though what
    > exactly it is that is not being identified might be worth clarifying,
    > too).

network ID is new, it's not in RFC6550.
DODAGID is though.

    >       management device (the JRC), then a common value that is the same
    > across all PANs MUST be configured so that pledges that attempt to

    > nit: I think "all the PANs" is more appropriate, since we only care
    > about the ones that lead to the same JRC (and there may be other PANIDs
    > in play).

okay.

    >       enroll do not waste time attempting multiple times with the same
    > network that has multiple attachment points.

    > nit: I'd consider expanding (again) what is being attempted.

Rewritten to:

In some LLNs where multiple PANIDs may lead to the same management device
(the Join Registrar/Coordinator - JRC), then a common value that is the same across all the PANs MUST be
configured.
Pledges that see the same networkID will not waste time
attempting to enroll multiple times with the same network that when the network has multiple attachment points.


    >       If the network ID is derived as suggested, then it will an
    > opaque,

    > nit: s/will/will be/

okay

    >       seemingly random value, and will reveal nothing in of itself.  An

    > I suggest "will not directly reveal any information about the network".

edited.

    > Section 3

    >    The sensitivity of each field is describe within the description of
    > each field.

    > nit: s/describe/described/

    >    visible.  Encrypting the schedule does not prevent an attacker from
    > jamming, but rather increases the energy cost of doing that jamming.

    > Perhaps also the side effects/collateral damage of the jamming.

I'm not sure what you are saying/suggesting here.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-