[lp-wan] SCHC-over-LoRaWAN clarifications and enhancements

[Julien Catalano <[e-mail]>]

Dear lpwan-ers, dear SCHC-over-LoRaWAN contributors,

Following our discussions in IETF 105 in Montreal, please find below my
proposals to clarify and enhance SCHC-over-LoRaWAN draft.

Proposals:
### 1 - Better usage of FPorts / distinct use for compression and
fragmentation

## 1.1 - Compression

| FPort | ext-RuleID | Compression residue | Payload |
+-------+------------+---------------------+---------+
| 8bits |    8bits   |      X bits         | N bytes |

When not using fragmentation, FPort 31 (0x1F) is the RECOMMENDED FPort
used to transport SCHC packets.
The ext-ruleID field size is left to the implementation, RECOMMENDED 1
byte (8 bits).

The actual ruleID value is the concatenation of FPort + ext-RuleID fields.
For example, if ext-RuleID field is 8 bits, value is 0x42, using
recommended FPort 31 (0x1F), gives RuleID number 0x1F42 (8002).

Note that usable FPort range is [1;223] according to LoRaWAN specification.

## 1.2 - Fragmentation

|   FPort (8 bits)  | SCHC header (8 bits) | Fragment payload (tiles) |
+-------------------+----------------------+--------------------------|
| Prefix | DTag | W | W |        FCN       |     X Tiles              |
| 6 bits | 1b   |   2b  |      7 bits      |     N Bytes              |


When SCHC fragmentation is used, SCHC fragments are transported on a
range of FPorts.
FPort field is divided in a Prefix (6bits) and the start of the SCHC
fragmentation header.
FPort Prefix represents the RuleID for fragmentation.
To conform with LoRaWAN specification, FPort Prefix field usable values
are from 0x01 to 0x37, which gives FPorts 4 to 220.
The RECOMMENDED FPort Prefix is 0x08, using FPorts [32;35] range.

Note that Prefix value is the ruleID value.
To avoid conflict with compression FPort, the FPorts allocation SHALL be
shared between the device and the SCHC gateway. Mechanism to share those
FPorts values is out-of-scope of this draft.

## 1.3 - Discussions
 - I kept all the SCHC fragmentation header fields to the same sizes are
currently defined
 - Now that the header is reduced to a single byte for all
fragmentation, is tile size = 3B still the best choice?
 - If DTag is not useful, only 2 FPorts for fragmentation are needed
(instead of 4)
 - Compression residue padding: As LoRaWAN SCHC fragmentation is aligned
to L2 words, I wonder if we could specify that compression residue can
be padded *before* payload, to ease implementation.


### 2- Reassembly Check Sequence (RCS) for LoRaWAN fragmentation

The proposal is to use AES-CMAC to compute SCHC fragmentation RCS.
AES-CMAC is already used in LoRaWAN L2 to compute MIC fields.
AES-CMAC is defined in RFC4493.
We compute AES-CMAC with a dummy key, set to 0.
RCS is computed as follows:
    RCSKey = 0x00000000000000000000000000000000 (128bits)
    cmac = aes128_cmac(RCSKey, SCHC Packet (padded) | Pad16)
    RCS = cmac[0..3]
    Pad16 is adding zero-padding to the padded-SCHC Packet to fit the
AES-CMAC algorithm.


## 2.1 - Discussions
 - Note that I propose using RCSkey = 0 as AES-CMAC is not used for
authenticity but only for integrity of the SCHC fragments. It does not
harm the "randomness" of the RCS algorithm.
 - Having a specific RCS algorithm for LoRaWAN creates an
interoperability issue with other SCHC fragmentation drafts? I don't
think so, as this draft is specific to LoRaWAN anyway.

Let me know what you think.
Thank you for the productive meeting.
Julien