[pkg-netfilter-team] Bug#923880: Fwd: ssh: IPQoS defaults change interacts badly with iptables -m tos

[Donovan Baarda]

G'day,

TLDR; I think the current openssh TOS settings of AF21 and CS1 are a poor
match for the old TOS bit fields and are causing confusion. IMHO AF22 and
AF11 would be a better backwards-compatible choice. I think the
iptables use of "08x/0x3f" for Maximize-Throughput is only wrong in that
the mask 0x3f includes 1 bit of the DSCP "Precedence" field.

I sent a message to 923879 at bugs.debian.org which bounced because it's
closed/archived, and found this bug as probably the most relevant open bug.

Reading this bug it looks to me like RFC 1349 confused Peter Lebbing by
using less-common big-endian bit numbering for their bit labels in the TOS
field and not making that very clear. Everything else I've seen has the
precedence bits in the Most-Significant-Bits of the octet including these;

http://www.rhyshaden.com/ipdgram.htm
https://my.ezycloud.com.au/knowledgebase/201204284/Quality-of-Service-QoS----DSCP-TOS-CoS-Precedence-Conversion-Chart.html

This is the convention ssh is currently using when it sets AF21 as 0x48 and
CS1 ax 0x20, and this appears to be what IP tables is also using.

This means I believe that iptables use of "08x/0x3f"
for Maximize-Throughput is only wrong in that the mask 0x3f includes 1 bit
of the DSCP "Precedence" field. I think the correct mask should be 0x1f,
though maybe there are reasons why you'd want to explicitly clear the LSB
of the DSCP Precedence field that I'm unaware of.

I stumbled upon https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923879
trying to figure out problems with my QoS firewall setup and a recent
Debian ssh which is using AF21 and CS1 for interactive and bulk traffic
respectively. This is the new ssh upstream default, and after speaking to
one of the ssh developers (dtucker) it seems TOS standards are a mess and
everyone they've spoken to have given them different advice. There are now
more than two RFCs and 100k of text per TOS header bit. The choice of AF21
and CS1 was taken as an attempt to pick the least-wrong option, and no-one
has been able to clearly justify anything better.

The reason AF21 is being classified as "Maximize-Throughput" is because
AF21 sets the (old?) Maximize-Throughput bit, not the Minimize-Delay bit,
despite the various DSCP docs describing AF21 as "interactive" (actually,
all of AF2[123] is documented as for "low latency traffic"). Note CS1
doesn't set any of the old Delay/Throughput/Reliablity/Cost TOS bits so is
likely classified as "normal" traffic, not "bulk" by most older QoS
systems. See the following chart for details;

https://my.ezycloud.com.au/knowledgebase/201204284/Quality-of-Service-QoS----DSCP-TOS-CoS-Precedence-Conversion-Chart.html

It appears from the settings that AF21 was intended for important
high-volume traffic. It looks like AF22 was intended for important
low-latency traffic (it sets the Minimize-Delay bit) and is probably a
better fit for ssh interactive traffic. Note that the ssh devs probably
chose AF21 over AF22 because the DSCP docs say AF22 should be dropped
before AF21, implying AF21 is "more important" than AF22;

https://en.wikipedia.org/wiki/Differentiated_services#Assured_Forwarding

However, I think the DSCP standards structure the drop-order this way to
reflect that they are actually equally important (as indicated by the
precedence setting of "Immediate), but high-volume traffic is more likely
to need the packets during congestion. Note that AF23 which sets both
Minimize-Delay AND Maximize-Throughput has an even higher drop probability,
probably because that's the price you pay for asking for both high volume
AND low latency.

The use of CS1 for ssh bulk traffic is also problematic, since it doesn't
set any of the old TOS bits and thus looks "normal" to anything only
looking at the old Delay/Throughput/Reliablity/Cost TOS bits. The
equivalent DSCP "Priority" precedence that does set the Maximize-Throughput
bit is AF11, which does seem like a better fit than CS1. Another option
would be to set the Minimize-Cost bit, but that bit is not used by DSCP so
there is no DSCP class with that bit set.

So personally I'm now using the following setting in both
/etc/ssh/ssh_config and /etc/ssh/sshd_config to override the defaults.

IPQoS af22 af11

Note the client/server settings affect the traffic in each direction
independently; a server without this setting will send packets with
tos=0x48 (AKA AF21) to a client sending packets with tos=0x50 (AKA AF22)
that does have these settings.

My only problem now is it seems at least one old Debian ssh package
(1:6.7p1-5+deb8u8) and/or the VPS I'm using for one of my machines doesn't
seem to honor the IPQoS setting and is just using tos=0x0... but that's
mostly unrelated.


--
abo at minkirri.apana.org.au
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-netfilter-team/attachments/20200504/7f9a4767/attachment.html>