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 PHC | |
Open Source and information security mailing list archives
| ||
|
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.
Powered by blists - more mailing lists