Roman Danyliw has entered the following ballot position for draft-ietf-6lo-use-cases-14: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6lo-use-cases/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 3 Security and Encryption: Though 6LoWPAN basic specifications do not address security at the network layer, the assumption is that L2 security must be present. In addition, application-level security is highly desirable. The working groups [IETF_ace] and [IETF_core] should be consulted for application and transport level security. The 6lo working group has worked on address authentication [RFC8928] and secure bootstrapping is also being discussed in the IETF. However, there may be other security mechanisms available in a deployment through other standards such as hardware-level security or certificates for the initial booting process. Encryption is important if the implementation can afford it. With the exception of authentication and secure bootstrapping, this text is vague on what security properties are to be considered. Likewise, saying “encryption” is not informative as it can help provide specific (but unnamed) security properties. What is intended is not clear. Specifically: -- What is the “L2 security” that “must be present” specifically? What properties are being addressed (e.g., confidentiality? Authenticity?) -- What is “application-level security” that is “desirable”? -- “Affordability” on what dimension per the supporting encryption? Is that a notional budget for the application, power/battery, etc? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Robert Sparks for the SECDIR review. ** Section 1. Running IPv6 on constrained node networks presents challenges, due to the characteristics of these networks such as small packet size, low power, low bandwidth, low cost, Why is “lost cost” a challenge to running IPv6 on a constrained network? It seems like a desirable property. ** Section 2. Editorial. Inconsistent descriptions of the protocols: -- Data rate: not mentioned in Section 2.2. -- Range: not mentioned in Sections 2.1, 2.2, 2.3, 2.5 ** Section 2.2. Editorial. Could references to Bluetooth 4.0, 4.1, and IPSP please be provided. ** Section 2.3. Editorial. Please provide a reference to DECT-ULE. ** Section 2.5. NFC technology enables simple and safe two-way interactions between electronic devices Are the other protocols in Section 2.* not “simple” or “safe”? ** Section 2.7 The following table shows the dominant parameters of each use case corresponding to the 6lo link layer technology. Is NFC “dominantly” only used in “health-care services”? Is there a basis for that assertion. ** Section 3. ... L2-address-derived IPv6 addresses are specified in [RFC4944], but there exist implications for privacy. Explicitly state those privacy implications. ** Section 4.2. Section 4.* is titled “deployment scenarios”. Section 4.1, 4.3, and 4.4 explicitly state where they are deployed. This section described Thread, but omits describing the envisioned deployment. ** Section 4.2. Editorial. The term “future-proof designs” seems like marketing. ** Section 4.* and 5.*. Editorial. I don’t understand the difference between a “deployment scenario” and a “6lo use case”. ** Section 5.1. Security support is required, especially for safety- related communication. What is a “security support”? Is “security” not desirable in the other use cases such as Section 5.2 - 5.4 _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
