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

[Hitoshi Asaeda <[e-mail]>]

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://www.ietf.org/mailman/listinfo/mboned