[pim] Re: [secdir] draft-ietf-pim-rfc1112bis-07 early Se cdir review

Thanks a lot, Brian.

All integrated into -08. Inline

On Thu, Feb 05, 2026 at 06:03:06PM -0800, Brian Weis wrote:
> Please excuse the extraneous text at the beginning of the review. Here is a version omitting it.
> I’ve also corrected the Datatracker version.
> 
> Thanks,
> Brian
> 
> ======
> 
> 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.

Thanks. I had actually changed text before this review bevause of EricN's
feedback already to:

The larger address space of IPv6 multicast groups may make it harder
for an IPv6  multicast address from being successfully discovered by
undesired receivers, but many IPv6 multicast addresses are not random but well-defined.

Hope this is fine too.

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

Ack!

And congrats! Long overdue ;-)

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

Great. I've elaborated a bit more and broken it into separate paragraphs:

Receivers in ASM can not control who is sending traffic to them.

Especially in IPv6 with its larger address space, random multicast group addresses 
(see {{receiver-control}}) may help to limit undesired senders if all allowed senders 
and receivers can be trusted not to leak the secret address, and the network towards 
such legitimate senders and receivers can not easily be observed by attackers to determine
the secret random address.

If deployed, network filtering may aid in restricting unexpected or unauthorized traffic.

This sender control problem is the same in unicast except that the methods or likelyhoods
to keep destination host unicast addresses and ASM group addresses secret
vary significantly. There is no analysis of ASM group
address privacy comparable to {{RFC7721}}.

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

Ack.

Leaves a bit open the explanation that the term privacy is a bit misplaced
when talking about addrsses, because its really  targeted at users, and the
mechanisms to support privacy at address level are all about the degree of
secrecy of the addresses.

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

Sure, draft is now using your new text. To counter your valid general concern
of talking about passwords the way i did: The authentication option in OSPF
shouldn't really be called that any more, and the password should also not be
called password. The security properties are just way too weak in todays
expectations to deliver on that original naming promise. Its now just
a "password-in-name-only" ;-)

But given how we're here just to educate multicast and not ospf users,
this wouldn't belong into the text.

Cheers & thanks a lot!
    Toerless

> 
> _______________________________________________
> secdir mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> wiki: https://wiki.ietf.org/group/secdir/SecDirReview
> 

-- 
---
[email protected]

_______________________________________________
pim mailing list -- [email protected]
To unsubscribe send an email to [email protected]