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

[Lou Berger <[e-mail]>]

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 ([e-mail] 
> <mailto:[e-mail]>) wrote:
>
> 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?
>
> Yes.  I’m not asking so much for a mechanism, but for at least the 
> recognition that it is a risk.
>
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!


>>
>>
>>
>> >
>> >>> 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?
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet