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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 07 Aug 2019 20:59:10 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6tisch-architecture-24: 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-architecture/

----------------------------------------------------------------------
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.

----------------------------------------------------------------------
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.]

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.

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.

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.

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?

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

   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.

Section 3.2

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

   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?

   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"?

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/

   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"?

Section 3.7

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

   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.

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/

Section 4.1.1

DAO should probably be expanded somewhere.

   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?

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.)

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

Section 4.2.2

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

   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?

Section 4.3.1.1

There seems to be a duplicated source line in here.

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?

   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?

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"?)

   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?

Section 4.4

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

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.

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?  Will
the sender know in advance if this is the case?

   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?

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?

   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.

Section 4.5.3

Where is PRE defined?

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.

   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.

Section 4.6.1

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

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?

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?

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.)

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.

Section 6

We might benefit from splitting this into a few subsections.

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.

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.

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

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).

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

   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?

Section 8.2

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

Section A.2.1

The EDHOC status could be updated to reflect the LAKE developments.

Section A.2.2

The "[formation of RAW] is being considered" text is basically
duplicated.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 9 Aug 2019 00:58:08 +0300

IEEE Std 802.15.4-2015 says:

----------------------------------------------------------------------
7.4.4.2 TSCH Synchronization IE

The TSCH Synchronization IE Content field shall be formatted as
illustrated in Figure 7-50.

          +-------------+---------------+
	  |  Octets: 5  |       1       |
          +-------------+---------------+
	  |     ASN     |  Join Metric  |
          +-------------+---------------+

     Figure 7-50 -- TSCH Synchronization IE Content field format
	   
The ASN field contains the ASN corresponding to the timeslot in which
the enhanced beacon is sent. The ASN is used as the Frame Counter for
security operations if enabled.

The Join Metric field is an unsigned integer and shall be set to
macJoinMetric.
----------------------------------------------------------------------

And

Section 8.4.2.2 TSCH-specific MAC PIB attributes

...

       Table 8-83 -- TSCH-specific MAC PIB attributes

Attribute	Type     Range       Description                     Default
...
macJoinMetric	Integer	 0x00–0xff   The sum of one and the	     1
			 	     value of the Join Metric
				     field from the TSCH
			 	     Synchronization IE, 7.4.4.2,
			 	     received in the Enhanced Beacon
			 	     frame used by the device
				     joining the network. If the
				     device is the an endpoint, the
				     value shall be set to zero.

So it is very clear that Join Metric can be any number between
0x00-0xff. 

> "timeskeeping" does not seem to be defined anywhere.

Timekeeping comes from the IEEE Std 802.15.4-2015 Section 7.4.4.3 TSCH
Slotframe and Link IE:

----------------------------------------------------------------------
   The Timekeeping field shall be set to one if the link is to be used
   for clock synchronization and shall be set to zero otherwise. RX
   links shall have the Timekeeping field set to one.
-- 
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 9 Aug 2019 05:20:56 +0000

Great!

We asked for that change at the time, and clearly it was implemented.
This means that the text in the Architecture is now obsolete and I’ll remove it.

Many thanks Tero.

Pascal

> Le 8 août 2019 à 23:58, Tero Kivinen <[email-masked]> a écrit :
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 9 Aug 2019 12:57:56 -0500

> IEEE Std 802.15.4-2015 says:

Great news; I see that Pascal will update the text/reference.

> Timekeeping comes from the IEEE Std 802.15.4-2015 Section 7.4.4.3 TSCH

Ah, so it's just a typo and not a term of art.  Thanks!

-Ben

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 Aug 2019 13:23:04 +0000

Hello Benjamin:

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

Please see below:
> 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.

