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

Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 08 August 2019 03:59 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: 6tisch@ietf.org
Delivered-To: 6tisch@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9548120033; Wed, 7 Aug 2019 20:59:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6tisch-architecture@ietf.org, 6tisch-chairs@ietf.org, shwetha.bhandari@gmail.com, 6tisch@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.100.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <156523675061.8257.3166819796531461415.idtracker@ietfa.amsl.com>
Date: Wed, 07 Aug 2019 20:59:10 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/qgUyCREAZJhfl_xlYaQ1Lg6td1I>
Subject: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Aug 2019 03:59:11 -0000

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.