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

["Holland, Jake" <[e-mail]>]

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