netdev - Re: [PATCH net] selftests: forwarding: vxlan_bridge

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]

Date:   Tue, 18 Feb 2020 10:05:08 +0800
From:   Hangbin Liu <liuhangbin@...il.com>
To:     Petr Machata <petrm@...lanox.com>
Cc:     Petr Machata <pmachata@...il.com>, netdev@...r.kernel.org,
        Ido Schimmel <idosch@...lanox.com>,
        "David S . Miller" <davem@...emloft.net>,
        Peter Dawson <petedaws@...il.com>,
        Daniel Borkmann <daniel@...earbox.net>
Subject: Re: [PATCH net] selftests: forwarding: vxlan_bridge_1d: fix tos value

On Mon, Feb 17, 2020 at 11:40:13AM +0100, Petr Machata wrote:
> >> > Thanks for this remind. I re-checked the tos definition and found a summary
> >> > from Peter Dawson[1].
> >> >
> >> > IPv4/6 Header:0 |0 1 2 3 |0 1 2 3 |0 1 2 3 |0 1 2 3 |
> >> > RFC2460(IPv6)   |Version | Traffic Class   |        |
> >> > RFC2474(IPv6)   |Version | DSCP        |ECN|        |
> >> > RFC2474(IPv4)   |Version |  IHL   |    DSCP     |ECN|
> >> > RFC1349(IPv4)   |Version |  IHL   | PREC |  TOS   |X|
> >> > RFC791 (IPv4)   |Version |  IHL   |      TOS        |
> >
> > As the commit said, we should not use config tos directly. We should remove
> > the precedence field based on RFC1349 or ENC field based on RFC2474.
> 
> Well, RFC1349 didn't know about DSCP. I do not think it is possible to
> conform to both RFC1349 and RFC2474 at the same time.

No, we can't. I mean no mater based on RFC1349 or RFC2474, we should not use
the config tos directly.

> 
> RFC2474 states that "DS field [...] is intended to supersede the
> existing definitions of the IPv4 TOS octet [RFC791] and the IPv6 Traffic
> Class octet [IPv6]". So the field should be assumed to contain DSCP from
> that point on. In my opinion, that makes commit 71130f29979c incorrect.
> 
> (And other similar uses of RT_TOS in other tunneling devices likewise.)

Yes, that's also what I mean, should we update RT_TOS to match
RFC2474?

Thanks
Hangbin