[gnutls-devel] [sr #108715] DTLS send does not respect MTU

[Andreas Schultz]

Follow-up Comment #4, sr #108715 (project gnutls):

ok, after reading the RFC again, if have to admit that "any" was way to
strong. Most things are there and it just difficult from the documentation to
understand what exactly the application has to implement and what is present
in the library. The examples are also that helpful, as they don't adjust the
MTU in the case or errors. So here is what I found surprising:

>From RFC6347, Section 4.1.1.1:

>   If there is a transport protocol indication (either via ICMP or via a
>   refusal to send the datagram as in Section 14 of [DCCP]), then the
>   DTLS record layer MUST inform the upper layer protocol of the error.

That works only partially. The second part:

>   or via a refusal to send the datagram

does work, the push function would return the error and all is well.
However with datagram sockets, sending an over sized datagram does not always
result in an immediate EMSGSIZE error (at least under linux).

At least under Linux, the EMSGSIZE is only returned if the datagram size
exceeds the CACHED Path MTU. The Path MTU is initially assumed to be the same
as the interface MTU (mostly 1500).

So GNUTLS will not report the proper error in the following scenario:

* initial state: unknown peer, PMTU assumed to be YY
* during handshake a datagram with YY bytes (minus header overhead) is sent,
the writev call will not return an error
* a ICMP Packet Too Big (max size XX bytes) is send from a router in the path
and the packet is lost

This ICMP error is not read nor handled in the DTLS layer. The only indication
the caller gets is after the transmission timer expires and GNUTLS tries to
send the packet again.

>   discovery.  In order to allow connections under these circumstances,
>   DTLS implementations SHOULD follow the following rules:
>
>   -  If the DTLS record layer informs the DTLS handshake layer that a
>      message is too big, it SHOULD immediately attempt to fragment it,
>      using any existing information about the PMTU.

I might be wrong, but as far as I can see, there is no code that queries the
underlying OS for the MTU (getsockopt IP_MTU under Linux) in case of a
EMSGSIZE, nor does there seem to be any code to adjust the MTU. All of this is
left to the application to handle.

>   -  If repeated retransmissions do not result in a response, and the
>      PMTU is unknown, subsequent retransmissions SHOULD back off to a
>      smaller record size, fragmenting the handshake message as
>      appropriate.  This standard does not specify an exact number of
>      retransmits to attempt before backing off, but 2-3 seems
>      appropriate.

It is arguable if this should be part of the library or not.


None of the above is an error, it just is a bit surprising. The manual does
mention it briefly in chapter 6.5.2:

> The “correct” maximum transfer unit can be obtained through a path MTU
discovery mechanism [RFC4821].

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?108715>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/