[pim] Re: Artart last call review of draft-ietf-pim-3228bis-05

[Brian Haberman <[e-mail]>]

Hi Martin,
      Thanks for the review! Some follow-up below...

On 6/4/24 4:47 AM, Martin Dürst via Datatracker wrote:
> Reviewer: Martin Dürst
> Review result: Ready with Issues
> 
> This document obsoletes RFC 3228. I have read both RFC 3228 and this document,
> they were both very short.
> 
> The new document changes registry policy for Type and Code fields in the IPv4
> IGMP header from IESG Approval or Standards Action to Standards Action
> exclusively. It also creates new registries for Query Message Flags (in the
> Multicast Listener Query Message and the IGMPv3 Query Message) and Report
> Message Flags (in the Multicast Listener Report Message and the IGMPv3 Report
> Message). Each of them is populated with one entry, with Standards Action for
> future entries.
> 
> This is mostly a document about registry bookkeeping. I did not find any
> application related issues.
> 
> The main issue and only issue that I found is that the detailed (10 lines)
> security section was replaced with a one-liner in the new document, without
> references elsewhere. As a result, there are some registries, but other than
> "Standards Action", there is no advice at all for what should be considered
> when planning additional registrations.

Several people provided feedback on the security text in 3228 and 
essentially said that it didn't really help. In a sentence, 3228 said 
that global visibility is needed for values in the fields in order to 
assist security devices to know how to interpret them.

Would the following make sense?

OLD:
This document only defines IANA registry actions and there are no 
associated security issues.

NEW:
The fields described in this document control the behavior of IGMP and 
MLD. Incorrect interpretations of these fields can lead to unexpected 
behavior or provide a vector of attack on multicast traffic, 
infrastructure devices, servers, and multicast-enabled hosts. Proper 
registration of used values provides the best opportunity for systems to 
handle these messages appropriately.

The fields controlled by these registries are limited in size. 
Assignments in these fields must be made carefully to ensure they are 
not exhausted. The use of Standards Action helps protect these fields 
from exhaustion.

Regards,
Brian