Early Review of draft-ietf-pim-gaap-11
review-ietf-pim-gaap-11-rtgdir-early-zhang-2026-03-25-00

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
https://datatracker.ietf.org/doc/draft-ietf-pim-gaap/

The Routing Directorate seeks to review all routing or routing-related drafts
as they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-pim-gaap-11
Reviewer: Zheng(Sandy) Zhang
Review Date: 2026-03-25
Intended Status: Experimental

Summary:
The draft is mostly clear and we can move on to the next step, but some
questions need to be clarified.

Comments:
Please consider the comments listed below with ZZ>.

                Group Address Allocation Protocol (GAAP)
                         draft-ietf-pim-gaap-11
......
4.  GAAP Message Format
......
   Record field descriptions:
......
      Group Name:  A variable length group name the multicast
         application uses.  It is in ASCII format [RFC0020].  The string
         is terminated with a null character.  Since the Group Name is
         variable length, subsequent records may not occur on a long- or
         short-word boundary.

ZZ> Because the Group Name is variable-length, the message length may be
unpredictable based on the Record Count. Furthermore, if the Group Name length
isn't fixed, how do we determine the starting position of the next record? Is
it determined by the string terminator "\0"? If it's determined by the string
terminator, then the next record could start at any position, even a non-8-bit
aligned position. Is that acceptable?

......
6.  Detail Protocol Operation

6.1.  Allocating Group Addresses

   When an application needs a group address it provides the GAAP API
   with a group name, the group name is used as input to a SHA-256 hash
   function [RFC6234].  Initially, when no group address collision is
   detected the group name is passed as a string to the hash function
   and the low-order 32-bits are used for a group address.  The
   following pseudo-code illustrates the functionality:

ZZ> Using the algorithm in RFC6234, is the result calculated based on the Group
Name unique? Is it possible for the same Group Name to correspond to different
Group Addresses?

......
6.2.  Claiming Group Addresses

   When a group address is allocated by a GAAP node it will build and
   send a Claim message.  Included in the Claim message is the group
   name, group address, and timestamp.  If the group address collides
   with other GAAP nodes already using the address, one of the nodes
   will send a Claim message to notify the colliding node that it needs
   to allocate a new group address.

   A collision is defined to be the same group address allocated to 2
   different group names.  So if a GAAP node is claiming a group address
   for its group name and a Claim is received with the same group name
   with the same group address, it is not a collision.  It is simply a
   peer group participant claiming the group address you both agree to
   be using.

ZZ> The conflict is identified from different Group Names using the same Group
Address. Does this imply two points? 1) that all GAAP-using applications must
use the same Group Address when using the same Group Name? 2) addressing the
same issue in section 6.1: if the hash result is not unique, is it normal for
different applications to advertise the same Group Name but different Group
Addresses?

......
7.  Security Considerations

   It is strongly suggested that the GAAP protocol run over an encrypted
   multicast channel.  All GAAP implementations should support the same
   encryption mechanism and use the same key management procedure to
   ensure interoperability.  This could be difficult in embedded devices
   with different configurations.  The message Marker is used to
   indicate if the packet is sent in plaintext or ciphertext.  If the
   Marker is not set to 0xAAAAAAAA and the receiver does not have a
   shared-key configured, the message MUST be dropped.

ZZ> As described in section 4, messages should be dropped regardless of whether
the Marker field in the message is not set to 0xAAAAAAAA, or encrypted tunnel
is used but the receiver is not configured with a shared key. Therefore, please
consider revising "If the Marker is not set to 0xAAAAAAAA and the receiver does
not have a shared key configured, the message MUST be dropped." to "If the
Marker is not set to 0xAAAAAAAA or the receiver does not have a shared key
configured, the message MUST be dropped."

......
   The following attack threats may exist with possible mitigation
   techniques:

   *  Even when an encrypted channel is used, a bad actor could be
      claiming a group address not derived from one of the group name
      inputs used for the Acceptable Group Hash List (see Definition of
      Terms section).  Cooperating nodes should ignore such messages and
      not try to send Claim messages to correct the bad actor node.

   *  A bad actor could send an invalid timestamp giving it tie-breaking
      priority when a group address collision occurs.  If the group
      address has been prior claimed by another node with a timestamp
      earlier than the invalid timestamp, cooperating nodes should put
      the bad actor node on a bad-actor list and ignore future messages
      from it.  If the group name has not been claimed yet, the
      timestamp will be accepted only if earlier than the current time
      for the receiving node.

   *  A bad actor could send messages too often and is not adhering to
      the random delay or periodic timer procedures in this document.
      When this occurs, cooperating nodes should start ignoring messages
      from the bad actor node and not reset or cancel timers, or send
      triggered Claim messages

ZZ> Are there other bad actors that waste receiver processing time by
constantly sending forged claim messages that carry Group Names that other
nodes don't have?

[End of Review]