netdev - Matching on DSCP with IPv4 FIB rules

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

Date: Wed, 26 Jun 2024 14:58:17 +0300
From: Ido Schimmel <idosch@...dia.com>
To: gnault@...hat.com, netdev@...r.kernel.org
Subject: Matching on DSCP with IPv4 FIB rules

Hi Guillaume, everyone,

We have users that would like to direct traffic to a routing table based
on the DSCP value in the IP header. While this can be done using IPv6
FIB rules, it cannot be done using IPv4 FIB rules as the kernel only
allows such rules to match on the three TOS bits from RFC 791 (lower
three DSCP bits). See more info in Guillaume's excellent presentation
here [1].

Extending IPv4 FIB rules to match on DSCP is not easy because of how
inconsistently the TOS field in the IPv4 flow information structure
(i.e., 'struct flowi4::flowi4_tos') is initialized and handled
throughout the networking stack.

Redefining the field using 'dscp_t' and removing the masking of the
upper three DSCP bits is not an option as it will change existing
behavior. For example, an incoming IPv4 packet with a DS field of 0xfc
will no longer match a FIB rule that matches on 'tos 0x1c'.

Instead, I was thinking of extending the IPv4 flow information structure
with a new 'dscp_t' field (e.g., 'struct flowi4::dscp') and adding a new
DSCP FIB rule attribute (e.g., 'FRA_DSCP') that accepts values in the
range of [0, 63] which both address families will support. This will
allow user space to get a consistent behavior between IPv4 and IPv6 with
regards to DSCP matching, without affecting existing use cases.

Adding the new field and initializing it correctly throughout the stack
is not a small undertaking so I was wondering a) Are you OK with the
suggested approach? b) If not, what else would you suggest?

Thanks

[1] https://lpc.events/event/11/contributions/943/attachments/901/1780/inet_tos_lpc2021.pdf