netdev - Re: [RFC net] Discuss seg6 potential wrong behavior

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: <21c70ad0-cf4b-1681-c606-768e992bcc6a@kernel.org>
Date:   Tue, 22 Mar 2022 20:10:15 -0600
From:   David Ahern <dsahern@...nel.org>
To:     Justin Iurman <justin.iurman@...ege.be>, netdev@...r.kernel.org
Cc:     davem@...emloft.net, yoshfuji@...ux-ipv6.org, kuba@...nel.org,
        pabeni@...hat.com
Subject: Re: [RFC net] Discuss seg6 potential wrong behavior

On 3/18/22 2:21 PM, Justin Iurman wrote:
> This thread aims to discuss a potential wrong behavior regarding seg6
> (as well as rpl). I'm curious to know if there is a specific reason for
> discarding the packet when seg6 is not enabled on an interface and when

that is standard. MPLS for example does the same.

> segments_left == 0. Indeed, reading RFC8754, I'm not sure this is the


> right thing to do. I think it would be more correct to process the next
> header in the packet. It does not make any sense to prevent further
> processing when the SRv6 node has literally nothing to do in that
> specific case. For that, we need to postpone the check of accept_seg6.
> And, in order to avoid a breach, we also check for accept_seg6 before
> decapsulation when segments_left == 0. Any comments on this?
> 
> Also, I'm not sure why accept_seg6 is set the current way. Are we not
> suppose to prioritize devconf_all? If "all" is set to 1, then it is

sadly, ipv6 is all over the place with 'all' vs 'dev' settings.