DSCP values in TCP handshake

DSCP values in TCP handshake

[Joe Buehler]

What does the LINUX network code put in the DSCP field of TCP SYN-ACK packets
that are replies to a SYN connection request?  I have a customer sending SYN
with 0x2e in the DSCP field but apparently getting DSCP 0x0 in the reply.

Joe Buehler

Re: DSCP values in TCP handshake

[Eric Dumazet]

Le lundi 18 avril 2011 à 13:48 +0000, Joe Buehler a écrit :
> What does the LINUX network code put in the DSCP field of TCP SYN-ACK packets
> that are replies to a SYN connection request?  I have a customer sending SYN
> with 0x2e in the DSCP field but apparently getting DSCP 0x0 in the reply.

The other way (server->client) is depending on application and listener
only.

If it uses a standard socket, standard bind() + listen(), TOS is 0

Re: DSCP values in TCP handshake

[Stephen Hemminger]

On Mon, 18 Apr 2011 16:05:12 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:

> Le lundi 18 avril 2011 à 13:48 +0000, Joe Buehler a écrit :
> > What does the LINUX network code put in the DSCP field of TCP SYN-ACK packets
> > that are replies to a SYN connection request?  I have a customer sending SYN
> > with 0x2e in the DSCP field but apparently getting DSCP 0x0 in the reply.
> 
> The other way (server->client) is depending on application and listener
> only.
> 
> If it uses a standard socket, standard bind() + listen(), TOS is 0

If you want to set DSCP in the response, the application needs to apply
set it on the listening socket. 
   dscp = 0x2e;
   setsockopt(s, IPPROTO_IP, IP_TOS, &dscp, sizeof(dscp));

Re: DSCP values in TCP handshake

[Mikael Abrahamsson]

On Mon, 18 Apr 2011, Stephen Hemminger wrote:

> If you want to set DSCP in the response, the application needs to apply
> set it on the listening socket.
>   dscp = 0x2e;
>   setsockopt(s, IPPROTO_IP, IP_TOS, &dscp, sizeof(dscp));

<http://tools.ietf.org/html/rfc2873> says this is ok, but I would like 
default to be that if incoming SYN has a certain DSCP value, the SYN+ACK 
should mirror this value if the application doesn't explicitly set 
anything else.

I was under the impression that mirroring was done historically, but this 
has changed? Looking at how my apache server is behaving in 2.6.32, it 
seems it uses 0x0 for the whole TOS byte by default. I send it 0x20 and it 
responds with 0x0. SSH does the same thing.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: DSCP values in TCP handshake

[Joe Buehler]

> <http://tools.ietf.org/html/rfc2873> says this is ok, but I would like
> default to be that if incoming SYN has a certain DSCP value, the SYN+ACK
> should mirror this value if the application doesn't explicitly set
> anything else.
> 
> I was under the impression that mirroring was done historically, but
> this has changed? Looking at how my apache server is behaving in 2.6.32,
> it seems it uses 0x0 for the whole TOS byte by default. I send it 0x20
> and it responds with 0x0. SSH does the same thing.

In my case I just need the SYN-ACK to reflect the incoming SYN.  To get
it I am going to use iptables like so (barring bugs on my part -- still
testing this...):

iptables -t mangle -A PREROUTING -m tcp -p tcp --tcp-flags SYN,RST,ACK
SYN -m dscp --dscp 0 -j CONNMARK --set-mark 0
iptables -t mangle -A POSTROUTING -m tcp -p tcp --tcp-flags SYN,RST,ACK
SYN,ACK -m connmark --mark 0 -j DSCP --set-dscp 0
(repeat for the other 63 values of DSCP...)

The argument I have seen for not making reflection standard behavior is
that it is not always appropriate for the application.  For example, web
servers have short requests but large responses so non-identical DSCP
values might make more sense.

Thanks for all the replies.

Joe Buehler

Re: DSCP values in TCP handshake

[Mikael Abrahamsson]

On Mon, 18 Apr 2011, Joe Buehler wrote:

> The argument I have seen for not making reflection standard behavior is 
> that it is not always appropriate for the application.  For example, web 
> servers have short requests but large responses so non-identical DSCP 
> values might make more sense.

I'm a router guy. I don't understand this reasoning at all.

Anyone care to elaborate?

I'd like reflection be standard and have the application set DSCP if it 
needs to.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: DSCP values in TCP handshake

[Stephen Hemminger]

