Hi Pascal! Thank you for publishing -25. It addresses my concern. I have one detailed response below about a possible edit based on your question.
Roman > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com] > Sent: Thursday, August 22, 2019 11:19 AM > To: Roman Danyliw <r...@cert.org>; The IESG <i...@ietf.org> > Cc: draft-ietf-6tisch-architect...@ietf.org; 6tisch-cha...@ietf.org; > shwetha.bhand...@gmail.com; 6tisch@ietf.org > Subject: RE: Roman Danyliw's No Objection on draft-ietf-6tisch-architecture- > 24: (with COMMENT) > > Hello Roman: > > Many thanks for your review, your time is much appreciated. > > Please see below: > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > ** Why are both Section 3.4 and Section 4.4 needed? Both appear to > > explain the four scheduling mechanisms. Section 4.4. appears to have > more details. > > Section 3 is a high level architecture, section 4 a low level. Having both in > 1 > document was a conscious decision since the early review by Ralph. We split > 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. > > 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. > > There was a desire to make section 4 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. > > I'm quite afraid to destabilize the document by doing a major change now. Understood. I can appreciate the intent here. > > > ** Section 3.6. Per the summary table in this section, what is the > > routing technique “reactive P2P”. It doesn’t appear to be explained in the > text above. > > PT> I removed the P2P which is not explained. The relevant text > PT> otherwise is > " > or by in a distributed fashion using a reactive routing protocol and > a Hop-by-Hop scheduling protocol. > " > > > > ** Section 3.6. Per the “Hop-by-Hop (TBD)” in the scheduling column > > in the summary table, to what does the “TBD”? > > PT> good catch. It is now AODV RPL, updated the picture > Thanks. > > ** Section 6. In reviewing the Security Considerations section, there > > is a substantial amount of technical detail (thank you!). However, > > despite this detail, understanding the overall security properties of > > the architecture and associate implementations mechanisms used by the > > architecture was challenging for me. Specifically, if 6TiSCH “is > > subject to the observations in section 5 of > > [I-D.ietf-detnet-architecture]”, then per [I-D.ietf-detnet- > > architecture] it should provide “confidentiality of data traversing > > the DetNet”, “authentication and authorization … for each connected > > device”, availability, and precision timing. The text needs to be > > clearer on how those properties are realized, and if there are > > residual threat. My recommended way to realize this clarity is restructure > the text into blocks around the relevant security properties and explicitly > state the property as an introduction. > > PT > I made an attempt at it, please see -25 once published. > The outlook would be > > 6. Security Considerations . . . . . . . . . . . . . . . . . . . 51 > 6.1. Availability of Remote Services . . . . . . . . . . . . . 51 > 6.2. MAC-Layer Security . . . . . . . . . . . . . . . . . . . 52 > 6.3. Time Synchronization . . . . . . . . . . . . . . . . . . 53 > 6.4. Selective Jamming . . . . . . . . . . . . . . . . . . . . 53 > 6.5. Validating ASN . . . . . . . . . . . . . . . . . . . . . 53 > 6.6. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 54 > 6.7. Deeper Considerations . . . . . . . . . . . . . . . . . . 54 > > More below This new text if very helpful and addresses my concern. Thank you. > > > A few additional points: > > > > -- Per precision timing, the text in this section says “measures must > > be taken to protect the time synchronization, and for 6TiSCH this > > includes ensuring that the Absolute Slot Number (ASN), which is used > > as ever incrementing counter for the computation of the Link-Layer > > security nonce, is not compromised, more below on this.” In the > > subsequent text there is “[t]he standard [IEEE802154] assumes that the > ASN is distributed securely by other means. > > The ASN is not passed explicitly in the data frames”. To confirm, is > > this the intended guidance on avoiding “compromising” the ASN – > > distribute it out of band and don’t pass it in the data frame? > > PT > ASN is not passed in the frame because it would was 5 octets. A network > is non-functional if nodes do not have the right sense of ASN so if the > network works, it means the 5 bytes can be saved. > PT > With 6TiSCH, ASN is learned from unsecured beacons, and needs t be > proven before used. We hint how that is done in this spec, and detail in > minimal security. > PT > once installed and as long as the node is synchronized to the network > ASN is implicit and cannot be compromised. > PT > One of the new sections deals with ASN protection and the details are in > the 6tisch minimal security draft > > > -- Per confidentiality (but it is really more than that), a series of > > security mechanisms/assumptions are inherited from [IEEE Std. > > 802.15.4] around link- layer security. They need to be explicitly > > stated (i.e., confidentiality, authenticity, with what crypto, > > relative to whom, etc.). The operational details of key management has no > treatment. > > PT> > PT > For the most part, I pointed at the minimal security draft for more > details, made it a normative reference: this comes from a chat with Ben > Kaduk and the authors of minimal security. We wish to place the gory details > in the security section of minimal security, and that includes key > management. Still I added some of the text below, a section on rekeying, > and MAC security, which is basically CCM* with a network-wide key, using > ASN and MAC addresses in the nonce: > " > > 6.4. Rekeying > > 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 Resetting Epoch time when rebooting the network. > " > > " 6.2. Relative to MAC-Layer Security > > This architecture operates on IEEE Std. 802.15.4 and expects the > Link-Layer security to be enabled at all times between connected > devices, except for the very first step of the device join process, > where a joining device may need some initial, unsecured exchanges so > as to obtain its initial key material. In a typical deployment, all > joined nodes use the same keys and rekeying needs to be global. > > 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. > > ... > " Works for me. > > -- Per availability, the text notes “communication with the PCE must > > be secured and protected against DoS”. Secured how? > > PT > This is what section 9 of RFC 8453 discusses. Note that it mostly > insists on > PKI / AAA as opposed to delay attacks and black holes. > How can take us in network architecture, isolation, firewalls. That seems to > take us quite off topic , doesn't it? > > > > > > ** Section 6. Per “Section 9 of [RFC8453] applies equally to 6TiSCH”, > > this reference organizes threats and mitigations around the CMI and > > MPI interfaces. > > What is the analog to those in this architecture? > > PT> This is the same parallel as done in the DetNet architecture from which > this is inherited, using the same reference. > The security issues that arise when a centralized control is separate from the > forwarding plane are similar: rogue access to one of the components, and > attacks on the connectivity on the control path, including interception, > blackholing or latency injection. > I can remove the reference and replace by text like the above, please advise. > In parammme please condsider the security section of the detnet > architecture, it is in AUTH 48 but still changeable. I would recommend taking a hybrid approach. I think it's worth making the more specific statement you propose but also citing that the more general version of this consideration comes from [RFC8453]. > > > > > ** Section 6. Please provide a citation for “CCM*” > > PT > Added Thanks. > > ** Editorial > > -- Section 3.1. Typo. s/an homogenous/a homogenous/ > > > > -- Section 3.5. Typo. s/[RFC6550]is/[RFC6550] is/ > > > > -- Section 3.6. Typo. s/A central/a central/ > > > > -- Section 3.6. Typo. s/an hybrid/a hybrid/ > > > > -- Section 3.7. The paragraph starting with “The reference stack that > > the 6TiSCH architecture presents …” doesn’t seem to add any clarity. > > > > -- Section 4.2.1. Typo. s/(JP):/(JP),/ > > > > -- Section 4.2.2. Typo. /ND ot the/ND to the/ > > > > -- Section 4.3.1.1. Typo. s/are are/are/ > > > > -- Section 4.3.1.1. Duplicate phrase. “added/moved/deleted, in which > > case 6top can only act as instructed,” appears twice. > > > > -- Section 4.3.5. Typo. s/an height/a height/ > > PT> all nits processed, many thanks! Thanks for these changes. > I will publish 25 to provide a abase on which we can refine in the next > minutes. > Please consider it before replying to this mail. > > Many thanks again! > > Pascal _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
