Re: [secdir] secdir review of draft-ietf-detnet-architecture-08
János Farkas <janos.farkas@ericsson.com> Wed, 06 February 2019 22:18 UTC
Return-Path: <Janos.Farkas@ericsson.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3027D130F3E for <secdir@ietfa.amsl.com>; Wed, 6 Feb 2019 14:18:05 -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 akW9A6ySQNCr for <secdir@ietfa.amsl.com>; Wed, 6 Feb 2019 14:18:02 -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 5EDC2130F72 for <secdir@ietf.org>; Wed, 6 Feb 2019 14:18:00 -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: János Farkas <janos.farkas@ericsson.com>
To: Daniel Harkins <dharkins@lounge.org>
CC: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, DetNet WG <detnet@ietf.org>
References: <c5b35342-1136-8af2-d0a8-d66603c6e124@ericsson.com> <df8412e9-a2fc-3953-7dc6-5ca48f363b8f@ericsson.com>
Message-ID: <50d31dc2-1f3f-21aa-2e2b-5432816e1425@ericsson.com>
Date: Wed, 06 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: <df8412e9-a2fc-3953-7dc6-5ca48f363b8f@ericsson.com>
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: <https://mailarchive.ietf.org/arch/msg/secdir/9U9rXtFij3f-qUj1SOb2tULo4VY>
Subject: Re: [secdir] secdir review of draft-ietf-detnet-architecture-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Feb 2019 22:18:08 -0000
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.
- [secdir] secdir review of draft-ietf-detnet-archi… Daniel Harkins
- Re: [secdir] secdir review of draft-ietf-detnet-a… Grossman, Ethan A.
- Re: [secdir] secdir review of draft-ietf-detnet-a… János Farkas
- Re: [secdir] secdir review of draft-ietf-detnet-a… János Farkas