Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Benjamin:

Many thanks for your in depth review of the draft, this is really appreciated.

Please see below:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Section 4.3.4 asserts:
> 
>    [...]                                      We'll note that the Join
>    Priority is now specified between 0 and 0x3F leaving 2 bits in the
>    octet unused in the IEEE Std. 802.15.4e specification.  After
>    consultation with IEEE authors, it was asserted that 6TiSCH can make
>    a full use of the octet to carry an integer value up to 0xFF.
> 
> I'm extremely reluctant to publish this text in the IETF stream without a citation.
> 
> 
> I also think there are more topics that need to be covered in the security
> considerations (see Comment, and not just the Section-6 portions), especially
> with respect to the reliance on the link-layer security mechanism and its
> network-wide shared key.
> 

PT> We checked on a separate thread and the latest 802.15.4 aligned to our requirements and made it a full byte, so we're all good and I removed the sentence altogether.


> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> [The shepherd writeup's answer for the question about "why is this the proper
> type of RFC" did not change when the intended status changed from Proposed
> Standard to Informational, which would have been nice to see recorded.]
> 

PT> agreed. Did the IESG discuss on what's the best track for this document?


> It would be good to see some architectural discussion about key management
> for the link-layer keys.  (Given that 802.15.4 leaves key management as out of
> scope, it is clearly our problem.)  Thus far I don't even have a sense for when it is
> possible to rotate a network's keys.
> 

PT> I took that to a separate thread with Michael, Tero and Malisa. It is certainly possible to rotate keys with minimal security. The tooling for peer-wise keys is also there. 
PT> We isolated cases where this is desirable in the discussion on the minimal security draft. I'm unclear how deep we need to go in this regards vs what belongs to the minimal security specification.
PT> I'm seeing reluctance in adding yet new text to the architecture, when minimal security is the central repository.
 
PT> Proposed text:

"
   Though it is possible to use peer-wise keys, a 6TiSCH network
   typically uses a network-wide key that is common for all
   transmissions in the LLN.  [I-D.ietf-6tisch-minimal-security] enables
   to obtain that key and to rekey the network when needed.  Since the
   ASN is expressed in 5 octets, it should never wrap during a network
   lifetime, and it is possible that a network never needs to rekey.
   Still, there are occasions where rekeying is necessary, for instance:

   o  An unwelcome node has joined and needs to be expelled

   o  The JRC needs to reassign a short address that was already
      assigned while the current network key was in use.

   o  Any action that may cause ASN to reuse a past value, e.g.,
      resetting Epoch time when rebooting the network.
"

> I'd like to see some discussion somewhere that the Join Proxy needs to take care
> to not be an open redirector by which an unauthenticated pledge can attack
> arbitrary network elements (whether within the LLN or on the broader
> network), e.g., by performing some validation on the claimed MASA identifier.
> Similarly, that the JRC will be exposed to lots of untrusted input and needs to be
> implemented in an especially robust manner.
> 

PT> I took that to a separate thread as well. People tend to defer that discussion to the minimal security draft.

I made the minimal security draft a normative reference and suggest to add:
"
   The reader is encouraged to review the security section of
   [I-D.ietf-6tisch-minimal-security], which discusses 6TiSCH security
   issues in more details.
"
Also added a discussion on protecting the path to the JRC as we already did for the PCE:
"
   In a similar manner, the communication with the
   JRC must be secured and should be protected against DoS attacks when
   possible.
"


> In some qualitative sense that's hard to describe, this document feels like a
> mash-up of two or maybe three different documents written at different levels
> of abstraction.  I don't know if it's even worth considering trying to tease them
> apart, though.
> 

PT> this was  a conscious decision since the early review by Ralph. We split the document in a high and a low level architecture and kept them combined to avoid the explosion of documents. For the same reason, we later incorporated the terminology that was initially a separate spec.
PT> As a result this draft has 2/3 documents in one, with commonalities in section 3.4 and 4.4 for instance. That's where we are and as you say, there is no fundamental new reason to undo that.