On Mon, 18 Apr 2011 21:16:35 +0200 (CEST)
Mikael Abrahamsson <swmike@swm.pp.se> wrote:

> On Mon, 18 Apr 2011, Joe Buehler wrote:
> 
> > The argument I have seen for not making reflection standard behavior is 
> > that it is not always appropriate for the application.  For example, web 
> > servers have short requests but large responses so non-identical DSCP 
> > values might make more sense.
> 
> I'm a router guy. I don't understand this reasoning at all.
> 
> Anyone care to elaborate?
> 
> I'd like reflection be standard and have the application set DSCP if it 
> needs to.
> 

If the DSCP bits are reflected, then it could allow for even better
SYN flood attack. Attacker could maliciously set DSCP to elevate priority
processing of his bogus SYN packets and also cause SYN-ACK on reverse path
to also take priority.

-- 

Re: DSCP values in TCP handshake

[Mikael Abrahamsson]

On Mon, 18 Apr 2011, Stephen Hemminger wrote:

> If the DSCP bits are reflected, then it could allow for even better SYN 
> flood attack. Attacker could maliciously set DSCP to elevate priority 
> processing of his bogus SYN packets and also cause SYN-ACK on reverse 
> path to also take priority.

Incoming, it's already too late. Outgoing, yes, that might be a problem, 
but if you have a QoS enabled network then you might as well solve that in 
the network, not in the host.

Does Linux internally look at DSCP when deciding what SYNs to handle 
first? If not, I think the above reasoning is misdirected.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: DSCP values in TCP handshake

[Stephen Hemminger]

On Tue, 19 Apr 2011 05:50:34 +0200 (CEST)
Mikael Abrahamsson <swmike@swm.pp.se> wrote:

> On Mon, 18 Apr 2011, Stephen Hemminger wrote:
> 
> > If the DSCP bits are reflected, then it could allow for even better SYN 
> > flood attack. Attacker could maliciously set DSCP to elevate priority 
> > processing of his bogus SYN packets and also cause SYN-ACK on reverse 
> > path to also take priority.
> 
> Incoming, it's already too late. Outgoing, yes, that might be a problem, 
> but if you have a QoS enabled network then you might as well solve that in 
> the network, not in the host.
> 
> Does Linux internally look at DSCP when deciding what SYNs to handle 
> first? If not, I think the above reasoning is misdirected.

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

Of course, you can do anything with qdisc, and iptables.

Re: DSCP values in TCP handshake

[Mikael Abrahamsson]

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@swm.pp.se

Re: DSCP values in TCP handshake

[Matt Mathis]

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

Please do.    This missing spec is one of the things that makes Less
than Best Effort (aka scavenger service) unusable.   Only the client
knows if they are fetching data in the background.   The server
doesn't care.

The other botch it is the spec that DSCP can be cleared under certain
conditions, which has the effect of promoting LBE to BE.   I have lost
track of the details.

Making LBE work would go a long way to solving the buffer bloat
problem and more....

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay




On Tue, Apr 19, 2011 at 12:28 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> 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@swm.pp.se
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: DSCP values in TCP handshake

[Mikael Abrahamsson]

On Tue, 19 Apr 2011, Matt Mathis wrote:

> Please do.  This missing spec is one of the things that makes Less than 
> Best Effort (aka scavenger service) unusable.  Only the client knows if 
> they are fetching data in the background.  The server doesn't care.

I emailed with Fred Baker and the below text seems to be where it ended 
regarding reflexive marking of packets. If someone wants this changed, 
they need to bring it up with the IETF.

<http://www.ietf.org/proceedings/54/220.htm>

"Fred Baker presented draft-ietf-ieprep-packet-marking-policy-00.txt

Van Jacobsen presented a concern for Kathy Nichols, Diffserv co-chair. The 
concern was that the DSCP is intended to identify traffic supported by a 
service, as opposed to traffic of a certain application type. He also 
worried that a specific BCP indicating the facilities used to support such 
services might be misused by regulators to mandate ISP services. 
Specifically, he wanted a statement between the requirements document and 
a document suggesting a specific configuration identifying the fact that 
inter-service-provider signaling as specified in this draft is certainly 
specified but is not commonly implemented.

Christian Huitema and another speaker also commented that while a cookbook 
such as this was an interesting useful document, it didn't seem to 
directly stem from emergency as a context.

Rei Atarashi presented draft-ietf-ieprep-reflexive-dscp-00.txt

Van basically felt that the notion of a default response from the host was 
inappropriate; this is something every network should provide a policy 
for. "

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se