TLS 2303 Bytes Packet Limit

[GNotman]

I have been testing out HTTPS with the http_application_update.

I have been able to successfully setup a TLS 1.2 connection, but I was seeing a lot of "Peer closed connection!" warnings after any request was made over the socket.

Swapping the request from GET to HEAD, resulted in a successful response, but of course the actual content was missing.

Upon further investigation, I found that reducing CONFIG_DOWNLOAD_CLIENT_MAX_TLS_FRAGMENT_SIZE from the default 2048 resolved the issue.

Looking further I found that the maximum total response (header + body/content) cannot be larger than 2303 bytes.

The header size is usually about 300-350 bytes in length, but this varies depending on the number of digits in the Content-Range header, and potentially there may be optional headers which might be included or omitted by any specific server.

I am wondering what the source of this limitation is, and more importantly is this limitation fixed/predictable, or could the maximum size be even lower under other circumstances?

I have seen some articles online about how TLS can be sensitive to packet fragmentation, which suggests this limit might be related to the MTU size (2303 is oddly close to the 802.11 MTU)? However, if this size limit for TLS is based on the MTU size, then it may be difficult to determine the maximum safe size to use. I expect the MTU size might change between network operators, and might even be route specific.

Alternatively, if this limit is related to some buffer size in modem firmware, then I should be able to specify a safe size (with a bit of slack for any variability in the header size).

Running the same application without TLS, I have no issue receiving 4096 byte size fragments of the file.

[Martin Lesund]

Hi GNotman,
The problem is that the HTTP-header is not a part of "CONFIG_DOWNLOAD_CLIENT_HTTP_FRAG_SIZE_2048",

so the fragment at 2048 + the HTTP header will be to big for the modem to receive.

Optimally you should use the fragment_size here: https://github.com/nrfconnect/sdk-nrf/blob/master/include/net/fota_download.h#L106

And do it dynamically as we do it in e.g. the Azure FOTA Sample: https://github.com/nrfconnect/sdk-nrf/blob/master/subsys/net/lib/azure_fota/azure_fota.c#L529 

Best regards;
Martin L.

[GNotman]

Hi Martin,

Thanks, I understand that I can control the amount of file data requested in the Range header. I have been able to successfully download the FW file by applying a fragment size limit which leaves enough space for the header.

However, my main question is what is imposing the 2303 byte limit, and equally important is that limit constant?

[Martin Lesund]

Hi GNotman,
It documented as a limitation in the mfw release notes.
That can be found in the .zip for the modem firmware.

*** Limitations
***************
- TLS/DTLS
    - Up to three simultaneous TLS/DTLS connections are possible.
    - Server certificate expiry time is not verified.
    - pkcs#8 is not supported.
    - Absolute maximum number of supported credentials is 32. The actual amount depends on size of
      credentials as memory area reserved for credentials may be a limiting factor as well.
    - DTLS supports PSK authentication only.
    - 2kB secure socket buffer size.
- Maximum number of raw sockets is 4.
- User plane data is supported in Cat M1 mode only.

It is listed 2kB, however 2303 is for the server you are connected to. 
There are some variances in overhead for TLS, but documented limit is set to 2kB.
Setting higher could be possible, but is "out of spec" and therefore you could see some issues.

best regards,
Martin L.