LWN: Comments on "Better visibility into packet-dropping decisions"

Better visibility into packet-dropping decisions

gdt — Thu, 07 Jul 2022 06:48:15 +0000

Even using a silly MD5 password is worthwhile, since the spray of failed MD5 packets (and thus log messages) prior to the BGP connection reset make it plain that the cause is network abuse.
Cynically, if the BGP connection isn't using a long, random, unique key prior to that outage, then it will be afterwards :-)

Linux counting failed MD5 packets is excellent, as network operators investigating BGP connection issues can check that the counter is the expected zero.

For the longest time vendors were promoting IPsec as the replacement for the TCP MD5 option, but operationally the overhead of configuration and customer education was too high. More recently TCP-AO (Authentication Option) offers a similar mechanism to the MD5 option, but with modern cyrptographic algorithms.

For external BGP connections the TTL security check also offers good protection from network abuse. Customers generally seem to be able to configure that without much difficulty.

return -Exxxxx;

njs — Fri, 11 Mar 2022 08:44:05 +0000

Someone actually implemented this and released the patches so you can to:

https://github.com/nviennot/linux-trace-error

Better visibility into packet-dropping decisions

rstonehouse — Wed, 09 Mar 2022 17:55:45 +0000

See https://github.com/idosch/mlxsw-1/wiki/Packet-Drops-Monit... which talks about using https://github.com/nhorman/dropwatch

(Also there is a systemtap script to do something similar. See https://sourceware.org/git/?p=systemtap.git;a=blob;f=test...)

Better visibility into packet-dropping decisions

gfa — Sun, 06 Mar 2022 20:16:13 +0000

> The kernel currently contains a "drop_monitor" functionality that was introduced in the 2.6.30 kernel back in 2009

Does anybody know any tool that can use this functionality?

thanks

Better visibility into packet-dropping decisions

amarao — Wed, 02 Mar 2022 09:58:17 +0000

I do understand you. When a new session is agreed with a party, a password is provided together with IP and AS number. Even md5 is considered hopelessly broken, for the sake of RST protection it is more than enough, because even 32 additional bits pushes attack from `feasible` to `unfeasible` realm.

Better visibility into packet-dropping decisions

MaZe — Wed, 02 Mar 2022 03:25:24 +0000

eh, most uses of tcp md5 are pretty pointless because they just use well known passwords...

Better visibility into packet-dropping decisions

amarao — Sun, 27 Feb 2022 23:43:28 +0000

Md5 for TCP is really a single good protection against RST attacks on BGP. You can filter ingress, but there always is a risk to miss something. Having MD allow to have month-long tcp session without risks of malicious rst.

Better visibility into packet-dropping decisions

shemminger — Sun, 27 Feb 2022 21:26:03 +0000

In order to see packets dropping because CPU can't keep up you have to look at the hardware statistics.
This is reported in rx_missed. Not sure if there more that HW can tell you.
There are lots of rx_dropped places in drivers, these could/should be instrumented.

return -Exxxxx;

jengelh — Sun, 27 Feb 2022 09:17:04 +0000

Good thing the main kernel has just two `case EINVAL` across its ~30 million lines.

return -Exxxxx;

roc — Sun, 27 Feb 2022 03:21:29 +0000

That would surely fail to build with EINVAL being used in a case label.

return -Exxxxx;

johill — Sat, 26 Feb 2022 19:05:13 +0000

In most files you can even just

#define EINVAL ({printk(...); 22;})

if you really want :-)

Better visibility into packet-dropping decisions

johill — Sat, 26 Feb 2022 19:03:21 +0000

Check out commit 2d4bc93368f5a ("netlink: extended ACK reporting") which added the bare minimum infrastructure a long time ago, and you can find many users of NL_SET_ERR_MSG/GENL_SET_ERR_MSG (and similar macros) these days.

It supports reporting a string (error message), a pointer to a bad attribute, and if NL_SET_ERR_MSG_ATTR_POL was used (which it is in the general policy-based parsing) will even return the policy for the attribute back to userspace to explain why the attribute failed (e.g. if it's NLA_RANGE(U32, 1,2) and you gave a value 3).

return -Exxxxx;

jreiser — Sat, 26 Feb 2022 15:20:14 +0000

There is a need for a facility to locate at run time every failed subroutine call. The source code be edited with sed so that return -Exxxxx; becomes return ErrorCode(Exxxxx); with a default macro definiton something like

     #ifndef ErrorCode
     #define ErrorCode(errnum) -(errnum)
     #endif

Then the determined investigator can re-compile selected source files with something like

     #define ErrorCode(errnum) myErrorDiagnostic(errnum, __builtin_return_address(0), __FUNCTION__, __LINE__)

and supply a definition for the added subroutine myErrorDiagnostic. Of course there are a handful of cases where error numbers are variables or the syntax is complex, and also a few places where simple automated editing fails. Rate limiting the reporting can be a problem. But I did this once, and got the answer I wanted.

Better visibility into packet-dropping decisions

tititou — Sat, 26 Feb 2022 05:52:11 +0000

Hi,
Can you provide a link or an example about it ?

Better visibility into packet-dropping decisions

alison — Sat, 26 Feb 2022 04:49:13 +0000

Assuredly knowing when packets are dropped because NAPI polling isn't keeping up with what's incoming would be valuable. Yeah, I'm sure that patches and test data would be welcome.

Better visibility into packet-dropping decisions

shemminger — Sat, 26 Feb 2022 02:04:21 +0000

Netlink was enhanced to provide error messages (not just errno).
Many places have it, but lots still need work -- volunteers wanted.

Better visibility into packet-dropping decisions

atnot — Fri, 25 Feb 2022 20:29:24 +0000

Has this been considered for other things too? I regularly find myself wishing something like this existed for figuring out which of the many mechanism an EPERM/EACCES was caused by (unix permissions, acl, selinux and other LSMs, file systems, dm layers, cgroups, namespaces, seccomp, capabilities, API misuse, ...)