Re: [Detnet] Roman Danyliw's No Objection on draft-ietf-detnet-bounded-latency-09: (with COMMENT)

Mohammadpour Ehsan <ehsan.mohammadpour@epfl.ch> Fri, 08 April 2022 14:51 UTC

Return-Path: <ehsan.mohammadpour@epfl.ch>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2060C3A0E17 for <detnet@ietfa.amsl.com>; Fri, 8 Apr 2022 07:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=epfl.ch
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 YhjK6G8vh_Sy for <detnet@ietfa.amsl.com>; Fri, 8 Apr 2022 07:51:26 -0700 (PDT)
Received: from smtp4.epfl.ch (smtp4.epfl.ch [IPv6:2001:620:618:1e0:1:80b2:e059:1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60483A0E06 for <detnet@ietf.org>; Fri, 8 Apr 2022 07:51:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=epfl.ch; s=epfl; t=1649429081; h=From:To:CC:Subject:Date:Message-ID:Content-Type:MIME-Version; bh=jhdL9jUfp1Gbrf77N+2WOh6Myfta/rAwercZn2grWl8=; b=J/GrEPhSBqZCw5lIfXyR5U5JpXdWHrH7c8wfT/Y01n70pIviQnlgAD3Opl2sxPAxQ h2aR8T4LCN4VJsUkgUrzEhJ7paKAkB/HrICyETGtFv+lXGTGUx8Q2gkmk7xKABj3T LRcQD7QTSRFb2/SX2CEZQUg/g++XI1QjDF76JGHgo=
Received: (qmail 2836 invoked by uid 107); 8 Apr 2022 14:44:41 -0000
Received: from ax-snat-224-62.epfl.ch (HELO ewa14.intranet.epfl.ch) (192.168.224.62) (TLS, ECDHE-RSA-AES256-GCM-SHA384 (X25519 curve) cipher) by mail.epfl.ch (AngelmatoPhylax SMTP proxy) with ESMTPS; Fri, 08 Apr 2022 16:44:41 +0200
X-EPFL-Auth: TZhd/zXRpnNIztJWlPNjzqbfd64wIQK2pzMZPQnTR7QvGRZnBK8=
Received: from ewa02.intranet.epfl.ch (128.178.224.159) by ewa14.intranet.epfl.ch (128.178.224.62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.24; Fri, 8 Apr 2022 16:44:41 +0200
Received: from ewa02.intranet.epfl.ch ([fe80::ddaf:e0cc:a2d6:4aaf]) by ewa02.intranet.epfl.ch ([fe80::ddaf:e0cc:a2d6:4aaf%3]) with mapi id 15.01.2375.024; Fri, 8 Apr 2022 16:44:41 +0200
From: Mohammadpour Ehsan <ehsan.mohammadpour@epfl.ch>
To: Roman Danyliw <rdd@cert.org>
CC: The IESG <iesg@ietf.org>, "draft-ietf-detnet-bounded-latency@ietf.org" <draft-ietf-detnet-bounded-latency@ietf.org>, DetNet Chairs <detnet-chairs@ietf.org>, DetNet WG <detnet@ietf.org>, "lberger@labn.net" <lberger@labn.net>
Thread-Topic: Roman Danyliw's No Objection on draft-ietf-detnet-bounded-latency-09: (with COMMENT)
Thread-Index: AQHYSbmJ77UuXjsLZUmfEWsBzYJ2Eazl+V+A
Date: Fri, 08 Apr 2022 14:44:41 +0000
Message-ID: <C97D3F41-15B6-4B07-B1FB-51F6C2F5ED2B@epfl.ch>
References: <164925136787.30316.10450416343702279248@ietfa.amsl.com>
In-Reply-To: <164925136787.30316.10450416343702279248@ietfa.amsl.com>
Accept-Language: en-US, fr-CH
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [5.217.73.121]
Content-Type: multipart/alternative; boundary="_000_C97D3F4115B64B07B1FB51F6C2F5ED2Bepflch_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/fO3dJ8rEZyCvSi_-WCJ8Wz6O2Yg>
Subject: Re: [Detnet] Roman Danyliw's No Objection on draft-ietf-detnet-bounded-latency-09: (with COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Fri, 08 Apr 2022 14:51:31 -0000

Dear Roman,

Thanks for your comments. Please find my responses as follows.


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

Thank you to Watson Ladd for the SECDIR review.

** Section 8.  It wasn’t clear to me that outright control of a resource (e.g.,
relay) was needed impact the latency bound calculation.  Recommending a bit
more flexibility on what an attack would take:

OLD
  but may have the
  ability to control some resources within the boundary of the DetNet
  domain.

NEW

but may have the ability to control or change the behavior of some resources
within the boundary of the DetNet domain.

We have changed the text according to your recommendation.


** Section 8.

An example of such attacks is to make some
  traffic sources under the control of the attacker send more traffic
  than their assumed T-SPECs.  This type of attack is typically avoided
  by ingress conditioning at the edge of a DetNet domain

If a traffic source _in the DetNet_ is induced to send more than their T-SPEC,
how does ingress conditioning at the edge help with mitigation?  This DetNet
node is already in the DetNet domain.


Between any traffic source and the rest of DetNet, there is source policing (aka ingress conditioning). Therefore, the traffic generated by any DetNet source passes a traffic policer. If the source sends excessive traffic, it is not allowed to the network as it affects other DetNet flows (may cause QoS violation). Hence, such an attack, mentioned by you, is also mitigated.



** Section 8.  Figure 1 presented a taxonomy of delays (#1 – 6) for the timing
model.  It would be helpful to explicitly extend this taxonomy to a threat
analysis, or to rule out that mitigating certain threats are out of scope.  For
example:

-- 1: Output delay: ?
-- 2: Link delay: somewhat covered by the discussion of timing; and violating
T-SPECs. -- 3: Frame preemption delay: ? -- 4: Processing delay: ? -- 5:
Regulation delay: ? -- 6: Queuing delay: covered by “Some queuing mechanisms
require time synchronization and operate correctly only if the time
synchronization works correctly …”

The delays (1,3,4) are technology-dependent and changing them requires physical access to a DetNet node. This is covered in paragraph 3 of this section:
"Latency bound calculations use parameters that reflect physical quantities. If an attacker finds a way to change the physical quantities unknown to the control and management planes the latency calculations fail and may result in latency violation and/or congestion losses”

Also, an attacker can manipulate this information in the control plane (delays 1,3,4 as well as the parameter of the regulators_ delay 5); this may lead to wrong computation of delay bounds. Such security considerations should be taken care of by the control plane documents and are out of scope of this document.



Best,
Ehsan



--
Ehsan Mohammadpour
PhD candidate at Swiss Federal Institute of Technology (EPFL)
EPFL EDIC PhD student representative
IC IINFCOM, LCA2, INF 011, Station 14, 1015 Lausanne, Switzerland
https://people.epfl.ch/ehsan.mohammadpour

On 6 Apr 2022, at 17:52, Roman Danyliw via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:

Roman Danyliw has entered the following ballot position for
draft-ietf-detnet-bounded-latency-09: 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-bounded-latency/



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

Thank you to Watson Ladd for the SECDIR review.

** Section 8.  It wasn’t clear to me that outright control of a resource (e.g.,
relay) was needed impact the latency bound calculation.  Recommending a bit
more flexibility on what an attack would take:

OLD
  but may have the
  ability to control some resources within the boundary of the DetNet
  domain.

NEW

but may have the ability to control or change the behavior of some resources
within the boundary of the DetNet domain.

** Section 8.

An example of such attacks is to make some
  traffic sources under the control of the attacker send more traffic
  than their assumed T-SPECs.  This type of attack is typically avoided
  by ingress conditioning at the edge of a DetNet domain

If a traffic source _in the DetNet_ is induced to send more than their T-SPEC,
how does ingress conditioning at the edge help with mitigation?  This DetNet
node is already in the DetNet domain.

** Section 8.  Figure 1 presented a taxonomy of delays (#1 – 6) for the timing
model.  It would be helpful to explicitly extend this taxonomy to a threat
analysis, or to rule out that mitigating certain threats are out of scope.  For
example:

-- 1: Output delay: ?
-- 2: Link delay: somewhat covered by the discussion of timing; and violating
T-SPECs. -- 3: Frame preemption delay: ? -- 4: Processing delay: ? -- 5:
Regulation delay: ? -- 6: Queuing delay: covered by “Some queuing mechanisms
require time synchronization and operate correctly only if the time
synchronization works correctly ...”