> Section 2.1
> 
>    Layer-2 vs. Layer-3 bundle:  Bundles are associated for either
>                Layer-2 (switching) or Layer-3 (routing) forwarding
>                operations.  A pair of Layer-3 bundles (one for each
>                direction) maps to an IP Link with a neighbor, whereas a
>                set of Layer-2 bundles (a number per neighbor, either
>                from or to the neighbor) corresponds to the relation of
>                one or more incoming bundle(s) from the previous-hop
>                neighbor(s) with one or more outgoing bundle(s) to the
>                next-hop neighbor(s) along a Track.
> 
> What does "a number per neighbor" mean? That the "set of Layer-2 bundles"
> can have "arbitrary" cardinality and be partitioned arbitrarily between an
> incoming neighbor and an outgoing neighbor as part of the switching role?

PT > The intent was to say that there can be more than one bundle with a neighbor, and that a bundle can be in either direction.
As opposed to the routing case, there can be (DetNet / RAW style) ARQ, replication and elimination which cause a different number of incoming and outgoing transmission resources.

Proposed rewrite:

"
   Layer-2 vs. Layer-3 bundle:  Bundles are associated for either
               Layer-2 (switching) or Layer-3 (routing) forwarding
               operations.  A pair of Layer-3 bundles (one for each
               direction) maps to an IP Link with a neighbor, whereas a
               set of Layer-2 bundles (of an "arbitrary" cardinality and
               direction) corresponds to the relation of one or more
               incoming bundle(s) from the previous-hop neighbor(s) with
               one or more outgoing bundle(s) to the next-hop
               neighbor(s) along a Track as part of the switching role,
               which may include replication and elimination.
"

> 
> "PDR" seems to currently get defined at its second (last!) use, not the first use.
> 

PT> Fixed


>    scheduled cell:  A cell which is assigned a neighbor MAC address
>                (broadcast address is also possible), and one or more of
>                the following flags: TX, RX, shared, timeskeeping.  A
> 
> "timeskeeping" does not seem to be defined anywhere.

PT> Taïpo, fixed to timekeeping : )


> 
> Section 3.2
> 
> In Figure 2, why is the 6LBR "off to the side" and not on the boundary interface
> of anything?

PT> On Fig 2, the optional 6LBR is connected to the backbone. I clarified the text below to  adding "optional" before 6LBR and pointing on the figure:
"

   The use of multicast can also be reduced on the backbone with a
   registrar that would contribute to Duplicate Address Detection as
   well as Address Lookup using only unicast request/response exchanges.
   [I-D.thubert-6man-unicast-lookup] is a proposed method that presents
   an example of how to this could be achieved with an extension of
   [RFC8505], using an optional 6LBR as a SubNet-level registrar, as
   illustrated in Figure 2. "

> 
>    The use of multicast can also be reduced on the backbone with a
>    registrar that would contribute to Duplicate Address Detection as
>    well as Address Lookup using only unicast request/response exchanges.
>    [I-D.thubert-6lo-unicast-lookup] is a proposed method that presents
>    an example of how to this could be achieved with an extension of
>    [RFC8505], using a 6LBR as a SubNet-level registrar.
> 
> How speculative is this reference?

PT> The draft has moved to 6MAN, where it is not adopted yet. It is still truly a proposed method for achieving this.


> 
>    As detailed in Section 4.1 the 6LBR that serves the LLN and the root
>    of the RPL network needs to share information about the devices that
>    are learned through either protocol but not both.  The preferred way
> 
> What are the two protocols involved in "either protocol but not both"?

PT> Changed to "that are learned through either 6LoWPAN ND or RPL but not both."

> 
> Section 3.4
> 
>    channel at any point of time.  Scheduled cells that play an equal
>    role, e.g., receive IP packets from a peer, are grouped in bundles.
> 
> nit: I'd suggest s/play an equal/fulfil the same/

PT| done

> 
>    Neighbor-to-Neighbor Scheduling:  This refers to the dynamic
>       adaptation of the bandwidth of the Links that are used for IPv6
>       traffic between adjacent routers.  Scheduling Functions such as
>       the "6TiSCH Minimal Scheduling Function (MSF)"
>       [I-D.ietf-6tisch-msf] influence the operation of the MAC layer to
>       add, update and remove cells in its own, and its peer's schedules
>       using 6P [RFC8480], for the negotiation of the MAC resources.
> 
> nit(?): is this "in its own schedule"?

