[secdir] Re: Secdir last call review of draft-ietf-pim-3810bis-10

[Brian Haberman <[e-mail]>]

Hi Valery,
      Thanks for the comments. I think we need to have a discussion as 
to how much of the below details to include given the history of 
multicast traffic. For example:

  - The multi-destination model of multicast makes it very difficult to 
provide any kind of confidentiality for multicast control traffic 
flowing from routers to hosts,

- The use of link-local multicast destination addresses (from link-local 
unicast addresses or even no source address) for signaling from host to 
routers precludes the use of crypto to prevent message forgery.

Looking for guidance from the SEC ADs on how to proceed with the below 
suggestions.

Regards,
Brian

On 5/29/24 4:43 AM, Valery Smyslov via Datatracker wrote:
> Reviewer: Valery Smyslov
> Review result: Has Issues
> 
> 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 document describes the Multicast Listener Discovery protocol version 2
> (MLDv2) for IPv6. This protocol allows IPv6 routers to discover the presence of
> multicast listeners on directly attached links, and to discover which multicast
> addresses are of interest to these listeners. The draft is well written and
> easy to understand. There are few issues though, that relate to security of the
> protocol.
> 
> 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.
> 
>