Subject: [Detnet] Alvaro Retana's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)

From: Alvaro Retana <[email-masked]>
Date: Wed, 20 Feb 2019 07:56:47 -0800

Alvaro Retana has entered the following ballot position for
draft-ietf-detnet-architecture-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-architecture/

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

I support Mirja's and Alissa's DISCUSSes...and have a related set of concerns
about the coexistence with non-DetNet traffic and privacy:

§3.3.1 talks about what I think is a hard to achieve balance between coexisting
with non-DetNet traffic and keeping that traffic from disrupting DetNet flows. 
Because of the constraints, the intent of prioritizing DetNet flows is clear
(and that is ok), but that may result in starvation of non-DetNet
traffic...even if the text does explicitly say that it "must be avoided".

I would like to see the potential case of starving non-DetNet traffic called
out somewhere.  I'm looking for something similar to the first paragraph in §5,
but focused on the non-DetNet traffic.

Related to the above is the fact that the identification of flows could be used
to specifically *not* include some of them as DetNet flows.  This is a
variation of the concern outlined in §6, but applied to non-DetNet flows, with
the potential starvation mentioned above.  Again, I would like to at least see
some discussion of this risk.

The use case and problem statement documents outline specific applications that
may not have non-DetNet traffic, and the Introduction supports that.  However,
the architecture described in this document may be used in more general
networks to provide guarantees to specific traffic...  IOW, even if the
intention is there, there is no guarantee that DetNet will only be used in the
expected use cases.

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

I agree with and support Benjamin's DISCUSS -- also, I think that
draft-ietf-detnet-security should be a Normative reference.

I also agree that Informational may be a better status.

[nit] s/sub-layer at which A DetNet service/sub-layer at which a DetNet service
[nit] Expand SRLG.

---

From: Lou Berger <[email-masked]>
Date: Wed, 20 Feb 2019 11:11:41 -0500

Hi Alissa,

Thanks for the comments - see below.

On 2/20/2019 10:56 AM, Alvaro Retana wrote:
> out somewhere.

This is the objective of section 3.3.1.

>   I'm looking for something similar to the first paragraph in §5,

The current text reads:

3.3.1.  Coexistence with normal traffic

    A DetNet network supports the dedication of a high proportion of the
    network bandwidth to DetNet flows.  But, no matter how much is
    dedicated for DetNet flows, it is a goal of DetNet to coexist with
    existing Class of Service schemes (e.g., DiffServ).  It is also
    important that non-DetNet traffic not disrupt the DetNet flow, of
    course (see Section 3.3.2 and Section 5).  For these reasons:

    o  Bandwidth (transmission opportunities) not utilized by a DetNet
       flow is available to non-DetNet packets (though not to other
       DetNet flows).

    o  DetNet flows can be shaped or scheduled, in order to ensure that
       the highest-priority non-DetNet packet is also ensured a worst-
       case latency.

    o  When transmission opportunities for DetNet flows are scheduled in
       detail, then the algorithm constructing the schedule should leave
       sufficient opportunities for non-DetNet packets to satisfy the
       needs of the users of the network.  Detailed scheduling can also
       permit the time-shared use of buffer resources by different DetNet
       flows.

    Starvation of non-DetNet traffic must be avoided, e.g., by traffic
    policing functions (e.g., [RFC2475]).  Thus, the net effect of the
    presence of DetNet flows in a network on the non-DetNet flows is
    primarily a reduction in the available bandwidth.

I think we need a little bit more to understand what you'd like to see changed or added.  Can you suggest text or what specific topic you'd like to see added/addressed?

> some discussion of this risk.

I don't follow - what is the risk that should be addressed?

> intention is there, there is no guarantee that DetNet will only be used in the

You're not requesting any change in the document here, right?

Thanks,

Lou

(as doc shepherd)

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 20 Feb 2019 13:24:28 -0500

On February 20, 2019 at 4:11:45 PM, Lou Berger ([email-masked]) wrote:

Hi Alissa,

…Alvaro… :-)

Hi!

The current text reads:

I think we need a little bit more to understand what you'd like to see
changed or added.  Can you suggest text or what specific topic you'd
like to see added/addressed?

Yes, let me try to explain better…while comparing with the current text in
§5, which basically says that even though the objective of DetNet is to
provide bounded latency, a MIIM may delay the traffic and the objective may
not be achieved.

For non-DetNet traffic, the objective is to not starve it, while providing
specific guarantees to the DetNet flows — said other way (from the
Introduction): "Unused reserved resources are available to non-DetNet
packets as long as all guarantees are fulfilled.”  However, the algorithms
(maybe error, misconfiguration…or even maliciously) may end up*not*
constructing the schedule to leave sufficient opportunities for non-DetNet
packets (as suggested in the text above from §3.3.1).

I see a parallel in how there is a risk of the intention for DetNet flows
not being met (because of an attack) and how the intention for non-DetNet
traffic may also not be met.

§6 talks about potential privacy concerns due to the identification of
flows.  I interpret that as potentially being able to identify the user
(application, or both maybe).

