Re: [pim] [MBONED] IGMPv3 backward compatibility issue killing SSM

[Dave Katz <[e-mail]>]

I also see I marked it as proprietary back then, so it goes.  I think it’s generally useful information and whatever advantage we might have had for actually knowing what we were implementing has probably dissipated…

—Dave

> On Jan 2, 2024, at 8:53 AM, Dave Katz <[e-mail]> wrote:
> 
> Here’s something I wrote up about 15 years ago (!) when I rewrote IGMP when we expected that cable TV was going to be delivered by multicast (that didn’t quite work out, thank you Netflix).
> 
> I’ve forgotten all of it but perhaps there is something to be gleaned from the document…
> 
> —Dave
> 
> <igmp_guide.txt>
> 
>> On Jan 2, 2024, at 8:28 AM, Hitoshi Asaeda <[e-mail]> wrote:
>> 
>> [External Email. Be cautious of content]
>> 
>> 
>> Hi Brian and folks,
>> 
>> I have a different opinion about Lenny's comment.
>> 
>> Dependency or relation between protocol designs and operational issues (or policies) should be always minimized.
>> Protocol behavior should not be solidly relies on the address range.
>> 
>> IP multicast has a long history for allocating (or chopping) its address ranges. We had adopted complicated "address scopes" such as administrative/site-local/organization-local scope... How we can interact with SSM range and them?
>> I've just remembered GLOP. How SSM and GLOP can be interacted with?
>> One may deduce, no need to interact with them, use SSM range.
>> Then what address ranges are obsolete today? What range should be used now? Is its decision persistent?
>> Such a dirty hack or patch work is not sustainable for designing protocols.
>> 
>> What I'm saying here may be a bit too conceptual. So, please ignore the points if people agree to relying on the SSM range. However, even so, I guess the following point must be taken into account.
>> Section 2 in RFC4604 says;
>>  A host or router may be configured to apply SSM semantics to
>>  addresses other than those in the IANA-allocated range.  The GMP
>>  module on a host or router SHOULD have a configuration option to set
>>  the SSM address range(s).  If this configuration option exists, it
>>  MUST default to the IANA-allocated SSM range.  The mechanism for
>>  setting this configuration option MUST at least allow for manual
>>  configuration.  Protocol mechanisms to set this option may be defined
>>  in the future.
>> I think this paragraph implies that applications that want to invoke SSM services can use any multicast address range.
>> If RFC4604 should be the normative reference, RFC4604 itself must be also revised.
>> 
>> Regards,
>> 
>> Hitoshi
>> 
>> 
>>> On Jan 2, 2024, at 22:39, Brian Haberman <[e-mail]> wrote:
>>> 
>>> Lenny's assessment is correct from my perspective. Section 7.3.2 specifies that IGMP version compatibility is kept on a per-group basis. This should preclude compliant routers from disabling SSM service in the SSM address range.
>>> 
>>> Section 7.3.1 discusses the compatibility mode configuration option for IGMPv3 routers, but there is not a recommended default setting for that option.
>>> 
>>> Are there aspects of RFC 4604 that people think need to be updated?
>>> 
>>> Regards,
>>> Brian
>>> 
>>> On 12/19/23 4:09 PM, Leonard Giuliano wrote:
>>>> 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$
>>>> |
>>> _______________________________________________
>>> MBONED mailing list
>>> [e-mail]
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mboned__;!!NEt6yMaO-gk!CdCLpafWuYi5H5RtrXjSntQWEXq4pVwYPcx3vYhCezHPEQLfj04lbhOJPl4t7LCjKcwHNQokMyBl$
>> 
>