Re: [pim] IGMPv3 backward compatibility issue killing SSM (was: Re: pim wglc for 3228bis, 3376bis and 3810bis)

[Toerless Eckert <[e-mail]>]

Thanks, Jake

Good insight into Linux behavior.
I wonder if/how we could capture this in our bis document...

> I'm not sure it makes sense to ship text that makes all the currently deployed
> routers retroactively non-compliant with a MUST in the new IGMPv3.

Aka: my proposed "MUST not fall back to IGMPv2/v1 by default"

Yes, i specifically put this out there to have the argument. And of course the argument
is whether that requirement would be a deal breaker for going to full internet standard.

So lets refine the requirement and say it only applies to SSM aware router, and
refine the definition of SSM aware of the device being configured to perform as
an SSM aware router - aka: router only becomes SSM aware once you configure L3
IP multicast routing with SSM support.

In this case, the requirement does not apply anymore to routers captured by 3376 because
we didn't talk about SSM aware routers in 3376. So it's a refinement of the common
behavior for RFC 4604/4607.

Cheers
    Toerless

On Mon, Dec 18, 2023 at 11:56:22PM +0000, Holland, Jake wrote:
> On 12/14/23, 1:29 PM, "pim on behalf of Toerless Eckert" <[e-mail] <mailto:[e-mail]> on behalf of [e-mail] <mailto:[e-mail]>> wrote:
> > The elephant IMHO is that rfc3376bis is so far not including changes to IGMPv3 behaviors
> > about backeward compatibility with v1/v2 routers on the LAN, and exactly this behavior is
> > killing SSM in deployment because any such router when it becomes querier will kill SSM
> > ... because hosts will revert to v1/v2 and not report their SSM (S,G) memberships.
> 
> +1, this is a serious problem.  The current default behavior bakes a DOS for SSM into the
> protocol.
> 
> > If there are routers that have config options to disable this backward compatibility with
> > older routers, i would love to learn about it.
> 
> When using linux routing there is `sysctl net.ipv4.force_igmp_version=3`, but it says because
> of the difference in the security considerations between MLD and IGMP it doesn't actually
> ignore v1 and v2 even when it's set:
> https://sysctl-explorer.net/net/ipv4/force_igmp_version/
> 
> (MLD permits an "ignore v1 completely" setting, but says it should only be used when
> source filtering is critical:
> https://datatracker.ietf.org/doc/html/rfc3810#section-10.2 )
> 
> > - Replace with something like:
> >
> > This revision of IGMPv3 version 3 removes automatic fallback to IGMP version 2 and version 1
> > routers on the same network as specified in [RFC3376]. Instead,
> > such older version router behavior MUST be explicitly configured.
> 
> While I agree that to the greatest extent we can induce, IGMPv3 queriers from now
> on should maintain the capability to propagate SSM and accept IGMPv3 membership
> reports under all circumstances (even when there is an IGMPv1 or v2 receiver on the
> LAN), I'm not sure it makes sense to ship text that makes all the currently deployed
> routers retroactively non-compliant with a MUST in the new IGMPv3.
> 
> But I'd support adding a section that describes the problem and provides a well-
> justified and strong recommendation that the default behavior be changed from
> what's in RFC 3376 and that a config option be provided to ignore IGMPv1 and v2
> packets, like with MLD.
> 
> It might be worth saying something like now that we have RFC 8815 and in light of
> the experimental status of RFC 3618 (MSDP) and its deployment BCP in 4611, source
> filtering should always be considered critical for clients that support it?  (Not sure that's
> necessary, just a brainstorming idea to point to some of the docs that cover new
> operational experience since 3376...)
> 
> > IGMPv3 routers MUST have a configuration option, disabled by default, to operate
> > as an IGMPv2 router. When enabled, all procedures of [RFC2236] apply. Configuring this
> > option is necessary in the presence of non-IGMPv3 capable IGMP snooping switches or
> > PIM routers. These are rare but may still be depoyed.
> >
> > When operating in IGMP version 3, routers MUST ignore version 1 and version 2 queries.
> > In version 3, the presence of those older version queries constitutes a misconfiguration
> > or attack, and these messages SHOULD result in logging of an error (rate-limited).
> >
> > - And in an appropriate part of the host behavior:
> >
> > IGMP version 3 hosts MUST have a configuration option, disabled by default, to ignore
> > IGMP version 1 and version 2 queries. This option SHOULD be auto-enabled when the host
> > is running SSM receiver applications, and hence depends on IGMP version 3 to operate in the
> > network.
> >
> > This is about as much as i think we can do if we still want to go full standard with rfc3376bis.
> > I can think of no operational deployment where the introduction of devices with existing
> > older RFC compatibility would cause interoperability issues. At worst the new router would
> > need to be explicitly configured for IGMPv2, which in my experience most routers deployed
> > into IGMPv3 environments are done anyhow.
> >
> > Comments welcome. Would love to see positive replies in which case i will be happy to explicitly
> > sugest the text changes for this elephant issue to the draft.
> 
> Thanks for raising this, Toerless, the IGMP downgrade problem has been a major source of pain
> for some deployments that rely on SSM.
> 
> - Jake
> 
> 

-- 
---
[e-mail]