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

[<[e-mail]>]

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 » <[e-mail]> a
écrit :

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

>
>-- 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?
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.

>
>-- Section 12.  Per “Our analysis equally applies to legitimate nodes
>‘going
>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.
>
>
>----------------------------------------------------------------------
>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?
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.

>
>(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?
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.

>
>(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.
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?

>
>(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?
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, ...



>
>(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.
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.

>
>(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?
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.

>
>(9) Editorial
>** The term “on the network side” is used a number of places in the
>document. 
>This isn’t precisely defined anywhere.
DB: thanks, we'll improve this.

>
>** Section 1.  Perhaps s/computer or smartphone/general-purpose computer
>or
>smartphone/, as the Devs are computers.
DB: will do.

>
>** 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
DB: Good catch, thanks. I'll check what happened!

>
>-- The LPWAN-AAA is depicted in Figure 1, but not enumerated in the
>bulleted
>list of elements
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"

>
>** 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)
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.