Re: [Detnet] Secdir last call review of draft-ietf-detnet-mpls-over-udp-ip-06

Stewart Bryant <stewart.bryant@gmail.com> Fri, 02 October 2020 12:20 UTC

Return-Path: <stewart.bryant@gmail.com>
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 908343A0FAE; Fri, 2 Oct 2020 05:20:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Rgg5HpXWxhyE; Fri, 2 Oct 2020 05:20:55 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 155A13A0FAC; Fri, 2 Oct 2020 05:20:54 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id g4so1604484wrs.5; Fri, 02 Oct 2020 05:20:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W56w8sN3drbmvIfht40n68CpymbCPdunfFuIJjlDaxU=; b=QEjuFLnFqt7rsnc7CpOx7srmkz6+cI815xls/E9nRH7UkvOE5Gq9pC7Bto4IKiXVfb kKSpgWqlVDS4tBDdybHHjARX25YJ7jtgGwyxAAa5NxAqRYZ+FtU1JeD/ma1UloP68gHG keyv/TdJnBg2fXZMJj9GgYAs+FXtK/VahSu+yO1ArspDpaNIHrczP0X/kZ2PO7C1W8sd /xqzELlsIY0lU2VcC2j55hrnsgCsbJkhHi3CCdZqSoXidsLOdOPynhD6V71ImadC7KBP 8Eu7V43KuRO1QIOB2KCTJbsumbVg3N+ke6lPOqccnLrlhTb7Kz41w/HlHp0WkLgdmvKj qqOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W56w8sN3drbmvIfht40n68CpymbCPdunfFuIJjlDaxU=; b=L/WGpNTsGHGX8Ix+znsD9+SuUpGsylTQBCI/GbpocmDB5o87Y7PZcRSxUg4Sa86VN4 YYcVj/eB4OPiKwLVqYGPG2aesG9iMZQwb54B+9paacI/4NzT+h7S0GneinrDr0NcQEBC kpWV5A+wfJ0+YCOpyQ5dbE2tLVRhDlN3EJSXzbEAeCUMqYCNcTb+MiVr09hG3b8e5Sv7 MTywwmVTT0j5n6HS5+lY2h3xfZ9uHbp1SUsuiiUCgWdipffuJWpBhZNusRRgTYGThSMH iy4EOYdKcrl2ZlKMPIaaCBAjEu/BKjeOu5my0BQJ09B7Vb1uj+WbKrxHKZanfVHhS2pv xZjg==
X-Gm-Message-State: AOAM531LemYt92YL+Tdp2aSylAcbo73y2WsRH/bS7A6c7QHTBmfzCsAx D5FWLwYdgpQ55i67mkARkak=
X-Google-Smtp-Source: ABdhPJwXDxK6vtljym8JkU1wbBOutia0m3YiHMnbt1XuiW0sTuk/ZM3N89RI0IuTYFY0rakkWxhsbg==
X-Received: by 2002:a5d:5583:: with SMTP id i3mr2702953wrv.119.1601641253144; Fri, 02 Oct 2020 05:20:53 -0700 (PDT)
Received: from broadband.bt.com ([2a00:23c5:3395:c901:a8cd:8305:e9ef:e109]) by smtp.gmail.com with ESMTPSA id w7sm1569824wmc.43.2020.10.02.05.20.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Oct 2020 05:20:52 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Stewart Bryant <stewart.bryant@gmail.com>
In-Reply-To: <MN2PR19MB404579FE42A2EA751B56381783300@MN2PR19MB4045.namprd19.prod.outlook.com>
Date: Fri, 02 Oct 2020 13:20:51 +0100
Cc: Stewart Bryant <stewart.bryant@gmail.com>, "Grossman, Ethan A." <eagros@dolby.com>, "secdir@ietf.org" <secdir@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "detnet@ietf.org" <detnet@ietf.org>, "draft-ietf-detnet-mpls-over-udp-ip.all@ietf.org" <draft-ietf-detnet-mpls-over-udp-ip.all@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4587A7BB-F83B-4A2A-89CF-CE36F922E277@gmail.com>
References: <160097130665.26261.15986068503995393539@ietfa.amsl.com> <BY5PR06MB6611BE0705F79CB6C4FE8883C4390@BY5PR06MB6611.namprd06.prod.outlook.com> <3D90BF69-C0F5-4538-B029-D6D189463100@gmail.com> <MN2PR19MB404579FE42A2EA751B56381783300@MN2PR19MB4045.namprd19.prod.outlook.com>
To: "Black, David" <David.Black@dell.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/zycqNiE6mel6J8yI_gGNFZ36sNI>
Subject: Re: [Detnet] Secdir last call review of draft-ietf-detnet-mpls-over-udp-ip-06
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, 02 Oct 2020 12:20:58 -0000

