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

[Lou Berger <[e-mail]>]

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


> Hi!
>
>
>>> ----------------------------------------------------------------------
>>> 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.
>>
>> This is the objective of section 3.3.1.
>>
>>
>>> I'm looking for something similar to the first paragraph in §5,
>>> but focused on the non-DetNet traffic.
>>
>> 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?
>
> 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?


>
>>> 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.
>>
>> I don't follow - what is the risk that should be addressed?
>>
> §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).
>
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.


> .
>
>>> 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.
>>
>> You're not requesting any change in the document here, right?
>>
> 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


> Hope this makes more sense.
>
> Thanks!
>
> Alvaro.
>