netdev - RE: [PATCHv2 net-next 00/14] sctp: implement RFC8899: Packetization Layer Path MTU Discovery for SCTP transport

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cfaa01992d064520b3a9138983e8ec41@AcuMS.aculab.com>
Date:   Tue, 22 Jun 2021 22:13:14 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Xin Long' <lucien.xin@...il.com>,
        network dev <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        "linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>
Subject: RE: [PATCHv2 net-next 00/14] sctp: implement RFC8899: Packetization
 Layer Path MTU Discovery for SCTP transport

From: Xin Long
> Sent: 22 June 2021 19:05
> 
> Overview(From RFC8899):
> 
>   In contrast to PMTUD, Packetization Layer Path MTU Discovery
>   (PLPMTUD) [RFC4821] introduces a method that does not rely upon
>   reception and validation of PTB messages.  It is therefore more
>   robust than Classical PMTUD.  This has become the recommended
>   approach for implementing discovery of the PMTU [BCP145].
> 
>   It uses a general strategy in which the PL sends probe packets to
>   search for the largest size of unfragmented datagram that can be sent
>   over a network path.  Probe packets are sent to explore using a
>   larger packet size.  If a probe packet is successfully delivered (as
>   determined by the PL), then the PLPMTU is raised to the size of the
>   successful probe.  If a black hole is detected (e.g., where packets
>   of size PLPMTU are consistently not received), the method reduces the
>   PLPMTU.

This seems to take a long time (probably well over a minute)
to determine the mtu.

What is used for the actual mtu while this is in progress?

Does packet loss and packet retransmission cause the mtu
to be reduced as well?

I can imagine that there is an expectation (from the application)
that the mtu is that of an ethernet link - perhaps less a PPPoE
header.
Starting with an mtu of 1200 will break this assumption and may
have odd side effects.
For TCP/UDP the ICMP segmentation required error is immediate
and gets used for the retransmissions.
This code seems to be looking at separate timeouts - so a lot of
packets could get discarded and application timers expire before
if determines the correct mtu.

Maybe I missed something about this only being done on inactive
paths?

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)