Subject: Re: [Last-Call] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-over-udp-ip-06

From: Balázs Varga A <[email-masked]>
Date: Thu, 1 Oct 2020 15:05:06 +0000

Hi Stephen / Ethan,

Many thanks for the review. 
Draft-ietf-detnet-mpls-over-udp-ip focuses on the scenario where two DetNet
MPLS nodes are interconnected via an IP sub-network and covers data plane
aspects. Security aspects of DetNet are covered in DetNet Security draft. 

DetNet flows are identified using a "6-tuple", what includes UDP, TCP, etc.
In my view using UDP/IP encapsulation between DetNet nodes - covered in
draft-ietf-detnet-mpls-over-udp-ip - is a subset of the general DetNet IP 
flow case, where the 6-tuple is used for DetNet flow identification. So, 
no extra security scenario here.

Thanks & Cheers
Bala'zs

-----Original Message-----
From: Grossman, Ethan A. <[email-masked]> 
Sent: Thursday, September 24, 2020 10:28 PM
To: Stephen Farrell <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Detnet] Secdir last call review of draft-ietf-detnet-mpls-over-udp-ip-06

Thanks Stephen. FWIW it isn't too late to add some text to the DetNet Security draft regarding DetNet over UDP, if someone can think up something useful to say. I suppose one could simply mention UDP in the same breath as TCP (implying that the same general security guidelines apply, if that's our stance). 
Any thoughts (from anyone)? 
Thanks,
Ethan (as Editor, DetNet Security draft)

-----Original Message-----
From: detnet <[email-masked]> On Behalf Of Stephen Farrell via Datatracker
Sent: Thursday, September 24, 2020 11:15 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Detnet] Secdir last call review of draft-ietf-detnet-mpls-over-udp-ip-06

Reviewer: Stephen Farrell
Review result: Ready

(Sorry for the missed review deadline.)

Other than general doubts about "I'll only use this in one administrative domain", the only specific thing that concerned me here was that draft-ietf-detnet-security doesn't seem to include any analysis of detnet/UDP (and indeed says that detnet runs over IP) and the security considerations section here is purely by reference. Given that draft-ietf-detnet-security seems to have done a reasonable job of analysis, it's a pity to not have that for the detnet/UDP case. All that said, I don't have any concrete problems to highlight with detnet/UDP, though of course I've not been thinking about this as $dayjob, so there may be issues there.

_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 1 Oct 2020 16:12:29 +0100

> On 24 Sep 2020, at 21:28, Grossman, Ethan A. <[email-masked]> wrote:
> 

Ethan

I would be rather surprised if anyone tried to run a deterministic application over TCP.

TCP would undo all the temporal determinism and or course it looks after packet loss.

- Stewart

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Thu, 1 Oct 2020 17:43:54 +0000

Yeah the thought occurred to me "why would we mention anything above IP at all?" I checked the Security draft and there is actually no relevant mention of TCP or UDP. So I think this is a no-op as far as the Security draft is concerned. Of course I could be missing something, so please correct me if necessary, but that's my current understanding. 
Ethan.

-----Original Message-----
From: Stewart Bryant <[email-masked]> 
Sent: Thursday, October 1, 2020 8:12 AM
To: Grossman, Ethan A. <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; Stephen Farrell <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Detnet] Secdir last call review of draft-ietf-detnet-mpls-over-udp-ip-06

Ethan

- Stewart

---

From: "Black, David" <[email-masked]>
Date: Thu, 1 Oct 2020 19:35:36 +0000

Playing devil's advocate for a moment ...

> TCP would undo all the temporal determinism and or course it looks after packet

... IF the DetNet service defines packet loss as a failure case, i.e., something that can't happen unless something in the network has actually failed and the preferred failure behavior is late delivery rather than non-delivery of impacted data, THEN TCP may be useful/appropriate.  OTOH, use of TCP increases the DetNet attack surface, as (in contrast to UDP), causing a drop or otherwise triggering retransmission becomes a way to attack the DetNet service by increasing the amount of traffic sent into limited reserved network capacity and also by delaying delivery of received data to the deterministic application.

