setsockopt(IP_TOS) being privileged or distinct capability?

setsockopt(IP_TOS) being privileged or distinct capability?

[Philip Prindeville]

Does anyone else think that setsockopt(IP_TOS) should be a privileged 
operation, perhaps using CAP_NET_ADMIN, or maybe even adding separate 
granularity as CAP_NET_TOS?

-Philip

Re: setsockopt(IP_TOS) being privileged or distinct capability?

[Alexander Clouter]

Philip Prindeville <philipp_subx@redfish-solutions.com> wrote:
>
> Does anyone else think that setsockopt(IP_TOS) should be a privileged 
> operation, perhaps using CAP_NET_ADMIN, or maybe even adding separate 
> granularity as CAP_NET_TOS?
> 
I really would prefer not having to run telnet and ssh *clients* as 
root. :)

Cheers

-- 
Alexander Clouter
.sigmonster says: Someday your prints will come.
                  		-- Kodak

Re: setsockopt(IP_TOS) being privileged or distinct capability?

[Philip Prindeville]

On 7/3/10 12:55 PM, Alexander Clouter wrote:
> Philip Prindeville<philipp_subx@redfish-solutions.com>  wrote:
>    
>> Does anyone else think that setsockopt(IP_TOS) should be a privileged
>> operation, perhaps using CAP_NET_ADMIN, or maybe even adding separate
>> granularity as CAP_NET_TOS?
>>
>>      
> I really would prefer not having to run telnet and ssh *clients* as
> root. :)
>
> Cheers
>
>    

Don't ping and traceroute -I currently run as root?

Re: setsockopt(IP_TOS) being privileged or distinct capability?

[Alexander Clouter]

Hi,

* Philip Prindeville <philipp_subx@redfish-solutions.com> [2010-07-03 17:07:52-0600]:
>
> On 7/3/10 12:55 PM, Alexander Clouter wrote:
>>    
>>> Does anyone else think that setsockopt(IP_TOS) should be a privileged
>>> operation, perhaps using CAP_NET_ADMIN, or maybe even adding separate
>>> granularity as CAP_NET_TOS?
>>>
>>>      
>> I really would prefer not having to run telnet and ssh *clients* as
>> root. :)
>
> Don't ping and traceroute -I currently run as root?
>
Indeed, but I have no idea what that has to do with ToS/DSCP flags?

ping and (old skool) traceroute use ICMP where you need to open a 
privileged socket; to send and receive ICMP packets.  Opening a UDP/TCP 
is an unprivileged operation and so is setsockopt(IP_TOS).

I'm guessing, if you excuse me Google-stalking you), this is all linked 
to:

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

You have to bear in mind ToS is a marking that userland can utilise to 
request that the network provides it with a particular QoS, this does 
not mean for an instant the network has to honour that (I know my ISP 
does not and neither does my work network I sysadmin for)...otherwise 
nothing would stop me using:

iptables -t mangle -I POSTROUTING -j DSCP --set-dscp-class EF

QoS is meaningless unless you place boundaries on the policies; the 
ToS/DSCP marking should only be used as a *hint* for classification of 
traffic flows.

For example, 'interactive' and 'low latency' (in the case of SSH or 
telnet) should not exceed 10kB/s...unless you like to play 0verkill :)  
Anything marking it's traffic as interactive but shutting traffic at 
500kB/s is obviously telling lies.  If you build your policing rules to 
blindly accept whatever is in the ToS/DSCP field, you are configuring a 
DoS vector on your network.

Cheers

-- 
Alexander Clouter
.sigmonster says: A rolling stone gathers momentum.

Re: setsockopt(IP_TOS) being privileged or distinct capability?

[Philip Prindeville]

On 7/3/10 5:48 PM, Alexander Clouter wrote:
> Hi,
>
> * Philip Prindeville<philipp_subx@redfish-solutions.com>  [2010-07-03 17:07:52-0600]:
>    
>> On 7/3/10 12:55 PM, Alexander Clouter wrote:
>>      
>>>
>>>        
>>>> Does anyone else think that setsockopt(IP_TOS) should be a privileged
>>>> operation, perhaps using CAP_NET_ADMIN, or maybe even adding separate
>>>> granularity as CAP_NET_TOS?
>>>>
>>>>
>>>>          
>>> I really would prefer not having to run telnet and ssh *clients* as
>>> root. :)
>>>        
>> Don't ping and traceroute -I currently run as root?
>>
>>      
> Indeed, but I have no idea what that has to do with ToS/DSCP flags?
>    

The logic being that if having a RAW socket requires privilege, but it's 
necessary to have reasonable security for user-invokable programs... and 
we manage to do this without too much trouble for those to programs, 
then it shouldn't be an undue hardship to do the same for ssh.

> ping and (old skool) traceroute use ICMP where you need to open a
> privileged socket; to send and receive ICMP packets.  Opening a UDP/TCP
> is an unprivileged operation and so is setsockopt(IP_TOS).
>    

