Subject: [Detnet] Roman Danyliw's Discuss on draft-ietf-detnet-mpls-11: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 08 Sep 2020 11:10:55 -0700

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

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

** (Discuss-discuss) Section 6.  Per “To prevent DetNet packets from being
delayed by an entity external to a DetNet domain, DetNet technology definition
can allow for the mitigation of MiTM attacks, for example through the use of
authentication and authorization of devices within the DetNet domain”, can this
attack scenario or the appropriate mitigation be clarified.  If packets are
coming from or going across the DetNet boundary how can any assurances be made?
 What is architecture element is the “MiTM” (relay? transit? per Figure 2)?

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

** Section 4.2.2.  To confirm, if ACH and GAL are used instead of d-CW, then
only 16-bit sequence numbers are supported?

** Section 6.  Per “Achieving such loss rates and bounded latency may not be
possible in the face of a … Internet Thread Model BCP72”, I concur with this
analysis.  However, as the applicability statement of DetNet is not the
internet, but (I thought) enterprise IT and OT networks, it might worth
reiterating this reduced scope and framing this text around the attacker
capabilities.

** Section 6.  Per the reduced scope attacker being capable of “control[ing] a
network node within the boundary of the DetNet domain”, are these nodes in
question limited to end systems, or would they also include relay/transit nodes
(per Figure 2)?  If it is the latter, then these seem like they would have the
ability to arbitrarily drop or delay packets cross their paths just like a
BCP72 attacker, so why make the distinction?  If it is the former, then the
paragraph after this one suggesting IPSec and MacSec doesn’t seem to be
mitigating a threat posed by a compromised end system.

** Section 6.  Per “The primary consideration for DetNet data plane is to
maintain integrity … and delivery …”, this framing suggests that integrity and
availability are the key concerns.  However, the paragraph prior, seemed to
frame that only availability with the key issue.

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

** Editorial Nits:

Section 1.  Editorial.  s/different network technologies is/different network
technologies are/

Section 2.1.  Editorial.  S-Label definition.  Doesn’t “… that implement also
the DetNet service sub-layer functions” say the same things as “An S-Label is
also used to identify a DetNet flow at DetNet service sub-layer …”?  I’m not
sure you need the “… that implement [sic] also the DetNet …” phrase at the end
of the first sentence.

Section 4.1.  Editorial.  This section opens with a list of 6 requirements. 
The paragraphs below this list begin explaining how these requirements are met.
 It was helpful that the text explicitly called out how “(1) and (2) in the
list above” were satisfied.  This convention was not followed for items 3 – 6.

Section 4.2.1.  Editorial.  Explain “S/N” (Sequence Number) on first use.

Section 4.3.  Editorial.  s/0X1/0x1/

Section 4.4.  s/this documents/this document/

Section 5.2.  Typo.  s/paramters/parameters/

Section 6.  Typo. s/the the/the/

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 8 Sep 2020 19:26:17 +0100

> On 8 Sep 2020, at 19:10, Roman Danyliw via Datatracker <[email-masked]> wrote:
> 

Remember no packet gets into an MPLS LSP unless specifically put there by a PE (this is fundamental MPLS).

So the requirement on the PE is that it only allows permitted packets to enter the LSP but this is always a requirement placed on a PE.

- Stewart

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 8 Sep 2020 19:20:14 +0000

Hi Stewart!

Thanks for clarifying, especially since I see the same language is in draft-ietf-detnet-ip-over-mpls.

Let me test my understanding using MPLS specific language.  Are you roughly saying:

OLD
To prevent DetNet packets
   from being delayed by an entity external to a DetNet domain, DetNet
   technology definition can allow for the mitigation of Man-In-The-
   Middle attacks, for example through use of authentication and
   authorization of devices within the DetNet domain.

NEW

To prevent the DetNet packets from being delayed by the volume of traffic from external entities using the same MPLS infrastructure, PEs implementing the DetNet architecture could only allow packets to enter the LSP from appropriately authenticated and authorized devices.

Roman

From: Stewart Bryant <[email-masked]>
Sent: Tuesday, September 8, 2020 2:26 PM
To: Roman Danyliw <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; The IESG <[email-masked]>; [email-masked]; DetNet Chairs <[email-masked]>; DetNet WG <[email-masked]>; Ethan Grossman <[email-masked]>
Subject: Re: Roman Danyliw's Discuss on draft-ietf-detnet-mpls-11: (with DISCUSS and COMMENT)

On 8 Sep 2020, at 19:10, Roman Danyliw via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:

- Stewart

---

From: Balázs Varga A <[email-masked]>
Date: Wed, 9 Sep 2020 15:13:30 +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: Tuesday, September 8, 2020 8:11 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Ethan Grossman <[email-masked]>; [email-masked]
Subject: Roman Danyliw's Discuss on draft-ietf-detnet-mpls-11: (with DISCUSS and 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.)

DISCUSS:

** (Discuss-discuss) Section 6.  Per “To prevent DetNet packets from being delayed by an entity external to a DetNet domain, DetNet technology definition can allow for the mitigation of MiTM attacks, for example through the use of authentication and authorization of devices within the DetNet domain”, can this attack scenario or the appropriate mitigation be clarified.  If packets are coming from or going across the DetNet boundary how can any assurances be made?

<Bala'zs> See, Stewarts reaction.

COMMENT:

** Section 4.2.2.  To confirm, if ACH and GAL are used instead of d-CW, then only 16-bit sequence numbers are supported?

<Bala'zs> OAM is covered in https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-oam/.

** Section 6.  Per “Achieving such loss rates and bounded latency may not be possible in the face of a … Internet Thread Model BCP72”, I concur with this analysis.  However, as the applicability statement of DetNet is not the internet, but (I thought) enterprise IT and OT networks, it might worth reiterating this reduced scope and framing this text around the attacker capabilities.

<Bala'zs> OK. Do You have a proposed text?

** Section 6.  Per the reduced scope attacker being capable of “control[ing] a network node within the boundary of the DetNet domain”, are these nodes in question limited to end systems, or would they also include relay/transit nodes (per Figure 2)?  If it is the latter, then these seem like they would have the ability to arbitrarily drop or delay packets cross their paths just like a

BCP72 attacker, so why make the distinction?  If it is the former, then the paragraph after this one suggesting IPSec and MacSec doesn’t seem to be mitigating a threat posed by a compromised end system.

<Bala'zs> It depends on the network scenario, whether the end host is MPLS capable and it is part of the DetNet network. So both applies.

** Section 6.  Per “The primary consideration for DetNet data plane is to maintain integrity … and delivery …”, this framing suggests that integrity and availability are the key concerns.  However, the paragraph prior, seemed to frame that only availability with the key issue.

<Bala'zs> Right. Integrity is a consideration like other flows, they are not DetNet specific. I will fix this sentence.

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

** Editorial Nits:

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

Section 1.  Editorial.  s/different network technologies is/different network technologies are/

Section 2.1.  Editorial.  S-Label definition.  Doesn’t “… that implement also the DetNet service sub-layer functions” say the same things as “An S-Label is also used to identify a DetNet flow at DetNet service sub-layer …”?  I’m not sure you need the “… that implement [sic] also the DetNet …” phrase at the end of the first sentence.

It was helpful that the text explicitly called out how “(1) and (2) in the list above” were satisfied.  This convention was not followed for items 3 – 6.