[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