Re: [Detnet] Éric Vyncke's No Objection on draft-ietf-detnet-security-13: (with COMMENT)

Ethan Grossman <ethan@ieee.org> Sat, 09 January 2021 00:13 UTC

Return-Path: <ethan@ieee.org>
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 BFF843A13E9 for <detnet@ietfa.amsl.com>; Fri, 8 Jan 2021 16:13:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=ieee.org
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 fBuPFWLRg_xK for <detnet@ietfa.amsl.com>; Fri, 8 Jan 2021 16:13:07 -0800 (PST)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 B29E43A13EE for <detnet@ietf.org>; Fri, 8 Jan 2021 16:13:07 -0800 (PST)
Received: by mail-pg1-x52f.google.com with SMTP id g15so8645823pgu.9 for <detnet@ietf.org>; Fri, 08 Jan 2021 16:13:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=reply-to:from:to:cc:references:in-reply-to:subject:date :organization:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=48HiR8JrIEkg7eaLwOwU8ft1h1F7pe4b5Xreku6vZpI=; b=KQriGXMGBWvaSdR2m2s18eRvYdXjc3sR4QdtwoY3ZOxGAuE53fQLwNqBjbsFWpwdqV tdGTCKELhRtVj5YIJFxfR7/gvpljFUEl2D6vaxXfFfsSHJPfOt/oKfDOY73v8uD3UuMF kVvl+TUaYhKtm1jObY8yxUTI2hOb+Q1ZXAJlA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:from:to:cc:references:in-reply-to :subject:date:organization:message-id:mime-version :content-transfer-encoding:content-language:thread-index; bh=48HiR8JrIEkg7eaLwOwU8ft1h1F7pe4b5Xreku6vZpI=; b=dYJzlnjL7LUjmYrf2uF4HZle/iopRc7j3FQGzJnFbSIsPRh9YjYWj4MAD8akunK0fH PYIG2Ekcp+jNqkR4oBdxLDaxlMQp7/19zurjXYrHttiEhjYZP4bZTlzp89E7VcsK9woZ rJ57wo1y4XQ4NFi+e522GjWCGkPlUuAisTD0NukynlIgqa+jeLFm5zFo61gpYAnnuOZI kGlV/aO7Rh9N8NMqQfii6gxakak4kheJmshJSY2xw4/tfbLavOzsf2R1QrV1YdmBUvVn 7/qmbeEqY7Z18OyY/vPrFdBoWOVJ5pCR8RlmpVoSxq8xSeaHDmtR2MzLlH2AxnmevC/q aIzg==
X-Gm-Message-State: AOAM532jJrfrJ1d5cuk5GhVJuqk+pMmAi/qG1Pqa7DePzGbFmCevDfla TjeC732Fl6GYoS2/lxHDQNR4NkB44PDb8EhW
X-Google-Smtp-Source: ABdhPJw4IU94pMcCcDKLzyu+51469tU24ANjbNjjavm3IBlqNUEkCLvTxq3dASUgr0E6N0cd7Wm1XQ==
X-Received: by 2002:a63:987:: with SMTP id 129mr9415960pgj.251.1610151186669; Fri, 08 Jan 2021 16:13:06 -0800 (PST)
Received: from DESKTOPC435DDQ (99-46-181-151.lightspeed.sntcca.sbcglobal.net. [99.46.181.151]) by smtp.gmail.com with ESMTPSA id 14sm9296395pjm.21.2021.01.08.16.13.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jan 2021 16:13:05 -0800 (PST)
Reply-To: <ethan@ieee.org>
From: "Ethan Grossman" <ethan@ieee.org>
To: =?utf-8?Q?'=C3=89ric_Vyncke'?= <evyncke@cisco.com>, "'The IESG'" <iesg@ietf.org>
Cc: <draft-ietf-detnet-security@ietf.org>, <detnet-chairs@ietf.org>, <detnet@ietf.org>, "'Lou Berger'" <lberger@labn.net>
References: <161002772940.25870.1767345558793174192@ietfa.amsl.com>
In-Reply-To: <161002772940.25870.1767345558793174192@ietfa.amsl.com>
Date: Fri, 8 Jan 2021 16:13:03 -0800
Organization: Coast Computer Design
Message-ID: <0ec201d6e61c$3395dae0$9ac190a0$@ieee.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQHRtcA+usibAoy0JnCQdhpv+CFigaooxdAg
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/BEuq6u5VjTxWKv9dOdZwDfyjDkM>
Subject: Re: [Detnet] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-detnet-security-13=3A_=28with_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 <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Jan 2021 00:13:10 -0000

