Subject: [Detnet] Roman Danyliw's No Objection on draft-ietf-detnet-ip-over-mpls-07: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 09 Sep 2020 08:15:36 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-detnet-ip-over-mpls-07: 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-ip-over-mpls/

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

(Identical comments as draft-ietf-detnet-mpls – if needed, we can chat about
them only once)

** Section 6.  Per “Application flows can be protected through whatever means
are provided by the underlying technology”, what is the scope of “underlying
technology”, is that an application concern?  Or a DetNet data or control plan
concern?  The text isn’t clear on who’s responsibility it is to provide these
services (IPSec or MacSec), or what assumptions the application can make?  IMO,
the clearer statement to make is that MPLS doesn’t provide any native security
services to account for confidentiality and integrity.

** Section 6.  Per “From a data plane perspective this document does not add or
modify any header information.”, to be clear, does this text mean
“_application_ header information”?  I’d recommend being clear.

** Section 6. Please s/for the mitigation of Man-In-The-Middle attackers/for
the mitigation of on-path attackers/

** Note the DISCUSS for draft-ietf-detnet-mpls.  Whatever the resolution on
that text would apply here too.  Due to the overlap in authors on both
documents, I’m adding the marker for that feedback here as a comment.

---

From: Balázs Varga A <[email-masked]>
Date: Wed, 9 Sep 2020 17:21:32 +0000

Hi Roman,
Many thanks for the review. My comments/replies inline.
Thanks & Cheers 
Bala'zs

-----Original Message-----
From: Roman Danyliw via Datatracker <[email-masked]> 
Sent: Wednesday, September 9, 2020 5:16 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Ethan Grossman <[email-masked]>; [email-masked]
Subject: Roman Danyliw's No Objection on draft-ietf-detnet-ip-over-mpls-07: (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.)

(Identical comments as draft-ietf-detnet-mpls – if needed, we can chat about them only once)

** Section 6.  Per “Application flows can be protected through whatever means are provided by the underlying technology”, what is the scope of “underlying technology”, is that an application concern?  Or a DetNet data or control plan concern?  The text isn’t clear on who’s responsibility it is to provide these services (IPSec or MacSec), or what assumptions the application can make?  IMO, the clearer statement to make is that MPLS doesn’t provide any native security services to account for confidentiality and integrity.

<Bala'zs> Right. I will fix this sentence with your suggested clearer statement.

** Section 6.  Per “From a data plane perspective this document does not add or modify any header information.”, to be clear, does this text mean “_application_ header information”?  I’d recommend being clear.

<Bala'zs> Thanks, I will fix this.

** Section 6. Please s/for the mitigation of Man-In-The-Middle attackers/for the mitigation of on-path attackers/

<Bala'zs> Thanks, I will fix this.

** Note the DISCUSS for draft-ietf-detnet-mpls.  Whatever the resolution on that text would apply here too.  Due to the overlap in authors on both documents, I’m adding the marker for that feedback here as a comment.

<Bala'zs> OK.