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

[Alvaro Retana <[e-mail]>]

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