[secdir] secdir review of draft-ietf-roll-admin-local-policy-02

[<[e-mail]>]

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