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

[Brian Haberman <[e-mail]>]

Hey Stig,
      Unfortunately, I will not be able to join the meeting as I will be 
on an airplane...

      I think you should note on slide 3 what the impact of each 
approach would have on advancing the spec to Internet Standard. To do 
that correctly, I think you have to break the last recommendation into 
two (add a recommendation, mandate a change).

      Personally, it seems like most of the scenarios posited have been 
related to old kit or mis-configuration. We can't standardize away those 
types of actions. At best, I think we can add recommended default 
settings for the compatibility mode variables referenced in section 7.

Regards,
Brian

On 3/19/24 8:34 PM, Stig Venaas wrote:
> Hi all
> 
> We have an agenda slot to discuss this here in Brisbane. Please join,
> in person or remotely to help us make the right decision.
> 
> You can see my proposed slides here
> https://datatracker.ietf.org/meeting/119/materials/slides-119-pim-rfc3376bis-v2-querier-fallback-issue-00
> 
> Let me know if you think this is inaccurate in any way or if there are
> important points we need to add. I know myself and others have
> different thoughts on this, it was hard resisting putting my own
> opinions in the slides. I plan to raise them as a participant at the
> meeting. Hope many of you can take part in the meeting as well.
> 
> Anyone from mboned seeing this, you are of course welcome to join as well.
> 
> Brian, are you able to join?
> 
> Thanks,
> Stig
> 
> On Tue, Jan 2, 2024 at 5:39 AM 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$
>>> |