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.   This document describes a technique for automatically managing the boundaries of the admin-local multicast scope in a border router, using MPL (Multicast Protocol for Low power and Lossy Networks).   In my view, this document is Not Ready.   The document is hard to understand. For example, the acronyms MPL and MPL4 are used throughout the document but they are not defined.   After reading the document several times, I have concluded that section 3.2 contains the most important part of the document: an algorithm for automatically defining the boundaries of the admin-local multicast scope using MPL. This section basically says that a border router should periodically send an MPL message on all interfaces to the ALL_MPL_FORWARDERS multicast address with admin-local scope. It should also listen for such messages on all interfaces. If it receives such a message, that interface should be marked as part of the admin-local scope.   This algorithm seems problematic from a security standpoint. Because any device on a network can send an MPL message to the ALL_MPL_FORWARDERS multicast address with admin-local scope, the boundaries of the admin-local multicast scope can be expanded by attackers fairly easily. Such manipulation may permit nodes that should be outside a particular administrative domain to join that domain and participate in receiving and sending multicast traffic within that domain. The implications of such an attack are not clear to me because I am not familiar with the protocols and devices that use admin-local multicast scope. However, it seems likely that expanding the admin-local multicast scope will permit external attackers to more easily monitor multicast traffic that should be private and to inject multicast messages into a relatively trusted domain.   In addition to this fundamental concern, I have a few minor concerns about the readability of the document. However, I seem to have mislaid my notes during the holidays. Because this review is already late and I’m on vacation, I will send the review now and follow up with the minor concerns at a later date if I can find them when I return to the office.   Thanks,   Steve   Attachment: smime.p7s Description: S/MIME cryptographic signature