Hello Éric,
Thank you for your review. In summary I agree with all of your points and will incorporate them into the next draft revision. I put my responses to your individual comments below inline (marked EAG). If you have any further comments or questions, please don't hesitate to reply.  
Sincerely,
Ethan (as Editor, DetNet Security draft)

-----Original Message-----
From: Éric Vyncke via Datatracker <noreply@ietf.org> 
Sent: Thursday, January 7, 2021 5:55 AM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-detnet-security@ietf.org; detnet-chairs@ietf.org; detnet@ietf.org; Lou Berger <lberger@labn.net>et>; lberger@labn.net
Subject: Éric Vyncke's No Objection on draft-ietf-detnet-security-13: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-detnet-security-13: 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-security/



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

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

Let's also try to address the COMMENT for section 4.

I hope that this helps to improve the document,
EAG: Yes, thank you!

Regards,

-éric

== COMMENTS ==

-- Section 1 --
In "best practices for security at both the data plane and controller plane", is there a reason why the management/telemetry plane(s) is not included? Of course, most of the time this plane is isolated from the others but anyway...
Also, is is "controller plane" or "control plane" ? or is the 'controller plane' the plane connecting PCC to PCE ? (with an assumption that the ID is also relying on PCC/PCE ?).

EAG: The DetNet Controller Plane is explicitly defined in the DetNet Architecture [ref RFC8655] (to which the reader is referred in the Introduction section) as "the aggregation of the Control and Management Planes". 


Section 8.3 (OAM) is welcome but why not already including OAM in the above sentence ?

EAG: OK, I will add it. 

-- Section 5.2.3 & 6.3.1 --
May I assume that any layer-1 'jamming' (e.g., microwave link) is also covered by this section ? If so, then I suggest to state it.

EAG: OK, as I understand it, "jamming" implies interfering with the reception of the radio signal, as opposed to introducing packets into the network via the radio link. So, I can add on the example of jamming a microwave link to the sentence starting with " If a DetNet flow is interrupted...".  Given that definition, I don't see anything to add to 5.2.3 - if you have a suggestion, please let me know. 

-- Section 3.3 --
"(Note that PREOF is not defined for a DetNet IP data plane)." will this note be applicable forever ? Should the word 'currently' be used in this statement?
I also do not see the point of using parenthesis. I prefer the wording used in section 7.1 "At the time of this writing, PREOF is not defined for the IP data plane."

EAG: Agree. 

-- Section 3.4 --
Probably due to my ignorance about DetNet, but, I fail to understand why "having the network shut down a link if a packet arrives outside of its prescribed time window" and the rest of the section. Again, probably due to my lack of context but you may want to explain the reasoning behind.

EAG: Agree - the intent is to "do the appropriate thing", as opposed to giving a simplistic example action like that. I will revise. 

-- Section 4 --
There is no 'TOS' field in the IPv6 header, it is replaced by 'Traffic Class'.
So, please mention both of the fields.

EAG: Understood, will do. 

-- Section 6 --
On figure 2, there are mentions of blockchain and network slicing without any previous explanations (and I have hard time to see how blockchain traffic should be detnet).

EAG: OK, and Alissa agrees with you on that, so out they go. 

-- Section 8.3 --
This section seems to consider only OAM traffic added to the DetNet traffic while there are a couple of in-band OAM techniques currently being specified at the IETF.

EAG: Our stance on OAM is that it is indistinguishable from any other DetNet traffic, and thus there isn't anything unique to DetNet about security practices for OAM. So, we mention it only to that extent. 

-- Section 9 --
If the IPsec sessions are established by a controller, then this controller could also send the Security Parameter Index (SPI) that is transmitted in the clear and use this SPI to in addition to the pair of IP addresses.

EAG: Good point - I will mention that. 

== NITS ==
EAG: OK, accept all nits. 


-- Section 1 --
s/A DetNet is one that/A DetNet is a network that/

-- Section 8.2 --
s/Figure 5maps/Figure 5 maps/

-- Authors --
The URL for http://www.mistiqtech.com does not work for me