[6tisch] Fw: Concerns about the CoJP message size, the need for BLOCK-WISE options and the use of NON-confirmable messages

[William Vignat <[e-mail]>]

Hello,


Mališa Vučinić asked me to forward this mail regarding the size of messages exchanged as part of the Minimal Security Framework for 6TiSCH to the broader 6tisch mailing list, hence this message. Once again I strongly recommend not viewing it here but there: https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues/19/concerns-about-the-cojp-message-size-the instead to enjoy the proper formatting of markdown text.


Sincerely,


William Vignat

Concerns about the CoJP message size, the need for BLOCK-WISE options and the use of NON-confirmable messages<https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues/19/concerns-about-the-cojp-message-size-the>
bitbucket.org





________________________________
From: William Vignat
Sent: Tuesday, July 3, 2018 3:00 PM
To: [e-mail]
Subject: Concerns about the CoJP message size, the need for BLOCK-WISE options and the use of NON-confirmable messages


Hello,


I already opened an issue on the bitbucket, however since this is not only an editorial matter I seem to remember from the IETF guidelines that a mail is also necessary.

(You will find the same text bellow, however I strongly recommend you to view this issue and answer directly on bitbucket here https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues/19/concerns-about-the-cojp-message-size-the because the markdown formatting will be way better. )


Sincerely,

William Vignat




--------------------------------------

Hello,

First, I wanted to thank you for all the efforts you put into this draft, its simplicty and reliance on already existing technologies truly are among its greatest assets in my opinion.

After finishing the test implementation of the latest OSCORE draft, I am starting to do the same with this draft, and while testing the serialization of messages, I noticed the large message size, which to be honest I hadn't expected while just reading this draft.

You will find bellow a detailed estimation of both the available CoAP message size using secured 802.15.4 messages and the CoJP size (at the CoAP level).

Without getting into the details so far, the conclusion, provided my predictions and calculations are good enough, is that although the CoJP request is surprisingly large, it manages to (barely sometimes, depending on the configuration used) be held into one unique 802.15.4 message. However the CoJP response will almost always overflow from such a message, and a way to fragment this message would be needed.

Now the BLOCK-WISE option is being devised just for this, however it is not really meant to be used with non-confirmable messages for obvious reasons such as packet loss...

