[pim] Deb Cooley's No Objection on draft-ietf-pim-3810bis-11: (with COMMENT)

[Deb Cooley via Datatracker <[e-mail]>]

Deb Cooley has entered the following ballot position for
draft-ietf-pim-3810bis-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pim-3810bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Valery Smyslov for his secdir review.  I'm copying part of his review
here:

--------------------------------------------
I think that the Security Consideration section should be expanded and be
rewritten in a more structural way. In particular, it should be mentioned that
the protocol lacks any cryptographic protection, thus its messages are not
authenticated, provide no confidentiality and can be replayed. Then I would
discuss the consequences of each of these deficiencies.

The lack of replay protection seems to have no effect on the protocol security,
because it is (at least it should be) designed so that it tolerates IP packets
duplication (correct me if I'm wrong, I read the protocol itself briefly, but
this was my impression).

The lack of authentication leads to possible message forgery. The corresponding
attacks are described in the draft, however, I'm not sure taht the list is
complete. For example, it seems to me that forged Current State Report message
from a malicious node may report a lot number of faked listening multicast
addresses, aiming to consume router's resources (a kind of DoS attack).

The lack of confidentiality is not discussed in the draft. In fact, it leads to
privacy issues - any passive attacker on the local link can learn what
multicast addresses other nodes are listen to, which may be quite sensitive
information.
---------------------------

With respect to that review, and the author response:

It is understood that it is very difficult/impossible to provide either
confidentiality or integrity protection for traffic in protocols such as MLD -
both multicast and discovery.  From my point of view, the only option would be
to modify the Security Consideration section.  I think one could use Valery's
suggestions, as appropriate (if replay isn't an issue, then leave that part
out, etc.).

Thanks for your attention.