As far as I understand the architecture, DetNet flows are identified at the
edge and then assigned to specific paths.  If the identification of flows
can be used to identify the user (for example), then it can be used to not
only attack specific DetNet flow, but also to decide to not provide
guarantees to a specific flow based on who the user or the application may
be.

I’m trying to point at a scenario where the identification may lead to flag
a flow as non-DetNet — and then (back to the initial point) potentially
starve it: eliminating the ability of that user to communicate.

Right.  Just pointing out that not all deployments of DetNet may be in the
expected use cases, potentially exposing them to other risks, or other
applications.

Hope this makes more sense.

Thanks!

Alvaro.

---

From: Lou Berger <[email-masked]>
Date: Thu, 21 Feb 2019 14:35:30 -0500

On 2/20/2019 1:24 PM, Alvaro Retana wrote:
> On February 20, 2019 at 4:11:45 PM, Lou Berger ([email-masked] 
> <mailto:[email-masked]>) wrote:
>> Hi Alissa,
>
> …Alvaro… :-)
>
woops -- too many messages. ;-)

> Yes, let me try to explain better…while comparing with the current 
> text in §5, which basically says that even though the objective of 
> DetNet is to provide bounded latency, a MIIM may delay the traffic and 
> the objective may not be achieved.
>
> For non-DetNet traffic, the objective is to not starve it, while 
> providing specific guarantees to the DetNet flows — said other way 
> (from the Introduction): "Unused reserved resources are available to 
> non-DetNet packets as long as all guarantees are fulfilled.”  However, 
> the algorithms (maybe error, misconfiguration…or even maliciously) may 
> end up*not* constructing the schedule to leave sufficient 
> opportunities for non-DetNet packets (as suggested in the text above 
> from §3.3.1).
>
> I see a parallel in how there is a risk of the intention for DetNet 
> flows not being met (because of an attack) and how the intention for 
> non-DetNet traffic may also not be met.
>
Okay, this sounds like basically the same point that Benjamin was 
making, i.e., there must be mechanisms preventing non-detnet traffic 
from impacting detnet traffic, and detnet traffic trying to use more 
than its allocation and impacting non-detnet traffic. Is this correct or 
are you asking for something different/additional?

> flows.  I interpret that as potentially being able to identify the 
> user (application, or both maybe).
>
Currently flow identification is based on IP headers (6 tuple) and/or 
MPLS labels.  So DetNet has the same privacy concerns as standard IP/MPLS.

> As far as I understand the architecture, DetNet flows are identified 
> at the edge and then assigned to specific paths.  If the 
> identification of flows can be used to identify the user (for 
> example), then it can be used to not only attack specific DetNet flow, 
> but also to decide to not provide guarantees to a specific flow based 
> on who the user or the application may be.
>
Given DetNet flow identification, is this any different than standard PBR?

> I’m trying to point at a scenario where the identification may lead to 
> flag a flow as non-DetNet — and then (back to the initial point) 
> potentially starve it: eliminating the ability of that user to communicate
>
I do think this is possible, just like a policy based routing can be 
used to blackhole any IP traffic based on its IP headers.

> .
> Right.  Just pointing out that not all deployments of DetNet may be in 
> the expected use cases, potentially exposing them to other risks, or 
> other applications.
>
>
Okay.

Thanks,

Lou

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 22 Feb 2019 06:02:06 -0500

On February 21, 2019 at 7:35:32 PM, Lou Berger ([email-masked]) wrote:

Hi!

>> I think we need a little bit more to understand what you'd like to see
changed or added. Can you suggest text or what specific topic you'd like to
see added/addressed?

Yes.  I’m not asking so much for a mechanism, but for at least the
recognition that it is a risk.

Right, it is not really different.  It is just not mentioned anywhere that
identification (or misidentification as it may be, maybe maliciously) can
lead to not providing guarantees, potential starving, etc..

Thanks!

Alvaro.

---

From: Lou Berger <[email-masked]>
Date: Sat, 23 Feb 2019 15:39:12 -0500

Hi *Alvaro*,

see below.

On 2/22/2019 6:02 AM, Alvaro Retana wrote:
> On February 21, 2019 at 7:35:32 PM, Lou Berger ([email-masked] 
>> >> This is the objective of section 3.3.1..
>> >>
>> >>
>> >> I think we need a little bit more to understand what you'd like to 
>> see changed or added. Can you suggest text or what specific topic 
>> you'd like to see added/addressed?
>> >
Fair enough- I expect the response a response for the architecture and 
security draft authors to address this.  I'm sure you will confirm that 
it does!

> Right, it is not really different.  It is just not mentioned anywhere 
> that identification (or misidentification as it may be, maybe 
> maliciously) can lead to not providing guarantees, potential starving, 
> etc..
>
I thought the quotes capture in the various mails on the topic showed 
how it was -- but let's wait for the updated text and see if it 
sufficiently addresses your concern/point, and then go from there.

Thanks again for the feedback.

Lou

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