Right.  And I'm saying because of the potentially disruptive nature of 
setsockopt(IP_TOS), perhaps it should require privilege.


> I'm guessing, if you excuse me Google-stalking you), this is all linked
> to:
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=1733
>    

That would be a very good guess.

And google-stalking is fine.  I draw the line at leaving dead cats at my 
front door.


> You have to bear in mind ToS is a marking that userland can utilise to
> request that the network provides it with a particular QoS, this does
> not mean for an instant the network has to honour that (I know my ISP
> does not and neither does my work network I sysadmin for)...otherwise
> nothing would stop me using:
>    

I understand that.  That's part of the reason that I've submitted 
patches for APR, Apache, Thunderbird, Firefox, Proftpd, Curl, wget, 
etc.  There is pressure within certain technical groups to get ISP's to 
voluntarily implement RFC-4594... that's the carrot.  The stick being 
FCC heavy-handed regulation of the ISP's if they don't.

Once QoS markings actually *are* implemented in carrier networks, the 
potential for abuse is non-insignificant.  Hence the suggestion to make 
it privileged.


> iptables -t mangle -I POSTROUTING -j DSCP --set-dscp-class EF
>    

Except that "iptables" is also a privileged operation.


> QoS is meaningless unless you place boundaries on the policies; the
> ToS/DSCP marking should only be used as a *hint* for classification of
> traffic flows.
>    

Like I said, there's an effort to push the ISP's into implementing 
RFC-4594 widespread.  Their previous arguments for not doing so were (a) 
most software doesn't implement QoS (hence the scrub I did above), and 
(b) there were no standard markings.  RFC-4594 attempts to impose a 
standard.


> For example, 'interactive' and 'low latency' (in the case of SSH or
> telnet) should not exceed 10kB/s...unless you like to play 0verkill :)
> Anything marking it's traffic as interactive but shutting traffic at
> 500kB/s is obviously telling lies.  If you build your policing rules to
> blindly accept whatever is in the ToS/DSCP field, you are configuring a
> DoS vector on your network.
>
> Cheers
>
>    

When you say "interactive" and "low latency" are you referring to the 
RFC-791 mappings for those, or to the RFC-4594 mappings of those classes?

Here we use Arno's Iptables Firewall with the traffic-shaper plugin I 
wrote.  This does shaping and policing within traffic classes.

And yes, doing an out-of-the-box shaper for Fedora is on my TODO list.

-Philip

Re: setsockopt(IP_TOS) being privileged or distinct capability?

[Philip Prindeville]

Say, on a slightly different subject... but still having to do with 
setsockopt(IP_TOS)... is it intentional that system call effectively 
does nothing if the socket is in listen(), connect(), or bind() states?

In other words, you have to issue the setsockopt() immediately after the 
socket() call, or it doesn't do anything.

As I remember, that's slightly different semantics from BSD, which 
allows you to change the markings on a bound or listening socket.

I've not walked through the kernel sources to see why this is.

-Philip

Re: setsockopt(IP_TOS) being privileged or distinct capability?

[Hagen Paul Pfeifer]

* Philip Prindeville | 2010-07-05 12:04:31 [-0600]:

>I understand that.  That's part of the reason that I've submitted
>patches for APR, Apache, Thunderbird, Firefox, Proftpd, Curl, wget,
>etc.  There is pressure within certain technical groups to get ISP's
>to voluntarily implement RFC-4594... that's the carrot.  The stick
>being FCC heavy-handed regulation of the ISP's if they don't.

Where is the _real_ advantage if setsockopt(IP_TOS) where a privileged
operation? At the end the user/service is still required to set his service
class, but this time with CAP_NET_ADMIN. Do you think that Service
Providers/Transit Providers trust (and this is the critical aspect) customers
based on some IP flags - this is extreme unlikely. 99% of users have
effective CAP_NET_ADMIN capabilities - and you cannot stop using them.

Service Providers/Transit Providers will trust customers who pays more and
then they will accept their DIFFSERV suggestion signaled via IP DSCP. All
other customers will be treated normal, with zeroed DSCP. It makes no sense
for ISP's to shift the trust aspect to the customer side.

HGN

Re: setsockopt(IP_TOS) being privileged or distinct capability?

[Philip Prindeville]

On 7/5/10 8:07 PM, Hagen Paul Pfeifer wrote:
> * Philip Prindeville | 2010-07-05 12:04:31 [-0600]:
>
>    
>> I understand that.  That's part of the reason that I've submitted
>> patches for APR, Apache, Thunderbird, Firefox, Proftpd, Curl, wget,
>> etc.  There is pressure within certain technical groups to get ISP's
>> to voluntarily implement RFC-4594... that's the carrot.  The stick
>> being FCC heavy-handed regulation of the ISP's if they don't.
>>      
> Where is the _real_ advantage if setsockopt(IP_TOS) where a privileged
> operation? At the end the user/service is still required to set his service
> class, but this time with CAP_NET_ADMIN. Do you think that Service
> Providers/Transit Providers trust (and this is the critical aspect) customers
> based on some IP flags - this is extreme unlikely. 99% of users have
> effective CAP_NET_ADMIN capabilities - and you cannot stop using them.
>    