I've lost track of the original context, so I'm not able to suggest specific text and where to add it or make changes.

Thanks, --David

> From: detnet <[email-masked]> On Behalf Of Stewart Bryant
> Sent: Thursday, October 1, 2020 11:12 AM
> To: Grossman, Ethan A.
> Cc: [email-masked]; [email-masked]; Stewart Bryant; [email-masked]; draft-
> [email-masked]; Stephen Farrell
> [EXTERNAL EMAIL]
> > Thanks Stephen. FWIW it isn't too late to add some text to the DetNet Security
> draft regarding DetNet over UDP, if someone can think up something useful to
> say. I suppose one could simply mention UDP in the same breath as TCP (implying
> that the same general security guidelines apply, if that's our stance).

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 2 Oct 2020 13:20:51 +0100

David

The way that I look at it, TCP will deliver a given byte fed into its transmission stream in its own good time, delaying that byte until all previous bytes are delivered. It will also keep trying to deliver that byte as long as there is connectivity between source and sink. That is a contrast with DetNet which is looking for fast delivery with possibly some mitigation for packet loss. In such circumstances TCP is a liability to the service that wanted deterministic characteristics. I cannot therefore think of any good reason to pay the price of DetNet to deliver TCP. If you do want to use a transport protocol that is more sophisticated than UDP, then SCTP-PR is probably a better choice.

- Stewart

> On 1 Oct 2020, at 20:35, Black, David <[email-masked]> wrote:
>

---

From: "Black, David" <[email-masked]>
Date: Fri, 2 Oct 2020 15:40:31 +0000

Stewart,

Going back to my earlier note to identify the design choice:

> > ... IF the DetNet service defines packet loss as a failure case, i.e., something
> > that can't happen unless something in the network has actually failed and the
> > preferred failure behavior is late delivery rather than non-delivery of impacted
> > data, THEN TCP may be useful/appropriate.  

I read your note as advocating that the preferred failure behavior is non-delivery of impacted data, in which case, I would agree that TCP is not a good choice of protocol.

Thanks, --David

> Sent: Friday, October 2, 2020 8:21 AM
> To: Black, David
> Cc: Stewart Bryant; Grossman, Ethan A.; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Stephen
> Farrell
> The way that I look at it, TCP will deliver a given byte fed into its transmission
> stream in its own good time, delaying that byte until all previous bytes are
> delivered. It will also keep trying to deliver that byte as long as there is
> connectivity between source and sink. That is a contrast with DetNet which is
> looking for fast delivery with possibly some mitigation for packet loss. In such
> circumstances TCP is a liability to the service that wanted deterministic
> characteristics. I cannot therefore think of any good reason to pay the price of
> DetNet to deliver TCP. If you do want to use a transport protocol that is more
> sophisticated than UDP, then SCTP-PR is probably a better choice.
> 
> - Stewart
> 
> 
> 
> > ... IF the DetNet service defines packet loss as a failure case, i.e., something
> that can't happen unless something in the network has actually failed and the
> preferred failure behavior is late delivery rather than non-delivery of impacted
> data, THEN TCP may be useful/appropriate.  OTOH, use of TCP increases the
> DetNet attack surface, as (in contrast to UDP), causing a drop or otherwise
> triggering retransmission becomes a way to attack the DetNet service by
> increasing the amount of traffic sent into limited reserved network capacity and
> also by delaying delivery of received data to the deterministic application.
> >
> >> Cc: [email-masked]; [email-masked]; Stewart Bryant;
> >> [email-masked]; draft- [email-masked];
> >> Stephen Farrell
> >> Subject: Re: [Detnet] Secdir last call review of
> >> draft-ietf-detnet-mpls-over-udp-
> >> ip-06
> >>
> >>
> >> [EXTERNAL EMAIL]
> >>
> >>
> >>
> >> draft regarding DetNet over UDP, if someone can think up something
> >> useful to say. I suppose one could simply mention UDP in the same
> >> breath as TCP (implying that the same general security guidelines apply, if
> that's our stance).