Early Review of draft-ietf-pim-rfc1112bis-07
review-ietf-pim-rfc1112bis-07-secdir-early-weis-2026-02-05-01

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 Has Nits.

This document updates RFC 1112, “Host Extensions for IP Multicasting”
published in 1989 to take into consideration the many newer IP
multicasting methods and considerations in today’s networks.

The Security Considerations section in rfc1112bis is comprehensive,
describing many of the practical security issues with Any Source
Multicast and to some extent Single Source Multicast. A few wording
changes should be mode, but none are issues. Most quibble with the use
of the word “secret”.

1. Section 12.2, second sentence. While the larger address space of IPv6
multicast groups might better obscure which groups are in use, it’s a
stretch to say it “may make it easier to keep an IP multicast address
secret from being successfully discovered by undesired receivers.” I
would rephrase the sentence without the word “secret”, since there’s no
actual secrecy involved. Maybe something like this:

OLD:
   The larger address space of IPv6 multicast groups may make it easier
   to keep an IP multicast address secret from being successfully
   discovered by undesired receivers.

NEW:
   The larger address space of IPv6 multicast groups may make it more
   difficult for undesired receivers to successfully discover which
   multicast groups are in use.

2. Sections 12.2 and Section 12.4: Please replace references to [GDOI]
with [RFC9838], as this newer RFC obsoletes GDOI.

3. Section 12.3, first sentence:  A receiver “can not control who is
sending traffic to them”, period. Even if the traffic is encrypted,
elsewhere the document correctly mentions that other receivers holding
the same traffic keys may be able to send unauthorized traffic. While in
some cases the network may restrict what is sent to them, and somewhat
protect them, the receivers aren’t in control. So I would also suggest
re-wording the first sentence as something like this:

OLD:
   Receivers in ASM can not control who is sending traffic to them
   unless they can rely on the aforementioned IP multicast address
   secrecy.

NEW:
   Receivers in ASM cannot control who is sending traffic to them. If
   deployed, network filtering may aid in restricting unexpected or
   unauthorized traffic, and as mentioned earlier the larger address
   space of IPv6 multicast groups may make it more difficult for
   undesired receivers to successfully discover which multicast groups
   are in use.

4. Section 12.3, second sentence: To my reading, RFC 7721 (referenced in
the next sentence) mainly describes mechanisms that can aid in keeping
an address “private”, which is a different property than “secret”.  I
suggest replacing “secret” with “private” in the second sentence.

5. Section 12.5.3 second paragraph: I don’t disagree with describing of
using OSPFv2 passwords as a separation mechanism, but it’s dangerous to
state that they “do not even have to be secret”. Passwords are
inherently meant to be secret and their value is diluted if they are
treated otherwise. For example, if users use network configuration tools
to share passwords unprotected, then when they later mean for passwords
to be secret they may unintentionally share them unprotected.  I would
recommend rewording something like the following:

OLD:
   In [OSPFv2], the common solution against this issue is to rely on the
   authentication option and simply distinguish instances through
   separate passwords - which then do not even have to be secret because
   they are not intended to protect against attacks but simply double as
   instance identification to protect against accidental incorrect
   wiring.

NEW:
   In [OSPFv2], the common solution against this issue is to rely on the
   authentication option and simply distinguish instances through
   separate passwords. This is a practical separation strategy,
   providing an instance identification to protect against accidental
   incorrect wiring.