I understand the reasonning behind making the request a NON-confirmable message to reduce the strain on the JP and the potential DoS, however maybe the answer should at least be a CONfirmable message so that it can easilly be fragmented using BLOCK-WISE (since the message is "flagged" by the stateless-proxy option we can make it so that the JP doesn't store any state even if the response is CON and just passes the messages along whether they are CON or NON)?

Since none of this is mentionned in the draft, I would like to know if a thought has been given to this particular problem, and if so if a solution that I'm not seeing has been chosen ?


Thank you in advance,

Sincerely


------------------------------------

**Rough payload size assessment:**

The maximum 802.15.4 message size is **127B**.

Lets take the example of a CoJP message being relayed on the network (during one of multiple hops), thus being protected both by OSCORE at the CoAP level, and by the L2 security that secures all the exchanges inside the network.

**Typical L2 (802.15.4) overhead with:**

- an 8-byte(medium security) MIC
- a 6-byte aux security header by relying on the fact that both addresses are present in the frame and thus KeyIdMode 0x00 or 0x01 can be used
- 8-byte MAC addresses since 2-byte short addresses at the L2 level are currently not supported in a lot of implementations, among which OpenWSN, but we don't use 10-byte addresses because we assume no PAN-id


In the end:

Frame control: 2 | Sequence nb: 1 | DstMAC@: 8 | SrcMAC@: 8 | Aux security header: 6 |  ...PAYLOAD...  | MIC: 8 | CRC: 2

TOTAL: **35B**





**Typical IPv6 overhead with:**

- a [2-byte compressed header](https://tools.ietf.org/html/rfc6282#section-3.1.1 ) (not counting the addresses)
- 8-byte IPv6 addresses (max would be 16 each, best case could optimize further by distributing addresses so that the common part can be ommited), but in this case, let's assume we don't specify the network, and we just specify the 8 bytes that correspond to the MAC address.


In the end:

LOWPAN_IPHC: 2 | Src IP @: 8 | Dst IP @: 8 ||
TOTAL: **18B**

**UDP overhead**:   8B

***Total message overhead: 61B***

***Thus leaving:  66B***


------------------------------------

**Now let's look at the size of the CoAP requests and response we actually want to send:**

**For all the OSCORE processing, if you want to verify the content of the messages by decrypting them, the following inputs have been used:**

- Master secret:{0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10}
- Master salt: <empty>
- Client(pledge) sid: {0x00}
- Server(JRC) sid: {0x4a, 0x52,0x43}
- The chosen 8-byte pledge identifier serving as kid/id-context was {0xaa,0xbb,0xcc,0xdd, 0xee,0xff,0x0a,0x0b}

**/!\ NOTE** that the newest version of the OSCORE draft, available
[here](https://tools.ietf.org/html/draft-ietf-core-object-security-13) was used, this version changes the processing of the input into the derived parameters and it adds the kid-context to this processing, thus changing completely the derived parameters and if you use an outdated implementation, you will not get those same results.

The following were thus derived and used:

- Common iv (size 13): { 0x30 0xD9 0x4B 0x12 0x25 0xA2 0x7A 0x24 0x83 0xE6 0x20 0x11 0xEF }
- Client sender key (size 16): { 0x8F 0x8B 0xC9 0x1B 0x3C 0xD0 0xAB 0xE4 0x19 0xB7 0xCF 0x22 0xF5 0x75 0xDA 0x12 }
- Client recipient key (size 16): { 0x26 0x3C 0x8A 0x53 0x03 0xBE 0xF8 0x49 0x95 0x9E 0x95 0x9F 0xF3 0x42 0x58 0x4E }

Note also that the first piv used in the request is 0x14 and not 0x00 for testing purposes.


For the CoAP processing:

- Message ID: {0xBA,0xAD}
- CoAP token: {0xDE, 0xAD, 0xBA, 0xBE}


For the CoJP request, a network id of size 4, e.g. "net1" was chosen, and the role is 0, i.e. node.

The cbor payload in diagnostic notation is:

{
    5: h'6E657431'
}
The obtained CoAP request looks as such (just leaving the pledge, before the JP):
-----JoinRequest for Node-----

CoAP-Message:{
version=1 , type=1 , TKL=4, Code=2, messageID=47789 ,token (size 4): 0xDE 0xAD 0xBA 0xBE

options=
CoAP-Opt: type=3 , value (size 11): 0x36 0x74 0x69 0x73 0x63 0x68 0x2E 0x61 0x72 0x70 0x61

CoAP-Opt: type=39 , value (size 4): 0x63 0x6F 0x61 0x70

CoAP-Opt: type=11 , value (size 1): 0x6A

payload (size 7): 0xA1 0x05 0x44 0x6E 0x65 0x74 0x31
}
serialized coap (size 36):

0x54 0x02 0xBA 0xAD 0xDE 0xAD 0xBA 0xBE 0x3B 0x36 0x74 0x69 0x73 0x63 0x68 0x2E 0x61 0x72 0x70 0x61 0x81 0x6A 0xD4 0x0F 0x63 0x6F 0x61 0x70 0xFF 0xA1 0x05 0x44 0x6E 0x65 0x74 0x31

And once it has been secured by OSCORE (the OSCORE option + inner/outer code + potential payload marker bytes (0xFF) added to it... +8 bytes of MAC), it looks like this:

OSCORE-Message:{
version=1 , type=1 , TKL=4, Code=2, messageID=47789 ,token (size 4): 0xDE 0xAD 0xBA 0xBE

options=
CoAP-Opt: type=3 , value (size 11): 0x36 0x74 0x69 0x73 0x63 0x68 0x2E 0x61 0x72 0x70 0x61

CoAP-Opt: type=21 , value (size 12): 0x19 0x15 0x08 0xAA 0xBB 0xCC 0xDD 0xEE 0xFF 0x0A 0x0B 0x00

payload (size 25): 0x5E 0x6C 0x59 0x4C 0xE8 0x11 0xBB 0x23 0x7D 0xD1 0xC8 0x9A 0x07 0x79 0xD7 0x96 0x2F 0x46 0x83 0x43 0x41 0x35 0xF8 0x4B 0xEA
}

serialized oscore (size 60):

0x54 0x02 0xBA 0xAD 0xDE 0xAD 0xBA 0xBE 0x3B 0x36 0x74 0x69 0x73 0x63 0x68 0x2E 0x61 0x72 0x70 0x61 0xDC 0x05 0x19 0x15 0x08 0xAA 0xBB 0xCC 0xDD 0xEE 0xFF 0x0A 0x0B 0x00 0xFF 0x5E 0x6C 0x59 0x4C 0xE8 0x11 0xBB 0x23 0x7D 0xD1 0xC8 0x9A 0x07 0x79 0xD7 0x96 0x2F 0x46 0x83 0x43 0x41 0x35 0xF8 0x4B 0xEA


This is already a sizeable message, even though it doesn't really contain any data, we have to remember that in our previous estimation of 66 available bytes, we counted the securing of the 802.15.4 frames (of size 6+8=14 bytes), which is not present for this message since it is exchanged on the unsecured part of the network between the pledge and the JP.

Therefore we are still ~ 20 bytes away from the actual limit here, but if 16-byte IPv6 addresses (instead of 8-byte) had been used this message would be on the brink of needing fragmentation.


The translation in the JP removes the "6tisch.arpa" (size 11+1) option, it thus reduces the size of the message by 12 bytes.
However it also needs to add the stateless proxy option:
The stateless proxy option value is unspecified (as it should be), but it MUST contain at least a timestamp/sequence number, so let's say a 4-byte integer, and it should logically at least contain the MAC address of the joining node, so an 8-byte address. In the end we end up with a ~13-byte (12+1 for the option 'header') stateless proxy option.
Thus **after translation in the JP**, the message is of size 60-11+13= **62 bytes**, and this is **dangerously close to the limit we saw before**.

-----JoinRequest transfer by JP-----

CoAP-Message:{
version=1 , type=1 , TKL=4, Code=2, messageID=47789 ,token (size 4): 0xDE 0xAD 0xBA 0xBE

options=
CoAP-Opt: type=21 , value (size 12): 0x19 0x15 0x08 0xAA 0xBB 0xCC 0xDD 0xEE 0xFF 0x0A 0x0B 0x00

CoAP-Opt: type=55 , value (size 12): 0x61 0x62 0x62 0x61 0x2E 0x69 0x73 0x2E 0x62 0x61 0x63 0x6B

payload (size 25): 0x5E 0x6C 0x59 0x4C 0xE8 0x11 0xBB 0x23 0x7D 0xD1 0xC8 0x9A 0x07 0x79 0xD7 0x96 0x2F 0x46 0x83 0x43 0x41 0x35 0xF8 0x4B 0xEA
}
serialized coap (size 62):
0x54 0x02 0xBA 0xAD 0xDE 0xAD 0xBA 0xBE 0xDC 0x08 0x19 0x15 0x08 0xAA 0xBB 0xCC 0xDD 0xEE 0xFF 0x0A 0x0B 0x00 0xDC 0x15 0x61 0x62 0x62 0x61 0x2E 0x69 0x73 0x2E 0x62 0x61 0x63 0x6B 0xFF 0x5E 0x6C 0x59 0x4C 0xE8 0x11 0xBB 0x23 0x7D 0xD1 0xC8 0x9A 0x07 0x79 0xD7 0x96 0x2F 0x46 0x83 0x43 0x41 0x35 0xF8 0x4B 0xEA

Now the CoJP response is "obviously" going to be bigger, since it actually contains a lot of information, among which at least one 16-byte key...
I chose to take a message that would also contain a 16-byte JRC address of "qwertyuioplkjhgf" (no trailing \0), and an 8-byte assigned pledge address of {0xa1,0xb1,0xc1,0xd1,0xe1,0xf1,0xa2,0xb2} available for one year, i.e. 31450000 seconds.

**We can note here that the requirement for the JRC address to be exactly 16 bytes and not either 2,8 or 16 bytes long seems unreasonnable**, at least 8 bytes could be properly shaved off of this in our example.

The cbor payload in diagnostic notation is:

{
    2: [1, 2, h'112233445566778899AABBCCDDEEFF11'],
    3: [h'A1B1C1D1E1F1A2B2', 31450000],
    4: h'71776572747975696F706C6B6A686766'
}
This gives us the CoAP response:

-----JoinResponse for Node-----

CoAP-Message:{
version=1 , type=1 , TKL=4, Code=68, messageID=47789 ,token (size 4): 0xDE 0xAD 0xBA 0xBE

options=
CoAP-Opt: type=55 , value (size 12): 0x61 0x62 0x62 0x61 0x2E 0x69 0x73 0x2E 0x62 0x61 0x63 0x6B

payload (size 50): 0xA3 0x02 0x83 0x01 0x02 0x50 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 0x99 0xAA 0xBB 0xCC 0xDD 0xEE 0xFF 0x11 0x03 0x82 0x42 0xA1 0xB1 0x1A 0x01 0xDF 0xE3 0x90 0x04 0x50 0x71 0x77 0x65 0x72 0x74 0x79 0x75 0x69 0x6F 0x70 0x6C 0x6B 0x6A 0x68 0x67 0x66
}
serialized coap (size 73):

0x54 0x44 0xBA 0xAD 0xDE 0xAD 0xBA 0xBE 0xDC 0x2A 0x61 0x62 0x62 0x61 0x2E 0x69 0x73 0x2E 0x62 0x61 0x63 0x6B 0xFF 0xA3 0x02 0x83 0x01 0x02 0x50 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 0x99 0xAA 0xBB 0xCC 0xDD 0xEE 0xFF 0x11 0x03 0x82 0x42 0xA1 0xB1 0x1A 0x01 0xDF 0xE3 0x90 0x04 0x50 0x71 0x77 0x65 0x72 0x74 0x79 0x75 0x69 0x6F 0x70 0x6C 0x6B 0x6A 0x68 0x67 0x66
and when secured by OSCORE:

OSCORE-Message:{
version=1 , type=1 , TKL=4, Code=68, messageID=47789 ,token (size 4): 0xDE 0xAD 0xBA 0xBE

options=
CoAP-Opt: type=21 , value (size 0):

CoAP-Opt: type=55 , value (size 12): 0x61 0x62 0x62 0x61 0x2E 0x69 0x73 0x2E 0x62 0x61 0x63 0x6B

payload (size 60): 0x70 0x3A 0xFB 0x0F 0xC6 0xB3 0x95 0x8E 0x29 0x58 0x6E 0x09 0x0C 0xE5 0xA7 0x5D 0x64 0x86 0xB3 0x61 0xBF 0x94 0xAB 0x24 0x7B 0xDD 0x56 0x85 0x55 0x9F 0x43 0xAC 0x47 0x41 0x9E 0xA0 0xD9 0x60 0x73 0xDD 0x8A 0x32 0x58 0xF8 0xCF 0x85 0xD5 0x29 0xFA 0x5D 0xC1 0x6E 0x82 0x4A 0x99 0xEC 0x3D 0x8A 0x77 0x63
}
serialized oscore (size 85):

0x54 0x44 0xBA 0xAD 0xDE 0xAD 0xBA 0xBE 0xD0 0x08 0xDC 0x15 0x61 0x62 0x62 0x61 0x2E 0x69 0x73 0x2E 0x62 0x61 0x63 0x6B 0xFF 0x70 0x3A 0xFB 0x0F 0xC6 0xB3 0x95 0x8E 0x29 0x58 0x6E 0x09 0x0C 0xE5 0xA7 0x5D 0x64 0x86 0xB3 0x61 0xBF 0x94 0xAB 0x24 0x7B 0xDD 0x56 0x85 0x55 0x9F 0x43 0xAC 0x47 0x41 0x9E 0xA0 0xD9 0x60 0x73 0xDD 0x8A 0x32 0x58 0xF8 0xCF 0x85 0xD5 0x29 0xFA 0x5D 0xC1 0x6E 0x82 0x4A 0x99 0xEC 0x3D 0x8A 0x77 0x63


Here the message just **NEEDS to be fragmented one way or another**, no questions asked.


(**Nota bene:**

Of course all of this is just preliminary results based on a test implementation that probably has a few bugs, however the change to the message size once those are ironed-out shouldn't change much and the global idea will quite probably stay the same)




Concerns about the CoJP message size, the need for BLOCK-WISE options and the use of NON-confirmable messages<https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues/19/concerns-about-the-cojp-message-size-the>
bitbucket.org



TriaGnoSys GmbH, Registergericht: München HRB 141647, Vat.: DE 813396184 Geschäftsführer: Núria Riera Díaz, Peter Lewalter
________________________________


This email and any files transmitted with it are confidential & proprietary to Zodiac Inflight Innovations. This information is intended solely for the use of the individual or entity to which it is addressed. Access or transmittal of the information contained in this e-mail, in full or in part, to any other organization or persons is not authorized.