PT| unsure I understand the question. The 6P protocol enables a node to negotiate cells, so a parent actually makes changes in the child's schedule.

> 
> Section 3.7
> 
> In Figure 4, what does "Applis" stand for?  It does not appear anywhere else in
> the document.

PT > Well, that's the applications whatever they are. Should I remove the block ?

> 
>    RPL is the routing protocol of choice for LLNs.  So far, there was no
>    identified need to define a 6TiSCH specific Objective Function.  The
>    Minimal 6TiSCH Configuration [RFC8180] describes the operation of RPL
>    over a static schedule used in a slotted aloha fashion, whereby all
> 
> RFC 8100 does not use the term "slotted aloha", and neither usage in this
> document provides an alternative reference or definition.

RFC 7554 mentions it but does not provide a reference. I added one here.

"
   [S-ALOHA]  Roberts, L. G., "ALOHA Packet System With and Without
              Slots and Capture", doi 10.1145/1024916.1024920, April
              1975, <https://dl.acm.org/citation.cfm?id=1024920>.
"

> 
> Section 3.8
> 
>    information that is being exchanged.  In contrast, an Interaction
>    Models would be more refined and could point on standard operation
> 
> nit: I suggest s/point on/point to/
> 

PT> done

> Section 4.1.1
> 
> DAO should probably be expanded somewhere.

PT> done on first use

> 
>    The RPL InstanceID that the leaf wants to participate to may be
>    signaled in the Opaque field of the EARO.  On the backbone, the
> 
> Any (informational) reference as to how?

Reworded the sentence to indicate that:
"

   [I-D.ietf-roll-unaware-leaves] also enables the leaf to signal the
   RPL InstanceID that it wants to participate to using the Opaque field
   of the EARO.  
"

> 
> Section 4.2.1
> 
> It's worrisome to see all the excitement around reusing BRSKI without clear
> evidence that the assumptions made in core BRSKI are being revalidated for the
> new use cases.  (I thought I had even noted such an assumption that merited a
> closer look in my ballot position on BRSKI, but I can't find it right now amongst
> the 1500 lines.)

Well we have been working on this for a very long time, had a design team etc.
See https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join/ and https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/ 


> 
> Please document somewhere that "@" is used as an abbreviation for "address"
> in Figure 5.

PT> fixed the figure not to use @

> 
> Section 4.2.2
> 
> I can't tell what the "<once>" in  Figure 6 is intended to refer to.
> Is it the whole figure?
> 

Removed the <once> and added text
"
   Figure 6 illustrates the initial IPv6 signaling that enables a 6LN to
   form a global address and register it to a 6LBR using 6LoWPAN ND
   [RFC8505], is then carried over RPL to the RPL root, and then to the
   6BBR.  This flow happens just once when the address is created and
   first registered.
"
Also
"
   Section 7 of [I-D.ietf-roll-unaware-leaves] specifies how the DAO
   messages are used to reconfirm the registration, thus eliminating a
   duplication of functionality between DAO and EDAR/EDAC messages, as
   illustrated in Figure 7.
"

>    to keep a global address alive and registered to its 6LBR using
>    6LoWPAN ND [RFC8505], using 6LoWPAN ND ot the 6LR, RPL to the RPL
> 
> nit: s/ot/to/
> Also, do we need to say "using 6LoWPAN ND" twice?
> 

PT> all cleaned up


> Section 4.3.1.1
> 
> There seems to be a duplicated source line in here.
> 

PT> cleaned up

> Section 4.3.4
> 
>    Time distribution requires a loop-free structure.  Nodes taken in a
>    synchronization loop will rapidly desynchronize from the network and
>    become isolated.  It is expected that a RPL DAG with a dedicated
>    global Instance is deployed for the purpose of time synchronization.
> 
> The "it is expected" language is confusing.  Is the TSGI part of the architecture, a
> common way to provide functionality assumed by the architecture, or
> something  else?

It is part of the architecture. Changed text to
"
6TiSCH uses a RPL DAG with a dedicated global Instance
for the purpose of time synchronization.
"

