Subject: [lp-wan] IANA registry for command and control rules

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 19 Mar 2020 10:54:45 +0000

Dear all

At the interim on March 3rd, as reminded by Olivier yesterday, I took a commitment to draft a request to IANA to create a registry for command and control rules.

For memory the quote is this:
https://datatracker.ietf.org/meeting/interim-2020-lpwan-05/materials/minutes-interim-2020-lpwan-05-202003041600
"

Olivier: use of SCHC Rule to convey a rejoin command, or carry a network prefix?
PT: why not, but write explicitely in the draft what you need.
PT: could be a RuleID that says "command&control", then assign a code point for rejoin within that space.
Olivier: could be useful for multicast as well.
PT: should be a generic draft for this new use of SCHC Rules.
PT: generic draft to desribe the use of a Rule for "command&control", and this draft to specify which codepoint to be used for Rejoin in LoraWAN.
PT; if very quick, could have other draft generate the IANA registry, and this draft to allocate a codepoint into that registry.
PT: it's one page. Will do it next week.
PT: same can be used for OAM as well.
"

Yesterday Alex suggested we clarify the intent so I'm opening this thread.

Basically the idea is that:
- a rule set may have a particular rule that says "command and control"
- that rule is followed by a value for command/control/response and then possibly one or more TLV expressed in a SCHC-compressed form.
- the need is to create a single registry for the values of command/control/response that is independent of the technology

My plan is to describe just that (one page) and provide an initial list of command/control/response values.

Questions:
0) Do we agree it's a good idea?
1) what do I miss in the above that should be in the draft?
2) what's your initial set of command/control/response?

All the best

Pascal

---

From: Olivier Gimenez <[email-masked]>
Date: Fri, 20 Mar 2020 09:47:17 +0000

Thank you Pascal for the email.

To answer your questions

0)      Yes, obviously :)

1)

a.       I also think that values should be express as TLV so we can send several commands at a time

b.       I do not understand the "expressed in SCHC-compressed form": in order to avoid mixing layers this message should not be fragmented nor compressed

c.       This has to be acknowledged by the receiver; two ways I can see: receiver is re-emitting the same payload or receiver is sending a hash of the received payload

2)      The need I foresee for now in SCHC over LoRaWAN draft:
2.1) IID nonce sharing
2.2) Eventually multicast setup, not be defined later

IID nonce sharing: I initially presented the need for this mechanism to send a rejoin request to a device, but sharing a nonce between the SCHC gateway and the device is better:

1.        After each join the "IID nonce" is reinitialised to 0 on device and SCHC gateway

2.       Both sides are using IID = F(devEui, AppSKey, IID nonce)

3.       If there is a conflict gateway generates a new nonce then share it with the device
This way there is no more the cross layer issue we discussed when an IID conflicts triggers a rejoin, the gateway is also able to trigger an IID change is required (like the change over time requirement of RFC8065)

Best regards
Olivier

Questions:

All the best

Pascal

To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 20 Mar 2020 13:21:23 +0000

Hello Olivier

For 1b I guess it might be out of scope but I thought that the content of the command could be compressed using a compression rule;
e.g., this can be a way to transform human readable formats.

The way I see it, we could have a train of rules, some expressing commands, some expressing compressed parameters for the previous command.

But this is very abstract till we have a draft that uses the commands

Pascal

From: Olivier Gimenez <[email-masked]>
Sent: vendredi 20 mars 2020 10:47
To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
Subject: RE: IANA registry for command and control rules

To answer your questions

  1.  Yes, obviously :)
  2.

     *   I also think that values should be express as TLV so we can send several commands at a time
     *   I do not understand the "expressed in SCHC-compressed form": in order to avoid mixing layers this message should not be fragmented nor compressed
     *   This has to be acknowledged by the receiver; two ways I can see: receiver is re-emitting the same payload or receiver is sending a hash of the received payload

  1.  The need I foresee for now in SCHC over LoRaWAN draft:
2.1) IID nonce sharing
2.2) Eventually multicast setup, not be defined later

Best regards
Olivier

Questions:

All the best

Pascal

To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal<http://www.semtech.com/legal>.

---

From: Alexander Pelov <[email-masked]>
Date: Thu, 26 Mar 2020 10:20:26 +0100

Dear Pascal, Olivier,

(chair hat off)

Thanks for getting the discussion on the Mailing List, so that we can have
the discussion here and see the need and the implications of what is being
discussed.

On the questions:

*0) Do we agree it’s a good idea?*

-> I'm not convinced. At least in the current form, I am really not sure
this is the right way to address the question.

