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

[János Farkas <[e-mail]>]

Thank you Alvaro!
Janos


On 3/25/2019 7:37 PM, Alvaro Retana wrote:
> János:
>
> Hi!
>
> Yes…I’m happy with the changes.  I’m clearing my DISCUSS.
>
> Thanks!
>
> Alvaro.
>
> On March 25, 2019 at 5:20:37 PM, János Farkas 
> ([e-mail] <mailto:[e-mail]>) wrote:
>
>> Hi Alvaro,
>>
>> We believe that we have addressed your comments in the most recent 
>> revision: 
>> https://tools.ietf.org/html/draft-ietf-detnet-architecture-12. 
>> (https://mailarchive.ietf.org/arch/msg/detnet/utVL9ZVGcOeGtRIASRFx5WT_ErM)
>>
>> Please let us know what else you would like to see done before you 
>> clear your DISCUSS.
>>
>> I/we would be happy to meet with you this week if there is anything 
>> you would like to discuss.
>>
>> Regards,
>> Janos
>>
>>
>> On 3/6/2019 6:56 AM, János Farkas wrote:
>>> Hi Alvaro,
>>>
>>> Do the updates we are making the security section resolve your comments:
>>> https://mailarchive.ietf.org/arch/msg/detnet/btWvDFtp4F3JY2rY3wZEYdNn42o
>>>
>>> The current proposed text:
>>>
>>> 5.  Security Considerations
>>>
>>>    Security considerations for DetNet are described in detail in
>>>    [I-D.ietf-detnet-security].  This section considers exclusively
>>>    security considerations which are specific to the DetNet
>>>    Architecture.
>>>
>>>    Security aspects which are unique to DetNet are those whose aim is to
>>>    provide the specific quality of service aspects of DetNet, which are
>>>    primarily to deliver data flows with extremely low packet loss rates
>>>    and bounded end-to-end delivery latency.  A DetNet may be implemented
>>>    using MPLS and/or IP (including both v4 and v6) technologies, and
>>>    thus inherits the security properties of those technologies at both
>>>    the control plane and the data plane.
>>>
>>>    Security considerations for DetNet are constrained (compared to, for
>>>    example, the open Internet) because DetNet is defined to operate only
>>>    within a single administrative domain (see Section 1).  The primary
>>>    considerations are to secure the request and control of DetNet
>>>    resources, maintain confidentiality of data traversing the DetNet,
>>>    and provide the availability of the DetNet quality of service.
>>>
>>>    To secure the request and control of DetNet resources, authentication
>>>    and authorization can be used for each device connected to a DetNet
>>>    domain, most importantly to network controller devices.  Control of a
>>>    DetNet network may be centralized or distributed (within a single
>>>    administrative domain).  In the case of centralized control,
>>>    precedent for security considerations as defined for Abstraction and
>>>    Control of Traffic Engineered Networks (ACTN) can be found in
>>>    [RFC8453], Section 9.  In the case of a distributed control
>>>    protocols, DetNet security is expected to be provided by the security
>>>    properties of the protocols in use.  In any case, the result is that
>>>    manipulation of administratively configurable parameters is limited
>>>    to authorized entities.
>>>
>>>    To maintain confidentiality of data traversing the DetNet,
>>>    application flows can be protected through whatever means is provided
>>>    by the underlying technology.  For example, encryption may be used,
>>>    such as that provided by IPSec [RFC4301] for IP (Layer 3) flows and
>>>    by MACSec [IEEE802.1AE-2018] for Ethernet (Layer 2) flows.
>>>
>>>    DetNet flows are identified on a per-flow basis, which may provide
>>>    attackers with additional information about the data flows (when
>>>    compared to networks that do not include per-flow identification).
>>>    This is an inherent property of DetNet which has security
>>>    implications which should be considered when determining if DetNet is
>>>    a suitable technology for any given use case.
>>>
>>>    To provide uninterrupted availability of the DetNet quality of
>>>    service, provisions can be made against DOS attacks and delay
>>>    attacks.  To protect against DOS attacks, excess traffic due to
>>>    malicious or malfunctioning devices can be prevented or mitigated,
>>>    for example through the use of traffic admission control applied at
>>>    the input of a DetNet domain, as described in Section 3.2.1, and
>>>    through the fault mitigation methods described in Section 3.3.2.  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.
>>>
>>>    Because DetNet mechanisms or applications that rely on DetNet can
>>>    make heavy use of methods that require precise time synchronization,
>>>    the accuracy, availability, and integrity of time synchronization is
>>>    of critical importance.  Extensive discussion of this topic can be
>>>    found in [RFC7384].
>>>
>>>    DetNet use cases are known to have widely divergent security
>>>    requirements.  The intent of this section is to provide a baseline
>>>    for security considerations which are common to all DetNet designs
>>>    and implementations, without burdening individual designs with
>>>    specifics of security infrastructure which may not be germane to the
>>>    given use case.  Designers and Implementers of DetNet systems are
>>>    expected to take use case specific considerations into account in
>>>    their DetNet designs and implementations.
>>>
>>>
>>> Please let us know if you have any remaining comments and what they are.
>>>
>>> Thank you!
>>> Janos
>>>
>>>
>>> On 2/23/2019 9:39 PM, Lou Berger wrote:
>>>>
>>>> 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
>>>
>>