netdev - IPv6 flow label reflection behave for RST packets

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-next>] [day] [month] [year] [list]

Date:   Tue, 9 Jul 2019 13:10:30 +0200
From:   Marek Majkowski <marek@...udflare.com>
To:     kuznet@....inr.ac.ru, yoshfuji@...ux-ipv6.org,
        Jakub Sitnicki <jakub@...udflare.com>
Cc:     netdev@...r.kernel.org, kernel-team <kernel-team@...udflare.com>
Subject: IPv6 flow label reflection behave for RST packets

Morning,

I'm experimenting with flow label reflection from a server point of
view. I'm able to get it working in both supported ways:

(a) per-socket with flow manager IPV6_FL_F_REFLECT and flowlabel_consistency=0

(b) with global flowlabel_reflect sysctl

However, I was surprised to see that RST after the connection is torn
down, doesn't have the correct flow label value:

IP6 (flowlabel 0x3ba3d) ::1.59276 > ::1.1235: Flags [S]
IP6 (flowlabel 0x3ba3d) ::1.1235 > ::1.59276: Flags [S.]
IP6 (flowlabel 0x3ba3d) ::1.59276 > ::1.1235: Flags [.]
IP6 (flowlabel 0x3ba3d) ::1.1235 > ::1.59276: Flags [F.]
IP6 (flowlabel 0x3ba3d) ::1.59276 > ::1.1235: Flags [P.]
IP6 (flowlabel 0xdfc46) ::1.1235 > ::1.59276: Flags [R]

Notice, the last RST packet has inconsistent flow label. Perhaps we
can argue this behaviour might be acceptable for a per-socket
IPV6_FL_F_REFLECT option, but with global flowlabel_reflect, I would
expect the RST to preserve the reflected flow label value.

I suspect the same behaviour is true for kernel-generated ICMPv6.

Prepared test case:
https://gist.github.com/majek/139081b84f9b5b6187c8ccff802e3ab3

This behaviour is not necessarily a bug, more of a surprise. Flow
label reflection is mostly useful in deployments where Linux servers
stand behind ECMP router, which uses flow-label to compute the hash.
Flow label reflection allows ICMP PTB message to be routed back to
correct server.

It's hard to imagine a situation where generated RST or ICMP echo
response would trigger a ICMP PTB. Flow label reflection is explained
here:
https://tools.ietf.org/html/draft-wang-6man-flow-label-reflection-01
and:
https://tools.ietf.org/html/rfc7098
https://tools.ietf.org/html/rfc6438

Cheers,
    Marek

(Note: the unrelated "fwmark_reflect" toggle is about something
different - flow marks, but also addresses RST and ICMP generated by
the server)