[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?
- [Detnet] Roman Danyliw's No Objection on draft-ie… Roman Danyliw via Datatracker