> [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.

> 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

> "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. "

> 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.

> 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."

> nit: I'd suggest s/play an equal/fulfil the same/

PT| done

> 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 ?

> 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>.
"

> nit: I suggest s/point on/point to/

PT> done

> DAO should probably be expanded somewhere.

PT> done on first use

> 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 @

> I can't tell what the "<once>" in  Figure 6 is intended to refer to.

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.
"

> Also, do we need to say "using 6LoWPAN ND" twice?

PT> all cleaned up

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

PT> cleaned up

> 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.
"

> 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. "

> 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 writing here is pretty speculative.  Maybe "envisions a protocol that enables
> chunk ownership appropriation" is better?
> 

PT> it is. I made the change

> The descriptions here seems to have high overlap with Section 3.4; can we

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.

> 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.

> 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.

> 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.

> 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.

"

> 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. 

> 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.
"

> 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.

> 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.

> (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"

> 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.

> 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.
"

> 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.

> 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

> 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 23 Aug 2019 14:21:17 -0500

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

I think we were fine with Informational, but didn't really talk about it.

>       resetting Epoch time when rebooting the network.

That looks great; thank you!
I might think about whether or not this text suggests that the approach in
minimal-security will be the only supported way to do so (and whether or
not that's true, I suppose), but I don't think that needs to hold up the
document.

>    JRC must be secured and should be protected against DoS attacks when

Okay.

> 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.

Thanks for the extra background; I definitely am not suggesting to undo
that.

>                which may include replication and elimination.

Thanks.

>    illustrated in Figure 2. "

Ah, thanks.

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

Okay, thanks for clarifying.

> 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.

I think I was just suggesting s/in its own/in its own schedule/ to make
the grammatical construction more parallel.

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

I think I was just failing to expand it to "Applications".  I don't
remebmer if there's a more-standard abbreviation that would fit in the
space available, though.

>               1975, <https://dl.acm.org/citation.cfm?id=1024920>.

Thanks!

>    RPL InstanceID that it wants to participate to using the Opaque field

Ah, thank you.

> See https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join/ and https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/ 

Thank you for pointing those out.  It only helps so much, since some of the
underlying BRSKI assumptions have only recently been written down, but I'm
sure we'll have more chances to think about it.

>    duplication of functionality between DAO and EDAR/EDAC messages, as

Thanks!

> PT> This is unspecified and all of the above would work. Can I steal your text?

Always!  (But I don't think it comes with any kind of warranty...)

>    is specified in [RFC8180] and pre-exists to the distribution of the

Thanks!  (nits: s/shared between/shared amongst/, s/pre-exists/exists
prior/)

> 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 destabiliz…

I didn't have anything particular in mind, and am happy to leave it in your
hands.  Thank you for making the extra pass thorugh.

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

I guess if it goes on for long enough you could get totally desynchronized,
and we do talk about the risks of that already, so this probably does not
need further discussion.

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

Cool, so if they care they can do advance planning.

> Also, RAW will be working on technique to actually not use the full set of (redundant) scheduled cells along a Track.

Fair enough, thanks.

>   in a rotation of the frequency that used for transmission.

Much better :)

>         at the lower MAC layer and thus is not received at the 6top sublayer.

Better.  I think maybe s/results in/results in a requirement that/, though?

> I removed that sentence too.

I love it when there's an easy fix like this :)

>    to the MAC address obtained from the tunnel information.

Thanks!

> 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…

I'm not clear on what attack vector I'm looking at, either :)
There's a few possible (some are listed below), but I'm willing to defer
this discussion as you note:

- increasead resource consumption on all nodes to do reassembly
- reassembly makes it easier to see all content on all nodes, for
  surveilance purposes (but that would be possible anyway)
- any effect on the DoS vectors on the recipient as it waits for all
  fragments
- fragments taking different paths and delivered out of order, dropped,
  etc.

> Changed to RPLInstanceID throughout

Thanks.

>    harder to perpetrate that particular attack.

Thanks!

>    from stealing and injecting traffic on behalf of a legitimate node.

Thanks; I'm happy to have a statement of the current state of affairs, even
if we'd like to get to some place better eventually.  Not making the
perfect the enemey of the good, and all that...

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

Okay.

>       the changes in the wireless links.

Thanks.  I definitely understand that this is mostly a topic for other
work.

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

Maybe "more-featureful zero-touch handshake", then?

> 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.

Let's defer to minimal-security.  And I think I just meant the
common-knowledge stuff, though I'm generally in favor of writing it down
anyway.

>     becomes possible and the network keys may be compromised.

Okay.

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

You're welcome!  Thanks for the thoughtful replies and careful editorial
stewardship!

-Ben