> 
>    A root is configured or obtains by some external means the knowledge
>    of the RPLInstanceID for the TSGI.  The root advertises its DagRank
> 
> To what extent will the RPL root be known advance as opposed to determined at
> runtime by the protocol execution?

PT> Added text before as follows:
"
   The provisioning of a RPL Root is out of scope for both RPL and this
   Architecture, whereas RPL enables to propagate configuration
   information down the DODAG.  This applies to the TSGI as well; a Root
   is configured or obtains by unspecified means the knowledge of the
   RPLInstanceID for the TSGI. "

> 
> Section 4.3.6
> 
> Is the division of the CDU matrix into chunks something expected to be
> conveyed during the join process, or provisioned at device manufacture, or
> codified into a profile document, or some other mechanism?  (Is this different
> from "static scheduling"?)

PT> This is unspecified and all of the above would work. Can I steal your text?
Some cells can be blocked for static scheduling and others can be assigned to chunks and managed by MSF.
The static scheduling is really hardcoded, with minimal parametrization from the beacon, so it does not need to disseminate a knowledge of chunks (see 6tisch minimal support).
Added:

"
The knowledge of this
   formatting is shared between all the nodes in a 6TiSCH network.  It
   could be conveyed during the join process, or codified into a profile
   document, or obtained using some other mechanism.  This is as opposed
   to static scheduling that refers to the pre-programmed mechanism that
   is specified in [RFC8180] and pre-exists to the distribution of the
   chunk formatting. "

> 
>    The 6TiSCH Architecture expects that a future protocol will enable a
>    chunk ownership appropriation whereby a RPL parent discovers a chunk
> 
> The writing here is pretty speculative.  Maybe "envisions a protocol that enables
> chunk ownership appropriation" is better?
> 

PT> it is. I made the change


> Section 4.4
> 
> The descriptions here seems to have high overlap with Section 3.4; can we
> deduplicate anything?
> 

PT> Ouch. There was a desire to make that section self-sufficient, with the idea of possibly splitting section 3 and 4 which we never did. Still it might be useful to the reader who just reads that section.
And there was a desire to have a discussion at the high level architecture on this topic so removing 3.4 is not good either.

Bottom line is I'll make a separate pass on this to reassess, but it is really really late ater all the IESG reviews we already had and the structure changes we made. I'm quite afraid to destabilize the document by doing a major change like here.


> Section 4.4.4
> 
>    This hop-by-hop reservation mechanism is expected to be similar in
>    essence to [RFC3209] and/or [RFC4080]/[RFC5974].  The protocol for a
>    node to trigger hop-by-hop scheduling is not yet defined.
> 
> For some reason this text feels much less speculative than the one I quoted from
> Section 4.3.6.

PT> probably because we have seen drafts on that. But we never chartered for it and the work went stale.
So we know we have 6P to reserve the cells on one hop, all we need is a protocol that says to do so over multiple hops.
We know of RSVP, and we know of AODV-RPL. The steps to get to a solution are not gigantic.

> 
> Section 4.5.1
> 
>    Multiple cells may be scheduled in a Track for the transmission of a
>    single packet, in which case the normal operation of IEEE Std.
>    802.15.4 Automatic Repeat-reQuest (ARQ) can take place; the
>    acknowledgment may be omitted in some cases, for instance if there is
>    no scheduled cell for a possible retry.
> 
> Are there security consequences of having to omit the ack/retry?  

PT> No Ack means no time sync when going up. I do not see a security implication though.

> Will the  sender know in advance if this is the case?

PT> In the given example of a scheduled cell it will, yes.

> 
>    4.  Tracks are protected from interfering with one another if a cell
>        belongs to at most one Track, and congestion loss is avoided if
>        at most one packet can be presented to the MAC to use that cell.
>        Tracks enhance the reliability of transmissions and thus further
>        improve the energy consumption in LLN Devices by reducing the
>        chances of retransmission.
> 
> How might these properties (cell belongs to at most one Track, at most one
> packet presented to the MAC to use that cell) be achieved?

Tracks are scheduled, so it up to the PCE to arrange that. I modified the text to insist on that as follows:

"

   Tracks are protected from interfering with one another if a cell
  is scheduled to belong to at most one Track, and congestion loss
  ... 
"

