[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 #17 from Philip Prindeville <philipp at redfish-solutions.com>  ---
(In reply to comment #16)
> You're confusing the settings for the daemon (sshd_config, which
> obviously only root should be able to change) with the settings for the
> client (ssh_config) when someone makes an outbound connection.

I'm not confusing them at all, and if you reread my comments you'll see
that I explicitly said "make the compelling argument to me that users
should be allowed to have their own .sshd_config file".  Not sure what
was unclear about that.

Moving on...

> The settings for the daemon can't be bypassed since obviously it
> requires root privileges to launch it to listen on port 22.

Or you could read all users' settings and just use the most permissive
of the union...  Or individual users could run their own instances on
ports other than 22...  since your argument was that users could have
their own binary clients, I'm saying why not take it a step further and
have them run their own servers...


> The settings for the client should be freely settable by the user, just
> as it is with the -S option for telnet. I have no problems with having
> smart defaults in ssh_config, but they definitely should be able to be
> overridden.

You're missing the point that this is largely IRRELEVANT.  The network
doesn't care if the client or the server is sending mislabeled packets,
they both have exactly the same potential to be disruptive to other
traffic types like VoIP and IPTV.

I would make the argument that letting the user (and client) set the
encryption algorithm, cipher strength, etc. was a serious mistake.  If
the user uses too weak an encryption standard, his connection can be
eavesdropped or even subverted.

> In the end, there's no sense having a setting which provides no
> security whatsoever (but looks like it does). If a user is malicious,
> they can compile their own ssh client with the settings they want and
> bypass your config anyways. Since the kernel doesn't enforce any
> privileges on the setting of the DSCP markings, you shouldn't either.
> Thus it only makes sense to provide a configurable default.

Did you read comment #9?

> Keep in mind it's up to the network to trust and enforce DSCP markings,
> so that's the proper place for these kind of access controls to appear.
> Otherwise you'll need to convince the various *nix vendors to require
> privileges on setting DSCP markings.

Again, you're missing the obvious: the settings are more easily and
better trusted when they're set by someone who actually had a hand in
setting the site network policy!  They are more likely to work.

You're thinking of these as a per-host setting that only affects the
host, and they're not.  It's a setting that affects the entire network,
and should be set in a consistent and coherent way organization-wide.

It's not about what the user might set just because he can.  It's about
what should be set by the site administrators because they're actually
the most clueful.

-- 
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.