-> I'll leave the other questions for discussion later, given that we'll
need to clarify 0) first.

There are a lot of potential issues I see with the way the question is
addressed.

Let me address the first, which is - why we are doing this? Let's delimit
the design space.

If it is only for the case when there might be IPv6 address collision -
then this seems as an overkill to me.

There are other solutions to the problem much simpler from SCHC point of
view, and second - for me, this implies heavy architectural dependencies.

If there are other use-cases, I think we need to discuss them and see how
should such command mechanism work.

Let me just ask a couple of questions that will need to be answered (sooner
or later):

- The discussion may start simple with the need to "only" do a "simple"
action. Very soon and very fast that will move to a full protocol spec. ->
E.g. what happens if the command gets lost? If you want return value - how
do you encode that? There are ideas about TLV - perfect, but we'll need to
define that as well.

- How do you handle security?

- How do you handle the case where the command cannot be executed by the
SCHC layer? (e.g. the IPv6 stack on the device has no knowledge of the SCHC
layer, and the SCHC layer has no access to the LPWAN stack beneath?).

On the solution side, there are at least two straightforward ways of doing
what is intended by Olivier:

A) Out-of-band. That would be the equivalent of sending a L2 MAC command to
the device to rejoin. It could be that the SCHC Network Gateway doesn't
respond to any uplink traffic and the device infers to rejoin after a given
number of uplink messages. (say 10). Both are not perfect but hey - we are
talking about a collision probability that is so incredibly small that I
don't expect that happening ever in production.

B.1) Have a service running on the link-local address of the device - on a
specific UDP port, and send the Rejoin / Rekey command to this service.
This way, there is no need to add any functionality to the SCHC layer
already present. You'll need to have a rule that compresses that type of
traffic added to the baseline rules, but that's it on the SCHC side. In
this case, you'll also be able to add security if that is required (or
not).

B.2) Have a "No compress" rule that is the default, fall-back rule when
other compression rule doesn't match the traffic. In this case, even if the
autoconfigured IPv6 address in the SCHC rule doesn't match the traffic, the
default "No compress" will let it through, which will leave room for other
protocols on top to handle the IPv6 configuration.

All three options proposed here require 0 new mechanisms and 0 discussions
of new documents.

I find this discussion and the idea really interesting and asking the right
questions at the right time. However, what I feel is that we have a
specific problem to resolve, and we're losing the bigger picture.

Given the time it took to get where we are with RFC-to-be-8724 it would be
wiser to move rapidly with the SCHC-over-FOO documents for a baseline that
will work, and then address the bigger architectural questions in a
separate document.

Cheers,

Alexander

On Fri, Mar 20, 2020 at 2:22 PM Pascal Thubert (pthubert) <pthubert=
[email-masked]> wrote:

> Hello Olivier
>
>
>
> For 1b I guess it might be out of scope but I thought that the content of
> the command could be compressed using a compression rule;
>
> The way I see it, we could have a train of rules, some expressing
> commands, some expressing compressed parameters for the previous command.
>
>
>
> *From:* Olivier Gimenez <[email-masked]>
> *Sent:* vendredi 20 mars 2020 10:47
> *To:* Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
> *Subject:* RE: IANA registry for command and control rules
>
>
>
>    1. Yes, obviously J
>    1. I also think that values should be express as TLV so we can send
>       several commands at a time
>       2. I do not understand the “expressed in SCHC-compressed form”: in
>       order to avoid mixing layers this message should not be fragmented nor
>       compressed
>       3. This has to be acknowledged by the receiver; two ways I can see:
>       receiver is re-emitting the same payload or receiver is sending a hash of
>       the received payload
>
>
> IID nonce sharing: I initially presented the need for this mechanism to
> send a rejoin request to a device, but sharing a nonce between the SCHC
> gateway and the device is better:
>
>    1.  After each join the “IID nonce” is reinitialised to 0 on device
>    and SCHC gateway
> This way there is no more the cross layer issue we discussed when an IID
> conflicts triggers a rejoin, the gateway is also able to trigger an IID
> change is required (like the change over time requirement of RFC8065)
>
>
>
>
>
> Best regards
>
> Olivier
>
>
>
>
>
> Questions:
>
> 0) Do we agree it’s a good idea?
>
> 2) what’s your initial set of command/control/response?
>
>
>
> All the best
>
>
>
> Pascal
>
>
>
>
> To view our privacy policy, including the types of personal information we
> collect, process and share, and the rights and options you have in this
> respect, see www.semtech.com/legal.
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>