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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Thu, 07 Jan 2021 05:55:29 -0800

É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,

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 ?).

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

-- 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.

-- 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."

-- 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.

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

-- 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).

-- 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.

-- 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.

== 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

---

From: "Ethan Grossman" <[email-masked]>
Date: Fri, 8 Jan 2021 16:13:03 -0800

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 <[email-masked]> 
Sent: Thursday, January 7, 2021 5:55 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Lou Berger <[email-masked]>; [email-masked]
Subject: Éric Vyncke's No Objection on draft-ietf-detnet-security-13: (with COMMENT)

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 find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

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 --

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 --

-- Section 8.2 --

-- Authors --