netdev - Re: BUG REPORT: iproute2 seems to have bug with dsfield/tos in ip-rule and ip-route

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

Message-ID: <a745127e-58f6-47e6-7b44-a1b5e028bd2d@street-artists.org>
Date:   Wed, 13 Dec 2017 14:52:43 -0800
From:   Daniel Lakeland <dlakelan@...eet-artists.org>
To:     David Ahern <dsahern@...il.com>,
        Stephen Hemminger <stephen@...workplumber.org>
Cc:     netdev@...r.kernel.org
Subject: Re: BUG REPORT: iproute2 seems to have bug with dsfield/tos in
 ip-rule and ip-route

On 12/13/2017 02:40 PM, David Ahern wrote:
>
> In fib4_rule_configure, this the check that is failing:
>
>      if (frh->tos & ~IPTOS_TOS_MASK)
>          goto errout;
>
> and EINVAL is returned.
>
> IPv4 routes has not checking on tos -- it is passed from user and
> rtm_tos to fc_tos to fib alias tos.

it seems to me that this IPTOS_TOS_MASK check should be either gotten 
rid of, or equal to 0x03 in modern usage. The bottom 2 bits are ECN and 
I suppose someone might want to route based on congestion... and hence 
maybe the mask should be dropped entirely, but if you refuse to allow 
routes on ECN then you'd want 0x03 as the mask

it seems to me this is left over from before DSCP.

apparently most people don't route on DSCP or work around this with 
firewall marks, and so this doesn't cause trouble enough to have been 
reported before?

I think the follow up question is does anyone have any idea why someone 
who set up routes with dsfield settings is not seeing packets routed? 
The kernel may not handle ip rule with DSCP, but it takes

ip route add default dsfield CS6 dev veth0

just fine... and shows up in the route table, but for example the person 
is not seeing CS6 marked packets going to veth2 and instead is seeing 
them routed to veth0 the default route...