> 
> Section 4.5.2
> 
> Do we want to note (again) that setting up this forwarding state costs energy
> since the radio will be active for all scheduled cells, or is that too much
> repetition?
> 

PT> well, for someone in the art, this could rapidly get boring.
Also, RAW will be working on technique to actually not use the full set of (redundant) scheduled cells along a Track.

>    For a given iteration of the device schedule, the effective channel
>    of the cell is obtained by adding a pseudo-random number to the
>    channelOffset of the cell, which results in a rotation of the
>    frequency that used for transmission.
> 
> I'm not sure that I understand how this works.
> 
Maybe change to:
"
  For a given iteration of the device schedule, the effective channel
  of the cell is obtained by following in a loop a well-known hopping sequence that
  started at Epoch time at the channelOffset of the cell, which results
  in a rotation of the frequency that used for transmission.

"

> Section 4.5.3
> 
> Where is PRE defined?

PT > In DetNet : ) it is now PREOF. Added text and changed use of PRE as follows

"
    This enables the Packet Replication, Elimination and Ordering Functions (PREOF)
    defined by Detnet. Packet ARQ, Replication, Elimination and Overhearing (PAREO)
    adds radio-specific capabilities of Layer-2 ARQ and promiscuous listening to 
    redundant transmissions to compensate for the lossiness of the medium and
    meet industrial expectations of a Reliable and Available Wireless (RAW) network. 

> 
> Section 4.5.5
> 
>    It results in a frame that is received in a RX-cell of a Track with a
>    destination MAC address set to this node as opposed to broadcast must
>    be extracted from the Track and delivered to the upper layer (a frame
>    with an unrecognized destination MAC address is dropped at the lower
>    MAC layer and thus is not received at the 6top sublayer).
> 
> I don't think this is a well-formed sentence (somewhere around "as opposed to
> broadcast"?).  The parenthetical should probably be its own sentence, even if it
> remains in parentheses.
> 

PT> Agreed. What about:
"
        It results in a frame that is received in a RX-cell of a Track with a
        destination MAC address set to this node as opposed to the broadcast MAC
        address must be extracted from the Track and delivered to the upper layer.
        Note that a frame with an unrecognized destination MAC address is dropped
        at the lower MAC layer and thus is not received at the 6top sublayer.
"


>    appropriate bundle if possible.  A frame should be re-Tracked if the
>    Per-Hop-Behavior group indicated in the Differentiated Services Field
>    of the IPv6 header is set to Deterministic Forwarding, as discussed
>    in Section 4.7.1.  A frame is re-Tracked by scheduling it for
> 
> I don't see anything about diffserv or deterministic forwarding in Section 4.7.1.

PT> The referred text was just removed, this is a leftover; great catch!
I removed that sentence too.

> 
> Section 4.6.1
> 
> It would be nice if the subsection order matched the list of the three different
> forwarding model[s].

PT> Done. The list now shows as

"
  6TiSCH supports
   three different forwarding model:(G-MPLS) Track Forwarding,
   (classical) IPv6 Forwarding and (6LoWPAN) Fragment Forwarding.
"
Per Eric's review, to also match the name of the following subsections more clearly.

> 
> Section 4.6.1.3
> 
>    address.  It is thus mandatory at the ingress point to validate that
>    the MAC address that was used at the 6LoWPAN sublayer for compression
>    matches that of the tunnel egress point.  For that reason, the node
>    that injects a packet on a Track checks that the destination is
>    effectively that of the tunnel egress point before it overwrites it
>    to broadcast.  [...]
> 
> What does it do if the check fails?

PT| The packet cannot be tunneled, the router is free to do whatever else it does based on its routes and policies.
I reworded a bit to make it more clear:
"

   If the Layer-3 destination address belongs to the tunnel termination,
   then it is possible that the IPv6 address of the destination is
   compressed at the 6LoWPAN sublayer based on the MAC address.
   Restoring the wrong MAC address at the egress would then also result
   in the wrong IP address in the packet after decompression.  For that
   reason, a packet can be injected in a Track only if the destination
   MAC address is effectively that of the tunnel egress point.  It is
   thus mandatory for the ingress router to validate that the MAC
   address that was used at the 6LoWPAN sublayer for compression matches
   that of the tunnel egress point before it overwrites it to broadcast.
   The 6top sublayer at the tunnel egress point reverts that operation
   to the MAC address obtained from the tunnel information.
