Subject: [Secdispatch] MTU Size

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Mar 2019 12:54:23 +0000

Hi all,

During the meeting, almost randomly, the design goal of being able to put key exchange messages into the MTU size was brought up. Unfortunately, it was unclear what the MTU size for the key exchange protocol for the different radio technologies is. There was some discussion on the Webex chat but it might be worthwhile to repeat it on the list.

So, what are the size constraints a key exchange protocol has to work with for

  *   6tisch
  *   LoRA WAN
  *   SMS (who cares?)
  *   NB IOT

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 6 Mar 2019 16:00:17 +0100

Hello Hannes,

Thanks for bringing this up. I have to say that until the meeting yesterday
I wasn't aware that "*rap" or "*rappy networks" was an appropriate language
for an interim meeting to describe IoT technologies but maybe it's my short
experience in the IETF that is to blame.

Regarding the overhead, I have put together a google doc summarizing the
overhead in 6TiSCH during the network access authentication and key
exchange. We do need to make a number of assumptions to get to a "concrete"
number that you are requesting, for example how efficiently can we compress
EUI-64s or how many hops are there in the network. I have documented some
reasonable values in the document. Please let me know if you need more
details on this.

https://docs.google.com/document/d/1wLoIexMLG3U9iYO5hzGzKjkvi-VDndQBbYRNsMUlh-k

Mališa

On Wed, Mar 6, 2019 at 1:55 PM Hannes Tschofenig <[email-masked]>
wrote:

> Hi all,
>
>
>
> During the meeting, almost randomly, the design goal of being able to put
> key exchange messages into the MTU size was brought up. Unfortunately, it
> was unclear what the MTU size for the key exchange protocol for the
> different radio technologies is. There was some discussion on the Webex
> chat but it might be worthwhile to repeat it on the list.
>
>
>
>    - 6tisch
>    - LoRA WAN
>    - SMS (who cares?)
>    - NB IOT
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Mar 2019 15:07:47 +0000

Hi Malisa,

Thanks for the numbers for the 6tisch network. If I understand your Excel sheet correctly then the max size a CoAP packet can have on the 6tisch network for uplink communication is 47 bytes and downlink is 45 bytes. The CoAP packet overhead is potentially 25 bytes (without OSCORE and the key management).
This means that we have 20 bytes for OSCORE and key management in 6tisch networks. Is this correct?

Great to hear that you like my comments.

Ciao
Hannes

From: Mališa Vučinić <[email-masked]>
Sent: Mittwoch, 6. März 2019 16:00
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [Secdispatch] MTU Size

Hello Hannes,

Thanks for bringing this up. I have to say that until the meeting yesterday I wasn't aware that "*rap" or "*rappy networks" was an appropriate language for an interim meeting to describe IoT technologies but maybe it's my short experience in the IETF that is to blame.

Regarding the overhead, I have put together a google doc summarizing the overhead in 6TiSCH during the network access authentication and key exchange. We do need to make a number of assumptions to get to a "concrete" number that you are requesting, for example how efficiently can we compress EUI-64s or how many hops are there in the network. I have documented some reasonable values in the document. Please let me know if you need more details on this.

Mališa

On Wed, Mar 6, 2019 at 1:55 PM Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

  *   6tisch
  *   LoRA WAN
  *   SMS (who cares?)
  *   NB IOT

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
Secdispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/secdispatch
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 6 Mar 2019 16:17:47 +0100

The 47 / 45 bytes figure before a packet is fragmented already includes the
CoAP header+options, and this refers to the network access phase. Once the
node joins and does not have to go over a proxy to reach the outside world,
the numbers go up.

Mališa

On Wed, Mar 6, 2019 at 4:07 PM Hannes Tschofenig <[email-masked]>
wrote:

> Hi Malisa,
>
>
>
> Thanks for the numbers for the 6tisch network. If I understand your Excel
> sheet correctly then the max size a CoAP packet can have on the 6tisch
> network for uplink communication is 47 bytes and downlink is 45 bytes. The
> CoAP packet overhead is potentially 25 bytes (without OSCORE and the key
> management).
>
> *From:* Mališa Vučinić <[email-masked]>
> *Sent:* Mittwoch, 6. März 2019 16:00
> *To:* Hannes Tschofenig <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Secdispatch] MTU Size
>
>
>
> Hello Hannes,
>
>
>
> Thanks for bringing this up. I have to say that until the meeting
> yesterday I wasn't aware that "*rap" or "*rappy networks" was an
> appropriate language for an interim meeting to describe IoT technologies
> but maybe it's my short experience in the IETF that is to blame.
>
>
>
> On Wed, Mar 6, 2019 at 1:55 PM Hannes Tschofenig <
> [email-masked]> wrote:
>
> Hi all,
>
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Mar 2019 17:12:18 +0000

*   Once the node joins and does not have to go over a proxy to reach the outside world, the numbers go up.
What are the numbers then?

From: Mališa Vučinić <[email-masked]>
Sent: Mittwoch, 6. März 2019 16:18
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [Secdispatch] MTU Size

The 47 / 45 bytes figure before a packet is fragmented already includes the CoAP header+options, and this refers to the network access phase. Once the node joins and does not have to go over a proxy to reach the outside world, the numbers go up.

Mališa
On Wed, Mar 6, 2019 at 4:07 PM Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi Malisa,

Ciao

Hannes

From: Mališa Vučinić <[email-masked]<mailto:[email-masked]>>
Sent: Mittwoch, 6. März 2019 16:00
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Secdispatch] MTU Size

Hello Hannes,

Mališa

  *   6tisch
  *   LoRA WAN
  *   SMS (who cares?)
  *   NB IOT

Ciao
Hannes

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 7 Mar 2019 14:26:15 -0600

Hi Mališa,

> experience in the IETF that is to blame.

I confess I did not notice comments about "crap networks" during the
interim (well, maybe to describe Richard's hotel wifi), and I like to think
that I would have pushed back on it at the time had I noticed.  (That is, I
don't think it's appropriate language for an IETF meeting.)

> https://docs.google.com/document/d/1wLoIexMLG3U9iYO5hzGzKjkvi-VDndQBbYRNsMUlh-k

Thanks for putting this together; it's good to have these numbers all in
one place.  It might be nice for the IETF archives if a version was
extracted from the gdoc and inlined into a message to the list at some
point, though of course you don't need to do that yourself.

-Ben