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: Wed, 18 May 2022 09:18:30 -0700 From: Jakub Kicinski <kuba@...nel.org> To: David Ahern <dsahern@...nel.org> Cc: Ido Schimmel <idosch@...dia.com>, Saranya Panjarathina <plsaranya@...il.com>, netdev@...r.kernel.org, Saranya_Panjarathina@...l.com, davem@...emloft.net, yoshfuji@...ux-ipv6.org, edumazet@...gle.com, pabeni@...hat.com, linux-kernel@...r.kernel.org, g_balaji1@...l.com, Nikolay Aleksandrov <razor@...ckwall.org> Subject: Re: [PATCH net-next] net: PIM register decapsulation and Forwarding. On Wed, 18 May 2022 08:36:26 -0600 David Ahern wrote: > >> Trying to understand the problem: > >> > >> 1. The RP has an (*, G) towards the receiver(s) (receiver joins first) > >> 2. The RP receives a PIM Register packet encapsulating the packet from > >> the source > >> 3. The kernel decapsulates the packet and injects it into the Rx path as > >> if the packet was received by the pimreg netdev > >> 4. The kernel forwards the packet according to the (*, G) route (no RPF > >> check) > >> > >> At the same time, the PIM Register packet should be received by whatever > >> routing daemon is running in user space via a raw socket for the PIM > >> protocol. My understanding is that it should cause the RP to send a PIM > >> Join towards the FHR, causing the FHR to send two copies of each packet > >> from the source: encapsulated in the PIM Register packet and over the > >> (S, G) Tree. > >> > >> If the RP already has an (S, G) route with IIF of skb->dev and the > >> decapsulated packet is injected into the Rx path via skb->dev, then what > >> prevents the RP from forwarding the same packet twice towards the > >> receiver(s)? > >> > >> I'm not a PIM expert so the above might be nonsense. Anyway, I will > >> check with someone from the FRR teams who understands PIM better than > >> me. > > > > We discussed this patch in FRR slack with the author and PIM experts. > > The tl;dr is that the patch is working around what we currently believe > > is an FRR bug, which the author will try to fix. > > > > After receiving a PIM Register message on the RP, FRR installs an (S, G) > > route with IIF being the interface via which the packet was received > > (skb->dev). FRR also sends a PIM Join towards the FHR and eventually a > > PIM Register Stop. > > > > The current behavior means that due to RPF assertion, all the > > encapsulated traffic from the source is dropped on the RP after FRR > > installs the (S, G) route. > > > > The patch is problematic because during the time the FHR sends both > > encapsulated and native traffic towards the RP, the RP will forward both > > copies towards the receiver(s). > > > > Instead, the suggestion is for FRR to install the initial (S, G) route > > with IIF being the pimreg device. This should allow decapsulated traffic > > to be forwarded correctly. Native traffic will trigger RPF assertion and > > thereby prompt FRR to: a) Replace the IIF from pimreg to the one via > > which traffic is received b) Send a PIM Register Stop towards the FHR, > > instructing it to stop sending encapsulated traffic. > > > > Thanks for diving into the problem and for the detailed response. +1, thanks Ido!
Powered by blists - more mailing lists