[Detnet] Roman Danyliw's No Objection on draft-ietf-detnet-yang-19: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Tue, 13 February 2024 18:59 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: detnet@ietf.org
Delivered-To: detnet@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFECC14F61F; Tue, 13 Feb 2024 10:59:03 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-detnet-yang@ietf.org, detnet-chairs@ietf.org, detnet@ietf.org, janos.farkas@ericsson.com, janos.farkas@ericsson.com
X-Test-IDTracker: no
X-IETF-IDTracker: 12.5.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <170785074396.65065.16231322901267436847@ietfa.amsl.com>
Date: Tue, 13 Feb 2024 10:59:03 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/5vfHKcthWYTCrw2Sv5_lMBrU-vs>
Subject: [Detnet] Roman Danyliw's No Objection on draft-ietf-detnet-yang-19: (with COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Feb 2024 18:59:04 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-detnet-yang-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-detnet-yang/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 10.  Per the write operations:

-- Editorial. Consider if this might be clear:

OLD
   Write operations (e.g., edit-config)
   to these data nodes without proper protection can break or
   incorrectly connect DetNet flows.
   Since this is a configured Data
   Plane any changes that are not coordinated with all devices along the
   path the whole DetNet module is considered vulnerable and should have
   authorized access only.

NEW
Unauthorized write operations (e.g., edit-config) to any elements of this
module can break or incorrectly connect DetNet flows. Since DetNet is a
configured Data Plane, any changes that are not coordinated with all devices
along the path will create a denial of service.

-- Is it possible quantify the security impact of these changes beyond a DoS? 
Is the following accurate, or is coordinate required in the path required?

NEW
Additional, arbitrary write operations could also enable an attacker to modify
a network topology to enable select traffic to avoid inspection or treatment by
security controls, or route traffic in a way that it would be subject to
inspect/modification by an adversary node.

** Section 10.  Per the read operations:

These are the subtrees and data
   node and their sensitivity/vulnerability:

   /detnet/app-flows: This controls the application details so it could
   be considered sensitive.

   /detnet/traffic-profile/member-app: This links traffic profiles to
   applications, service sub-layers and/or and forwarding sub-layers so
   this also could be considered more sensitive.

   /detnet/service/sub-layer/incoming/app-flow: This links applications
   to services.

   /detnet/service/sub-layer/outgoing/app-flow: This links applications
   to services.

-- Please amend the text to explain why these nodes are sensitive (i.e., why
revealing this information is a problem).

-- Is there confidence that only these nodes are read sensitive?  Wouldn’t
almost every part of the module reveal internal topology which would inform the
targeting of an attacker?