"


> 
> Section 4.6.3
> 
> What are the security consequences of fragment forwarding vs. reassembly at
> each hop?  Are we assuming that only nodes granted a certain degree of trust
> are on the network (as we might be wont to do given the link-layer access
> control) to provide some protection against abuse?

PT> This discussion belongs to the security sections of the pointed drafts, ietf-6lo-minimal-fragment and  ietf-6lo-fragment-recovery. I also made them normative.
In a way, relates to the discussion on minimal security, and the desire not to duplicate the content of all the security sections of the normative references into this.
Now, to answer your point, I'm not clear on which attack vector you're looking at. It is not identified in the current versions of the drafts and I'd like to continue this discussion on a separate thread or during the sec-dir review of ietf-6lo-minimal-fragment.


> Section 4.7.1
> 
> The text here isn't quite enough for me to tease out whether the 6TiSCH
> Instance ID and the RPLInstanceID are the same thing or different.
> (In particular, the "location [...] must be the same" for the 6TiSCH one is hard to
> mesh with the RPL one being in an IPv6 hop-by-hop header.)

PT> I should have used only one wording. Thing is when we talk we say instance ID but that's always the one in RPL, there is no other.
Changed to RPLInstanceID throughout


> Section 4.7.2
> 
> "sequence number would be tagged in the packet for that purpose" is maybe a
> little heavier on jargon that it needs to be.
> 

PT> Changed " would be" to "is"


> Section 6
> 
> We might benefit from splitting this into a few subsections.

PT> Done, 
PT> This and the below result in a global change that is easier to consider globally. Please look at the result in -25 when published

> 
> We could potentially talk about the risk of external/unregulated interference
> breaking the deterministic guarantees of any wireless scheme, as a sufficiently
> motived (targetted) attacker could always effectively jam the legitimate
> communications.
> 

PT> Yes, PHY attacks are possible on anything wireless. This much is a bit obvious ot mention. More interesting is that such attack can be stealthy if it knows one cell used by the flow, because it can focus on jamming that cell over and over since the hopping sequence is well known, without impacting any other traffic.
This is taking us deep into IEEE land. We have a solution draft to obfuscate the hopping sequence, draft-tiloca-6tisch-robust-scheduling, but the problem is that it almost completely MAC layer.
Added 
"
   The Hopping Sequence of a TSCH network is well-known, meaning that if
   a rogue manages to identify a cell of a particular flow, then it may
   to selectively jam that cell, without impacting any other traffic.
   This attack can be performed at the PHY layer without any knowledge
   of the Layer-2 keys, and is very hard to detect and diagnose because
   only one flow is impacted.  [I-D.tiloca-6tisch-robust-scheduling]
   proposes a method to obfuscate the hopping sequence and make it
   harder to perpetrate that particular attack.
"

> I'd like to see some discussion about the threat model, in addition to the generic
> DetNet architecture.  Specifically, for TiSCH, we seem to be relying heavily on
> the link-layer security, which ends up being a group symmetric secret.  Thus, we
> rely on the join process to deny authorization of invalid nodes and preserve the
> integrity of the network keys.  This, in turn, looks a lot like the "thin crispy shell
> and gooey interior" network model that is going out of favor for corporate
> networks in favor of a VPNless or "zero-trust" model.  It's not clear that we can
> make the same transition at the LLN layer, but we can at least talk about the
> risks, especially when we are going to be dependent on a third party (MASA) in
> the trust chain.

PT> Sadly, we are exactly there -the thin shell- and 6TiSCH as no charter to get beyond that.
I'm happy to quote the above since it is exactly true, but cannot point on much effort to improve it.
The only thing I'm aware of is ietf-6lo-ap-nd that protects the addresses independently of L2 security.
I'd like to inject work in ROLL to protect RPL better against a rogue with L2 access, but that has not started yet. 
Added:
"
   The 6TISCH Architecture relies on the join process to deny
   authorization of invalid nodes and preserve the integrity of the
   network keys.  A rogue that managed to access the network can perform
   a large variety of attacks from DoS to injecting forged packets and
   routing information.  "Zero-trust" properties would be highly
   desirable but are mostly not available at the time of this writing.
   [I-D.ietf-6lo-ap-nd] is a notable exception that protects the
   ownership of IPv6 addresses and prevents a rogue node with L2 access
   from stealing and injecting traffic on behalf of a legitimate node.
