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

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

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
>