Re: Current behavior to set DSCP EF code point by default is harmful

Well... since Trixie/Excalibur (Debian 13 / Devuan 6) I've seen some
SSH network "hangs" which might just be explained by these bits and
the networks I cross.

And there had been other *suprises* with Trixie with OpenSSH 10.1 vs
9.6 in Bookworm... like the builtin too aggressive (IMhO) blocking,
but that is not the issue I'd like to raise  here:

On Fri, Apr 10, 2026 at 4:09 AM Theo de Raadt <[email protected]> wrote:
> We deployed this in OpenSSH incrementally and substantially for 6
> months,

The "fun" with especially RedHat and Debian, is they don't do that
much "incremental" and are quite bang releases, thus, a claim like
this doesn't quite hold water as we see it not when it get's released,
but when the version after this baked in in release get released by
the distros.

>  and by my recollection have heard only two concerns previously

And here the flood starts as Trixie in PVE9 are now getting full
installs and upgrades.

> which both turned out to be incorrect ISP segment configurations, which
> were corrected after the customer reached out.  One of them was only on
> certain segments of the ISP, the other I don't believe we got details
> on.  One configuration was so incorrect the other trafffic was also
> being blackholed.  Screaming at ISPs who deploy it incorrectly is more
> valuable effort, not at tiny stack software which often uses it for
> critical traffic.

hmm... yeah, I don't disagree on the "critical", but more on the
problem that when that critical connection does a `sh running-conf` or
a `sh ip route` and floods the network, it's not the express/critical
keyboard latency anymore...

> I think we can afford to wait for the community to understand that the
> majority of SSH traffic is minimal, generally either trivial volume or
> for critical management,

hmmm... again, though there are water in that argument, SSH traffic
quickly can get the majority when a tcpdump is execute in the shell..
and yes, from a network management perspective, those are common
patterns in my life doing hosting and managing/involved with IXP
network.

> is as valuable as voice, if not more.  To me,

the problem is: how do you tell the real differences between when that
interactive session turns non-interactive? When is the htop display
not keyboard interactive anymore?

> that's a better future.  EF isn't just cat videos, otoh I suspect it
> contains almost no 911/112 calls.

For the better part I'd advocate that you have this as opt-in not
opt-out (or baked in) behaviour, as then the network/etc. operator can
decide themselves when/if a specific router/switch does need the EF
bit or not. 'cause several times those same network operators would be
pushing configs  emass (or other information gathering scripts using
keyboard interactive expect sessions) that would want  to have it
turned it off during those sessions as a default (not the opposite)


I do hope that Theo & Damien would reconsider this and make it opt-IN
settings for those that feel/have the need/use to enable it as they
require it, and not a blanket aggresive setting as the brute force
blocking (an example that I will use as even SSHguard that I dpeloy as
default to handle those, aren;t as aggresive, and still blocks a very
higher percentage for longer using the firewalling rules)
_______________________________________________
openssh-unix-dev mailing list
[email protected]
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev