Last Call Review of draft-ietf-roll-admin-local-policy-02
review-ietf-roll-admin-local-policy-02-secdir-lc-hanna-2015-01-02-00

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