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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 20 Aug 2019 10:54:41 -0700

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)

---

From: <[email-masked]>
Date: Wed, 21 Aug 2019 14:49:27 +0000

Hello Roman, all,

First, thanks for your time reading and commenting on our draft!
Please find my responses/questions inline.
Best regards

Dominique

Le 20/08/19 19:54, « Roman Danyliw via Datatracker » <[email-masked]> a
écrit :

><<<…>>>
DB: we meant to say that we do not address the threats that are not
specific to SCHC (e.g. Radio jamming).
There are too many security mechanisms in wireless networks, at all
layers, for us to cite them.
Maybe it's obvious that this draft's Security Considerations should only
focus on security issues created/enabled by SCHC, and it would be better
to remove the offending sentence altogether?

>network”, what is that precisely?  Is this simply join the network?
DB: this sentence was meant to set the attacker's capabilities.
We assume we are in the situation where an attacking SCHC entity is able
to exchange SCHC messages with a legitimate SCHC entity, and the former is
obviously not bound by this specification.
This could happen by an attacking node joining a SCHC-enabled network by
means of physically compromising an existing node, or breaking the join
security mechanisms of the underlying network, or any other way.

>crazy’”, what does that mean – compromised nodes? unexplained behavior?
DB: By "legitimate nodes 'going crazy", we mean that a legitimate node
that does not behave per this specification for a reason other than
malicious behaviour, could create the same issues as described for the
attacker case. Causes for "crazy" behaviour can be an implementation bug
or a soft error due to cosmic rays.
DB: Thanks, we'll improve this text. We mean somewhere on the Internet, as
shown in Fig 5., which is a more accurate depiction of the SCHC
architecture.

>write another draft which updates this RFC?
DB: indeed, there are thought in the WG of adding more MOs and CDAs in the
future, and the plan is to write other drafts to extend this RFC.

>might be worth saying that.
DB: if a sender decides that a window it sends has fewer tiles, the
receiver has no way of knowing it. The receiver behaves per this RFC,
which mandates that all windows have the same number of tiles.
To the receiver, it will look like one or several Fragment messages have
been lost, because the assumed-missing tiles were not received. The
mechanisms meant to cure the missing tiles issue will kick-in
(retransmission request, RCS validation, etc.).

>(5) Section 8.2.3.  A citation is needed for “Reassembly Check Sequence”.
DB: do you mean a citation external to this draft, or an internal
reference?
The term we originally used was MIC (Message Integrity Check). However, it
was rejected as misleading.
We coined the term RCS (Reassembly Check Sequence) as better representing
what we are doing.
A web search does not return anything for this term, but this draft.
Do you mean that Section 8.2.3 does not properly document the algorithm?

>and this text is simply stating that there might be a per rule
DB: indeed, we mean to have a per rule WINDOW_SIZE.
This is re-inforced in Section 8.4.3, which states
Each Profile, for each Rule ID value, MUST define
o ...
o  the value of WINDOW_SIZE, ...

>one) but the second sentence then says, the second from last tile could be
DB: you are right, this second sentence is creating an exception in the
first sentence, and this could be written better.
We'll improve this text.

>Section 3.7 of 
>https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-15?
DB: you're right, there is a slight increase in processing to conduct
decompression.
In LPWANs, we operate under the assumption that transmission cost (1 to
1000 uJ per bit)
is much higher that computation cost (1-100 nJ per instruction), and
therefore tend to ignore computation overhead if not for the most extreme
compute-intensive tasks.

>This isn’t precisely defined anywhere.
DB: thanks, we'll improve this.

>smartphone/, as the Devs are computers.
DB: will do.

>-- Inconsistent with the others, the Application Server has no
DB: Good catch, thanks. I'll check what happened!

>-- The LPWAN-AAA is depicted in Figure 1, but not enumerated in the
Fig 1. is excerpted from RFC8376 and we resisted the temptation to hack it
for our purpose.
I guess you're suggesting we rip LPWAN-AAA out of Fig 1, which is not used
anywhere in this draft.
The caption will state "LPWAN architecture, simplified from that shown in
RFC8376"

>that it isn’t used by all of the modes)
DB: thanks, will do all 4.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.