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

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

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