netdev - Re: Asserting ECN from userspace?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 07 Oct 2011 07:23:09 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	David Täht <dave.taht@...il.com>
Cc:	netdev@...r.kernel.org, bloat-devel@...ts.bufferbloat.net
Subject: Re: Asserting ECN from userspace?

Le mardi 04 octobre 2011 à 23:18 -0700, David Täht a écrit :
> No sooner had I noted (with pleasure) the kernel's new ability to
> correctly set the dscp bits on IPv6 TCP streams without messing with the
> negotiated ECN status, that I found several use cases where being able
> to assert ECN from userspace (for either ipv4, or ipv6) would be useful.
> 
> 1) Applications such as bittorrent (transmission, etc) that are much
> more aware of their overall environment could assert ECN on their UDP
> streams to indicate congestion.
> 
> 2) Test tools. It would be nice to be able, from userspace, to easily
> diagnose if ECN was working on a stream, end to end, and being able to
> set and receive the ECN bits on a less algorithmic basis (ie, not wedged
> deep within a kernel aqm such as RED or SFB)
> 
> 3) Web Proxies. A web proxy could note when it was experiencing
> congestion on one side of the proxied connection (or another) and signal
> the other side to slow down.
> 
> Ah, ECN, we hardly know ye.
> 
> as for item 1 I'm hard pressed to think of a case where setting the ECN
> bits on udp streams would introduce a security problem.
> 
> As for 2, can live without.
> 
> As for 3... perhaps a grantable network capability? A proxy could
> acquire privs to twiddle those bits before dropping root privs.
> 
> That begs the question of how to see those bits in the first place. OOB
> data?
> 
> And twiddling them, on a per stream basis, for a single packet, would
> seem to require something more robust than setsockopt/getsockopt
> (although that would work for udp streams)
> 

For UDP, its really easy to set ECT(0) or ECT(1) in your outgoing
frames, and test as well ECT(0),ECT(1),ECN in incoming frames.

For the sending part:
int tos = 0x2; /* ECT(1) */
setsockopt(fd, IP_PROTOIP, IP_TOS, &tos, sizeof(tos));

To be able to get the TOS value :

int on = 1;
setsockopt(fd, IP_PROTOIP, IP_RECVTOS, &on, sizeof(on));

RECVTOS (since Linux 2.2)
     If  enabled the IP_TOS ancillary message is passed with incoming packets.
     It contains a byte which specifies the Type of Service/Precedence
     field of the packet header.  Expects a boolean integer flag.



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html