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

Hi Toerless,

Thanks for the reply. I’ve added a couple comments inline.

> On Feb 26, 2026, at 6:41 PM, Toerless Eckert <[email protected]> wrote:
> 
> 
> 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.

That’s a very good addition.

> 
>> 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 ;-)

Yes. :-)

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

That sounds fine to me.

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

Yes, makes sense. 

Thanks,
Brian

> 
> Cheers & thanks a lot!
>    Toerless
> 
>> 
>> _______________________________________________
>> secdir mailing list -- [email protected] <mailto:[email protected]>
>> To unsubscribe send an email to [email protected] <mailto:[email protected]>
>> wiki: https://wiki.ietf.org/group/secdir/SecDirReview
>> 
> 
> -- 
> ---
> [email protected] <mailto:[email protected]>

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