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

["Martin J. Dürst" <[e-mail]>]

Hello Brian,

Please see inline.

On 2024-06-04 22:31, Brian Haberman wrote:
> 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.

My reading was that it mainly pointed to the problems that might arise 
when new values were defined, but not yet implemented everywhere.
We could call this the compatibility issue or the upgrade issue.


> 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.

All of the above isn't wrong, and I wouldn't oppose it. But it doesn't 
mention the compatibility/upgrade issue that was in the old document.

For my part, I'm fine with whatever the WG and the IESG is happy with. I 
just want to make sure that it's clear where I saw an issue.


Regards,   Martin.

> Regards,
> Brian