From nobody Wed Feb 6 13:31:29 2019 Return-Path: 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 65586130EE0; Wed, 6 Feb 2019 13:31:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: detnet@ietf.org Message-ID: <154948868729.32751.2201776958890865308@ietfa.amsl.com> Date: Wed, 06 Feb 2019 13:31:27 -0800 Archived-At: Subject: [Detnet] I-D Action: draft-ietf-detnet-architecture-11.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 21:31:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Deterministic Networking WG of the IETF. Title : Deterministic Networking Architecture Authors : Norman Finn Pascal Thubert Balázs Varga János Farkas Filename : draft-ietf-detnet-architecture-11.txt Pages : 43 Date : 2019-02-06 Abstract: This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include: 1) reserving data plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow; 2) providing explicit routes for DetNet flows that do not immediately change with the network topology; and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over sub-network technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking (TSN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-architecture-11 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-architecture-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-architecture-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 6 14:06:59 2019 Return-Path: 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 E88F9130E62 for ; Wed, 6 Feb 2019 14:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.854 X-Spam-Level: X-Spam-Status: No, score=-8.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 0SXITumg8Jw8 for ; Wed, 6 Feb 2019 14:06:56 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B9112D4F3 for ; Wed, 6 Feb 2019 14:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1549490814; x=1552082814; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DV8eczyE/UcDRv1H/JebZJ0P6d+pYMRYxJ2xbsR/2NQ=; b=U5bF1ORutlPt2kgJQdZuemIN+XhKtdyCY6QiFW1+wt/KIotAfxax4lVgoVq333Ka 8v9mgvHIb2WsXcV/apQ8Q07KhpRB/AGqBW30uXw03KCrla7u6SUe8CUXN06i7xGV snckxcgBYpNZ/bV4pctQmOASu0Ji4J2CYqEQG9JD1xo=; X-AuditID: c1b4fb25-da1ff70000005ff7-a2-5c5b5a7e21ba Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 02.66.24567.E7A5B5C5; Wed, 6 Feb 2019 23:06:54 +0100 (CET) Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Feb 2019 23:06:53 +0100 Received: from [100.94.32.17] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.184) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Wed, 6 Feb 2019 23:06:53 +0100 References: <154948868757.32751.2439824342725787652.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?J=c3=a1nos_Farkas?= To: DetNet WG X-Forwarded-Message-Id: <154948868757.32751.2439824342725787652.idtracker@ietfa.amsl.com> Message-ID: Date: Wed, 6 Feb 2019 23:06:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <154948868757.32751.2439824342725787652.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyM2J7uW5dVHSMwffzIha/P81mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxv/riQVT2SrmfzJqYOxi7WLk5JAQMJG4+voXexcjF4eQwBFG ie5/j6Gcr4wSe3rvskA4hxgl5kz6ygzSIiygJbFh4zU2EFtIwFdi2fZlYDabgL3E3UsbwGpE BOQlGns/s0OsiJSYMr+LCcTmBar5sL0DrJ5FQEVi07m9YHFRgViJT1cWM0PUCEqcnPmEBcTm FPCT6NjbDlbPLGAhMXP+eUYIW15i+9s5zBC2uMStJ/OZIO5Rk/j09iH7BEahWUhGzULSPgtJ +ywk7QsYWVYxihanFiflphsZ66UWZSYXF+fn6eWllmxiBIbywS2/VXcwXn7jeIhRgINRiYdX zzU6Rog1say4MhcYOhzMSiK8b59FxQjxpiRWVqUW5ccXleakFh9ilOZgURLn/SMkGCMkkJ5Y kpqdmlqQWgSTZeLglGpg5JjP/3fn2u+x5yZKT56qnR6bH8ZuWKmfx6+359z2abZp3RJxqjl6 DD52rHOnWUsdWOaY0Wls2a8/+6j3pR08R/v4q9P3R/P2ivB+fyt/MeH6mbqvvEqKtdv/2k7/ bTF5lfJmpY/qno72a1gaLXcvnbAniXvlH9YX03YfN1+ikaO9ZEbDIm11JZbijERDLeai4kQA YBLVuGECAAA= Archived-At: Subject: [Detnet] draft-ietf-detnet-architecture-11 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 22:06:58 -0000 Hi, The DetNet architecture document has been updated to address the comments received on v10. The new revision (v11) is available at https://tools.ietf.org/html/draft-ietf-detnet-architecture-11. The changes are contributions from the authors and have been aligned with the shepherd. The authors had multiple cycle discussions to refine the the text contributed to the list. The purpose of the refinements were: - avoid the introduction of any new term - avoid or minimize the use of terms that have been recently removed from the document - improve clarity, e.g., remove "throttling" and replace it with clearer phrasing The changes compared to v10 are shown here: https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-architecture-11. Best regards, Janos From nobody Wed Feb 6 14:17:45 2019 Return-Path: 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 9B2EB130EE9 for ; Wed, 6 Feb 2019 14:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.854 X-Spam-Level: X-Spam-Status: No, score=-8.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 4-5R82qgC1w8 for ; Wed, 6 Feb 2019 14:17:41 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65C8C130E62 for ; Wed, 6 Feb 2019 14:17:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1549491459; x=1552083459; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0VlZ5DGZynmvw3k7BtIAixYjcXDPKTSiRO17N1Hd67A=; b=DOBNfwIlkzrE4XdrA3DGXn3ckPH2amQHHVR5f4gg2126DrFuS/f3IocugPJ/ovg1 eHcwtkevRVQeBvFPQgYbzx1aDdswq7G1Abk/nTcDt07lWAUXnk1FrNE8HjBYIboM qw+31RSSVCwxbiC87PdUfzRWGWt0Z/DWBEesBtib2uw=; X-AuditID: c1b4fb2d-db5ff7000000062f-5d-5c5b5d03454e Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 16.66.01583.30D5B5C5; Wed, 6 Feb 2019 23:17:39 +0100 (CET) Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Feb 2019 23:17:39 +0100 Received: from [100.94.32.17] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.193) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Wed, 6 Feb 2019 23:17:39 +0100 To: "Scharf, Michael" CC: "tsv-art@ietf.org" , "detnet@ietf.org" References: <153817345967.27205.135001179751151278@ietfa.amsl.com> <6EC6417807D9754DA64F3087E2E2E03E2D16A4D3@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2D16C02A@rznt8114.rznt.rzdir.fht-esslingen.de> <505e7a95-05bd-5dcb-628f-460790fc1b12@labn.net> <3DF0466E9510274382F5B74499ACD6F80171FFF5@lhrpml504-mbx.exmail.huawei.com> <6EC6417807D9754DA64F3087E2E2E03E2D17715F@rznt8114.rznt.rzdir.fht-esslingen.de> From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: Date: Wed, 6 Feb 2019 23:17:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D17715F@rznt8114.rznt.rzdir.fht-esslingen.de> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM2J7pS5zbHSMweH5Wha/P81msdi3uJnd YtaeRSwOzB5Nr/6xeixZ8pMpgCmKyyYlNSezLLVI3y6BK+Pj52NMBfecK6a/WsjawLjJvIuR g0NCwETiyav6LkYuDiGBI4wSH1YeYINwvjJKzF47Dco5xCix/NoVli5GTg5hgTiJxtntbCDd IgJmEssWGoGEmQX8JL5Oe8gIUT+bRaL3wwZ2kASbgL3E3UsbmEHqeYHsybsCQMIsAioSTyct YQOxRQViJT5dWcwMYvMKCEqcnPkEbBWnQIxE67wXTBDzLSRmzj/PCGHLS2x/O4cZwhaXuPVk PliNkICaxKe3D9knMArNQjJqFpL2WUjaZyFpX8DIsopRtDi1uDg33chYL7UoM7m4OD9PLy+1 ZBMjMNAPbvmtu4Nx9WvHQ4wCHIxKPLwK0dExQqyJZcWVucDA4WBWEuF9+ywqRog3JbGyKrUo P76oNCe1+BCjNAeLkjjvHyHBGCGB9MSS1OzU1ILUIpgsEwenVAOjz6F/e522XF6zeuvUy8Wf xXwcs6bP+NxVdXjDpzdWWUYn/z7Wy9bWSdrUuH/TzQemX0tY3T0+vZi1+tGZruNGRs3xRexz E/+LHO55LqtVs/XPjf/qrk7z/1rbv3jxoPyi0ckZJ055mapvZtgQu/BVfXPkhnWeE/aoZmxU Y1iuJzFB5fKuWsuDxkosxRmJhlrMRcWJAKBkOzhwAgAA Archived-At: Subject: Re: [Detnet] [Tsv-art] Tsvart last call review of draft-ietf-detnet-architecture-08 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 22:17:43 -0000 Hi Michael, Thank you very much again for your review! The draft had multiple updates since v08 you reviewed. The latest revision is v 11: https://mailarchive.ietf.org/arch/msg/detnet/SP63CCzi4C2Biy9mk0Qxrehoa_0 The updates address review comments, and comments and discussions on the DetNet WG list. Please let us know if you have further comments. Regards, Janos On 11/28/2018 8:02 AM, Scharf, Michael wrote: > Just to repeat: I won't mandate text on this specific issue. > > But there could be an implicit assumption that PREOF compute resources in the node fast path will _always_ be available. And it is entirely unclear to me if that would be a realistic assumption if the router fast path has to do complex coding on each packet, e.g. for "network coding" as explicitly mentioned in the architecture document. There could be tradeoffs on power, cost, etc. when doing such complex PREOF coding functions for every single packet. And it could be more complex than existing MPLS protection and restoration schemes. > > So, one could e.g. wonder if a DetNet network could run into the situation that a DetNet node as enough bandwidth and buffer, but not enough "network coding" coding/decoding capacity, or if a DetNet node would have to announce that it can do, say, 1+1 protection with PREOF, but there are not enough transcoder resources left for doing PREOF "network coding". Then there could be architectural implications, e.g., on protocols. > > Assuming that "implementers will do the right thing" would be reasonable if per-packet coding/decoding actions in PREOF are always cheap. Otherwise, one may have to consider transcoders as a potentially scarce resource that could also impact flow placement decisions - maybe somewhat similar to wavelength converters in optical networks. > > I don't know how to implement "network coding" in the fast path of a router that runs at Tbit/s. If running code has already shown that doing "network coding" at the line speed of today's routers is easily doable, this specific point may not be relevant. Clearly I am not an expert for router fast path designs. > > Michael > > >> -----Original Message----- >> From: Norman Finn [mailto:norman.finn@mail01.huawei.com] >> Sent: Tuesday, November 27, 2018 11:32 PM >> To: Lou Berger; Scharf, Michael >> Cc: tsv-art@ietf.org; detnet@ietf.org; draft-ietf-detnet- >> architecture.all@ietf.org >> Subject: RE: [Detnet] [Tsv-art] Tsvart last call review of draft-ietf- >> detnet-architecture-08 >> >> Typically, the resources for DetNet flows are reserved before the flow >> starts. In the case of PREOF, the functions are at least configured >> before being used. I would think that, if insufficient capability >> exists, the reservation/configuration would be refused. We're talking >> an awful lot of 9s here, to justify this feature, so doing otherwise >> would be a poor implementation choice. Do we need to say something >> about that, or figure that implementors will do the right thing? >> >> -- Norm >> >> ________________________________________ >> From: detnet [detnet-bounces@ietf.org] on behalf of Lou Berger >> [lberger@labn.net] >> Sent: Tuesday, November 20, 2018 10:07 AM >> To: Scharf, Michael >> Cc: tsv-art@ietf.org; detnet@ietf.org; draft-ietf-detnet- >> architecture.all@ietf.org >> Subject: Re: [Detnet] [Tsv-art] Tsvart last call review of draft-ietf- >> detnet-architecture-08 >> >> Michael, >> >> Thanks for the clarification. >> >> On 11/20/2018 10:02 AM, Scharf, Michael wrote: >>> Lou, >>> >>> Just regarding my comment that seems unclear... >>> >>> [snip] >>> >>>>> In addition, I'd like to emphasize that my review comment "It is >> surprising that there is hardly any discussion on network robustness >> and safety" >>>> I have no idea what you mean by safety here. Can you elaborate. >>> As far as I understand, DetNet introduces network functions that at >> least partly novel, such as PREOF. And as PREOF explicitly allows >> solutions beyond 1+1 protection ("network coding" is mentioned as >> example). >> >> at the network layer, protection and restoration is not new. There is >> LFAs. FRR, 1+1, 1:n, shared mesh etc all defined in RFCs - mostly, but >> not solely for MPLS. It's also not new transport protocol layer either >> as there is work (have to check if RFCs) on network coding and 1+1 -- >> but this is outside the scope of Detnet. >> >> >>> I believe that any new function typically raises operational issues. >>> >>> Out-of-my-head, here are some examples of potential challenges that >> seem not well addressed in -09: >>> - PREOF (and specifically) PEF as a single point of failure: Is there >> any need to worry about that? As far as I can see, the document >> discusses failures of paths between POF and PEF, but not failures of >> the functions themselves. Wouldn't it make sense to discuss basic >> requirements such as implementing these functions redundantly etc.? And >> if they are implemented redundantly, does this impact the architecture, >> e.g., result in additional interfaces that may need standardization? >> >> No more so than exists in the current RFCs related to the topic. >> >>> - Overload of DetNet components: As another example for PREOF, how >> would a DetNet deployment ensure that PEF never gets overloaded? >> >> Umm, how does an RFC ever dictate that a router/node/host isn't >> overloaded? In the normal internet case, I think this is way outside >> the scope of an RFC. For TE networks, this is what >> configuration/management/control is all about - and sure we can add a >> sentence on that. >> >> >>> Buffering and resequencing of packets requires processing. Techniques >> to allocate buffer space alone may not be enough to ensure that PEF >> never gets overloaded. Is this a problem or not? And even if this >> problem may perhaps not really exist for 1+1, is there no need to worry >> about other, possibly more complex PREOF schemes that may require >> complex packet processing (or even coding)? Are there scaling issues in >> PREOF? And could this impact signaling, e.g., require control plane >> protocol extensions? >> >> yes, there is configuration/management/control-- this can be mentioned. >> >> >>> More generally, if the intention of DetNet is to carry mission- >> critical or safety-critical traffic that cannot tolerate any packet >> loss, let alone any downtime, wouldn't words such as "reliability", >> "dependability", "redundancy", "high availability", etc. be relevant in >> a description of the architecture? (Some of these terms are actually >> used in this document, mostly in references to non-IETF work.) >> >> The IETF generally just defines the behavior on the wire in standards >> track RFCs and let others define requirement system performance levels. >> I don't think we should be changing this in DetNet. >> >> >>> And this may not only matter for the data plane. Assuming that a lot >> of DetNet traffic requires extremely high reliability, are there >> architectural requirements on components outside the data plane, e.g., >> regarding redundancy? Obviously, control plane and management plane >> functions are often built today already as high availability solutions, >> but if the intention is to _never_ fail, isn't there a risk that DetNet >> may require solutions "better-than-current-IP" outside the data plane >> as well? >> >> There are plenty of high availability (and different level of >> availability) implementations of systems out there. The only think the >> IETF gets involved with specifying are those aspects that impact >> interoperability between systems. (E.g., all the graceful restart >> related extensions in control plane protocols). Again, I don't think >> it's for DetNet to move beyond this. >> >> >>> This list of topics may not be comprehensive. I just want to >> illustrate some examples for what could also matter when running a >> network _really_ deterministically, beyond the well-known congestion >> issue. >>> However, just to be precise: I don't ask for additional text to >> address what is written in this e-mail. >> >> Thanks - it sounds like we're ending at the same place even if we >> didn't >> follow the same path to get here. >> >> Thanks again for comments/review. I do think we'll have a better >> document once the other points are addressed. >> >> Lou >> >>> Michael >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet From nobody Wed Feb 6 14:18:01 2019 Return-Path: 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 E1075130F52 for ; Wed, 6 Feb 2019 14:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.854 X-Spam-Level: X-Spam-Status: No, score=-8.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Mns_ldVK6Hkn for ; Wed, 6 Feb 2019 14:17:48 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60DEE130F67 for ; Wed, 6 Feb 2019 14:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1549491466; x=1552083466; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0CLOuOBeszV3Lxa4Yo9O7HLWmxgtrj84vUI9zZLtDfw=; b=RAlhiuchSCgTSZUk0rjgm6U8wh2paQS6H5fSsZQ1YjsvZ5Qb/5w/3zzlUPw1VZpH Wf0lXGX1Ouhw/VWtYgxq2U686YD0dTXGmn8da7m3umPQthqmBBLJ+vkGk+b5qj6n 1URPPUbskMyRU5d5fcGrfYdcxvf3NlrqNJa0UVsGhwY=; X-AuditID: c1b4fb30-fabff7000000355c-aa-5c5b5d0ae756 Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 5E.BE.13660.A0D5B5C5; Wed, 6 Feb 2019 23:17:46 +0100 (CET) Received: from ESESSMB504.ericsson.se (153.88.183.122) by ESESSMB504.ericsson.se (153.88.183.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Feb 2019 23:17:46 +0100 Received: from [100.94.32.17] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.192) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Wed, 6 Feb 2019 23:17:46 +0100 To: "Joel M. Halpern" CC: , DetNet WG References: <0cf9f2ac-f813-8f30-9889-4c1e5fc95b7b@ericsson.com> From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: Date: Wed, 6 Feb 2019 23:17:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM2J7lS5XbHSMwep+LYvfn2azWFx99ZnF 4uOpN0wOzB5Llvxk8jg35TtjAFMUl01Kak5mWWqRvl0CV8al9WwF28QrZvf9ZW9gfCXUxcjJ ISFgInHo4FqmLkYuDiGBI4wSp/+0MkI4Xxkl7v2ezw7hHGKUWH5lHRtIi7CAp8TbzZNYQWwR AW2J/Us+MIHYzALGEgtmfWKDaFjHKLFuTwszSIJNwF7i7qUNYDYvkP197z8wm0VAReLCmQ/s ILaoQKzEpyuLoWoEJU7OfMICYnMKOEv07m5ghlhgITFz/nlGCFteonnrbKi4uMStJ/PBjhAS UJP49PYh+wRGoVlIRs1C0j4LSfssJO0LGFlWMYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgQG +8Etvw12ML587niIUYCDUYmHtzsqOkaINbGsuDIXGDwczEoivG+fRcUI8aYkVlalFuXHF5Xm pBYfYpTmYFES5/0jJBgjJJCeWJKanZpakFoEk2Xi4JRqYIzQt5xxzSCPNdM3aL6GrsrE1G9r /v26uGHXD+utT5YvbT2f5WurwPNfpjeu0LVcxGlSQM5Ldq/XTdlTCo7b2Sy4rsl2wWbJkVOp mQfSi3o0X5ftkFGwV7ks2OlrkJH57xdLU5J3Qe/dzrbgSs/eQ4Ex26J1p4i6yJhd6rc61N89 Lc6jK+mgEktxRqKhFnNRcSIAMZFSYHICAAA= Archived-At: Subject: Re: [Detnet] Genart last call review of draft-ietf-detnet-architecture-08 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 22:17:55 -0000 Hi Joel, Thank you very much again for your review! The draft had multiple updates since v08 you reviewed. The latest revision is v 11: https://mailarchive.ietf.org/arch/msg/detnet/SP63CCzi4C2Biy9mk0Qxrehoa_0 The updates address review comments, and comments and discussions on the DetNet WG list. Please let us know if you have further comments. Regards, Janos On 10/19/2018 9:17 PM, Joel M. Halpern wrote: > Thank you Janos.  Two clarifications under retained text, with the > rest elided. > > Yours, > Joel > > On 10/19/18 3:10 PM, János Farkas wrote: > ... >> On 9/22/2018 2:59 AM, Joel Halpern wrote: > ... >>> Minor issues: >>>      Section 3.1 states that worst case delay for priority queueing is >>>      unbounded.  That does not match my understanding.  I know that >>> DelayBound >>>      DSCP behavior tightly (although, I think, not as tightly as >>> Detnet) limits >>>      both the worst case delay and the delay variation. >> Strict priority is not good enough for DetNet. A high priority packet >> may need to wait until the transmission of a lower priority packet is >> finished at an outbound port, which can cause too much uncertainties >> in the network. > > I understand that strict priority queueing is viewed as insufficient.  > I wasn;t arguing about that.  I was arguing with the use of the word > "unbounded".  As far as I can tell, with suitable priority queueing > the worst case delay is bounded, simply not well enough bounded. > > ... >>>      In section 4.1.2, I realized that the Detnet Transit node >>> terminology had >>>      mildly confused me.  The text says "DetNet enabled nodes are >>> interconnected >>>      via transit nodes (e.g., LSRs) which support DetNet, but are >>> not DetNet >>>      service aware."  Reading this, and the definitions in section >>> 2.1, it >>>      appears that a Detnet Transit node is a node that is providing >>> transport >>>      behavior that detnet needs, but is not actually modified for >>> detnet. >> Based on last call comments: >> https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html, >> the phrase "DetNet enabled nodes" is removed from the document and it >> has been made clear what type of DetNet node is meant: >> The text is updated to: >> >>     A "Deterministic Network" will be composed of DetNet enabled end >>     systems, DetNet edge nodes, DetNet relay nodes and collectively >>     deliver DetNet services.  DetNet relay and edge nodes are >>     interconnected via DetNet transit nodes (e.g., LSRs) which support >>     DetNet, but are not DetNet service aware. > > Any chance you could simply say "transit nodes" instead of "DetNet > transit nodes?  As far as I can tell, they are existing nodes that > were designed and implemented (and even configured) potentially before > DetNet was even defined? > > ... From nobody Wed Feb 6 14:18:21 2019 Return-Path: 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 2F294130F49 for ; Wed, 6 Feb 2019 14:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.853 X-Spam-Level: X-Spam-Status: No, score=-8.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 EwcIPgJjrfK9 for ; Wed, 6 Feb 2019 14:18:00 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2461130F67 for ; Wed, 6 Feb 2019 14:17:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1549491477; x=1552083477; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=v5zG2X5PCsVrVCH4jlOZtLjNotMiJi4uQYdXpRyRlJQ=; b=Lffukcvni07S/s4LWAM6WVavrIeJZpHkZISjq0OKNH3QWdoXcdDhDf+ku0FuXqQY Nn5G0eykFngo4EnRaeB3TNbTvQm5bCF+/JyrYJ0L5i+0mg9A/6R+q0fxV+N81Rdp 7JRepWY9QvSESTsKgUI0zuwcHshJdOFvCfOoGuQhhEc=; X-AuditID: c1b4fb3a-14fff7000000672c-47-5c5b5d159aa3 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id AE.96.26412.51D5B5C5; Wed, 6 Feb 2019 23:17:57 +0100 (CET) Received: from ESESBMR502.ericsson.se (153.88.183.134) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Feb 2019 23:17:56 +0100 Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESBMR502.ericsson.se (153.88.183.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Feb 2019 23:17:56 +0100 Received: from [100.94.32.17] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.191) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Wed, 6 Feb 2019 23:17:56 +0100 From: =?UTF-8?Q?J=c3=a1nos_Farkas?= To: Daniel Harkins CC: "iesg@ietf.org" , "secdir@ietf.org" , DetNet WG References: Message-ID: <50d31dc2-1f3f-21aa-2e2b-5432816e1425@ericsson.com> Date: Wed, 6 Feb 2019 23:17:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------77E3A8F48C7BE9F74D534660" Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbG9WFc0NjrG4EoXj8XvT7NZLJb++8Ji MePPRGaLDwsfsjiweCxZ8pPJ49nulywBTFFcNimpOZllqUX6dglcGZP6drAXLA+sOHPrDWMD 43m7LkZODgkBE4kXa5+xdzFycQgJHGGU6NwxB8r5yihx8N0mBOfW84UsEM4hRonP818ygfQL C9hLdN2YAGazAdl3L21gBrFFBDQkOrctZuti5OBgFkiXaGgoAwkLCZRKNK5Yygpi8wKVvzmx kA3EZhFQkViyr40FxBYViJX4dGUxM0SNoMTJmU9YQMZwCjhIfFlTABJmFgiTuLF5KiOELS5x 68l8JojxahLvG+4wTmAUmoWkexaSlllIWiBsC4mZ889DxeUlmrfOZoawNSRa58xlRxZfwMi+ ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMweg5u+W21g/Hgc8dDjAIcjEo8vHuio2OEWBPL iitzgWHGwawkwvv2WVSMEG9KYmVValF+fFFpTmrxIUZpDhYlcd4/QoIxQgLpiSWp2ampBalF MFkmDk6pBka781kv9sos751ynkFEL0zkmLvGDabzk+wPnngcUHFXfsZeXq5ve6tnezM1yARP Wvzs+MfywunXj4YeSH4ab/LyLts3jiRmXqlXPXNMj5Z+2HJu6UmhaYyVezKzj0uvczijeDS7 bknWn59/61Q/uj7OOfA4+uByjTuetzKfXlt0L9mk8+nepSc9lViKMxINtZiLihMB8XYOOJoC AAA= Archived-At: Subject: Re: [Detnet] secdir review of draft-ietf-detnet-architecture-08 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 22:18:07 -0000 --------------77E3A8F48C7BE9F74D534660 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Daniel, Thank you very much again for your review! The draft had multiple updates since v08 you reviewed. The latest revision is v 11: https://mailarchive.ietf.org/arch/msg/detnet/SP63CCzi4C2Biy9mk0Qxrehoa_0 The updates address review comments, and comments and discussions on the DetNet WG list. Please let us know if you have further comments. Regards, Janos On 10/17/2018 10:28 AM, János Farkas wrote: > Hi Daniel, > > Thank you very much for your review! > > Please find below how we plan to update the draft to address your > comments. > > Best regards, > Janos > > > On 9/25/2018 2:58 AM, Daniel Harkins wrote: >> >>   Hello, >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> The summary of the review is ready with issues. >> >> This draft describes an architecture for deterministic networking >> that provides for delivery of packet flows with low packet loss and >> with a maximum amount of latency. >> >> A nit first. The terminology seems a bit overblown. We have DetNet >> Intermediate nodes that could be relay nodes or transit nodes; and a >> DetNet system that is a DetNet aware system or transit node or >> relay node; and DetNet edge nodes that are relay nodes; and DetNet >> relay nodes that can be bridges, firewalls, or anything else that >> participates in DetNet. Finally, to translate between 802.1 TSN and >> DetNet we have a "relay system" that is an 802.1 term for a DetNet >> intermediate node which, as we have seen, is a DetNet relay node. This >> can be simplified considerably. > The definition of DetNet relay node will be updated. > "A DetNet relay node can be a bridge, a router, a firewall, or any > other system" will be delated. > > OLD: > A DetNet node including a service layer function that > interconnects different DetNet transport layer paths to > provide service protection. A DetNet relay node can be a > bridge, a router, a firewall, or any other system that > participates in the DetNet service layer. It typically > incorporates DetNet transport layer functions as well, in > which case it is collocated with a transit node. > > NEW: > A DetNet node including a service layer function that > interconnects different DetNet transport layer paths to > provide service protection. A DetNet relay node operates > at the service layer. It typically incorporates DetNet > transport layer functions as well, in which case it is > collocated with a DetNet transit node. > > > >> The Security Considerations is thin, especially for an architecture >> draft that is going to be referred to by subsequent drafts which will >> just say something along the lines of, "as an instance of the DetNet >> FooBar, these Security Considerations are those from [ARCH]", where >> ARCH is the RFC that comes out of this I-D. I think there needs to be >> a description of the various points in the architecture that an attacker >> could exploit, and if a point is not exploitable it should say so. For >> instance: >> >> - is it possible for an attacker to launch a DoS attack by manipulating >> member flows of a DetNet flow in order to force DetNet nodes to >> consume buffers they allocated to deal with the DetNet flow? >> >> - If an end system is not DetNet aware there needs to be a DetNet edge >> node to handle the encaps of the flow into the DetNet system. Can an >> attacker in that case introduce packets that shouldn't be part of the >> DetNet flow into the flow by getting the edge node to encaps them as >> such? >> >> If there are any assumptions being made-- e.g. "insider attacks are not >> being considered"-- they should be mentioned. >> >> regards, >> >> Dan. >> >> > Security issues and considerations are addressed by the DetNet > Security draft: > https://datatracker.ietf.org/doc/draft-ietf-detnet-security. > Reference will be added to the DetNet security document. --------------77E3A8F48C7BE9F74D534660 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Daniel,

Thank you very much again for your review!

The draft had multiple updates since v08 you reviewed. The latest revision is v 11: https://mailarchive.ietf.org/arch/msg/detnet/SP63CCzi4C2Biy9mk0Qxrehoa_0

The updates address review comments, and comments and discussions on the DetNet WG list.

Please let us know if you have further comments.

Regards,
Janos


On 10/17/2018 10:28 AM, János Farkas wrote:
Hi Daniel,

Thank you very much for your review!

Please find below how we plan to update the draft to address your comments.

Best regards,
Janos


On 9/25/2018 2:58 AM, Daniel Harkins wrote:
 
  Hello,
  I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

  The summary of the review is ready with issues.

  This draft describes an architecture for deterministic networking
that provides for delivery of packet flows with low packet loss and
with a maximum amount of latency. 

  A nit first. The terminology seems a bit overblown. We have DetNet
Intermediate nodes that could be relay nodes or transit nodes; and a
DetNet system that is a DetNet aware system or transit node or
relay node; and DetNet edge nodes that are relay nodes; and DetNet
relay nodes that can be bridges, firewalls, or anything else that
participates in DetNet. Finally, to translate between 802.1 TSN and
DetNet we have a "relay system" that is an 802.1 term for a DetNet
intermediate node which, as we have seen, is a DetNet relay node. This
can be simplified considerably.
The definition of DetNet relay node will be updated.
"A DetNet relay node can be a bridge, a router, a firewall, or any other system" will be delated.

OLD:
A DetNet node including a service layer function that
interconnects different DetNet transport layer paths to
provide service protection. A DetNet relay node can be a
bridge, a router, a firewall, or any other system that
participates in the DetNet service layer. It typically
incorporates DetNet transport layer functions as well, in
which case it is collocated with a transit node.

NEW:
A DetNet node including a service layer function that
interconnects different DetNet transport layer paths to
provide service protection. A DetNet relay node operates
at the service layer. It typically incorporates DetNet
transport layer functions as well, in which case it is
collocated with a DetNet transit node.



  The Security Considerations is thin, especially for an architecture
draft that is going to be referred to by subsequent drafts which will
just say something along the lines of, "as an instance of the DetNet
FooBar, these Security Considerations are those from [ARCH]", where
ARCH is the RFC that comes out of this I-D. I think there needs to be
a description of the various points in the architecture that an attacker
could exploit, and if a point is not exploitable it should say so. For
instance:

  - is it possible for an attacker to launch a DoS attack by manipulating
    member flows of a DetNet flow in order to force DetNet nodes to
    consume buffers they allocated to deal with the DetNet flow?

  - If an end system is not DetNet aware there needs to be a DetNet edge
    node to handle the encaps of the flow into the DetNet system. Can an
    attacker in that case introduce packets that shouldn't be part of the
    DetNet flow into the flow by getting the edge node to encaps them as
    such?

If there are any assumptions being made-- e.g. "insider attacks are not
being considered"-- they should be mentioned. 

  regards,

  Dan.

Security issues and considerations are addressed by the DetNet Security draft: https://datatracker.ietf.org/doc/draft-ietf-detnet-security.
Reference will be added to the DetNet security document.

--------------77E3A8F48C7BE9F74D534660-- From nobody Wed Feb 6 14:55:05 2019 Return-Path: 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 A2DA5130F41; Wed, 6 Feb 2019 14:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 DjjCBwCJWwBE; Wed, 6 Feb 2019 14:54:54 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C9A130F40; Wed, 6 Feb 2019 14:54:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 43vxbf2C6dz1W3Dp; Wed, 6 Feb 2019 14:54:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1549493694; bh=DnyeMgBMKwxiZh/pdrTrGvdhK9c90Jn+p5N0EYpOeIM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=UPK7k21qWfnuCPsNQAK3GNpnuNNlDm1x/GUQSpHj2nlgf3xqGeKRXxT3EdDhG33pk taPG7pOazgG1CCQM7gNWJcrcYTcdo1BAJh8Xxn2oRQDeE3RkGeXm5MZN/IewbjV0+B KZ5bd8I0QrX24Q6USZCk2AV7yVYqvV/kg883sdvc= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 43vxbd4v0yz1W3Dh; Wed, 6 Feb 2019 14:54:53 -0800 (PST) To: =?UTF-8?Q?J=c3=a1nos_Farkas?= Cc: gen-art@ietf.org, DetNet WG References: <0cf9f2ac-f813-8f30-9889-4c1e5fc95b7b@ericsson.com> From: "Joel M. Halpern" Message-ID: <4103c85b-98e3-2eef-27f6-e50efeaed120@joelhalpern.com> Date: Wed, 6 Feb 2019 17:54:52 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Detnet] Genart last call review of draft-ietf-detnet-architecture-08 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 22:55:03 -0000 Thanks Janos. I will take a look at it promptly. Yours, Joel On 2/6/19 5:17 PM, János Farkas wrote: > Hi Joel, > > Thank you very much again for your review! > > The draft had multiple updates since v08 you reviewed. The latest > revision is v 11: > https://mailarchive.ietf.org/arch/msg/detnet/SP63CCzi4C2Biy9mk0Qxrehoa_0 > > The updates address review comments, and comments and discussions on the > DetNet WG list. > > Please let us know if you have further comments. > > Regards, > Janos > > > On 10/19/2018 9:17 PM, Joel M. Halpern wrote: >> Thank you Janos.  Two clarifications under retained text, with the >> rest elided. >> >> Yours, >> Joel >> >> On 10/19/18 3:10 PM, János Farkas wrote: >> ... >>> On 9/22/2018 2:59 AM, Joel Halpern wrote: >> ... >>>> Minor issues: >>>>      Section 3.1 states that worst case delay for priority queueing is >>>>      unbounded.  That does not match my understanding.  I know that >>>> DelayBound >>>>      DSCP behavior tightly (although, I think, not as tightly as >>>> Detnet) limits >>>>      both the worst case delay and the delay variation. >>> Strict priority is not good enough for DetNet. A high priority packet >>> may need to wait until the transmission of a lower priority packet is >>> finished at an outbound port, which can cause too much uncertainties >>> in the network. >> >> I understand that strict priority queueing is viewed as insufficient. >> I wasn;t arguing about that.  I was arguing with the use of the word >> "unbounded".  As far as I can tell, with suitable priority queueing >> the worst case delay is bounded, simply not well enough bounded. >> >> ... >>>>      In section 4.1.2, I realized that the Detnet Transit node >>>> terminology had >>>>      mildly confused me.  The text says "DetNet enabled nodes are >>>> interconnected >>>>      via transit nodes (e.g., LSRs) which support DetNet, but are >>>> not DetNet >>>>      service aware."  Reading this, and the definitions in section >>>> 2.1, it >>>>      appears that a Detnet Transit node is a node that is providing >>>> transport >>>>      behavior that detnet needs, but is not actually modified for >>>> detnet. >>> Based on last call comments: >>> https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html, >>> the phrase "DetNet enabled nodes" is removed from the document and it >>> has been made clear what type of DetNet node is meant: >>> The text is updated to: >>> >>>     A "Deterministic Network" will be composed of DetNet enabled end >>>     systems, DetNet edge nodes, DetNet relay nodes and collectively >>>     deliver DetNet services.  DetNet relay and edge nodes are >>>     interconnected via DetNet transit nodes (e.g., LSRs) which support >>>     DetNet, but are not DetNet service aware. >> >> Any chance you could simply say "transit nodes" instead of "DetNet >> transit nodes?  As far as I can tell, they are existing nodes that >> were designed and implemented (and even configured) potentially before >> DetNet was even defined? >> >> ... > From nobody Thu Feb 7 06:19:50 2019 Return-Path: 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 CCE14126DBF; Thu, 7 Feb 2019 06:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 cwIdRRsKcIY3; Thu, 7 Feb 2019 06:19:29 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E7F123FFD; Thu, 7 Feb 2019 06:19:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 43wL6T4vsTzPpkF; Thu, 7 Feb 2019 06:19:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1549549169; bh=KKRM5Icz776zJ/g2qd5T9Ua/+vb2dXfxr3l0LoqyrSU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=GqLYyUrk1AiLhGWtgBSvtc2kCF38a2yw0hzTmJIFhf29BEtQ7+gaIsuNIlXoyk3Gb pRGKqp2m7SB+RHTkaawnfd8/yi8/wTh1Z8J6M324KCdzuNPnkWb1k5HDi2BPHc/5Lr 4S66tnBniNHMfXii70LrR/9/YlU2UHVwf3qVQECA= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 43wL6S6jtczPpkP; Thu, 7 Feb 2019 06:19:28 -0800 (PST) To: =?UTF-8?Q?J=c3=a1nos_Farkas?= Cc: gen-art@ietf.org, DetNet WG References: <0cf9f2ac-f813-8f30-9889-4c1e5fc95b7b@ericsson.com> From: "Joel M. Halpern" Message-ID: <8b0aa58a-0f64-6d34-f06c-5f3de34af026@joelhalpern.com> Date: Thu, 7 Feb 2019 09:19:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Detnet] Genart last call review of draft-ietf-detnet-architecture-08 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 14:19:32 -0000 Thank you Janos. I have looked at the changes. They address my concerns, and make a number of other useful and consistent changes that improve the document readability and clarity. Yours, Joel On 2/6/19 5:17 PM, János Farkas wrote: > Hi Joel, > > Thank you very much again for your review! > > The draft had multiple updates since v08 you reviewed. The latest > revision is v 11: > https://mailarchive.ietf.org/arch/msg/detnet/SP63CCzi4C2Biy9mk0Qxrehoa_0 > > The updates address review comments, and comments and discussions on the > DetNet WG list. > > Please let us know if you have further comments. > > Regards, > Janos > > > On 10/19/2018 9:17 PM, Joel M. Halpern wrote: >> Thank you Janos.  Two clarifications under retained text, with the >> rest elided. >> >> Yours, >> Joel >> >> On 10/19/18 3:10 PM, János Farkas wrote: >> ... >>> On 9/22/2018 2:59 AM, Joel Halpern wrote: >> ... >>>> Minor issues: >>>>      Section 3.1 states that worst case delay for priority queueing is >>>>      unbounded.  That does not match my understanding.  I know that >>>> DelayBound >>>>      DSCP behavior tightly (although, I think, not as tightly as >>>> Detnet) limits >>>>      both the worst case delay and the delay variation. >>> Strict priority is not good enough for DetNet. A high priority packet >>> may need to wait until the transmission of a lower priority packet is >>> finished at an outbound port, which can cause too much uncertainties >>> in the network. >> >> I understand that strict priority queueing is viewed as insufficient. >> I wasn;t arguing about that.  I was arguing with the use of the word >> "unbounded".  As far as I can tell, with suitable priority queueing >> the worst case delay is bounded, simply not well enough bounded. >> >> ... >>>>      In section 4.1.2, I realized that the Detnet Transit node >>>> terminology had >>>>      mildly confused me.  The text says "DetNet enabled nodes are >>>> interconnected >>>>      via transit nodes (e.g., LSRs) which support DetNet, but are >>>> not DetNet >>>>      service aware."  Reading this, and the definitions in section >>>> 2.1, it >>>>      appears that a Detnet Transit node is a node that is providing >>>> transport >>>>      behavior that detnet needs, but is not actually modified for >>>> detnet. >>> Based on last call comments: >>> https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html, >>> the phrase "DetNet enabled nodes" is removed from the document and it >>> has been made clear what type of DetNet node is meant: >>> The text is updated to: >>> >>>     A "Deterministic Network" will be composed of DetNet enabled end >>>     systems, DetNet edge nodes, DetNet relay nodes and collectively >>>     deliver DetNet services.  DetNet relay and edge nodes are >>>     interconnected via DetNet transit nodes (e.g., LSRs) which support >>>     DetNet, but are not DetNet service aware. >> >> Any chance you could simply say "transit nodes" instead of "DetNet >> transit nodes?  As far as I can tell, they are existing nodes that >> were designed and implemented (and even configured) potentially before >> DetNet was even defined? >> >> ... > From nobody Thu Feb 7 06:58:01 2019 Return-Path: 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 4F38C1200D7 for ; Thu, 7 Feb 2019 06:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 n9oVFSajCze8 for ; Thu, 7 Feb 2019 06:57:47 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D093F1228B7 for ; Thu, 7 Feb 2019 06:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1549551463; x=1552143463; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=d1URckH1HOGKPeE2YPUkYbbHUC3adfRZL6CizKK7M/o=; b=NxOoQ0B3jo0ylZAMiphd2FdUYilnVd2g2zAvk4nDsxPfDnHEWHvteTyBxJLaHGYg L2aWz012oXhjQxSQupfZ5GYIBVVTC9k/sS2JUKX5OV0vTc1RBR6cMbkVFJEpAg8t WcVzVHs7P43xIv92BqkuKSJjGrUqHZcEp3brQ57WTWc=; X-AuditID: c1b4fb25-da1ff70000005ff7-7f-5c5c4767e3f7 Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E2.15.24567.7674C5C5; Thu, 7 Feb 2019 15:57:43 +0100 (CET) Received: from ESESBMR504.ericsson.se (153.88.183.139) by ESESSMB504.ericsson.se (153.88.183.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 7 Feb 2019 15:57:43 +0100 Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESBMR504.ericsson.se (153.88.183.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 7 Feb 2019 15:57:43 +0100 Received: from [131.160.181.199] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.193) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Thu, 7 Feb 2019 15:57:42 +0100 To: "Joel M. Halpern" CC: , DetNet WG References: <0cf9f2ac-f813-8f30-9889-4c1e5fc95b7b@ericsson.com> <8b0aa58a-0f64-6d34-f06c-5f3de34af026@joelhalpern.com> From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: <6a4cf4fc-c3df-a7b3-c1a6-1dc30b44383e@ericsson.com> Date: Thu, 7 Feb 2019 15:57:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <8b0aa58a-0f64-6d34-f06c-5f3de34af026@joelhalpern.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM2J7lW66e0yMwfqFKha/P81msbj66jOL xcdTb5gcmD2WLPnJ5HFuynfGAKYoLpuU1JzMstQifbsErox3s/ewFRyXqdh69gdLA2OfeBcj J4eEgInEu30TmbsYuTiEBI4wSky4cZgVwvnKKNGxYx0TnPPxRTcLhHOUUeLdzjMsIP3CAiES t15dArNFBLQl9i/5wARiMwsYSyyY9YkNomEuk8TPE73sIAk2AXuJu5c2AC3k4OAFslffkQEJ swioSHTuuQ42R1QgVuLTlcXMIDavgKDEyZlPWEDKOQWcJd7OKIQYbyExc/55RghbXqJ562xm CFtc4taT+WAnCAmoSbxvuMM4gVF4FpJJs5C0z0LSPgtJ+wJGllWMosWpxUm56UbGeqlFmcnF xfl5enmpJZsYgVFwcMtv1R2Ml984HmIU4GBU4uH9bB4TI8SaWFZcmXuIUYKDWUmEt8oFKMSb klhZlVqUH19UmpNafIhRmoNFSZz3j5BgjJBAemJJanZqakFqEUyWiYNTqoExVfO+6B2VM7ma Cl5qU1tSgrsWTamIWG39fCKL0+F6t82ZZVODCu6tnXwgdmJR7sPATQp6/bIbpQLEXHfZH4h4 +eR/6Es+tePvRDylT6RVyjX8jNuws0OUpeLHh8lCtXt3LtrIIbk07llu11KPLh6zusULlSdc 3aNzb11mlFnIH+UPoaU7lrIqsRRnJBpqMRcVJwIA9JODk34CAAA= Archived-At: Subject: Re: [Detnet] Genart last call review of draft-ietf-detnet-architecture-08 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 14:57:49 -0000 Thank you Joel! Janos On 2/7/2019 3:19 PM, Joel M. Halpern wrote: > Thank you Janos.  I have looked at the changes.  They address my > concerns, and make a number of other useful and consistent changes > that improve the document readability and clarity. > > Yours, > Joel > > On 2/6/19 5:17 PM, János Farkas wrote: >> Hi Joel, >> >> Thank you very much again for your review! >> >> The draft had multiple updates since v08 you reviewed. The latest >> revision is v 11: >> https://mailarchive.ietf.org/arch/msg/detnet/SP63CCzi4C2Biy9mk0Qxrehoa_0 >> >> The updates address review comments, and comments and discussions on >> the DetNet WG list. >> >> Please let us know if you have further comments. >> >> Regards, >> Janos >> >> >> On 10/19/2018 9:17 PM, Joel M. Halpern wrote: >>> Thank you Janos.  Two clarifications under retained text, with the >>> rest elided. >>> >>> Yours, >>> Joel >>> >>> On 10/19/18 3:10 PM, János Farkas wrote: >>> ... >>>> On 9/22/2018 2:59 AM, Joel Halpern wrote: >>> ... >>>>> Minor issues: >>>>>      Section 3.1 states that worst case delay for priority >>>>> queueing is >>>>>      unbounded.  That does not match my understanding.  I know >>>>> that DelayBound >>>>>      DSCP behavior tightly (although, I think, not as tightly as >>>>> Detnet) limits >>>>>      both the worst case delay and the delay variation. >>>> Strict priority is not good enough for DetNet. A high priority >>>> packet may need to wait until the transmission of a lower priority >>>> packet is finished at an outbound port, which can cause too much >>>> uncertainties in the network. >>> >>> I understand that strict priority queueing is viewed as >>> insufficient. I wasn;t arguing about that.  I was arguing with the >>> use of the word "unbounded".  As far as I can tell, with suitable >>> priority queueing the worst case delay is bounded, simply not well >>> enough bounded. >>> >>> ... >>>>>      In section 4.1.2, I realized that the Detnet Transit node >>>>> terminology had >>>>>      mildly confused me.  The text says "DetNet enabled nodes are >>>>> interconnected >>>>>      via transit nodes (e.g., LSRs) which support DetNet, but are >>>>> not DetNet >>>>>      service aware."  Reading this, and the definitions in section >>>>> 2.1, it >>>>>      appears that a Detnet Transit node is a node that is >>>>> providing transport >>>>>      behavior that detnet needs, but is not actually modified for >>>>> detnet. >>>> Based on last call comments: >>>> https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html, >>>> the phrase "DetNet enabled nodes" is removed from the document and >>>> it has been made clear what type of DetNet node is meant: >>>> The text is updated to: >>>> >>>>     A "Deterministic Network" will be composed of DetNet enabled end >>>>     systems, DetNet edge nodes, DetNet relay nodes and collectively >>>>     deliver DetNet services.  DetNet relay and edge nodes are >>>>     interconnected via DetNet transit nodes (e.g., LSRs) which support >>>>     DetNet, but are not DetNet service aware. >>> >>> Any chance you could simply say "transit nodes" instead of "DetNet >>> transit nodes?  As far as I can tell, they are existing nodes that >>> were designed and implemented (and even configured) potentially >>> before DetNet was even defined? >>> >>> ... >> > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Thu Feb 7 12:08:29 2019 Return-Path: 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 0B1DF1293B1; Thu, 7 Feb 2019 12:08:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Michael Scharf To: Cc: draft-ietf-detnet-architecture.all@ietf.org, detnet@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154957010697.5316.5869067660230640460@ietfa.amsl.com> Date: Thu, 07 Feb 2019 12:08:27 -0800 Archived-At: Subject: [Detnet] Tsvart telechat review of draft-ietf-detnet-architecture-11 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 20:08:27 -0000 Reviewer: Michael Scharf Review result: Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. This is a follow-up to my TSV-ART review of version of -08 of this document. I have read again version -11. The content of version -11 is a huge improvement. I'd like to thank the authors, the document shepherd, and the tech advisor (David Black) for addressing my main concerns. Michael From nobody Thu Feb 7 12:45:03 2019 Return-Path: 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 20E95130E5A for ; Thu, 7 Feb 2019 12:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 XhCkUL7lWz15 for ; Thu, 7 Feb 2019 12:44:51 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F11B71276D0 for ; Thu, 7 Feb 2019 12:44:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1549572285; x=1552164285; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1YP1nR9oDwaG/+5EEMm5FRgYP6P/Tmeiyx9fXQzXBPc=; b=Q4U1K0edonHx4HsElP2f/JAHUQajv7AUga4053RMDjvpV6rn3LqUE85jjkOmGNft l3+uNhzCbiOpWtcIKaFwGSzL/Dxpj6M7HaEXvGD6hn/uriMmavrUlLaFz7fP6Vt2 OlQFMQgPVwF+RkTWjk5y5VKBb+8/Tjruv19DpV+Wr24=; X-AuditID: c1b4fb25-da1ff70000005ff7-17-5c5c98bd40d0 Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B5.E9.24567.DB89C5C5; Thu, 7 Feb 2019 21:44:45 +0100 (CET) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 7 Feb 2019 21:44:45 +0100 Received: from [100.94.32.237] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.185) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Thu, 7 Feb 2019 21:44:44 +0100 To: Michael Scharf CC: , , , References: <154957010697.5316.5869067660230640460@ietfa.amsl.com> From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: Date: Thu, 7 Feb 2019 21:44:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <154957010697.5316.5869067660230640460@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM2J7te7eGTExBldPq1n8/jSbxWLfrE0s Fs82zgeyFjezW8zas4jFgdWj6dU/Vo8lS34yBTBFcdmkpOZklqUW6dslcGVMPtHIXPCDvWLh ou+MDYzL2LoYOTgkBEwklv1m7mLk4hASOMIocf/LHRYI5yujxPavP1khnMOMEpuv7AZyODmE BTwkjkzZAWaLCBhLLF+7lAXEZhbIllh85A1YXEjASeL2kW/sIDabgL3E3UsbmEFsXiD7ybtH YPUsAioSC15MA6sXFYiV+HRlMVSNoMTJmU/AajgFnCWW/TnNDDHfQmLm/POMELa8xPa3c6Di 4hK3nsxngtirJvHp7UP2CYxCs5CMmoWkfRaS9llI2hcwsqxiFC1OLU7KTTcy1kstykwuLs7P 08tLLdnECAz/g1t+q+5gvPzG8RCjAAejEg9vwJSYGCHWxLLiytxDjBIczEoivIYgId6UxMqq 1KL8+KLSnNTiQ4zSHCxK4rx/hARjhATSE0tSs1NTC1KLYLJMHJxSDYx9sva8C8ysf2XM/Tb1 DFsze2ps8V7Dy8+bufILZ/js8gsJv3WxqDfnrSg/20am4HKn+02NrH82zdvcoiPGZm0XKtVp WtUVfej+pam+bXOjOCdFeC6vy975o6lLVkYg+NxHRpu3YlPbNhz/dPS1dP3THo+4eYUuYvV5 TdGf7W9+PZV+/Ya/lxJLcUaioRZzUXEiAK5AL7Z7AgAA Archived-At: Subject: Re: [Detnet] Tsvart telechat review of draft-ietf-detnet-architecture-11 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 20:44:55 -0000 Thank you Michael! Janos On 2/7/2019 9:08 PM, Michael Scharf wrote: > Reviewer: Michael Scharf > Review result: Ready > > This document has been reviewed as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the document's > authors and WG to allow them to address any issues raised and also to the IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this > review as part of the last-call comments they receive. Please always CC > tsv-art@ietf.org if you reply to or forward this review. > > This is a follow-up to my TSV-ART review of version of -08 of this document. I > have read again version -11. > > The content of version -11 is a huge improvement. I'd like to thank the > authors, the document shepherd, and the tech advisor (David Black) for > addressing my main concerns. > > Michael > From nobody Thu Feb 7 13:19:36 2019 Return-Path: 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 556D1129C6A; Thu, 7 Feb 2019 13:19:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: draft-ietf-detnet-architecture.all@ietf.org, detnet@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154957437026.5554.4163956192901377898@ietfa.amsl.com> Date: Thu, 07 Feb 2019 13:19:30 -0800 Archived-At: Subject: [Detnet] Genart telechat review of draft-ietf-detnet-architecture-11 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 21:19:30 -0000 Reviewer: Joel Halpern Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-detnet-architecture-11 Reviewer: Joel Halpern Review Date: 2019-02-07 IETF LC End Date: 2018-10-03 IESG Telechat date: 2019-02-21 Summary: This Internet Draft is ready for publication as a Proposed Standard Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A From nobody Fri Feb 8 09:03:27 2019 Return-Path: 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 CC2651288BD for ; Fri, 8 Feb 2019 09:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 Oh1mY9xkg3ik for ; Fri, 8 Feb 2019 09:03:22 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1E5212867A for ; Fri, 8 Feb 2019 09:03:22 -0800 (PST) Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id B6EE9142F0D for ; Fri, 8 Feb 2019 09:51:21 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id s9N3gcZKZszDUs9N3gwgxj; Fri, 08 Feb 2019 09:51:21 -0700 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ZrbqcGLpUwCU+NUkM8i0hHCMNHcB5KN4Z+bpykxPGP4=; b=bZDoswgyIzF9UFVfHBAV1d6Yxl GuskaC8BZxUhTwl6KD+GubOEP/7QPyohdkL4z3mJlByNgALPCI5ufDHH4o9j2ZE6J0bNwIWK0psWn y1QuBLNTU7MiRbfeS82TjeX98; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:40462 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gs9N3-0018pt-9u; Fri, 08 Feb 2019 09:51:21 -0700 To: =?UTF-8?Q?J=c3=a1nos_Farkas?= , DetNet WG References: <154948868757.32751.2439824342725787652.idtracker@ietfa.amsl.com> From: Lou Berger Message-ID: <072ed7a0-b3a1-154c-f7c7-b2e71402134a@labn.net> Date: Fri, 8 Feb 2019 11:51:15 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 72.66.11.201 X-Source-L: No X-Exim-ID: 1gs9N3-0018pt-9u X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:40462 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Detnet] draft-ietf-detnet-architecture-11 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 17:03:25 -0000 Authors (reviewers), Thank you for the editorial cleanup -- I think the result is definitely an improved document. WG, If you haven't looked at these changes, now would be a good time. Lou On 2/6/2019 5:06 PM, János Farkas wrote: > Hi, > > The DetNet architecture document has been updated to address the > comments received on v10. The new revision (v11) is available at > https://tools.ietf.org/html/draft-ietf-detnet-architecture-11. > > The changes are contributions from the authors and have been aligned > with the shepherd. The authors had multiple cycle discussions to refine > the the text contributed to the list. The purpose of the refinements were: > - avoid the introduction of any new term > - avoid or minimize the use of terms that have been recently removed > from the document > - improve clarity, e.g., remove "throttling" and replace it with clearer > phrasing > > The changes compared to v10 are shown here: > https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-architecture-11. > > Best regards, > Janos > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > From nobody Mon Feb 11 21:25:48 2019 Return-Path: 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 0B3AC12D4E9 for ; Mon, 11 Feb 2019 21:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.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 PFG0GVYr71ZD for ; Mon, 11 Feb 2019 21:25:43 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-eopbgr800097.outbound.protection.outlook.com [40.107.80.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90FD12D4E6 for ; Mon, 11 Feb 2019 21:25:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N7epTGeStWQPals6sYQQoAMUSawEx/iMixH0CRE2S0E=; b=dZw+/nc89I4hr1p2eII/JDCNGBXGIK2xaCzjERJ90cNEko94FFAF0R9+OdJ1ru0/wWa20Hj7Dg1jgN40Ltp3Z1xufOX1ngpFdiAMjarx04ZiF6GBgJBGYpCJCnZEl7w2X1o02KQzoOe55ZJXd3bezqHMdxzAazskmsn00gq9uZM= Received: from BYAPR06MB4325.namprd06.prod.outlook.com (52.135.240.140) by BYAPR06MB4856.namprd06.prod.outlook.com (20.177.127.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.22; Tue, 12 Feb 2019 05:25:40 +0000 Received: from BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::c443:7956:f734:2064]) by BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::c443:7956:f734:2064%5]) with mapi id 15.20.1601.023; Tue, 12 Feb 2019 05:25:40 +0000 From: "Grossman, Ethan A." To: "detnet@ietf.org" CC: "ekr@rtfm.com" Thread-Topic: DetNet Security Draft Proposed Text - Encryption Thread-Index: AdTCk1I+rewKQpliQKSaD45oyDyx+Q== Date: Tue, 12 Feb 2019 05:25:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXGVhZ3Jvc1xhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLWExNzQ4MTQ3LTJlODYtMTFlOS05M2ZjLWFjYmMzMjdhNTFjNlxhbWUtdGVzdFxhMTc0ODE0OC0yZTg2LTExZTktOTNmYy1hY2JjMzI3YTUxYzZib2R5Lmh0bWwiIHN6PSIxMDg1MCIgdD0iMTMxOTQ0MjI3MzkxMzMzMjg0IiBoPSJMbVZDdDJUNEdrbytNTSsydkFZbjk1RW1RaDg9IiBpZD0iIiBibD0iMCIgYm89IjEiLz48L21ldGE+ authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [8.39.141.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 19d729fd-4b46-4893-7e2d-08d690aa86fb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BYAPR06MB4856; x-ms-traffictypediagnostic: BYAPR06MB4856: x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; BYAPR06MB4856; 23:zf7NRPt3z/x/iy4KhEruXxgoLttY8hOUzQcxv2vIx?= =?us-ascii?Q?+uk6NotFF4FNi8rYbeGjqQL+MwPOXp9t59yjeUoXBDvMe8unl3W7plUyVd2O?= =?us-ascii?Q?yb1MyoLmO25ilf0QJTcz26zq1b4z2clA/ZY4d0wgUKv6BILhz+QwWH6eI3eo?= =?us-ascii?Q?4Q4w11K4GZQHVyc9X0D9UA6jZgKbz3IsSstVq27/JVtmY/cT95/iGsfNTUkD?= =?us-ascii?Q?co0X+bDmGNdK7tXGJgoVwFoF3vRwnSfjyK5uA9J1VSAG8dv6ZiqRf4FE7m1x?= =?us-ascii?Q?1LO3oUUupnVbrP9oT/G0lObJ4HWO/EP3vydHT941DnvTe7btEpcDx+nCaKLV?= =?us-ascii?Q?sukzk4N7xKbINNaING3e6ofezAIjrEgeEj/kXfFBIxkfzCe2WxvemQ3EuMxA?= =?us-ascii?Q?BRBoAR+ExxCngsLEb651N/Na3yzW48Ls6MqloHPyRruy/pwKCM4KKhcATrLJ?= =?us-ascii?Q?Na4qNNNsb60A9Y/ZBV+5zMwT7JNQxmhovsoJThnQkd0mkvRmTuo3Tj9EP6+b?= =?us-ascii?Q?992FYRdn/a+fmz/IerDNZSLQ94JM61yK3a/qmGg1la/JGrdtKxV03JhajxHa?= =?us-ascii?Q?eUG11IvqMFRasoFVmmqFalLQEBloTVYK2DQNu+otTGCKe6HaVWZabIX48Tw9?= =?us-ascii?Q?Ghlzwlzct1Y7MJ74n8Qkel8zTG1fEwYfhcD19qDYe+A5bzXIBdnxtjGWFlAt?= =?us-ascii?Q?ONVXYLtjXcHjt9Z+iOPqcpnJix1VlXFjBvGS+wcqdiMXPt7gKWmmcDt4SHFa?= =?us-ascii?Q?lgs6fq0GhZQuebSseVu2LBut4RQvROYecbAu/IyWAAwVgu3dbr+hZe/oD01h?= =?us-ascii?Q?xu+zwGi4Fkifcdw9eVrjtg+4tCXDk26sCGXZNJ+rtxd06BNZxaPUy/aujpkL?= =?us-ascii?Q?8Zc/ywfGDsWpENPQ7PkjdnjpGb7vkjYFlTdsV30IMWvDwWAKqOF52yrweSZH?= =?us-ascii?Q?hoYonhLSAnbKzZ+3q1ZTwHkgzFAfH0qouQd+3TD/sbs2QNYr1utuxJtTCsMx?= =?us-ascii?Q?8YzK+VFqA6Trw30+wGgY2fowd6G8mM7z3QKR8hNCXe/6ecCjLJFeEwRF6fAB?= =?us-ascii?Q?iYdOhdXxCcXaf+NzpSU5LWAsTr9XJgPXxVGBV0opw4Rd7x7uXt34xQwUKv4F?= =?us-ascii?Q?kXe0yuL8OeFwGYbVhY2aeqwgLZoBrLHSyo89JNNOkmDqgTELiOagyIB9I1jM?= =?us-ascii?Q?pq4XH1DuG9kv5d2ssWifr6Hq0KFbFuzNHsUJryoKkcN9RwPD+jhLr64aExrw?= =?us-ascii?Q?cV8Cyx4fhuS+gleqmNtxmtvVbZsIIm7TKARRw6QT4dC00yIP+miWVP3lLVCE?= =?us-ascii?Q?AWGZnKWyiTPwKi50e+sdVSOp9XHy9q+/pQ9InFpl6Yx?= x-microsoft-antispam-prvs: x-forefront-prvs: 0946DC87A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(396003)(376002)(346002)(136003)(53754006)(189003)(199004)(14454004)(9326002)(102836004)(1730700003)(81156014)(81166006)(476003)(486006)(4326008)(186003)(478600001)(66066001)(26005)(6506007)(55016002)(5640700003)(99286004)(8676002)(8936002)(2501003)(15650500001)(790700001)(6116002)(316002)(2420400007)(3846002)(105586002)(106356001)(7696005)(2351001)(6306002)(7110500001)(33656002)(54896002)(53936002)(97736004)(86362001)(68736007)(10710500007)(7736002)(71200400001)(71190400001)(6436002)(9686003)(14444005)(2906002)(256004)(6916009)(74316002)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR06MB4856; H:BYAPR06MB4325.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 36vm0E0yvOtTjZ5YQxx5Baa2fYOZ/G77mJ21AYxoeJVCGAqNcEX5ZUonFjlMBzJkECs715m+S1iUfQLXDmTG+vRcBu44kbHxHQNTnWzGLN9znZmkLxkz1+RK+KGxCb/7d2E0I+8fg/lm9VWpwMoy3u74uDmTBR1NSFosWsNEzel3EAVIj5L70cXnyhv/glfCfpzTFEWHL+282e/1VrnkomSPhvYbIb7nbkovaaWzYQXshEz7996VVivlslAB+YSEIHaQFRH7hacYBqaDL/xvFJaFUWFkc0ta2ilyR4asEx4n4W2TJ6GRXBgNF+Qk7pAjjvUBZeAUjLUd9CH+IswcIklKE+P1mzPZKgL1BNCqoDt9+/CUuK+2zRNocqoy/martOOKHZau/gWR1x8FDGsbVZo6r/qq1gwQK44lFuq0m5M= Content-Type: multipart/alternative; boundary="_000_BYAPR06MB4325F626B1FAFB7E4B81C827C4650BYAPR06MB4325namp_" MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 19d729fd-4b46-4893-7e2d-08d690aa86fb X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2019 05:25:40.1451 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB4856 Archived-At: Subject: [Detnet] DetNet Security Draft Proposed Text - Encryption X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 05:25:46 -0000 --_000_BYAPR06MB4325F626B1FAFB7E4B81C827C4650BYAPR06MB4325namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I have consolidated the list discussion about the pros and cons of encrypti= on algorithms into the Mitigation-Encryption section of the security draft = (text of the section as it now reads is below). I would like the WG to revi= ew it before I publish it in a new version of the Security draft. Thanks, Ethan (as editor of the DetNet Security draft) -------------------------------------------------------------------- 5. Security Threat Mitigation 5.4. Encryption Description DetNet flows can be forwarded in encrypted form. Related attacks Encryption can be used to mitigate recon attacks (Section 3.2.7). However, = for the DetNet to give differentiated quality of service on a flow-by-flow = basis, it must be able to identify the flows individually. This implies tha= t in a recon attack the attacker may also be able to track individual flows= to learn more about the system. Encryption can also provide traffic origin verification, i.e. to verify tha= t each packet in a DetNet flow is from a verified source, for example as pa= rt of ingress filtering. 5.4.1. Encryption Considerations for DetNet Any time spent on encryption and decryption processing ("crypto") must be i= ncluded in the flow latency calculations. Thus, crypto algorithms used in a= DetNet must have bounded execution times. Some crypto algorithms are symmetric in encode/decode time (such as AES and= SHA-2) and others are asymmetric (such as public key algorithms). There ar= e advantages and disadvantages to the use of either type in a given DetNet = context. Asymmetrical crypto is typically not used in networks on a packet-by-packet= basis due to its computational cost. For example, if only endpoint checks = or checks at a small number of intermediate points are required, one can us= e asymmetric crypto to authenticate distribution or exchange of a secret sy= mmetric crypto key; a successful check based on that key will provide traff= ic origin verification as long as the key is kept secret by the participant= s. Both TLS and IKE (for IPsec) are examples of this for endpoint checks. However, if we use secret symmetrical keys for this purpose we must give th= e key to all relays, which increases the probability of a secret key being = leaked. Also, if any relay is compromised or misbehaving it may inject traf= fic into the flow. Alternatively, asymmetric crypto can provide traffic origin verification at= every intermediate node. For example, a DetNet flow can be associated with= an (asymmetric) keypair, such that the private key is available to the sou= rce of the flow and the public key is distributed with the flow information= , allowing verification at every node for every packet. However, this is mo= re computationally expensive. In either case, origin verification also requires replay detection mechanis= m as part of the security protocol to prevent an attacker from recording an= d resending traffic, e.g., as a denial of service attack on flow forwarding= resources. --_000_BYAPR06MB4325F626B1FAFB7E4B81C827C4650BYAPR06MB4325namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

I have consolidated the list discussion about the pr= os and cons of encryption algorithms into the Mitigation-Encryption section= of the security draft (text of the section as it now reads is below). I wo= uld like the WG to review it before I publish it in a new version of the Security draft.

Thanks,

Ethan (as editor of the DetNet Security draft)<= /o:p>

----------------------------------------------------= ----------------

<= ![if !supportLists]>5.    Security Threat Mitigation

<= ![if !supportLists]>5.4.      &nb= sp;  Encryption

Description

        &nbs= p;      DetNet flows can be forwarded in encrypted= form.

Related attacks

Encryption can be used to mitigate recon attacks (Se= ction 3.2.7). However, for the DetNet to give differentiated quality of ser= vice on a flow-by-flow basis, it must be able to identify the flows individ= ually. This implies that in a recon attack the attacker may also be able to track individual flows to learn mo= re about the system.

Encryption can also provide traffic origin verificat= ion, i.e. to verify that each packet in a DetNet flow is from a verified so= urce, for example as part of ingress filtering.

<= ![if !supportLists]>5.4.1.     Encryption Considerations for DetNet

Any time spent on encryption and decryption processi= ng (“crypto”) must be included in the flow latency calculations= . Thus, crypto algorithms used in a DetNet must have bounded execution time= s.

Some crypto algorithms are symmetric in encode/decod= e time (such as AES and SHA-2) and others are asymmetric (such as public ke= y algorithms). There are advantages and disadvantages to the use of either = type in a given DetNet context.

Asymmetrical crypto is typically not used in network= s on a packet-by-packet basis due to its computational cost. For example, i= f only endpoint checks or checks at a small number of intermediate points a= re required, one can use asymmetric crypto to authenticate distribution or exchange of a secret symmetric cryp= to key; a successful check based on that key will provide traffic origin ve= rification as long as the key is kept secret by the participants.  Bot= h TLS and IKE (for IPsec) are examples of this for endpoint checks.

However, if we use secret symmetrical keys for this = purpose we must give the key to all relays, which increases the probability= of a secret key being leaked. Also, if any relay is compromised or misbeha= ving it may inject traffic into the flow.

Alternatively, asymmetric crypto can provide traffic= origin verification at every intermediate node. For example, a DetNet flow= can be associated with an (asymmetric) keypair, such that the private key = is available to the source of the flow and the public key is distributed with the flow information, allowing= verification at every node for every packet. However, this is more computa= tionally expensive.

In either case, origin verification also requires re= play detection mechanism as part of the security protocol to prevent an att= acker from recording and resending traffic, e.g., as a denial of service at= tack on flow forwarding resources.

 

--_000_BYAPR06MB4325F626B1FAFB7E4B81C827C4650BYAPR06MB4325namp_-- From nobody Mon Feb 11 23:26:35 2019 Return-Path: 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 29E7D12870E for ; Mon, 11 Feb 2019 23:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=CCn6ebVN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=So0oQHdG 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 XZW7skvq7dhy for ; Mon, 11 Feb 2019 23:26:31 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12056129A87 for ; Mon, 11 Feb 2019 23:26:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17858; q=dns/txt; s=iport; t=1549956391; x=1551165991; h=from:to:cc:subject:date:message-id:mime-version; bh=8FcdwaE9etZ7lKwHkUDMPxY7hQSqFrtHDk7VkzS7M4I=; b=CCn6ebVNMYFTnqSpAAQjHGu9M63POWBRGZVOgOHQXrRWVZ1YiSO88Pxv IrjzMzSm5q1jwuWARKplCsJCVdsxbxAaJ4ADud8+vQAoAcFZUhNo6MA8Z goGum+BFbeSDkiQYQlwjzM+/DSY+UUNzcKxEcnRkfW0IeAJMxQa5cslsk c=; IronPort-PHdr: =?us-ascii?q?9a23=3AZ/mnbxergR51YwyBC01Yc4UVlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/aiUhEcldXVtN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAADvc2Jc/49dJa1ZChoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVQCAQEBAQsBgQ0jUANndAQLJwqHQQOPd4JXmTcDVAsBASy?= =?us-ascii?q?EQINKIjcGDQEDAQECAQECbRwMhUoBBi0TAQE3AREBCBEDAQIoORQJCgQBDQU?= =?us-ascii?q?fgwaBHUwDFQGhKAKKFIIggngBAQWCRYI/GIILCIl7dhCBJR0XgUA/gw5nLoR?= =?us-ascii?q?WS4VAigGGHZInXAkCiyKHLBmSYIMkhAODDJFiAgQCBAUCDQEBBYFcIoFWcBU?= =?us-ascii?q?7gmyCHINuilNygSiLcAGBHgEB?= X-IronPort-AV: E=Sophos;i="5.58,361,1544486400"; d="scan'208,217";a="432096668" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2019 07:26:28 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x1C7QSaa030453 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Feb 2019 07:26:28 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 12 Feb 2019 01:26:28 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 12 Feb 2019 02:22:36 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 12 Feb 2019 02:22:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wnq049J0vkOEEa7CrTCaD9BFq7dz/5xXXUTcHOfS7Vw=; b=So0oQHdGmCOt1U9vj+OWWRZ+GD4cFdA6JH0f1o6S2chwX2EnY7MqY95imzUerkyVFvRUY2wWVtwpDvCIeKzVOxWtGOMkP4SkyE6XAJYxboaPu+j6NIuws3jK29LCscnbrC/jLQIY/KDAwVwlGMzvz8WH9AqCkysdHutFewauU5M= Received: from CY4PR11MB1479.namprd11.prod.outlook.com (10.172.66.137) by CY4PR11MB2008.namprd11.prod.outlook.com (10.169.252.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Tue, 12 Feb 2019 07:22:35 +0000 Received: from CY4PR11MB1479.namprd11.prod.outlook.com ([fe80::582b:d678:23c3:ad22]) by CY4PR11MB1479.namprd11.prod.outlook.com ([fe80::582b:d678:23c3:ad22%4]) with mapi id 15.20.1622.016; Tue, 12 Feb 2019 07:22:34 +0000 From: "Maik Seewald (maseewal)" To: "Grossman, Ethan A." , "detnet@ietf.org" CC: "ekr@rtfm.com" Thread-Topic: [Detnet] DetNet Security Draft Proposed Text - Encryption Thread-Index: AQHUwqO59xE6aoAp/UuUS5dNynm9eg== Date: Tue, 12 Feb 2019 07:22:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.6.150930 authentication-results: spf=none (sender IP is ) smtp.mailfrom=maseewal@cisco.com; x-originating-ip: [173.38.220.40] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 550c01b6-d546-4dba-44d9-08d690badc0c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:CY4PR11MB2008; x-ms-traffictypediagnostic: CY4PR11MB2008: x-microsoft-exchange-diagnostics: =?Windows-1252?Q?1; CY4PR11MB2008; 23:bT+8ZNZG53fH/nPmAc3c1W1DpvGbEcG3UKRfZ?= =?Windows-1252?Q?6QzJICyEhDYlg1m9bz7GvKVOpqVv+jJgRLfhzABZxtyFfWi7khUGshFX?= =?Windows-1252?Q?KuqXVA94lCGllplTl79MG71xqvqDaiNonL14JKvEpPOd9Ix1qoQrMSDE?= =?Windows-1252?Q?h1MJcB88sppHOMDa0PQJMSK6OqMplGtPgLjxsXuPMYfZDOpwIdjfi5lT?= =?Windows-1252?Q?UwedCSFg0jtKZfjt7m2Ls7+skl65/VHwXJMGeHe86PmcgUG3CgrwVEJ+?= =?Windows-1252?Q?58l3rHN6OSC1ngCXF0gh3Kf52Ite2wgypX8rByHkvqnc486ed/JTF0OP?= =?Windows-1252?Q?FRpAMoN0XTMMkM4DeUFF3wQE06xZPqujDvinrJx1ek+rsMd5b4I0kiqn?= =?Windows-1252?Q?YfvtYV8ohHutJ5gOq0q0D8vj1NC2/LnSH70aTLT5qJ/iabk8rP/Sab8s?= =?Windows-1252?Q?fQU9EYUfr0/+VLsPSQQOaijILQkJFWcMz1jaa23+FhAVNQT3ZesgQkBU?= =?Windows-1252?Q?tmUFwXkzDvKCSjru5jx3h2oxNN09lp4kP+MfhoftKIq1VjlY1iAEmhwF?= =?Windows-1252?Q?pvRWCImLV83nttte0RyA1dw8ZfIXz+HEFtimttcV/2nahoboYgr5gr/T?= =?Windows-1252?Q?bqHDGE0k5TA58DjWBw2Yuh4xQtMg5sSNkIiZ+b41+Q55kGla9YvLl8yP?= =?Windows-1252?Q?OAb/h3LTc+IGgbHRGFVGmPK5ZAdiZhernwAEWgK4J1dPJvIL3U/61oE5?= =?Windows-1252?Q?hzXtY2iv2B+KXxSxaN8qyqBTctRmiXed00Gihqdm6RC5MTwwKotblzhQ?= =?Windows-1252?Q?w3zqDijOhgPSqRx5U+EilYOGl3lwvGrvE+W0DOYijg+yB6q11v8t46A6?= =?Windows-1252?Q?ZUTPKZG7MTM3hb+RxW8z9pBuAjKelLvchWlOBc/iWjm71w31Bp+m0gA8?= =?Windows-1252?Q?+SP/cDw067kD5zdnc8s3jMT5UgZqhlhAKyj8/8OthjgVGMN3h/GaW+HK?= =?Windows-1252?Q?ajl6StwRAWZgBS8j14qVFU7agmTtisBI9mn7nQqvqkDz80UtquJZPpZ2?= =?Windows-1252?Q?yXe+UkEL88X32FgBQnqQaAh1NI1rsS6R1VTMHPrcLb9XqQ/o6OHIPajr?= =?Windows-1252?Q?yEC9FzYcHY/gHRhefQob6lzIU+5Fjkrm/rVwBy82w6TFjwL2SCgxeuXj?= =?Windows-1252?Q?+20OT3kOID9BeeGrVUpwhK69mdC7DU871dQ54ehjDKXlvLvF035P0yUo?= =?Windows-1252?Q?9+Ox8QWIQ/cdiBJD9t6mBauakvkciT+DhmhSpI3nyotxVJFwosHRw9Bd?= =?Windows-1252?Q?vbP7/rmXuwxZlZ/ZauIQyAhRSLRiOyRdr6SYaCYfyMzR6VnKYZRtamPr?= =?Windows-1252?Q?KQ9Fhz/moh9MoISJY5DsoJ7HqIATEpI+BrKknzmvwa4+sJHSESyiqtBP?= =?Windows-1252?Q?rIy5v/InPpFZCi+sKU0?= x-microsoft-antispam-prvs: x-forefront-prvs: 0946DC87A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(136003)(376002)(396003)(39860400002)(53754006)(199004)(189003)(256004)(10710500007)(105586002)(2501003)(229853002)(790700001)(7110500001)(3846002)(6116002)(36756003)(66066001)(6246003)(236005)(58126008)(53936002)(6306002)(54896002)(6512007)(110136005)(106356001)(71190400001)(71200400001)(478600001)(14444005)(316002)(86362001)(7736002)(26005)(53546011)(102836004)(6506007)(68736007)(6436002)(2906002)(14454004)(25786009)(6486002)(97736004)(4326008)(476003)(2420400007)(486006)(99286004)(2616005)(8676002)(15650500001)(81156014)(186003)(81166006)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB2008; H:CY4PR11MB1479.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: rpPmxnjc/XRpZb0Gg0tXv0k0pAr+EnsVSHzb9wBLz2rPdQ8GOovlipIu4EFTyXD+WkJCjSd8nalfpnxHL9AmU2OuS7ljXNtYgYYEdw2OXd+1NciRql2e3SU4YWYYO8XopjE9QjKX+7tHeXamnEAZgU8FMC7s6vnR5wqO8XsCVHD9CbTDPRrd+5d3bCzvgsoCdHC6Lwugi5gssQI+Ox+TQ6QKau+jjpM8tAtrXJq8e5ePQqsUKQuAr6LUG3wXH2wyXpB8EOvRhPX/oK3sL7MxlLvIjQT2LlJ+hA1aloy4CxDCDEEYC+zf6+6kanfYLT1EEFDs+gUPINzvnI67dHEG4lhGB7VsY/RjO95agIFuH8e8kCr5fD2zYZ/jxxcn3cnVxvLQ61/caOCMJGa3CUTi1MIfoa1Ohub3Ed9D/XcRBSg= Content-Type: multipart/alternative; boundary="_000_D8882F5079D0Dmaseewalciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 550c01b6-d546-4dba-44d9-08d690badc0c X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2019 07:22:34.9021 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB2008 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.25, xch-aln-015.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encryption X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 07:26:34 -0000 --_000_D8882F5079D0Dmaseewalciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Ethan, Only a few comments: Execution times are essential for flow calculations. On the other hand, to define bounded execution times is challenging. And, does it make sense to use the boundary (value) for calculations? Since this is a new standard, we should recommend agility of crypto algorit= hms in order to address quantum-safe crypto. This especially impacts asymmetric algoritms. Of course, there are implications with symmetric crypto, especially in term= s of key management. But I assume, this won=92t be part of the text=85 Cheers, Maik From: detnet > on b= ehalf of "Grossman, Ethan A." > Date: Tuesday, 12. February 2019 at 06:25 To: "detnet@ietf.org" > Cc: Eric Rescorla > Subject: [Detnet] DetNet Security Draft Proposed Text - Encryption Hi All, I have consolidated the list discussion about the pros and cons of encrypti= on algorithms into the Mitigation-Encryption section of the security draft = (text of the section as it now reads is below). I would like the WG to revi= ew it before I publish it in a new version of the Security draft. Thanks, Ethan (as editor of the DetNet Security draft) -------------------------------------------------------------------- 5. Security Threat Mitigation 5.4. Encryption Description DetNet flows can be forwarded in encrypted form. Related attacks Encryption can be used to mitigate recon attacks (Section 3.2.7). However, = for the DetNet to give differentiated quality of service on a flow-by-flow = basis, it must be able to identify the flows individually. This implies tha= t in a recon attack the attacker may also be able to track individual flows= to learn more about the system. Encryption can also provide traffic origin verification, i.e. to verify tha= t each packet in a DetNet flow is from a verified source, for example as pa= rt of ingress filtering. 5.4.1. Encryption Considerations for DetNet Any time spent on encryption and decryption processing (=93crypto=94) must = be included in the flow latency calculations.. Thus, crypto algorithms used= in a DetNet must have bounded execution times. Some crypto algorithms are symmetric in encode/decode time (such as AES and= SHA-2) and others are asymmetric (such as public key algorithms). There ar= e advantages and disadvantages to the use of either type in a given DetNet = context. Asymmetrical crypto is typically not used in networks on a packet-by-packet= basis due to its computational cost. For example, if only endpoint checks = or checks at a small number of intermediate points are required, one can us= e asymmetric crypto to authenticate distribution or exchange of a secret sy= mmetric crypto key; a successful check based on that key will provide traff= ic origin verification as long as the key is kept secret by the participant= s. Both TLS and IKE (for IPsec) are examples of this for endpoint checks. However, if we use secret symmetrical keys for this purpose we must give th= e key to all relays, which increases the probability of a secret key being = leaked. Also, if any relay is compromised or misbehaving it may inject traf= fic into the flow. Alternatively, asymmetric crypto can provide traffic origin verification at= every intermediate node. For example, a DetNet flow can be associated with= an (asymmetric) keypair, such that the private key is available to the sou= rce of the flow and the public key is distributed with the flow information= , allowing verification at every node for every packet. However, this is mo= re computationally expensive. In either case, origin verification also requires replay detection mechanis= m as part of the security protocol to prevent an attacker from recording an= d resending traffic, e.g., as a denial of service attack on flow forwarding= resources. --_000_D8882F5079D0Dmaseewalciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hello Ethan,

Only a few comments: 

Execution times are essential for flow calculations. 
On the other hand, to define bounded execution times is challenging.
And, does it make sense to use the boundary (value) for calculations?<= /div>

Since this is a new standard, we should recommend agility of crypto al= gorithms in order to address quantum-safe crypto.
This especially impacts asymmetric algoritms.

Of course, there are implications with symmetric crypto, especially in= terms of key management.
But I assume, this won=92t be part of the text=85

Cheers,
Maik

From: detnet <detnet-bounces@ietf.org> on behalf of "= ;Grossman, Ethan A." <eagros@do= lby.com>
Date: Tuesday, 12. February 2019 at= 06:25
To: "detnet@ietf.org" <= detnet@ietf.org>
Cc: Eric Rescorla <ekr@rtfm.com>
Subject: [Detnet] DetNet Security D= raft Proposed Text - Encryption

Hi All,

I have consolidated the list discussion about the pr= os and cons of encryption algorithms into the Mitigation-Encryption section= of the security draft (text of the section as it now reads is below). I wo= uld like the WG to review it before I publish it in a new version of the Security draft.

Thanks,

Ethan (as editor of the DetNet Security draft)<= /o:p>

----------------------------------------------------= ----------------

<= !--[if !supportLists]-->5.    Security Threat Mitigation

<= !--[if !supportLists]-->5.4.      = ;   Encryption

Description

        &nbs= p;      DetNet flows can be forwarded in encrypted= form.

Related attacks

Encryption can be used to mitigate recon attacks (Se= ction 3.2.7). However, for the DetNet to give differentiated quality of ser= vice on a flow-by-flow basis, it must be able to identify the flows individ= ually. This implies that in a recon attack the attacker may also be able to track individual flows to learn mo= re about the system.

Encryption can also provide traffic origin verificat= ion, i.e. to verify that each packet in a DetNet flow is from a verified so= urce, for example as part of ingress filtering.

<= !--[if !supportLists]-->5.4.1.     Encryption Considerations for DetNet=

Any time spent on encryption and decryption processi= ng (=93crypto=94) must be included in the flow latency calculations.. Thus,= crypto algorithms used in a DetNet must have bounded execution times.

Some crypto algorithms are symmetric in encode/decod= e time (such as AES and SHA-2) and others are asymmetric (such as public ke= y algorithms). There are advantages and disadvantages to the use of either = type in a given DetNet context.

Asymmetrical crypto is typically not used in network= s on a packet-by-packet basis due to its computational cost. For example, i= f only endpoint checks or checks at a small number of intermediate points a= re required, one can use asymmetric crypto to authenticate distribution or exchange of a secret symmetric cryp= to key; a successful check based on that key will provide traffic origin ve= rification as long as the key is kept secret by the participants.  Bot= h TLS and IKE (for IPsec) are examples of this for endpoint checks.

However, if we use secret symmetrical keys for this = purpose we must give the key to all relays, which increases the probability= of a secret key being leaked. Also, if any relay is compromised or misbeha= ving it may inject traffic into the flow.

Alternatively, asymmetric crypto can provide traffic= origin verification at every intermediate node. For example, a DetNet flow= can be associated with an (asymmetric) keypair, such that the private key = is available to the source of the flow and the public key is distributed with the flow information, allowing= verification at every node for every packet. However, this is more computa= tionally expensive.

In either case, origin verification also requires re= play detection mechanism as part of the security protocol to prevent an att= acker from recording and resending traffic, e.g., as a denial of service at= tack on flow forwarding resources.

 

 --_000_D8882F5079D0Dmaseewalciscocom_-- From nobody Tue Feb 12 11:10:50 2019 Return-Path: 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 0C34012D4F0 for ; Tue, 12 Feb 2019 11:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.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 SbcWDjv6OhRl for ; Tue, 12 Feb 2019 11:10:45 -0800 (PST) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710099.outbound.protection.outlook.com [40.107.71.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9234128B36 for ; Tue, 12 Feb 2019 11:10:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=INvmckDhJJPtz+ooquNO70CCLzFQG4rs/7qupcEJDc4=; b=AsNs8GMnbCcALsBYQZXmCKgwFmLQjf5+MNZM7jumN0zTbj0iQK+A8sZMA00OREV2Dyw+BaJtWek5hcapDipuUTrfdxSBQomheyH9IPmRo4HesQ4wSzHFAsFgDg+SNV8hIbcDhDLpiEJTK7jLi/o8v3jTRAZm8tVdTQWzZb1n1rI= Received: from BYAPR06MB4325.namprd06.prod.outlook.com (52.135.240.140) by BYAPR06MB4024.namprd06.prod.outlook.com (52.135.192.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.22; Tue, 12 Feb 2019 19:10:43 +0000 Received: from BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::c443:7956:f734:2064]) by BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::c443:7956:f734:2064%5]) with mapi id 15.20.1601.023; Tue, 12 Feb 2019 19:10:42 +0000 From: "Grossman, Ethan A." To: "Maik Seewald (maseewal)" , "detnet@ietf.org" CC: "ekr@rtfm.com" Thread-Topic: [Detnet] DetNet Security Draft Proposed Text - Encryption Thread-Index: AQHUwqO59xE6aoAp/UuUS5dNynm9eqXcho4w Date: Tue, 12 Feb 2019 19:10:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXGVhZ3Jvc1xhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLWUyZTJiNDRhLTJlZjktMTFlOS05M2ZjLWFjYmMzMjdhNTFjNlxhbWUtdGVzdFxlMmUyYjQ0Yy0yZWY5LTExZTktOTNmYy1hY2JjMzI3YTUxYzZib2R5Lmh0bWwiIHN6PSIxNjYyOSIgdD0iMTMxOTQ0NzIyNDA5OTc4MzA4IiBoPSI5YmFraDVvcFdnZ0Z3dnYxSTlpektSeU9tQ1E9IiBpZD0iIiBibD0iMCIgYm89IjEiLz48L21ldGE+ authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [8.39.141.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7120f819-4778-4e10-f686-08d6911dc8e3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BYAPR06MB4024; x-ms-traffictypediagnostic: BYAPR06MB4024: x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; BYAPR06MB4024; 23:uJ8zTCjYNtoSHU/sSVuNZ7eFgRg+LRg1wiKo+gh2m?= =?us-ascii?Q?DFRkyau0pn33VCZSkSeg9L2vJxGsNdY6jH+e6IYwik7EWxRUbUJw3f41QMNA?= =?us-ascii?Q?cjiFLOA2bJvtzeRoJdZcdcwghGzRSGEwgXE87ymbAqq1TDMYdS5UHeok8c/5?= =?us-ascii?Q?vM1e4HBq9iiOHcLZruum2wqKZnYYZ+tcJZbYbe5DVR/0pAolH53vu9gfeK3y?= =?us-ascii?Q?HYVpclGp78RBsVgCtSevotI2fbLVBFCddsA/Hsqir0PaLRD5SVkwcu+24OKO?= =?us-ascii?Q?THI6CjJxDR5AUSzay6DoNECVpURbf+n/ZneAAigdGhTvW7J+oBtufIL3g9M4?= =?us-ascii?Q?FTnXc1yU1AVe5IRrrsbAYacuoTyOV1pobwl84yURcB66TMBrkHjZDfFatPHq?= =?us-ascii?Q?ts8nwaGY+wtzUt1CyptM74T3WsFJmDkJMRDE2Rjf0KkhAelpwBISn0pyHXp5?= =?us-ascii?Q?VS6mKyvMkE0BNWTqqxU3cxUra5JxKzITnaSxtx+8y7vkWHrbmmadndXRbrIW?= =?us-ascii?Q?Nk2rPQFcPj5SLW60RSZ4K5FbuMu0Cxjy85PXqeFAcFCdocNvT6CkxkxWGz2a?= =?us-ascii?Q?/wrvUBmaw8VX/WPFguMCFCAyFDU+brn6nK6FWUEWeWq1SLridPAC11mWWt29?= =?us-ascii?Q?LG9dUQlM2fY738cEJrO7ZHrnnZH3KlGK/cbljm1RCsevHX0paCit9f/19N1i?= =?us-ascii?Q?yWQBhDyDDnr2/I03gR8P0vpQvVt2wTir5XnzJwIjo1wUykKe2nzituE0XpwZ?= =?us-ascii?Q?Z9yTraxdD5wB3hqjLuKnRAbCM6LHYg2LYt32JTLZuoyBUn6E3l2UY3IpXNIp?= =?us-ascii?Q?eij0vPXq1L6QM7l/MtcBvK9JlOZvx6mqeYBHj8Y6DZaNXuTiw9f9qZwzOY70?= =?us-ascii?Q?aBFMkeXi98a7LZT9Su94naieRKixFOQbdr5SskcYEAjptWlU6QlbLOFvClSh?= =?us-ascii?Q?2MlnF9deXMDSPfbO6EzscKF6xny9ujoQ2GHn2VmEly04KvUtC3dSzvl7cgll?= =?us-ascii?Q?ROI4lQUE6i1TKxJv5GvfamUbappPzImSzOLbGcKjm1ybgnx6q2gJ1oqArpnx?= =?us-ascii?Q?zZbesahZCcwRIoWnPizAOi2mDm/62JCc0EPAfrF98Gl4yTV3wK5TfQhQ+8SA?= =?us-ascii?Q?PdgZ8Dydf2ADossOT2RNBx9s+a95IjYQO1WAbuGWwLol+KHzs6ewOC6vMKRB?= =?us-ascii?Q?Xj4jb83pWKhnNv0DYDbFZDN7Kbw1YK6V5gjQxcAyo+uRowJMsmGxdnkDz2Ww?= =?us-ascii?Q?dKPezvI790LeCn2AU+eE99TKyrBQ1QtUb79g4M6c0xgrgOBnMv+EpUD+Z8C0?= =?us-ascii?Q?k/UnTkL3vkWK8Wa/PIR4rbmhE5kD/LBDp+DnkspbReY3AGhRtvGh3XuvgdeK?= =?us-ascii?Q?adGvcHxhv7usp2rkyVSsynB3s1ZbkeMlCh+Jy+1onrnp3P/CYuq5cJOjJ9HY?= =?us-ascii?Q?hyND5WQ0Q=3D=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0946DC87A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(366004)(39860400002)(376002)(346002)(51914003)(199004)(189003)(53754006)(4326008)(6436002)(99286004)(97736004)(76176011)(2501003)(55016002)(66066001)(9686003)(316002)(229853002)(86362001)(7110500001)(6246003)(236005)(7696005)(9326002)(81156014)(81166006)(53546011)(33656002)(6506007)(8936002)(26005)(10710500007)(790700001)(25786009)(102836004)(106356001)(6116002)(11346002)(476003)(186003)(14454004)(8676002)(486006)(71200400001)(71190400001)(74316002)(54896002)(53936002)(110136005)(6306002)(256004)(14444005)(105586002)(2906002)(478600001)(68736007)(446003)(3846002)(2420400007)(7736002)(15650500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR06MB4024; H:BYAPR06MB4325.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: EnjQk2bBg1vu9XZ8AVQsH+DN+nQcRY4ngG9fvytf0VYiWglqDzUYhlMezUUceM+2Iy8HuGRFsVcmjIT0nYUc/KKOwf5x8Yb4ATVKsC2HrNJmV0AT3PmeqIqnoHXWyZPYcnC5MvU0HYJvYr7l8dG8oZSvObGBmHUOgSV8Z7RxH/M/D+Xy40e+1C7Leq7f1/CmAYsVHhC5gEGeVGWi2yeu2hk2LrzXgDSlfp7sewuQrc+6cgqBdT8P8n+3pOUYUh4V4YGDJXhkghLFq0pz7u4npHR+1NjwBkAPWyUGLwfdXEkGxMvyIKTRtecMhj/6HEJbWvK0lj7Oiay4xV9YWUYPZ6m/pLnWcq2XtF+jYjnUXOWhYpqjE9HFpSl7zXmynPAv8Krby6azGuwWsk70sYgsKuqSpdEcfTX/KzmtWDuRUu8= Content-Type: multipart/alternative; boundary="_000_BYAPR06MB4325A1C7CD3E1ED725FAD94FC4650BYAPR06MB4325namp_" MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7120f819-4778-4e10-f686-08d6911dc8e3 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2019 19:10:42.8544 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB4024 Archived-At: Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encryption X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 19:10:49 -0000 --_000_BYAPR06MB4325A1C7CD3E1ED725FAD94FC4650BYAPR06MB4325namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Maik, Thanks for these comments. Regarding "to define bounded execution times is challenging. And, does it m= ake sense to use the boundary (value) for calculations?" - if I understand = your question correctly, then yes, it does make sense, because end-to-end l= atency must be bounded so for any packet processing the worst case time mus= t be used. Regarding "we should recommend agility of crypto algorithms in order to add= ress quantum-safe crypto" - I don't understand exactly the implication of t= his - can you suggest some changes to my text to incorporate this concept? Thanks, Ethan. From: Maik Seewald (maseewal) Sent: Monday, February 11, 2019 11:23 PM To: Grossman, Ethan A. ; detnet@ietf.org Cc: ekr@rtfm.com Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encryption Hello Ethan, Only a few comments: Execution times are essential for flow calculations. On the other hand, to define bounded execution times is challenging. And, does it make sense to use the boundary (value) for calculations? Since this is a new standard, we should recommend agility of crypto algorit= hms in order to address quantum-safe crypto. This especially impacts asymmetric algoritms. Of course, there are implications with symmetric crypto, especially in term= s of key management. But I assume, this won't be part of the text... Cheers, Maik From: detnet > on b= ehalf of "Grossman, Ethan A." > Date: Tuesday, 12. February 2019 at 06:25 To: "detnet@ietf.org" > Cc: Eric Rescorla > Subject: [Detnet] DetNet Security Draft Proposed Text - Encryption Hi All, I have consolidated the list discussion about the pros and cons of encrypti= on algorithms into the Mitigation-Encryption section of the security draft = (text of the section as it now reads is below). I would like the WG to revi= ew it before I publish it in a new version of the Security draft. Thanks, Ethan (as editor of the DetNet Security draft) -------------------------------------------------------------------- 5. Security Threat Mitigation 5.4. Encryption Description DetNet flows can be forwarded in encrypted form. Related attacks Encryption can be used to mitigate recon attacks (Section 3.2.7). However, = for the DetNet to give differentiated quality of service on a flow-by-flow = basis, it must be able to identify the flows individually. This implies tha= t in a recon attack the attacker may also be able to track individual flows= to learn more about the system. Encryption can also provide traffic origin verification, i.e. to verify tha= t each packet in a DetNet flow is from a verified source, for example as pa= rt of ingress filtering. 5.4.1. Encryption Considerations for DetNet Any time spent on encryption and decryption processing ("crypto") must be i= ncluded in the flow latency calculations.. Thus, crypto algorithms used in = a DetNet must have bounded execution times. Some crypto algorithms are symmetric in encode/decode time (such as AES and= SHA-2) and others are asymmetric (such as public key algorithms). There ar= e advantages and disadvantages to the use of either type in a given DetNet = context. Asymmetrical crypto is typically not used in networks on a packet-by-packet= basis due to its computational cost. For example, if only endpoint checks = or checks at a small number of intermediate points are required, one can us= e asymmetric crypto to authenticate distribution or exchange of a secret sy= mmetric crypto key; a successful check based on that key will provide traff= ic origin verification as long as the key is kept secret by the participant= s. Both TLS and IKE (for IPsec) are examples of this for endpoint checks. However, if we use secret symmetrical keys for this purpose we must give th= e key to all relays, which increases the probability of a secret key being = leaked. Also, if any relay is compromised or misbehaving it may inject traf= fic into the flow. Alternatively, asymmetric crypto can provide traffic origin verification at= every intermediate node. For example, a DetNet flow can be associated with= an (asymmetric) keypair, such that the private key is available to the sou= rce of the flow and the public key is distributed with the flow information= , allowing verification at every node for every packet. However, this is mo= re computationally expensive. In either case, origin verification also requires replay detection mechanis= m as part of the security protocol to prevent an attacker from recording an= d resending traffic, e.g., as a denial of service attack on flow forwarding= resources. --_000_BYAPR06MB4325A1C7CD3E1ED725FAD94FC4650BYAPR06MB4325namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Maik,

Thanks for these comments.

Regarding “to define bounded execution times is challenging= . And, does it make sense to use the boundary (value) for calculations?R= 21; – if I understand your question correctly, then yes, it does make sense, because end-to-end latency must be bounded so for= any packet processing the worst case time must be used.

Regarding “we should recommend agility of crypto algorithms= in order to address quantum-safe crypto” – I don’t under= stand exactly the implication of this – can you suggest some changes to my text to incorporate this concept?

Thanks,

Ethan.

From: Maik Seewald (maseewal) <maseewal@cisco.com>
Sent: Monday, February 11, 2019 11:23 PM
To: Grossman, Ethan A. <eagros@dolby.com>; detnet@ietf.org
Cc: ekr@rtfm.com
Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encrypti= on

 

Hello Ethan,

 

Only a few comments: 

 

Execution times are essential for flow calculations. 

On the other hand, to define bounded execution times is challengi= ng.

And, does it make sense to use the boundary (value) for calculati= ons?

 

Since this is a new standard, we should recommend agility of cryp= to algorithms in order to address quantum-safe crypto.

This especially impacts asymmetric algoritms.

 

Of course, there are implications with symmetric crypto, especial= ly in terms of key management.

But I assume, this won’t be part of the text…

 

Cheers,

Maik

 

From: detnet <detnet-bounces@ietf.org> on behalf of "Grossman, Ethan A.&qu= ot; <eagros@dolby.com>
Date: Tuesday, 12. February 2019 at 06:25
To: "detnet@ietf.org&quo= t; <detnet@ietf.org>
Cc: Eric Rescorla <ekr@rtfm.com>
Subject: [Detnet] DetNet Security Draft Proposed Text - Encryption

 

Hi All,

I have consolidated the = list discussion about the pros and cons of encryption algorithms into the M= itigation-Encryption section of the security draft (text of the section as = it now reads is below). I would like the WG to review it before I publish it in a new version of the Security d= raft.

Thanks,

Ethan (as editor of the = DetNet Security draft)

------------------------= --------------------------------------------

<= ![if !supportLists]>5.    Security Threat Mitigation

<= ![if !supportLists]>5.4.      &nb= sp;  Encryption

Description

    =            DetNet flows c= an be forwarded in encrypted form.

Related attacks

Encryption can be used t= o mitigate recon attacks (Section 3.2.7). However, for the DetNet to give d= ifferentiated quality of service on a flow-by-flow basis, it must be able t= o identify the flows individually. This implies that in a recon attack the attacker may also be able to track indi= vidual flows to learn more about the system.

Encryption can also prov= ide traffic origin verification, i.e. to verify that each packet in a DetNe= t flow is from a verified source, for example as part of ingress filtering.=

<= ![if !supportLists]>5.4.1.     Encryption Considerations for DetNet

Any time spent on encryp= tion and decryption processing (“crypto”) must be included in t= he flow latency calculations.. Thus, crypto algorithms used in a DetNet mus= t have bounded execution times.

Some crypto algorithms a= re symmetric in encode/decode time (such as AES and SHA-2) and others are a= symmetric (such as public key algorithms). There are advantages and disadva= ntages to the use of either type in a given DetNet context.

Asymmetrical crypto is t= ypically not used in networks on a packet-by-packet basis due to its comput= ational cost. For example, if only endpoint checks or checks at a small num= ber of intermediate points are required, one can use asymmetric crypto to authenticate distribution or exchange of = a secret symmetric crypto key; a successful check based on that key will pr= ovide traffic origin verification as long as the key is kept secret by the = participants.  Both TLS and IKE (for IPsec) are examples of this for endpoint checks.

However, if we use secre= t symmetrical keys for this purpose we must give the key to all relays, whi= ch increases the probability of a secret key being leaked. Also, if any rel= ay is compromised or misbehaving it may inject traffic into the flow.

Alternatively, asymmetri= c crypto can provide traffic origin verification at every intermediate node= . For example, a DetNet flow can be associated with an (asymmetric) keypair= , such that the private key is available to the source of the flow and the public key is distributed with the flow = information, allowing verification at every node for every packet. However,= this is more computationally expensive.

In either case, origin v= erification also requires replay detection mechanism as part of the securit= y protocol to prevent an attacker from recording and resending traffic, e.g= ., as a denial of service attack on flow forwarding resources.

 =

--_000_BYAPR06MB4325A1C7CD3E1ED725FAD94FC4650BYAPR06MB4325namp_-- From nobody Tue Feb 12 11:19:22 2019 Return-Path: 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 429B412E7C1 for ; Tue, 12 Feb 2019 11:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.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 PGx_Y0nMJXU4 for ; Tue, 12 Feb 2019 11:19:18 -0800 (PST) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710102.outbound.protection.outlook.com [40.107.71.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1125A128B36 for ; Tue, 12 Feb 2019 11:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ND1D2kuZxapIB18K59lzN9mMcFuccKLdkWbi5WGjdFY=; b=VMZMPZBSEy4OAKPsPR69uDcUPO5ivqeCa9grindggnzNgBUM1pHCFC6nQFEp2Vgl6Rug53ihcH4iGPv0jNMvEQKtxWQuQEJBQIOBNQWOU+iGuIh1owH2lxY6mT7t8j2xTTDbTnOCdfoD0VHKxahddDWzkfnlWBvwg1Oo+H6kHG4= Received: from BYAPR06MB4325.namprd06.prod.outlook.com (52.135.240.140) by BYAPR06MB5928.namprd06.prod.outlook.com (20.179.157.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.21; Tue, 12 Feb 2019 19:19:13 +0000 Received: from BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::c443:7956:f734:2064]) by BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::c443:7956:f734:2064%5]) with mapi id 15.20.1601.023; Tue, 12 Feb 2019 19:19:13 +0000 From: "Grossman, Ethan A." To: "Maik Seewald (maseewal)" , "detnet@ietf.org" CC: "ekr@rtfm.com" Thread-Topic: [Detnet] DetNet Security Draft Proposed Text - Encryption Thread-Index: AQHUwqO59xE6aoAp/UuUS5dNynm9eqXciKZg Date: Tue, 12 Feb 2019 19:19:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXGVhZ3Jvc1xhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLTEzMTQzNzYwLTJlZmItMTFlOS05M2ZjLWFjYmMzMjdhNTFjNlxhbWUtdGVzdFwxMzE0Mzc2Mi0yZWZiLTExZTktOTNmYy1hY2JjMzI3YTUxYzZib2R5Lmh0bWwiIHN6PSIyMDQwOCIgdD0iMTMxOTQ0NzI3NTEzNTIxNzc2IiBoPSI2dko0aUdsWE4wY1dvNlYvU01VS1k4U0NWb3c9IiBpZD0iIiBibD0iMCIgYm89IjEiLz48L21ldGE+ authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [8.39.141.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7e32cf6f-f8e1-4e1a-207b-08d6911ef973 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BYAPR06MB5928; x-ms-traffictypediagnostic: BYAPR06MB5928: x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; BYAPR06MB5928; 23:YVERoYeOXHzC53atRofMMv3cMn2ijhATTZxrWGmQC?= =?us-ascii?Q?KPsA6xt9TXD6bduqqgoxBFbOPBbkLG9gyj83M1HVZFOG1utpkiDFWbxZFKLW?= =?us-ascii?Q?U7WJ/O9ohRXulqodC7hvtKgs2Yziq5oKE77bhzevjY0beFr20jQ1YveHSoR7?= =?us-ascii?Q?A1TwfokUievgrkVakyrJ00fWmovTxkksDoTW36xPIrnaSRjBGH3Ycv3zYPzk?= =?us-ascii?Q?atNAlWQdbgZIN9wIa9djUjapulg27GXN49B0tbz9+xWTP0dy3GM/92t/biSH?= =?us-ascii?Q?J4UUtKbUUCInDvf6HI9+5s6fri4NT+kS2Ej9nlMZz8I4LegUf9aqMB5VlJCc?= =?us-ascii?Q?cB4+AR5rqG2CE1/tNk2YDRomedZG6IuinXu4Hin/J77Ho7crjmvQjKB4ULK3?= =?us-ascii?Q?RL6p5oi5frIJoAXnBcO3rgNjIGtn9ndA5Ayi3+r3zy6vXW2qws2DI6kT5adU?= =?us-ascii?Q?5UKggDu3mZpPx3fc9AcMAdFCsq9v2DG5A671Aj6OnbC3KUo3LtH0kqHFRKsD?= =?us-ascii?Q?fbS9pHvYuof/XQIulEWleK8N4MRZrLN0ZgIUNnnhp2SV/WUTv3IBdfl3l+ek?= =?us-ascii?Q?ctZOaMnn67PG7XU0UJxy+0c3s+WaA8SiWZ3O1wlJUQzcCgSI0bAXRU2Wju8Z?= =?us-ascii?Q?XsouLEDdhlKsUgw94F1OLNZAQgL9nVBsdYHWMXUNWiySJlCtlQlLrWPJxJ/6?= =?us-ascii?Q?9PMVHqhmmLCwMGjBa9XsYM0uJNffnH8WKNNeVFsngIg2JNLF9Z0+sB22MlMN?= =?us-ascii?Q?9ZF+SC6CBdQ0LMWdkO3IXFt1ie1SFGZPaF1tRbUNBaO+Q+g/fFbBPDBN8qcF?= =?us-ascii?Q?2qJsXCv3Q/ERtfCXjQYbL5beYOPAegUEYoQmYyyBP5oqiAhOkxIN5t2Gsr1p?= =?us-ascii?Q?qvukQp7KZfIjfjvI/YdM03ZkJKrJtZ4qa4cYb5S3Qw3z61kZNMp+YpgAv6cc?= =?us-ascii?Q?juaI+gOk8Xo9Q66S+UwEuo7O0HL1lVL17vvlDUC7utkyviFTeZHnSrkG4m4e?= =?us-ascii?Q?VL4wYd4Oy27IaMHhZQaQ+3io6F+6kHOktbs8krOm8uzBY1178VFvBx9eJhkL?= =?us-ascii?Q?1MNC8nIe/yEZ+6IQB3zN1Rmy2pdWyE4+zd0wcvSUF2NVa13ghec9XR89nYCD?= =?us-ascii?Q?CRQWj3LuQPsmmFx79UxCBRRU6bDLgomdD3csy91/hbmQ7TvgA+zEVHblTcEw?= =?us-ascii?Q?Obfxp6y2PtkR1I5SRrXSFfB7KQvqoxmHkQcSzQASol/QGYNkBpl2rYECHQUe?= =?us-ascii?Q?CS5oSV8aMEbg7XCFKFLiFgoqdcnowmC8Ks3IlZQO4BKBilka7etHx0lzlXXj?= =?us-ascii?Q?kJCxl3sbl6vo6zaa/SnYPOB2e+91Perto5XwykfQKYU+iQkkgYVywBOauaF3?= =?us-ascii?Q?CV7mXO3qgGccvZjNpZgblvcoddbHK+m6cw67B5iNpBnNClM?= x-microsoft-antispam-prvs: x-forefront-prvs: 0946DC87A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(346002)(396003)(39850400004)(376002)(53754006)(199004)(189003)(66066001)(186003)(486006)(7696005)(478600001)(102836004)(76176011)(11346002)(26005)(446003)(14454004)(476003)(71190400001)(71200400001)(33656002)(4326008)(15650500001)(6506007)(53546011)(25786009)(6246003)(256004)(236005)(81156014)(105586002)(106356001)(3846002)(6116002)(229853002)(14444005)(10710500007)(2420400007)(7736002)(68736007)(7110500001)(74316002)(790700001)(81166006)(8936002)(6306002)(110136005)(86362001)(316002)(99286004)(55016002)(9686003)(54896002)(6436002)(2906002)(53936002)(97736004)(2501003)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR06MB5928; H:BYAPR06MB4325.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 3i6squEeyqCqTtZoCSlv71oNNHx2g2RWdE12yHMDvlTHBMCsN2ggA16oG6DDYDD0Y6aQj4q+IyM6c5LWORCFZ1bLE44wBdu6p9vANuX33zIRYkF0lPj5DQ+o/IGOB3gqypCO5lIICfn7AtoqoORuUjMfEpLNoF5EpBkIg1vGih9Ctl+3unrHY4+4oTgrBIm4+tDHsYfqMUqqeX/926+ILq49cQZjeQPduiJN7lB0CgS3SFM8q3O+FfWRnGmz2mP4vYYlflBynoJWAuzAsHKcGvOT1uVECL2XmNFJCglV3jPxZQs3I7gXiDnG0MtZb4ObS8Qa8VzsxTAzsp5E38gniXtDdbjdq3c/wYYLjU5iU4eES2QGxsO4fM8dAF5Zur6Zw4gshhoCsvTx8gSG8/PaYzKdh2jiLlibfJwxH1Q0jwc= Content-Type: multipart/alternative; boundary="_000_BYAPR06MB4325ED8D44F051EBAA973392C4650BYAPR06MB4325namp_" MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7e32cf6f-f8e1-4e1a-207b-08d6911ef973 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2019 19:19:13.7930 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB5928 Archived-At: Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encryption X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 19:19:20 -0000 --_000_BYAPR06MB4325ED8D44F051EBAA973392C4650BYAPR06MB4325namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Maik, Also I have paraphrased your earlier proposed additions to the Utilities us= e case text (as copied from the Use Cases draft for reference) in Appendix = A of the Security draft. Here is the text I added, please let me know if yo= u have any corrections or other changes. Existing power automation security standards can inform networ= k security. For example the NERC CIP (North American Electric Reliability Corporation C= ritical Infrastructure Protection) plan is a set of requirements designed to secure th= e assets required for operating North America's bulk electric system. Another standar= dized security control technique is Segmentation (zones and conduits including access = control). The requirements in Industrial Automation and Control Systems = (IACS) are quite similar, especially in new scenarios such as Industry 4.0/Digital Factor= y where workflows and protocols cross zones, segments, and entities. IEC 62443 (ISA99= ) defines security for IACS, typically for installations in other critical infrastruct= ure such as oil and gas. Availability and integrity are the most important security obj= ectives for the lower layers of such networks; confidentiality and privacy are releva= nt if customer or market data is involved, typically handled by higher layers. FYI All of Appendix A will probably be removed from the Security draft befo= re publication, but during draft development we are keeping it there to pro= vide a single reference point. Thanks again for your input, Ethan. From: Maik Seewald (maseewal) Sent: Monday, February 11, 2019 11:23 PM To: Grossman, Ethan A. ; detnet@ietf.org Cc: ekr@rtfm.com Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encryption Hello Ethan, Only a few comments: Execution times are essential for flow calculations. On the other hand, to define bounded execution times is challenging. And, does it make sense to use the boundary (value) for calculations? Since this is a new standard, we should recommend agility of crypto algorit= hms in order to address quantum-safe crypto. This especially impacts asymmetric algoritms. Of course, there are implications with symmetric crypto, especially in term= s of key management. But I assume, this won't be part of the text... Cheers, Maik From: detnet > on b= ehalf of "Grossman, Ethan A." > Date: Tuesday, 12. February 2019 at 06:25 To: "detnet@ietf.org" > Cc: Eric Rescorla > Subject: [Detnet] DetNet Security Draft Proposed Text - Encryption Hi All, I have consolidated the list discussion about the pros and cons of encrypti= on algorithms into the Mitigation-Encryption section of the security draft = (text of the section as it now reads is below). I would like the WG to revi= ew it before I publish it in a new version of the Security draft. Thanks, Ethan (as editor of the DetNet Security draft) -------------------------------------------------------------------- 5. Security Threat Mitigation 5.4. Encryption Description DetNet flows can be forwarded in encrypted form. Related attacks Encryption can be used to mitigate recon attacks (Section 3.2.7). However, = for the DetNet to give differentiated quality of service on a flow-by-flow = basis, it must be able to identify the flows individually. This implies tha= t in a recon attack the attacker may also be able to track individual flows= to learn more about the system. Encryption can also provide traffic origin verification, i.e. to verify tha= t each packet in a DetNet flow is from a verified source, for example as pa= rt of ingress filtering. 5.4.1. Encryption Considerations for DetNet Any time spent on encryption and decryption processing ("crypto") must be i= ncluded in the flow latency calculations.. Thus, crypto algorithms used in = a DetNet must have bounded execution times. Some crypto algorithms are symmetric in encode/decode time (such as AES and= SHA-2) and others are asymmetric (such as public key algorithms). There ar= e advantages and disadvantages to the use of either type in a given DetNet = context. Asymmetrical crypto is typically not used in networks on a packet-by-packet= basis due to its computational cost. For example, if only endpoint checks = or checks at a small number of intermediate points are required, one can us= e asymmetric crypto to authenticate distribution or exchange of a secret sy= mmetric crypto key; a successful check based on that key will provide traff= ic origin verification as long as the key is kept secret by the participant= s. Both TLS and IKE (for IPsec) are examples of this for endpoint checks. However, if we use secret symmetrical keys for this purpose we must give th= e key to all relays, which increases the probability of a secret key being = leaked. Also, if any relay is compromised or misbehaving it may inject traf= fic into the flow. Alternatively, asymmetric crypto can provide traffic origin verification at= every intermediate node. For example, a DetNet flow can be associated with= an (asymmetric) keypair, such that the private key is available to the sou= rce of the flow and the public key is distributed with the flow information= , allowing verification at every node for every packet. However, this is mo= re computationally expensive. In either case, origin verification also requires replay detection mechanis= m as part of the security protocol to prevent an attacker from recording an= d resending traffic, e.g., as a denial of service attack on flow forwarding= resources. --_000_BYAPR06MB4325ED8D44F051EBAA973392C4650BYAPR06MB4325namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Maik,

Also I have paraphrased your earlier proposed additi= ons to the Utilities use case text (as copied from the Use Cases draft for = reference) in Appendix A of the Security draft. Here is the text I added, p= lease let me know if you have any corrections or other changes.

   &nbs= p;      <t>Existing power automation security standards can inform network security. For examp= le
            the NERC= CIP (North American Electric Reliability Corporation Critical Infrastructu= re
            Protecti= on) plan is a set of requirements designed to secure the assets required fo= r
            operatin= g North America's bulk electric system. Another standardized security contr= ol
            techniqu= e is Segmentation (zones and conduits including access control). </t>

          <t>The requirements in Industrial Automation and Control Systems (IACS) are quite= similar,
            especial= ly in new scenarios such as Industry 4.0/Digital Factory where workflows an= d
            protocol= s cross zones, segments, and entities. IEC 62443 (ISA99) defines security f= or
            IACS, ty= pically for installations in other critical infrastructure such as oil and<= br>             gas.</t>=

          <t>Availability and integrity are the most important security objectives for the lower
            layers o= f such networks; confidentiality and privacy are relevant if customer or ma= rket
            data is = involved, typically handled by higher layers.</t>

FYI All of Appendix A will probabl= y be removed from the Security draft before publication, but during draft d= evelopment we are keeping it there to provide a single reference point.

 

Thanks again for your input,

Ethan.

 

From: Maik Seewald (maseewal) <maseewal@cisco.com>
Sent: Monday, February 11, 2019 11:23 PM
To: Grossman, Ethan A. <eagros@dolby.com>; detnet@ietf.org
Cc: ekr@rtfm.com
Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encrypti= on

 

Hello Ethan,

 

Only a few comments: 

 

Execution times are essential for flow calculations. 

On the other hand, to define bounded execution times is challengi= ng.

And, does it make sense to use the boundary (value) for calculati= ons?

 

Since this is a new standard, we should recommend agility of cryp= to algorithms in order to address quantum-safe crypto.

This especially impacts asymmetric algoritms.

 

Of course, there are implications with symmetric crypto, especial= ly in terms of key management.

But I assume, this won’t be part of the text…

 

Cheers,

Maik

 

From: detnet <detnet-bounces@ietf.org> on behalf of "Grossman, Ethan A.&qu= ot; <eagros@dolby.com>
Date: Tuesday, 12. February 2019 at 06:25
To: "detnet@ietf.org&quo= t; <detnet@ietf.org>
Cc: Eric Rescorla <ekr@rtfm.com>
Subject: [Detnet] DetNet Security Draft Proposed Text - Encryption

 

Hi All,

I have consolidated the = list discussion about the pros and cons of encryption algorithms into the M= itigation-Encryption section of the security draft (text of the section as = it now reads is below). I would like the WG to review it before I publish it in a new version of the Security d= raft.

Thanks,

Ethan (as editor of the = DetNet Security draft)

------------------------= --------------------------------------------

<= ![if !supportLists]>5.    Security Threat Mitigation

<= ![if !supportLists]>5.4.      &nb= sp;  Encryption

Description

    =            DetNet flows c= an be forwarded in encrypted form.

Related attacks

Encryption can be used t= o mitigate recon attacks (Section 3.2.7). However, for the DetNet to give d= ifferentiated quality of service on a flow-by-flow basis, it must be able t= o identify the flows individually. This implies that in a recon attack the attacker may also be able to track indi= vidual flows to learn more about the system.

Encryption can also prov= ide traffic origin verification, i.e. to verify that each packet in a DetNe= t flow is from a verified source, for example as part of ingress filtering.=

<= ![if !supportLists]>5.4.1.     Encryption Considerations for DetNet

Any time spent on encryp= tion and decryption processing (“crypto”) must be included in t= he flow latency calculations.. Thus, crypto algorithms used in a DetNet mus= t have bounded execution times.

Some crypto algorithms a= re symmetric in encode/decode time (such as AES and SHA-2) and others are a= symmetric (such as public key algorithms). There are advantages and disadva= ntages to the use of either type in a given DetNet context.

Asymmetrical crypto is t= ypically not used in networks on a packet-by-packet basis due to its comput= ational cost. For example, if only endpoint checks or checks at a small num= ber of intermediate points are required, one can use asymmetric crypto to authenticate distribution or exchange of = a secret symmetric crypto key; a successful check based on that key will pr= ovide traffic origin verification as long as the key is kept secret by the = participants.  Both TLS and IKE (for IPsec) are examples of this for endpoint checks.

However, if we use secre= t symmetrical keys for this purpose we must give the key to all relays, whi= ch increases the probability of a secret key being leaked. Also, if any rel= ay is compromised or misbehaving it may inject traffic into the flow.

Alternatively, asymmetri= c crypto can provide traffic origin verification at every intermediate node= . For example, a DetNet flow can be associated with an (asymmetric) keypair= , such that the private key is available to the source of the flow and the public key is distributed with the flow = information, allowing verification at every node for every packet. However,= this is more computationally expensive.

In either case, origin v= erification also requires replay detection mechanism as part of the securit= y protocol to prevent an attacker from recording and resending traffic, e.g= ., as a denial of service attack on flow forwarding resources.

 =

--_000_BYAPR06MB4325ED8D44F051EBAA973392C4650BYAPR06MB4325namp_-- From nobody Wed Feb 13 00:18:06 2019 Return-Path: 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 665E8131031 for ; Wed, 13 Feb 2019 00:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=austad-us.20150623.gappssmtp.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 Ety021EI6MXW for ; Wed, 13 Feb 2019 00:18:00 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 06BCB12870E for ; Wed, 13 Feb 2019 00:17:59 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id l7-v6so1199112ljg.9 for ; Wed, 13 Feb 2019 00:17:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=austad-us.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ILOx7bwKVMmF3ll1g2OMeTYHCy/O3dFH3c39LK4TCGg=; b=0RqdeOsK9Sb8nKaWv7FiObIjhVpWHXeOO+JCMMKPzP3r5kZQEuDfGr0O1fxOgMm/dU ZUZ1LYP1PQJEOlbWvNRDterMMgXMDULC1ggtOmfxtkzGoZ5IzV9A4nxLmAlbWkycqouj UGD20UsI4s51LoPqrGVR8GUmuGV0ifc7fNuU9M67liPOYSqsBPNYV5VcZQw/sTy736Ns E0KY3ZP7F58NgYjG7w0xQ2yU0sW7sEGXl88uM/EtNpao8dDB/mY4XnPB51pAlETSuBP4 ecw6Rxuavv+j+8QBkaLFG0tcdR8RiU7v1raAH4FPNrjrfHzymQHMJBFSY+ohg1z44y6B G3wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ILOx7bwKVMmF3ll1g2OMeTYHCy/O3dFH3c39LK4TCGg=; b=ToVvSqTcR82ZhHlWJF3wgADFp89byclgugjawcJZFPYwBuma4C1V8fBzwzBwfU7fLL 0mznIO6KqVgp3I+YS9RJ08JIiWiTcGVfIdQ6Ma0dvWR4d4iOm+0f7jVKdsINGfRrBDnp CsAhiotwT1eiXPLc1NfTY2w/uAjxxLANsdH1W9lbf0vEmuoAOJjid3t4T5nA53FG7ABT 0zzi9H+BjojUigO1uev9tqWMd1Ux7q+Xa1Kw+wwuW+upRI/EtZiTdBpGiSNiz+gccIxQ DUHbkq1/SIIbT7j5VWx+rv8f5LyiWooFD3dpjxLZMed8pitYFQcOreAjgUfbuFbgH9uc pyrg== X-Gm-Message-State: AHQUAube3dYoUAlCCVm6LPi8iAQFL8MC8v7Cvm/yL/46JodcVsxhfXD0 fwh8gQ74jYoHkECcO7+qsgFdZQ== X-Google-Smtp-Source: AHgI3IYzHwYG70MZpPCvIU4oIVPau+9tep9go3D/JmrWOrWBxK0mBrPGffd9Rp15PVqr/FXpvazAmw== X-Received: by 2002:a2e:9395:: with SMTP id g21-v6mr4607269ljh.78.1550045877450; Wed, 13 Feb 2019 00:17:57 -0800 (PST) Received: from sisyphus.home.austad.us (11.92-220-88.customer.lyse.net. [92.220.88.11]) by smtp.gmail.com with ESMTPSA id w24-v6sm2999682ljh.83.2019.02.13.00.17.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 00:17:56 -0800 (PST) Date: Wed, 13 Feb 2019 09:17:54 +0100 From: Henrik Austad To: "Grossman, Ethan A." Cc: "detnet@ietf.org" , "ekr@rtfm.com" Message-ID: <20190213081754.GB11908@sisyphus.home.austad.us> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kORqDWCi7qDJ0mEj" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encryption X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 08:18:05 -0000 --kORqDWCi7qDJ0mEj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 12, 2019 at 05:25:40AM +0000, Grossman, Ethan A. wrote: > Hi All, Hi Ethan, > I have consolidated the list discussion about the pros and cons of=20 > encryption algorithms into the Mitigation-Encryption section of the=20 > security draft (text of the section as it now reads is below). I would=20 > like the WG to review it before I publish it in a new version of the=20 > Security draft. I must have missed that discussion - sorry! (If this means that I'm covering old, settled points below, please just=20 ignore my ramblings) Question (relevant for my points below): Do we plan to *encrypt* the header of the DetNet flows in transit, or will= =20 it be sufficient that the header is cryptographically signed? Follow up; if we go with signing, will intermidate nodes have a need to=20 update the DetNet hader, and if so, how do we solve the key-management=20 problem for a per-flow set of signing keys to all relevant nodes? -H > Thanks, > Ethan (as editor of the DetNet Security draft) > -------------------------------------------------------------------- > 5. Security Threat Mitigation > 5.4. Encryption > Description > DetNet flows can be forwarded in encrypted form. > Related attacks > Encryption can be used to mitigate recon attacks (Section 3.2.7).=20 > However, for the DetNet to give differentiated quality of service on a=20 > flow-by-flow basis, it must be able to identify the flows individually.= =20 > This implies that in a recon attack the attacker may also be able to=20 > track individual flows to learn more about the system. > > Encryption can also provide traffic origin verification, i.e. to verify= =20 > that each packet in a DetNet flow is from a verified source, for example= =20 > as part of ingress filtering. Since this covers more than 1 vector, perhaps it would be worthwhile to=20 distinguish between confidentiality (encrypting the payload of the stream,= =20 preferrably in an end-to-end manner) and integrity (of the header itself=20 using some sort of HMAC). As Maik pointed out in another email, we must=20 make a point about crypto agility. The payload itself should be end-to-end encrypted, the nodes should not=20 have any need to inspect the payload itself. We can probably push the=20 responsibility of this to the DetNet-application, the protocol should be=20 data-agnostic. > 5.4.1. Encryption Considerations for DetNet > > Any time spent on encryption and decryption processing ("crypto") must be= =20 > included in the flow latency calculations. Thus, crypto algorithms used= =20 > in a DetNet must have bounded execution times. Some crypto algorithms are= =20 > symmetric in encode/decode time (such as AES and SHA-2) and others are=20 > asymmetric (such as public key algorithms).=20 Nitpick SHA-2 is a hashing algorithm, not a crypto-algorithm. Also, Since SHA-2 is very similar to SHA-1 (which is considered broken), SHA-3 was born. As with crypto agility, we should make a note about=20 hash-function agility. > There are advantages and disadvantages to the use of either type in a=20 > given DetNet context. Asymmetrical crypto is typically not used in=20 > networks on a packet-by-packet basis due to its computational cost. For= =20 > example, if only endpoint checks or checks at a small number of=20 > intermediate points are required, one can use asymmetric crypto to=20 > authenticate distribution or exchange of a secret symmetric crypto key; a= =20 > successful check based on that key will provide traffic origin=20 > verification as long as the key is kept secret by the participants. Both= =20 > TLS and IKE (for IPsec) are examples of this for endpoint checks.=20 Not only TLS and IKE; this is pretty much how asymmetric crypto works. You= =20 create a symmetric key and you use asymmetrci crypto to share that secret= =20 between Alice and Bob. Then you also re-generate the symmetric keys periodically. This is perhaps= =20 something we should make a not of, as that will add some additional cost,= =20 thus affecting the determinstic behaviour. > However, if we use secret symmetrical keys for this purpose we must give= =20 > the key to all relays, which increases the probability of a secret key=20 > being leaked. Also, if any relay is compromised or misbehaving it may=20 > inject traffic into the flow. Hence the need to split the header from the payload, regenerate symmetric= =20 keys etc. > Alternatively, asymmetric crypto can provide traffic origin verification= =20 > at every intermediate node. Signature verification using public keys is a pretty deterministic=20 operation I think, generate the hash, verify the signature. I need to dig= =20 through some books to be sure. > For example, a DetNet flow can be associated with an (asymmetric)=20 > keypair, such that the private key is available to the source of the flow= =20 > and the public key is distributed with the flow information, allowing=20 > verification at every node for every packet. However, this is more=20 > computationally expensive. In either case, origin verification also=20 > requires replay detection mechanism as part of the security protocol to= =20 > prevent an attacker from recording and resending traffic, e.g., as a=20 > denial of service attack on flow forwarding resources. There are ways to avoid replay-attacks when you have secure hashes, but you= =20 must store some state on each node. Since each frame contains both a=20 sequence-number and a stream-id, what we need are available to detect=20 replays. This means that the header must either be transported in the=20 clear, or that we can decrypt it in transit though. --=20 Henrik Austad --kORqDWCi7qDJ0mEj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlxj0rIACgkQ6k5VT6v45lnfcACgvvfziL7L3FtZGpwt4ByM/Dk7 hHcAn3V8VgBYMPGhhlkRyeJArY8QUH2j =EM4M -----END PGP SIGNATURE----- --kORqDWCi7qDJ0mEj-- From nobody Wed Feb 13 00:30:54 2019 Return-Path: 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 B8AFC12870E for ; Wed, 13 Feb 2019 00:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ca+b2cZ3; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=l+feZbc9 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 ZRko-yfc2Hzt for ; Wed, 13 Feb 2019 00:30:49 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5808B128CB7 for ; Wed, 13 Feb 2019 00:30:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30305; q=dns/txt; s=iport; t=1550046649; x=1551256249; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YOoAvBTqg7ot2JxWZytciy48cvPJhmiXIM1FQboHXXA=; b=ca+b2cZ3lE6Qgc7Q0E4DmT0P3Ecr/KpzZSUkGPwkqt5AdP/skQH4Pi/+ LhXGErNw8kpcBmhJ17zmCoVnEnYQlfLWYnnE0iuYkiIC/i3r8lLHhPMy/ z6XtEM66y59i6FNMA/kkbrpKSPQDKpSy5qjoIEQZnFeEHGwDnpoCKuJpC E=; IronPort-PHdr: =?us-ascii?q?9a23=3A5raxgRZz8QpCW80eWeDgWP7/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavvZjc3EdtLUHdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAABc1GNc/5JdJa1ZChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVQBAQEBAQELAYENI1ADZ3QECycKh0IDj3dKgg2YJ4E?= =?us-ascii?q?QA1QLAQEshEACg08iNwYNAQMBAQIBAQJtHAyFSgEBAQQtEwEBNwEPAgEIEQM?= =?us-ascii?q?BAQEhAQYHMhQJCAIEAQ0FH4MGgR1MAxUBnlsCihSCIIJ4AQEFgkWCPxiCCwi?= =?us-ascii?q?JenYQJYEAHReBQD+BEYF9Zy6EVg8EOBaFKooCA4YdMIZQE4sYXAkCiFGCVIc?= =?us-ascii?q?sGYFthVKEfIY0gyWEBIMMkWgCBAIEBQINAQEFgVwigVZwFTuCbIIcg26KU3K?= =?us-ascii?q?BKI0oAYEeAQE?= X-IronPort-AV: E=Sophos;i="5.58,365,1544486400"; d="scan'208,217";a="521062547" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2019 08:30:35 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x1D8UXB0000467 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Feb 2019 08:30:33 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 13 Feb 2019 02:30:32 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 13 Feb 2019 02:30:31 -0600 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 13 Feb 2019 02:30:31 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vRS/6SBQfoZ13JufshInly5A859At8hZqXzcxkLketE=; b=l+feZbc9oJPi0i4KlpyK0tlSpeT7NVLH4Kan69BRvWIgdCKBqEZbs3HEGceegtecyvgGoj5+gZZSKRkQhoPWBLX1G16vEVLa32Oa3l8+rS4zHggiL2ASJQ9uQWSAPQQyCxhckUqtB9g6HT6VCvt4bFz+XKth5F9l7ch9RCWVwQQ= Received: from CY4PR11MB1479.namprd11.prod.outlook.com (10.172.66.137) by CY4PR11MB2054.namprd11.prod.outlook.com (10.173.16.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Wed, 13 Feb 2019 08:30:30 +0000 Received: from CY4PR11MB1479.namprd11.prod.outlook.com ([fe80::582b:d678:23c3:ad22]) by CY4PR11MB1479.namprd11.prod.outlook.com ([fe80::582b:d678:23c3:ad22%4]) with mapi id 15.20.1622.016; Wed, 13 Feb 2019 08:30:30 +0000 From: "Maik Seewald (maseewal)" To: "Grossman, Ethan A." , "detnet@ietf.org" CC: "ekr@rtfm.com" Thread-Topic: [Detnet] DetNet Security Draft Proposed Text - Encryption Thread-Index: AQHUwqO59xE6aoAp/UuUS5dNynm9eqXciKZggADv2gA= Date: Wed, 13 Feb 2019 08:30:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.6.150930 authentication-results: spf=none (sender IP is ) smtp.mailfrom=maseewal@cisco.com; x-originating-ip: [173.38.220.42] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3453eec0-192f-41fc-c5d5-08d6918d839f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:CY4PR11MB2054; x-ms-traffictypediagnostic: CY4PR11MB2054: x-microsoft-exchange-diagnostics: =?Windows-1252?Q?1; CY4PR11MB2054; 23:48zzRgMINxj+jYaHKN34IqomVg1aCqcSD1omL?= =?Windows-1252?Q?zjJHFW1XGbAcSXbnRbEyhjg5pobrQgzqhrlaj1FOxEB9qtg1Tj2TZHeZ?= =?Windows-1252?Q?cqcArjKGFbPQgt7bv6W5hgAzE4TmaLPIgPoPXxvAlh6L8usXpuNKRcL+?= =?Windows-1252?Q?qAnL+n5qNpTR3xR+k7vh0qttb9ZXKJFtt7w9lWjvx4drLOgV5U8S+74Y?= =?Windows-1252?Q?CroANZpTUauZoaco7n4jITduAfdM9ihSV0pfwAahzygFp8Yg1iDL9zUd?= =?Windows-1252?Q?1KZGgUy/FI55kEkRm7doj2gF76U3mcgGRIydg1ToEbJ2eG7nexe4T99y?= =?Windows-1252?Q?vm105JH2av8yaLulHjAcJFPufj5KxnI64XVNp1N+gxGh3NI7W1l5+lWx?= =?Windows-1252?Q?XElwYpEcEcqyfMKghyPXSlXDw3ad4PSjGb1xcubj+Pachr6ZnKEnKacM?= =?Windows-1252?Q?a8IS0VS7BZ3iekednsgqrX+Q7EwVe6fxxd5pH9FjtoVfEgOJmjHiH3KL?= =?Windows-1252?Q?q3CLz/H+OQKzdJ4LLL9ELYeD09w1LTTe9QW+BboKPFdWemfpwNSbEaCw?= =?Windows-1252?Q?VPFgyYsYh9jDvie/7llGjHrEPzKOk9SCjdNeq+RsAwR37OxTsDM8pGOn?= =?Windows-1252?Q?n9HJnq7JeRGOh/FwSnIlGFbLhC418QvkHlGnsD6HgmOebmlfc1hytaqy?= =?Windows-1252?Q?gMgwHUE4EyqekM5qJaqOpN9Kpg4eyu8hXOJAuDCGMK4fuFK1Hl96s3FN?= =?Windows-1252?Q?lMbDJe2Ghrvxp7D9LWj+gOrck/1AlbYFGgkjShS3cSRatS6JIPqtTZGD?= =?Windows-1252?Q?kPqsiguc2nF2oFGPGy0XDSvIKyXPUCJGisFZ7J6SEU3PqpfMXjGuXKeX?= =?Windows-1252?Q?K60b/0uE4Wsop6bjyYf/6MUb1iyjUQXTPY1dIBZz75I9un2McOzte0B+?= =?Windows-1252?Q?7oXqGhTlmtDsxlg4uuMUgVjNRHra+Y4ccSmevFTMWhz8sUMFG1lYBjU4?= =?Windows-1252?Q?Odu6ELfupWogFqmlgKBYV2JRNXZk1/GD935nqcvCOLQWlY/lb656bNJ0?= =?Windows-1252?Q?Qr86odxvKdwJmHMrNGo7sebBnCN8CQvcs4XWRgwzZctT42hlpd0qiyj+?= =?Windows-1252?Q?LOasEEBAuGxmIdXY2HRFrTM6xZEli2+yWusME6G9jeWtzmoF/czpR4U/?= =?Windows-1252?Q?FVygP30qQbHMjtAKcPL7YsxD1NRKUmp0wqFMLlXjOiwSQmjPjaWavvyf?= =?Windows-1252?Q?S9rMVgMG2ybJbqy5e6Bt0mrd2XmK7s/sTObAxKvW2YdHIdPZ2rxzElNi?= =?Windows-1252?Q?KuA4bskP1nMbgVLObGFLjwAWyYINv9L+IuthKuIl9T2OkTUeaIggKRSM?= =?Windows-1252?Q?fW2w9Fo4l6u0RVdaIU0SfuRu5QzZoqEuk5M/dkgf0vYEVuhRfulrjp+x?= =?Windows-1252?Q?fgZs2+LgJ+nnLnbmnZ0aR0J6IYasaBQtht0oCQyHwhzVA++dKetZE0Ha?= =?Windows-1252?Q?9WQdVA=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 094700CA91 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(39860400002)(136003)(396003)(53754006)(189003)(199004)(256004)(6486002)(25786009)(7736002)(68736007)(15650500001)(2420400007)(316002)(6436002)(10710500007)(99286004)(6512007)(53936002)(6246003)(54896002)(236005)(8936002)(4326008)(36756003)(14444005)(81166006)(86362001)(2906002)(6306002)(81156014)(478600001)(8676002)(229853002)(14454004)(11346002)(2616005)(71200400001)(71190400001)(6506007)(486006)(446003)(476003)(7110500001)(97736004)(186003)(102836004)(53546011)(26005)(110136005)(76176011)(105586002)(2501003)(66066001)(106356001)(790700001)(3846002)(6116002)(58126008); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB2054; H:CY4PR11MB1479.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: AlQZhgEZ2R/XNq4SdHUX25M7Az3rfiG8FLUGmh5HjsjVRimOk1jhPjj67v3mmUMMbETqVTOGZRSvwF/wJGmADNr7sDIn4WEUWL/pn6n6vdTxfao4TZu2Sk+GzmQGsVp0u+9VewA8PatLSJQtbFFZQNuly9mEaFD4rTzwnAiED2HtnR3KhtFczU46O36LRPYlFrs+LgLbz6ZVuFkV9zKrQWkNaN8MOB3MpM5BOYA6tBQwXw+BaGjnioFlpb3UEbkZG0TmiRr//SEiDclUXdSIbFqVX1VJKqFd5WnGuPyHNhA8ebUuK3g2o0T3BCKCBRhgAhnOg1rWAMCIGEkBj0Q0pejImEynM8cLbSQgwXxqpCLMQ7ofm9FWnOZuTbaSbwIKPsZ8mOrqPsLJPmDKanpjMr1ymTnleCZZO0oSd7DbOu0= Content-Type: multipart/alternative; boundary="_000_D889918379E0Fmaseewalciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3453eec0-192f-41fc-c5d5-08d6918d839f X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2019 08:30:30.2735 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB2054 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encryption X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 08:30:53 -0000 --_000_D889918379E0Fmaseewalciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Ethan, It looks good! Thanks. Maik From: "Grossman, Ethan A." > Date: Tuesday, 12. February 2019 at 20:19 To: Cisco Employee >, "detnet= @ietf.org" = > Cc: Eric Rescorla > Subject: RE: [Detnet] DetNet Security Draft Proposed Text - Encryption Maik, Also I have paraphrased your earlier proposed additions to the Utilities us= e case text (as copied from the Use Cases draft for reference) in Appendix = A of the Security draft. Here is the text I added, please let me know if yo= u have any corrections or other changes. Existing power automation security standards can inform networ= k security. For example the NERC CIP (North American Electric Reliability Corporation C= ritical Infrastructure Protection) plan is a set of requirements designed to secure th= e assets required for operating North America's bulk electric system. Another standar= dized security control technique is Segmentation (zones and conduits including access = control). The requirements in Industrial Automation and Control Systems = (IACS) are quite similar, especially in new scenarios such as Industry 4.0/Digital Factor= y where workflows and protocols cross zones, segments, and entities. IEC 62443 (ISA99= ) defines security for IACS, typically for installations in other critical infrastruct= ure such as oil and gas. Availability and integrity are the most important security obj= ectives for the lower layers of such networks; confidentiality and privacy are releva= nt if customer or market data is involved, typically handled by higher layers. FYI All of Appendix A will probably be removed from the Security draft befo= re publication, but during draft development we are keeping it there to pro= vide a single reference point. Thanks again for your input, Ethan. From: Maik Seewald (maseewal) > Sent: Monday, February 11, 2019 11:23 PM To: Grossman, Ethan A. >; detnet@= ietf.org Cc: ekr@rtfm.com Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encryption Hello Ethan, Only a few comments: Execution times are essential for flow calculations. On the other hand, to define bounded execution times is challenging. And, does it make sense to use the boundary (value) for calculations? Since this is a new standard, we should recommend agility of crypto algorit= hms in order to address quantum-safe crypto. This especially impacts asymmetric algoritms. Of course, there are implications with symmetric crypto, especially in term= s of key management. But I assume, this won=92t be part of the text=85 Cheers, Maik From: detnet > on b= ehalf of "Grossman, Ethan A." > Date: Tuesday, 12. February 2019 at 06:25 To: "detnet@ietf.org" > Cc: Eric Rescorla > Subject: [Detnet] DetNet Security Draft Proposed Text - Encryption Hi All, I have consolidated the list discussion about the pros and cons of encrypti= on algorithms into the Mitigation-Encryption section of the security draft = (text of the section as it now reads is below). I would like the WG to revi= ew it before I publish it in a new version of the Security draft. Thanks, Ethan (as editor of the DetNet Security draft) -------------------------------------------------------------------- 5. Security Threat Mitigation 5.4. Encryption Description DetNet flows can be forwarded in encrypted form. Related attacks Encryption can be used to mitigate recon attacks (Section 3.2.7). However, = for the DetNet to give differentiated quality of service on a flow-by-flow = basis, it must be able to identify the flows individually. This implies tha= t in a recon attack the attacker may also be able to track individual flows= to learn more about the system. Encryption can also provide traffic origin verification, i.e. to verify tha= t each packet in a DetNet flow is from a verified source, for example as pa= rt of ingress filtering. 5.4.1. Encryption Considerations for DetNet Any time spent on encryption and decryption processing (=93crypto=94) must = be included in the flow latency calculations.. Thus, crypto algorithms used= in a DetNet must have bounded execution times. Some crypto algorithms are symmetric in encode/decode time (such as AES and= SHA-2) and others are asymmetric (such as public key algorithms). There ar= e advantages and disadvantages to the use of either type in a given DetNet = context. Asymmetrical crypto is typically not used in networks on a packet-by-packet= basis due to its computational cost. For example, if only endpoint checks = or checks at a small number of intermediate points are required, one can us= e asymmetric crypto to authenticate distribution or exchange of a secret sy= mmetric crypto key; a successful check based on that key will provide traff= ic origin verification as long as the key is kept secret by the participant= s. Both TLS and IKE (for IPsec) are examples of this for endpoint checks. However, if we use secret symmetrical keys for this purpose we must give th= e key to all relays, which increases the probability of a secret key being = leaked. Also, if any relay is compromised or misbehaving it may inject traf= fic into the flow. Alternatively, asymmetric crypto can provide traffic origin verification at= every intermediate node. For example, a DetNet flow can be associated with= an (asymmetric) keypair, such that the private key is available to the sou= rce of the flow and the public key is distributed with the flow information= , allowing verification at every node for every packet. However, this is mo= re computationally expensive. In either case, origin verification also requires replay detection mechanis= m as part of the security protocol to prevent an attacker from recording an= d resending traffic, e.g., as a denial of service attack on flow forwarding= resources. --_000_D889918379E0Fmaseewalciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hello Ethan,

It looks good! 

Thanks.
Maik

From: "Grossman, Ethan A."= ; <eagros@dolby.com>
Date: Tuesday, 12. February 2019 at= 20:19
To: Cisco Employee <maseewal@cisco.com>, "detnet@ietf.org" <detnet@ietf.org>
Cc: Eric Rescorla <ekr@rtfm.com>
Subject: RE: [Detnet] DetNet Securi= ty Draft Proposed Text - Encryption

Maik,

Also I have paraphrased your earlier proposed additi= ons to the Utilities use case text (as copied from the Use Cases draft for = reference) in Appendix A of the Security draft. Here is the text I added, p= lease let me know if you have any corrections or other changes.

   &nbs= p;      <t>Existing power automation security standards can inform network security. For examp= le
            the NERC= CIP (North American Electric Reliability Corporation Critical Infrastructu= re
            Protecti= on) plan is a set of requirements designed to secure the assets required fo= r
            operatin= g North America's bulk electric system. Another standardized security contr= ol
            techniqu= e is Segmentation (zones and conduits including access control). </t>

          <t>The requirements in Industrial Automation and Control Systems (IACS) are quite= similar,
            especial= ly in new scenarios such as Industry 4.0/Digital Factory where workflows an= d
            protocol= s cross zones, segments, and entities. IEC 62443 (ISA99) defines security f= or
            IACS, ty= pically for installations in other critical infrastructure such as oil and<= br>             gas.</t>=

          <t>Availability and integrity are the most important security objectives for the lower
            layers o= f such networks; confidentiality and privacy are relevant if customer or ma= rket
            data is = involved, typically handled by higher layers.</t>

FYI All of Appendix A will probabl= y be removed from the Security draft before publication, but during draft d= evelopment we are keeping it there to provide a single reference point.

 

Thanks again for your input,

Ethan.

 

From: Maik Seewald (maseewal) <maseewal@cisco.com>
Sent: Monday, February 11, 2019 11:23 PM
To: Grossman, Ethan A. <eagro= s@dolby.com>; detnet@ietf.org
Cc: ekr@rtfm.com
Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encrypti= on

 

Hello Ethan,

 

Only a few comments: 

 

Execution times are essential for flow calculations. 

On the other hand, to define bounded execution times is challengi= ng.

And, does it make sense to use the boundary (value) for calculati= ons?

 

Since this is a new standard, we should recommend agility of cryp= to algorithms in order to address quantum-safe crypto.

This especially impacts asymmetric algoritms.

 

Of course, there are implications with symmetric crypto, especial= ly in terms of key management.

But I assume, this won=92t be part of the text=85

 

Cheers,

Maik

 

From: detnet <detnet-bounces@ietf.org> on behalf of "Grossman, Ethan A.&qu= ot; <eagros@dolby.com>
Date: Tuesday, 12. February 2019 at 06:25
To: "detnet@ietf.org&quo= t; <detnet@ietf.org>
Cc: Eric Rescorla <ekr@rtfm.com>
Subject: [Detnet] DetNet Security Draft Proposed Text - Encryption

 

Hi All,

I have consolidated the = list discussion about the pros and cons of encryption algorithms into the M= itigation-Encryption section of the security draft (text of the section as = it now reads is below). I would like the WG to review it before I publish it in a new version of the Security d= raft.

Thanks,

Ethan (as editor of the = DetNet Security draft)

------------------------= --------------------------------------------

<= !--[if !supportLists]-->5.    Security Threat Mitigation

<= !--[if !supportLists]-->5.4.      = ;   Encryption

Description

    =            DetNet flows c= an be forwarded in encrypted form.

Related attacks

Encryption can be used t= o mitigate recon attacks (Section 3.2.7). However, for the DetNet to give d= ifferentiated quality of service on a flow-by-flow basis, it must be able t= o identify the flows individually. This implies that in a recon attack the attacker may also be able to track indi= vidual flows to learn more about the system.

Encryption can also prov= ide traffic origin verification, i.e. to verify that each packet in a DetNe= t flow is from a verified source, for example as part of ingress filtering.=

<= !--[if !supportLists]-->5.4.1.     Encryption Considerations for DetNet=

Any time spent on encryp= tion and decryption processing (=93crypto=94) must be included in the flow = latency calculations.. Thus, crypto algorithms used in a DetNet must have b= ounded execution times.

Some crypto algorithms a= re symmetric in encode/decode time (such as AES and SHA-2) and others are a= symmetric (such as public key algorithms). There are advantages and disadva= ntages to the use of either type in a given DetNet context.

Asymmetrical crypto is t= ypically not used in networks on a packet-by-packet basis due to its comput= ational cost. For example, if only endpoint checks or checks at a small num= ber of intermediate points are required, one can use asymmetric crypto to authenticate distribution or exchange of = a secret symmetric crypto key; a successful check based on that key will pr= ovide traffic origin verification as long as the key is kept secret by the = participants.  Both TLS and IKE (for IPsec) are examples of this for endpoint checks.

However, if we use secre= t symmetrical keys for this purpose we must give the key to all relays, whi= ch increases the probability of a secret key being leaked. Also, if any rel= ay is compromised or misbehaving it may inject traffic into the flow.

Alternatively, asymmetri= c crypto can provide traffic origin verification at every intermediate node= . For example, a DetNet flow can be associated with an (asymmetric) keypair= , such that the private key is available to the source of the flow and the public key is distributed with the flow = information, allowing verification at every node for every packet. However,= this is more computationally expensive.

In either case, origin v= erification also requires replay detection mechanism as part of the securit= y protocol to prevent an attacker from recording and resending traffic, e.g= ., as a denial of service attack on flow forwarding resources.

 =

--_000_D889918379E0Fmaseewalciscocom_-- From nobody Wed Feb 13 02:14:49 2019 Return-Path: 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 9EB01124408 for ; Wed, 13 Feb 2019 02:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=TPLCbC/K; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lqu+8VTO 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 T-VibuQoptd6 for ; Wed, 13 Feb 2019 02:14:44 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D9512894E for ; Wed, 13 Feb 2019 02:14:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28007; q=dns/txt; s=iport; t=1550052883; x=1551262483; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WtE02XlsWWlmXRp0A0GjMl/bFuvrzDZyTqyw2LyMAcE=; b=TPLCbC/KbJ9xsTz/9PmR7ybwHW7WWN3YPqMpfGuuaTozQjNH0ibbZYR4 WtedP3W9+ELg+FKThcRSdNj2BxsRa10/xhpLo5K4GkIH8+bRNsospclFU 4YHKKgCKYp30Jth/p0EK1SBZOjjMCuLPuewRZX5YpW5K4yfQ43hqw/hKD 0=; IronPort-PHdr: =?us-ascii?q?9a23=3Akm+KqBV3QYAqO8OAfMtgdacrc4TV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank/Fd9PWUBs+1mwMFNeH4D1YFiB6nA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABh7WNc/49dJa1ZChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYENIyomA2d0BAsnCodCA4RQiydKgg2?= =?us-ascii?q?YE4EkA1QLAQEshEACg1IiNAkNAQMBAQIBAQJtHAyFSgEBAQQtEwEBNwEPAgE?= =?us-ascii?q?IEQMBAQEhBwcyFAkIAgQBDQUfgjpMgR1MAxUBnm0CihSCIIJ4AQEFgkWCPhi?= =?us-ascii?q?CCwiJenYQJYEAHReBQD+DDmcuhFZLFoUqigWGHYcTixhcCQKLJYcsGZJvgyW?= =?us-ascii?q?EBIMMkWgCBAIEBQINAQEFgUY4gVZwFTuCbIIcg26KU3KBKI0oAYEeAQE?= X-IronPort-AV: E=Sophos;i="5.58,365,1544486400"; d="scan'208,217";a="518008689" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2019 10:14:36 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x1DAEX61004758 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Feb 2019 10:14:33 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 13 Feb 2019 04:14:33 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 13 Feb 2019 04:14:32 -0600 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 13 Feb 2019 04:14:32 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hVX/3yLYcBYAsevdHfm8NGJoIc5YJOBGedQtE5P3PAI=; b=lqu+8VTOvQ9Adl+zhu+ljiSxLrvgW1Q1dz//l9cjnTZmE5Wb6loEq3Es28FtBqidUhJBCE/5/reaQuqvRQkIA64CG2jSNo9YUQuFQFhKzbksZbtFVY/j5ucaUdoHFQL5K25JplhCEBORvTFnbY6UM4XSi/HpTRltjBmiJw4/6iY= Received: from CY4PR11MB1479.namprd11.prod.outlook.com (10.172.66.137) by CY4PR11MB1608.namprd11.prod.outlook.com (10.172.71.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Wed, 13 Feb 2019 10:14:31 +0000 Received: from CY4PR11MB1479.namprd11.prod.outlook.com ([fe80::582b:d678:23c3:ad22]) by CY4PR11MB1479.namprd11.prod.outlook.com ([fe80::582b:d678:23c3:ad22%4]) with mapi id 15.20.1622.016; Wed, 13 Feb 2019 10:14:31 +0000 From: "Maik Seewald (maseewal)" To: "Grossman, Ethan A." , "detnet@ietf.org" CC: "ekr@rtfm.com" Thread-Topic: [Detnet] DetNet Security Draft Proposed Text - Encryption Thread-Index: AQHUwqO59xE6aoAp/UuUS5dNynm9eqXcho4wgAEPBIA= Date: Wed, 13 Feb 2019 10:14:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.6.150930 x-originating-ip: [173.38.220.42] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 585a83ea-85de-4476-680a-08d6919c0b50 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:CY4PR11MB1608; x-ms-traffictypediagnostic: CY4PR11MB1608: x-microsoft-exchange-diagnostics: =?Windows-1252?Q?1; CY4PR11MB1608; 23:+xTDEDoZLTDbnPUF0xqpcsWiOCHtWd7lpoFaE?= =?Windows-1252?Q?5eTm9V94/VRSHMwe1UhzwTlkQryLAgKzzLp/P4dYiUQOAUD3qABRvySE?= =?Windows-1252?Q?FZPDTxx3EwPmIu+46YieZFt8yKJ4RUhmimMacg4Q4Tzzq3Cd7eoULQdG?= =?Windows-1252?Q?CFkq3ZMVyL/uzP6zGw3gHEWV0vuoKmFnSC0f7nF8LfYM7IYuACwgpYJs?= =?Windows-1252?Q?++2hAC+omwV+l9a607bosXKTeEmvxiTUnWwb+zXMWc7Thsfgsz5VwwcE?= =?Windows-1252?Q?+4YYlglry5Y2dj6Sl3wGzgVo4gBTiOPokmtzYMSZ8Zvy6u9g4nGZgAt3?= =?Windows-1252?Q?6eFiUgvCKq8WcoYo8li+F8hZ/m7xQxoH+0BHCDJTMWDSq/qnVbuVGE5Q?= =?Windows-1252?Q?rCUuCZHQSTKL1iWUcPrmab3B7HR0NQNksZ6J+1A24/yqyC7wEGp2VgM+?= =?Windows-1252?Q?Rm8lBVtoIMPalYMF8sDcblka3vQnm0NZAqxSnOYRDVp+czqvOAW4+k5W?= =?Windows-1252?Q?utHXtaeibbJtxOHr8Yctef7a4taVt4HdRI2Qa62wriCR4SZtksAd2bEK?= =?Windows-1252?Q?VGONEbOdCCBPghuhIL+h6pZ9f4jLgLqKm9YuJA2paKfqeGtWGG1CcEV4?= =?Windows-1252?Q?2OqIwyaIzs+t1vheCzK/Z/Z34tRFXcahFSVENZK3KG9CQ/xY7HrWkEAa?= =?Windows-1252?Q?8BsE2Q0i8sHx3t7rR8VI+aIsHUCkLz/aqkq9YobfJl6zhMkWYAVlvbzf?= =?Windows-1252?Q?ihtgDH5nRWLRs6EnMhHTR6vT3A3iflWPZm8UMx7zm8dVIqTBCcwwjHKg?= =?Windows-1252?Q?/3aQZAMkQVTavyYJfwGF/7BqYxBq5kJRSlGxljqedPnheSSh6RT6dT3Y?= =?Windows-1252?Q?OWcVfeXo8o6DwCUp03mHEg0YYshzeMtLvjnHRY9Qb932m5r7Wbla/0l0?= =?Windows-1252?Q?xSLKCNqzI0AD3xqPY4ZrH0BzD9nioDwqtdJlujFWKXPvMicu0236o7py?= =?Windows-1252?Q?h/G30V5jBNX/Gg1io2TXgbkBEqJJOSU/eFZg6oRknJt2v15UzmMI/WZy?= =?Windows-1252?Q?aLcn2NfYWIGL2x1XTiOzFkXHxhtFt73u+h8PNTBQEyCzZQXE1tQ2FrDo?= =?Windows-1252?Q?YBMBw+0hf4T3GumszCX/tnvZ2hSBjBSNJMyowj52jRUO88w8JFhfytvp?= =?Windows-1252?Q?g+1mnwpu/ELhxmb509HGG5qNIxmSo44A5nEffk5phkZfQWjjEfT3zySf?= =?Windows-1252?Q?3S4ysGW2qCQURzp83OQm8V7xLyHhs1jhvamctTq8khLLG+/LRuVuKGT1?= =?Windows-1252?Q?rdCoss/8Hz/0VO1BOCImppi6o/RqT5nv8XtqubDcjTbR63qrJ0erI4Vi?= =?Windows-1252?Q?A+tlbMlReGYHZ/00PVR3rkHcVfx0sf3kLDDa6JV0CdFx7TLPivLhxTpq?= =?Windows-1252?Q?zbEds7gsSyu86MpTK8WXVV5PGnUWeSrikn/s0khc6T5lLOKLgtJhUC4q?= =?Windows-1252?Q?acgfUwAN11TOtcgglzRb2iWAwgRYI2lCIpFOns4pucHh0SJHQ=3D=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 094700CA91 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(39860400002)(376002)(346002)(396003)(53754006)(51914003)(189003)(199004)(476003)(6512007)(15650500001)(236005)(4326008)(105586002)(229853002)(2616005)(7736002)(6306002)(790700001)(3846002)(486006)(110136005)(76176011)(54896002)(6116002)(6246003)(106356001)(186003)(36756003)(256004)(14444005)(66066001)(6436002)(53546011)(478600001)(25786009)(14454004)(81166006)(8936002)(6506007)(81156014)(8676002)(2906002)(58126008)(446003)(71200400001)(11346002)(6486002)(316002)(68736007)(7110500001)(26005)(102836004)(10710500007)(2420400007)(2501003)(97736004)(6346003)(71190400001)(86362001)(99286004)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB1608; H:CY4PR11MB1479.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=maseewal@cisco.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: losk3pgjsAjBLg1JHB7VxknxNkXRSjQWShB5u+HmxjBkFVDbSgZCZ4DmbUTgjfdlGVoUniczmDpW+7Q2FMmGyWe/JyXPrZHxNSw3nsh8tQQW+tlkNSECcLCTMnG3BqXSrr1Js6xsNujXn58khtk3Okx4uQpVbmLPLhd3pEHkUXtqBnC1+WNBBZA/SHimD+RIcXlc9QFIsq/DfOMiX1E/EXHjW+vCNR1KSI+CG60SrB4lYV2GDK+xkuyM1djUY318IihHqCcKwiFwintC7amsG0mKa4ViLAfpC3EiXsD9JRLbdK/TcU/Nh7Ym65UirWdYwOnQi7OaplMWET1AIUxzIoJTnd8YvJmCvC8ToF9catDkjU1u2nFzYprax08u5inEe6WrJ8iM3iTlOcheNPZ+q2VBIjsx+FvqKYZUatA1pV4= Content-Type: multipart/alternative; boundary="_000_D88999B379E2Fmaseewalciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 585a83ea-85de-4476-680a-08d6919c0b50 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2019 10:14:30.9497 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1608 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encryption X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 10:14:48 -0000 --_000_D88999B379E2Fmaseewalciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ethan, Sorry for being that unspecific. Yes, the worst time must be used. But this is very much hardware/implementation depending. On encryption in general (and addressing Henrik=92s response he sent minute= s ago), this is typically an end-to-end requirement in many industries and = is typically implemented in the upper layers: 4.5, 8, 9. In many industries, that might use DetNet for WAN transport, it is not acce= ptable to have messages decrypted/encrypted on network nodes. Regarding the agility, I had been very unspecific again. Reason, I don=92t = have a good answer ready to propose. (1) It also depends on the depth we want to address crypto in this draft: p= rescribing algorithms vs. defining security objectives and controls (confid= entiality/secrecy, integrity, =85)? And I have not yet mentioned the complex area of key management. The comment reg agility is about the fact that quantum-based computing will= break existing crypto much easier/faster, especially asymmetric algorithms= . In order to address this disruptive event, standards already addressing qua= ntum-safe crypto in a very simple manner: recommending agility of crypto (e= .g.: allowing endpoints to pick the best algorithms in a sequence; at least= , not hard-coding things, very simple stuff but helpful). Hope this is somehow useful=85 But my response is basically boiling down to the question (1). Cheers, Maik From: "Grossman, Ethan A." > Date: Tuesday, 12. February 2019 at 20:10 To: Cisco Employee >, "detnet= @ietf.org" = > Cc: Eric Rescorla > Subject: RE: [Detnet] DetNet Security Draft Proposed Text - Encryption Hi Maik, Thanks for these comments. Regarding =93to define bounded execution times is challenging. And, does it= make sense to use the boundary (value) for calculations?=94 =96 if I under= stand your question correctly, then yes, it does make sense, because end-to= -end latency must be bounded so for any packet processing the worst case ti= me must be used. Regarding =93we should recommend agility of crypto algorithms in order to a= ddress quantum-safe crypto=94 =96 I don=92t understand exactly the implicat= ion of this =96 can you suggest some changes to my text to incorporate this= concept? Thanks, Ethan. From: Maik Seewald (maseewal) > Sent: Monday, February 11, 2019 11:23 PM To: Grossman, Ethan A. >; detnet@= ietf.org Cc: ekr@rtfm.com Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encryption Hello Ethan, Only a few comments: Execution times are essential for flow calculations. On the other hand, to define bounded execution times is challenging. And, does it make sense to use the boundary (value) for calculations? Since this is a new standard, we should recommend agility of crypto algorit= hms in order to address quantum-safe crypto. This especially impacts asymmetric algoritms. Of course, there are implications with symmetric crypto, especially in term= s of key management. But I assume, this won=92t be part of the text=85 Cheers, Maik From: detnet > on b= ehalf of "Grossman, Ethan A." > Date: Tuesday, 12. February 2019 at 06:25 To: "detnet@ietf.org" > Cc: Eric Rescorla > Subject: [Detnet] DetNet Security Draft Proposed Text - Encryption Hi All, I have consolidated the list discussion about the pros and cons of encrypti= on algorithms into the Mitigation-Encryption section of the security draft = (text of the section as it now reads is below). I would like the WG to revi= ew it before I publish it in a new version of the Security draft. Thanks, Ethan (as editor of the DetNet Security draft) -------------------------------------------------------------------- 5. Security Threat Mitigation 5.4. Encryption Description DetNet flows can be forwarded in encrypted form. Related attacks Encryption can be used to mitigate recon attacks (Section 3.2.7). However, = for the DetNet to give differentiated quality of service on a flow-by-flow = basis, it must be able to identify the flows individually. This implies tha= t in a recon attack the attacker may also be able to track individual flows= to learn more about the system. Encryption can also provide traffic origin verification, i.e. to verify tha= t each packet in a DetNet flow is from a verified source, for example as pa= rt of ingress filtering. 5.4.1. Encryption Considerations for DetNet Any time spent on encryption and decryption processing (=93crypto=94) must = be included in the flow latency calculations.. Thus, crypto algorithms used= in a DetNet must have bounded execution times. Some crypto algorithms are symmetric in encode/decode time (such as AES and= SHA-2) and others are asymmetric (such as public key algorithms). There ar= e advantages and disadvantages to the use of either type in a given DetNet = context. Asymmetrical crypto is typically not used in networks on a packet-by-packet= basis due to its computational cost. For example, if only endpoint checks = or checks at a small number of intermediate points are required, one can us= e asymmetric crypto to authenticate distribution or exchange of a secret sy= mmetric crypto key; a successful check based on that key will provide traff= ic origin verification as long as the key is kept secret by the participant= s. Both TLS and IKE (for IPsec) are examples of this for endpoint checks. However, if we use secret symmetrical keys for this purpose we must give th= e key to all relays, which increases the probability of a secret key being = leaked. Also, if any relay is compromised or misbehaving it may inject traf= fic into the flow. Alternatively, asymmetric crypto can provide traffic origin verification at= every intermediate node. For example, a DetNet flow can be associated with= an (asymmetric) keypair, such that the private key is available to the sou= rce of the flow and the public key is distributed with the flow information= , allowing verification at every node for every packet. However, this is mo= re computationally expensive. In either case, origin verification also requires replay detection mechanis= m as part of the security protocol to prevent an attacker from recording an= d resending traffic, e.g., as a denial of service attack on flow forwarding= resources. --_000_D88999B379E2Fmaseewalciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4D9EE820B2168440A2AFA91789FFBC8A@namprd11.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Ethan,

Sorry for being that unspecific. Yes, the worst time must be used.
But this is very much hardware/implementation depending. 

On encryption in general (and addressing Henrik=92s response he sent m= inutes ago), this is typically an end-to-end requirement in many industries= and is typically implemented in the upper layers: 4.5, 8, 9.
In many industries, that might use DetNet for WAN transport, it is not= acceptable to have messages decrypted/encrypted on network nodes. 

Regarding the agility, I had been very unspecific again. Reason, I don= =92t have a good answer ready to propose.
(1) It also depends on the depth we want to address crypto in this dra= ft: prescribing algorithms vs. defining security objectives and controls (c= onfidentiality/secrecy, integrity, =85)?
And I have not yet mentioned the complex area of key management.

The comment reg agility is about the fact that quantum-based computing= will break existing crypto much easier/faster, especially asymmetric algor= ithms.
In order to address this disruptive event, standards already addressin= g quantum-safe crypto in a very simple manner: recommending agility of cryp= to (e.g.: allowing endpoints to pick the best algorithms in a sequence; at = least, not hard-coding things, very simple stuff but helpful).

Hope this is somehow useful=85
But my response is basically boiling down to the question (1).

Cheers,
Maik

From: "Grossman, Ethan A."= ; <eagros@dolby.com>
Date: Tuesday, 12. February 2019 at= 20:10
To: Cisco Employee <maseewal@cisco.com>, "detnet@ietf.org" <detnet@ietf.org>
Cc: Eric Rescorla <ekr@rtfm.com>
Subject: RE: [Detnet] DetNet Securi= ty Draft Proposed Text - Encryption

Hi Maik,

Thanks for these comments.

Regarding =93to define bounded execution times is challenging. An= d, does it make sense to use the boundary (value) for calculations?=94 =96 = if I understand your question correctly, then yes, it does make sense, because end-to-end latency must be bounded so for= any packet processing the worst case time must be used.

Regarding =93we should recommend agility of crypto algorithms in = order to address quantum-safe crypto=94 =96 I don=92t understand exactly th= e implication of this =96 can you suggest some changes to my text to incorporate this concept?

Thanks,

Ethan.

From: Maik Seewald (maseewal) <maseewal@cisco.com>
Sent: Monday, February 11, 2019 11:23 PM
To: Grossman, Ethan A. <eagro= s@dolby.com>; detnet@ietf.org
Cc: ekr@rtfm.com
Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encrypti= on

 

Hello Ethan,

 

Only a few comments: 

 

Execution times are essential for flow calculations. 

On the other hand, to define bounded execution times is challengi= ng.

And, does it make sense to use the boundary (value) for calculati= ons?

 

Since this is a new standard, we should recommend agility of cryp= to algorithms in order to address quantum-safe crypto.

This especially impacts asymmetric algoritms.

 

Of course, there are implications with symmetric crypto, especial= ly in terms of key management.

But I assume, this won=92t be part of the text=85

 

Cheers,

Maik

 

From: detnet <detnet-bounces@ietf.org> on behalf of "Grossman, Ethan A.&qu= ot; <eagros@dolby.com>
Date: Tuesday, 12. February 2019 at 06:25
To: "detnet@ietf.org&quo= t; <detnet@ietf.org>
Cc: Eric Rescorla <ekr@rtfm.com>
Subject: [Detnet] DetNet Security Draft Proposed Text - Encryption

 

Hi All,

I have consolidated the = list discussion about the pros and cons of encryption algorithms into the M= itigation-Encryption section of the security draft (text of the section as = it now reads is below). I would like the WG to review it before I publish it in a new version of the Security d= raft.

Thanks,

Ethan (as editor of the = DetNet Security draft)

------------------------= --------------------------------------------

<= !--[if !supportLists]-->5.    Security Threat Mitigation

<= !--[if !supportLists]-->5.4.      = ;   Encryption

Description

    =            DetNet flows c= an be forwarded in encrypted form.

Related attacks

Encryption can be used t= o mitigate recon attacks (Section 3.2.7). However, for the DetNet to give d= ifferentiated quality of service on a flow-by-flow basis, it must be able t= o identify the flows individually. This implies that in a recon attack the attacker may also be able to track indi= vidual flows to learn more about the system.

Encryption can also prov= ide traffic origin verification, i.e. to verify that each packet in a DetNe= t flow is from a verified source, for example as part of ingress filtering.=

<= !--[if !supportLists]-->5.4.1.     Encryption Considerations for DetNet=

Any time spent on encryp= tion and decryption processing (=93crypto=94) must be included in the flow = latency calculations.. Thus, crypto algorithms used in a DetNet must have b= ounded execution times.

Some crypto algorithms a= re symmetric in encode/decode time (such as AES and SHA-2) and others are a= symmetric (such as public key algorithms). There are advantages and disadva= ntages to the use of either type in a given DetNet context.

Asymmetrical crypto is t= ypically not used in networks on a packet-by-packet basis due to its comput= ational cost. For example, if only endpoint checks or checks at a small num= ber of intermediate points are required, one can use asymmetric crypto to authenticate distribution or exchange of = a secret symmetric crypto key; a successful check based on that key will pr= ovide traffic origin verification as long as the key is kept secret by the = participants.  Both TLS and IKE (for IPsec) are examples of this for endpoint checks.

However, if we use secre= t symmetrical keys for this purpose we must give the key to all relays, whi= ch increases the probability of a secret key being leaked. Also, if any rel= ay is compromised or misbehaving it may inject traffic into the flow.

Alternatively, asymmetri= c crypto can provide traffic origin verification at every intermediate node= . For example, a DetNet flow can be associated with an (asymmetric) keypair= , such that the private key is available to the source of the flow and the public key is distributed with the flow = information, allowing verification at every node for every packet. However,= this is more computationally expensive.

In either case, origin v= erification also requires replay detection mechanism as part of the securit= y protocol to prevent an attacker from recording and resending traffic, e.g= ., as a denial of service attack on flow forwarding resources.

 =

--_000_D88999B379E2Fmaseewalciscocom_-- From nobody Tue Feb 19 19:44:36 2019 Return-Path: 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 6DEE51310F4; Tue, 19 Feb 2019 19:44:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-detnet-architecture@ietf.org, Lou Berger , detnet-chairs@ietf.org, lberger@labn.net, detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155063426136.20704.6779201119170972943.idtracker@ietfa.amsl.com> Date: Tue, 19 Feb 2019 19:44:21 -0800 Archived-At: Subject: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 03:44:24 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-detnet-architecture-11: 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: https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I note that the DETNET WG is explicitly chartered with a work item for the "overall architecture: This work encompasses ... and security aspects". It seems incomplete to specify an architecture for a topic such as deterministic networking without specifically considering what threats are and are not in scope to be protected against. Some easy questions should be whether the system is expected to be robust in the face of an attacker that generates non-DetNet traffic? Or an attacker that generates DetNet traffic in excess of reservations? It can even be a fine engineering goal to produce a solution that only protects against media corruption and hardware crashes and leaves active attacks out of scope, but the actual intended scope of the work needs to be clear. At the other end of the spectrum, protecting against as potent an attacker as a malicious traffic policer is probably a lost cause, especially if the policer is authorized to direct remote nodes to take action to terminate "misbehaving" flows. The referenced draft-ietf-detnet-security is not at a comparable maturity level to this document and also fails to present a clear threat model for the DetNet architecture. (The section entitled "Threat Model" reads as more of a taxonomy of threats than a model for what threats are and are not to be addressed.) It also presents the usage of cryptographic mechanisms as mitigation techniques without provisioning for the prerequisties of such mechanisms (e.g., using HMAC for message integrity protection without mention of infrastructure for distributing the keys for keying the HMAC). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alexey that Informational would (also) be a fine status in which to publish this document. Abstract DetNet operates at the IP layer and delivers service over sub-network technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking (TSN). I don't know what "sub-network technologies" means. (Should I? Is it defined somewhere we can reference?) More generally, is DetNet supposed to be a "sub-layer" and/or "sub-network" that lies between specific layers or classes of layer? Does DetNet itself have component "sub-layers" that provide distinct DetNet functionality? These are good questions to address early on in the document so the reader is familiar with the concepts as they progress through the document. Section 1 DetNet is for networks that are under a single administrative control or within a closed group of administrative control; these include campus-wide networks and private WANs. DetNet is not for large groups of domains such as the Internet. side note: Campus-wide networks at educational institutions are basically guaranteed to have untrusted entities participating in them, just as a backdrop for security considerations. Section 3.1 This mechanism distributes the contents of DetNet flows over multiple paths in time and/or space, so that the loss of some of the paths does need not cause the loss of any The failure models for which this statement is absolutely true as opposed to probabilistically true seem rather unrealistic models of real physical systems. Section 3.2.1.1 The primary means by which DetNet achieves its QoS assurances is to reduce, or even completely eliminate packet loss due to output packet contention within a DetNet node as a cause of packet loss. [...] editing error? Note that App-flows are generally not expected to be responsive to implicit [RFC2914] or explicit congestion notification [RFC3168]. I note that the word "implicit" does not appear in RFC 2914; it may be worth a bit more detailed of a mapping from concept to reference. (This text/reference also appears in Section 4.3.2.) Section 3.2.1.2 In general, users are encouraged to use, instead of, "do this when you get the packet," a combination of: It seems that an architecture would be within its rights to *mandate* such application design, rather than just encourage it. What sorts of exceptions would cause us to not want to mandate this design? Section 3.2.2.2 Please expand SRLG (it is only used once, so the abbreviation itself may not be needed at all). Section 3.2.3 Out-of-order packet delivery can be a side effect of distributing a single flow over multiple paths especially when there is a change from one path to another when combining the flow. [...] nit: comma before "especially". Resource allocation The DetNet forwarding sub-layer provides resource allocation. See Section 4.5. The actual queuing and shaping mechanisms are typically provided by underlying subnet, these can be nit: is this usage of "subnet" common? Also, this comma looks to be a comma splice. closely associated with the means of providing paths for DetNet flows, the path and the resource allocation are conflated in this figure. nit: Hmm, actually, is this comma *also* a comma splice? Operations, Administration, and Maintenance (OAM) leverages in-band and out-of-band signaling that validates whether the service is effectively obtained within QoS constraints. [...] nit: is there a singular/plural mismatch here ("the service"/"service" vs. "effectively within"/"effectively obtained within")? Section 4.1.1 This figure would have helped me a lot several sections earlier. Section 4.1.2 A "Deterministic Network" will be composed of DetNet enabled end systems, DetNet edge nodes, DetNet relay nodes and collectively deliver DetNet services. DetNet relay and edge nodes are Nit: I think this is intended to be: A "Deterministic Network" will be composed of DetNet-enabled end systems, DetNet edge nodes, and DetNet relay nodes, which collectively deliver DetNet services. DetNet relay and edge nodes are Examples of sub-networks include MPLS TE, IEEE 802.1 TSN and OTN. [...] nit: are these sub-networks or protocols used by sub-networks? Distinguishing the function of two DetNet data plane sub-layers, the DetNet service sub-layer and the DetNet forwarding sub-layer, helps to explore and evaluate various combinations of the data plane solutions available, some are illustrated in Figure 4. This nit: this last comma is a comma splice. There are many valid options to create a data plane solution for DetNet traffic by selecting a technology approach for the DetNet service sub-layer and also selecting a technology approach for the DetNet forwarding sub-layer. There are a high number of valid combinations. nit: I think "large number" is more conventional prose. Section 4.3.1 I think I'm confused about how, for these flows that "require the feature", whether that means that the DetNet implementation must provide , or that it is required for the application to have implemented the feature. A mapping (if it makes sense) to the categorization of end systems in Section 4.2.1 would be a big help. Section 4.3.2 Asynchronous DetNet flows are characterized by: o A maximum packet size; o An observation interval; and o A maximum number of transmissions during that observation interval. Is there necessarily only a single tier of observation interval/rate? (E.g., could there be a burst cap in a small interval and then a lower overall baseline rate over large intervals?) That is, while any useful application is written to expect a certain number of lost packets, the real-time applications of interest to DetNet demand that the loss of data due to the network is a rare event. (I might even go with "vanishingly rare".) Section 4.4.1 (Is there a standard reference for "Northbound"? I know we're all used to it, but it's probably best to have a reference if we can.) Section 4.4.2 The deterministic sequence can typically be more complex than a direct sequence and include redundancy path, with one or more packet replication and elimination points. [...] nit: "redundancy paths", plural? Section 4.8 How does *provisioning* require knowledge of *dynamic* state? Section 4.9 Does aggregation like this pose a risk of all the aggregatees getting affected when one exceeds their allocation substantially (so as to also cause the aggregate to exceed the aggregate's allocation)? Section 6 The ability for an attacker to use QoS markings as part of traffic correlation/inspection is not new with DetNet, but is probably still worth mentioning explicitly. From nobody Wed Feb 20 05:05:53 2019 Return-Path: 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 A668E130DDA; Wed, 20 Feb 2019 05:05:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-detnet-architecture@ietf.org, Lou Berger , detnet-chairs@ietf.org, lberger@labn.net, detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155066795164.31466.275999283339131275.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2019 05:05:51 -0800 Archived-At: Subject: [Detnet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-detnet-architecture-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 13:05:52 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-detnet-architecture-11: 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: https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for addressing the tsv-art review comments (and big thanks to Michael and David!) and all the work done so far! I think the document is in good shape and I only have one minor comment that I would like to see addressed/more explicitly spelled out. However, this should be done quickly with potentially 2-3 small changes in the draft. See below. Given that DetNet traffic is often assumed to be not congestion controlled, it is important that there is also some network function that makes sure the source traffic stays within the requested bandwidth limit in-order to protect non-Detnet traffic. This is to some extended discussed in section 3.3.2 but I think it should be more clearly spelled out that this would require a rate limiting function at each DetNet source/relay (tunnel ingress). Currently sec 3.3.2 says: "Filters and policers should be used in a DetNet network to detect if DetNet packets are received on the wrong interface, or at the wrong time, or in too great a volume." However, maybe this case of limiting non-congestion controlled traffic (in case the source in not keeping to the limits on purpose/in order to cheat, because it couldn't estimate the needed bandwidth requirement an better, or due to timely fluctuations) could be explained more clearing and the respective requirement to implement rate limiting could be state separately and more strongly...? One related comment on this sentence in Sec 3.1: "As DetNet provides allocated resources (including provisioned capacity) to DetNet flows the use of transport layer congestion control [RFC2914] by App-flows is explicitly not required." I guess congestion control should still be a requirement if the App-flow also passes not-DetNet-aware segments of the path, e.g. maybe the first hop. Usually use of congestion control for application limited flows is also not a problem if sufficient bandwidth is available. Also note that, as I stated above, the important part for not requiring congestion control is actually not only that resources are allocated but also that rate limiting is in place to make sure resources usage cannot be exceeded above the reserved allocation. Maybe this sentence could also be further clarified in the draft...? And then one more small comment that is also related. Sec 3.2.2.2 says: "If packet replication and elimination is used over paths with resource allocation (Section 3.2.1), ..." My assumption was that all DetNet traffic is send over pre-allocated resources...? If that is not true that has implication on congestion control and needs some additional considerations. Can you please confirm that and maybe clarify in the draft! Thanks! ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alexey and Benjamin that this document should be informational. Informational documents can also have IETF consensus, so that cannot be the reason to go for PS. However, this document does not specify a protocol or any requirements that are mandatory to implement for interoperability and therefore should not be PS. From nobody Wed Feb 20 06:43:40 2019 Return-Path: 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 7B169130E8E for ; Wed, 20 Feb 2019 06:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (768-bit key) reason="fail (body has been altered)" header.d=labn.net 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 DBk81bLfMk9J for ; Wed, 20 Feb 2019 06:43:28 -0800 (PST) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B2B130E89 for ; Wed, 20 Feb 2019 06:43:23 -0800 (PST) Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 7FB2F80602184 for ; Wed, 20 Feb 2019 07:33:36 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id wSwKggBrsmds9wSwKgSoSE; Wed, 20 Feb 2019 07:33:36 -0700 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=dVZQWj5DrMTvgdwEH+Tmm7OHAtftsbqk5W5DP9NlxzA=; b=uEv+WQOC9zDXdoNSITipR849bV FlFabii2qcUMmMcuGnjNooH3jz35fSuIKyUsJU5LubBDznHkMJ2JWodiwinnWMhRoUYHo4bO/D6IO CGXLXxeD29ppY5dhj+agZ4S9/; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:46092 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gwSwK-0006Ph-2l; Wed, 20 Feb 2019 07:33:36 -0700 To: Benjamin Kaduk , The IESG Cc: draft-ietf-detnet-architecture@ietf.org, detnet@ietf.org, detnet-chairs@ietf.org References: <155063426136.20704.6779201119170972943.idtracker@ietfa.amsl.com> From: Lou Berger Message-ID: Date: Wed, 20 Feb 2019 09:33:34 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <155063426136.20704.6779201119170972943.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 72.66.11.201 X-Source-L: No X-Exim-ID: 1gwSwK-0006Ph-2l X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:46092 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 14:43:35 -0000 Hi Benjamin, I'm responding as doc shepherd (and chair). Thank you for your comments.  Please see below for specific responses. On 2/19/2019 10:44 PM, Benjamin Kaduk wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-detnet-architecture-11: 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: > https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I note that the DETNET WG is explicitly chartered with a work item for the > "overall architecture: This work encompasses ... and security aspects". > It seems incomplete to specify an architecture for a topic such as > deterministic networking without specifically considering what threats are > and are not in scope to be protected against. The working group certainly recognizes that security is an important topic and necessary part of the work. The WG's  approach to ensure that this significant topic is sufficiently covered is to have a  document dedicated to the topic.  As you note below this work,  draft-ietf-detnet-security, is not at the same level maturity - so please stay tuned.  Of course, the WG would welcome any input on this security draft now or even a full early-review or security area advisor. (We have one from the transport area.) > Some easy questions should > be whether the system is expected to be robust in the face of an attacker > that generates non-DetNet traffic? Or an attacker that generates DetNet > traffic in excess of reservations? It can even be a fine engineering goal > to produce a solution that only protects against media corruption and > hardware crashes and leaves active attacks out of scope, but the actual > intended scope of the work needs to be clear. At the other end of the > spectrum, protecting against as potent an attacker as a malicious traffic > policer is probably a lost cause, especially if the policer is authorized > to direct remote nodes to take action to terminate "misbehaving" flows. > The referenced draft-ietf-detnet-security is not at a comparable maturity > level to this document and also fails to present a clear threat model for > the DetNet architecture. (The section entitled "Threat Model" reads as > more of a taxonomy of threats than a model for what threats are and are not > to be addressed.) It also presents the usage of cryptographic mechanisms > as mitigation techniques without provisioning for the prerequisties of such > mechanisms (e.g., using HMAC for message integrity protection without > mention of infrastructure for distributing the keys for keying the HMAC). > These are all great input for draft-ietf-detnet-security - I'll touch with authors to ensure that they are aware of your comments. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Alexey that Informational would (also) be a fine status in > which to publish this document. I defer to the IESG and our AD. I think the authors can address/respond to the remaining comments. ... Thanks, Lou From nobody Wed Feb 20 06:54:52 2019 Return-Path: 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 10C97130E8E; Wed, 20 Feb 2019 06:54:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-detnet-architecture@ietf.org, Lou Berger , detnet-chairs@ietf.org, lberger@labn.net, detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155067447797.31337.768983002923056061.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2019 06:54:37 -0800 Archived-At: Subject: [Detnet] Alissa Cooper's Discuss on draft-ietf-detnet-architecture-11: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 14:54:43 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-detnet-architecture-11: 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: https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- = Section 6 = "DetNet is provides a Quality of Service (QoS), and as such, does not directly raise any new privacy considerations." This seems like a false statement given the possibility that DetNet may require novel flow IDs and OAM tags that create additional identification and correlation risk beyond existing fields used to support QoS today. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Benjamin's DISCUSS. I agree with others that this document should be informational. = Section 3.1 = "There are, of course, simpler methods available (and employed, today) to achieve levels of latency and packet loss that are satisfactory for many applications." I think this paragraph would make more sense if it said "specific levels of latency and packet loss for particular applications." A lot of applications have satisfactory performance without any of the methods/techniques described. "Prioritization and over-provisioning is one such technique." It seems these are two techniques, not one. = Section 3.2.1.2 = s/sensitive/time-sensitive/ I can't parse this sentence: 'In general, users are encouraged to use, instead of, "do this when you get the packet," a combination of: o Sub-microsecond time synchronization among all source and destination end systems, and o Time-of-execution fields in the application packets.' = Section 3.2.2.2 = s/ Either of these functions/ Any of these functions/ "Providing sequencing information to the packets of a DetNet compound flow. This may be done by adding a sequence number or time stamp as part of DetNet, or may be inherent in the packet, e.g., in a higher layer protocol, or associated to other physical properties such as the precise time (and radio channel) of reception of the packet." How do multiple connected DetNet nodes know which fields they are supposed to use as the packet sequence number? = Section 3.3.1 = "the highest-priority non-DetNet packet is also ensured a worst-case latency." --> Did you mean "ensured less than or equal to a worst-case latency"? = Section 4.3.2 = If applications need to be altered to be run over DetNet, or if they need to be DetNet-aware, it would be useful to state that explicitly up front somewhere in this document. This is sort of implied in this section but it's not clear. = Section 6 = "However, the requirement for every (or almost every) node along the path of a DetNet flow to identify DetNet flows may present an additional attack surface for privacy, should the DetNet paradigm be found useful in broader environments." I'm not sure what is meant by "broader environments." Is the implication that flow identification doesn't present a privacy risk within a single administrative domain? I don't think that is always true. From nobody Wed Feb 20 06:58:38 2019 Return-Path: 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 3E49E129741; Wed, 20 Feb 2019 06:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=QZJkC9IS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dQqbuUbC 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 Kb8GAuwllLhK; Wed, 20 Feb 2019 06:58:28 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC69127AC2; Wed, 20 Feb 2019 06:58:27 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 52292331D; Wed, 20 Feb 2019 09:58:26 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 20 Feb 2019 09:58:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=D yN8lUBuBuNAnxNeXmuQDQVcsbIFtKwRnsDnNi4Z9r4=; b=QZJkC9ISgpRm4cddH rhvKBoYMX1N1bQO0CJ2NJv81+7kcHBr4LwwMTrT8VmfLGv/3Qa3NMenUSdh3BXMx F5/46DH8QDsjkYBgRkzJ3oocSLtK6MOeoiD2llfyHi46+49185Z2Rj2Z2qOvqjvk GZtYOskbCVYcMFu8gEqfWUXvPfAlExKcEBka0HeuVRrxu+lhUCkDbhoGBpQJRAJl EtxD+nEHTZ7aZXbUFzG0N28yHTQrWY9tuOBEuBAdcafKHUeS3L/N3SNjlMwZqM1B +Fvwz1QexaiHa5nhc2qOiQfAtkJ0dA5EGnxR7vUW7HqQ1fmJPLIf6B8JDIbtXs1i m8y5w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=DyN8lUBuBuNAnxNeXmuQDQVcsbIFtKwRnsDnNi4Z9 r4=; b=dQqbuUbCmRFrwfIkSjy0bAEnEbY5U0nullLHWDoN/AbQNdMEaABkH9EZg 2TRg4SI3RwjabjmLvIlZ4vwc7cz+b9lrzTiUBXxTx1v5eS9mVdpRD3RCOWox1qq9 DHNvlio2MwSDPHp3fan+2XinOFjNmh82Xlafv0EMfJJZsOtm3TM4DXYi2zMwotV7 vNx4B+yU09gdKEVUqIwzoxS7aPFx+tSWtGwS2A31kLMHjuTY0EUkisyymQNXP4IO IpSur+6ewdoiYAGdH9PZwR0qwXATKPiq7EeqeK4I7yc/y2Ypb89/ZrVNB17NFYXr sk3PpoDIIUbkef5zw39XMzacbiIhg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrtdeigdejtdculddtuddrgedtledrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrledtnecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-vpn3-946.cisco.com (unknown [173.38.117.90]) by mail.messagingengine.com (Postfix) with ESMTPA id 720AF1026E; Wed, 20 Feb 2019 09:58:24 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <154957437026.5554.4163956192901377898@ietfa.amsl.com> Date: Wed, 20 Feb 2019 06:58:22 -0800 Cc: IETF Gen-ART , draft-ietf-detnet-architecture.all@ietf.org, detnet@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154957437026.5554.4163956192901377898@ietfa.amsl.com> To: Joel Halpern X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Detnet] [Gen-art] Genart telechat review of draft-ietf-detnet-architecture-11 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 14:58:30 -0000 Joel, thanks for your reviews of this document. Authors, thanks for your = responses. I entered a DISCUSS ballot based on one bit in Section 6. Alissa > On Feb 7, 2019, at 1:19 PM, Joel Halpern wrote: >=20 > Reviewer: Joel Halpern > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-detnet-architecture-11 > Reviewer: Joel Halpern > Review Date: 2019-02-07 > IETF LC End Date: 2018-10-03 > IESG Telechat date: 2019-02-21 >=20 > Summary: This Internet Draft is ready for publication as a Proposed = Standard >=20 > Major issues: N/A >=20 > Minor issues: N/A >=20 > Nits/editorial comments: N/A >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Feb 20 07:04:54 2019 Return-Path: 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 0FA12130E13 for ; Wed, 20 Feb 2019 07:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 zY4LfoYsretk for ; Wed, 20 Feb 2019 07:04:50 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7762C130E09 for ; Wed, 20 Feb 2019 07:04:50 -0800 (PST) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 18B8D1ACD2A for ; Wed, 20 Feb 2019 07:46:37 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id wT8ugEuLrD8RpwT8ugdTkp; Wed, 20 Feb 2019 07:46:37 -0700 X-Authority-Reason: nr=8 X-Authority-Analysis: $(_cmae_reason DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=tIjlET0Cg5Gi8CthFB7yvfVR7TciWcDCeEpKG+irBBw=; b=xj4A7gv/aEbB/bRAq68rOV+XDg w9/tIbi2VZPyT2WxbNoCQMX4AnlFl0tw4fAGkGwhkC2D2rFQtfM6gZy3kSBdx9EzY7PWIlsG3/BZX qVxeny/SwVdg3enNmOnzULOoU; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:48688 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gwT8u-000A6i-5R; Wed, 20 Feb 2019 07:46:36 -0700 To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , The IESG Cc: draft-ietf-detnet-architecture@ietf.org, detnet@ietf.org, detnet-chairs@ietf.org References: <155066795164.31466.275999283339131275.idtracker@ietfa.amsl.com> From: Lou Berger Message-ID: <77e87eca-07df-99eb-9edb-7f6f18913dfd@labn.net> Date: Wed, 20 Feb 2019 09:46:29 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <155066795164.31466.275999283339131275.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 72.66.11.201 X-Source-L: No X-Exim-ID: 1gwT8u-000A6i-5R X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:48688 X-Source-Auth: lberger@labn.net X-Email-Count: 9 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Detnet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-detnet-architecture-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 15:04:52 -0000 Hi Mirja, I'm responding as doc shepherd (and chair). Thank you for your comments.  Please see below for specific responses. On 2/20/2019 8:05 AM, Mirja Kühlewind wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-detnet-architecture-11: 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: > https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for addressing the tsv-art review comments (and big thanks to Michael > and David!) and all the work done so far! I think the document is in good shape > and I only have one minor comment that I would like to see addressed/more > explicitly spelled out. However, this should be done quickly with potentially > 2-3 small changes in the draft. See below. The input from Michael and David certainly led to a much improved document.  If you can help the authors with some specific text suggestions that would be most helpful. > Given that DetNet traffic is often assumed to be not congestion controlled, it > is important that there is also some network function that makes sure the > source traffic stays within the requested bandwidth limit in-order to protect > non-Detnet traffic. This is to some extended discussed in section 3.3.2 but I > think it should be more clearly spelled out that this would require a rate > limiting function at each DetNet source/relay (tunnel ingress). Currently sec > 3.3.2 says: > > "Filters and policers should be used in a DetNet network to > detect if DetNet packets are received on the wrong interface, or at > the wrong time, or in too great a volume." > > However, maybe this case of limiting non-congestion controlled traffic (in case > the source in not keeping to the limits on purpose/in order to cheat, because > it couldn't estimate the needed bandwidth requirement an better, or due to > timely fluctuations) could be explained more clearing and the respective > requirement to implement rate limiting could be state separately and more > strongly...? Section 3.2.1.1 days: Ensuring adequate buffering requires, in turn, that the source, and every DetNet node along the path to the destination (or nearly every node, see Section 4.3.3) be careful to regulate its output to not exceed the data rate for any DetNet flow, except for brief periods when making up for interfering traffic. Any packet sent ahead of its time potentially adds to the number of buffers required by the next hop DetNet node and may thus exceed the resources allocated for a particular DetNet flow. Section 3.3.1 also says: Starvation of non-DetNet traffic must be avoided, e.g., by traffic policing functions (e.g., [RFC2475]). Thus, the net effect of the presence of DetNet flows in a network on the non-DetNet flows is primarily a reduction in the available bandwidth. Is this not sufficient?  If not, can you suggest some additional language? > > One related comment on this sentence in Sec 3.1: > > "As DetNet provides allocated resources (including provisioned capacity) > to DetNet flows the use of transport layer congestion control > [RFC2914] by App-flows is explicitly not required." > > I guess congestion control should still be a requirement if the App-flow also > passes not-DetNet-aware segments of the path, e.g. maybe the first hop. This point is addressed in section 3.3.2 Note that the sending of App-flows that do not use transport layer congestion control per [RFC2914] into a network that is not provisioned to handle such DetNet traffic has to be treated as a fault and prevented. > Usually > use of congestion control for application limited flows is also not a problem > if sufficient bandwidth is available. Also note that, as I stated above, the > important part for not requiring congestion control is actually not only that > resources are allocated but also that rate limiting is in place to make sure > resources usage cannot be exceeded above the reserved allocation. Maybe this > sentence could also be further clarified in the draft...? Is the above sufficient?  If not, can you suggest some additional language? > And then one more small comment that is also related. Sec 3.2.2.2 says: > > "If packet replication and elimination is used over paths with > resource allocation (Section 3.2.1), ..." > > My assumption was that all DetNet traffic is send over pre-allocated > resources...? If that is not true that has implication on congestion control > and needs some additional considerations. Can you please confirm that and maybe > clarify in the draft! Thanks! The intent was to cover sending over non-pre-allocated paths as a fault case, and cover it in section 3.3.2. In addition to the previously quoted text, the section also says: PRF generated DetNet member flows also need to be treated as not using transport layer congestion control even if the original App-flow supports transport layer congestion control because PREOF can remove congestion indications at the PEF and thereby hide such indications (e.g., drops, ECN markings, increased latency) from end systems. Does this address your concern? > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Alexey and Benjamin that this document should be informational. > Informational documents can also have IETF consensus, so that cannot be the > reason to go for PS. However, this document does not specify a protocol or any > requirements that are mandatory to implement for interoperability and therefore > should not be PS. > I defer to the IESG and AD on this... Thank you! Lou > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Wed Feb 20 07:21:56 2019 Return-Path: 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 3C0CC12F1AC for ; Wed, 20 Feb 2019 07:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 EQKVyjI6Xupd for ; Wed, 20 Feb 2019 07:21:54 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E171277D2 for ; Wed, 20 Feb 2019 07:21:54 -0800 (PST) Received: from cmgw14.unifiedlayer.com (unknown [10.9.0.14]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 81B9C14400F for ; Wed, 20 Feb 2019 08:17:16 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id wTcagSzjdXFO5wTcagCVqn; Wed, 20 Feb 2019 08:17:16 -0700 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=YTa7IC7c3UPVkGVJLblqJRWn691d0IYgBMQnapalCTY=; b=LW/cfBchWedbd5F+iaiKIa+LA7 R6ryVyS6ms8x9qew9U1osow9yoF2svLLXy4d9fJie2mqLqlj9wHzJzsKj96W+CzE0s/SA1r48VKl4 qB7vXzuarv15NNucS/U9SX+Xb; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:53846 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gwTca-000KUJ-48; Wed, 20 Feb 2019 08:17:16 -0700 To: Alissa Cooper , The IESG Cc: draft-ietf-detnet-architecture@ietf.org, detnet-chairs@ietf.org, detnet@ietf.org References: <155067447797.31337.768983002923056061.idtracker@ietfa.amsl.com> From: Lou Berger Message-ID: <40b28261-5f04-7fcd-4f4f-ce243f32a808@labn.net> Date: Wed, 20 Feb 2019 10:17:14 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <155067447797.31337.768983002923056061.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 72.66.11.201 X-Source-L: No X-Exim-ID: 1gwTca-000KUJ-48 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:53846 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Detnet] Alissa Cooper's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 15:21:55 -0000 Hi Alissa, Thanks for the comments - see below. On 2/20/2019 9:54 AM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-detnet-architecture-11: 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: > https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > = Section 6 = > > "DetNet is provides a Quality of Service (QoS), and as such, does not > directly raise any new privacy considerations." > > This seems like a false statement given the possibility that DetNet may require > novel flow IDs and OAM tags that create additional identification and > correlation risk beyond existing fields used to support QoS today. Based on the other work in the WG, I think "is not expected" is more accurate than "does not". This is based on the WG solutions for the DetNet data plane using existing IP (v4 or 6) headers or MPLS labels for flow identification. Would changing to "is not expected" address your concern? Thanks, Lou From nobody Wed Feb 20 07:25:44 2019 Return-Path: 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 301D1130E9E; Wed, 20 Feb 2019 07:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=i9LlwvcG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nplWrK6b 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 Gcf77QeW40NO; Wed, 20 Feb 2019 07:25:26 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40B08130E85; Wed, 20 Feb 2019 07:25:26 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 12B8F3355; Wed, 20 Feb 2019 10:25:25 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 20 Feb 2019 10:25:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm2; bh=Bp6D8JuhSecgUCUKxNDhCgh xVlXyYFfB1pvRP225PWk=; b=i9LlwvcGfbTf5Rj16SY0buXl05p6wCMJMezrOuA J5q4h0lo8Jxm2f3C3i1sJRwH6vBZFuUOKpQLhyzGj+Yu9jCRwJcPNf8Jbv+dyCBR 5QvrqdmWsrlSHd3bMwjViyccQM9jR/vrxV5ylWzz2PHZWcTdF4TkHJDH41KeBfr4 lIoC/fbRmTjeyOcIKnIwELAUiu0H50Qyc4zT2oUCeC1rjq7gFNBKbf1YxdVE9TH/ goNiEySY87BZvdNYSnY0yocQiqqb3cniFBjiQChf1XXPOefh1qKqGf/yS7aw1zA2 tTLUWZIhp4yDP69KW0frEhqFWVnS1ZI4HYEF7xI34/K6D6w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Bp6D8J uhSecgUCUKxNDhCghxVlXyYFfB1pvRP225PWk=; b=nplWrK6bQrtJHfADeY7aHH siJEW+YhUcU0g9A+LAEXH+28PaRfV2GA+TzEhujvn14voSpR6CYB2dnWAK7gG1BQ jATIp/rFLgmYeYqX5+K7npsA9Qzgn7TjnjLH3RFMfqxKuuYFCIe3rGRlQ7Fm7wq7 RN/EnbjMsC4G0YORgcG8r3AGTK46iA8Lkr9azk2NEfD7nAzhdtZjqNS72fBIqoJf gpI3vAxnEiHcQM0SwM6j6rAzujvHdeQqgrQknkSWtl1bdza2iTrSVTAbgtxVFj48 HbDHwEwTrUgZV4isw4/zFFqtBVzZiE388C2Xh56nXsoRh6/O7vNITriO9aJAurhQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrtdeigdejieculddtuddrgedtledrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdeltdenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from rtp-vpn3-946.cisco.com (unknown [173.38.117.90]) by mail.messagingengine.com (Postfix) with ESMTPA id 02F19E44D4; Wed, 20 Feb 2019 10:25:22 -0500 (EST) From: Alissa Cooper Message-Id: <1AA376D8-DE94-4FAF-B9D2-CC4E155CEC85@cooperw.in> Content-Type: multipart/alternative; boundary="Apple-Mail=_42D59460-C6A2-4FF4-9513-6B896CE2E96B" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 20 Feb 2019 07:25:21 -0800 In-Reply-To: <40b28261-5f04-7fcd-4f4f-ce243f32a808@labn.net> Cc: The IESG , draft-ietf-detnet-architecture@ietf.org, detnet@ietf.org, detnet-chairs@ietf.org To: Lou Berger References: <155067447797.31337.768983002923056061.idtracker@ietfa.amsl.com> <40b28261-5f04-7fcd-4f4f-ce243f32a808@labn.net> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Detnet] Alissa Cooper's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 15:25:35 -0000 --Apple-Mail=_42D59460-C6A2-4FF4-9513-6B896CE2E96B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 20, 2019, at 7:17 AM, Lou Berger wrote: >=20 > Hi Alissa, >=20 > Thanks for the comments - see below. >=20 > On 2/20/2019 9:54 AM, Alissa Cooper wrote: >> Alissa Cooper has entered the following ballot position for >> draft-ietf-detnet-architecture-11: Discuss >>=20 >> 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.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> =3D Section 6 =3D >>=20 >> "DetNet is provides a Quality of Service (QoS), and as such, does not >> directly raise any new privacy considerations." >>=20 >> This seems like a false statement given the possibility that DetNet = may require >> novel flow IDs and OAM tags that create additional identification and >> correlation risk beyond existing fields used to support QoS today. >=20 > Based on the other work in the WG, I think "is not expected" is more = accurate than "does not". This is based on the WG solutions for the = DetNet data plane using existing IP (v4 or 6) headers or MPLS labels for = flow identification. If that is the case then the references to new flow IDs and OAM tags = should be removed from the architecture. >=20 > Would changing to "is not expected" address your concern? Combined with the above removals, that would work for me. Thanks, Alissa >=20 > Thanks, >=20 > Lou --Apple-Mail=_42D59460-C6A2-4FF4-9513-6B896CE2E96B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Feb 20, 2019, at 7:17 AM, Lou Berger <lberger@labn.net> = wrote:

Hi Alissa,

Thanks for the comments - see = below.

On 2/20/2019 = 9:54 AM, Alissa Cooper wrote:
Alissa Cooper has entered the = following ballot position for
draft-ietf-detnet-architecture-11: 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.htmlfor more information about IESG DISCUSS and COMMENT = positions.


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



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

=3D Section 6 =3D

"DetNet is provides a Quality of Service (QoS), and as such, = does not
   directly raise any new privacy = considerations."

This seems like a false = statement given the possibility that DetNet may require
novel flow IDs and OAM tags that create additional = identification and
correlation risk beyond existing fields = used to support QoS today.

Based on the other work in the = WG, I think "is not expected" is more accurate than "does not". This is = based on the WG solutions for the DetNet data plane using existing IP = (v4 or 6) headers or MPLS labels for flow identification.

If that is = the case then the references to new flow IDs and OAM tags should be = removed from the architecture.


Would changing to "is not expected" address your = concern?

Combined with the above removals, that would work = for me.

Thanks,
Alissa


Thanks,

Lou

= --Apple-Mail=_42D59460-C6A2-4FF4-9513-6B896CE2E96B-- From nobody Wed Feb 20 07:56:55 2019 Return-Path: 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 2EA8F127AC2; Wed, 20 Feb 2019 07:56:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-detnet-architecture@ietf.org, Lou Berger , detnet-chairs@ietf.org, detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155067820715.31361.3746519237969586434.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2019 07:56:47 -0800 Archived-At: Subject: [Detnet] Alvaro Retana's Discuss on draft-ietf-detnet-architecture-11: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 15:56:47 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-detnet-architecture-11: 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: https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support Mirja's and Alissa's DISCUSSes...and have a related set of concerns about the coexistence with non-DetNet traffic and privacy: §3.3.1 talks about what I think is a hard to achieve balance between coexisting with non-DetNet traffic and keeping that traffic from disrupting DetNet flows. Because of the constraints, the intent of prioritizing DetNet flows is clear (and that is ok), but that may result in starvation of non-DetNet traffic...even if the text does explicitly say that it "must be avoided". I would like to see the potential case of starving non-DetNet traffic called out somewhere. I'm looking for something similar to the first paragraph in §5, but focused on the non-DetNet traffic. Related to the above is the fact that the identification of flows could be used to specifically *not* include some of them as DetNet flows. This is a variation of the concern outlined in §6, but applied to non-DetNet flows, with the potential starvation mentioned above. Again, I would like to at least see some discussion of this risk. The use case and problem statement documents outline specific applications that may not have non-DetNet traffic, and the Introduction supports that. However, the architecture described in this document may be used in more general networks to provide guarantees to specific traffic... IOW, even if the intention is there, there is no guarantee that DetNet will only be used in the expected use cases. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with and support Benjamin's DISCUSS -- also, I think that draft-ietf-detnet-security should be a Normative reference. I also agree that Informational may be a better status. [nit] s/sub-layer at which A DetNet service/sub-layer at which a DetNet service [nit] Expand SRLG. From nobody Wed Feb 20 08:03:23 2019 Return-Path: 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 38FE012D826 for ; Wed, 20 Feb 2019 08:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 mJlg1KzPR4qj for ; Wed, 20 Feb 2019 08:03:19 -0800 (PST) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92CBE12F19D for ; Wed, 20 Feb 2019 08:03:12 -0800 (PST) Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id 0F962411CB for ; Wed, 20 Feb 2019 08:39:42 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id wTyHgh6gCmds9wTyHgTiqa; Wed, 20 Feb 2019 08:39:42 -0700 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=biyJgNhai/3qguNSBWP9mSxu+vJ6ou/im/kGbrJDfoA=; b=JyvoFQDRunaemWV+m4nB7Fs3gN w8JisAcxinvAszWws6V7OkWOfVLCGp2m1+HI74WafhLxvhaqQRwgGtGGE+YrxS0abOgGmM6SiXsg9 UZWAqmu0GEdSsDh/JeavQfkwF; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:56652 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gwTyH-000Rmq-Hx; Wed, 20 Feb 2019 08:39:41 -0700 To: Alissa Cooper Cc: draft-ietf-detnet-architecture@ietf.org, detnet@ietf.org, The IESG , detnet-chairs@ietf.org References: <155067447797.31337.768983002923056061.idtracker@ietfa.amsl.com> <40b28261-5f04-7fcd-4f4f-ce243f32a808@labn.net> <1AA376D8-DE94-4FAF-B9D2-CC4E155CEC85@cooperw.in> From: Lou Berger Message-ID: Date: Wed, 20 Feb 2019 10:39:40 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <1AA376D8-DE94-4FAF-B9D2-CC4E155CEC85@cooperw.in> Content-Type: multipart/alternative; boundary="------------EE421D4EFAE6835F7E73AE8B" Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 72.66.11.201 X-Source-L: No X-Exim-ID: 1gwTyH-000Rmq-Hx X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:56652 X-Source-Auth: lberger@labn.net X-Email-Count: 8 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Org: HG=bhcustomer;ORG=bluehost; X-Local-Domain: yes Archived-At: Subject: Re: [Detnet] Alissa Cooper's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 16:03:21 -0000 This is a multi-part message in MIME format. --------------EE421D4EFAE6835F7E73AE8B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 2/20/2019 10:25 AM, Alissa Cooper wrote: > > >> On Feb 20, 2019, at 7:17 AM, Lou Berger > > wrote: >> >> Hi Alissa, >> >> Thanks for the comments - see below. >> >> On 2/20/2019 9:54 AM, Alissa Cooper wrote: >>> Alissa Cooper has entered the following ballot position for >>> draft-ietf-detnet-architecture-11: 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: >>> https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> = Section 6 = >>> >>> "DetNet is provides a Quality of Service (QoS), and as such, does not >>> directly raise any new privacy considerations." >>> >>> This seems like a false statement given the possibility that DetNet >>> may require >>> novel flow IDs and OAM tags that create additional identification and >>> correlation risk beyond existing fields used to support QoS today. >> >> Based on the other work in the WG, I think "is not expected" is more >> accurate than "does not". This is based on the WG solutions for the >> DetNet data plane using existing IP (v4 or 6) headers or MPLS labels >> for flow identification. > > If that is the case then the references to new flow IDs and OAM tags > should be removed from the architecture. sounds reasonable. Can you point to the specific offending text? Thanks, Lou > >> >> Would changing to "is not expected" address your concern? > > Combined with the above removals, that would work for me. > > Thanks, > Alissa > >> >> Thanks, >> >> Lou > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet --------------EE421D4EFAE6835F7E73AE8B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit


On 2/20/2019 10:25 AM, Alissa Cooper wrote:


On Feb 20, 2019, at 7:17 AM, Lou Berger <lberger@labn.net> wrote:

Hi Alissa,

Thanks for the comments - see below.

On 2/20/2019 9:54 AM, Alissa Cooper wrote:
Alissa Cooper has entered the following ballot position for
draft-ietf-detnet-architecture-11: 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:
https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

= Section 6 =

"DetNet is provides a Quality of Service (QoS), and as such, does not
directly raise any new privacy considerations."

This seems like a false statement given the possibility that DetNet may require
novel flow IDs and OAM tags that create additional identification and
correlation risk beyond existing fields used to support QoS today.

Based on the other work in the WG, I think "is not expected" is more accurate than "does not". This is based on the WG solutions for the DetNet data plane using existing IP (v4 or 6) headers or MPLS labels for flow identification.

If that is the case then the references to new flow IDs and OAM tags should be removed from the architecture.

sounds reasonable. Can you point to the specific offending text?

Thanks,

Lou



Would changing to "is not expected" address your concern?

Combined with the above removals, that would work for me.

Thanks,
Alissa


Thanks,

Lou


_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet
--------------EE421D4EFAE6835F7E73AE8B-- From nobody Wed Feb 20 08:06:49 2019 Return-Path: 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 5BB571295EC; Wed, 20 Feb 2019 08:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 ES9NT-y6IE6I; Wed, 20 Feb 2019 08:06:29 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 B6533128B01; Wed, 20 Feb 2019 08:06:29 -0800 (PST) Received: from 200116b82c6eb300094777de67d06586.dip.versatel-1u1.de ([2001:16b8:2c6e:b300:947:77de:67d0:6586]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gwUOA-0000n9-Q5; Wed, 20 Feb 2019 17:06:27 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <77e87eca-07df-99eb-9edb-7f6f18913dfd@labn.net> Date: Wed, 20 Feb 2019 17:06:24 +0100 Cc: The IESG , draft-ietf-detnet-architecture@ietf.org, detnet@ietf.org, detnet-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5AF7514B-B8C9-48E5-B1F4-BF2139EB128A@kuehlewind.net> References: <155066795164.31466.275999283339131275.idtracker@ietfa.amsl.com> <77e87eca-07df-99eb-9edb-7f6f18913dfd@labn.net> To: Lou Berger X-Mailer: Apple Mail (2.3445.9.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1550678789;b484e300; X-HE-SMSGID: 1gwUOA-0000n9-Q5 Archived-At: Subject: Re: [Detnet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-detnet-architecture-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 16:06:35 -0000 Hi Lou, I=E2=80=99m happy to see that my concerns seem to be cover. So maybe = this is mostly a point about wording. Please see below. > Am 20.02.2019 um 15:46 schrieb Lou Berger : >=20 > Hi Mirja, >=20 > I'm responding as doc shepherd (and chair). Thank you for your = comments. Please see below for specific responses. >=20 > On 2/20/2019 8:05 AM, Mirja K=C3=BChlewind wrote: >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-detnet-architecture-11: Discuss >>=20 >> 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.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> Thanks for addressing the tsv-art review comments (and big thanks to = Michael >> and David!) and all the work done so far! I think the document is in = good shape >> and I only have one minor comment that I would like to see = addressed/more >> explicitly spelled out. However, this should be done quickly with = potentially >> 2-3 small changes in the draft. See below. >=20 > The input from Michael and David certainly led to a much improved = document. If you can help the authors with some specific text = suggestions that would be most helpful. >=20 >=20 >> Given that DetNet traffic is often assumed to be not congestion = controlled, it >> is important that there is also some network function that makes sure = the >> source traffic stays within the requested bandwidth limit in-order to = protect >> non-Detnet traffic. This is to some extended discussed in section = 3.3.2 but I >> think it should be more clearly spelled out that this would require a = rate >> limiting function at each DetNet source/relay (tunnel ingress). = Currently sec >> 3.3.2 says: >>=20 >> "Filters and policers should be used in a DetNet network to >> detect if DetNet packets are received on the wrong interface, or = at >> the wrong time, or in too great a volume." >>=20 >> However, maybe this case of limiting non-congestion controlled = traffic (in case >> the source in not keeping to the limits on purpose/in order to cheat, = because >> it couldn't estimate the needed bandwidth requirement an better, or = due to >> timely fluctuations) could be explained more clearing and the = respective >> requirement to implement rate limiting could be state separately and = more >> strongly...? >=20 > Section 3.2.1.1 days: >=20 > Ensuring adequate buffering requires, in turn, that the source, and > every DetNet node along the path to the destination (or nearly every > node, see Section 4.3.3) be careful to regulate its output to not > exceed the data rate for any DetNet flow, except for brief periods > when making up for interfering traffic. Any packet sent ahead of = its > time potentially adds to the number of buffers required by the next > hop DetNet node and may thus exceed the resources allocated for a > particular DetNet flow. >=20 > Section 3.3.1 also says: >=20 > Starvation of non-DetNet traffic must be avoided, e.g., by traffic > policing functions (e.g., [RFC2475]). Thus, the net effect of the > presence of DetNet flows in a network on the non-DetNet flows is > primarily a reduction in the available bandwidth. >=20 > Is this not sufficient? If not, can you suggest some additional = language? My question is mostly if you only need to protect _complete_ starvation = or any over-use by DetNet flows and how you would do that. If the answer = is to rate limit the DetNet flows at ingress to the allocated bandwidth, = that would completely address my concern. However note that buffer = dimensioning and rate limiting is not the same. Rate limiting is usually = a scheduling question, e.g. using a token bucket scheme or a fixed = non-work conserving scheduler. Therefore it would be nice to add one = additional sentence in section 3.2 that spells that out directly. e.g. = something like: =E2=80=9EIn order to protect non-DetNet traffic from potentially = misbehaving DetNet-Traffic sources, rate limiting, e.g. using a token = bucket scheme, at each tunnel ingress must be applied.=E2=80=9C=20 I=E2=80=99m sure you can adapt the wording to make it more DetNet-like = language and maybe you also want to add another sentence explaining the = problem, please feel free to do so but that=E2=80=99s more or less what = I=E2=80=99m looking for. >=20 >>=20 >> One related comment on this sentence in Sec 3.1: >>=20 >> "As DetNet provides allocated resources (including provisioned = capacity) >> to DetNet flows the use of transport layer congestion control >> [RFC2914] by App-flows is explicitly not required." >>=20 >> I guess congestion control should still be a requirement if the = App-flow also >> passes not-DetNet-aware segments of the path, e.g. maybe the first = hop. >=20 > This point is addressed in section 3.3.2 >=20 > Note that the sending of App-flows that do not use transport layer > congestion control per [RFC2914] into a network that is not > provisioned to handle such DetNet traffic has to be treated as a > fault and prevented. >=20 >> Usually >> use of congestion control for application limited flows is also not a = problem >> if sufficient bandwidth is available. Also note that, as I stated = above, the >> important part for not requiring congestion control is actually not = only that >> resources are allocated but also that rate limiting is in place to = make sure >> resources usage cannot be exceeded above the reserved allocation. = Maybe this >> sentence could also be further clarified in the draft...? >=20 > Is the above sufficient? If not, can you suggest some additional = language? Maybe we can just extend the above statement a bit in order to be = crystal clear about this, e.g.: "As DetNet flow are assumed to be rate-limited and DetNet is designed to = provide sufficient allocated resources (including provisioned capacity), = the use of transport layer congestion control [RFC2914] for end-to-end = DetNet flows is not required, however, if resources are allocated = appropriately, use of congestion control should not impact transmission = negatively.=E2=80=9C >=20 >=20 >> And then one more small comment that is also related. Sec 3.2.2.2 = says: >>=20 >> "If packet replication and elimination is used over paths with >> resource allocation (Section 3.2.1), ..." >>=20 >> My assumption was that all DetNet traffic is send over pre-allocated >> resources...? If that is not true that has implication on congestion = control >> and needs some additional considerations. Can you please confirm that = and maybe >> clarify in the draft! Thanks! >=20 > The intent was to cover sending over non-pre-allocated paths as a = fault case, and cover it in section 3.3.2. If that is the case, maybe we can just removed the half-sentence I cited = above? Thanks! Mirja >=20 > In addition to the previously quoted text, the section also says: >=20 > PRF generated DetNet member flows also need to > be treated as not using transport layer congestion control even if > the original App-flow supports transport layer congestion control > because PREOF can remove congestion indications at the PEF and > thereby hide such indications (e.g., drops, ECN markings, increased > latency) from end systems. >=20 > Does this address your concern? >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I agree with Alexey and Benjamin that this document should be = informational. >> Informational documents can also have IETF consensus, so that cannot = be the >> reason to go for PS. However, this document does not specify a = protocol or any >> requirements that are mandatory to implement for interoperability and = therefore >> should not be PS. >>=20 > I defer to the IESG and AD on this... >=20 > Thank you! >=20 > Lou >=20 >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet >=20 >=20 From nobody Wed Feb 20 08:07:57 2019 Return-Path: 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 C7407128B01; Wed, 20 Feb 2019 08:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mit.edu 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 ipf4MiYjDxxC; Wed, 20 Feb 2019 08:07:52 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750093.outbound.protection.outlook.com [40.107.75.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104B112870E; Wed, 20 Feb 2019 08:07:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c4Ajd5vIhFctsbHgO/106260PsEiuBU21dUwHnFn6uw=; b=r8tLx9LuqVdm5l55WP1k2gGl3xa57DlylHLS8dGqpcDVnU/9goJ1mGZGgM8XfqpM9EPro6oR4sO19V3ZXplSKzLy4btOhX3irtK1MDZUil+wTvZ1fjpdK6XW3GadzdQK2vEJuLKK33eabYRW3NFukaRo3PbpDzr5nF9m2Gx7Id4= Received: from CY4PR0101CA0021.prod.exchangelabs.com (2603:10b6:910:3c::34) by BL0PR01MB4851.prod.exchangelabs.com (2603:10b6:208:7e::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Wed, 20 Feb 2019 16:07:49 +0000 Received: from CO1NAM03FT026.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::204) by CY4PR0101CA0021.outlook.office365.com (2603:10b6:910:3c::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.14 via Frontend Transport; Wed, 20 Feb 2019 16:07:48 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT026.mail.protection.outlook.com (10.152.80.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Wed, 20 Feb 2019 16:07:48 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1KG7iAG028767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Feb 2019 11:07:46 -0500 Date: Wed, 20 Feb 2019 10:07:44 -0600 From: Benjamin Kaduk To: Lou Berger CC: The IESG , , , Message-ID: <20190220160743.GD69562@kduck.mit.edu> References: <155063426136.20704.6779201119170972943.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(136003)(39860400002)(346002)(376002)(2980300002)(189003)(199004)(2870700001)(88552002)(6916009)(786003)(2906002)(26005)(476003)(6306002)(478600001)(126002)(486006)(75432002)(106002)(956004)(966005)(14444005)(26826003)(446003)(4326008)(55016002)(1076003)(11346002)(8676002)(58126008)(106466001)(54906003)(53416004)(246002)(53546011)(8936002)(316002)(356004)(336012)(86362001)(76176011)(7696005)(305945005)(186003)(229853002)(50466002)(5660300002)(33656002)(36906005)(47776003)(104016004)(6246003)(23756003)(426003)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR01MB4851; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 508f787c-01f0-46e9-79f7-08d6974d8eea X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:BL0PR01MB4851; X-MS-TrafficTypeDiagnostic: BL0PR01MB4851: X-MS-Exchange-PUrlCount: 2 X-Microsoft-Exchange-Diagnostics: 1; BL0PR01MB4851; 20:GpYNOvUKb71hKnUZ1hkAJ3UbbsdYHAyrW8GmuSe4btzJoJNr0b904BYLB8c6J8+xzqTDjFWJoYRRsxoLMhxvw1fls/+vZlrIkHK9LcoS4NYV+sAZXJ4Cf3Ugr0GyT2InGnVqXX8CPKLzFp3G3hlxO2kADXqwrP65PQ2L1a0qgJ2loARIetKEeVeWob4lw5ig3+2drkMC6E/kQ2hMH++pPYll71EzBv9jHlHwRWA1Z4Frxh+jhIn9MChLBwLLQkY+Jz9pbUdxaQMd5LrlVB6mecrs73Q8Mcdv5XZeARB/7SFFj99vqVOiMO3UjhqyMliKAClwUqJnXhDRrUp0aTtJVGW3xg/JxFoRAncYbFuZDc7HIR6TFdgkTUIq4t/uAEmD0lyhlnkh+FxpkV3GTMg19hA4QENMWQid2sDvJvlEOYkf93+uSQY7H0l9+OMUiFb3lOWY4s/9Ou+gGHHV7BqryQ9a3YTa/HyadN/aNPnL4of1szNWoXbkn4jnbuOCdqAZqtZfeLYu07VdfSa9dwE/KjFA8Hgtr9SI7GK1vHK8ht6QDaG45opOFbEj+FW4NuJiyVDJBk5ruMbDqzRTjn1In3JAB2Ap1BGkH4SQky5TvP8= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0954EE4910 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BL0PR01MB4851; 23:V4s+Q368blq3+mt7BOMbiyYsAZivVzEGxFGB+Xb?= =?iso-8859-1?Q?VnqhbWM5mKL6GVU59s7VMCUARz+F4Iu3I+oZf+DmQDArgfasZdcvGnd7YR?= =?iso-8859-1?Q?eG7Hf6idPeojPgYquhQIbwvCgQ7DtitcSGoVvcwrZGRrqUE5i5q6YdfV3w?= =?iso-8859-1?Q?UHvYtFhrha4nltG4XLLl6rxN02zW4RnJGM5x2azAfjBsMlKjlb4bpP5y87?= =?iso-8859-1?Q?rKJZKquS8Xi4dmhXro7Abu8NKgrTWzeEKfOMKMIQfPHW/QgEEeSSqJ+xfx?= =?iso-8859-1?Q?5h+kToN9EsrAotZLS2/fluUmf+8qLjAaoSJIjYR5/2+N3eI1apN/W6Qtvi?= =?iso-8859-1?Q?tyYOk1fEJnoMClleeJmgoIkS2aQU5ifQKoz996ioWDxaSqkJLfOro5QVIL?= =?iso-8859-1?Q?4fFex/B6xSltTG9Fq/qfMyjyRxR0By+ti8Xcr/4j/1K3W9J+JF7mGi5FcH?= =?iso-8859-1?Q?fBEsBeeVAob6OWhK/pMiemTB/rg6PRceNxf4wOofhZ/IfEJ4oLhoNFb3QG?= =?iso-8859-1?Q?CYDzhEPOyJR2SYr3ATv6ezRm47UD0iq/zDBN64aHq4jvm2YShntwqagmjR?= =?iso-8859-1?Q?moxK8ZUO/8q9DebbOM+e+ljvl8VRRU11kv7LS2ldlDScmbBIl48krJwcES?= =?iso-8859-1?Q?gcTA0EO7kAFF+sSbDpAwzPkAGlIDBcRGuSD51u5n4IQda966bnbpIRvE8h?= =?iso-8859-1?Q?+1sejwRWMcT45NGIOIXkkdarjmifdtTPR9kcVVP56+sNyx7qOUL6L6ZzF/?= =?iso-8859-1?Q?TPYGQDlKEq9Agd4E6j6qjp/YZQrwWVu6yaYm/p3lub5eJLAVbw3OWagXey?= =?iso-8859-1?Q?DSIqI81taa/90KW2AFiiu/WTSs6BRamkTgM0PHDStZc8egGPlZNYPH91j+?= =?iso-8859-1?Q?emre6Zb9IyCpOqiYfyR09qoeDLf7qzTzOsm6LRtw61eqbxYpT1HpgUr7eP?= =?iso-8859-1?Q?vRaQokaGHwIbi9OH+JDm2E6UwGIKmeNuUzqju8zWVGzzAqTYl3V91dCu9W?= =?iso-8859-1?Q?80g0Qg5DE9+pOMXkFsU0G0eNIBgqMBMtfDMnJRHiYvrf2Y/qJtkE51QKtY?= =?iso-8859-1?Q?Z/4UHDe59nKLwumjmDTKFY+nSv/xLzRTnfDYBthHbp1PSN6exE7uxpwNf2?= =?iso-8859-1?Q?pU7W/yszOl6pOCZntQF/qkFnJ6BG64nPh855SYmUWE9PCLYhhjkpDu8Js+?= =?iso-8859-1?Q?dEIPh2rQZRfEKEmrokqeB+SaM0VRDBT//zJrOfUbxmJE8CBSHxY2tP5JhY?= =?iso-8859-1?Q?vMtgEIB/D+aUlsvACgz1cQRYLk46TNCkg5jdf8AX9LFuDfWil9aZZ11nHj?= =?iso-8859-1?Q?6I=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: wLUv0pHjPU/IOObCBZ/ho1DNggf647BghIn2QnI040Wjxgf4nw0FTiEPZFZLLXCumDgLR75lsuddiHjasNIEOf4r4BPWIXRFjO99eTg3LKAU7sKZ3ZO/YXCV0YUp9w8ufPuI9HJlqVfAll8G2ttvMqOfa4Kx/lw6mKBErZ95f9JaNSj0nzePv96PZGk0F9AZ+3sMZjHrCl598IFr//eku/LQCVoEmpKgPGtuM51Dq3nkgHpVkSmni51+dva7Q1Hw+fRAQNOiZGtcgeDMlja24ZDDC4t+fZjXy4OcJWw8Zfo2ERq8om1McZkJKt65JVf1msmxu+0Eyf/VO00OddXAKset9e1qM1lFafQUDalXAEjr7hQ7DOy6qdIe/MW02G69p74uAw7rNf33ow45rs8FJKZaqT7nrR/UK7vUbix5Hks= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Feb 2019 16:07:48.1407 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 508f787c-01f0-46e9-79f7-08d6974d8eea X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR01MB4851 Archived-At: Subject: Re: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 16:07:55 -0000 Hi Lou, On Wed, Feb 20, 2019 at 09:33:34AM -0500, Lou Berger wrote: > Hi Benjamin, > > I'm responding as doc shepherd (and chair). Thank you for your > comments. Please see below for specific responses. > > On 2/19/2019 10:44 PM, Benjamin Kaduk wrote: > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-detnet-architecture-11: 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: > > https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I note that the DETNET WG is explicitly chartered with a work item for the > > "overall architecture: This work encompasses ... and security aspects". > > It seems incomplete to specify an architecture for a topic such as > > deterministic networking without specifically considering what threats are > > and are not in scope to be protected against. > > The working group certainly recognizes that security is an important > topic and necessary part of the work. The WG's approach to ensure that > this significant topic is sufficiently covered is to have a document > dedicated to the topic. As you note below this work, > draft-ietf-detnet-security, is not at the same level maturity - so > please stay tuned. Of course, the WG would welcome any input on this > security draft now or even a full early-review or security area advisor. I do appreciate that the WG has taken the time to work on a dedicated security document, that goes through the (tedious!) effort to tabulate the various known attacker capabilities, threats, and their interactions. What I think is missing from the high-level architecture document is a sense for what security goals the architecture intends to achieve. It's fine to have this be separate from the nitty-gritty stuff in the separate document, but these high-level questions can have an impact on the high-level design of the protocol ecosystem as a whole. We have mounds of examples of "come up with a design; bolt security on as an afterthought" working poorly or being nigh-impossible, and I haven't seen any attempt at justification for why doing so here is likely to be any different. Including the security concepts from the start and wholly integrating them into the system tends to produce a much more elegant design and smoother outcomes all around. > (We have one from the transport area.) > > > Some easy questions should > > be whether the system is expected to be robust in the face of an attacker > > that generates non-DetNet traffic? Or an attacker that generates DetNet > > traffic in excess of reservations? It can even be a fine engineering goal > > to produce a solution that only protects against media corruption and > > hardware crashes and leaves active attacks out of scope, but the actual > > intended scope of the work needs to be clear. At the other end of the > > spectrum, protecting against as potent an attacker as a malicious traffic > > policer is probably a lost cause, especially if the policer is authorized > > to direct remote nodes to take action to terminate "misbehaving" flows. > > The referenced draft-ietf-detnet-security is not at a comparable maturity > > level to this document and also fails to present a clear threat model for > > the DetNet architecture. (The section entitled "Threat Model" reads as > > more of a taxonomy of threats than a model for what threats are and are not > > to be addressed.) It also presents the usage of cryptographic mechanisms > > as mitigation techniques without provisioning for the prerequisties of such > > mechanisms (e.g., using HMAC for message integrity protection without > > mention of infrastructure for distributing the keys for keying the HMAC). > > > These are all great input for draft-ietf-detnet-security - I'll touch > with authors to ensure that they are aware of your comments. I noticed a few other things of note while skimming; I'll try to send those over as well. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I agree with Alexey that Informational would (also) be a fine status in > > which to publish this document. > > I defer to the IESG and our AD. > > I think the authors can address/respond to the remaining comments. Sounds good. -Benjamin From nobody Wed Feb 20 08:11:51 2019 Return-Path: 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 0B84312870E for ; Wed, 20 Feb 2019 08:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 jHL5IoELNW2J for ; Wed, 20 Feb 2019 08:11:47 -0800 (PST) Received: from alt-proxy16.mail.unifiedlayer.com (alt-proxy16.mail.unifiedlayer.com [70.40.197.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 496961277D2 for ; Wed, 20 Feb 2019 08:11:47 -0800 (PST) Received: from cmgw10.unifiedlayer.com (unknown [10.9.0.10]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id F01E01E1050 for ; Wed, 20 Feb 2019 09:11:44 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id wUTGgXHBSuj2owUTGgbfwg; Wed, 20 Feb 2019 09:11:42 -0700 X-Authority-Reason: nr=8 X-Authority-Analysis: $(_cmae_reason DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=iZ1FR7xcIl+1+HBCpZNFQLSuWKB0dxgbY3vQsU+XbC8=; b=fyVRjN2x6nO21AqmkqlpKoiVdF /6x7ArJsJWN5elDU84SEC0hYKek1RrYRs9Uim2/aiufYfI24lz+fIX5CB0TcdJvkMSKeTzWs+d1a1 o73jH9fcBNxXj735B7e8+WF7+; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:60832 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gwUTG-000cd4-MT; Wed, 20 Feb 2019 09:11:42 -0700 To: Alvaro Retana , The IESG Cc: draft-ietf-detnet-architecture@ietf.org, detnet-chairs@ietf.org, detnet@ietf.org References: <155067820715.31361.3746519237969586434.idtracker@ietfa.amsl.com> From: Lou Berger Message-ID: <108f9294-fb9d-557a-011a-6a53156bcb37@labn.net> Date: Wed, 20 Feb 2019 11:11:41 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <155067820715.31361.3746519237969586434.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------43FA4C089F9DBF3828CB31D4" Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 72.66.11.201 X-Source-L: No X-Exim-ID: 1gwUTG-000cd4-MT X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:60832 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Detnet] Alvaro Retana's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 16:11:50 -0000 This is a multi-part message in MIME format. --------------43FA4C089F9DBF3828CB31D4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Alissa, Thanks for the comments - see below. On 2/20/2019 10:56 AM, Alvaro Retana wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-detnet-architecture-11: 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: > https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I support Mirja's and Alissa's DISCUSSes...and have a related set of concerns > about the coexistence with non-DetNet traffic and privacy: > > §3.3.1 talks about what I think is a hard to achieve balance between coexisting > with non-DetNet traffic and keeping that traffic from disrupting DetNet flows. > Because of the constraints, the intent of prioritizing DetNet flows is clear > (and that is ok), but that may result in starvation of non-DetNet > traffic...even if the text does explicitly say that it "must be avoided". > > I would like to see the potential case of starving non-DetNet traffic called > out somewhere. This is the objective of section 3.3.1. > I'm looking for something similar to the first paragraph in §5, > but focused on the non-DetNet traffic. The current text reads: 3.3.1. Coexistence with normal traffic A DetNet network supports the dedication of a high proportion of the network bandwidth to DetNet flows. But, no matter how much is dedicated for DetNet flows, it is a goal of DetNet to coexist with existing Class of Service schemes (e.g., DiffServ). It is also important that non-DetNet traffic not disrupt the DetNet flow, of course (see Section 3.3.2 and Section 5). For these reasons: o Bandwidth (transmission opportunities) not utilized by a DetNet flow is available to non-DetNet packets (though not to other DetNet flows). o DetNet flows can be shaped or scheduled, in order to ensure that the highest-priority non-DetNet packet is also ensured a worst- case latency. o When transmission opportunities for DetNet flows are scheduled in detail, then the algorithm constructing the schedule should leave sufficient opportunities for non-DetNet packets to satisfy the needs of the users of the network. Detailed scheduling can also permit the time-shared use of buffer resources by different DetNet flows. Starvation of non-DetNet traffic must be avoided, e.g., by traffic policing functions (e.g., [RFC2475]). Thus, the net effect of the presence of DetNet flows in a network on the non-DetNet flows is primarily a reduction in the available bandwidth. I think we need a little bit more to understand what you'd like to see changed or added. Can you suggest text or what specific topic you'd like to see added/addressed? > Related to the above is the fact that the identification of flows could be used > to specifically *not* include some of them as DetNet flows. This is a > variation of the concern outlined in §6, but applied to non-DetNet flows, with > the potential starvation mentioned above. Again, I would like to at least see > some discussion of this risk. I don't follow - what is the risk that should be addressed? > The use case and problem statement documents outline specific applications that > may not have non-DetNet traffic, and the Introduction supports that. However, > the architecture described in this document may be used in more general > networks to provide guarantees to specific traffic... IOW, even if the > intention is there, there is no guarantee that DetNet will only be used in the > expected use cases. You're not requesting any change in the document here, right? Thanks, Lou (as doc shepherd) --------------43FA4C089F9DBF3828CB31D4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 
Hi Alissa,

Thanks for the comments - see below.
On 2/20/2019 10:56 AM, Alvaro Retana wrote:
Alvaro Retana has entered the following ballot position for
draft-ietf-detnet-architecture-11: 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:
https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I support Mirja's and Alissa's DISCUSSes...and have a related set of concerns
about the coexistence with non-DetNet traffic and privacy:

§3.3.1 talks about what I think is a hard to achieve balance between coexisting
with non-DetNet traffic and keeping that traffic from disrupting DetNet flows. 
Because of the constraints, the intent of prioritizing DetNet flows is clear
(and that is ok), but that may result in starvation of non-DetNet
traffic...even if the text does explicitly say that it "must be avoided".

I would like to see the potential case of starving non-DetNet traffic called
out somewhere.

This is the objective of section 3.3.1. 


 I'm looking for something similar to the first paragraph in §5,
but focused on the non-DetNet traffic.

The current text reads:

3.3.1.  Coexistence with normal traffic

   A DetNet network supports the dedication of a high proportion of the
   network bandwidth to DetNet flows.  But, no matter how much is
   dedicated for DetNet flows, it is a goal of DetNet to coexist with
   existing Class of Service schemes (e.g., DiffServ).  It is also
   important that non-DetNet traffic not disrupt the DetNet flow, of
   course (see Section 3.3.2 and Section 5).  For these reasons:

   o  Bandwidth (transmission opportunities) not utilized by a DetNet
      flow is available to non-DetNet packets (though not to other
      DetNet flows).

   o  DetNet flows can be shaped or scheduled, in order to ensure that
      the highest-priority non-DetNet packet is also ensured a worst-
      case latency.

   o  When transmission opportunities for DetNet flows are scheduled in
      detail, then the algorithm constructing the schedule should leave
      sufficient opportunities for non-DetNet packets to satisfy the
      needs of the users of the network.  Detailed scheduling can also
      permit the time-shared use of buffer resources by different DetNet
      flows.

   Starvation of non-DetNet traffic must be avoided, e.g., by traffic
   policing functions (e.g., [RFC2475]).  Thus, the net effect of the
   presence of DetNet flows in a network on the non-DetNet flows is
   primarily a reduction in the available bandwidth.


I think we need a little bit more to understand what you'd like to see changed or added.  Can you suggest text or what specific topic you'd like to see added/addressed? 



Related to the above is the fact that the identification of flows could be used
to specifically *not* include some of them as DetNet flows.  This is a
variation of the concern outlined in §6, but applied to non-DetNet flows, with
the potential starvation mentioned above.  Again, I would like to at least see
some discussion of this risk.

I don't follow - what is the risk that should be addressed?


The use case and problem statement documents outline specific applications that
may not have non-DetNet traffic, and the Introduction supports that.  However,
the architecture described in this document may be used in more general
networks to provide guarantees to specific traffic...  IOW, even if the
intention is there, there is no guarantee that DetNet will only be used in the
expected use cases.

You're not requesting any change in the document here, right?

Thanks,

Lou

(as doc shepherd)


    

  


--------------43FA4C089F9DBF3828CB31D4--


From nobody Wed Feb 20 08:43:22 2019
Return-Path: 
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 8E1A71277D2 for ; Wed, 20 Feb 2019 08:43:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 t0wI_Wb-g_4L for ; Wed, 20 Feb 2019 08:43:17 -0800 (PST)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5352E1200D7 for ; Wed, 20 Feb 2019 08:43:17 -0800 (PST)
Received: from CMGW (unknown [10.9.0.13]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id BD7D11787EC for ; Wed, 20 Feb 2019 09:24:22 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id wUfWgD7cceyBxwUfWgm7nR; Wed, 20 Feb 2019 09:24:22 -0700
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=mPdtgih+LZc0P5Df6BblUGjSaOxPkJriQoquL3MAmKw=; b=vRTT9rkJlMsbO153PIhqcASL6T HRRRBjx8YW/hGvlG7xX/IYwN2PRrgmQmo/eFCaiCiys5pcbnZwCRakK46186cSlRMGfJqffW7VnBH emp2kfNgrz9z/eImSEw2R8MRD;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:34050 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gwUfW-000gXo-F7; Wed, 20 Feb 2019 09:24:22 -0700
To: "Mirja Kuehlewind (IETF)" 
Cc: The IESG , draft-ietf-detnet-architecture@ietf.org, detnet@ietf.org, detnet-chairs@ietf.org
References: <155066795164.31466.275999283339131275.idtracker@ietfa.amsl.com> <77e87eca-07df-99eb-9edb-7f6f18913dfd@labn.net> <5AF7514B-B8C9-48E5-B1F4-BF2139EB128A@kuehlewind.net>
From: Lou Berger 
Message-ID: <8b47372c-210a-5ecb-f563-788d84535279@labn.net>
Date: Wed, 20 Feb 2019 11:24:21 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <5AF7514B-B8C9-48E5-B1F4-BF2139EB128A@kuehlewind.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 72.66.11.201
X-Source-L: No
X-Exim-ID: 1gwUfW-000gXo-F7
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:34050
X-Source-Auth: lberger@labn.net
X-Email-Count: 9
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [Detnet]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-detnet-architecture-11=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2019 16:43:20 -0000

Hi Mirja,

     See below.

On 2/20/2019 11:06 AM, Mirja Kuehlewind (IETF) wrote:
> Hi Lou,
>
> I’m happy to see that my concerns seem to be cover. So maybe this is mostly a point about wording. Please see below.
>
>> Am 20.02.2019 um 15:46 schrieb Lou Berger :
>>
>> Hi Mirja,
>>
>> I'm responding as doc shepherd (and chair). Thank you for your comments.  Please see below for specific responses.
>>
>> On 2/20/2019 8:05 AM, Mirja Kühlewind wrote:
>>> Mirja Kühlewind has entered the following ballot position for
>>> draft-ietf-detnet-architecture-11: 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:
>>> https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> Thanks for addressing the tsv-art review comments  (and big thanks to Michael
>>> and David!) and all the work done so far! I think the document is in good shape
>>> and I only have one minor comment that I would like to see addressed/more
>>> explicitly spelled out. However, this should be done quickly with potentially
>>> 2-3 small changes in the draft. See below.
>> The input from Michael and David certainly led to a much improved document.  If you can help the authors with some specific text suggestions that would be most helpful.
>>
>>
>>> Given that DetNet traffic is often assumed to be not congestion controlled, it
>>> is important that there is also some network function that makes sure the
>>> source traffic stays within the requested bandwidth limit in-order to protect
>>> non-Detnet traffic. This is to some extended discussed in section 3.3.2 but I
>>> think it should be more clearly spelled out that this would require a rate
>>> limiting function at each DetNet source/relay (tunnel ingress). Currently sec
>>> 3.3.2 says:
>>>
>>> "Filters and policers should be used in a DetNet network to
>>>     detect if DetNet packets are received on the wrong interface, or at
>>>     the wrong time, or in too great a volume."
>>>
>>> However, maybe this case of limiting non-congestion controlled traffic (in case
>>> the source in not keeping to the limits on purpose/in order to cheat, because
>>> it couldn't estimate the needed bandwidth requirement an better, or due to
>>> timely fluctuations) could be explained more clearing and the respective
>>> requirement to implement rate limiting could be state separately and more
>>> strongly...?
>> Section 3.2.1.1 days:
>>
>>    Ensuring adequate buffering requires, in turn, that the source, and
>>    every DetNet node along the path to the destination (or nearly every
>>    node, see Section 4.3.3) be careful to regulate its output to not
>>    exceed the data rate for any DetNet flow, except for brief periods
>>    when making up for interfering traffic.  Any packet sent ahead of its
>>    time potentially adds to the number of buffers required by the next
>>    hop DetNet node and may thus exceed the resources allocated for a
>>    particular DetNet flow.
>>
>> Section 3.3.1 also says:
>>
>>    Starvation of non-DetNet traffic must be avoided, e.g., by traffic
>>    policing functions (e.g., [RFC2475]).  Thus, the net effect of the
>>    presence of DetNet flows in a network on the non-DetNet flows is
>>    primarily a reduction in the available bandwidth.
>>
>> Is this not sufficient?  If not, can you suggest some additional language?
> My question is mostly if you only need to protect _complete_ starvation or any over-use by DetNet flows and how you would do that. If the answer is to rate limit the DetNet flows at ingress to the allocated bandwidth, that would completely address my concern. However note that buffer dimensioning and rate limiting is not the same. Rate limiting is usually a scheduling question, e.g. using a token bucket scheme or a fixed non-work conserving scheduler. Therefore it would be nice to add one additional sentence in section 3.2 that spells that out directly. e.g. something like:
>
> „In order to protect non-DetNet traffic from potentially misbehaving DetNet-Traffic sources, rate limiting, e.g. using a token bucket scheme, at each tunnel ingress must be applied.“

> I’m sure you can adapt the wording to make it more DetNet-like language and maybe you also want to add another sentence explaining the problem, please feel free to do so but that’s more or less what I’m looking for.

I do agree that we seem to be having a terminology issue here - and that 
we are on the same page with what should happen.  The terminology I've 
used/seen in past RFCs has usually used the terms 'shaping' and 
'policing' - and these are what we've been using within the WG.  For 
example, both of these terms are used in RFC2475 but 'rate limiting' is 
not. Would it work for you for the draft to use/adapt the rest of your 
language, but keep 'by traffic policing functions (e.g., [RFC2475])' 
rather than 'rate limiting, e.g. using a token bucket scheme,' ?


>
>>> One related comment on this sentence in Sec 3.1:
>>>
>>> "As DetNet provides allocated resources (including provisioned capacity)
>>>     to DetNet flows the use of transport layer congestion control
>>>     [RFC2914] by App-flows is explicitly not required."
>>>
>>> I guess congestion control should still be a requirement if the App-flow also
>>> passes not-DetNet-aware segments of the path, e.g. maybe the first hop.
>> This point is addressed in section 3.3.2
>>
>>    Note that the sending of App-flows that do not use transport layer
>>    congestion control per [RFC2914] into a network that is not
>>    provisioned to handle such DetNet traffic has to be treated as a
>>    fault and prevented.
>>
>>> Usually
>>> use of congestion control for application limited flows is also not a problem
>>> if sufficient bandwidth is available. Also note that, as I stated above, the
>>> important part for not requiring congestion control is actually not only that
>>> resources are allocated but also that rate limiting is in place to make sure
>>> resources usage cannot be exceeded above the reserved allocation. Maybe this
>>> sentence could also be further clarified in the draft...?
>> Is the above sufficient?  If not, can you suggest some additional language?
> Maybe we can just extend the above statement a bit in order to be crystal clear about this, e.g.:
>
> "As DetNet flow are assumed to be rate-limited and DetNet is designed to provide sufficient allocated resources (including provisioned capacity), the use of transport layer congestion control [RFC2914] for end-to-end DetNet flows is not required, however, if resources are allocated appropriately, use of congestion control should not impact transmission negatively.“
Great!  (I'll leave it to the authors to do the final wording adaptation)
>
>>> And then one more small comment that is also related. Sec 3.2.2.2 says:
>>>
>>> "If packet replication and elimination is used over paths with
>>>     resource allocation (Section 3.2.1), ..."
>>>
>>> My assumption was that all DetNet traffic is send over pre-allocated
>>> resources...? If that is not true that has implication on congestion control
>>> and needs some additional considerations. Can you please confirm that and maybe
>>> clarify in the draft! Thanks!
>> The intent was to cover sending over non-pre-allocated paths as a fault case, and cover it in section 3.3.2.
> If that is the case, maybe we can just removed the half-sentence I cited above?

WFM!

Thank you!

>
> Thanks!
> Mirja
>
>> In addition to the previously quoted text, the section also says:
>>
>>    PRF generated DetNet member flows also need to
>>    be treated as not using transport layer congestion control even if
>>    the original App-flow supports transport layer congestion control
>>    because PREOF can remove congestion indications at the PEF and
>>    thereby hide such indications (e.g., drops, ECN markings, increased
>>    latency) from end systems.
>>
>> Does this address your concern?
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> I agree with Alexey and Benjamin that this document should be informational.
>>> Informational documents can also have IETF consensus, so that cannot be the
>>> reason to go for PS. However, this document does not specify a protocol or any
>>> requirements that are mandatory to implement for interoperability and therefore
>>> should not be PS.
>>>
>> I defer to the IESG and AD on this...
>>
>> Thank you!
>>
>> Lou
>>
>>> _______________________________________________
>>> detnet mailing list
>>> detnet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/detnet
>>
>


From nobody Wed Feb 20 08:43:42 2019
Return-Path: 
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 4D66712870E for ; Wed, 20 Feb 2019 08:43:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 iz1Re8nnS2aA for ; Wed, 20 Feb 2019 08:43:39 -0800 (PST)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 150461277D2 for ; Wed, 20 Feb 2019 08:43:39 -0800 (PST)
Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id C0BAD1795C5 for ; Wed, 20 Feb 2019 09:34:12 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id wUp2ghw1Cmds9wUp2gUXnN; Wed, 20 Feb 2019 09:34:12 -0700
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=+pVaXKNUgDlYg56bKXiMiolurTazy2ds1IkW6NwyPwk=; b=G8mLRtld9nkPIV4rdolWjpNuhB ZOhyAxAlfJs0Ka9uNIZTVSfd//eR9gQ2HVirPsuj8gACU3d888rDEkZgWKNGbwt5jywodmYzBMvis JB5KSZ2x5lA6PhXvVJCsmSlS0;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:35608 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gwUp2-000jUG-6s; Wed, 20 Feb 2019 09:34:12 -0700
To: Benjamin Kaduk 
Cc: draft-ietf-detnet-architecture@ietf.org, detnet@ietf.org, The IESG , detnet-chairs@ietf.org
References: <155063426136.20704.6779201119170972943.idtracker@ietfa.amsl.com>  <20190220160743.GD69562@kduck.mit.edu>
From: Lou Berger 
Message-ID: <36c4ce97-5c4a-89ab-d648-3e7705a6acd3@labn.net>
Date: Wed, 20 Feb 2019 11:34:11 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <20190220160743.GD69562@kduck.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 72.66.11.201
X-Source-L: No
X-Exim-ID: 1gwUp2-000jUG-6s
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:35608
X-Source-Auth: lberger@labn.net
X-Email-Count: 13
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2019 16:43:40 -0000

Hi Benjamin,

     Please see below.

On 2/20/2019 11:07 AM, Benjamin Kaduk wrote:
> Hi Lou,
>
> On Wed, Feb 20, 2019 at 09:33:34AM -0500, Lou Berger wrote:
>> Hi Benjamin,
>>
>> I'm responding as doc shepherd (and chair). Thank you for your
>> comments.  Please see below for specific responses.
>>
>> On 2/19/2019 10:44 PM, Benjamin Kaduk wrote:
>>> Benjamin Kaduk has entered the following ballot position for
>>> draft-ietf-detnet-architecture-11: 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:
>>> https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> I note that the DETNET WG is explicitly chartered with a work item for the
>>> "overall architecture: This work encompasses ... and security aspects".
>>> It seems incomplete to specify an architecture for a topic such as
>>> deterministic networking without specifically considering what threats are
>>> and are not in scope to be protected against.
>> The working group certainly recognizes that security is an important
>> topic and necessary part of the work. The WG's  approach to ensure that
>> this significant topic is sufficiently covered is to have a  document
>> dedicated to the topic.  As you note below this work,
>> draft-ietf-detnet-security, is not at the same level maturity - so
>> please stay tuned.  Of course, the WG would welcome any input on this
>> security draft now or even a full early-review or security area advisor.
> I do appreciate that the WG has taken the time to work on a dedicated
> security document, that goes through the (tedious!) effort to tabulate the
> various known attacker capabilities, threats, and their interactions.
>
> What I think is missing from the high-level architecture document is a
> sense for what security goals the architecture intends to achieve.  It's
> fine to have this be separate from the nitty-gritty stuff in the separate
> document, but these high-level questions can have an impact on the
> high-level design of the protocol ecosystem as a whole.  We have mounds of
> examples of "come up with a design; bolt security on as an afterthought"
> working poorly or being nigh-impossible, and I haven't seen any attempt at
> justification for why doing so here is likely to be any different.
> Including the security concepts from the start and wholly integrating them
> into the system tends to produce a much more elegant design and smoother
> outcomes all around.

We went back and forth on how much of the security topic to include in 
the architecture document and settled on the current text of section 5 
where just high level security requirements are identified.  From your 
list below, the architecture covers the points you raise (non-detnet 
traffic impacting detnet traffic, and detnet traffic trying to use more 
than its allocation) mainly from a service delivery perspective.  It 
does mention "shaping" as a security concern, the document could expand 
these if helpful. But I think the real discussion point is how much of 
the security details should be in the base (vs dedicated) document  -- 
and that you disagree with where the WG has drawn the line.  Is this 
correct?

Thanks,

Lou


>> (We have one from the transport area.)
>>
>>> Some easy questions should
>>> be whether the system is expected to be robust in the face of an attacker
>>> that generates non-DetNet traffic?  Or an attacker that generates DetNet
>>> traffic in excess of reservations?  It can even be a fine engineering goal
>>> to produce a solution that only protects against media corruption and
>>> hardware crashes and leaves active attacks out of scope, but the actual
>>> intended scope of the work needs to be clear.  At the other end of the
>>> spectrum, protecting against as potent an attacker as a malicious traffic
>>> policer is probably a lost cause, especially if the policer is authorized
>>> to direct remote nodes to take action to terminate "misbehaving" flows.
>>> The referenced draft-ietf-detnet-security is not at a comparable maturity
>>> level to this document and also fails to present a clear threat model for
>>> the DetNet architecture.  (The section entitled "Threat Model" reads as
>>> more of a taxonomy of threats than a model for what threats are and are not
>>> to be addressed.)  It also presents the usage of cryptographic mechanisms
>>> as mitigation techniques without provisioning for the prerequisties of such
>>> mechanisms (e.g., using HMAC for message integrity protection without
>>> mention of infrastructure for distributing the keys for keying the HMAC).
>>>
>> These are all great input for draft-ietf-detnet-security - I'll touch
>> with authors to ensure that they are aware of your comments.
> I noticed a few other things of note while skimming; I'll try to send those
> over as well.
>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> I agree with Alexey that Informational would (also) be a fine status in
>>> which to publish this document.
>> I defer to the IESG and our AD.
>>
>> I think the authors can address/respond to the remaining comments.
> Sounds good.
>
> -Benjamin
>
> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet
>


From nobody Wed Feb 20 10:11:29 2019
Return-Path: 
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 DB4A5130E0A; Wed, 20 Feb 2019 10:11:21 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ben Campbell 
To: "The IESG" 
Cc: draft-ietf-detnet-architecture@ietf.org, Lou Berger , detnet-chairs@ietf.org, lberger@labn.net, detnet@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155068628183.31466.17047287566875848268.idtracker@ietfa.amsl.com>
Date: Wed, 20 Feb 2019 10:11:21 -0800
Archived-At: 
Subject: [Detnet] Ben Campbell's No Objection on draft-ietf-detnet-architecture-11: (with COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2019 18:11:22 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-detnet-architecture-11: 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/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:
https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/



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

I support Benjamin's and Alissa's DISCUSS positions. I also agree with the
several people who commented that this should be informational. Otherwise, I
have some minor comments:

§3.2.1.2,
- first paragraph: Please expand "GigE"

- "In general, users are encouraged to use, instead of, "do this when you
get the packet," a combination of:" - Hard to parse.

§3.2.2.2: Please expand "PREOF" on first use. I realize readers can probably
construct it from the previous few sentences, but it's more reader-friendly not
to require them to do so.

§3.3.2: "Robust real-time systems require to reduce the number of possible
failures." - The sentence does not parse.  Are there missing words prior to
"to"?

§4.1.2:

- "Distinguishing the function of two DetNet data plane sub-layers, the
DetNet service sub-layer and the DetNet forwarding sub-layer, helps
to explore and evaluate various combinations of the data plane
solutions available, some are illustrated in Figure 4."

Hard to parse. Also, there is a comma splice.

- "There are many valid options to create a data plane solution for
DetNet traffic by selecting a technology approach for the DetNet
service sub-layer and also selecting a technology approach for the
DetNet forwarding sub-layer. There are a high number of valid
combinations."

Does this refer to implementation/deployment options, or protocol design
options? If the latter, are the choices still open?

§4.1.3: Please define or expand DetNet-UNI.

§4.2.1, first paragraph: Does L1 stand for Layer-1, etc? If so, please spell it
out.



From nobody Wed Feb 20 10:24:34 2019
Return-Path: 
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 941A7130E57; Wed, 20 Feb 2019 10:24:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 JnP0Wq2AKogT; Wed, 20 Feb 2019 10:24:30 -0800 (PST)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 DCE68130E2F; Wed, 20 Feb 2019 10:24:29 -0800 (PST)
Received: by mail-ot1-x335.google.com with SMTP id i5so41767929oto.9; Wed, 20 Feb 2019 10:24:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Jx57uaHCor5dpnmiG6dSlz4DGnws+M1r1ztOfsU2r+Q=; b=J87dxuPZrC8Bpf5oIofNeXXLpL7keorVkHgI3tNddYwi5S7ggq5VaUhnDC5tk8yOWu gYrxxCxzjrmdaaKwbnSyvNr53IMVI/HfcbejLxhCKHQw915m717cbjTnI2ouAmBQHXeq 53wkkN97+kQQKN+q0ZcVOiAM72MMThANFkxq9g/JMlzJfVci01QwAdiLiXg4rOgKHHAC DcJHOhiMqoX+cEieAxbudB/Zh1qZiHl9U+k43iLyXxqLyNr4v3fpuk8i3GLKwq6AVQgc 5jZPyzECNU4Jy670EqVZSX6sHYbCf06+YeMY0q11S4XUujBVBMHSYfnXu2VMSln5iDf+ R6sg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Jx57uaHCor5dpnmiG6dSlz4DGnws+M1r1ztOfsU2r+Q=; b=LTjOX3zXShr3Je0+bL8LyjylhZG7shhRFi1GuoE0tUQv1ach4i3SP7mshUgt6rkeI4 4Y1jBl0UCbrmWV3rOU/GOx9srAbmG+cLKAa6ryokGvOOR2iMtHTBwNL9hjRqCjLtWJqH PCIu2XjM9Sy7/eZBXI8Tl9Uyv08uKE5TUJ0C81jQOzQdQvMHhTeUV6l1lxUh2OhjXOLM DHBi8ukyK5zlKxM+pHrtw5f13k9DznsjAhzH5aq9E/nGZzl4ttFHUY7xeni2oLsMpwZo RkIE6ZORg1Ea8PEWIVyzPUST5rdNvf6oItRqdFUY46sakW41pwZRnttWYT4Ku9ASmGTZ Ym8w==
X-Gm-Message-State: AHQUAuZoN2sRWaDj0kRMsXRPXjaHdza6xBpxX5ZA8WlW+ZTWO44aDkjJ Fw5kMfyYcbGljzSkrzuMO3Pi9Xzu4vWxbQCGtqvstF8A
X-Google-Smtp-Source: AHgI3Ib9+WuLMDiavcRGB6ON+VDWj7qQKKEpr0yTiFZGuVWnhx0bPCy593vjlWSIrWcPXllSJcF2OqxJkTfzY5Jlpe4=
X-Received: by 2002:a9d:3de2:: with SMTP id l89mr22628633otc.239.1550687069074;  Wed, 20 Feb 2019 10:24:29 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 20 Feb 2019 13:24:28 -0500
From: Alvaro Retana 
In-Reply-To: <108f9294-fb9d-557a-011a-6a53156bcb37@labn.net>
References: <155067820715.31361.3746519237969586434.idtracker@ietfa.amsl.com> <108f9294-fb9d-557a-011a-6a53156bcb37@labn.net>
MIME-Version: 1.0
Date: Wed, 20 Feb 2019 13:24:28 -0500
Message-ID: 
To: Lou Berger , The IESG 
Cc: detnet-chairs@ietf.org, detnet@ietf.org,  draft-ietf-detnet-architecture@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e9023005825777bb"
Archived-At: 
Subject: Re: [Detnet] Alvaro Retana's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2019 18:24:33 -0000

--000000000000e9023005825777bb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On February 20, 2019 at 4:11:45 PM, Lou Berger (lberger@labn.net) wrote:

Hi Alissa,

=E2=80=A6Alvaro=E2=80=A6 :-)

Hi!


----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I support Mirja's and Alissa's DISCUSSes...and have a related set of concer=
ns
about the coexistence with non-DetNet traffic and privacy:

=C2=A73.3.1 talks about what I think is a hard to achieve balance between c=
oexisting
with non-DetNet traffic and keeping that traffic from disrupting DetNet flo=
ws.
Because of the constraints, the intent of prioritizing DetNet flows is clea=
r
(and that is ok), but that may result in starvation of non-DetNet
traffic...even if the text does explicitly say that it "must be avoided".

I would like to see the potential case of starving non-DetNet traffic calle=
d
out somewhere.

This is the objective of section 3.3.1.


I'm looking for something similar to the first paragraph in =C2=A75,
but focused on the non-DetNet traffic.

The current text reads:

3.3.1.  Coexistence with normal traffic

   A DetNet network supports the dedication of a high proportion of the
   network bandwidth to DetNet flows.  But, no matter how much is
   dedicated for DetNet flows, it is a goal of DetNet to coexist with
   existing Class of Service schemes (e.g., DiffServ).  It is also
   important that non-DetNet traffic not disrupt the DetNet flow, of
   course (see Section 3.3.2 and Section 5).  For these reasons:

   o  Bandwidth (transmission opportunities) not utilized by a DetNet
      flow is available to non-DetNet packets (though not to other
      DetNet flows).

   o  DetNet flows can be shaped or scheduled, in order to ensure that
      the highest-priority non-DetNet packet is also ensured a worst-
      case latency.

   o  When transmission opportunities for DetNet flows are scheduled in
      detail, then the algorithm constructing the schedule should leave
      sufficient opportunities for non-DetNet packets to satisfy the
      needs of the users of the network.  Detailed scheduling can also
      permit the time-shared use of buffer resources by different DetNet
      flows.

   Starvation of non-DetNet traffic must be avoided, e.g., by traffic
   policing functions (e.g., [RFC2475]).  Thus, the net effect of the
   presence of DetNet flows in a network on the non-DetNet flows is
   primarily a reduction in the available bandwidth.


I think we need a little bit more to understand what you'd like to see
changed or added.  Can you suggest text or what specific topic you'd
like to see added/addressed?

Yes, let me try to explain better=E2=80=A6while comparing with the current =
text in
=C2=A75, which basically says that even though the objective of DetNet is t=
o
provide bounded latency, a MIIM may delay the traffic and the objective may
not be achieved.

For non-DetNet traffic, the objective is to not starve it, while providing
specific guarantees to the DetNet flows =E2=80=94 said other way (from the
Introduction): "Unused reserved resources are available to non-DetNet
packets as long as all guarantees are fulfilled.=E2=80=9D  However, the alg=
orithms
(maybe error, misconfiguration=E2=80=A6or even maliciously) may end up*not*
constructing the schedule to leave sufficient opportunities for non-DetNet
packets (as suggested in the text above from =C2=A73.3.1).

I see a parallel in how there is a risk of the intention for DetNet flows
not being met (because of an attack) and how the intention for non-DetNet
traffic may also not be met.


Related to the above is the fact that the identification of flows could be =
used
to specifically *not* include some of them as DetNet flows.  This is a
variation of the concern outlined in =C2=A76, but applied to non-DetNet flo=
ws, with
the potential starvation mentioned above.  Again, I would like to at least =
see
some discussion of this risk.

I don't follow - what is the risk that should be addressed?

=C2=A76 talks about potential privacy concerns due to the identification of
flows.  I interpret that as potentially being able to identify the user
(application, or both maybe).

As far as I understand the architecture, DetNet flows are identified at the
edge and then assigned to specific paths.  If the identification of flows
can be used to identify the user (for example), then it can be used to not
only attack specific DetNet flow, but also to decide to not provide
guarantees to a specific flow based on who the user or the application may
be.

I=E2=80=99m trying to point at a scenario where the identification may lead=
 to flag
a flow as non-DetNet =E2=80=94 and then (back to the initial point) potenti=
ally
starve it: eliminating the ability of that user to communicate.

The use case and problem statement documents outline specific applications =
that
may not have non-DetNet traffic, and the Introduction supports that.  Howev=
er,
the architecture described in this document may be used in more general
networks to provide guarantees to specific traffic...  IOW, even if the
intention is there, there is no guarantee that DetNet will only be used in =
the
expected use cases.

You're not requesting any change in the document here, right?

Right.  Just pointing out that not all deployments of DetNet may be in the
expected use cases, potentially exposing them to other risks, or other
applications.


Hope this makes more sense.

Thanks!

Alvaro.

--000000000000e9023005825777bb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

On February 20, 2019 at 4:11:45 PM, Lou Berger (lberger@labn.net) wrote:
 
Hi Alissa,
<=
font face=3D"Helvetica">=E2=80=A6Alvaro=E2=80=A6 :-)
Hi!

-----------------------------------------=
-----------------------------
DISCUSS:
----------------------------------------------------------------------

I support Mirja's and Alissa's DISCUSSes...and have a related set o=
f concerns
about the coexistence with non-DetNet traffic and privacy:

=C2=A73.3.1 talks about what I think is a hard to achieve balance between c=
oexisting
with non-DetNet traffic and keeping that traffic from disrupting DetNet flo=
ws. =20
Because of the constraints, the intent of prioritizing DetNet flows is clea=
r
(and that is ok), but that may result in starvation of non-DetNet
traffic...even if the text does explicitly say that it "must be avoide=
d".

I would like to see the potential case of starving non-DetNet traffic calle=
d
out somewhere. 
This is the objective of section 3.3.1=
.

I'm looking for something similar to the first paragraph in =C2=A75,
but focused on the non-DetNet traffic.
The current tex=
t reads:
3.3.1.  Coexi=
stence with normal traffic

   A DetNet network supports the dedication of a high proportion of the
   network bandwidth to DetNet flows.  But, no matter how much is
   dedicated for DetNet flows, it is a goal of DetNet to coexist with
   existing Class of Service schemes (e.g., DiffServ).  It is also
   important that non-DetNet traffic not disrupt the DetNet flow, of
   course (see Section 3.3.2 and Section 5).  For these reasons:

   o  Bandwidth (transmission opportunities) not utilized by a DetNet
      flow is available to non-DetNet packets (though not to other
      DetNet flows).

   o  DetNet flows can be shaped or scheduled, in order to ensure that
      the highest-priority non-DetNet packet is also ensured a worst-
      case latency.

   o  When transmission opportunities for DetNet flows are scheduled in
      detail, then the algorithm constructing the schedule should leave
      sufficient opportunities for non-DetNet packets to satisfy the
      needs of the users of the network.  Detailed scheduling can also
      permit the time-shared use of buffer resources by different DetNet
      flows.

   Starvation of non-DetNet traffic must be avoided, e.g., by traffic
   policing functions (e.g., [RFC2475]).  Thus, the net effect of the
   presence of DetNet flows in a network on the non-DetNet flows is
   primarily a reduction in the available bandwidth.


I think we need a little bit more to understand what you'd like to see =
changed or added.  Can you suggest text or what specific topic you'd li=
ke to see added/addressed? 
Yes, let me try to explain better=E2=80=A6wh=
ile comparing with the current text in =C2=A75, which basically says that e=
ven though the objective of DetNet is to provide bounded latency, a MIIM ma=
y delay the traffic and the objective may not be achieved. =C2=A0
For non-DetNet traffic, the objective is to no=
t starve it, while providing specific guarantees to the DetNet flows =E2=80=
=94 said other way (from the Introduction): "Unused reserved resources=
 are available to non-DetNet packets as long as all guarantees are fulfille=
d.=E2=80=9D =C2=A0However, the algorithms (maybe error, misconfiguration=E2=
=80=A6or even maliciously) may end up*not* constructing the schedule to lea=
ve sufficient opportunities for non-DetNet packets (as suggested in the tex=
t above from =C2=A73.3.1).
I see a pa=
rallel in how there is a risk of the intention for DetNet flows not being m=
et (because of an attack) and how the intention for non-DetNet traffic may =
also not be met.

=

Related to the above is the fact that the id=
entification of flows could be used
to specifically *not* include some of them as DetNet flows.  This is a
variation of the concern outlined in =C2=A76, but applied to non-DetNet flo=
ws, with
the potential starvation mentioned above.  Again, I would like to at least =
see
some discussion of this risk.
I don't follow - wha=
t is the risk that should be addressed?
=C2=A76 talks about potential priv=
acy concerns due to the identification of flows.=C2=A0 I interpret that as =
potentially being able to identify the user (application, or both maybe).
As far as I understand the architectur=
e, DetNet flows are identified at the edge and then assigned to specific pa=
ths.=C2=A0 If the identification of flows can be used to identify the user =
(for example), then it can be used to not only attack specific DetNet flow,=
 but also to decide to not provide guarantees to a specific flow based on w=
ho the user or the application may be.
I=E2=80=99m trying to point at a scenario where the identification may le=
ad to flag a flow as non-DetNet =E2=80=94 and then (back to the initial poi=
nt) potentially starve it: eliminating the ability of that user to communic=
ate.
The use case and problem=
 statement documents outline specific applications that
may not have non-DetNet traffic, and the Introduction supports that.  Howev=
er,
the architecture described in this document may be used in more general
networks to provide guarantees to specific traffic...  IOW, even if the
intention is there, there is no guarantee that DetNet will only be used in =
the
expected use cases.
You're not requesting any chan=
ge in the document here, right?
<=
/div>
Right.=C2=A0 Just pointing out that not al=
l deployments of DetNet may be in the expected use cases, potentially expos=
ing them to other risks, or other applications.

Hope this makes more =
sense.
Thanks!
Alvaro.


--000000000000e9023005825777bb--


From nobody Wed Feb 20 10:36:42 2019
Return-Path: 
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 8B963130E2F; Wed, 20 Feb 2019 10:36:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 g0T1PTU4r204; Wed, 20 Feb 2019 10:36:37 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 3EA14130E13; Wed, 20 Feb 2019 10:36:37 -0800 (PST)
Received: from 200116b82c6eb300094777de67d06586.dip.versatel-1u1.de ([2001:16b8:2c6e:b300:947:77de:67d0:6586]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gwWjR-0000kH-Go; Wed, 20 Feb 2019 19:36:33 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Mirja Kuehlewind (IETF)" 
In-Reply-To: <8b47372c-210a-5ecb-f563-788d84535279@labn.net>
Date: Wed, 20 Feb 2019 19:36:32 +0100
Cc: The IESG , draft-ietf-detnet-architecture@ietf.org, detnet@ietf.org, detnet-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <155066795164.31466.275999283339131275.idtracker@ietfa.amsl.com> <77e87eca-07df-99eb-9edb-7f6f18913dfd@labn.net> <5AF7514B-B8C9-48E5-B1F4-BF2139EB128A@kuehlewind.net> <8b47372c-210a-5ecb-f563-788d84535279@labn.net>
To: Lou Berger 
X-Mailer: Apple Mail (2.3445.9.1)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1550687797;86c3d419;
X-HE-SMSGID: 1gwWjR-0000kH-Go
Archived-At: 
Subject: Re: [Detnet]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-detnet-architecture-11=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2019 18:36:41 -0000

Hi Lou,

see below.

> Am 20.02.2019 um 17:24 schrieb Lou Berger :
>=20
> Hi Mirja,
>=20
>     See below.
>=20
> On 2/20/2019 11:06 AM, Mirja Kuehlewind (IETF) wrote:
>> Hi Lou,
>>=20
>> I=E2=80=99m happy to see that my concerns seem to be cover. So maybe =
this is mostly a point about wording. Please see below.
>>=20
>>> Am 20.02.2019 um 15:46 schrieb Lou Berger :
>>>=20
>>> Hi Mirja,
>>>=20
>>> I'm responding as doc shepherd (and chair). Thank you for your =
comments.  Please see below for specific responses.
>>>=20
>>> On 2/20/2019 8:05 AM, Mirja K=C3=BChlewind wrote:
>>>> Mirja K=C3=BChlewind has entered the following ballot position for
>>>> draft-ietf-detnet-architecture-11: Discuss
>>>>=20
>>>> 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.)
>>>>=20
>>>>=20
>>>> Please refer to =
https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>=20
>>>>=20
>>>> The document, along with other ballot positions, can be found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/
>>>>=20
>>>>=20
>>>>=20
>>>> =
----------------------------------------------------------------------
>>>> DISCUSS:
>>>> =
----------------------------------------------------------------------
>>>>=20
>>>> Thanks for addressing the tsv-art review comments  (and big thanks =
to Michael
>>>> and David!) and all the work done so far! I think the document is =
in good shape
>>>> and I only have one minor comment that I would like to see =
addressed/more
>>>> explicitly spelled out. However, this should be done quickly with =
potentially
>>>> 2-3 small changes in the draft. See below.
>>> The input from Michael and David certainly led to a much improved =
document.  If you can help the authors with some specific text =
suggestions that would be most helpful.
>>>=20
>>>=20
>>>> Given that DetNet traffic is often assumed to be not congestion =
controlled, it
>>>> is important that there is also some network function that makes =
sure the
>>>> source traffic stays within the requested bandwidth limit in-order =
to protect
>>>> non-Detnet traffic. This is to some extended discussed in section =
3.3.2 but I
>>>> think it should be more clearly spelled out that this would require =
a rate
>>>> limiting function at each DetNet source/relay (tunnel ingress). =
Currently sec
>>>> 3.3.2 says:
>>>>=20
>>>> "Filters and policers should be used in a DetNet network to
>>>>    detect if DetNet packets are received on the wrong interface, or =
at
>>>>    the wrong time, or in too great a volume."
>>>>=20
>>>> However, maybe this case of limiting non-congestion controlled =
traffic (in case
>>>> the source in not keeping to the limits on purpose/in order to =
cheat, because
>>>> it couldn't estimate the needed bandwidth requirement an better, or =
due to
>>>> timely fluctuations) could be explained more clearing and the =
respective
>>>> requirement to implement rate limiting could be state separately =
and more
>>>> strongly...?
>>> Section 3.2.1.1 days:
>>>=20
>>>   Ensuring adequate buffering requires, in turn, that the source, =
and
>>>   every DetNet node along the path to the destination (or nearly =
every
>>>   node, see Section 4.3.3) be careful to regulate its output to not
>>>   exceed the data rate for any DetNet flow, except for brief periods
>>>   when making up for interfering traffic.  Any packet sent ahead of =
its
>>>   time potentially adds to the number of buffers required by the =
next
>>>   hop DetNet node and may thus exceed the resources allocated for a
>>>   particular DetNet flow.
>>>=20
>>> Section 3.3.1 also says:
>>>=20
>>>   Starvation of non-DetNet traffic must be avoided, e.g., by traffic
>>>   policing functions (e.g., [RFC2475]).  Thus, the net effect of the
>>>   presence of DetNet flows in a network on the non-DetNet flows is
>>>   primarily a reduction in the available bandwidth.
>>>=20
>>> Is this not sufficient?  If not, can you suggest some additional =
language?
>> My question is mostly if you only need to protect _complete_ =
starvation or any over-use by DetNet flows and how you would do that. If =
the answer is to rate limit the DetNet flows at ingress to the allocated =
bandwidth, that would completely address my concern. However note that =
buffer dimensioning and rate limiting is not the same. Rate limiting is =
usually a scheduling question, e.g. using a token bucket scheme or a =
fixed non-work conserving scheduler. Therefore it would be nice to add =
one additional sentence in section 3.2 that spells that out directly. =
e.g. something like:
>>=20
>> =E2=80=9EIn order to protect non-DetNet traffic from potentially =
misbehaving DetNet-Traffic sources, rate limiting, e.g. using a token =
bucket scheme, at each tunnel ingress must be applied.=E2=80=9C
>=20
>> I=E2=80=99m sure you can adapt the wording to make it more =
DetNet-like language and maybe you also want to add another sentence =
explaining the problem, please feel free to do so but that=E2=80=99s =
more or less what I=E2=80=99m looking for.
>=20
> I do agree that we seem to be having a terminology issue here - and =
that we are on the same page with what should happen.  The terminology =
I've used/seen in past RFCs has usually used the terms 'shaping' and =
'policing' - and these are what we've been using within the WG.  For =
example, both of these terms are used in RFC2475 but 'rate limiting' is =
not. Would it work for you for the draft to use/adapt the rest of your =
language, but keep 'by traffic policing functions (e.g., [RFC2475])' =
rather than 'rate limiting, e.g. using a token bucket scheme,' ?
>=20
Indeed there is a wording issue here, but there is one important =
difference here. Policing as defined in [RFC2475] is the action of =
dropping to comply to a policy. While shaping is delaying to confirm to =
a traffic profile. A token bucket would do both=E2=80=A6 however, the =
important bit is not what you do but what your goal/policy/profile is, =
and the goal is to keep the traffic (on average) below a certain rate. =
This bit should be spelled out more explicitly.

Mirja




>>=20
>>>> One related comment on this sentence in Sec 3.1:
>>>>=20
>>>> "As DetNet provides allocated resources (including provisioned =
capacity)
>>>>    to DetNet flows the use of transport layer congestion control
>>>>    [RFC2914] by App-flows is explicitly not required."
>>>>=20
>>>> I guess congestion control should still be a requirement if the =
App-flow also
>>>> passes not-DetNet-aware segments of the path, e.g. maybe the first =
hop.
>>> This point is addressed in section 3.3.2
>>>=20
>>>   Note that the sending of App-flows that do not use transport layer
>>>   congestion control per [RFC2914] into a network that is not
>>>   provisioned to handle such DetNet traffic has to be treated as a
>>>   fault and prevented.
>>>=20
>>>> Usually
>>>> use of congestion control for application limited flows is also not =
a problem
>>>> if sufficient bandwidth is available. Also note that, as I stated =
above, the
>>>> important part for not requiring congestion control is actually not =
only that
>>>> resources are allocated but also that rate limiting is in place to =
make sure
>>>> resources usage cannot be exceeded above the reserved allocation. =
Maybe this
>>>> sentence could also be further clarified in the draft...?
>>> Is the above sufficient?  If not, can you suggest some additional =
language?
>> Maybe we can just extend the above statement a bit in order to be =
crystal clear about this, e.g.:
>>=20
>> "As DetNet flow are assumed to be rate-limited and DetNet is designed =
to provide sufficient allocated resources (including provisioned =
capacity), the use of transport layer congestion control [RFC2914] for =
end-to-end DetNet flows is not required, however, if resources are =
allocated appropriately, use of congestion control should not impact =
transmission negatively.=E2=80=9C
> Great!  (I'll leave it to the authors to do the final wording =
adaptation)
>>=20
>>>> And then one more small comment that is also related. Sec 3.2.2.2 =
says:
>>>>=20
>>>> "If packet replication and elimination is used over paths with
>>>>    resource allocation (Section 3.2.1), ..."
>>>>=20
>>>> My assumption was that all DetNet traffic is send over =
pre-allocated
>>>> resources...? If that is not true that has implication on =
congestion control
>>>> and needs some additional considerations. Can you please confirm =
that and maybe
>>>> clarify in the draft! Thanks!
>>> The intent was to cover sending over non-pre-allocated paths as a =
fault case, and cover it in section 3.3.2.
>> If that is the case, maybe we can just removed the half-sentence I =
cited above?
>=20
> WFM!
>=20
> Thank you!
>=20
>>=20
>> Thanks!
>> Mirja
>>=20
>>> In addition to the previously quoted text, the section also says:
>>>=20
>>>   PRF generated DetNet member flows also need to
>>>   be treated as not using transport layer congestion control even if
>>>   the original App-flow supports transport layer congestion control
>>>   because PREOF can remove congestion indications at the PEF and
>>>   thereby hide such indications (e.g., drops, ECN markings, =
increased
>>>   latency) from end systems.
>>>=20
>>> Does this address your concern?
>>>> =
----------------------------------------------------------------------
>>>> COMMENT:
>>>> =
----------------------------------------------------------------------
>>>>=20
>>>> I agree with Alexey and Benjamin that this document should be =
informational.
>>>> Informational documents can also have IETF consensus, so that =
cannot be the
>>>> reason to go for PS. However, this document does not specify a =
protocol or any
>>>> requirements that are mandatory to implement for interoperability =
and therefore
>>>> should not be PS.
>>>>=20
>>> I defer to the IESG and AD on this...
>>>=20
>>> Thank you!
>>>=20
>>> Lou
>>>=20
>>>> _______________________________________________
>>>> detnet mailing list
>>>> detnet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>=20
>>=20
>=20


From nobody Wed Feb 20 11:53:55 2019
Return-Path: 
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 DEF55130E82 for ; Wed, 20 Feb 2019 11:53:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 Pq9xrA-96tOF for ; Wed, 20 Feb 2019 11:53:52 -0800 (PST)
Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80159130E7E for ; Wed, 20 Feb 2019 11:53:52 -0800 (PST)
Received: from cmgw14.unifiedlayer.com (unknown [10.9.0.14]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id A09A2808CDEE4 for ; Wed, 20 Feb 2019 12:49:36 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id wXs8gWxnNXFO5wXs8gGSAO; Wed, 20 Feb 2019 12:49:36 -0700
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=L7588UTY54J0A0rC7sRuqr2BwX3NYYBUKv4TOmX6JGw=; b=gBuSJ4xSLxHrj3+GSPZaxCjTrm 2JPptvo6WfhFJ3OqeNB9VTkig8m/NAjkOL5svWAgUyQgRkPzNHSu4Umd0+L60IZeSeDKizbJ7kcav vhebJ252k699PBqLBYllFd8Py;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:37598 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gwXs8-001i7R-AX; Wed, 20 Feb 2019 12:49:36 -0700
To: "Mirja Kuehlewind (IETF)" 
Cc: draft-ietf-detnet-architecture@ietf.org, detnet@ietf.org, The IESG , detnet-chairs@ietf.org
References: <155066795164.31466.275999283339131275.idtracker@ietfa.amsl.com> <77e87eca-07df-99eb-9edb-7f6f18913dfd@labn.net> <5AF7514B-B8C9-48E5-B1F4-BF2139EB128A@kuehlewind.net> <8b47372c-210a-5ecb-f563-788d84535279@labn.net> 
From: Lou Berger 
Message-ID: 
Date: Wed, 20 Feb 2019 14:49:35 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 72.66.11.201
X-Source-L: No
X-Exim-ID: 1gwXs8-001i7R-AX
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:37598
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [Detnet]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-detnet-architecture-11=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2019 19:53:54 -0000

Hi Mirja,

On 2/20/2019 1:36 PM, Mirja Kuehlewind (IETF) wrote:
> Hi Lou,
>
> see below.
>
>> Am 20.02.2019 um 17:24 schrieb Lou Berger :
>>
>> Hi Mirja,
>>
>>      See below.
>>
>> On 2/20/2019 11:06 AM, Mirja Kuehlewind (IETF) wrote:
>>> Hi Lou,
>>>
>>> I’m happy to see that my concerns seem to be cover. So maybe this is mostly a point about wording. Please see below.
>>>
>>>> Am 20.02.2019 um 15:46 schrieb Lou Berger :
>>>>
>>>> Hi Mirja,
>>>>
>>>> I'm responding as doc shepherd (and chair). Thank you for your comments.  Please see below for specific responses.
>>>>
>>>> On 2/20/2019 8:05 AM, Mirja Kühlewind wrote:
>>>>> Mirja Kühlewind has entered the following ballot position for
>>>>> draft-ietf-detnet-architecture-11: 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:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>> DISCUSS:
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>> Thanks for addressing the tsv-art review comments  (and big thanks to Michael
>>>>> and David!) and all the work done so far! I think the document is in good shape
>>>>> and I only have one minor comment that I would like to see addressed/more
>>>>> explicitly spelled out. However, this should be done quickly with potentially
>>>>> 2-3 small changes in the draft. See below.
>>>> The input from Michael and David certainly led to a much improved document.  If you can help the authors with some specific text suggestions that would be most helpful.
>>>>
>>>>
>>>>> Given that DetNet traffic is often assumed to be not congestion controlled, it
>>>>> is important that there is also some network function that makes sure the
>>>>> source traffic stays within the requested bandwidth limit in-order to protect
>>>>> non-Detnet traffic. This is to some extended discussed in section 3.3.2 but I
>>>>> think it should be more clearly spelled out that this would require a rate
>>>>> limiting function at each DetNet source/relay (tunnel ingress). Currently sec
>>>>> 3.3.2 says:
>>>>>
>>>>> "Filters and policers should be used in a DetNet network to
>>>>>     detect if DetNet packets are received on the wrong interface, or at
>>>>>     the wrong time, or in too great a volume."
>>>>>
>>>>> However, maybe this case of limiting non-congestion controlled traffic (in case
>>>>> the source in not keeping to the limits on purpose/in order to cheat, because
>>>>> it couldn't estimate the needed bandwidth requirement an better, or due to
>>>>> timely fluctuations) could be explained more clearing and the respective
>>>>> requirement to implement rate limiting could be state separately and more
>>>>> strongly...?
>>>> Section 3.2.1.1 days:
>>>>
>>>>    Ensuring adequate buffering requires, in turn, that the source, and
>>>>    every DetNet node along the path to the destination (or nearly every
>>>>    node, see Section 4.3.3) be careful to regulate its output to not
>>>>    exceed the data rate for any DetNet flow, except for brief periods
>>>>    when making up for interfering traffic.  Any packet sent ahead of its
>>>>    time potentially adds to the number of buffers required by the next
>>>>    hop DetNet node and may thus exceed the resources allocated for a
>>>>    particular DetNet flow.
>>>>
>>>> Section 3.3.1 also says:
>>>>
>>>>    Starvation of non-DetNet traffic must be avoided, e.g., by traffic
>>>>    policing functions (e.g., [RFC2475]).  Thus, the net effect of the
>>>>    presence of DetNet flows in a network on the non-DetNet flows is
>>>>    primarily a reduction in the available bandwidth.
>>>>
>>>> Is this not sufficient?  If not, can you suggest some additional language?
>>> My question is mostly if you only need to protect _complete_ starvation or any over-use by DetNet flows and how you would do that. If the answer is to rate limit the DetNet flows at ingress to the allocated bandwidth, that would completely address my concern. However note that buffer dimensioning and rate limiting is not the same. Rate limiting is usually a scheduling question, e.g. using a token bucket scheme or a fixed non-work conserving scheduler. Therefore it would be nice to add one additional sentence in section 3.2 that spells that out directly. e.g. something like:
>>>
>>> „In order to protect non-DetNet traffic from potentially misbehaving DetNet-Traffic sources, rate limiting, e.g. using a token bucket scheme, at each tunnel ingress must be applied.“
>>> I’m sure you can adapt the wording to make it more DetNet-like language and maybe you also want to add another sentence explaining the problem, please feel free to do so but that’s more or less what I’m looking for.
>> I do agree that we seem to be having a terminology issue here - and that we are on the same page with what should happen.  The terminology I've used/seen in past RFCs has usually used the terms 'shaping' and 'policing' - and these are what we've been using within the WG.  For example, both of these terms are used in RFC2475 but 'rate limiting' is not. Would it work for you for the draft to use/adapt the rest of your language, but keep 'by traffic policing functions (e.g., [RFC2475])' rather than 'rate limiting, e.g. using a token bucket scheme,' ?
>>
> Indeed there is a wording issue here, but there is one important difference here. Policing as defined in [RFC2475] is the action of dropping to comply to a policy. While shaping is delaying to confirm to a traffic profile. A token bucket would do both… however, the important bit is not what you do but what your goal/policy/profile is, and the goal is to keep the traffic (on average) below a certain rate. This bit should be spelled out more explicitly.

I completely agree that both shaping and policing play a role in 
supporting DetNet services (independent of the specific mechanism 
selected for implementation) and think adding 'shaping' here - and 
perhaps other places that policing is mentioned is a worthwhile change.

Thanks!

Lou


>
> Mirja
>
>
>
>
>>>>> One related comment on this sentence in Sec 3.1:
>>>>>
>>>>> "As DetNet provides allocated resources (including provisioned capacity)
>>>>>     to DetNet flows the use of transport layer congestion control
>>>>>     [RFC2914] by App-flows is explicitly not required."
>>>>>
>>>>> I guess congestion control should still be a requirement if the App-flow also
>>>>> passes not-DetNet-aware segments of the path, e.g. maybe the first hop.
>>>> This point is addressed in section 3.3.2
>>>>
>>>>    Note that the sending of App-flows that do not use transport layer
>>>>    congestion control per [RFC2914] into a network that is not
>>>>    provisioned to handle such DetNet traffic has to be treated as a
>>>>    fault and prevented.
>>>>
>>>>> Usually
>>>>> use of congestion control for application limited flows is also not a problem
>>>>> if sufficient bandwidth is available. Also note that, as I stated above, the
>>>>> important part for not requiring congestion control is actually not only that
>>>>> resources are allocated but also that rate limiting is in place to make sure
>>>>> resources usage cannot be exceeded above the reserved allocation. Maybe this
>>>>> sentence could also be further clarified in the draft...?
>>>> Is the above sufficient?  If not, can you suggest some additional language?
>>> Maybe we can just extend the above statement a bit in order to be crystal clear about this, e.g.:
>>>
>>> "As DetNet flow are assumed to be rate-limited and DetNet is designed to provide sufficient allocated resources (including provisioned capacity), the use of transport layer congestion control [RFC2914] for end-to-end DetNet flows is not required, however, if resources are allocated appropriately, use of congestion control should not impact transmission negatively.“
>> Great!  (I'll leave it to the authors to do the final wording adaptation)
>>>>> And then one more small comment that is also related. Sec 3.2.2.2 says:
>>>>>
>>>>> "If packet replication and elimination is used over paths with
>>>>>     resource allocation (Section 3.2.1), ..."
>>>>>
>>>>> My assumption was that all DetNet traffic is send over pre-allocated
>>>>> resources...? If that is not true that has implication on congestion control
>>>>> and needs some additional considerations. Can you please confirm that and maybe
>>>>> clarify in the draft! Thanks!
>>>> The intent was to cover sending over non-pre-allocated paths as a fault case, and cover it in section 3.3.2.
>>> If that is the case, maybe we can just removed the half-sentence I cited above?
>> WFM!
>>
>> Thank you!
>>
>>> Thanks!
>>> Mirja
>>>
>>>> In addition to the previously quoted text, the section also says:
>>>>
>>>>    PRF generated DetNet member flows also need to
>>>>    be treated as not using transport layer congestion control even if
>>>>    the original App-flow supports transport layer congestion control
>>>>    because PREOF can remove congestion indications at the PEF and
>>>>    thereby hide such indications (e.g., drops, ECN markings, increased
>>>>    latency) from end systems.
>>>>
>>>> Does this address your concern?
>>>>> ----------------------------------------------------------------------
>>>>> COMMENT:
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>> I agree with Alexey and Benjamin that this document should be informational.
>>>>> Informational documents can also have IETF consensus, so that cannot be the
>>>>> reason to go for PS. However, this document does not specify a protocol or any
>>>>> requirements that are mandatory to implement for interoperability and therefore
>>>>> should not be PS.
>>>>>
>>>> I defer to the IESG and AD on this...
>>>>
>>>> Thank you!
>>>>
>>>> Lou
>>>>
>>>>> _______________________________________________
>>>>> detnet mailing list
>>>>> detnet@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/detnet
> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet


From nobody Wed Feb 20 13:21:17 2019
Return-Path: 
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 70C7C12D4E7; Wed, 20 Feb 2019 13:21:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level: 
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mit.edu
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 8Iz9rSz9TYWA; Wed, 20 Feb 2019 13:21:11 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810094.outbound.protection.outlook.com [40.107.81.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8A09128AFB; Wed, 20 Feb 2019 13:21:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1;  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W6e2w3mvBg45ZWGVXCzdWMevXTxeDuOQgiCGXwXYqqc=; b=cIp1ERmvhfvNfxdpEcj+yVVexHMDMkvs3+boUmvxX+YBUhAIii+Rcteoif+6H8SgdsWLwPbFG3Dl2ICTMnEYplq3gURweN/csuFEYpF/BZUy94UnmWyq8w9bYxNAkNwfrq/KSjKdngw4aSuv1qPx/zZ2GgHV96IE92ulGlk4Pn8=
Received: from MWHPR01CA0039.prod.exchangelabs.com (2603:10b6:300:101::25) by BYAPR01MB5176.prod.exchangelabs.com (2603:10b6:a03:7f::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.19; Wed, 20 Feb 2019 21:21:09 +0000
Received: from CO1NAM03FT029.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::205) by MWHPR01CA0039.outlook.office365.com (2603:10b6:300:101::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.15 via Frontend Transport; Wed, 20 Feb 2019 21:21:09 +0000
Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu;
Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT029.mail.protection.outlook.com (10.152.80.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Wed, 20 Feb 2019 21:21:09 +0000
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1KLL5ZX000981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Feb 2019 16:21:07 -0500
Date: Wed, 20 Feb 2019 15:21:05 -0600
From: Benjamin Kaduk 
To: Lou Berger 
CC: , , The IESG , 
Message-ID: <20190220212104.GK69562@kduck.mit.edu>
References: <155063426136.20704.6779201119170972943.idtracker@ietfa.amsl.com>  <20190220160743.GD69562@kduck.mit.edu> <36c4ce97-5c4a-89ab-d648-3e7705a6acd3@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <36c4ce97-5c4a-89ab-d648-3e7705a6acd3@labn.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(39860400002)(376002)(136003)(346002)(2980300002)(199004)(189003)(104016004)(7696005)(8676002)(53416004)(336012)(8936002)(86362001)(4326008)(54906003)(186003)(246002)(5660300002)(14444005)(106466001)(126002)(305945005)(426003)(26005)(476003)(956004)(47776003)(11346002)(2906002)(2870700001)(75432002)(53546011)(486006)(23756003)(93886005)(88552002)(76176011)(33656002)(6916009)(478600001)(356004)(229853002)(26826003)(446003)(50466002)(55016002)(36906005)(6246003)(58126008)(786003)(316002)(1076003)(106002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR01MB5176; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; 
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 355cca06-4a29-4aa6-5e22-08d697795551
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:BYAPR01MB5176; 
X-MS-TrafficTypeDiagnostic: BYAPR01MB5176:
X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB5176; 20:MqlAJrffhN/4R1f4MY0H9JNLw4YEONHNHYHpC8Bc2gePaBrQyHrcqBoiXhQ05iZy9BlZemRSlDrs9gvPaLf4AAMckZR7KlEZh6vBhZqESe/Uk1emwMPrLsOCul44g7yu1U4KhbcAQrNYkyKxZwmhHpnZ5PzQpgDRbn4A/kGMK6UYEZCNOIV1M+OyZeBxAEq68z8nGaFDrBbfM7AtqV4xR0h+mArt1tFkkQKYyuJLBN5TdN95IcTDxxRyD4Fhjhg/sesrLHasmyqbwp8UYj1Dzot9cO36WlvPVH1KqgSxlUZGjYYmLwYE/6TdrbgFFN0U81wkmrn5lKCmuelnCVcV8hZIzL+XftotvsSTFPKTq3r9OuwGsEM+MGnzvTsgYgL47zJbT2DUwpNXGj+6fm6LlW0DGlwfSOeOJzzWqqsKhbsI/NcEAs4QuVuioo7CFkUU7FA57DBprt7sWet68Yrdo94o2XZoTDSHwBMQ/ttkULe9UgfLmX5wZVjDNOXV2QEK5U372cIipOMSdmQYq0MRsbcBC+bFAwbA224FEBVNduoCTwE1T4IKp4aJub7D2uVjw5W7u+G+ighGH1YYvXiODQ4yZJDL+OcBtGElfHedhuE=
X-Microsoft-Antispam-PRVS: 
X-Forefront-PRVS: 0954EE4910
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BYAPR01MB5176; 23:SuhLmBY+V+UwKVlXPFMBKHRZEa+BzosL8eHql+P?= =?iso-8859-1?Q?jH+A7HDnD1fBrGre5JNO1lptqyN7zoJJRsGYUdpAzYqWDCNKoFXYijBgOj?= =?iso-8859-1?Q?Axhwo6/ar3k1ub1/GJ56o8nI+4qjL4KUEfOOTg7yGFuZ2L/6ZZyuRbBmxk?= =?iso-8859-1?Q?3vBxWdoJlu/hNEeIcRi3BNNXmHRq6gD4sx6mb/ZLMi0mZts9RCnVJ+/Gr9?= =?iso-8859-1?Q?SVNRdv7VModU2tsgCocJPksFAfrDHf7qbyoY5210FSYx2IJ3I+960xn0wj?= =?iso-8859-1?Q?KXTr/o2GfVlrtfYyCldaH0xhUikTnrkqifteytTa387TntZpQd1xP6hBCj?= =?iso-8859-1?Q?bYqHA6ZdRoPRfnRFCHMD9tb9tdtVgHpJ0z20SITzMf6D13EThKA0A9g7Rh?= =?iso-8859-1?Q?Wv2irIUzVxhJcM3vueXVrGQcXb5TuCktg/457V15n4OPPB089aY/bsmxe2?= =?iso-8859-1?Q?cY/+d1/+cvee+qh/06sR7qxMybPc2OWQtvACfeAOxfV2YCuZWXNc6vl3tk?= =?iso-8859-1?Q?HdTxVXWsyfSygbgPovg9LzqdBGPJ6L2Bpxas5sTMzSrL3oY25HD9oGzOqw?= =?iso-8859-1?Q?zNCm0o2Nvq5Zs+x7vanhBbvr/Mf/sIa+gj3V5WhZmGFqhCn+rv36tZxHFB?= =?iso-8859-1?Q?Al2cAIqOOQk9+MSEjiZB8dTqArmgib7wvCtnBSijhhLPohNWId9fRvxSAt?= =?iso-8859-1?Q?D95uxW78dIY3zm1I9aub3ShSefXJxIJbGGoaSyL5jKBzMlK27Ja1XX5RWV?= =?iso-8859-1?Q?IPkvrvMj/G1jGm5G0+fwMRf4p1VC5VOmt6ZJ/0rG5jhfCLZtdb5eRsDR1V?= =?iso-8859-1?Q?yM61k6XFBSVVefv8eLQdh/GLRfKIE9Fkvf+l3MpZMi+b5nTf30lkh/VB1u?= =?iso-8859-1?Q?s2ierPpaXDBIf3x3GNcMmtt7cFPsJ04X7mXp8r6RJGQ3qwhSc6+cMw3Ebn?= =?iso-8859-1?Q?97Fb7qtHvuwxp/KkC4JORmjTZvhR1UdLWsZyPffFxvTaaYaYrUWQlXnf71?= =?iso-8859-1?Q?ZgWvLhPcodeDjBOR0bKR8MX+DRFh5HU0JLeaOupTDuIpA+bS1oyt5hk/6P?= =?iso-8859-1?Q?YBx8XNy94XcXaKtRyXK+XMy+Bm3VWrSOYfd7bwVGVxymDYEwsXMxopJ9xj?= =?iso-8859-1?Q?7v36TULAnxorC5ZML3mQN5U16G/JIVVGlXgrPcSGZImIY2Ic7udpXjDVYc?= =?iso-8859-1?Q?uATOwu0kz5qmri/6ji/mR3zb+sAaknQG9jjDp82qA53ebRhRNw67sApdfU?= =?iso-8859-1?Q?k5S0nS4eF6jjDewHqDwP+mGIA8nAJ4dYGItfcSw=3D=3D?=
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: 1S0qnrYU7bRABxvdV9eLOPzM6L7vZ3ZIYBHqKLj35Fd2TVVnbOWmXZWNFSE7ivKHMmK1Dlpck1d0qnNd0Q8Ig+WJjUq+Jnk5u3ZNzka8nH17926X4z3waqIUWq6y9jmilJeLZ+d7ipn7Ru7WuLEHGXgYZTcJ97Q3QeBqWBHKdwD5VFciiGEB88u/Zoo7VhdhJc90SFaH740lJHXyqUFNxhkqzGqeVKgFZWiX368jTN7tceY+eML1RAcrD9YJlTWM9Y3a/hN38Rtk5XDqfySHi01YQpUwhfuA4fy8zzvEwUzrz8/oRsEuluhwGjGBahLdzHKzr35nCT9+AKNTGxRINlSex3XETZ5hA67f4JwPbO/DP8e97Nk8kgHsbQrXUtcP0a1OgU/s1L8h3npMZJUMGhMseHrgyPjyWuiDmcJFco0=
X-OriginatorOrg: mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Feb 2019 21:21:09.3593 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 355cca06-4a29-4aa6-5e22-08d697795551
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11];  Helo=[outgoing.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR01MB5176
Archived-At: 
Subject: Re: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2019 21:21:14 -0000

Hi Lou,

On Wed, Feb 20, 2019 at 11:34:11AM -0500, Lou Berger wrote:
> On 2/20/2019 11:07 AM, Benjamin Kaduk wrote:
> > On Wed, Feb 20, 2019 at 09:33:34AM -0500, Lou Berger wrote:
> >> On 2/19/2019 10:44 PM, Benjamin Kaduk wrote:
> >>> I note that the DETNET WG is explicitly chartered with a work item for the
> >>> "overall architecture: This work encompasses ... and security aspects".
> >>> It seems incomplete to specify an architecture for a topic such as
> >>> deterministic networking without specifically considering what threats are
> >>> and are not in scope to be protected against.
> >> The working group certainly recognizes that security is an important
> >> topic and necessary part of the work. The WG's approach to ensure that
> >> this significant topic is sufficiently covered is to have a document
> >> dedicated to the topic. As you note below this work,
> >> draft-ietf-detnet-security, is not at the same level maturity - so
> >> please stay tuned. Of course, the WG would welcome any input on this
> >> security draft now or even a full early-review or security area advisor.
> > I do appreciate that the WG has taken the time to work on a dedicated
> > security document, that goes through the (tedious!) effort to tabulate the
> > various known attacker capabilities, threats, and their interactions.
> >
> > What I think is missing from the high-level architecture document is a
> > sense for what security goals the architecture intends to achieve.  It's
> > fine to have this be separate from the nitty-gritty stuff in the separate
> > document, but these high-level questions can have an impact on the
> > high-level design of the protocol ecosystem as a whole.  We have mounds of
> > examples of "come up with a design; bolt security on as an afterthought"
> > working poorly or being nigh-impossible, and I haven't seen any attempt at
> > justification for why doing so here is likely to be any different.
> > Including the security concepts from the start and wholly integrating them
> > into the system tends to produce a much more elegant design and smoother
> > outcomes all around.
> 
> We went back and forth on how much of the security topic to include in 
> the architecture document and settled on the current text of section 5 
> where just high level security requirements are identified. From your 
> list below, the architecture covers the points you raise (non-detnet 
> traffic impacting detnet traffic, and detnet traffic trying to use more 
> than its allocation) mainly from a service delivery perspective. It 
> does mention "shaping" as a security concern, the document could expand 
> these if helpful. But I think the real discussion point is how much of 
> the security details should be in the base (vs dedicated) document -- 
> and that you disagree with where the WG has drawn the line. Is this 
> correct?

Well, it's not as much that I disagree about where the line is drawn, as
that I disagree with the characterization as "high level security
requirements".

The first paragraph covers topics worth including here, certainly -- an
attacker that can introduce delay can inherently break the DetNet
guarantees, and there is no further defense.  But the text could probably
go further than its current version and explicitly call out that no
technical measures can defend against such delay, other than by
rerouting/avoiding the compromised position.

The second paragraph also covers a topic worth noting, that entropy and
Murphy as as important of risks to consider as active attacks.

The rest of the section/list don't seem to match up with the high-level
view, though -- "protection of the signaling protocol", but protection
against what?  Authentication and authorization are important parts of
security, but authorization is tied to actions and entities, not just
entities in vacuo.  For "identification and shaping of DetNet flows", if
security must cover them, what security properties are needed.  Do we need
to provide integrity protection for the marking, or confidentiality
protection, too?  Does authentication/integrity need to be provided for
in-line or are out-of-band considerations in play?

The rest of the document presents a good high level picture of what pieces
will be involved in a system, and how they fit together.  I'm hoping to see
a high-level picture of what attacks/failures the architecture does and
does not aim to protect against.  It's somewhat implied that we need to
protect against the failure of any single node or link (except at the
boundary) due to random faults; explicitly saying this would be a perfect
hting to include in the security considerations here!  Once we get beyond
entropy as an attack, into more active attack scenarios, though, we need to
consider what capabilities an attacker might have.  Do we protect against
an entity with the ability to inject various forms of traffic?  Modify or
drop valid traffic?  Are there any (classes of) credentials that we assume
must be securely held, or will we attempt to protect against attackers that
have some privilege within the system?  (Note that misbehaving hardware can
sometimes present as similar or identical to such an attacker.)

Does this give a better picture of what I'm thinking of as "high-level
security requirements"?  I don't necessarily need details of specific
hardware or credentials at play, and certainly not for the solutions, but I
want to have a clear picture of what the scope of future security analysis
will be.  "How will I be able to tell if the actual protocols meet the
security requirements of the architecture?"

-Benjamin


From nobody Wed Feb 20 14:14:54 2019
Return-Path: 
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 79298129AA0; Wed, 20 Feb 2019 14:14:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 d3qjf6vYiTnW; Wed, 20 Feb 2019 14:14:51 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B40A128701; Wed, 20 Feb 2019 14:14:51 -0800 (PST)
Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1KM5jFq002388; Wed, 20 Feb 2019 17:14:50 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 2qseyw10au-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Feb 2019 17:14:50 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x1KMEmKH020402; Wed, 20 Feb 2019 17:14:49 -0500
Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [135.66.87.31]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x1KMEigs020244; Wed, 20 Feb 2019 17:14:44 -0500
Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [127.0.0.1]) by zlp27127.vci.att.com (Service) with ESMTP id 3ED344048B50; Wed, 20 Feb 2019 22:14:44 +0000 (GMT)
Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (unknown [130.9.129.151]) by zlp27127.vci.att.com (Service) with ESMTPS id 2C11D4048B49; Wed, 20 Feb 2019 22:14:44 +0000 (GMT)
Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.22]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0435.000; Wed, 20 Feb 2019 17:14:43 -0500
From: "BRUNGARD, DEBORAH A" 
To: Lou Berger , Benjamin Kaduk , The IESG 
CC: "draft-ietf-detnet-architecture@ietf.org" , "detnet@ietf.org" , "detnet-chairs@ietf.org" 
Thread-Topic: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: status of document?
Thread-Index: AdTJYxyv8qAmYrpWRaee3sZVBbkuAg==
Date: Wed, 20 Feb 2019 22:14:42 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.10.197.133]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-20_17:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=429 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902200148
Archived-At: 
Subject: Re: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: status of document?
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2019 22:14:53 -0000

DQoNCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IENPTU1FTlQ6DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBJ
IGFncmVlIHdpdGggQWxleGV5IHRoYXQgSW5mb3JtYXRpb25hbCB3b3VsZCAoYWxzbykgYmUgYSBm
aW5lIHN0YXR1cyANCj4+IGluIHdoaWNoIHRvIHB1Ymxpc2ggdGhpcyBkb2N1bWVudC4NCg0KPkkg
ZGVmZXIgdG8gdGhlIElFU0cgYW5kIG91ciBBRC4NCg0KPkkgdGhpbmsgdGhlIGF1dGhvcnMgY2Fu
IGFkZHJlc3MvcmVzcG9uZCB0byB0aGUgcmVtYWluaW5nIGNvbW1lbnRzLg0KDQpbZGVib3JhaF0N
CkFzIHRoZSBTaGVwaGVyZCB3cml0ZXVwIHN0YXRlcywgdGhpcyBkb2N1bWVudCBoYXMgbm90IG9u
bHkgaW50ZXItSUVURiBhcmVhIGltcGFjdCBidXQgYWxzbyBpbnRlci1TRE8gaW1wYWN0LCBub3Rh
Ymx5IElFRUUuIFdpdGggdGhlIGh1Z2UgaW50ZXJlc3QgaW4gbmV0d29yayBzbGljaW5nIGZvciBw
cm92aWRpbmcgbG93IGxhdGVuY3kgZW5kLXRvLWVuZCBwYXRocywgdGhpcyB3b3JrIHdpbGwgaGF2
ZSBpbXBhY3RzIG9uIGRpc2N1c3Npb25zIGluIElUVS1ULCBCQkYsIDNHUFAsIGV0Yy4gV2hpbGUg
SW5mb3JtYXRpb25hbCBkb2N1bWVudHMgaGF2ZSB0aGUgc3RhdHVzIG9mIElFVEYgY29uc2Vuc3Vz
LCB0aGV5IGFyZSBjbGFzc2VkIGFzICJpbmZvcm1hdGlvbmFsIiB0byB0aGUgY29tbXVuaXR5LiBU
aGlzIGRvY3VtZW50IGlzIG1vcmUgdGhhbiBpbmZvcm1hdGlvbmFsLCBpdCBpcyBhIHNwZWNpZmlj
YXRpb24gb2YgdGhlIGJ1aWxkaW5nIGJsb2NrcyBhbmQgbWVjaGFuaXNtcyB3aGljaCBhIHNvbHV0
aW9uIGlzIHJlcXVpcmVkIHRvIHN1cHBvcnQsIGJvdGggd2l0aCByZXNwZWN0IHRvIElFVEYgbmV0
d29yayBwcm90b2NvbHMgYW5kIElFRUUgVFNOLiBJIHN1cHBvcnRlZCB0aGF0IGl0IHNob3VsZCBi
ZSBzdGFuZGFyZHMgdHJhY2suDQoNCkZvciB0aG9zZSBub3QgZmFtaWxpYXIsIHRoZSBmb2xsb3dp
bmcgUkZDcyB3ZXJlIGFsbCBkZXNpZ25hdGVkIFBTOg0KUkZDMzAzMSBNUExTIEFyY2hpdGVjdHVy
ZSwgUkZDMzk0NSBHTVBMUyBBcmNoaXRlY3R1cmUsIFJGNTk2MCBNUExTLVRQIERhdGEgUGxhbmUg
QXJjaGl0ZWN0dXJlLCBSRkM4Mjc5IEJpZXIgQXJjaGl0ZWN0dXJlLg0KDQo=


From nobody Thu Feb 21 06:11:26 2019
Return-Path: 
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 926E6130FDA; Thu, 21 Feb 2019 06:11:23 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Suresh Krishnan 
To: "The IESG" 
Cc: draft-ietf-detnet-architecture@ietf.org, Lou Berger , detnet-chairs@ietf.org, lberger@labn.net, detnet@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155075828359.8615.9538259641487527490.idtracker@ietfa.amsl.com>
Date: Thu, 21 Feb 2019 06:11:23 -0800
Archived-At: 
Subject: [Detnet] Suresh Krishnan's No Objection on draft-ietf-detnet-architecture-11: (with COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2019 14:11:24 -0000

Suresh Krishnan has entered the following ballot position for
draft-ietf-detnet-architecture-11: 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/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:
https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/



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

* Section 3.2.1.1.

Given that we also know some of the downsides as well of large buffers, I think
a pointer to some background might be warranted here. I would recommend a basic
reference to something like

Bufferbloat: Dark Buffers in the Internet, Communications of the ACM, January
2012,

* Section 3.2.2.2.

It is not obvious to me how the POF cannot be the last operation at the
receiver. Can you clarify? Also, do intermediate nodes apply the POF? I can see
the need for them to do PRF and PEFs but I am not sure applying the POF at
intermediate nodes can necessarily help the low latency and low jitter goals.

   The order in which a DetNet node applies PEF, POF, and PRF to a
   DetNet flow is implementation specific.

* Section 3.2.3.

RFC7426 does not contain much specific information about explicit route setup.
Is there a particular section you want to point to. If not, I don't think this
reference is of much use. RFC8453 is listed twice.

* Section 3.3.1.

Not sure why this is a requirement but I do wish to note that there are no such
worst-case latency guarantees for best effort traffic (aka non-Detnet) in
current networks. Can you clarify?

   o  DetNet flows can be shaped or scheduled, in order to ensure that
      the highest-priority non-DetNet packet is also ensured a worst-
      case latency.

* Section 4.1.1.

This text "Peers with Duplicate elimination." seems to be completely out of
place under the "Packet sequencing" heading below Figure 2. Copy and paste
error?

* Section 4.3.2.

I found the expression "number of bit times" confusing. I have understood "bit
time" to mean the amount of time taken to emit a bit from a network interface.
Based on that definition, this expression does not make sense. Is there a
better reference/definition of what you mean?

* Section 4.5.

There might be some other recent IETF defined mechanisms that might be relevant
to mention here as well. e.g. RFC8289 (Codel), RFC8033 (PIE) etc.

* Section 4.7.2.

While IPv6 does offer a mechanism to add/remove a flow id (flow label) not sure
what kind of mapping you were thinking for IPv4. If this is not possible, I
think a note to that effect might be useful here.

* Sections 5 and 6

I also support Alissa and Benjamin's DISCUSSes (on privacy and security) and
would like to see them addressed.



From nobody Thu Feb 21 11:35:39 2019
Return-Path: 
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 929F813114C for ; Thu, 21 Feb 2019 11:35:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 7bm9_r1t15Wb for ; Thu, 21 Feb 2019 11:35:35 -0800 (PST)
Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74B45131146 for ; Thu, 21 Feb 2019 11:35:35 -0800 (PST)
Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id DB7D78137A53B for ; Thu, 21 Feb 2019 12:35:31 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id wu83gaGK6D8Rpwu83gydS2; Thu, 21 Feb 2019 12:35:31 -0700
X-Authority-Reason: nr=8
X-Authority-Analysis: $(_cmae_reason
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=H9fskMPItLXhjqfIm+YfvWuvlyOZUs0M/K65YbUkmyY=; b=dP7thZ/Nvp3s2sEUQ5StdqFudT Ny0FgWhkHRZw8w1aGkTX/s6MDIgEQl6dDwrSI27xZ18PQ/0BnTWfsQ/M8qxlaPge8z5AioDwrDr1Y 0Cwcs3GYMnERc26aJDuoDKet0;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:53326 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gwu83-003wfa-Eh; Thu, 21 Feb 2019 12:35:31 -0700
To: Alvaro Retana , The IESG 
Cc: detnet-chairs@ietf.org, detnet@ietf.org, draft-ietf-detnet-architecture@ietf.org
References: <155067820715.31361.3746519237969586434.idtracker@ietfa.amsl.com> <108f9294-fb9d-557a-011a-6a53156bcb37@labn.net> 
From: Lou Berger 
Message-ID: <7056c886-3aa9-2d85-7824-ee5f1ac9bb33@labn.net>
Date: Thu, 21 Feb 2019 14:35:30 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 72.66.11.201
X-Source-L: No
X-Exim-ID: 1gwu83-003wfa-Eh
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:53326
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [Detnet] Alvaro Retana's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2019 19:35:38 -0000

On 2/20/2019 1:24 PM, Alvaro Retana wrote:
> On February 20, 2019 at 4:11:45 PM, Lou Berger (lberger@labn.net 
> ) wrote:
>> Hi Alissa,
>
> …Alvaro… :-)
>
woops -- too many messages. ;-)


> Hi!
>
>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> I support Mirja's and Alissa's DISCUSSes...and have a related set of concerns
>>> about the coexistence with non-DetNet traffic and privacy:
>>>
>>> §3.3.1 talks about what I think is a hard to achieve balance between coexisting
>>> with non-DetNet traffic and keeping that traffic from disrupting DetNet flows.
>>> Because of the constraints, the intent of prioritizing DetNet flows is clear
>>> (and that is ok), but that may result in starvation of non-DetNet
>>> traffic...even if the text does explicitly say that it "must be avoided".
>>>
>>> I would like to see the potential case of starving non-DetNet traffic called
>>> out somewhere.
>>
>> This is the objective of section 3.3.1.
>>
>>
>>> I'm looking for something similar to the first paragraph in §5,
>>> but focused on the non-DetNet traffic.
>>
>> The current text reads:
>>
>> 3.3.1.  Coexistence with normal traffic
>>
>>     A DetNet network supports the dedication of a high proportion of the
>>     network bandwidth to DetNet flows.  But, no matter how much is
>>     dedicated for DetNet flows, it is a goal of DetNet to coexist with
>>     existing Class of Service schemes (e.g., DiffServ).  It is also
>>     important that non-DetNet traffic not disrupt the DetNet flow, of
>>     course (see Section 3.3.2 and Section 5).  For these reasons:
>>
>>     o  Bandwidth (transmission opportunities) not utilized by a DetNet
>>        flow is available to non-DetNet packets (though not to other
>>        DetNet flows).
>>
>>     o  DetNet flows can be shaped or scheduled, in order to ensure that
>>        the highest-priority non-DetNet packet is also ensured a worst-
>>        case latency.
>>
>>     o  When transmission opportunities for DetNet flows are scheduled in
>>        detail, then the algorithm constructing the schedule should leave
>>        sufficient opportunities for non-DetNet packets to satisfy the
>>        needs of the users of the network.  Detailed scheduling can also
>>        permit the time-shared use of buffer resources by different DetNet
>>        flows.
>>
>>     Starvation of non-DetNet traffic must be avoided, e.g., by traffic
>>     policing functions (e.g., [RFC2475]).  Thus, the net effect of the
>>     presence of DetNet flows in a network on the non-DetNet flows is
>>     primarily a reduction in the available bandwidth.
>>
>>
>> I think we need a little bit more to understand what you'd like to see changed or added.  Can you suggest text or what specific topic you'd like to see added/addressed?
>
> Yes, let me try to explain better…while comparing with the current 
> text in §5, which basically says that even though the objective of 
> DetNet is to provide bounded latency, a MIIM may delay the traffic and 
> the objective may not be achieved.
>
> For non-DetNet traffic, the objective is to not starve it, while 
> providing specific guarantees to the DetNet flows — said other way 
> (from the Introduction): "Unused reserved resources are available to 
> non-DetNet packets as long as all guarantees are fulfilled.”  However, 
> the algorithms (maybe error, misconfiguration…or even maliciously) may 
> end up*not* constructing the schedule to leave sufficient 
> opportunities for non-DetNet packets (as suggested in the text above 
> from §3.3.1).
>
> I see a parallel in how there is a risk of the intention for DetNet 
> flows not being met (because of an attack) and how the intention for 
> non-DetNet traffic may also not be met.
>
Okay, this sounds like basically the same point that Benjamin was 
making, i.e., there must be mechanisms preventing non-detnet traffic 
from impacting detnet traffic, and detnet traffic trying to use more 
than its allocation and impacting non-detnet traffic. Is this correct or 
are you asking for something different/additional?


>
>>> Related to the above is the fact that the identification of flows could be used
>>> to specifically *not* include some of them as DetNet flows.  This is a
>>> variation of the concern outlined in §6, but applied to non-DetNet flows, with
>>> the potential starvation mentioned above.  Again, I would like to at least see
>>> some discussion of this risk.
>>
>> I don't follow - what is the risk that should be addressed?
>>
> §6 talks about potential privacy concerns due to the identification of 
> flows.  I interpret that as potentially being able to identify the 
> user (application, or both maybe).
>
Currently flow identification is based on IP headers (6 tuple) and/or 
MPLS labels.  So DetNet has the same privacy concerns as standard IP/MPLS.


> As far as I understand the architecture, DetNet flows are identified 
> at the edge and then assigned to specific paths.  If the 
> identification of flows can be used to identify the user (for 
> example), then it can be used to not only attack specific DetNet flow, 
> but also to decide to not provide guarantees to a specific flow based 
> on who the user or the application may be.
>
Given DetNet flow identification, is this any different than standard PBR?


> I’m trying to point at a scenario where the identification may lead to 
> flag a flow as non-DetNet — and then (back to the initial point) 
> potentially starve it: eliminating the ability of that user to communicate
>
I do think this is possible, just like a policy based routing can be 
used to blackhole any IP traffic based on its IP headers.


> .
>
>>> The use case and problem statement documents outline specific applications that
>>> may not have non-DetNet traffic, and the Introduction supports that.  However,
>>> the architecture described in this document may be used in more general
>>> networks to provide guarantees to specific traffic...  IOW, even if the
>>> intention is there, there is no guarantee that DetNet will only be used in the
>>> expected use cases.
>>
>> You're not requesting any change in the document here, right?
>>
> Right.  Just pointing out that not all deployments of DetNet may be in 
> the expected use cases, potentially exposing them to other risks, or 
> other applications.
>
>
Okay.

Thanks,

Lou


> Hope this makes more sense.
>
> Thanks!
>
> Alvaro.
>


From nobody Thu Feb 21 12:32:25 2019
Return-Path: 
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 CBA99130E83 for ; Thu, 21 Feb 2019 12:32:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 fUKHSuF6oOBp for ; Thu, 21 Feb 2019 12:32:20 -0800 (PST)
Received: from alt-proxy16.mail.unifiedlayer.com (alt-proxy16.mail.unifiedlayer.com [70.40.197.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A560130E7F for ; Thu, 21 Feb 2019 12:32:20 -0800 (PST)
Received: from CMGW (unknown [10.9.0.13]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 80B831E076D for ; Thu, 21 Feb 2019 13:32:17 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id wv0zgT7SZeyBxwv0zg1vqn; Thu, 21 Feb 2019 13:32:17 -0700
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=WEJ1w0REHCzPyujUKH+cecrupFsAHyKbRlYh9VAEkwI=; b=dcVkoS7f67G6wy6DDg4sZ6XGZ+ dt6VVIYK7d9z0XkG2tBzB6MsOviuOU7KLQVGqoKjHV2dpLoA9O6BWVYpcCcWo8Jtr8IqOo2ny2Uhj bYucTPOcRYa2GgdOIaUntJ1GT;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:59514 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gwv0z-004E5w-3T; Thu, 21 Feb 2019 13:32:17 -0700
To: Benjamin Kaduk 
Cc: draft-ietf-detnet-architecture@ietf.org, detnet@ietf.org, The IESG , detnet-chairs@ietf.org
References: <155063426136.20704.6779201119170972943.idtracker@ietfa.amsl.com>  <20190220160743.GD69562@kduck.mit.edu> <36c4ce97-5c4a-89ab-d648-3e7705a6acd3@labn.net> <20190220212104.GK69562@kduck.mit.edu>
From: Lou Berger 
Message-ID: <30e27625-da32-7e67-6e3a-a923830b9e5c@labn.net>
Date: Thu, 21 Feb 2019 15:32:15 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <20190220212104.GK69562@kduck.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 72.66.11.201
X-Source-L: No
X-Exim-ID: 1gwv0z-004E5w-3T
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:59514
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2019 20:32:23 -0000

Hi Benjamin,

On 2/20/2019 4:21 PM, Benjamin Kaduk wrote:
> Hi Lou,
>
> On Wed, Feb 20, 2019 at 11:34:11AM -0500, Lou Berger wrote:
>> On 2/20/2019 11:07 AM, Benjamin Kaduk wrote:
>>> On Wed, Feb 20, 2019 at 09:33:34AM -0500, Lou Berger wrote:
>>>> On 2/19/2019 10:44 PM, Benjamin Kaduk wrote:
>>>>> I note that the DETNET WG is explicitly chartered with a work item for the
>>>>> "overall architecture: This work encompasses ... and security aspects".
>>>>> It seems incomplete to specify an architecture for a topic such as
>>>>> deterministic networking without specifically considering what threats are
>>>>> and are not in scope to be protected against.
>>>> The working group certainly recognizes that security is an important
>>>> topic and necessary part of the work. The WG's  approach to ensure that
>>>> this significant topic is sufficiently covered is to have a  document
>>>> dedicated to the topic.  As you note below this work,
>>>> draft-ietf-detnet-security, is not at the same level maturity - so
>>>> please stay tuned.  Of course, the WG would welcome any input on this
>>>> security draft now or even a full early-review or security area advisor.
>>> I do appreciate that the WG has taken the time to work on a dedicated
>>> security document, that goes through the (tedious!) effort to tabulate the
>>> various known attacker capabilities, threats, and their interactions.
>>>
>>> What I think is missing from the high-level architecture document is a
>>> sense for what security goals the architecture intends to achieve.  It's
>>> fine to have this be separate from the nitty-gritty stuff in the separate
>>> document, but these high-level questions can have an impact on the
>>> high-level design of the protocol ecosystem as a whole.  We have mounds of
>>> examples of "come up with a design; bolt security on as an afterthought"
>>> working poorly or being nigh-impossible, and I haven't seen any attempt at
>>> justification for why doing so here is likely to be any different.
>>> Including the security concepts from the start and wholly integrating them
>>> into the system tends to produce a much more elegant design and smoother
>>> outcomes all around.
>> We went back and forth on how much of the security topic to include in
>> the architecture document and settled on the current text of section 5
>> where just high level security requirements are identified.  From your
>> list below, the architecture covers the points you raise (non-detnet
>> traffic impacting detnet traffic, and detnet traffic trying to use more
>> than its allocation) mainly from a service delivery perspective.  It
>> does mention "shaping" as a security concern, the document could expand
>> these if helpful. But I think the real discussion point is how much of
>> the security details should be in the base (vs dedicated) document  --
>> and that you disagree with where the WG has drawn the line.  Is this
>> correct?
> Well, it's not as much that I disagree about where the line is drawn, as
> that I disagree with the characterization as "high level security
> requirements".
>
> The first paragraph covers topics worth including here, certainly -- an
> attacker that can introduce delay can inherently break the DetNet
> guarantees, and there is no further defense.  But the text could probably
> go further than its current version and explicitly call out that no
> technical measures can defend against such delay, other than by
> rerouting/avoiding the compromised position.
>
> The second paragraph also covers a topic worth noting, that entropy and
> Murphy as as important of risks to consider as active attacks.
>
> The rest of the section/list don't seem to match up with the high-level
> view, though -- "protection of the signaling protocol", but protection
> against what?  Authentication and authorization are important parts of
> security, but authorization is tied to actions and entities, not just
> entities in vacuo.  For "identification and shaping of DetNet flows", if
> security must cover them, what security properties are needed.  Do we need
> to provide integrity protection for the marking, or confidentiality
> protection, too?  Does authentication/integrity need to be provided for
> in-line or are out-of-band considerations in play?
>
> The rest of the document presents a good high level picture of what pieces
> will be involved in a system, and how they fit together.  I'm hoping to see
> a high-level picture of what attacks/failures the architecture does and
> does not aim to protect against.  It's somewhat implied that we need to
> protect against the failure of any single node or link (except at the
> boundary) due to random faults; explicitly saying this would be a perfect
> hting to include in the security considerations here!  Once we get beyond
> entropy as an attack, into more active attack scenarios, though, we need to
> consider what capabilities an attacker might have.  Do we protect against
> an entity with the ability to inject various forms of traffic?  Modify or
> drop valid traffic?  Are there any (classes of) credentials that we assume
> must be securely held, or will we attempt to protect against attackers that
> have some privilege within the system?  (Note that misbehaving hardware can
> sometimes present as similar or identical to such an attacker.)
>
> Does this give a better picture of what I'm thinking of as "high-level
> security requirements"?  I don't necessarily need details of specific
> hardware or credentials at play, and certainly not for the solutions, but I
> want to have a clear picture of what the scope of future security analysis
> will be.  "How will I be able to tell if the actual protocols meet the
> security requirements of the architecture?"

I'll get with authors (of both the architecture and security docs) and 
see how much they think can be reasonably be added to this document -- 
to be clear you *are* asking for a change in how the WG decide to 
address this topic and what would go in which document.

Lou

> -Benjamin
>
> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet
>


From nobody Fri Feb 22 03:02:22 2019
Return-Path: 
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 408041277CC; Fri, 22 Feb 2019 03:02:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level: 
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 VuThWfEsW1KH; Fri, 22 Feb 2019 03:02:08 -0800 (PST)
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 8D597124D68; Fri, 22 Feb 2019 03:02:08 -0800 (PST)
Received: by mail-ot1-x32e.google.com with SMTP id b3so1526399otp.4; Fri, 22 Feb 2019 03:02:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=3jKhbLq8SNNZOI/5mcuqkFBH0qptNR+q4s502/IRDQs=; b=N+IXFlB2S+m3cNYdsvS88PN+Cv5tekPRe0XL1mJYKnzSv3MO9yQZae3BrKeW0o+tBW U2x4faA/ua/CPyGLiABTXRkrp9dZNUUrrrR2ImYHOAA9gLvwzv5BmQ8P7tdAMkwE9nuT FGD9bBTuAuraN/yXx2C/9NXaIhRQqkdgWOQLnXWbC2vvCF+SKybedo7n3L8ZFvygVrG1 kn4yIn4b3IX/HHI+ZDBx5xdAP5gg4N49CD44QR+bYiIShoBLDJl2wq8NWQMFA1nK0+Nd Yvd5SADdqo/6Vwocb7hdpf/prykl+chIIcyqzhaJd7l1YapvrcQVu4EWKYwA7RVMTRXi QJww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=3jKhbLq8SNNZOI/5mcuqkFBH0qptNR+q4s502/IRDQs=; b=EIbDODXPfA5k1dkaoEGmTNVYv9N0YGfbpBit6U4FYiAKlXct/Ki8O3ifYPHz2Hl4Sn Lah+5GJ91W+TGBomchfqMGcPN9bu9sfIRcI5hLcH8wMEnLm6A1y441hJiaCg+IwjB9Cn 4JwRutw6H/h8mjcUrMePm2E9Sqqpm6w1WmPQ2CzOTtHg1Tao9pSYiSK4FHLiPMg3ESSR MsX221Y/sgssPu5IuVFrlQtYMhuXtA+SYbjCkw5OopyYcpnMzZ7G99NqoAlzNF9c97uj fdR2Y+9GrAoe2jloRMglwRpCd86Xrclhp5fEzzUf121ain5JmTN8/M4gStyeGtNCMha7 nY3w==
X-Gm-Message-State: AHQUAub57wpdX6RX01+UxyyV6HmrC9pFq7SC+ArQUFmAKSHZTg5ywVUB pPoazv2docxJA3kvSMBC+AP0ymdJIzE011CprTjXxwQM
X-Google-Smtp-Source: AHgI3IZ4/GGceaWPjalKYlh0aq85kiR2m9pdWoP2MEy/RGficwjBuy9aYqH8/evu2aYIJrg23UxRwyR323n/fYNkM1k=
X-Received: by 2002:a9d:6348:: with SMTP id y8mr2196319otk.287.1550833327713;  Fri, 22 Feb 2019 03:02:07 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 22 Feb 2019 06:02:06 -0500
From: Alvaro Retana 
In-Reply-To: <7056c886-3aa9-2d85-7824-ee5f1ac9bb33@labn.net>
References: <155067820715.31361.3746519237969586434.idtracker@ietfa.amsl.com> <108f9294-fb9d-557a-011a-6a53156bcb37@labn.net>  <7056c886-3aa9-2d85-7824-ee5f1ac9bb33@labn.net>
MIME-Version: 1.0
Date: Fri, 22 Feb 2019 06:02:06 -0500
Message-ID: 
To: Lou Berger , The IESG 
Cc: detnet@ietf.org, draft-ietf-detnet-architecture@ietf.org,  detnet-chairs@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009ab5aa05827985d7"
Archived-At: 
Subject: Re: [Detnet] Alvaro Retana's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2019 11:02:16 -0000

--0000000000009ab5aa05827985d7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On February 21, 2019 at 7:35:32 PM, Lou Berger (lberger@labn.net) wrote:

Hi!

>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> I support Mirja's and Alissa's DISCUSSes...and have a related set of
concerns
>>> about the coexistence with non-DetNet traffic and privacy:
>>>
>>> =C2=A73.3.1 talks about what I think is a hard to achieve balance betwe=
en
coexisting
>>> with non-DetNet traffic and keeping that traffic from disrupting DetNet
flows.
>>> Because of the constraints, the intent of prioritizing DetNet flows is
clear
>>> (and that is ok), but that may result in starvation of non-DetNet
>>> traffic...even if the text does explicitly say that it "must be
avoided".
>>>
>>> I would like to see the potential case of starving non-DetNet traffic
called
>>> out somewhere.
>>
>> This is the objective of section 3.3.1.
>>
>>
>>> I'm looking for something similar to the first paragraph in =C2=A75,
>>> but focused on the non-DetNet traffic.
>>
>> The current text reads:
>>
>> 3.3.1. Coexistence with normal traffic
>>
>> A DetNet network supports the dedication of a high proportion of the
>> network bandwidth to DetNet flows. But, no matter how much is
>> dedicated for DetNet flows, it is a goal of DetNet to coexist with
>> existing Class of Service schemes (e.g., DiffServ). It is also
>> important that non-DetNet traffic not disrupt the DetNet flow, of
>> course (see Section 3.3.2 and Section 5). For these reasons:
>>
>> o Bandwidth (transmission opportunities) not utilized by a DetNet
>> flow is available to non-DetNet packets (though not to other
>> DetNet flows).
>>
>> o DetNet flows can be shaped or scheduled, in order to ensure that
>> the highest-priority non-DetNet packet is also ensured a worst-
>> case latency.
>>
>> o When transmission opportunities for DetNet flows are scheduled in
>> detail, then the algorithm constructing the schedule should leave
>> sufficient opportunities for non-DetNet packets to satisfy the
>> needs of the users of the network. Detailed scheduling can also
>> permit the time-shared use of buffer resources by different DetNet
>> flows.
>>
>> Starvation of non-DetNet traffic must be avoided, e.g., by traffic
>> policing functions (e.g., [RFC2475]). Thus, the net effect of the
>> presence of DetNet flows in a network on the non-DetNet flows is
>> primarily a reduction in the available bandwidth.
>>
>>
>> I think we need a little bit more to understand what you'd like to see
changed or added. Can you suggest text or what specific topic you'd like to
see added/addressed?
>
> Yes, let me try to explain better=E2=80=A6while comparing with the curren=
t
> text in =C2=A75, which basically says that even though the objective of
> DetNet is to provide bounded latency, a MIIM may delay the traffic and
> the objective may not be achieved.
>
> For non-DetNet traffic, the objective is to not starve it, while
> providing specific guarantees to the DetNet flows =E2=80=94 said other wa=
y
> (from the Introduction): "Unused reserved resources are available to
> non-DetNet packets as long as all guarantees are fulfilled.=E2=80=9D  How=
ever,
> the algorithms (maybe error, misconfiguration=E2=80=A6or even maliciously=
) may
> end up*not* constructing the schedule to leave sufficient
> opportunities for non-DetNet packets (as suggested in the text above
> from =C2=A73.3.1).
>
> I see a parallel in how there is a risk of the intention for DetNet
> flows not being met (because of an attack) and how the intention for
> non-DetNet traffic may also not be met.
>
Okay, this sounds like basically the same point that Benjamin was
making, i.e., there must be mechanisms preventing non-detnet traffic
from impacting detnet traffic, and detnet traffic trying to use more
than its allocation and impacting non-detnet traffic. Is this correct or
are you asking for something different/additional?

Yes.  I=E2=80=99m not asking so much for a mechanism, but for at least the
recognition that it is a risk.




>
>>> Related to the above is the fact that the identification of flows could
be used
>>> to specifically *not* include some of them as DetNet flows. This is a
>>> variation of the concern outlined in =C2=A76, but applied to non-DetNet
flows, with
>>> the potential starvation mentioned above. Again, I would like to at
least see
>>> some discussion of this risk.
>>
>> I don't follow - what is the risk that should be addressed?
>>
> =C2=A76 talks about potential privacy concerns due to the identification =
of
> flows.  I interpret that as potentially being able to identify the
> user (application, or both maybe).
>
Currently flow identification is based on IP headers (6 tuple) and/or
MPLS labels.  So DetNet has the same privacy concerns as standard IP/MPLS.


> As far as I understand the architecture, DetNet flows are identified
> at the edge and then assigned to specific paths.  If the
> identification of flows can be used to identify the user (for
> example), then it can be used to not only attack specific DetNet flow,
> but also to decide to not provide guarantees to a specific flow based
> on who the user or the application may be.
>
Given DetNet flow identification, is this any different than standard PBR?

Right, it is not really different.  It is just not mentioned anywhere that
identification (or misidentification as it may be, maybe maliciously) can
lead to not providing guarantees, potential starving, etc..

Thanks!

Alvaro.

--0000000000009ab5aa05827985d7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

On February 21, 2019 at 7:35:32 PM, Lou Berger (=
lberger@labn.net) wrote:

Hi!

 
>>> --------=
--------------------------------------------------------------=C2=A0
>>> DISCUSS:=C2=A0
>>> -----------------=
-----------------------------------------------------=C2=A0
>>>=C2=A0
>>> I support Mirja's and Alissa'=
s DISCUSSes...and have a related set of concerns=C2=A0
>>> about the coexistence with non-Det=
Net traffic and privacy:=C2=A0=

>>>=C2=A0
>=
>> =C2=A73.3.1 talks about what I think is a hard to achieve balance =
between coexisting=C2=A0
&g=
t;>> with non-DetNet traffic and keeping that traffic from disrupting=
 DetNet flows.=C2=A0
>&g=
t;> Because of the constraints, the intent of prioritizing DetNet flows =
is clear=C2=A0
>>>=
 (and that is ok), but that may result in starvation of non-DetNet=C2=A0
>>> traffic...even i=
f the text does explicitly say that it "must be avoided".=C2=A0
>>>=C2=A0
>>> I would like to see the=
 potential case of starving non-DetNet traffic called=C2=A0
>>> out somewhere.=C2=A0
>>=C2=A0
>> This is the objective of section 3.3.1=
.=C2=A0
>>=C2=A0
>>=C2=A0
>>> I'm looking for something =
similar to the first paragraph in =C2=A75,=C2=A0
>>> but focused on the non-DetNet traffic.=C2=A0
>>=C2=A0
>> The current text reads:=C2=A0
>>=C2=A0
>> 3.3.1. Coexistence with n=
ormal traffic=C2=A0
>>=
;=C2=A0
>> A DetNet n=
etwork supports the dedication of a high proportion of the=C2=A0
>> network bandwidth to DetNet =
flows. But, no matter how much is=C2=
=A0
>> dedicated for DetNet flows, it is a goal of DetNet t=
o coexist with=C2=A0
>&g=
t; existing Class of Service schemes (e.g., DiffServ). It is also=C2=A0
>> important that non-De=
tNet traffic not disrupt the DetNet flow, of=C2=A0
>> course (see Section 3.3.2 and Section 5). =
For these reasons:=C2=A0
&g=
t;>=C2=A0
>> o Ban=
dwidth (transmission opportunities) not utilized by a DetNet=C2=A0
>> flow is available to non-D=
etNet packets (though not to other=C2=
=A0
>> DetNet flows).=
=C2=A0
>>=C2=A0
>> o DetNet flows can be shaped or scheduled, in order to ensure=
 that=C2=A0
>> the hi=
ghest-priority non-DetNet packet is also ensured a worst-=C2=A0
>> case latency.=C2=A0
>>=C2=A0
>> o When transmission opportunities for D=
etNet flows are scheduled in=C2=A0
>> detail, then the algorithm constructing the schedule shoul=
d leave=C2=A0
>> suff=
icient opportunities for non-DetNet packets to satisfy the=C2=A0
>> needs of the users of the ne=
twork. Detailed scheduling can also=
=C2=A0
>> permit the time-shared use of buffer resources by=
 different DetNet=C2=A0
>=
;> flows.=C2=A0
>>=
=C2=A0
>> Starvation =
of non-DetNet traffic must be avoided, e.g., by traffic=C2=A0
>> policing functions (e.g., [RFC2=
475]). Thus, the net effect of the=C2=
=A0
>> presence of DetNet flows in a network on the non-Det=
Net flows is=C2=A0
>>=
 primarily a reduction in the available bandwidth.=C2=A0
>>=C2=A0
>>=C2=A0
>> I think we need a little bit more to understand what you'=
;d like to see changed or added. Can you suggest text or what specific topi=
c you'd like to see added/addressed?=C2=A0
>=C2=A0=

> Yes, let me try to explain better=E2=80=A6while comparing with the=
 current=C2=A0
> text in=
 =C2=A75, which basically says that even though the objective of=C2=A0
> DetNet is to provide bound=
ed latency, a MIIM may delay the traffic and=C2=A0
> the objective may not be achieved.=C2=A0
>=C2=A0
> For non-DetNet traffic, the objective is t=
o not starve it, while=C2=A0> providing specific guarantees to the DetNet flows =E2=80=94 said oth=
er way=C2=A0
> (from the=
 Introduction): "Unused reserved resources are available to=C2=A0
> non-DetNet packets as long=
 as all guarantees are fulfilled.=E2=80=9D =C2=A0However,=C2=A0
> the algorithms (maybe error, misc=
onfiguration=E2=80=A6or even maliciously) may=C2=A0
> end up*not* constructing the schedule to leav=
e sufficient=C2=A0
> opp=
ortunities for non-DetNet packets (as suggested in the text above=C2=A0
> from =C2=A73.3.1).=C2=A0
>=C2=A0
> I see a parallel in how there is a ris=
k of the intention for DetNet=C2=A0
> flows not being met (because of an attack) and how the intent=
ion for=C2=A0
> non-DetN=
et traffic may also not be met.=C2=A0=

>=C2=A0
Okay,=
 this sounds like basically the same point that Benjamin was=C2=A0
making, i.e., there must be mechani=
sms preventing non-detnet traffic=C2=
=A0
from impacting detnet traffic, and detnet traffic trying to u=
se more=C2=A0
than its allo=
cation and impacting non-detnet traffic. Is this correct or=C2=A0
are you asking for something differe=
nt/additional?=C2=A0
Yes.=C2=A0 I=E2=80=99m not asking so much fo=
r a mechanism, but for at least the recognition that it is a risk.
=



=

>=C2=A0
>>>=
 Related to the above is the fact that the identification of flows could be=
 used=C2=A0
>>> to=
 specifically *not* include some of them as DetNet flows. This is a=C2=A0
>>> variation of th=
e concern outlined in =C2=A76, but applied to non-DetNet flows, with=C2=A0
>>> the potential =
starvation mentioned above. Again, I would like to at least see=C2=A0
>>> some discussion of=
 this risk.=C2=A0
>><=
span class=3D"Apple-converted-space">=C2=A0
>> I don't =
follow - what is the risk that should be addressed?=C2=A0
>>=C2=A0
> =C2=A76 talks about potential privacy concerns due =
to the identification of=C2=A0=

> flows.=C2=A0 I interpret that as potentially being able to identif=
y the=C2=A0
> user (appl=
ication, or both maybe).=C2=A0=

>=C2=A0
Currently fl=
ow identification is based on IP headers (6 tuple) and/or=C2=A0
MPLS labels.=C2=A0 So DetNet has the s=
ame privacy concerns as standard IP/MPLS.=C2=A0


> As far as I understand the architecture, =
DetNet flows are identified=C2=A0
> at the edge and then assigned to specific paths.=C2=A0 If the=C2=A0
> identification of=
 flows can be used to identify the user (for=C2=A0
> example), then it can be used to not only atta=
ck specific DetNet flow,=C2=A0=

> but also to decide to not provide guarantees to a specific flow ba=
sed=C2=A0
> on who the u=
ser or the application may be.=C2=A0<=
/span>
>=C2=A0
Given =
DetNet flow identification, is this any different than standard PBR?=C2=A0
Right, it is not really different.=C2=A0 It is just not mentioned=
 anywhere that identification (or misidentification as it may be, maybe mal=
iciously) can lead to not providing guarantees, potential starving, etc..
Thanks!
Alvaro.


--0000000000009ab5aa05827985d7--


From nobody Sat Feb 23 13:01:38 2019
Return-Path: 
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 06D6D130EE5 for ; Sat, 23 Feb 2019 13:01:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.807
X-Spam-Level: 
X-Spam-Status: No, score=-1.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 tGY3eYU6k2WU for ; Sat, 23 Feb 2019 13:01:35 -0800 (PST)
Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 157E8130ECD for ; Sat, 23 Feb 2019 13:01:35 -0800 (PST)
Received: from CMGW (unknown [10.9.0.13]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id 8A0AC406B2 for ; Sat, 23 Feb 2019 13:39:51 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id xe5PgpEgjeyBxxe5PgNk2h; Sat, 23 Feb 2019 13:39:51 -0700
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=+uPMnwykIpNDTfV+WT0R8PGq/vALfLPsjWp1aSfUJt4=; b=P+q5Eq92X++WfB9t6tqqXK6csM Bp1teQIbKcQpfW6YEm6t9artVNhx3/+6OVt7BITg61MUo+uG85HAHbCjm0P/lXFu0u+DknaKBZN6W 3fgSOmzQMiHsZ4JnQwVFdpC7Q;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:38774 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gxe5M-003nBT-Dd; Sat, 23 Feb 2019 13:39:51 -0700
To: Alvaro Retana , The IESG 
Cc: draft-ietf-detnet-architecture@ietf.org, detnet@ietf.org, detnet-chairs@ietf.org
References: <155067820715.31361.3746519237969586434.idtracker@ietfa.amsl.com> <108f9294-fb9d-557a-011a-6a53156bcb37@labn.net>  <7056c886-3aa9-2d85-7824-ee5f1ac9bb33@labn.net> 
From: Lou Berger 
Message-ID: 
Date: Sat, 23 Feb 2019 15:39:12 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------14BCA084D4D9DEB70C9FEF59"
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 72.66.11.201
X-Source-L: No
X-Exim-ID: 1gxe5M-003nBT-Dd
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:38774
X-Source-Auth: lberger@labn.net
X-Email-Count: 10
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Org: HG=bhcustomer;ORG=bluehost;
X-Local-Domain: yes
Archived-At: 
Subject: Re: [Detnet] Alvaro Retana's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Feb 2019 21:01:37 -0000

This is a multi-part message in MIME format.
--------------14BCA084D4D9DEB70C9FEF59
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi *Alvaro*,

see below.

On 2/22/2019 6:02 AM, Alvaro Retana wrote:
> On February 21, 2019 at 7:35:32 PM, Lou Berger (lberger@labn.net 
> ) wrote:
>
> Hi!
>
>> >>> ----------------------------------------------------------------------
>> >>> DISCUSS:
>> >>> 
>> ----------------------------------------------------------------------
>> >>>
>> >>> I support Mirja's and Alissa's DISCUSSes...and have a related set 
>> of concerns
>> >>> about the coexistence with non-DetNet traffic and privacy:
>> >>>
>> >>> §3.3.1 talks about what I think is a hard to achieve balance 
>> between coexisting
>> >>> with non-DetNet traffic and keeping that traffic from disrupting 
>> DetNet flows.
>> >>> Because of the constraints, the intent of prioritizing DetNet 
>> flows is clear
>> >>> (and that is ok), but that may result in starvation of non-DetNet
>> >>> traffic...even if the text does explicitly say that it "must be 
>> avoided".
>> >>>
>> >>> I would like to see the potential case of starving non-DetNet 
>> traffic called
>> >>> out somewhere.
>> >>
>> >> This is the objective of section 3.3.1..
>> >>
>> >>
>> >>> I'm looking for something similar to the first paragraph in §5,
>> >>> but focused on the non-DetNet traffic.
>> >>
>> >> The current text reads:
>> >>
>> >> 3.3.1. Coexistence with normal traffic
>> >>
>> >> A DetNet network supports the dedication of a high proportion of the
>> >> network bandwidth to DetNet flows. But, no matter how much is
>> >> dedicated for DetNet flows, it is a goal of DetNet to coexist with
>> >> existing Class of Service schemes (e.g., DiffServ). It is also
>> >> important that non-DetNet traffic not disrupt the DetNet flow, of
>> >> course (see Section 3.3.2 and Section 5). For these reasons:
>> >>
>> >> o Bandwidth (transmission opportunities) not utilized by a DetNet
>> >> flow is available to non-DetNet packets (though not to other
>> >> DetNet flows).
>> >>
>> >> o DetNet flows can be shaped or scheduled, in order to ensure that
>> >> the highest-priority non-DetNet packet is also ensured a worst-
>> >> case latency.
>> >>
>> >> o When transmission opportunities for DetNet flows are scheduled in
>> >> detail, then the algorithm constructing the schedule should leave
>> >> sufficient opportunities for non-DetNet packets to satisfy the
>> >> needs of the users of the network. Detailed scheduling can also
>> >> permit the time-shared use of buffer resources by different DetNet
>> >> flows.
>> >>
>> >> Starvation of non-DetNet traffic must be avoided, e.g., by traffic
>> >> policing functions (e.g., [RFC2475]). Thus, the net effect of the
>> >> presence of DetNet flows in a network on the non-DetNet flows is
>> >> primarily a reduction in the available bandwidth.
>> >>
>> >>
>> >> I think we need a little bit more to understand what you'd like to 
>> see changed or added. Can you suggest text or what specific topic 
>> you'd like to see added/addressed?
>> >
>> > Yes, let me try to explain better…while comparing with the current
>> > text in §5, which basically says that even though the objective of
>> > DetNet is to provide bounded latency, a MIIM may delay the traffic and
>> > the objective may not be achieved.
>> >
>> > For non-DetNet traffic, the objective is to not starve it, while
>> > providing specific guarantees to the DetNet flows — said other way
>> > (from the Introduction): "Unused reserved resources are available to
>> > non-DetNet packets as long as all guarantees are fulfilled.”  However,
>> > the algorithms (maybe error, misconfiguration…or even maliciously) may
>> > end up*not* constructing the schedule to leave sufficient
>> > opportunities for non-DetNet packets (as suggested in the text above
>> > from §3.3.1).
>> >
>> > I see a parallel in how there is a risk of the intention for DetNet
>> > flows not being met (because of an attack) and how the intention for
>> > non-DetNet traffic may also not be met.
>> >
>> Okay, this sounds like basically the same point that Benjamin was
>> making, i.e., there must be mechanisms preventing non-detnet traffic
>> from impacting detnet traffic, and detnet traffic trying to use more
>> than its allocation and impacting non-detnet traffic. Is this correct or
>> are you asking for something different/additional?
>
> Yes.  I’m not asking so much for a mechanism, but for at least the 
> recognition that it is a risk.
>
Fair enough- I expect the response a response for the architecture and 
security draft authors to address this.  I'm sure you will confirm that 
it does!


>>
>>
>>
>> >
>> >>> Related to the above is the fact that the identification of flows 
>> could be used
>> >>> to specifically *not* include some of them as DetNet flows. This is a
>> >>> variation of the concern outlined in §6, but applied to 
>> non-DetNet flows, with
>> >>> the potential starvation mentioned above. Again, I would like to 
>> at least see
>> >>> some discussion of this risk.
>> >>
>> >> I don't follow - what is the risk that should be addressed?
>> >>
>> > §6 talks about potential privacy concerns due to the identification of
>> > flows.  I interpret that as potentially being able to identify the
>> > user (application, or both maybe).
>> >
>> Currently flow identification is based on IP headers (6 tuple) and/or
>> MPLS labels.  So DetNet has the same privacy concerns as standard 
>> IP/MPLS.
>>
>>
>> > As far as I understand the architecture, DetNet flows are identified
>> > at the edge and then assigned to specific paths. If the
>> > identification of flows can be used to identify the user (for
>> > example), then it can be used to not only attack specific DetNet flow,
>> > but also to decide to not provide guarantees to a specific flow based
>> > on who the user or the application may be.
>> >
>> Given DetNet flow identification, is this any different than standard 
>> PBR?
>
> Right, it is not really different.  It is just not mentioned anywhere 
> that identification (or misidentification as it may be, maybe 
> maliciously) can lead to not providing guarantees, potential starving, 
> etc..
>
I thought the quotes capture in the various mails on the topic showed 
how it was -- but let's wait for the updated text and see if it 
sufficiently addresses your concern/point, and then go from there.

Thanks again for the feedback.

Lou


> Thanks!
>
> Alvaro.
>
>
> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet

--------------14BCA084D4D9DEB70C9FEF59
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi *Alvaro*,

    
see below.

    

    
On 2/22/2019 6:02 AM, Alvaro Retana
      wrote:

    

    

      
      
      
On
        February 21, 2019 at 7:35:32 PM, Lou Berger (lberger@labn.net)
        wrote:

      


      

      
Hi!

      


      

      

        

            

              
>>>
                ---------------------------------------------------------------------- 

                >>> DISCUSS: 

                >>>
                ---------------------------------------------------------------------- 

                >>> 

                >>> I support Mirja's and Alissa's
                DISCUSSes...and have a related set of concerns 

                >>> about the coexistence with non-DetNet
                traffic and privacy: 

                >>> 

                >>> §3.3.1 talks about what I think is a hard
                to achieve balance between coexisting 

                >>> with non-DetNet traffic and keeping that
                traffic from disrupting DetNet flows. 

                >>> Because of the constraints, the intent of
                prioritizing DetNet flows is clear 

                >>> (and that is ok), but that may result in
                starvation of non-DetNet 

                >>> traffic...even if the text does explicitly
                say that it "must be avoided". 

                >>> 

                >>> I would like to see the potential case of
                starving non-DetNet traffic called 

                >>> out somewhere. 

                >> 

                >> This is the objective of section 3.3.1.. 

                >> 

                >> 

                >>> I'm looking for something similar to the
                first paragraph in §5, 

                >>> but focused on the non-DetNet traffic. 

                >> 

                >> The current text reads: 

                >> 

                >> 3.3.1. Coexistence with normal traffic 

                >> 

                >> A DetNet network supports the dedication of a
                high proportion of the 

                >> network bandwidth to DetNet flows. But, no
                matter how much is 

                >> dedicated for DetNet flows, it is a goal of
                DetNet to coexist with 

                >> existing Class of Service schemes (e.g.,
                DiffServ). It is also 

                >> important that non-DetNet traffic not disrupt
                the DetNet flow, of 

                >> course (see Section 3.3.2 and Section 5). For
                these reasons: 

                >> 

                >> o Bandwidth (transmission opportunities) not
                utilized by a DetNet 

                >> flow is available to non-DetNet packets (though
                not to other 

                >> DetNet flows). 

                >> 

                >> o DetNet flows can be shaped or scheduled, in
                order to ensure that 

                >> the highest-priority non-DetNet packet is also
                ensured a worst- 

                >> case latency. 

                >> 

                >> o When transmission opportunities for DetNet
                flows are scheduled in 

                >> detail, then the algorithm constructing the
                schedule should leave 

                >> sufficient opportunities for non-DetNet packets
                to satisfy the 

                >> needs of the users of the network. Detailed
                scheduling can also 

                >> permit the time-shared use of buffer resources
                by different DetNet 

                >> flows. 

                >> 

                >> Starvation of non-DetNet traffic must be
                avoided, e.g., by traffic 

                >> policing functions (e.g., [RFC2475]). Thus, the
                net effect of the 

                >> presence of DetNet flows in a network on the
                non-DetNet flows is 

                >> primarily a reduction in the available
                bandwidth. 

                >> 

                >> 

                >> I think we need a little bit more to understand
                what you'd like to see changed or added. Can you suggest
                text or what specific topic you'd like to see
                added/addressed? 

                > 

                > Yes, let me try to explain better…while comparing
                with the current 

                > text in §5, which basically says that even though
                the objective of 

                > DetNet is to provide bounded latency, a MIIM may
                delay the traffic and 

                > the objective may not be achieved. 

                > 

                > For non-DetNet traffic, the objective is to not
                starve it, while 

                > providing specific guarantees to the DetNet flows —
                said other way 

                > (from the Introduction): "Unused reserved resources
                are available to 

                > non-DetNet packets as long as all guarantees are
                fulfilled.”  However, 

                > the algorithms (maybe error, misconfiguration…or
                even maliciously) may 

                > end up*not* constructing the schedule to leave
                sufficient 

                > opportunities for non-DetNet packets (as suggested
                in the text above 

                > from §3.3.1). 

                > 

                > I see a parallel in how there is a risk of the
                intention for DetNet 

                > flows not being met (because of an attack) and how
                the intention for 

                > non-DetNet traffic may also not be met. 

                > 

                Okay, this sounds like basically the same point that
                Benjamin was 

                making, i.e., there must be mechanisms preventing
                non-detnet traffic 

                from impacting detnet traffic, and detnet traffic trying
                to use more 

                than its allocation and impacting non-detnet traffic. Is
                this correct or 

                are you asking for something different/additional? 

            

          

      

      
Yes.  I’m not asking so much for a mechanism, but for at least
        the recognition that it is a risk.

    

    
Fair enough- I expect the response a response for the
      architecture and security draft authors to address this.  I'm sure
      you will confirm that it does!

    


    

    

      

        

          

              

                


                  

                  

                  > 

                  >>> Related to the above is the fact that the
                  identification of flows could be used 

                  >>> to specifically *not* include some of
                  them as DetNet flows. This is a 

                  >>> variation of the concern outlined in §6,
                  but applied to non-DetNet flows, with 

                  >>> the potential starvation mentioned above.
                  Again, I would like to at least see 

                  >>> some discussion of this risk. 

                  >> 

                  >> I don't follow - what is the risk that should
                  be addressed? 

                  >> 

                  > §6 talks about potential privacy concerns due to
                  the identification of 

                  > flows.  I interpret that as potentially being
                  able to identify the 

                  > user (application, or both maybe). 

                  > 

                  Currently flow identification is based on IP headers
                  (6 tuple) and/or 

                  MPLS labels.  So DetNet has the same privacy concerns
                  as standard IP/MPLS. 

                  

                  

                  > As far as I understand the architecture, DetNet
                  flows are identified 

                  > at the edge and then assigned to specific paths. 
                  If the 

                  > identification of flows can be used to identify
                  the user (for 

                  > example), then it can be used to not only attack
                  specific DetNet flow, 

                  > but also to decide to not provide guarantees to a
                  specific flow based 

                  > on who the user or the application may be. 

                  > 

                  Given DetNet flow identification, is this any
                  different than standard PBR? 

              

            

        

        
Right, it is not really different.  It is just not mentioned
          anywhere that identification (or misidentification as it may
          be, maybe maliciously) can lead to not providing guarantees,
          potential starving, etc..

      

    

    
I thought the quotes capture in the various mails on the topic
      showed how it was -- but let's wait for the updated text and see
      if it sufficiently addresses your concern/point, and then go from
      there.

    

    
Thanks again for the feedback.

    
Lou

    

    


    

    

      

        
Thanks!

        
Alvaro.

      

      

      

      
_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet


    

  


--------------14BCA084D4D9DEB70C9FEF59--


From nobody Sun Feb 24 22:31:25 2019
Return-Path: 
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 89BEC130E0A; Sun, 24 Feb 2019 22:31:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.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 Lr7Ih3Yggq1H; Sun, 24 Feb 2019 22:31:20 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770117.outbound.protection.outlook.com [40.107.77.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF7712F1AC; Sun, 24 Feb 2019 22:31:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3fDXtQFL1IKxJPYeEZWk4D4JbZEQ/7+H9u6GzUPFeHs=; b=d1IvSDZurSQ1fGGhJXzhAl5tNms/JK2TZPcsTEpMpoQxmbjcz8woX1QohH0PxpFIuFzqCTHUNgKOlowJz4vJFHrU88DUujxI2h8EwUJkHyVVwCWhc9H7KJyC3a+X+VFS+/W5b62WzGu9Vq/DhG/+airPH6fN47NLSfapa5HTJsQ=
Received: from BYAPR06MB4325.namprd06.prod.outlook.com (52.135.240.140) by BYAPR06MB6054.namprd06.prod.outlook.com (20.178.51.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.18; Mon, 25 Feb 2019 06:31:16 +0000
Received: from BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::a55b:5609:ca77:6500]) by BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::a55b:5609:ca77:6500%6]) with mapi id 15.20.1643.019; Mon, 25 Feb 2019 06:31:16 +0000
From: "Grossman, Ethan A." 
To: Benjamin Kaduk 
CC: "draft-ietf-detnet-architecture@ietf.org" , "detnet@ietf.org" , The IESG , "detnet-chairs@ietf.org" 
Thread-Topic: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
Thread-Index: AQHUyM6XP+fod7L+2k6iJmhQjssa7KXowOYAgAAaUACAAAdkgIAAUCiAgAGEsICABUlAUA==
Date: Mon, 25 Feb 2019 06:31:16 +0000
Message-ID: 
References: <155063426136.20704.6779201119170972943.idtracker@ietfa.amsl.com>  <20190220160743.GD69562@kduck.mit.edu> <36c4ce97-5c4a-89ab-d648-3e7705a6acd3@labn.net> <20190220212104.GK69562@kduck.mit.edu> <30e27625-da32-7e67-6e3a-a923830b9e5c@labn.net>
In-Reply-To: <30e27625-da32-7e67-6e3a-a923830b9e5c@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; 
x-originating-ip: [73.162.193.175]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0bfcd8e4-39b4-45de-637d-08d69aead89e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR06MB6054; 
x-ms-traffictypediagnostic: BYAPR06MB6054:
x-ms-exchange-purlcount: 1
x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjA2TUI2MDU0OzIzOnQwL1FMS3NPYThuQ1RmWXhmR3U3ZlhFRjQx?= =?utf-8?B?bmtvZ1JsWll3MGQvbVpMNVg0WjRMRnU5TWRSRWx2WVZoR2xCeHUrTmRvTjFY?= =?utf-8?B?MXRNYkwyVTMrQ0NWbkpURklwQkt0Z25QeUlUWDNMNk90NlFjb0pTMDd0cVJk?= =?utf-8?B?aGR6TVRSUENJODdwVHY4ejZ1Z1BwUmE0VnVxVEZJWjc2MExFQjVod1R4KzZx?= =?utf-8?B?SFFQY0x4SHpyM0ZhcTBQQlFscmtwWlpHQWplMDVEb3IzN1A3TlRXS3gwUHdQ?= =?utf-8?B?UVR3VjdlZWt1Szl6dVR3WUJyYjdDUk5LbWFCU3R2bGtTRXhmNFQ0NDl4T2pj?= =?utf-8?B?MWJPZnhmRDBlbVZpc2lmNHpoM1ZkTU5DL0wyRHNxUVZEVTJwMFBZMFc4eUwy?= =?utf-8?B?VUh2NVJBRGFkeGxuWHRkSHd0S3h6QWFXMmUwQ3MrK0Z4R0lQS2lvU0FpOFFF?= =?utf-8?B?Q2FVN015MEkzT0h2K20xTHhmN0hmQ0lxMEhPalkwUkVGaEdMak1PREl6Zmgz?= =?utf-8?B?RzV6TDBxMEZYUzVobEl2UEN1bS9WL1UyRTRHbTNSMjV2TkhRaE5jV2gvVzdQ?= =?utf-8?B?ZnowVlN1cE14SHR4ODJCTkFEemtxUEJUV2FNUXo4ZnhSOXZLYjRFaC9PeWxW?= =?utf-8?B?MTV4NDl0NUVqWFE4TW04bHo2TUFOK3pTbnhRU3dJdytSYXYvT0tUUFUxb1N2?= =?utf-8?B?NWUzUVRvVjlYQk01c2JRL1VLL1UvVTNsMzBEUVF5MHZLMXp3SzhCOHN0ajMz?= =?utf-8?B?KzRsR094eWR4dmI1OUtVb3ZiUnFpd0ZQbEh6YmpVZDFjRnIvMGV6OE5xdndj?= =?utf-8?B?N2U5MHRuQjhHYUJoWjBoYUNIcWpJVWpicG4vd1BqTk1mZmJMNU1BN2xuMkJH?= =?utf-8?B?RG8ySCttYkgrOFcwVm1rREYxeTZPT2MrVFJhYlFWeTNjSkFLUmNhaU9NcVRV?= =?utf-8?B?c2VLZ2tZeUJKaUJxOUNoTFhPd28ydk9Hd293cHdPalUxVUNRek9ieVpiZ0lG?= =?utf-8?B?OUtiOGJZczZ1YzM1N1ljR1hQTnQ2TE5qRm9KOUt5TW5mdkNXOHI3NlQxb1dk?= =?utf-8?B?cnd0ZFhKRTBYQWJtbEZ2YTY2NUdTU1dCM1lCcGFOWTEzejZnK1NNUUJiN3J0?= =?utf-8?B?U2c3SW1PQ3YzcE5oN1BSZUtZOW9ZMStCclBXZERseGQraENzb0Y2eDYzSzBL?= =?utf-8?B?SkhlamxKdTgrZ3BpbXB3dGlBUFJCellPNmMwMmdobHduNExJSWxQSFArVzFE?= =?utf-8?B?UHh2RU1xQnA1V3VQaE9SYVJqMjNnd1pMMk15VUlpTnZ6TngxVkRla3Z1WjFE?= =?utf-8?B?cU9tdUJEcndZNkx3cXdQSXRIckU2V0pzcFEvbEpicmhHSEc2b1lPR3NkSVJD?= =?utf-8?B?bVlJSXF4R3BYb1hwdDdnZU95UjRhc2ExV3FidzRuOG5GRmhTZm5peXpKNHBr?= =?utf-8?B?aEw1Vzh0d0xZK3c4QTBacE50UkNISDB0N2VBU2Vwb3RhcDkvS0I0bzFOVXps?= =?utf-8?B?VEViM3FrTWFCTDlxS1BDVWRFbVJJRXFOd3RHZWVnenBLcVJnNm5pRUhBSG01?= =?utf-8?B?aTNEU2VyQ0VHWTBUU2RhM0UyYnBmRlF2VEdQU21WL3YwMmw2cVZGeGJqUU5U?= =?utf-8?B?eVd1VFVrSy9yVHF3K1VXb0dCZVlqNVM2Wnl2T1g5S01rMU1hNmlMVlVibU9M?= =?utf-8?B?ckVCWXcrdlYwR0pzTlNkOThKbU9aN3FlM1FBWmhWVmZWWGRDRTUvVjBDcFFl?= =?utf-8?B?TVpTSWpLaXQxanJ1Z3MvS2Y2UTQ5NWt4RFRydVdlN2dCTUNkWmtveE5qSE9x?= =?utf-8?B?RkFBVitTdGtWUU1wS2JMM2M2RDBaRVZYMTlTTEd1U29IeVExeUpFY3FKTERs?= =?utf-8?Q?TGjF6DMMG0c=3D?=
x-microsoft-antispam-prvs: 
x-forefront-prvs: 095972DF2F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(376002)(366004)(39850400004)(396003)(199004)(189003)(13464003)(102836004)(6506007)(53936002)(25786009)(53546011)(71190400001)(71200400001)(81156014)(66066001)(81166006)(8936002)(26005)(6116002)(3846002)(8676002)(186003)(106356001)(7736002)(305945005)(229853002)(6436002)(6916009)(486006)(74316002)(105586002)(99286004)(476003)(4326008)(11346002)(446003)(256004)(86362001)(97736004)(7696005)(9686003)(55016002)(6306002)(76176011)(2171002)(478600001)(93886005)(316002)(33656002)(2906002)(30864003)(68736007)(54906003)(14444005)(6246003)(14454004)(966005)(52536013)(5660300002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR06MB6054; H:BYAPR06MB4325.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: ZjcLHBuxKlKxbTul+OcJLhn+FbvNuL0uTsvPyG/eWL+0E1yfZyUCxy9zuOESPCmyaqi3X0rTalrr9eWoq7aptKM9XvgWG0NMYzMWHuiLBiXHAVbfnZF0VRClzSulUb6ibcoOj6rfXkcoS48gZdbvDOSGONRZjkk9skj83Df5icp9AbqrvRkZgPFV2rCUpCCNdBjjvmoTsJqkYbjSrD5ZuGvlmZ1YCCbQEsnqYGLs+kTbKUyqwBI/p488HGkDqN+5k0JE+r/CyF9D8YZ577+XVJyo6j4XokAjVoPHT60FdzdtUqukU4d005+EOw3NZMvNzyGPoP7pz7jBSSPsWBOKIpPAPTAec5b+G1h1kMXuGVK3+aWVzh/uIgXzVD7Cavq8tpSROIZsqC5/aFgojlw4S/iJnNaLbjbtvUYYtndb9us=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: dolby.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0bfcd8e4-39b4-45de-637d-08d69aead89e
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2019 06:31:16.5896 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB6054
Archived-At: 
Subject: Re: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Feb 2019 06:31:24 -0000

SGkgQmVuamFtaW4sDQpBcyBlZGl0b3IgYW5kIGNvLWF1dGhvciBvZiB0aGUgRGV0TmV0IFNlY3Vy
aXR5IGRyYWZ0LCBJIHRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgY29tbWVudHMgcmVnYXJk
aW5nIHRoZSBzZWN1cml0eSBhc3BlY3RzIG9mIHRoZSBEZXROZXQgQXJjaGl0ZWN0dXJlIGFuZCBT
ZWN1cml0eSBkcmFmdC4gSW5kZWVkIGl0IGlzIG91ciBpbnRlbnQgdG8gZW5zdXJlIHRoYXQgc2Vj
dXJpdHkgaXMgY29uc2lkZXJlZCB0aHJvdWdob3V0IHRoZSBkZXNpZ24gcHJvY2VzcyBhbmQgbm90
ICJib2x0ZWQgb24iIGF0IHRoZSBlbmQ7IHRoaXMgaXMgd2h5IHdlIGhhdmUgYmVlbiBkZXZlbG9w
aW5nIHRoZSBTZWN1cml0eSBkcmFmdCBpbiBwYXJhbGxlbCB3aXRoIHRoZSBBcmNoaXRlY3R1cmUs
IERhdGEgUGxhbmUgYW5kIG90aGVyIGRyYWZ0cy4gIEhlcmUgYXJlIGEgY291cGxlIG9mIG15IGlu
aXRpYWwgdGhvdWdodHMgb24geW91ciBjb21tZW50czsgSSBwcmVzZW50IHRoZW0gZm9yIGRpc2N1
c3Npb24sIG5vdCBhcyBhIGRlZmVuc2Ugb2YgYSBwcmUtZGV0ZXJtaW5lZCBvdXRjb21lLiANCg0K
SSBmb2xsb3cgeW91ciBjb25jZXJuIHRoYXQgd2UgaGF2ZSBub3QgbWFkZSBhIGRpc3RpbmN0aW9u
IGJldHdlZW4gdGhlIGxhdW5kcnkgbGlzdCBvZiBwb3NzaWJsZSB0aHJlYXRzIHZlcnN1cyB0aG9z
ZSB0aHJlYXRzIHRoYXQgZGVzaWducyBiYXNlZCBvbiB0aGUgYXJjaGl0ZWN0dXJlIG11c3QgYWRk
cmVzcyBpbiBvcmRlciB0byBzYXRpc2Z5IHRoZSBzZWN1cml0eSByZXF1aXJlbWVudHMgb2YgdGhl
IGFyY2hpdGVjdHVyZS4gRXhjZWxsZW50IHBvaW50LCBpbiB0aGF0IEkgZm9yIG9uZSBoYXZlIG5v
dCBjb25zaWRlcmVkIHRoZSB0b3BpYyBpbiB0aGF0IGxpZ2h0IGJlZm9yZSwgYW5kIEkgYXBwcmVj
aWF0ZSB0aGUgbmVlZCB0byBkbyBzbyBub3cuIA0KDQpVcCB1bnRpbCB0aGlzIHBvaW50LCBpLmUu
IHByaW9yIHRvIHlvdXIgY29tbWVudHMsIHdlIGhhdmUgYmVlbiB3b3JraW5nIGJhc2VkIG9uIGF0
IGxlYXN0IHR3byBndWlkaW5nIHByaW5jaXBsZXMuIE9uZSBpcyB0aGF0IHdlIGFyZSBvbmx5IGFk
ZHJlc3Npbmcgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgd2hpY2ggYXJlIHNwZWNpZmljIHRvIHRp
bWUtc2Vuc2l0aXZlLCByb3V0ZWQsIGNlbnRyYWxseS1hZG1pbmlzdGVyZWQgbmV0d29ya3MsIHNv
IGFueXRoaW5nIHRoYXQgY291bGQgYmUgY29uc2lkZXJlZCB0byBiZSAiY292ZXJlZCBlbHNld2hl
cmUiIHdlIGhhdmUgaW50ZW50aW9uYWxseSBvbWl0dGVkLiBGb3IgZXhhbXBsZSB5b3UgY2l0ZSAi
dXNpbmcgSE1BQyBmb3IgbWVzc2FnZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiB3aXRob3V0IG1lbnRp
b24gb2YgaW5mcmFzdHJ1Y3R1cmUgZm9yIGRpc3RyaWJ1dGluZyB0aGUga2V5cyBmb3Iga2V5aW5n
IHRoZSBITUFDIjsgSSB3b3VsZCBleHBlY3QgdGhhdCB0aGlzIHRvcGljIGNvdWxkIGJlIHJlZ2Fy
ZGVkIGFzICJjb3ZlcmVkIGVsc2V3aGVyZSIsIGJ1dCBwbGVhc2UgY29ycmVjdCBtZSBpZiBJJ20g
bWlzc2luZyBzb21ldGhpbmcgaGVyZS4gDQoNCkFub3RoZXIgbWFpbiB0aHJlYWQgcnVubmluZyB0
aHJvdWdoIGFsbW9zdCBldmVyeSBhc3BlY3Qgb2YgRGV0TmV0IGlzIHRoYXQgYXMgbm90ZWQgaW4g
dGhlIFVzZSBDYXNlcyBkcmFmdCwgdGhlcmUgYXJlIG1hbnkgYW5kIGRpdmVyc2UgYXBwbGljYXRp
b25zIGZvciBEZXROZXQsIHNwYW5uaW5nIG5ldHdvcmtzIGNvbnRhaW5lZCB3aXRoaW4gYSBzaW5n
bGUgbWFjaGluZSBhbGwgdGhlIHdheSB0aHJvdWdoIG5ldHdvcmtzIHNwYW5uaW5nIGEgbmF0aW9u
LiBBcyBzdWNoIGl0IGlzIGRpZmZpY3VsdCB0byBtYWtlIGdlbmVyYWxpemF0aW9ucyBhYm91dCBh
bG1vc3QgYW55dGhpbmcgaW4gRGV0TmV0IC0gZXZlcnl0aGluZyBoYXMgdG8gYmUgZnJhbWVkIGFz
ICJzY2FsYWJsZSIgc28gdGhhdCB3ZSBkb24ndCBtYW5kYXRlIHNvbWV0aGluZyB0aGF0IG1ha2Vz
IHNlbnNlIGZvciBvbmUgdXNlIGNhc2UgYnV0IG5vdCBmb3IgYW5vdGhlci4gDQoNClNvIHRoZSBp
bnRlbnQgb2YgdGhlIFNlY3VyaXR5IGRyYWZ0IChpbiBjb25qdW5jdGlvbiB3aXRoIHNlY3VyaXR5
IHRleHQgaW4gdGhlIG90aGVyIERldE5ldCBkcmFmdHMpIHRodXMgZmFyIGhhcyBiZWVuIHRvIHBy
b3ZpZGUgc29tZSBpbnNpZ2h0cyBpbnRvIHRoZSBhc3BlY3RzIG9mIHNlY3VyaXR5IHRoYXQgYXJl
IGludHJvZHVjZWQgd2l0aCB0aW1lLXNlbnNpdGl2aXR5IHRvIHJvdXRlZCBuZXR3b3Jrcywgd2l0
aCBhIG5vZCBhcyB0byBob3cgdGhleSBtaWdodCBiZSBhZGRyZXNzZWQsIHdoaWxlIGJlaW5nIGFs
bW9zdCBjb21wbGV0ZWx5IG5vbi1wcmVzY3JpcHRpdmUgYWJvdXQgaXQsIGxlYXZpbmcgdGhlIGRl
dGFpbHMgYXMgYW4gZXhlcmNpc2UgZm9yIHRoZSByZWFkZXIgYmFzZWQgb24gdGhlaXIgcGFydGlj
dWxhciB1c2UgY2FzZS4gDQoNCkluIG90aGVyIHdvcmRzLCBhcyBzb29uIGFzIHdlIHNheSAiYSBE
ZXROZXQgbXVzdCBpbmNsdWRlIFthbnkgc3BlY2lmaWMgc2VjdXJpdHkgcHJvcGVydHldIiwgc29t
ZW9uZSB3aWxsIGluZXZpdGFibHkgY29tZSB1cCB3aXRoIGEgdXNlIGNhc2UgZm9yIHdoaWNoIHRo
YXQgZGlkbid0IG1ha2Ugc2Vuc2UgKGluc3VmZmljaWVudCB0aW1lLCBpbnN1ZmZpY2llbnQgQ1BV
IGN5Y2xlcywgbm90IHJlcXVpcmVkIGluIHRoaXMgY2FzZSBiZWNhdXNlIGJsYWgsIGV0Yy4pIEZv
ciBleGFtcGxlIHdoZW4gSSBsb29rIGF0IHlvdXIgcXVlc3Rpb25zIGxpa2UgIkRvIHdlIG5lZWQg
dG8gcHJvdmlkZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBmb3IgdGhlIG1hcmtpbmcsIG9yIGNvbmZp
ZGVudGlhbGl0eSBwcm90ZWN0aW9uLCB0b28/ICBEb2VzICBhdXRoZW50aWNhdGlvbi9pbnRlZ3Jp
dHkgbmVlZCB0byBiZSBwcm92aWRlZCBmb3IgaW4tbGluZSBvciBhcmUgb3V0LW9mLWJhbmQgY29u
c2lkZXJhdGlvbnMgaW4gcGxheT8iIG15IHRob3VnaHQgd291bGQgYmUgdG8gc2F5ICJ3ZWxsIGl0
IGRlcGVuZHMgb24gdGhlIHVzZSBjYXNlLCBpLmUuIHRoZSBzcGVjaWZpYyBpbXBsZW1lbnRhdGlv
biIuIA0KDQpTbyBhdCB0aGlzIHBvaW50IEkgZG9uJ3Qga25vdyB3aGV0aGVyIHRoaXMgc3RhbmNl
IGlzIHZhbGlkLCBvciB3aGV0aGVyIGl0IGlzIGFuIGFiZGljYXRpb24gb2Ygb3VyIHJlc3BvbnNp
YmlsaXR5LCBvciB3aGV0aGVyIHRoZXJlIGFyZSBzb21lIHN0YWtlcyBpbiB0aGUgZ3JvdW5kIHRo
YXQgd2UgY2FuIGFjdHVhbGx5IGNsYWltIHdpbGwgZml0IGFsbCB1c2UgY2FzZXMsIGFuZCB0aHVz
IHdlIHNob3VsZCBiZSBzdGF0aW5nIGFzIG1hbmRhdG9yeS4gQ2VydGFpbmx5IHdlIHdvdWxkIGxp
a2UgdG8gYXZvaWQgdGhlIG91dGNvbWUgdGhhdCB0aGUgYXJjaGl0ZWN0dXJlIGxlYXZlcyBvcGVu
IHF1ZXN0aW9ucyBhcyB0byB3aGV0aGVyIGEgZ2l2ZW4gaW1wbGVtZW50YXRpb24gc2F0aXNmaWVz
IGl0cyBzZWN1cml0eSByZXF1aXJlbWVudHMuIFdlIGFsc28gd2FudCB0byBhdm9pZCBiZWluZyBv
dmVybHkgcHJlc2NyaXB0aXZlIHN1Y2ggdGhhdCAiZXhjZXB0aW9ucyIgd291bGQgbmVlZCB0byBi
ZSBtYWRlIHRvIGFjY29tbW9kYXRlIGRpdmVyc2UgdXNlIGNhc2VzLiANCg0KUGxlYXNlIGxldCB1
cyBrbm93IGhvdyB0aGlzIGxpbmUgb2YgdGhpbmtpbmcgYWZmZWN0cyB5b3VyIGFzc2Vzc21lbnQg
b2Ygb3VyIHNpdHVhdGlvbiwgaWYgYXQgYWxsLiBNeSBzaG9ydCB0ZXJtIGdvYWwgaGVyZSBpcyB0
byB1bmJsb2NrIHB1YmxpY2F0aW9uIG9mIHRoZSBBcmNoaXRlY3R1cmUgZHJhZnQsIGJ1dCBub3Qg
YXQgdGhlIGV4cGVuc2Ugb2YgYWRlcXVhdGUgY292ZXJhZ2UgYW5kIGludGVncmF0aW9uIG9mIHNl
Y3VyaXR5LiANCg0KVGhhbmtzIGFnYWluIGZvciB5b3VyIHJldmlldywgDQpTaW5jZXJlbHksDQpF
dGhhbiAoYXMgZWRpdG9yIGFuZCBjby1hdXRob3Igb2YgdGhlIERldE5ldCBTZWN1cml0eSBkcmFm
dCBhbmQgdGhlIERldE5ldCBVc2UgQ2FzZXMgZHJhZnQpLiANCg0KDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogZGV0bmV0IDxkZXRuZXQtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo
YWxmIE9mIExvdSBCZXJnZXINClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyMSwgMjAxOSAxMjoz
MiBQTQ0KVG86IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1Pg0KQ2M6IGRyYWZ0LWlldGYt
ZGV0bmV0LWFyY2hpdGVjdHVyZUBpZXRmLm9yZzsgZGV0bmV0QGlldGYub3JnOyBUaGUgSUVTRyA8
aWVzZ0BpZXRmLm9yZz47IGRldG5ldC1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGV0
bmV0XSBCZW5qYW1pbiBLYWR1aydzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1kZXRuZXQtYXJjaGl0
ZWN0dXJlLTExOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQpIaSBCZW5qYW1pbiwNCg0K
T24gMi8yMC8yMDE5IDQ6MjEgUE0sIEJlbmphbWluIEthZHVrIHdyb3RlOg0KPiBIaSBMb3UsDQo+
DQo+IE9uIFdlZCwgRmViIDIwLCAyMDE5IGF0IDExOjM0OjExQU0gLTA1MDAsIExvdSBCZXJnZXIg
d3JvdGU6DQo+PiBPbiAyLzIwLzIwMTkgMTE6MDcgQU0sIEJlbmphbWluIEthZHVrIHdyb3RlOg0K
Pj4+IE9uIFdlZCwgRmViIDIwLCAyMDE5IGF0IDA5OjMzOjM0QU0gLTA1MDAsIExvdSBCZXJnZXIg
d3JvdGU6DQo+Pj4+IE9uIDIvMTkvMjAxOSAxMDo0NCBQTSwgQmVuamFtaW4gS2FkdWsgd3JvdGU6
DQo+Pj4+PiBJIG5vdGUgdGhhdCB0aGUgREVUTkVUIFdHIGlzIGV4cGxpY2l0bHkgY2hhcnRlcmVk
IHdpdGggYSB3b3JrIGl0ZW0gDQo+Pj4+PiBmb3IgdGhlICJvdmVyYWxsIGFyY2hpdGVjdHVyZTog
VGhpcyB3b3JrIGVuY29tcGFzc2VzIC4uLiBhbmQgc2VjdXJpdHkgYXNwZWN0cyIuDQo+Pj4+PiBJ
dCBzZWVtcyBpbmNvbXBsZXRlIHRvIHNwZWNpZnkgYW4gYXJjaGl0ZWN0dXJlIGZvciBhIHRvcGlj
IHN1Y2ggYXMgDQo+Pj4+PiBkZXRlcm1pbmlzdGljIG5ldHdvcmtpbmcgd2l0aG91dCBzcGVjaWZp
Y2FsbHkgY29uc2lkZXJpbmcgd2hhdCANCj4+Pj4+IHRocmVhdHMgYXJlIGFuZCBhcmUgbm90IGlu
IHNjb3BlIHRvIGJlIHByb3RlY3RlZCBhZ2FpbnN0Lg0KPj4+PiBUaGUgd29ya2luZyBncm91cCBj
ZXJ0YWlubHkgcmVjb2duaXplcyB0aGF0IHNlY3VyaXR5IGlzIGFuIA0KPj4+PiBpbXBvcnRhbnQg
dG9waWMgYW5kIG5lY2Vzc2FyeSBwYXJ0IG9mIHRoZSB3b3JrLiBUaGUgV0cnc8KgIGFwcHJvYWNo
IA0KPj4+PiB0byBlbnN1cmUgdGhhdCB0aGlzIHNpZ25pZmljYW50IHRvcGljIGlzIHN1ZmZpY2ll
bnRseSBjb3ZlcmVkIGlzIHRvIA0KPj4+PiBoYXZlIGHCoCBkb2N1bWVudCBkZWRpY2F0ZWQgdG8g
dGhlIHRvcGljLsKgIEFzIHlvdSBub3RlIGJlbG93IHRoaXMgDQo+Pj4+IHdvcmssIGRyYWZ0LWll
dGYtZGV0bmV0LXNlY3VyaXR5LCBpcyBub3QgYXQgdGhlIHNhbWUgbGV2ZWwgbWF0dXJpdHkgDQo+
Pj4+IC0gc28gcGxlYXNlIHN0YXkgdHVuZWQuwqAgT2YgY291cnNlLCB0aGUgV0cgd291bGQgd2Vs
Y29tZSBhbnkgaW5wdXQgDQo+Pj4+IG9uIHRoaXMgc2VjdXJpdHkgZHJhZnQgbm93IG9yIGV2ZW4g
YSBmdWxsIGVhcmx5LXJldmlldyBvciBzZWN1cml0eSBhcmVhIGFkdmlzb3IuDQo+Pj4gSSBkbyBh
cHByZWNpYXRlIHRoYXQgdGhlIFdHIGhhcyB0YWtlbiB0aGUgdGltZSB0byB3b3JrIG9uIGEgDQo+
Pj4gZGVkaWNhdGVkIHNlY3VyaXR5IGRvY3VtZW50LCB0aGF0IGdvZXMgdGhyb3VnaCB0aGUgKHRl
ZGlvdXMhKSBlZmZvcnQgDQo+Pj4gdG8gdGFidWxhdGUgdGhlIHZhcmlvdXMga25vd24gYXR0YWNr
ZXIgY2FwYWJpbGl0aWVzLCB0aHJlYXRzLCBhbmQgdGhlaXIgaW50ZXJhY3Rpb25zLg0KPj4+DQo+
Pj4gV2hhdCBJIHRoaW5rIGlzIG1pc3NpbmcgZnJvbSB0aGUgaGlnaC1sZXZlbCBhcmNoaXRlY3R1
cmUgZG9jdW1lbnQgaXMgDQo+Pj4gYSBzZW5zZSBmb3Igd2hhdCBzZWN1cml0eSBnb2FscyB0aGUg
YXJjaGl0ZWN0dXJlIGludGVuZHMgdG8gYWNoaWV2ZS4gIA0KPj4+IEl0J3MgZmluZSB0byBoYXZl
IHRoaXMgYmUgc2VwYXJhdGUgZnJvbSB0aGUgbml0dHktZ3JpdHR5IHN0dWZmIGluIA0KPj4+IHRo
ZSBzZXBhcmF0ZSBkb2N1bWVudCwgYnV0IHRoZXNlIGhpZ2gtbGV2ZWwgcXVlc3Rpb25zIGNhbiBo
YXZlIGFuIA0KPj4+IGltcGFjdCBvbiB0aGUgaGlnaC1sZXZlbCBkZXNpZ24gb2YgdGhlIHByb3Rv
Y29sIGVjb3N5c3RlbSBhcyBhIA0KPj4+IHdob2xlLiAgV2UgaGF2ZSBtb3VuZHMgb2YgZXhhbXBs
ZXMgb2YgImNvbWUgdXAgd2l0aCBhIGRlc2lnbjsgYm9sdCBzZWN1cml0eSBvbiBhcyBhbiBhZnRl
cnRob3VnaHQiDQo+Pj4gd29ya2luZyBwb29ybHkgb3IgYmVpbmcgbmlnaC1pbXBvc3NpYmxlLCBh
bmQgSSBoYXZlbid0IHNlZW4gYW55IA0KPj4+IGF0dGVtcHQgYXQganVzdGlmaWNhdGlvbiBmb3Ig
d2h5IGRvaW5nIHNvIGhlcmUgaXMgbGlrZWx5IHRvIGJlIGFueSBkaWZmZXJlbnQuDQo+Pj4gSW5j
bHVkaW5nIHRoZSBzZWN1cml0eSBjb25jZXB0cyBmcm9tIHRoZSBzdGFydCBhbmQgd2hvbGx5IA0K
Pj4+IGludGVncmF0aW5nIHRoZW0gaW50byB0aGUgc3lzdGVtIHRlbmRzIHRvIHByb2R1Y2UgYSBt
dWNoIG1vcmUgDQo+Pj4gZWxlZ2FudCBkZXNpZ24gYW5kIHNtb290aGVyIG91dGNvbWVzIGFsbCBh
cm91bmQuDQo+PiBXZSB3ZW50IGJhY2sgYW5kIGZvcnRoIG9uIGhvdyBtdWNoIG9mIHRoZSBzZWN1
cml0eSB0b3BpYyB0byBpbmNsdWRlIA0KPj4gaW4gdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBh
bmQgc2V0dGxlZCBvbiB0aGUgY3VycmVudCB0ZXh0IG9mIA0KPj4gc2VjdGlvbiA1IHdoZXJlIGp1
c3QgaGlnaCBsZXZlbCBzZWN1cml0eSByZXF1aXJlbWVudHMgYXJlIGlkZW50aWZpZWQuwqAgDQo+
PiBGcm9tIHlvdXIgbGlzdCBiZWxvdywgdGhlIGFyY2hpdGVjdHVyZSBjb3ZlcnMgdGhlIHBvaW50
cyB5b3UgcmFpc2UgDQo+PiAobm9uLWRldG5ldCB0cmFmZmljIGltcGFjdGluZyBkZXRuZXQgdHJh
ZmZpYywgYW5kIGRldG5ldCB0cmFmZmljIA0KPj4gdHJ5aW5nIHRvIHVzZSBtb3JlIHRoYW4gaXRz
IGFsbG9jYXRpb24pIG1haW5seSBmcm9tIGEgc2VydmljZSANCj4+IGRlbGl2ZXJ5IHBlcnNwZWN0
aXZlLsKgIEl0IGRvZXMgbWVudGlvbiAic2hhcGluZyIgYXMgYSBzZWN1cml0eSANCj4+IGNvbmNl
cm4sIHRoZSBkb2N1bWVudCBjb3VsZCBleHBhbmQgdGhlc2UgaWYgaGVscGZ1bC4gQnV0IEkgdGhp
bmsgdGhlIA0KPj4gcmVhbCBkaXNjdXNzaW9uIHBvaW50IGlzIGhvdyBtdWNoIG9mIHRoZSBzZWN1
cml0eSBkZXRhaWxzIHNob3VsZCBiZSANCj4+IGluIHRoZSBiYXNlICh2cyBkZWRpY2F0ZWQpIGRv
Y3VtZW50wqAgLS0gYW5kIHRoYXQgeW91IGRpc2FncmVlIHdpdGggDQo+PiB3aGVyZSB0aGUgV0cg
aGFzIGRyYXduIHRoZSBsaW5lLsKgIElzIHRoaXMgY29ycmVjdD8NCj4gV2VsbCwgaXQncyBub3Qg
YXMgbXVjaCB0aGF0IEkgZGlzYWdyZWUgYWJvdXQgd2hlcmUgdGhlIGxpbmUgaXMgZHJhd24sIA0K
PiBhcyB0aGF0IEkgZGlzYWdyZWUgd2l0aCB0aGUgY2hhcmFjdGVyaXphdGlvbiBhcyAiaGlnaCBs
ZXZlbCBzZWN1cml0eSANCj4gcmVxdWlyZW1lbnRzIi4NCj4NCj4gVGhlIGZpcnN0IHBhcmFncmFw
aCBjb3ZlcnMgdG9waWNzIHdvcnRoIGluY2x1ZGluZyBoZXJlLCBjZXJ0YWlubHkgLS0gDQo+IGFu
IGF0dGFja2VyIHRoYXQgY2FuIGludHJvZHVjZSBkZWxheSBjYW4gaW5oZXJlbnRseSBicmVhayB0
aGUgRGV0TmV0IA0KPiBndWFyYW50ZWVzLCBhbmQgdGhlcmUgaXMgbm8gZnVydGhlciBkZWZlbnNl
LiAgQnV0IHRoZSB0ZXh0IGNvdWxkIA0KPiBwcm9iYWJseSBnbyBmdXJ0aGVyIHRoYW4gaXRzIGN1
cnJlbnQgdmVyc2lvbiBhbmQgZXhwbGljaXRseSBjYWxsIG91dCANCj4gdGhhdCBubyB0ZWNobmlj
YWwgbWVhc3VyZXMgY2FuIGRlZmVuZCBhZ2FpbnN0IHN1Y2ggZGVsYXksIG90aGVyIHRoYW4gDQo+
IGJ5IHJlcm91dGluZy9hdm9pZGluZyB0aGUgY29tcHJvbWlzZWQgcG9zaXRpb24uDQo+DQo+IFRo
ZSBzZWNvbmQgcGFyYWdyYXBoIGFsc28gY292ZXJzIGEgdG9waWMgd29ydGggbm90aW5nLCB0aGF0
IGVudHJvcHkgDQo+IGFuZCBNdXJwaHkgYXMgYXMgaW1wb3J0YW50IG9mIHJpc2tzIHRvIGNvbnNp
ZGVyIGFzIGFjdGl2ZSBhdHRhY2tzLg0KPg0KPiBUaGUgcmVzdCBvZiB0aGUgc2VjdGlvbi9saXN0
IGRvbid0IHNlZW0gdG8gbWF0Y2ggdXAgd2l0aCB0aGUgDQo+IGhpZ2gtbGV2ZWwgdmlldywgdGhv
dWdoIC0tICJwcm90ZWN0aW9uIG9mIHRoZSBzaWduYWxpbmcgcHJvdG9jb2wiLCBidXQgDQo+IHBy
b3RlY3Rpb24gYWdhaW5zdCB3aGF0PyAgQXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24g
YXJlIA0KPiBpbXBvcnRhbnQgcGFydHMgb2Ygc2VjdXJpdHksIGJ1dCBhdXRob3JpemF0aW9uIGlz
IHRpZWQgdG8gYWN0aW9ucyBhbmQgDQo+IGVudGl0aWVzLCBub3QganVzdCBlbnRpdGllcyBpbiB2
YWN1by4gIEZvciAiaWRlbnRpZmljYXRpb24gYW5kIHNoYXBpbmcgDQo+IG9mIERldE5ldCBmbG93
cyIsIGlmIHNlY3VyaXR5IG11c3QgY292ZXIgdGhlbSwgd2hhdCBzZWN1cml0eSANCj4gcHJvcGVy
dGllcyBhcmUgbmVlZGVkLiAgRG8gd2UgbmVlZCB0byBwcm92aWRlIGludGVncml0eSBwcm90ZWN0
aW9uIGZvciANCj4gdGhlIG1hcmtpbmcsIG9yIGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0aW9uLCB0
b28/ICBEb2VzIA0KPiBhdXRoZW50aWNhdGlvbi9pbnRlZ3JpdHkgbmVlZCB0byBiZSBwcm92aWRl
ZCBmb3IgaW4tbGluZSBvciBhcmUgb3V0LW9mLWJhbmQgY29uc2lkZXJhdGlvbnMgaW4gcGxheT8N
Cj4NCj4gVGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50IHByZXNlbnRzIGEgZ29vZCBoaWdoIGxldmVs
IHBpY3R1cmUgb2Ygd2hhdCANCj4gcGllY2VzIHdpbGwgYmUgaW52b2x2ZWQgaW4gYSBzeXN0ZW0s
IGFuZCBob3cgdGhleSBmaXQgdG9nZXRoZXIuICBJJ20gDQo+IGhvcGluZyB0byBzZWUgYSBoaWdo
LWxldmVsIHBpY3R1cmUgb2Ygd2hhdCBhdHRhY2tzL2ZhaWx1cmVzIHRoZSANCj4gYXJjaGl0ZWN0
dXJlIGRvZXMgYW5kIGRvZXMgbm90IGFpbSB0byBwcm90ZWN0IGFnYWluc3QuICBJdCdzIHNvbWV3
aGF0IA0KPiBpbXBsaWVkIHRoYXQgd2UgbmVlZCB0byBwcm90ZWN0IGFnYWluc3QgdGhlIGZhaWx1
cmUgb2YgYW55IHNpbmdsZSBub2RlIA0KPiBvciBsaW5rIChleGNlcHQgYXQgdGhlDQo+IGJvdW5k
YXJ5KSBkdWUgdG8gcmFuZG9tIGZhdWx0czsgZXhwbGljaXRseSBzYXlpbmcgdGhpcyB3b3VsZCBi
ZSBhIA0KPiBwZXJmZWN0IGh0aW5nIHRvIGluY2x1ZGUgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVy
YXRpb25zIGhlcmUhICBPbmNlIHdlIA0KPiBnZXQgYmV5b25kIGVudHJvcHkgYXMgYW4gYXR0YWNr
LCBpbnRvIG1vcmUgYWN0aXZlIGF0dGFjayBzY2VuYXJpb3MsIA0KPiB0aG91Z2gsIHdlIG5lZWQg
dG8gY29uc2lkZXIgd2hhdCBjYXBhYmlsaXRpZXMgYW4gYXR0YWNrZXIgbWlnaHQgaGF2ZS4gIA0K
PiBEbyB3ZSBwcm90ZWN0IGFnYWluc3QgYW4gZW50aXR5IHdpdGggdGhlIGFiaWxpdHkgdG8gaW5q
ZWN0IHZhcmlvdXMgDQo+IGZvcm1zIG9mIHRyYWZmaWM/ICBNb2RpZnkgb3IgZHJvcCB2YWxpZCB0
cmFmZmljPyAgQXJlIHRoZXJlIGFueSANCj4gKGNsYXNzZXMgb2YpIGNyZWRlbnRpYWxzIHRoYXQg
d2UgYXNzdW1lIG11c3QgYmUgc2VjdXJlbHkgaGVsZCwgb3Igd2lsbCANCj4gd2UgYXR0ZW1wdCB0
byBwcm90ZWN0IGFnYWluc3QgYXR0YWNrZXJzIHRoYXQgaGF2ZSBzb21lIHByaXZpbGVnZSANCj4g
d2l0aGluIHRoZSBzeXN0ZW0/ICAoTm90ZSB0aGF0IG1pc2JlaGF2aW5nIGhhcmR3YXJlIGNhbiBz
b21ldGltZXMgDQo+IHByZXNlbnQgYXMgc2ltaWxhciBvciBpZGVudGljYWwgdG8gc3VjaCBhbiBh
dHRhY2tlci4pDQo+DQo+IERvZXMgdGhpcyBnaXZlIGEgYmV0dGVyIHBpY3R1cmUgb2Ygd2hhdCBJ
J20gdGhpbmtpbmcgb2YgYXMgImhpZ2gtbGV2ZWwgDQo+IHNlY3VyaXR5IHJlcXVpcmVtZW50cyI/
ICBJIGRvbid0IG5lY2Vzc2FyaWx5IG5lZWQgZGV0YWlscyBvZiBzcGVjaWZpYyANCj4gaGFyZHdh
cmUgb3IgY3JlZGVudGlhbHMgYXQgcGxheSwgYW5kIGNlcnRhaW5seSBub3QgZm9yIHRoZSBzb2x1
dGlvbnMsIA0KPiBidXQgSSB3YW50IHRvIGhhdmUgYSBjbGVhciBwaWN0dXJlIG9mIHdoYXQgdGhl
IHNjb3BlIG9mIGZ1dHVyZSANCj4gc2VjdXJpdHkgYW5hbHlzaXMgd2lsbCBiZS4gICJIb3cgd2ls
bCBJIGJlIGFibGUgdG8gdGVsbCBpZiB0aGUgYWN0dWFsIA0KPiBwcm90b2NvbHMgbWVldCB0aGUg
c2VjdXJpdHkgcmVxdWlyZW1lbnRzIG9mIHRoZSBhcmNoaXRlY3R1cmU/Ig0KDQpJJ2xsIGdldCB3
aXRoIGF1dGhvcnMgKG9mIGJvdGggdGhlIGFyY2hpdGVjdHVyZSBhbmQgc2VjdXJpdHkgZG9jcykg
YW5kIHNlZSBob3cgbXVjaCB0aGV5IHRoaW5rIGNhbiBiZSByZWFzb25hYmx5IGJlIGFkZGVkIHRv
IHRoaXMgZG9jdW1lbnQgLS0gdG8gYmUgY2xlYXIgeW91ICphcmUqIGFza2luZyBmb3IgYSBjaGFu
Z2UgaW4gaG93IHRoZSBXRyBkZWNpZGUgdG8gYWRkcmVzcyB0aGlzIHRvcGljIGFuZCB3aGF0IHdv
dWxkIGdvIGluIHdoaWNoIGRvY3VtZW50Lg0KDQpMb3UNCg0KPiAtQmVuamFtaW4NCj4NCj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZGV0bmV0IG1h
aWxpbmcgbGlzdA0KPiBkZXRuZXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9kZXRuZXQNCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCmRldG5ldCBtYWlsaW5nIGxpc3QNCmRldG5ldEBpZXRmLm9yZw0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQNCg==


From nobody Tue Feb 26 04:45:34 2019
Return-Path: 
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 9E4571200B3 for ; Tue, 26 Feb 2019 04:45:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 FzNv_CTeF2vH for ; Tue, 26 Feb 2019 04:45:28 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50FB412F1AC for ; Tue, 26 Feb 2019 04:45:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed;  q=dns/txt; i=@ericsson.com; t=1551185122; x=1553777122; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Cnbz36NbvS7OZVGOT6bTHu2WqxXFc0knPDh5Yg7be30=; b=KsV4h3OVfEA35xx1agQg/jzyRE4t0rsf4N+nJgqmB3eGWdT3ED8b69kHgWJIMVAJ 26HClnTSLAdERkmuN4L9vvqYH/+pB7aaq/9oVt1ePJ5pbRUUcPamxSxwfVlwbr8R +OPdkhJnjTFAOWbWfj6pS07GxKGAdov4DdHyeBbXNpM=;
X-AuditID: c1b4fb3a-5c9c29e00000672c-b4-5c7534e2a712
Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id DE.5E.26412.2E4357C5; Tue, 26 Feb 2019 13:45:22 +0100 (CET)
Received: from ESESBMR501.ericsson.se (153.88.183.129) by ESESSMB504.ericsson.se (153.88.183.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 26 Feb 2019 13:45:22 +0100
Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESBMR501.ericsson.se (153.88.183.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 26 Feb 2019 13:45:21 +0100
Received: from [131.160.183.210] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.187) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Tue, 26 Feb 2019 13:45:21 +0100
To: "Mirja Kuehlewind (IETF)" 
CC: Lou Berger , The IESG , , , 
References: <155066795164.31466.275999283339131275.idtracker@ietfa.amsl.com> <77e87eca-07df-99eb-9edb-7f6f18913dfd@labn.net> <5AF7514B-B8C9-48E5-B1F4-BF2139EB128A@kuehlewind.net> <8b47372c-210a-5ecb-f563-788d84535279@labn.net>
From: =?UTF-8?Q?J=c3=a1nos_Farkas?= 
Message-ID: <5a998fcf-0572-82f6-8bee-2cac21635117@ericsson.com>
Date: Tue, 26 Feb 2019 13:45:21 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <8b47372c-210a-5ecb-f563-788d84535279@labn.net>
Content-Type: multipart/alternative; boundary="------------087B3AA5468A747AF71CABE8"
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2J7le4jk9IYgzlnRSyu9f9gsfj9aTaL xYdvM1ksZvyZyGzx4vpHZouO5rcsDmweS5b8ZPJo+biQ1ePDpma2AOYoLpuU1JzMstQifbsE royX+xvYC85PZ6ro2X2BrYHx/HHGLkYODgkBE4kb2/27GLk4hASOMErcmXaMCcL5xiix4dl3 djhnxftuFgjnGKPEhOsLwRxhgXmMEnMW7wLq4eQQETCWODz5OytIgllgOqPE+fkv2CBaXjBK vJ5+gBGkik3AXuLupQ3MIDYvkP3ryXSwbhYBVYldDefAakQFYiU+XVkMVSMocXLmExYQm1PA RmLNhU6wOLNAmMSWZX/ZIWxxiVtP5oPNERJQk3jfcIdxAqPQLCTts5C0zELSAmFbSMycf54R wpaXaN46mxnC1pBonTOXHVl8ASP7KkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAODu45bfV DsaDzx0PMQpwMCrx8BpplsYIsSaWFVfmHmKU4GBWEuG9oQoU4k1JrKxKLcqPLyrNSS0+xCjN waIkzvtHSDBGSCA9sSQ1OzW1ILUIJsvEwSnVwOi0WeV8CNsj/5nHLecdl/WvWG6w3zLgfPLz Iwm70qu9/vytj/2x4Rv/h83VKYunmHMpz2i8uOSzuzzv9susCyZc3R5ddqUhlmXT5S8+l3Uu htevXhchzMy9KXbN4ohp1d9sl1ixvpSS+npiT+rJpLD7didsrt69LtBf3dy7KYrrZObE7wKm 7R+VWIozEg21mIuKEwHATTHsrwIAAA==
Archived-At: 
Subject: Re: [Detnet]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-detnet-architecture-11=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2019 12:45:32 -0000

--------------087B3AA5468A747AF71CABE8
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit

Hi Mirja,

Thank you for your review!

Please see in-line changes suggested to address your comments.


On 2/20/2019 5:24 PM, Lou Berger wrote:
> Hi Mirja,
>
>     See below.
>
> On 2/20/2019 11:06 AM, Mirja Kuehlewind (IETF) wrote:
>> Hi Lou,
>>
>> I’m happy to see that my concerns seem to be cover. So maybe this is 
>> mostly a point about wording. Please see below.
>>
>>> Am 20.02.2019 um 15:46 schrieb Lou Berger :
>>>
>>> Hi Mirja,
>>>
>>> I'm responding as doc shepherd (and chair). Thank you for your 
>>> comments.  Please see below for specific responses.
>>>
>>> On 2/20/2019 8:05 AM, Mirja Kühlewind wrote:
>>>> Mirja Kühlewind has entered the following ballot position for
>>>> draft-ietf-detnet-architecture-11: 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:
>>>> https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> DISCUSS:
>>>> ----------------------------------------------------------------------
>>>>
>>>> Thanks for addressing the tsv-art review comments  (and big thanks 
>>>> to Michael
>>>> and David!) and all the work done so far! I think the document is 
>>>> in good shape
>>>> and I only have one minor comment that I would like to see 
>>>> addressed/more
>>>> explicitly spelled out. However, this should be done quickly with 
>>>> potentially
>>>> 2-3 small changes in the draft. See below.
>>> The input from Michael and David certainly led to a much improved 
>>> document.  If you can help the authors with some specific text 
>>> suggestions that would be most helpful.
>>>
>>>
>>>> Given that DetNet traffic is often assumed to be not congestion 
>>>> controlled, it
>>>> is important that there is also some network function that makes 
>>>> sure the
>>>> source traffic stays within the requested bandwidth limit in-order 
>>>> to protect
>>>> non-Detnet traffic. This is to some extended discussed in section 
>>>> 3.3.2 but I
>>>> think it should be more clearly spelled out that this would require 
>>>> a rate
>>>> limiting function at each DetNet source/relay (tunnel ingress). 
>>>> Currently sec
>>>> 3.3.2 says:
>>>>
>>>> "Filters and policers should be used in a DetNet network to
>>>>     detect if DetNet packets are received on the wrong interface, 
>>>> or at
>>>>     the wrong time, or in too great a volume."
>>>>
>>>> However, maybe this case of limiting non-congestion controlled 
>>>> traffic (in case
>>>> the source in not keeping to the limits on purpose/in order to 
>>>> cheat, because
>>>> it couldn't estimate the needed bandwidth requirement an better, or 
>>>> due to
>>>> timely fluctuations) could be explained more clearing and the 
>>>> respective
>>>> requirement to implement rate limiting could be state separately 
>>>> and more
>>>> strongly...?
>>> Section 3.2.1.1 days:
>>>
>>>    Ensuring adequate buffering requires, in turn, that the source, and
>>>    every DetNet node along the path to the destination (or nearly every
>>>    node, see Section 4.3.3) be careful to regulate its output to not
>>>    exceed the data rate for any DetNet flow, except for brief periods
>>>    when making up for interfering traffic.  Any packet sent ahead of 
>>> its
>>>    time potentially adds to the number of buffers required by the next
>>>    hop DetNet node and may thus exceed the resources allocated for a
>>>    particular DetNet flow.
>>>
>>> Section 3.3.1 also says:
>>>
>>>    Starvation of non-DetNet traffic must be avoided, e.g., by traffic
>>>    policing functions (e.g., [RFC2475]).  Thus, the net effect of the
>>>    presence of DetNet flows in a network on the non-DetNet flows is
>>>    primarily a reduction in the available bandwidth.
>>>
>>> Is this not sufficient?  If not, can you suggest some additional 
>>> language?
>> My question is mostly if you only need to protect _complete_ 
>> starvation or any over-use by DetNet flows and how you would do that. 
>> If the answer is to rate limit the DetNet flows at ingress to the 
>> allocated bandwidth, that would completely address my concern. 
>> However note that buffer dimensioning and rate limiting is not the 
>> same. Rate limiting is usually a scheduling question, e.g. using a 
>> token bucket scheme or a fixed non-work conserving scheduler. 
>> Therefore it would be nice to add one additional sentence in section 
>> 3.2 that spells that out directly. e.g. something like:
>>
>> „In order to protect non-DetNet traffic from potentially misbehaving 
>> DetNet-Traffic sources, rate limiting, e.g. using a token bucket 
>> scheme, at each tunnel ingress must be applied.“
>
>> I’m sure you can adapt the wording to make it more DetNet-like 
>> language and maybe you also want to add another sentence explaining 
>> the problem, please feel free to do so but that’s more or less what 
>> I’m looking for.
>
> I do agree that we seem to be having a terminology issue here - and 
> that we are on the same page with what should happen.  The terminology 
> I've used/seen in past RFCs has usually used the terms 'shaping' and 
> 'policing' - and these are what we've been using within the WG.  For 
> example, both of these terms are used in RFC2475 but 'rate limiting' 
> is not. Would it work for you for the draft to use/adapt the rest of 
> your language, but keep 'by traffic policing functions (e.g., 
> [RFC2475])' rather than 'rate limiting, e.g. using a token bucket 
> scheme,' ?

We could extend the 2nd paragraph in 3.2.1.1 
(https://tools.ietf.org/html/draft-ietf-detnet-architecture-11#section-3.2.1.1) 
to capture this comment:

OLD:
             Ensuring adequate buffering requires, in turn, that the 
source, and every DetNet
             node along the path to the destination (or nearly every 
node, see
             ) be careful to regulate its 
output to not exceed the
             data rate for any DetNet flow, except for brief periods 
when making up for
             interfering traffic.  Any packet sent ahead of its time 
potentially adds to the
             number of buffers required by the next hop DetNet node and 
may thus exceed the resources
             allocated for a particular DetNet flow.

NEW:

             Ensuring adequate buffering requires, in turn, that the 
source, and every DetNet
             node along the path to the destination (or nearly every 
node, see
             ) be careful to regulate its 
output to not exceed the
             data rate for any DetNet flow, except for brief periods 
when making up for
             interfering traffic.  Any packet sent ahead of its time 
potentially adds to the
             number of buffers required by the next hop DetNet node and 
may thus exceed the resources
             allocated for a particular DetNet flow. Furthermore, rate 
limiting, e.g., using traffic
             policing and shaping functions, e.g., , at the ingress of the
             DetNet domain must be applied. This is needed for meeting 
the requirements of DetNet
             flows as well as for protecting non-DetNet traffic from 
potentially misbehaving DetNet
             traffic sources.


Furthermore, replace the two occurrences of "policing" with "policing 
and shaping":

OLD:
    Starvation of non-DetNet traffic must be avoided, e.g., by traffic
    policing functions (e.g., [RFC2475]).

NEW:
    Starvation of non-DetNet traffic must be avoided, e.g., by traffic
    policing and shaping functions (e.g., [RFC2475]).


OLD:
    Examples of such techniques include traffic policing
    functions (e.g., [RFC2475]) and separating flows into per-flow rate-
    limited queues.

NEW:
    Examples of such techniques include traffic policing and shaping
    functions (e.g., [RFC2475]) and separating flows into per-flow rate-
    limited queues.

>
>
>>
>>>> One related comment on this sentence in Sec 3.1:
>>>>
>>>> "As DetNet provides allocated resources (including provisioned 
>>>> capacity)
>>>>     to DetNet flows the use of transport layer congestion control
>>>>     [RFC2914] by App-flows is explicitly not required."
>>>>
>>>> I guess congestion control should still be a requirement if the 
>>>> App-flow also
>>>> passes not-DetNet-aware segments of the path, e.g. maybe the first 
>>>> hop.
>>> This point is addressed in section 3.3.2
>>>
>>>    Note that the sending of App-flows that do not use transport layer
>>>    congestion control per [RFC2914] into a network that is not
>>>    provisioned to handle such DetNet traffic has to be treated as a
>>>    fault and prevented.
>>>
>>>> Usually
>>>> use of congestion control for application limited flows is also not 
>>>> a problem
>>>> if sufficient bandwidth is available. Also note that, as I stated 
>>>> above, the
>>>> important part for not requiring congestion control is actually not 
>>>> only that
>>>> resources are allocated but also that rate limiting is in place to 
>>>> make sure
>>>> resources usage cannot be exceeded above the reserved allocation. 
>>>> Maybe this
>>>> sentence could also be further clarified in the draft...?
>>> Is the above sufficient?  If not, can you suggest some additional 
>>> language?
>> Maybe we can just extend the above statement a bit in order to be 
>> crystal clear about this, e.g.:
>>
>> "As DetNet flow are assumed to be rate-limited and DetNet is designed 
>> to provide sufficient allocated resources (including provisioned 
>> capacity), the use of transport layer congestion control [RFC2914] 
>> for end-to-end DetNet flows is not required, however, if resources 
>> are allocated appropriately, use of congestion control should not 
>> impact transmission negatively.“
> Great!  (I'll leave it to the authors to do the final wording adaptation)

"App-flow" seems to be better than "end-to-end DetNet flow". The change 
with that would be:

OLD:
    As
    DetNet provides allocated resources (including provisioned capacity)
    to DetNet flows the use of transport layer congestion control
    [RFC2914] by App-flows is explicitly not required.

NEW:
             As
             DetNet flows are assumed to be rate-limited and DetNet is 
designed
             to provide sufficient allocated resources (including 
provisioned
             capacity), the use of transport layer congestion control 
[RFC2914]
             for App-flows is not required; however, if resources are 
allocated
             appropriately, use of congestion control should not impact
             transmission negatively.

>>
>>>> And then one more small comment that is also related. Sec 3.2.2.2 
>>>> says:
>>>>
>>>> "If packet replication and elimination is used over paths with
>>>>     resource allocation (Section 3.2.1), ..."
>>>>
>>>> My assumption was that all DetNet traffic is send over pre-allocated
>>>> resources...? If that is not true that has implication on 
>>>> congestion control
>>>> and needs some additional considerations. Can you please confirm 
>>>> that and maybe
>>>> clarify in the draft! Thanks!
>>> The intent was to cover sending over non-pre-allocated paths as a 
>>> fault case, and cover it in section 3.3.2.
>> If that is the case, maybe we can just removed the half-sentence I 
>> cited above?
>
> WFM!

The sentence after removing the text as you suggest:

OLD:
    If packet replication and elimination is used over paths with
    resource allocation (Section 3.2.1), and member flows that take
    different-length paths through the network are combined, a merge
    point may require extra buffering to equalize the delays over the
    different paths.

NEW:
    If member flows that take different-length paths through the
    network are combined, a merge point may require extra buffering
    to equalize the delays over the different paths.


Thank you!
Janos


>
> Thank you!
>
>>
>> Thanks!
>> Mirja
>>
>>> In addition to the previously quoted text, the section also says:
>>>
>>>    PRF generated DetNet member flows also need to
>>>    be treated as not using transport layer congestion control even if
>>>    the original App-flow supports transport layer congestion control
>>>    because PREOF can remove congestion indications at the PEF and
>>>    thereby hide such indications (e.g., drops, ECN markings, increased
>>>    latency) from end systems.
>>>
>>> Does this address your concern?
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>>
>>>> I agree with Alexey and Benjamin that this document should be 
>>>> informational.
>>>> Informational documents can also have IETF consensus, so that 
>>>> cannot be the
>>>> reason to go for PS. However, this document does not specify a 
>>>> protocol or any
>>>> requirements that are mandatory to implement for interoperability 
>>>> and therefore
>>>> should not be PS.
>>>>
>>> I defer to the IESG and AD on this...
>>>
>>> Thank you!
>>>
>>> Lou
>>>
>>>> _______________________________________________
>>>> detnet mailing list
>>>> detnet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>
>>


--------------087B3AA5468A747AF71CABE8
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Mirja,

        

        Thank you for your review!

        

        Please see in-line changes suggested to address your comments.

    

    

    
On 2/20/2019 5:24 PM, Lou Berger wrote:

    

    
Hi Mirja,
      

      

          See below.
      

      

      On 2/20/2019 11:06 AM, Mirja Kuehlewind (IETF) wrote:
      

      
Hi Lou,
        

        

        I’m happy to see that my concerns seem to be cover. So maybe
        this is mostly a point about wording. Please see below.
        

        

        
Am 20.02.2019 um 15:46 schrieb Lou
          Berger <lberger@labn.net>:
          

          

          Hi Mirja,
          

          

          I'm responding as doc shepherd (and chair). Thank you for your
          comments.  Please see below for specific responses.
          

          

          On 2/20/2019 8:05 AM, Mirja Kühlewind wrote:
          

          
Mirja Kühlewind has entered the
            following ballot position for
            

            draft-ietf-detnet-architecture-11: 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:
            

https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/
            

            

            

            

----------------------------------------------------------------------
            

            DISCUSS:
            

----------------------------------------------------------------------
            

            

            Thanks for addressing the tsv-art review comments  (and big
            thanks to Michael
            

            and David!) and all the work done so far! I think the
            document is in good shape
            

            and I only have one minor comment that I would like to see
            addressed/more
            

            explicitly spelled out. However, this should be done quickly
            with potentially
            

            2-3 small changes in the draft. See below.
            

          

          The input from Michael and David certainly led to a much
          improved document.  If you can help the authors with some
          specific text suggestions that would be most helpful.
          

          

          

          
Given that DetNet traffic is often
            assumed to be not congestion controlled, it
            

            is important that there is also some network function that
            makes sure the
            

            source traffic stays within the requested bandwidth limit
            in-order to protect
            

            non-Detnet traffic. This is to some extended discussed in
            section 3.3.2 but I
            

            think it should be more clearly spelled out that this would
            require a rate
            

            limiting function at each DetNet source/relay (tunnel
            ingress). Currently sec
            

            3.3.2 says:
            

            

            "Filters and policers should be used in a DetNet network to
            

                detect if DetNet packets are received on the wrong
            interface, or at
            

                the wrong time, or in too great a volume."
            

            

            However, maybe this case of limiting non-congestion
            controlled traffic (in case
            

            the source in not keeping to the limits on purpose/in order
            to cheat, because
            

            it couldn't estimate the needed bandwidth requirement an
            better, or due to
            

            timely fluctuations) could be explained more clearing and
            the respective
            

            requirement to implement rate limiting could be state
            separately and more
            

            strongly...?
            

          

          Section 3.2.1.1 days:
          

          

             Ensuring adequate buffering requires, in turn, that the
          source, and
          

             every DetNet node along the path to the destination (or
          nearly every
          

             node, see Section 4.3.3) be careful to regulate its output
          to not
          

             exceed the data rate for any DetNet flow, except for brief
          periods
          

             when making up for interfering traffic.  Any packet sent
          ahead of its
          

             time potentially adds to the number of buffers required by
          the next
          

             hop DetNet node and may thus exceed the resources allocated
          for a
          

             particular DetNet flow.
          

          

          Section 3.3.1 also says:
          

          

             Starvation of non-DetNet traffic must be avoided, e.g., by
          traffic
          

             policing functions (e.g., [RFC2475]).  Thus, the net effect
          of the
          

             presence of DetNet flows in a network on the non-DetNet
          flows is
          

             primarily a reduction in the available bandwidth.
          

          

          Is this not sufficient?  If not, can you suggest some
          additional language?
          

        

        My question is mostly if you only need to protect _complete_
        starvation or any over-use by DetNet flows and how you would do
        that. If the answer is to rate limit the DetNet flows at ingress
        to the allocated bandwidth, that would completely address my
        concern. However note that buffer dimensioning and rate limiting
        is not the same. Rate limiting is usually a scheduling question,
        e.g. using a token bucket scheme or a fixed non-work conserving
        scheduler. Therefore it would be nice to add one additional
        sentence in section 3.2 that spells that out directly. e.g.
        something like:
        

        

        „In order to protect non-DetNet traffic from potentially
        misbehaving DetNet-Traffic sources, rate limiting, e.g. using a
        token bucket scheme, at each tunnel ingress must be applied.“
        

      

      

      
I’m sure you can adapt the wording to make
        it more DetNet-like language and maybe you also want to add
        another sentence explaining the problem, please feel free to do
        so but that’s more or less what I’m looking for.
        

      

      

      I do agree that we seem to be having a terminology issue here -
      and that we are on the same page with what should happen.  The
      terminology I've used/seen in past RFCs has usually used the terms
      'shaping' and 'policing' - and these are what we've been using
      within the WG.  For example, both of these terms are used in
      RFC2475 but 'rate limiting' is not. Would it work for you for the
      draft to use/adapt the rest of your language, but keep 'by traffic
      policing functions (e.g., [RFC2475])' rather than 'rate limiting,
      e.g. using a token bucket scheme,' ?
      

    

    

    We could extend the 2nd paragraph in 3.2.1.1
    (https://tools.ietf.org/html/draft-ietf-detnet-architecture-11#section-3.2.1.1)
    to capture this comment:

    

    OLD:

                Ensuring adequate buffering requires, in turn, that the
    source, and every DetNet

                node along the path to the destination (or nearly every
    node, see

                <xref target="Incomplete"/>) be careful to
    regulate its output to not exceed the

                data rate for any DetNet flow, except for brief periods
    when making up for

                interfering traffic.  Any packet sent ahead of its time
    potentially adds to the

                number of buffers required by the next hop DetNet node
    and may thus exceed the resources

                allocated for a particular DetNet flow.

    

    NEW:

    

                Ensuring adequate buffering requires, in turn, that the
    source, and every DetNet

                node along the path to the destination (or nearly every
    node, see

                <xref target="Incomplete"/>) be careful to
    regulate its output to not exceed the

                data rate for any DetNet flow, except for brief periods
    when making up for

                interfering traffic.  Any packet sent ahead of its time
    potentially adds to the

                number of buffers required by the next hop DetNet node
    and may thus exceed the resources

                allocated for a particular DetNet flow. Furthermore,
    rate limiting, e.g., using traffic 

                policing and shaping functions, e.g., <xref
    target="RFC2475"/>, at the ingress of the 

                DetNet domain must be applied. This is needed for
    meeting the requirements of DetNet 

                flows as well as for protecting non-DetNet traffic from
    potentially misbehaving DetNet

                traffic sources.

    

    

    Furthermore, replace the two occurrences of "policing" with
    "policing and shaping":

    

    OLD:

       Starvation of non-DetNet traffic must be avoided, e.g., by
    traffic

       policing functions (e.g., [RFC2475]).  

    

    NEW:

       Starvation of non-DetNet traffic must be avoided, e.g., by
    traffic

       policing and shaping functions (e.g., [RFC2475]).  

    

    

    OLD:

       Examples of such techniques include traffic policing

       functions (e.g., [RFC2475]) and separating flows into per-flow
    rate-

       limited queues.

    

    NEW:

       Examples of such techniques include traffic policing and shaping

       functions (e.g., [RFC2475]) and separating flows into per-flow
    rate-

       limited queues.

    

    

      

      

      

        

        

          
One related comment on this sentence
            in Sec 3.1:
            

            

            "As DetNet provides allocated resources (including
            provisioned capacity)
            

                to DetNet flows the use of transport layer congestion
            control
            

                [RFC2914] by App-flows is explicitly not required."
            

            

            I guess congestion control should still be a requirement if
            the App-flow also
            

            passes not-DetNet-aware segments of the path, e.g. maybe the
            first hop.
            

          

          This point is addressed in section 3.3.2
          

          

             Note that the sending of App-flows that do not use
          transport layer
          

             congestion control per [RFC2914] into a network that is not
          

             provisioned to handle such DetNet traffic has to be treated
          as a
          

             fault and prevented.
          

          

          
Usually
            

            use of congestion control for application limited flows is
            also not a problem
            

            if sufficient bandwidth is available. Also note that, as I
            stated above, the
            

            important part for not requiring congestion control is
            actually not only that
            

            resources are allocated but also that rate limiting is in
            place to make sure
            

            resources usage cannot be exceeded above the reserved
            allocation. Maybe this
            

            sentence could also be further clarified in the draft...?
            

          

          Is the above sufficient?  If not, can you suggest some
          additional language?
          

        

        Maybe we can just extend the above statement a bit in order to
        be crystal clear about this, e.g.:
        

        

        "As DetNet flow are assumed to be rate-limited and DetNet is
        designed to provide sufficient allocated resources (including
        provisioned capacity), the use of transport layer congestion
        control [RFC2914] for end-to-end DetNet flows is not required,
        however, if resources are allocated appropriately, use of
        congestion control should not impact transmission negatively.“
        

      

      Great!  (I'll leave it to the authors to do the final wording
      adaptation)
      

    

    

    "App-flow" seems to be better than "end-to-end DetNet flow". The
    change with that would be:

    

    OLD:

       As

       DetNet provides allocated resources (including provisioned
    capacity)

       to DetNet flows the use of transport layer congestion control

       [RFC2914] by App-flows is explicitly not required.

    

    NEW:

                As 

                DetNet flows are assumed to be rate-limited and DetNet
    is designed

                to provide sufficient allocated resources (including
    provisioned

                capacity), the use of transport layer congestion control
    [RFC2914] 

                for App-flows is not required; however, if resources are
    allocated

                appropriately, use of congestion control should not
    impact

                transmission negatively.

    

    

      

        

        

          
And then one more small comment that
            is also related. Sec 3.2.2.2 says:
            

            

            "If packet replication and elimination is used over paths
            with
            

                resource allocation (Section 3.2.1), ..."
            

            

            My assumption was that all DetNet traffic is send over
            pre-allocated
            

            resources...? If that is not true that has implication on
            congestion control
            

            and needs some additional considerations. Can you please
            confirm that and maybe
            

            clarify in the draft! Thanks!
            

          

          The intent was to cover sending over non-pre-allocated paths
          as a fault case, and cover it in section 3.3.2.
          

        

        If that is the case, maybe we can just removed the half-sentence
        I cited above?
        

      

      

      WFM!
      

    

    

    The sentence after removing the text as you suggest:

    

    OLD:

       If packet replication and elimination is used over paths with

       resource allocation (Section 3.2.1), and member flows that take

       different-length paths through the network are combined, a merge

       point may require extra buffering to equalize the delays over the

       different paths.

    

    NEW:

       If member flows that take different-length paths through the 

       network are combined, a merge point may require extra buffering

       to equalize the delays over the different paths.

    

    

    Thank you!

    Janos

    

    

    

      

      Thank you!
      

      

      

        

        Thanks!
        

        Mirja
        

        

        
In addition to the previously quoted
          text, the section also says:
          

          

             PRF generated DetNet member flows also need to
          

             be treated as not using transport layer congestion control
          even if
          

             the original App-flow supports transport layer congestion
          control
          

             because PREOF can remove congestion indications at the PEF
          and
          

             thereby hide such indications (e.g., drops, ECN markings,
          increased
          

             latency) from end systems.
          

          

          Does this address your concern?
          

          
----------------------------------------------------------------------
            

            COMMENT:
            

----------------------------------------------------------------------
            

            

            I agree with Alexey and Benjamin that this document should
            be informational.
            

            Informational documents can also have IETF consensus, so
            that cannot be the
            

            reason to go for PS. However, this document does not specify
            a protocol or any
            

            requirements that are mandatory to implement for
            interoperability and therefore
            

            should not be PS.
            

            

          

          I defer to the IESG and AD on this...
          

          

          Thank you!
          

          

          Lou
          

          

          
_______________________________________________
            

            detnet mailing list
            

            detnet@ietf.org
            

            https://www.ietf.org/mailman/listinfo/detnet
            

          

          

        

        

      

    

    

  


--------------087B3AA5468A747AF71CABE8--


From nobody Tue Feb 26 05:20:53 2019
Return-Path: 
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 D05FE130F81 for ; Tue, 26 Feb 2019 05:20:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 tPaPEBaswYFy for ; Tue, 26 Feb 2019 05:20:44 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6A3E130F8A for ; Tue, 26 Feb 2019 05:20:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed;  q=dns/txt; i=@ericsson.com; t=1551187241; x=1553779241; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pyDypj+vzC+Ph7kkMuCsfQbhDHOrLBUxMSVZcAQXbNU=; b=HKBZ5ozzwM1ZNHkMwaMvrfMAonD20AiAKT2LjaH5uHbjhihC0v+HUENwJ0ZlTJbc 9gVVKU17fRkrLxIB5XZ1J9VshH8lZvwQ1S8mUI8Fj4m/rI96eVP7qDtZOWASAmuR tV56V8L4gQKfaZpPwemvBJbXo6PNl1ysONJsz6zXu3Y=;
X-AuditID: c1b4fb2d-2198b9e00000062f-2d-5c753d2916c2
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F2.4D.01583.92D357C5; Tue, 26 Feb 2019 14:20:41 +0100 (CET)
Received: from ESESSMR504.ericsson.se (153.88.183.126) by ESESSMB502.ericsson.se (153.88.183.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 26 Feb 2019 14:20:26 +0100
Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMR504.ericsson.se (153.88.183.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 26 Feb 2019 14:20:26 +0100
Received: from [131.160.183.210] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.190) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Tue, 26 Feb 2019 14:20:25 +0100
To: Alissa Cooper 
CC: Lou Berger , ,  , The IESG , 
References: <155067447797.31337.768983002923056061.idtracker@ietfa.amsl.com> <40b28261-5f04-7fcd-4f4f-ce243f32a808@labn.net> <1AA376D8-DE94-4FAF-B9D2-CC4E155CEC85@cooperw.in> 
From: =?UTF-8?Q?J=c3=a1nos_Farkas?= 
Message-ID: 
Date: Tue, 26 Feb 2019 14:20:25 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------13117617D61820C842D0F1E7"
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2J7ha6mbWmMwdxbphbTz/xltLjW/4PF 4ven2SwWH77NZLGY8Wcis0VH81sWBzaPL09eMnksWfKTyePDpma2AOYoLpuU1JzMstQifbsE royD61tYCzbMZqzYMekrYwNje04XIyeHhICJxKp5F1i6GLk4hASOMErc+3YKyvnGKDF76kx2 OGfCghOMEM4xRomF548yg/QLCxRI9F9YDmaLCKhKXD32gw2kiFlgKqPEg+77rCAJIYEnjBJX dkeB2GwC9hJ3L20Aa+AFsq++/A5Uw8HBAtR8d0cGSFhUIFbi05XFUCWCEidnPmEBsTkFbCR+ XH/LDmIzC4RJnFnxnA3CFpe49WQ+E8QqNYn3DXcYJzAKzULSPgtJyywkLbOANjMDXfFgaxlE WF6ieetsZghbX+L6nfusyOILGNlXMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgTG18Etv3V3 MK5+7XiIUYCDUYmHN1ejNEaINbGsuDL3EKMEB7OSCO8NVaAQb0piZVVqUX58UWlOavEhRmkO FiVx3j9CgjFCAumJJanZqakFqUUwWSYOTqkGxkDmy1o8pZyHEoQrjneUnpKVXMhs88ojaeqx czUrRVIfVG29sujPkoDfbOmdgocOnkrzbPu51yHp+61pjf3Xm1Lv9ezzexGwW6vouI/yVtUt 7d9SFvAsn2J+feMOoXmTJpiEJRtqsHzJ9kjv036r1Ovwdf9U+bmuSTwFhptM3R3uZMUdCb/g p8RSnJFoqMVcVJwIAJXdWAarAgAA
Archived-At: 
Subject: Re: [Detnet] Alissa Cooper's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Feb 2019 13:20:51 -0000

--------------13117617D61820C842D0F1E7
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit

Hi Alissa,

Thank you for your review!

We can replace
"DetNet is provides a Quality of Service (QoS), and as such, does not
  directly raise any new privacy considerations."
with
"DetNet provides a Quality of Service (QoS), and as such, is not expected to
  directly raise any new privacy considerations."

I'm not sure what "references to new flow IDs and OAM tags should be 
removed"?

Could you point to the text that should be changed?

Thank you!
Janos


On 2/20/2019 4:39 PM, Lou Berger wrote:
>
>
> On 2/20/2019 10:25 AM, Alissa Cooper wrote:
>>
>>
>>> On Feb 20, 2019, at 7:17 AM, Lou Berger >> > wrote:
>>>
>>> Hi Alissa,
>>>
>>> Thanks for the comments - see below.
>>>
>>> On 2/20/2019 9:54 AM, Alissa Cooper wrote:
>>>> Alissa Cooper has entered the following ballot position for
>>>> draft-ietf-detnet-architecture-11: 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:
>>>> https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> DISCUSS:
>>>> ----------------------------------------------------------------------
>>>>
>>>> = Section 6 =
>>>>
>>>> "DetNet is provides a Quality of Service (QoS), and as such, does not
>>>> directly raise any new privacy considerations."
>>>>
>>>> This seems like a false statement given the possibility that DetNet 
>>>> may require
>>>> novel flow IDs and OAM tags that create additional identification and
>>>> correlation risk beyond existing fields used to support QoS today.
>>>
>>> Based on the other work in the WG, I think "is not expected" is more 
>>> accurate than "does not". This is based on the WG solutions for the 
>>> DetNet data plane using existing IP (v4 or 6) headers or MPLS labels 
>>> for flow identification.
>>
>> If that is the case then the references to new flow IDs and OAM tags 
>> should be removed from the architecture.
>
> sounds reasonable. Can you point to the specific offending text?
>
> Thanks,
>
> Lou
>
>>
>>>
>>> Would changing to "is not expected" address your concern?
>>
>> Combined with the above removals, that would work for me.
>>
>> Thanks,
>> Alissa
>>
>>>
>>> Thanks,
>>>
>>> Lou
>>
>>
>> _______________________________________________
>> detnet mailing list
>> detnet@ietf.org
>> https://www.ietf.org/mailman/listinfo/detnet


--------------13117617D61820C842D0F1E7
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Alissa,

    

    Thank you for your review!

    

    We can replace 

    "DetNet is provides a Quality of Service (QoS), and as such, does
    not

     directly raise any new privacy considerations."

    with

    "DetNet provides a Quality of Service (QoS), and as such, is not
    expected to

     directly raise any new privacy considerations."

    

    I'm not sure what "references to new flow IDs and OAM tags should be
    removed"?

    

    Could you point to the text that should be changed?

    

    Thank you!

    Janos

    

    

    
On 2/20/2019 4:39 PM, Lou Berger wrote:

    

    

      
      


      

      
On 2/20/2019 10:25 AM, Alissa Cooper
        wrote:

      

      
 

        


          

            
On Feb 20, 2019, at 7:17 AM, Lou Berger <lberger@labn.net> wrote:

            

            
Hi Alissa,

              

              Thanks for the comments - see below.

              

              On 2/20/2019 9:54 AM, Alissa Cooper wrote:

              
Alissa Cooper has entered the following ballot
                position for

                draft-ietf-detnet-architecture-11: 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:

                https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/

                

                

                

----------------------------------------------------------------------

                DISCUSS:

----------------------------------------------------------------------

                

                = Section 6 =

                

                "DetNet is provides a Quality of Service (QoS), and as
                such, does not

                directly raise any new privacy considerations."

                

                This seems like a false statement given the possibility
                that DetNet may require

                novel flow IDs and OAM tags that create additional
                identification and

                correlation risk beyond existing fields used to support
                QoS today.

              

              

              Based on the other work in the WG, I think "is
                not expected" is more accurate than "does not". This is
                based on the WG solutions for the DetNet data plane
                using existing IP (v4 or 6) headers or MPLS labels for
                flow identification.

            

          

          


          

          
If that is the case then the references to new flow IDs
            and OAM tags should be removed from the architecture.

        

      

      
sounds reasonable. Can you point to the specific offending
        text?

      
Thanks,

      
Lou

      

      

        


          

            


              Would changing to "is not expected" address
                your concern?

            

          

          


          

          
Combined with the above removals, that would work for me.

          


          

          
Thanks,

          
Alissa

          

          

            


              Thanks,

              

              Lou

          

        

        

        

        

        
_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet


      

    

    

  


--------------13117617D61820C842D0F1E7--