Skip to main content

IETF Last Call Review of draft-ietf-pim-pfm-forwarding-enhancements-05
review-ietf-pim-pfm-forwarding-enhancements-05-secdir-lc-huitema-2026-05-20-00

Request Review of draft-ietf-pim-pfm-forwarding-enhancements
Requested revision No specific revision (document currently at 05)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2026-05-21
Requested 2026-05-07
Authors Ananya Gopal , Stig Venaas , Francesco Meo
I-D last updated 2026-05-21 (Latest revision 2026-05-06)
Completed reviews Secdir IETF Last Call review of -05 by Christian Huitema
Assignment Reviewer Christian Huitema
State Completed
Request IETF Last Call review on draft-ietf-pim-pfm-forwarding-enhancements by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/J0wur92MH8iv8Q-Qzu7_k8Lk4zw
Reviewed revision 05
Result Ready
Completed 2026-05-20
review-ietf-pim-pfm-forwarding-enhancements-05-secdir-lc-huitema-2026-05-20-00
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