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

[Stig Venaas <[e-mail]>]

Hi Brian

I'm personally fine with no changes, if we make changes then I think
they should be at most recommendations. Hopefully we will see more
widespread IGMPv3 support and this will be less of an issue. It will
also help if implementations have IGMPv3 enabled by default.

Section 7.2 is the more problematic part, but the issue is mainly with
some unmanaged/unexpected device using version 1 or 2 I believe. If
there are unexpected pim routers present or some pim router has wrong
configuration, then things may break in many ways even if we were to
address the v3 fallback. E.g. the unexpected device may become DR and
not supporting v3 at all, or not having correct RP configuration.

Regards,
Stig

On Thu, Jan 4, 2024 at 11:41 AM Brian Haberman <[e-mail]> wrote:
>
> Hi Hitoshi and Dave,
>       Sorry for the delay in responding... I agree with separating
> protocol design/behavior from operational policies. What I am trying to
> determine is if there are concrete changes needed in the updated specs,
> ideally to move them to Internet Standard. *If the WG thinks these SSM
> issues are critical, we should discuss a revision that captures the
> necessary changes and stays at Proposed Standard.*
>
>       While my initial response focused on leveraging the SSM address
> range, Hitoshi's comments got me to go back and re-re-read section 7.
>
>       Section 7.2.1is clear that hosts manage their compatibility mode
> based on the version of IGMP queries and its Host Compatibility Mode
> variable. In this sense, any multicast address can be leveraged for SSM
> operations if all the routers use IGMPv3.
>
>       Section 7.3.1 also recommends using a configuration option to
> manage compatibility mode between routers. The logging recommendation
> should allow operators to determine if routers on the network are not
> operating in the desire mode.
>
>       Section 7.3.2 has similar language that allows for determining,
> per-group, if systems are not operating as expected.
>
>       Given the above, is Section 2 in RFC 4604 still seen as
> problematic? The compatibility mode discussed in Section 7.3.2 captures
> the need for per-group state to track the version of IGMP operation.
>
>       Are there concrete text changes people would like to see in
> 3376bis? I think the one pending update would be if we want to add a
> recommended default value for the compatibility mode variables.
>
> Regards,
> Brian
>
> On 1/2/24 11:53 AM, Dave Katz 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
> >
> >
> >
> >> 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$
> >>
> >
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned