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]