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

<Steve.Hanna@infineon.com> Tue, 30 December 2014 12:55 UTC

Return-Path: <steve.hanna@infineon.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 2C4F41A0097; Tue, 30 Dec 2014 04:55:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id z9sQ1d_iqgs7; Tue, 30 Dec 2014 04:55:54 -0800 (PST)
Received: from smtp2.infineon.com (smtp2.infineon.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD51C1A0095; Tue, 30 Dec 2014 04:55:53 -0800 (PST)
X-SBRS: None
Received: from unknown (HELO mucxv001.muc.infineon.com) ([]) by smtp2.infineon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Dec 2014 13:55:51 +0100
Received: from MUCSE607.infineon.com (mucltm01.eu.infineon.com []) by mucxv001.muc.infineon.com (Postfix) with ESMTPS; Tue, 30 Dec 2014 13:55:53 +0100 (CET)
Received: from KLUSE610.infineon.com ( by MUCSE607.infineon.com ( with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 30 Dec 2014 13:55:50 +0100
Received: from KLUSE610.infineon.com ( by KLUSE610.infineon.com ( with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 30 Dec 2014 13:55:49 +0100
Received: from KLUSE610.infineon.com ([]) by KLUSE610.infineon.com ([]) with mapi id 15.00.0995.032; Tue, 30 Dec 2014 13:55:49 +0100
From: <Steve.Hanna@infineon.com>
To: <secdir@ietf.org>, <iesg@ietf.org>, <draft-ietf-roll-admin-local-policy.all@tools.ietf.org>
Thread-Topic: secdir review of draft-ietf-roll-admin-local-policy-02
Thread-Index: AdAff2eol7wcDrkvTNS1G9OE6YCkGQ==
Date: Tue, 30 Dec 2014 12:55:48 +0000
Message-ID: <7e9a24ab8a294586bc19f23673551c24@KLUSE610.infineon.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0991_01D02406.03E075F0"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/rKZR76ePNvuGD7Mo5pHYvXnixQw
Subject: [secdir] secdir review of draft-ietf-roll-admin-local-policy-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Dec 2014 12:55:57 -0000

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.