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

Date:   Wed, 13 Dec 2017 16:05:57 -0700
From:   David Ahern <dsahern@...il.com>
To:     Daniel Lakeland <dlakelan@...eet-artists.org>,
        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/17 3:52 PM, Daniel Lakeland wrote:
> 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...
> 
> 

If you are running a modern kernel (>= ~4.5) there are fib tracepoints
you can use to try to answer that:

   perf record -e fib:fib_table_lookup -a -g
   perf script [-G]

I've had some doubts about tos handling in the output path but have not
had the time (or motivation) to dig into it. Specifically, the tos
adjustments in ip_route_output_key_hash look weird to me.