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
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
