[lp-wan] Roman Danyliw's Discuss on draft-ietf-lpwan-ipv6-static-context-hc-21: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-lpwan-ipv6-static-context-hc-21: 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-lpwan-ipv6-static-context-hc/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) Section 12.  The introductory text needs a bit more precision. Specifically:

-- Per “Wireless networks are subjects to various sorts of attacks , which are
not specific to SCHC.”, which other security considerations are being cited
here?  An alternative construct would be to state that “SCHC Packets rely on
the security mechanisms of … [insert relevant references]”

-- Section 12.  “[W]e’ll assume that an attacker was able to break into the
network”, what is that precisely?  Is this simply join the network?

-- Section 12.  Per “Our analysis equally applies to legitimate nodes ‘going
crazy’”, what does that mean – compromised nodes? unexplained behavior?


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

(2) Section 5.2.  The text notes that the “SCHC F/R and C/D on the Network side
can be located in the NGW or somewhere else …”.  Given the reference
architecture (per Figure 1) to what part of the architecture does  “somewhere
else” refer?

(3) Section 7.4 and 7.5, was there any WG discussion around extensibility if
one wanted to add additional MOs and CDAs in the future (I have no leading
suggestions on what one of these extensions might be)?  Is the thinking to
write another draft which updates this RFC?

(4) Section 8.2.2.2.  What happens if a given window doesn’t have the same
number of tiles as the others?  I assume you silently drop the frames.  It
might be worth saying that.

(5) Section 8.2.3.  A citation is needed for “Reassembly Check Sequence”.

(6) Section 8.2.4.  Per “if windows are used and what the value of WINDOW_SIZE
is”, to clarify, WINDOW_SIZE is actually set via profile (per Section 8.2.2.2),
and this text is simply stating that there might be a per rule WINDOW_SIZE?

(7) Section 8.4.3. Per “All tiles MUST be of equal size, except for the last
one, which MUST be of the same size or smaller than the regular ones.  If
allowed in a Profile, the penultimate tile MAY be exactly one L2 Word smaller
than the regular tile size.”, it seems like these two sentences conflict.  The
first sentence appears to state that all MUST be of equal size (but the last
one) but the second sentence then says, the second from last tile could be
shorter.

(8) Section 12.1.  Per “As a consequence, SCHC Decompression does not amplify
attacks, beyond adding a bounded …”, but also a slight increase in processing
to conduct the decompression too, no? Section 12.  Do LPWAN environments have
the equivalent of NIDS that which could be evaded with SDHC fragmentation per
Joe Salowey’s SECDIR review
(https://mailarchive.ietf.org/arch/msg/secdir/p-D9T5Z2nOJ9DHox1nqLCkd2z0A) and
Section 3.7 of https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-15?

(9) Editorial
** The term “on the network side” is used a number of places in the document. 
This isn’t precisely defined anywhere.

** Section 1.  Perhaps s/computer or smartphone/general-purpose computer or
smartphone/, as the Devs are computers.

** Section 3.  This section provides a list and simple definition of elements
of the architecture and depicts their relationship in Figure 1.

-- Inconsistent with the others, the Application Server has no explanation in
the bulleted list

-- The LPWAN-AAA is depicted in Figure 1, but not enumerated in the bulleted
list of elements

** In multiple places.  Typo.  s/occurence/occurrence/g

** Section 7.3.  Typo.  s/Inded/Indeed/

** Section 7.5.1 and 7.5.2.  Typo. s/aplying/applying/

** Figure 3 and 24: Perhaps note that the SCHC ACK is optional/as needed (given
that it isn’t used by all of the modes)