Re: [6lo] Roman Danyliw's Discuss on draft-ietf-6lo-use-cases-14: (with DISCUSS and COMMENT)

[Erik Kline <[e-mail]>]

Thank you, Roman, for the review.

Authors: I believe we're waiting for someone to produce one or more
updates that collectively address the comments provided.

Thanks,
-ek


On Tue, Dec 13, 2022 at 3:15 PM Roman Danyliw via Datatracker
<[e-mail]> wrote:
>
> 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
>
>
>