[secdir] secdir review of draft-ietf-detnet-architecture-08

Daniel Harkins <dharkins@lounge.org> Tue, 25 September 2018 00:58 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A41EA13115B; Mon, 24 Sep 2018 17:58:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Rm1cxrOILv1Z; Mon, 24 Sep 2018 17:58:09 -0700 (PDT)
Received: from www.goatley.com (www.goatley.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6579D1311C8; Mon, 24 Sep 2018 17:58:09 -0700 (PDT)
Received: from trixy.bergandi.net ([]) by wwwlocal.goatley.com (PMDF V6.7-x02 #1001) with ESMTP id <0PFL00NBA6OWQ0@wwwlocal.goatley.com>; Mon, 24 Sep 2018 19:58:08 -0500 (CDT)
Received: from thinny.local ([]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PFL00D6P6M100@trixy.bergandi.net>; Mon, 24 Sep 2018 17:56:26 -0700 (PDT)
Received: from 69-12-173-8.static.dsltransport.net ([] EXTERNAL) (EHLO thinny.local) with TLS/SSL by trixy.bergandi.net ([]) (PreciseMail V3.3); Mon, 24 Sep 2018 17:56:26 -0700
Date: Mon, 24 Sep 2018 17:58:06 -0700
From: Daniel Harkins <dharkins@lounge.org>
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Cc: draft-ietf-detnet-architecture.all@ietf.org
Message-id: <72b6e1cf-3a41-7845-863e-7958a09d36fc@lounge.org>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_lwuImKJGlKANg5eaSkuukg)"
Content-language: en-US
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=
X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [] (EHLO thinny.local)
X-PMAS-Software: PreciseMail V3.3 [180924a] (trixy.bergandi.net)
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/e96EtHujm6Rtmb95EUicKFAOPOQ>
Subject: [secdir] secdir review of draft-ietf-detnet-architecture-08
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: Tue, 25 Sep 2018 00:58:12 -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.

   The summary of the review is ready with issues.

   This draft describes an architecture for deterministic networking
that provides for delivery of packet flows with low packet loss and
with a maximum amount of latency.

   A nit first. The terminology seems a bit overblown. We have DetNet
Intermediate nodes that could be relay nodes or transit nodes; and a
DetNet system that is a DetNet aware system or transit node or
relay node; and DetNet edge nodes that are relay nodes; and DetNet
relay nodes that can be bridges, firewalls, or anything else that
participates in DetNet. Finally, to translate between 802.1 TSN and
DetNet we have a "relay system" that is an 802.1 term for a DetNet
intermediate node which, as we have seen, is a DetNet relay node. This
can be simplified considerably.

   The Security Considerations is thin, especially for an architecture
draft that is going to be referred to by subsequent drafts which will
just say something along the lines of, "as an instance of the DetNet
FooBar, these Security Considerations are those from [ARCH]", where
ARCH is the RFC that comes out of this I-D. I think there needs to be
a description of the various points in the architecture that an attacker
could exploit, and if a point is not exploitable it should say so. For

   - is it possible for an attacker to launch a DoS attack by manipulating
     member flows of a DetNet flow in order to force DetNet nodes to
     consume buffers they allocated to deal with the DetNet flow?

   - If an end system is not DetNet aware there needs to be a DetNet edge
     node to handle the encaps of the flow into the DetNet system. Can an
     attacker in that case introduce packets that shouldn't be part of the
     DetNet flow into the flow by getting the edge node to encaps them as

If there are any assumptions being made-- e.g. "insider attacks are not
being considered"-- they should be mentioned.