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

[Leonard Giuliano <[e-mail]>]

As I understand, RFC4604 explicitly prevents SSM service from being killed 
by the presence of an IGMPv1/2 host (assuming the router is SSM aware, 
which in 2023 is a fairly valid assumption).  That is bc the router should 
ignore any v1/v2 reports in the ssm range (232/8).  And as I understand, 
RFC3376 Sect 7.3.2 provides backwards compatibility for v1/2 hosts, but 
only on a *per-group* basis- not for the whole LAN.

Combining the two, SSM service is protected in SSM range (232/8).  In 
non-SSM range, due to backward compat, you could lose SSM behavior- but 
since you are in non-SSM range, all bets were off in the first place.

So unless I'm missing something, I don't see see the risk of SSM being 
killed by v3 backwards compatibility.  Adding DKatz, who know this stuff 
way better than me in case I misinterpreted any of these specs.


-Lenny

On Mon, 18 Dec 2023, 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://urldefense.com/v3/__https://sysctl-explorer.net/net/ipv4/force_igmp_version/__;!!NEt6yMaO-gk!BhrKkLRDUzon0XP8RebeJvai8X02-AU2RBEGA0iJrQsgSIeCPBd4KVVIUoc5jD59w8aYpNbAYiTFWo_sN87x_ZENUoioNQ$
| 
| (MLD permits an "ignore v1 completely" setting, but says it should only be used when
| source filtering is critical:
| https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc3810*section-10.2__;Iw!!NEt6yMaO-gk!BhrKkLRDUzon0XP8RebeJvai8X02-AU2RBEGA0iJrQsgSIeCPBd4KVVIUoc5jD59w8aYpNbAYiTFWo_sN87x_ZEHCk8UTw$  )
| 
| > - 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
| 
| 
| _______________________________________________
| MBONED mailing list
| [e-mail]
| https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mboned__;!!NEt6yMaO-gk!BhrKkLRDUzon0XP8RebeJvai8X02-AU2RBEGA0iJrQsgSIeCPBd4KVVIUoc5jD59w8aYpNbAYiTFWo_sN87x_ZG9c7AK9g$
|