Add support for Path MTU Discovery (PMTUD)

[stv0g]

cunicu currently attempts at auto-detecting a correct tunnel MTU by taking the link/route MTUs into consideration.
However, this will not be optimal as the path MTU can be smaller than the link MTUs.
Such cases can be detected via PMTUD.

However, there is another twist to this.
In larger WireGuard meshes we somehow need to coordinate all peers to use the smallest of all peer-to-peer path MTUs.
This can be achieved via our signaling backend by including a detected path MTU into the peer descriptions.

[stv0g]

• https://www.rfc-editor.org/rfc/rfc1191
• https://www.rfc-editor.org/rfc/rfc4821
• https://manpages.debian.org/stretch/manpages/ip.7.en.html
  • IP_MTU
  • IP_MTU_DISCOVER

[stv0g]

See also:

• https://lists.zx2c4.com/pipermail/wireguard/2018-April/002651.html
• https://datatracker.ietf.org/doc/html/rfc8899

[stv0g]

There is a quite helpful discussion on the WireGuard mailing list which I have linked above.
Similar discussions have been held by the IPsec community which deals with similar issues.

The conclusion of these discussions is, that tunnel protocols should not relay on ICMP packet-to-big (PTB) messages from outside the tunnel as these are not authenticated and can be forged. This would allow attackers to purposefully reduce the tunnel MTU to perform a DoS attack or infer information about the encrypted payloads.

Performing classing PMTUD through the tunnel is not working. Instead PLMTUD seems the way to go here.

I plan to implement PLMTUD in cunicu according to the current IETF draft on Packetization Layer Path MTU Discovery for Datagram Transports.