Re: [6tisch] Thomas' review of draft-richardson-6tisch-enrollment-enhanced-beacon-00

[Thomas Watteyne <[e-mail]>]

one more editorial comment: the header says "6lo". typo or on purpose? The
draft name suggests 6TISCH.

On Sun, Mar 4, 2018 at 5:10 PM, Thomas Watteyne <[e-mail]>
wrote:

> co-chair hat off.
>
> The draft is easy to understand and to follow.
>
> The main recommendation I have is that the rationale/context is VERY
> poorly introduced. The abstract and intro discuss the fact that a node
> cannot send many EBs, but the actual contents of the draft is something
> COMPLETELY different, which is pretty much orthogonal to the statement inf
> the abstract/intro. This spec simply defines an IE that goes into EBs and
> which contains a number of priorities. AFAICT, that is information that is
> used for a pledge to make an informed decision about (1) which LLN to join
> and (2) which proxy to pick.
>
> I imagine the use case is a super dense network in which a pledge hears
> may different LLNs. Without this spec, some other LLN selection mechanisms
> can be imagined (PANID being the obvious one). This spec prevents the
> pledge from trying every LLN until it find the best one.
>
> None of that discussion is anywhere in the draft. My recommendatoins are:
>
>    - give that IE a name
>    - rename the draft the name you just chose
>    - rewrite the intro entirely, drop all the talk about the slow rate of
>    EBs, and justify what it is you're trying to define.
>    - in particular, describe in plain English how a node picks the proxy,
>    pan and rank priorities, and what rule a pledge has when selecting a JP
>    based on that info. Rewriting the intro will already be a good step forward
>    in proving the relevance of the work, but I'm anticipating a lot of
>    pushback if the logictics behind picking these numbers aren't clearly
>    stated.
>
> Bellow is the draft contents with my annotations, starting with "TW>"
>
> Thomas
>
> ===
>
> 6lo Working Group                                             D. Dujovne
> Internet-Draft                                Universidad Diego Portales
> Intended status: Informational                             M. Richardson
> Expires: August 12, 2018                        Sandelman Software Works
>                                                        February 08, 2018
>
> TW> looks like Diego is editor (from the authors addresses section)
> TW> I'm surprised his name at the top doesn't contain the usual ", Ed."
> TW> annotation.
> TW> also, wouldn't this mean a renaming of the doc to
> TW> draft-dujovne-6tisch-enrollment-enhanced-beacon-00?
>
>   IEEE802.15.4 Informational Element encapsulation of 6tisch Join and
>                          Enrollment Information
>          draft-richardson-6tisch-enrollment-enhanced-beacon-00
>
> Abstract
>
>    In TSCH mode of IEEE802.15.4,
> TW> In *the* TSCH
>    as described by [RFC8180],
>    opportunities for broadcasts are limited to specific times and
>    specific channels.
> TW> I don't fully understand this sentence. What makes opportunities
> TW> limited? The number of broadcast timeslots?
>    Nodes in a TSCH network typically frequently send
>    Enhanced Beacon (EB) frames to announce the presence of the network.
>    This document provides a mechanism by which small details critical
>    for new nodes (pledges) and long sleeping nodes may be carried within
>    the Enhanced Beacon.
> TW> I would simplify this abstract to basically a single sentence
> TW> "This document defines the X and Y that are carried in Enhanced
> TW> Beacon (EB) frames to allow Z."
>
> Status of This Memo
>
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    This Internet-Draft will expire on August 12, 2018.
>
> Copyright Notice
>
>    Copyright (c) 2018 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
>
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>    (http://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with respect
>
>
>
> Dujovne & Richardson     Expires August 12, 2018                [Page 1]
> Internet-Draft                IE for ICMPv6                February 2018
>
>
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the Simplified BSD License.
>
> Table of Contents
>
>    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
>      1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
>      1.2.  Layer-2 Synchronization . . . . . . . . . . . . . . . . .   3
>      1.3.  Layer-3 synchronization IPv6 Router solicitations and
>            advertisements  . . . . . . . . . . . . . . . . . . . . .   3
>    2.  Protocol Definition . . . . . . . . . . . . . . . . . . . . .   4
>      2.1.  Protocol Example  . . . . . . . . . . . . . . . . . . . .   5
>    3.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
>    4.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   5
>    5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
>    6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
>    7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
>      7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
>      7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
>    Appendix A.  Change history . . . . . . . . . . . . . . . . . . .   7
>    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7
>
> 1.  Introduction
>
>    [RFC7554] describes the use of the time-slotted channel hopping
>    (TSCH) mode of [ieee802154].  As further details in [RFC8180], an
>    Enhanced Beacon is transmitted during a slot designated a broadcast
>    slot.
>
>    EDNOTE: Explain why broadcasts are rare, and why we need them.  What
>    the Enhanced Beacon is, and what Information Elements are, and how
>    the IETF has a subtype for that area.  Explain what kind of things
>    could be placed in Information Elements, how big they could be, and
>    how they could be compressed.
> TW> also talk about encryption of IEs.
>
> 1.1.  Terminology
>
>    In this document, the key words "MUST", "MUST NOT", "REQUIRED",
>    "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
>    and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
>    [RFC2119] and indicate requirement levels for compliant STuPiD
>    implementations.
> TW> STuPiD implementations? I need to know more about that!
>
>
>
>
>
>
>
> Dujovne & Richardson     Expires August 12, 2018                [Page 2]
> Internet-Draft                IE for ICMPv6                February 2018
>
>
> 1.2.  Layer-2 Synchronization
>
>    As explained in section 6 of [RFC8180], the Enhanced Beacon has a
>    number of purposes:
> TW> "has a number of purposes" is too vague IMO. I suggest to rephrase
> TW> to something like:
> TW> the Enhanced Beacon allows a pledge to detect the presence of the
> TW> network, and learn enough about the configurations of the network
> TW> to start joining the network, if it wishes to do so.
>    synchronization of ASN and Join Metric, timeslot
>    template identifier, the channel hopping sequence identifier, TSCH
>    SlotFrame and Link IE.
>
>    The Enhanced Beacon (EB) is used by nodes already part of a TSCH
>    network to annouce its existance.
> TW> typo
>    Receiving an EB allows a Joining
>    Node (pledge)
> TW> the term JN disappeared, just use pledge throughout
>    to learn about the network and synchronize to it.  The
>    EB may also be used as a means for a node already part of the network
>    to re-synchronize [RFC7554].
>
>    There are a limited number of timeslots designated as a broadcast
>    slot by each router.  These slots are rare, and with 10ms slots, with
>    a slot-frame length of 100,
> TW> I would use the example slotframe length from RFC8180, which is 101
>    there may be only 1 slot/s for the
>    beacon.
>
> 1.3.  Layer-3 synchronization IPv6 Router solicitations and
>       advertisements
>
>    At layer 3, [RFC2461] defines a mechanism by which nodes learn about
>    routers by listening for multicasted
> TW> multicasted -> multicast ?
>    Router Advertisements (RA).  If
>    no RA is heard within a set time, then a Router Solicitation (RS) may
>    be multicast, to which an RA will be received, usually unicast.
>
>    Although [RFC6775] reduces the amount of multicast
> TW> multicast*s*
>    necessary to do
>    address resolution via Neighbor Solicitation messages, it still
>    requires multicast of either RAs or RS.  This is an expensive
>    operation for two reasons: there are few multicast timeslots for
>    unsolicited RAs; if a pledge node does not hear an RA, and decides to
>    send a RS (consuming a broadcast aloha slot with unencrypted
>    traffic), many unicast RS may be sent in response.
>
>    This is a particularly acute issue for the join process for the
>    following reasons:
>
>    1.  use of a multicast slot by even a non-malicious unauthenticated
>        node for a Router Solicitation may overwhelm that time slot.
>
>    2.  it may require many seconds of on-time before a new pledge hears
>        a Router Soliciation
> TW> typo
>        that it can use.
>
>    3.  a new pledge may listen to many Enhanced Beacons before it can
>        pick an appropriate network and/or closest Join Assistant
> TW> JA -> JP
>        attach to.  If it must listen for a
> TW> an
>        RS as well as find the
>        Enhanced Beacon, then the process may take a very long time.
>
>
>
>
> Dujovne & Richardson     Expires August 12, 2018                [Page 3]
> Internet-Draft                IE for ICMPv6                February 2018
>
>
> 2.  Protocol Definition
>
>    [RFC8137] creates a registry for new IETF IE subtypes.  This document
>    allocates a new subtype TBD-XXX.
>
>    This document documents
> TW> document documents reads strange -> defines?
>    a new IE subtype structure is
> TW> remove is"
>    as follows.  As
>    explained in [RFC8137] the length of the Sub-Type Content can be
>    calculated from the container, so no length information is necessary.
>
>                         1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   TBD-XXX     |R|pan priority |proxy prio.  | rank prio.      |
>    +-+-+-+-+-+-+-+-+-+-------------+-------------+-----------------+
>    |                                                               |
>    +                                                               +
>    |                           network ID                          |
>    +                                                               +
>    |                                                               |
>    +                                                               +
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> TW> please put the description of the fields in the same order as the
> TW> fields themselves.
>
>    proxy priority  the proxy prority value contains a number from 0 to
>       0x7f.  Lower numbers are considered to be a higher preference.  A
>       priority of 0x7f indicates that the announcer should never be
>       considered as a viable enrollment proxy.  Lower value indicates
>       willing to act as a Join Proxy as described in
>       [I-D.ietf-6tisch-minimal-security].  Only unenrolled
> TW> unenrolled -> un-enrolled (please look for the same everywhere)
>       pledges look
>       at this value.
> TW> can you give us a hint at how this proxy priority would be managed?
> TW> what's the rationale behind its use?
> TW> for sure, this should be described much earlier on in this spec.
>
>    pan priority  the pan priority is a value set by the 6LBR to indicate
>       the relative priority of this LLN compared to those with different
>       PANIDs.  This value may be used as part of the enrollment
>       priority, but typically is used by devices which have already
>       enrolled, and need to determine which PAN to pick.
> TW> what is your definition of enrollment? AFAICT, a pledge is not enrolled
> TW> picks an LLN, and joins that. I don't see a case where a node is
> TW> enrolled but not joined to an LLN.
>       Unenrolled
>       pledges MAY consider this value when selecting a PAN to join.
>       Enrolled devices MAY consider this value when looking for an
>       elegible
> TW> eligible
>       parent device.
>
>    rank priority  the rank priority is set by the 6LR which sent the
>       beacon and is an indication of how willing this 6LR is to serve as
>       an RPL parent within a particular network ID.  This is a local
>       value to be determined in other work.  It might be calculated from
>       RPL rank, and it may include some modifications based upon current
>       number of children, or number of neighbor cache entries available.
>       This value MUST be ignored by pledges, it is for enrolled devices
>       only.
> TW> I fail to understand the difference between proxy priority and
> TW> rank priority. I understand the fact that each deals with a different
> TW> part of the stack (proxying vs routing), but in the end, a pledge
> TW> receives an EB which says "pick me", or "don't pick me". What happens
> TW> if a pledge receives an EB with a low proxy priority but no
> TW> rank priorioty? Again, the intro needs to put more context and
> TW> justification of why this is an important problem to solve.
>
>
>
>
> Dujovne & Richardson     Expires August 12, 2018                [Page 4]
> Internet-Draft                IE for ICMPv6                February 2018
>
>
>    R  the Router Advertisement flag is set if the sending node will act
>       as a Router for host-only nodes that need addressing via unicast
>       Router Solicitation messages.
> TW> please specify what a sender means when not setting that flag.
>
>    network ID  this is an opaque 16-byte identifier that uniquely
>       identifies this network, potentially among many networks that are
>       operating in the same frequencies in overlapping physical space.
>
>    In a 6tisch
> TW> 6TiSCH (casing)
>    network, where RPL is used as the mesh routing protocol,
>    the network ID can be constructed from a SHA256 hash of the prefix
>    (/64) of the network.  That is just a suggestion for a default value.
>    In some LLNs where multiple PANIDs may lead to the same management
>    device (the JRC), then a common value that is the same across all
>    PANs MUST be configured.
>
> 2.1.  Protocol Example
>
>    Here will be three examples of processing.
> TW> please put a clear "TODO" statement. I took me a second to parse what
> TW> you meant. If you're saying 3 examples, justify why 3, and ideally
> TW> which ones. If 3 is just a magic value, just put "TODO".
>
> 3.  Security Considerations
>
>    All of the contents of this Information Element are sent in the
>    clear.  The containing Enhanced Beacon is not encrypted.
>
>    The Enhanced Beagon
> TW> beacon
>    is authenticated at the layer-2 level using
>    802.15.4 mechanisms using the network-wide keying material.  Nodes
>    which are enrolled will have the network-wide keying material and can
>    validate the beacon.
>
>    Pledges which have not yet enrolled are unable to authenticate the
>    beacons.
> TW> you are describing the "mechanics" of which, easy to follow.
> TW> but I was expected some form of conclusion about security, e.g.
> TW> "this is no problem because X", or "this makes the system
> TW> vulnerable to Y, but Z".
>
> 4.  Privacy Considerations
>
>    The use of a network ID may reveal information about the network.
>    The use of a SHA256 hash of the DODAGID, rather than using the
>    DODAGID directly provides some cover
> TW> "for"? looks like a word is missing.
>    the addresses used within the
>    network.  The DODAGID is usually the IPv6 address of the root of the
>    RPL mesh.
>
>    An interloper with a radio sniffer would be able to use the network
>    ID to map out the extend of the mesh network.
>
> 5.  IANA Considerations
>
>    Allocate a new number TBD-XXX from Registry IETF IE Sub-type ID.
>    This entry should be called 6tisch-Join-Info.
>
>
>
>
> Dujovne & Richardson     Expires August 12, 2018                [Page 5]
> Internet-Draft                IE for ICMPv6                February 2018
>
>
> 6.  Acknowledgements
> TW> Acknowledgment
>
>    Thomas Watteyne provided extensive editorial comments on the
>    document.
> TW> did I? it's a -00.
>
> 7.  References
>
> 7.1.  Normative References
>
>    [I-D.ietf-6tisch-architecture]
>               Thubert, P., "An Architecture for IPv6 over the TSCH mode
>               of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work
>               in progress), November 2017.
>
>    [I-D.ietf-6tisch-minimal-security]
>               Vucinic, M., Simon, J., Pister, K., and M. Richardson,
>               "Minimal Security Framework for 6TiSCH", draft-ietf-
>               6tisch-minimal-security-04 (work in progress), October
>               2017.
>
>    [ieee802154]
>               IEEE Standard, ., "802.15.4-2015 - IEEE Standard for Low-
>               Rate Wireless Personal Area Networks (WPANs)", 2015,
>               <http://standards.ieee.org/findstds/
>               standard/802.15.4-2015.html>.
>
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119,
>               DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
>               editor.org/info/rfc2119>.
>
>    [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
>               Discovery for IP Version 6 (IPv6)", RFC 2461,
>               DOI 10.17487/RFC2461, December 1998, <https://www.rfc-
>               editor.org/info/rfc2461>.
>
>    [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
>               Bormann, "Neighbor Discovery Optimization for IPv6 over
>               Low-Power Wireless Personal Area Networks (6LoWPANs)",
>               RFC 6775, DOI 10.17487/RFC6775, November 2012,
>               <https://www.rfc-editor.org/info/rfc6775>.
>
>    [RFC7554]  Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
>               IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
>               Internet of Things (IoT): Problem Statement", RFC 7554,
>               DOI 10.17487/RFC7554, May 2015, <https://www.rfc-
>               editor.org/info/rfc7554>.
>
>
>
>
> Dujovne & Richardson     Expires August 12, 2018                [Page 6]
> Internet-Draft                IE for ICMPv6                February 2018
>
>
>    [RFC8137]  Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information
>               Element for the IETF", RFC 8137, DOI 10.17487/RFC8137, May
>               2017, <https://www.rfc-editor.org/info/rfc8137>.
>
> 7.2.  Informative References
>
>    [I-D.ietf-6tisch-dtsecurity-secure-join]
>               Richardson, M., "6tisch Secure Join protocol", draft-ietf-
>               6tisch-dtsecurity-secure-join-01 (work in progress),
>               February 2017.
>
>    [RFC8180]  Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal
>               IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH)
>               Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180,
>               May 2017, <https://www.rfc-editor.org/info/rfc8180>.
>
> Appendix A.  Change history
> TW> please add a marker (e.g. "[TEMPORARY]") to indicate this section
> TW> is not going to be there when the document is finished.
>
>    The extension was originally for the use of Pledges only during the
>    enrollment/join process.  Additional information was desired for
>    nodes which have already enrolled in order to aid in the joining
>    (selecting of a parent) of an RPL DAG.  The term "join" was realized
>    to be ambiguous, meaning different things to different groups, and so
>    the activity where the pledge finds a "Join Proxy" has been named
>    "enrollment"
> TW> the information is this paragraph should be at the very top of the
> TW> spec...
>
>    This is an evolution of an earlier proposal which provided for
>    storing an entire IPv6 Router Adverisement in an Informational
>    Element.  It was deemed too general a solution, possibly subject to
>    mis-use.  This proposal restricts the use to just the key pieces of
>    information required.
>
> Authors' Addresses
>
>    Diego Dujovne (editor)
>    Universidad Diego Portales
>    Escuela de Informatica y Telecomunicaciones, Av. Ejercito 441
>    Santiago, Region Metropolitana
>    Chile
>
>    Phone: [phone]
>    Email: [e-mail]
>
>
>    Michael Richardson
>    Sandelman Software Works
>
>    Email: [e-mail]
>
>
>
> Dujovne & Richardson     Expires August 12, 2018                [Page 7]
>
>


-- 
________________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Analog Devices
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
________________________________________