"

> Will there need to be any (additional) authentication/authorization mechanisms
> for cell or chunk reservation/allocation?

PT> unknown, that design has not started. Following Michael's advice I would not go any deeper into guess work in this document.

> For central monitoring/management cases, are there any additional
> considerations to mention with respect to getting the monitoring to the
> controller in a timely and accurate fashion?  I don't remember how strongly
> detnet overlaps with this (but our radio technology potentially makes this a
> more important consideration).

PT> It does and DetNet does not care much, because the work there is focused on use cases for high speed wires.
OTOH this is the central subject for RAW: basically you cannot update the routes from a central controller that resides far over the constrained network at the speed at which the quality of the wireless links varies. 
So there must be a lot of NECMP and PAREO programmed by the routing on a long term basis, and then an intelligent and very dynamic use of those opportunities by the forwarding to deliver a guaranteed PDR and yet save constrained resources (battery and spectrum). Not an easy problem. Then again 6TiSCH itself did not work too deep in the matter, and I'd rather defer to RAW if it is chartered. 
Adding text in appendix "6TiSCH Track Setup"
"
In a large LLN, it is not
      feasible to update the routes from a central controller that resides far
      over the constrained network at the speed at which the quality of the
      wireless links varies. 
      RAW would focus on forwarding behaviors to react quickly and locally to
      the changes in the wireless links.
"


> 
>    After obtaining the tentative ASN, a pledge that wishes to join the
>    6TiSCH network must use a join protocol to obtain its security keys.
>    The join protocol used in 6TiSCH is the Constrained Join Protocol
>    (CoJP).  In the minimal setting defined in
>    [I-D.ietf-6tisch-minimal-security], the authentication requires a
>    pre-shared key, based on which a secure session is derived.  The CoJP
>    exchange may also be preceded with a zero-touch handshake
>    [I-D.ietf-6tisch-dtsecurity-zerotouch-join] in order to enable pledge
>    joining based on certificates and/or inter-domain communication.
> 
> Do we want to mention that more robuse ("non-minimal") mechanisms are also
> in development?

PT> ietf-6tisch-dtsecurity-zerotouch-join is a non-minimal. This is the one that would use the constrained voucher and EDHOC.

> It's probably worth talking about the risks of the pure-PSK usage in 6tisch-
> minimal-security, lack of forward secrecy(?), etc.
> 

PT> isn't that common knowledge? Or do you mean something deeply related to 6TiSCH? In that case I'd defer (point) to minimal security because that is the place where we use PSK.


>    appropriate network.  As a result of the CoJP exchange, the pledge is
>    in possession of a Link-Layer material including keys and a short
>    address, and if the ASN is known to be correct, all traffic can now
>    be secured using CCM* at the Link-Layer.
> 
> What happens if the ASN is not correct?

PT > We have this
"
    If the receiver and the sender have a different sense of ASN, the MIC will
    not validate and the frame will be dropped.
"
The key though is the "known to be". If it is not known to be correct then it might be a reply and the pledge using the network key with an ASN in the past may leak the key.
We have this:
"
If the pledge uses an ASN that is learned
    from a replayed beacon for an encrypted transmission, a nonce-reuse attack
    becomes possible and the network keys may be compromised.
"

> Section 8.2
> 
> I agree with Mirja that many of these nominally-informative references are
> really normative.
> 

PT> Acted upon


> Section A.2.1
> 
> The EDHOC status could be updated to reflect the LAKE developments.
> 

PT > Changed to
"
   "Ephemeral Diffie-Hellman Over COSE (EDHOC)"
   [I-D.selander-ace-cose-ecdhe], which is being considered for adoption
   at the LAKE WG.

"



> Section A.2.2
> 
> The "[formation of RAW] is being considered" text is basically duplicated.
> 

Whao, that was an in-depth review. Many, many thanks Ben!

All the best,

Pascal