David

The way that I look at it, TCP will deliver a given byte fed into its transmission stream in its own good time, delaying that byte until all previous bytes are delivered. It will also keep trying to deliver that byte as long as there is connectivity between source and sink. That is a contrast with DetNet which is looking for fast delivery with possibly some mitigation for packet loss. In such circumstances TCP is a liability to the service that wanted deterministic characteristics. I cannot therefore think of any good reason to pay the price of DetNet to deliver TCP. If you do want to use a transport protocol that is more sophisticated than UDP, then SCTP-PR is probably a better choice.

- Stewart



> On 1 Oct 2020, at 20:35, Black, David <David.Black@dell.com> wrote:
> 
> Playing devil's advocate for a moment ...
> 
>> I would be rather surprised if anyone tried to run a deterministic application over
>> TCP.
>> 
>> TCP would undo all the temporal determinism and or course it looks after packet
>> loss.
> 
> ... IF the DetNet service defines packet loss as a failure case, i.e., something that can't happen unless something in the network has actually failed and the preferred failure behavior is late delivery rather than non-delivery of impacted data, THEN TCP may be useful/appropriate.  OTOH, use of TCP increases the DetNet attack surface, as (in contrast to UDP), causing a drop or otherwise triggering retransmission becomes a way to attack the DetNet service by increasing the amount of traffic sent into limited reserved network capacity and also by delaying delivery of received data to the deterministic application.
> 
> I've lost track of the original context, so I'm not able to suggest specific text and where to add it or make changes.
> 
> Thanks, --David
> 
>> -----Original Message-----
>> From: detnet <detnet-bounces@ietf.org> On Behalf Of Stewart Bryant
>> Sent: Thursday, October 1, 2020 11:12 AM
>> To: Grossman, Ethan A.
>> Cc: secdir@ietf.org; last-call@ietf.org; Stewart Bryant; detnet@ietf.org; draft-
>> ietf-detnet-mpls-over-udp-ip.all@ietf.org; Stephen Farrell
>> Subject: Re: [Detnet] Secdir last call review of draft-ietf-detnet-mpls-over-udp-
>> ip-06
>> 
>> 
>> [EXTERNAL EMAIL]
>> 
>> 
>> 
>>> On 24 Sep 2020, at 21:28, Grossman, Ethan A. <eagros@dolby.com> wrote:
>>> 
>>> Thanks Stephen. FWIW it isn't too late to add some text to the DetNet Security
>> draft regarding DetNet over UDP, if someone can think up something useful to
>> say. I suppose one could simply mention UDP in the same breath as TCP (implying
>> that the same general security guidelines apply, if that's our stance).
>>> Any thoughts (from anyone)?
>> 
>> Ethan
>> 
>> I would be rather surprised if anyone tried to run a deterministic application over
>> TCP.
>> 
>> TCP would undo all the temporal determinism and or course it looks after packet
>> loss.
>> 
>> - Stewart
>> 
>> 
>> 
>> _______________________________________________
>> detnet mailing list
>> detnet@ietf.org
>> https://www.ietf.org/mailman/listinfo/detnet