[Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-security-13: (with DISCUSS and COMMENT)

Magnus Westerlund via Datatracker <noreply@ietf.org> Tue, 22 December 2020 14:12 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 D350B3A10CB; Tue, 22 Dec 2020 06:12:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Magnus Westerlund via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-detnet-security@ietf.org, detnet-chairs@ietf.org, detnet@ietf.org, Lou Berger <lberger@labn.net>, lberger@labn.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <160864632278.13800.15298127874258170906@ietfa.amsl.com>
Date: Tue, 22 Dec 2020 06:12:02 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/o_5xiB8-3wbDXTLixXZpmVNErSg>
Subject: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-security-13: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
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, 22 Dec 2020 14:12:03 -0000

Magnus Westerlund has entered the following ballot position for
draft-ietf-detnet-security-13: Discuss

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Section 3.1:

   A DetNet system security designer relies on the premise that any
   resources allocated to a resource-reserved (OT-type) flow are
   inviolable, in other words there is no physical possibility within a
   DetNet component that resources allocated to a given flow can be
   compromised by any type of traffic in the network; this includes both
   malicious traffic as well as inadvertent traffic such as might be
   produced by a malfunctioning component, for example one made by a
   different manufacturer.

Can we really ensure that a malfunctioning component can't compromise the
resources of another one. The most simple example I would have is a router with
a malfunction rewriting the destination address or flow label of a packet
causing the packet to change the flow it is belonging too, thus if occurring
for any significant amount of packets causing overflow in the next hop router
when the original and the remarked flow compete for the same resources
assigned. The only way to ensure that this happens is to verify a strong header
integrity protection at each point a decision on how to forward, classify or
remark the flow is done. So Section 3.3 indicate that this is an issue, but
only discusses how it can be solved over ethernet. This issue hasn't been well
handled in either the MPLS or IP detnet data planes as no additional mechanism
was required to ensure this criteria is meet.

So I think the requirement that also malfunctions in equipment don't result in
flow violations is hard, and will require that the already approved data plane
specification needs additional mechanism that verify all data used on each
occasion the data is used. Neither MPLS nor IP as currently specified fulfill
this, not even against non-malicious malfunctions or corruption type
malfunctions. Then we have those malfunction that breaks the network or where
control plane information provided is being corrupted.

I have only looked a bit deeply on one type of malfunction that I know that can
occur. I convinced that this document will indicate a number of additional
potential ways things can go wrong that can't be determined without additional
mechanisms and likely additional per packet fields. Thus, I think we need to
discuss if the security properties matches the actual approved data plane, or
if the property is so important that the data plane specification is moved back
to the WG to be fixed?

I would also recommend that you don't indicate that a different manufacturer
can be blamed. Isn't a malfunction going to occur where they occur, it is not
like a single vendor network will be without malfunctions due to hardware
issue, nor have its set of software bugs.

Section 9.1:

   The IP protocol has a long history of security considerations and
   architectural protection mechanisms.  From a data plane perspective
   DetNet does not add or modify any IP header information, so the
   carriage of DetNet traffic over an IP data plane does not introduce
   any new security issues that were not there before, apart from those
   already described in the data-plane-independent threats section
   Section 5, Security Threats.

The above requirement from Section 3.1 in regards to IP header fields used for
flow classification are not automatically fulfilled without additional
mechanisms. Thus, I would claim that DETNET unless Section 3.1 requirement is
minimized will require support for a strong integrity mechanism over all
headers. So if this needs to be keyed or not is totally dependent on if
malicious modifications of packet headers needs to be taken into account or not.

Section 9.2:

Same as previous issue but for integrity over the MPLS headers.


8.1.6.  End-to-End Delivery
Packets sent over DetNet are not to be dropped by the network due to
   congestion.  (Packets may however intentionally be dropped for
   intended reasons, e.g. per security measures).
Maybe it need to be stated that packets for a flow that are within flow
parameters are not to be dropped due to congestion.

The security aspects include packets being dropped due to corruption malicious
or not.