Re: [secdir] [Roll] Secdir last call review of draft-ietf-roll-turnon-rfc8138-12

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 06 September 2020 16:35 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BBC3A0C9B; Sun, 6 Sep 2020 09:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byJUUCmuVk4i; Sun, 6 Sep 2020 09:34:58 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 634493A0C9A; Sun, 6 Sep 2020 09:34:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B4F45389BD; Sun, 6 Sep 2020 12:13:46 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0b6jFDXGSdQy; Sun, 6 Sep 2020 12:13:44 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AB580389B4; Sun, 6 Sep 2020 12:13:44 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9EE44FB; Sun, 6 Sep 2020 12:34:52 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
cc: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-roll-turnon-rfc8138.all@ietf.org" <draft-ietf-roll-turnon-rfc8138.all@ietf.org>
In-Reply-To: <MWHPR16MB15352A9604389BC647A87A5FEA2A0@MWHPR16MB1535.namprd16.prod.outlook.com>
References: <MWHPR16MB15352A9604389BC647A87A5FEA2A0@MWHPR16MB1535.namprd16.prod.outlook.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sun, 06 Sep 2020 12:34:52 -0400
Message-ID: <1440.1599410092@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/VS2OIrahRoHd3Cm7Jz5UJVfzNpU>
Subject: Re: [secdir] [Roll] Secdir last call review of draft-ietf-roll-turnon-rfc8138-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 06 Sep 2020 16:35:01 -0000

Thank you for the review.

Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com> wrote:
    > [1] You may want to clarify how the attacker manages to modify a
    > protected configuration including the "T" flag introduced in this
    > spec.

Every router within every routing protocol can do wrong things :-)
RPL is an IGP, so all routers are within the same security control, and at
the same level.

An attacker would have to introduce malware into the device to modify data.
RFC7416 lays out all of these threats: they are no different for the T-bit
than other bits.

    > [2] Is it possible to identify the attacker (or compromised router) who
    > set the "T" flag to remediation measures ?

Maybe. Probably not.
There are few things we can do within any routing protocol to identify
mis-behaving routers.

    > [3] If due to an human error one or more of the on-path routers are not
    > upgraded or if the router sees both settings, I presume an alert could
    > be sent to the network management for troubleshooting. You may want to
    > add text to discuss the same.

At present, RPL does not include a standard off-path alerting mechanism.
This remains a todo item for the WG.
Some use NETCONF or HTTP to collect statistics in a proprietary way.
We can send ICMPs, but since the affects how the packets are encoded, we
likely can't send an ICMP to a relevant router, just one hop in the direction
it came from.

    > [4] What do you mean by "subDAG" (I don't see any definition in this spec and RFC8138) ?

It's a sub-portion of a DAG. A sub-tree.


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide