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

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.

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.


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

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