[pim] draft-ietf-pim-pfm-forwarding-enhancements-05 ietf last call Secdir review
Christian Huitema via Datatracker <noreply@ietf.org> Wed, 20 May 2026 18:31 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: pim@ietf.org
Delivered-To: pim@mail2.ietf.org
Received: from [10.244.11.249] (unknown [4.156.85.76]) by mail2.ietf.org (Postfix) with ESMTP id DBE16F1C78F9; Wed, 20 May 2026 11:31:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1779301873; bh=LSfqQ/IKmocFlYEYw3qQR0+s8gq40WzVcq2bk0tWyFM=; h=From:To:Cc:Subject:Reply-To:Date; b=e5aGCzjg0ivsc2xv96Eq3TGPJZxiU2Z31xeKVPPCO06XGsDpvjyOf5p/tg7BgFGQZ BnN4znY0X6Y7eyPqOpyrJFCniiGU7Q9PQy7YPHDHf8z2FBzcY6E8iu0kndBR9VsMNr 34c+M4hHNBur08LlsBJXzoBx44aU54hDnFfTw44Q=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Christian Huitema via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.65.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <177930187380.1149.11470812261957516421@dt-datatracker-6995bf6b4c-lv9zr>
Date: Wed, 20 May 2026 11:31:13 -0700
Message-ID-Hash: 4JT6H3VEL5KE6IEPU6KJY7X5E5TR5AS7
X-Message-ID-Hash: 4JT6H3VEL5KE6IEPU6KJY7X5E5TR5AS7
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pim.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-pim-pfm-forwarding-enhancements.all@ietf.org, last-call@ietf.org, pim@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: Christian Huitema <huitema@huitema.net>
Subject: [pim] draft-ietf-pim-pfm-forwarding-enhancements-05 ietf last call Secdir review
List-Id: Protocol Independent Multicast <pim.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/rhgZFBhExQb-dvlG1yg68KJDgyQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Owner: <mailto:pim-owner@ietf.org>
List-Post: <mailto:pim@ietf.org>
List-Subscribe: <mailto:pim-join@ietf.org>
List-Unsubscribe: <mailto:pim-leave@ietf.org>
Document: draft-ietf-pim-pfm-forwarding-enhancements Title: PIM Flooding Mechanism and Source Discovery Enhancements Reviewer: Christian Huitema Review result: Ready Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready This document, draft-ietf-pim-pfm-forwarding-enhancements-05, specifies improvements to the flooding mechanism used to propogate multicast information among Protocol Independent Multicast (PIM) routers. If there are multiple links between a pair of PIM routers, the improvement leads to sending multicast information once per pair instead of once per link. There are pros and cons to doing this kind of improvement. The flooding mechanism is very robust, but also sends a lot of messages that turn out to be duplicates. The proposed improvement reduces the amount of duplicate messages, and if done smartly should not reduce the robustness of the propagation. However, the "smarts" used to reduce the number of messages are based on information about the state of the links. A router will only be aware that a link failed some time after that failure. During that "non awareness" period, there is a risk that multicast information sent to the failing link will be lost, or at least delayed. I assume that this was studied by the WG, that some corrective action will kick in, and that everything will be fine. But I did not see in the draft a discussion of that potential reduction in robustness. The security consideration section directs the reader to RFC 7761, which itself refers to RFC 5796 for a description of how to use IPSEC to secure traffic between PIM routers. IPSEC would indeed mitigate the message forgery attacks described in the security section of RFC 7761. I understand that use of IPSEC is optional in PIM deployments. It might be nice to point out that the proposed improvement to flooding might offer more opportunity for message forgery attacks by eliminating the redundant message paths, and that using IPSEC might be a very good idea. -- Christian Huitema
- [pim] draft-ietf-pim-pfm-forwarding-enhancements-… Christian Huitema via Datatracker