QoS is expensive to implement, since it requires a lot more inspection 
of the packet, multiple queues, bandwidth reservation, etc.

ISP's are going to look for an excuse not to implement it.

Having it be exploited by users is another arrow in their quill to not 
implement it.

Yes, most users have admin/privileged rights on their machines, but 
don't know enough to exploit that.

Whatever makes it harder to abusively exploit QoS seems like a good 
idea.  Harder.  Not impossible.

"Stopping them" was never the objective.

> Service Providers/Transit Providers will trust customers who pays more and
> then they will accept their DIFFSERV suggestion signaled via IP DSCP. All
> other customers will be treated normal, with zeroed DSCP. It makes no sense
> for ISP's to shift the trust aspect to the customer side.
>
> HGN
>
>
>    

Alas there's more to it than that: the movement is to make QoS be 
ubiquitous for all SLA's of broadband.

I'd argue that it makes no sense for them not to trust it:  SDP/RTP 
packets are hard to identify as such without peaking into the 
accompanying SIP conversation... which drives up the cost of their 
required infrastructure to handle QoS even more.

Besides, if I deploy a new protocol that uses RTP or leverages QoS, I'd 
have to wait for the ISP to update their network with knowledge of that 
protocol in order to handle it properly... given the glacial pace that 
at which ISP's certify and deploy software updates, configuration 
changes, etc. I don't want to have to wait months or years for them to 
play catch-up.

What's more, if I'm running SIP over TLS over TCP, they can't peek into 
the stream anyway to figure out what UDP ports I'm using for SDP.

So I can sacrifice control, privacy, or timeliness... or they can simply 
trust my QoS markings.

But what's the downside of their trusting my markings, anyway?

Let's say that I have 7mb/s DSL, and with that standard base profile 
comes 240kb/s EF policing, 512kb/s AF4x, etc.  Further let's suppose 
that I exceed my SLA: they could either downgrade the excess to the next 
lowest bin, or discard it... Hence I'm highly incentivized to remain 
within my agreed SLA envelope.

Re: setsockopt(IP_TOS) being privileged or distinct capability?

[David Miller]

From: Philip Prindeville <philipp_subx@redfish-solutions.com>
Date: Mon, 05 Jul 2010 21:08:05 -0600

> Yes, most users have admin/privileged rights on their machines, but
> don't know enough to exploit that.

Even "stupid" users are a very slim, marginal, step away from making
use of it once they get shown with a HOWTO on some web site what is
possible with this if QoS is being abided by on their network.

Look, this discussion seems completely pointless.  The behavior is
never changing, setting the TOS will always be non-privileged.

We cannot change the current behavior no matter what political or
other motivation we might have for doing so.  It's been non-privileged
for more than 15 years, and we'd knowingly break applications with the
change.

And I don't even agree with the arguments being proposed for doing
this.  Users can control their packets however they wish.  The only
thing the ISP can do to prevent toying with the TOS bits is putting
logic into your little black box that hooks up to your cable/dsl line.

So this TOS being privileged proposal it's a "no go" from any angle as
far as I'm concerned.

Re: setsockopt(IP_TOS) being privileged or distinct capability?

[Rémi Denis-Courmont]

On Sat, 03 Jul 2010 11:58:45 -0600, Philip Prindeville
<philipp_subx@redfish-solutions.com> wrote:
> Does anyone else think that setsockopt(IP_TOS) should be a privileged
> operation, perhaps using CAP_NET_ADMIN, or maybe even adding separate
> granularity as CAP_NET_TOS?

That's a terribly idea.
Some applications do rely on this to set their TOS "correctly". If you
don't want unprivileged applications to be able to affect the queuing
policy, then don't use the TOS bits in your queuing policy - as simple as
that.

-- 
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis

Re: setsockopt(IP_TOS) being privileged or distinct capability?

[Benny Amorsen]

Philip Prindeville <philipp_subx@redfish-solutions.com> writes:

> Once QoS markings actually *are* implemented in carrier networks, the
> potential for abuse is non-insignificant.  Hence the suggestion to
> make it privileged.

I think you are overestimating the potential for abuse. ISP's who
oversubscribe enough to suffer from heavy congestion internally should
stop doing that and most likely have fancy congestion control equipment
installed. That equipment can apply all sorts of limits to prioritized
traffic.

For a more typical ISP, marking TCP packets with EF means you get
marginally lower and more stable latency but risk increased packet loss.
TCP does not mind a little extra latency and suffers badly from packet
loss, so that behaviour should be self-limiting.


/Benny