Re: [PATCH net] net: l2tp: reduce log level when passing up invalid packets
From: Jakub Kicinski <kuba@kernel.org>
Date: 2021-02-22 22:32:36
Also in:
lkml
On Mon, 22 Feb 2021 17:40:16 +0100 Matthias Schiffer wrote:
quoted
quoted
This will not be sufficient for my usecase: To stay compatible with older versions of fastd, I can't set the T flag in the first packet of the handshake, as it won't be known whether the peer has a new enough fastd version to understand packets that have this bit set. Luckily, the second handshake byte is always 0 in fastd's protocol, so these packets fail the tunnel version check and are passed to userspace regardless. I'm aware that this usecase is far outside of the original intentions of the code and can only be described as a hack, but I still consider this a regression in the kernel, as it was working fine in the past, without visible warnings.I'm sorry, but for the reasons stated above I disagree about it being a regression.Hmm, is it common for protocol implementations in the kernel to warn about invalid packets they receive? While L2TP uses connected sockets and thus usually no unrelated packets end up in the socket, a simple UDP port scan originating from the configured remote address/port will trigger the "short packet" warning now (nmap uses a zero-length payload for UDP scans by default). Log spam caused by a malicous party might also be a concern.
Indeed, seems like appropriate counters would be a good fit here? The prints are both potentially problematic for security and lossy.