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>] [day] [month] [year] [list]
Date:   Mon, 8 Apr 2019 11:08:25 +0300
From:   Dmitry Izbitsky <izbitsky@...il.com>
To:     netdev@...r.kernel.org
Cc:     Alexandra.Kossovsky@...etlabs.ru
Subject: IPV6_TCLASS and policy-based routing

Greetings,

it appears that policy based routing works rather strange for IPv6, if
I try to make it to select routing table based on IPv6 traffic class.
In case of IPv4, you can add rule like

ip rule add tos 8 table 111

and all the packets from sockets with IP_TOS set to 8 will be routed
according to table 111.

In case of IPv6, IPV6 Traffic Class seems to be very similar to TOS,
however “ip rule” does not have separate “tclass” option. From kernel
sources (fib6_rule_configure() in net/ipv6/fib6_rules.c) it seems that
it sets tclass to value specified for tos, and rule like

ip -6 rule add tos 8 table 111

should work (if instead of IP_TOS we set IPV6_TCLASS to 8 for IPv6 socket).

However I discovered that if that table 111 contains a route to some
destination and there is no other route to there in any other table,
this really works fine only for sending data with sendto() from not
connected UDP IPv6 socket. connect() for UDP IPv6 socket to the same
destination fails with ENETUNREACH, for TCP socket connection
establishment does not work too. I’ve seen this while using 5.0.0
kernel.

In kernel sources I see that in fib6_rule_match() tclass is compared
with ip6_tclass(fl6->flowlabel). However ip6_make_flowinfo() which is
used to add tclass to flowlabel is used only in udpv6_sendmsg()
defined in net/ipv6/udp.c (other places where it can be seen seem not
being directly related to TCP/UDP). This may explain the strange
behavior described above.

To make reproducing the issue simpler, I include two C files in
attachment, ipv6_tclass_server.c and ipv6_tclass_client.c. I have two
hosts, host A and host B, connected with interfaces enp1s0f1np1 (on
host A) and eth3 (on host B).

1. On host B I did the following:
sudo ip -6 addr add fec1:34::5555 dev eth3
sudo ip -6 route add fec1:33::5555/128 dev eth3
gcc ipv6_tclass_server.c -o ipv6_tclass_server
./ipv6_tclass_server fec1:34::5555 8
[output] fec1:34::5555 8 5743 5743

In the last command the second argument (8) is value of IPV6_TCLASS
option set on sockets. Its output should be fed to ipv6_tclass_client
on the second step (after source address as the first argument).

2. On host A I did the following:
sudo ip -6 addr add fec1:33::5555 dev enp1s0f1np1
sudo ip -6 route add fec1:34::5555/128 dev enp1s0f1np1 table 111
sudo ip -6 rule add tos 8 table 111
gcc ipv6_tclass_client.c -o ipv6_tclass_client
./ipv6_tclass_client fec1:33::5555 fec1:34::5555 8 5743 5743

This ipv6_tclass_client tries to check four things: UDP connect(), UDP
sendto(), TCP accept(), TCP connect().
Resulting output - only sendto() from UDP socket is successfull (but
not connect() to the same destination from the same UDP socket):

Connecting UDP socket to fec1:34::5555 failed with errno 101 (Network
is unreachable)
Sending from UDP socket to fec1:34::5555 succeeded
TCP listener did not become readable within 1 second
Nonblocking connect() failed with unexpected errno
errno=101 (Network is unreachable)

If I add a route to fec1:34:5555 in main table on host A:
sudo ip -6 route add fec1:34::5555/128 dev enp1s0f1np1

all works fine:
./ipv6_tclass_client fec1:33::5555 fec1:34::5555 8 5743 5743

Connecting UDP socket to fec1:34::5555 succeeded
Sending from UDP socket to fec1:34::5555 succeeded
TCP connection was accepted successfully from fec1:34::5555
Active TCP connection was successfully established

Redards,
Dmitry Izbitsky

View attachment "ipv6_tclass_client.c" of type "text/x-csrc" (6686 bytes)

View attachment "ipv6_tclass_server.c" of type "text/x-csrc" (7848 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