[lp-wan] Roman Danyliw's No Objection on draft-ietf-lpwan-schc-over-lorawan-13: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Tue, 03 November 2020 02:03 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-lpwan-schc-over-lorawan@ietf.org, lpwan-chairs@ietf.org, lp-wan@ietf.org, Dominique Barthel <dominique.barthel@orange.com>, dominique.barthel@orange.com
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <160436899340.23890.76548819458326051@ietfa.amsl.com>
Date: Mon, 02 Nov 2020 18:03:13 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/ctNsTAzmhnvRBNLHRaXXhfx5ey0>
Subject: [lp-wan] Roman Danyliw's No Objection on draft-ietf-lpwan-schc-over-lorawan-13: (with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-lpwan-schc-over-lorawan-13: No Objection

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-lpwan-schc-over-lorawan/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 3.  Per “… sending application flows using IPv6 or IPv6/UDP
protocols”?  It isn’t clear to me what nuance is being conveyed by saying IPv6
with and without UDP.

** Section 5.3
-- it would be useful to explicitly state that AppSKey is a session key and
what it is used for (encryption and decryption of the payload)

-- s/As AppSKey is renewed each time/As AppSKey is regenerated each time/ --
isn’t it derived per each join from a the AppKey+nonce+?

-- s/appSKey:/AppSKey/

-- RFC4493 should be normative because it is needed to compute the IID

** Section 6.
Moreover, SCHC data (LoRaWAN payload) are protected at
   the LoRaWAN level by an AES-128 encryption with a session key shared
   by the device and the SCHC gateway.  These session keys are renewed
   at each LoRaWAN session (ie: each join or rejoin to the LoRaWAN
   network)

Appreciating that this document is not redefining LoRaWAN security, it might
nevertheless be helpful to more clearly state (or provide a reference to) the
security properties of the link between the device and the application service
(SCHC gateway).  Since the text explicitly noted that confidentiality via the
session key, it would also be helpful to note the other properties such as
integrity provided by the MIC, partial replay protection via the DevNonce, etc.

[lp-wan] Roman Danyliw's No Objection on draft-ie… Roman Danyliw via Datatracker