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. _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch