Multicast Listener Discovery Version 2 (MLDv2) for IPv6
draft-ietf-pim-3810bis-12

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.

I reviewed the diff between this and RFC3810 only for this position.

I don't understand the SHOULD NOTs in Section 5.2.13.  What harm to interoperability results from sending them if they are simply ignored?

# Orie Steele, ART AD, comments for draft-ietf-pim-3810bis-11 
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pim-3810bis-11.txt&submitcheck=True

## Comments

### Why not MUST NOT?

```
1182	           multicast address, if it is non-empty.  An SSM-aware host
1183	           SHOULD NOT send a MODE_IS_EXCLUDE record type for multicast
1184	           addresses that fall within the SSM address range as they will
1185	           be ignored by SSM-aware routers [RFC4604].
```

```
1206	           the specified multicast address, if it is non-empty.  An SSM-
1207	           aware host SHOULD NOT send a CHANGE_TO_EXCLUDE_MODE record
1208	           type for multicast addresses that fall within the SSM address
1209	           range.
```

Is this simply a SHOULD because it won't cause harm, because it is ignored?

Are there cases where an SSM-aware host MUST / MUST NOT send MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE ?

### Why not MUST?

```
1292	   Records of the Report message.  From now on, it will treat packets
1293	   sent to those multicast addresses according to this new listening
1294	   state.  Once a valid link-local address is available, a node SHOULD
1295	   generate new MLDv2 Report messages for all multicast addresses joined
1296	   on the interface.
```

Under which conditions should a node not generate new new MLDv2 Report messages.

```
2414	   SHOULD log an error.  It is RECOMMENDED that implementions provide a
2415	   configuration option to disable use of Host Compatibility Mode to
2416	   allow networks to operate only in SSM mode.  This configuration
2417	   option SHOULD be disabled by default.
```

implementions -> implementations

Under which conditions is it ok to leave this configuration enabled by default?

Thank you to Russ Housley for the GENART review.

** Idnits reported the following:

  -- The document seems to contain a disclaimer for pre-RFC5378 work, and may
     have content which was first submitted before 10 November 2008.  The
     disclaimer is necessary when there are original authors that you have
     been unable to contact, or if some do not wish to grant the BCP78 rights
     to the IETF Trust.  If you are able to get all authors (current and
     original) to grant those rights, you can and should remove the
     disclaimer; otherwise, the disclaimer is needed and you can ignore this
     comment. (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

Has one of the original authors of RFC3376 been approached to file the appropriate paperwork with the Trust to assign the new rights?

Thanks for working on this specification.

# Éric Vyncke, INT AD, comments for draft-ietf-pim-3810bis-11

Thank you for the work put into this document. I have mainly reviewed the diff with RFC 3810:
https://author-tools.ietf.org/iddiff?url1=rfc3810&url2=draft-ietf-pim-3810bis-11&difftype=--html

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit.

Special thanks to Stig Venaas for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status (i.e., it is "Internet Standard").

Other thanks to Sheng Jiang, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-pim-3376bis-11-intdir-telechat-halley-2024-07-28/ (just one nit that I have repeated in my ballot)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Section 5.1.6

Should the IANA registry name be used rather than the reference to the RFC creating that registry ?

Unsure whether allocation is the right term to be used here, suggest to use "Specification".

Should there be the usual text "unassigned bits in the Flags field MUST be set to 0 on transmission and MUST be ignored on reception" ?

## Section 5.1.11

Should `unicast addresses` be refined ? I.e., can it be link-local ? or unspecified ?

## Appendix B.1

Unsure whether this section (about changes from MLDv1) is useful in a -bis document.

# NITS (non-blocking / cosmetic)

## Sections 7.6.2

Repeating Sheng Jiang nits about using lower case in IPv6 addresses per RFC 5952 (especially since all other IPv6 addresses are rightfully written).