netdev - Re: DSCP values in TCP handshake

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 19 Apr 2011 06:28:02 +0200 (CEST)
From:	Mikael Abrahamsson <swmike@....pp.se>
To:	Stephen Hemminger <shemminger@...tta.com>
cc:	Joe Buehler <aspam@....net>, Eric Dumazet <eric.dumazet@...il.com>,
	netdev@...r.kernel.org
Subject: Re: DSCP values in TCP handshake

On Mon, 18 Apr 2011, Stephen Hemminger wrote:

> Linux does not look at DSCP of incoming packets (there is no queue).

Then I see no reason for the policy of not reflecting DSCP.

If we receive the DSCP marked packet then it means the network is either 
not QoS enabled (it doesn't care) or it's actually allowed through the 
border router with DSCP unchanged. Either means it's safe to reflect the 
DSCP value, either it will have no effect or it's actually meant to be 
prioritized.

With precedence, it originally was mandated that if the precedence value 
changed, the TCP session should be reset. Fortunately, this was changed 
but I would still say that it's thought that DSCP values should be 
reflected by the server.

For instance:

<http://tools.ietf.org/html/draft-ietf-ieprep-reflexive-dscp-02>

"The requester could initiate this. Thus, if the DSCP
    received on one TCP segment differs from the TCP used on a prior TCP
    segment in a session, the new DSCP SHOULD be reflected unless local
    policy prevents this."

I don't know why this didn't make it into RFC, I can inquiry if there is 
interest.

-- 
Mikael Abrahamsson    email: swmike@....pp.se
--
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