Subject: [core] draft-ietf-core-coap-tcp-tls message length question

From: Jim Schaad <[email-masked]>
Date: Tue, 2 May 2017 09:04:08 +0200

I am trying to decide if the maximum message size for coaps+tcp is pre or
post TLS.  I would assume that it would be pre-TLS to match with the message
size requirements of coaps, however the minimal guidance on estimating the
size of the TLS overhead is not in this document while it is in RFC 7252.
Since there are multiple buffers that might need to be dealt with, and most
TLS implementations are going to have an internal buffer as well, it is not
completely clear to me what is being stated.

Jim

---

From: "weigengyu" <[email-masked]>
Date: Tue, 2 May 2017 16:10:44 +0800

Hi Jim,

I am not sure fully understood the message and its options.
> post TLS.
> I would assume that it would be pre-TLS to match with the message size 
> requirements of coaps,
> however the minimal guidance on estimating the size of the TLS overhead is 
> not in this document while it is in RFC 7252.

It is pre-TLS in our implementation which is based on extending CF.CoAP in 
accordance with the former version draft.
The maximum message size for coaps+tcp is determined when binding the 
protocol stack.

By the way, it also is tried to have only one CoAP message format of RFC7252 
over any transport facilities.
A CoAP message length option is defined privately and carried in a CoAP 
message of RFC7252.
The delimiter of one CoAP message is clear for CoAP/UDP, CoAP/TCP, or 
CoAP/WSS.
This is not a standard.
It works, and not many CoAP ACK overheads are felt.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Jim Schaad
Sent: Tuesday, May 02, 2017 3:04 PM
To: [email-masked]
Cc: 'core'
Subject: [core] draft-ietf-core-coap-tcp-tls message length question

Jim

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 May 2017 16:22:34 +0200

> I am trying to decide if the maximum message size for coaps+tcp is pre or

Good question. RFC 7252 Section 4.6 discusses message sizes, but never really comes clean what exactly that means, because it doesn’t need to.
But the progression from 1280 to 1152 to 1024 for MTU, message size, payload size kind of makes clear that this is the size of the CoAP message.
Which is OK, as “message size” is not very different from “size of the message”, exactly what’s meant.

> I would assume that it would be pre-TLS to match with the message

TCP removes the need to consider MTU that much:
TCP segmentation is much more well-behaved than the IP (or 6LoWPAN adaptation layer) fragmentation needed for UDP.

On the other hand, there is still a bit of space between 1152 and 1280 for IP, TCP, TLS, so segmentation for default-maximum-size messages is not necessary.

> completely clear to me what is being stated.

If there were an intention to include TLS overheads inside the figure for message size, this would run into trouble quickly, because there is no way for the CoAP implementation to control how many TLS headers the TLS layer spends for one message.  You can be optimistic and say “1”, but that is just that, optimistic (or the actual number might even be “0.5” if there is some concurrency).

So, clearly, the sensible interpretation, again, is for “message size” to be the size of the CoAP message (header/length/token, Options, payload marker, payload).
(Note that, for a ~ 1152 byte message, the size of a CoAP over TCP message is exactly the same as that of a CoAP over UDP message; see Figure 7 of draft-ietf-core-coap-tcp-tls.)

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 4 May 2017 13:17:41 +0200

Hi Jim,

similarly to Carsten and Gengyu I would argue that the message size
refers to the payload of the CoAP message since this is something the
CoAP layer would know. Our mbed TLS stack also provides information to
the application about the level of "expansion" due to encryption but
then there is potentially also padding involved (although more
theoretically than in practice to conceal the real size of the message).

Ciao
Hannes