[Bug 1733] Enhance support for QoS (ToS) by supporting DSCP/CS and adding option

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #15 from Philip Prindeville <philipp at redfish-solutions.com>  ---
(In reply to comment #14)
> Just a further note that having the "system-wide config restriction" is
> pretty useless if anyone can copy their own binary onto the system and
> bypass it. I suggest having a default in /etc/ssh/ssh_config, and can
> can be overridden by the user either in their local config or as an
> argument on the command line.

And... this is why I think that would be a bad idea.

You're fairly typical, I'd say, of most users.  You understand what QoS
settings are for, and how they can be changed, and what ultimately
they're expected to do.

But the finer details would seem to have been missed.

There are no "standard" profiles for interpreting QoS markings, for
instance.  There's a proposal (RFC 4594) for uniform markings that
ISP's and Enterprises are free to implement, or equally free not to.

So you can set your QoS bits to AF22 thinking that this will do what
you want, and there's a good chance you'd be wrong: the only person who
knows for sure is the Enterprise network architect that provisioned the
entire infrastructure.  Everyone else is just pulling numbers out of
their hat.

For *exactly* the same reasons that "PermitRootLogin",
"PermitEmptyPasswords", and "IgnoreRhosts" aren't user-settable
(because end-users shouldn't be making decisions that potentially
impact performance and/or security organization-wide), the QoS bits
shouldn't be user-settable either.

If users can wreak havoc by having their own profile containing
"PermitRootLogin yes/PermitEmptyPasswords yes", then be aware that they
can negatively impact organization-wide networking (especially VoIP and
IPTV services) by making poor choices elsewhere.

Make the compelling argument to me that users should be allowed to have
their own .sshd_config file, and put into it those latter two settings,
and I'll concede that by the same reasoning they should be allowed to
set their own QoS policy.

But the bottom line is that QoS markings are as much a part of a site's
singular and standardized architectural policy as the type and degree
of enforcement of their security measures.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.