Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-security-13: (with DISCUSS and COMMENT)

[Ethan Grossman <[e-mail]>]

Hello Magnus,
Thank you again for your considered review, and this follow-up. I have refactored section 3.1 as shown below, in order to incorporate your thoughts. Please let us know what you think - I am committed to making this draft meet or exceed your standards, and I do appreciate your direction. 
Sincerely,
Ethan. 
-----------REV2 START--------------------------------
REV1 (the new OLD, i.e. yesterday's revision :- )  
3.1.  Resource Allocation

A DetNet system security designer relies on the premise that any resources allocated to a resource-reserved (OT-type) flow are inviolable; in other words there is no physical possibility within a DetNet component that resources allocated to a given flow can be compromised by any type of traffic in the network; this includes malicious traffic as well as inadvertent traffic such as might be produced by a malfunctioning component, or due to interactions between components that were not sufficiently tested for interoperability. From a security standpoint, this is a critical assumption, for example when designing against DOS attacks.  
It is the responsibility of the component designer to ensure that this condition is met; this implies protection against excess traffic from adjacent flows, and against compromises to the resource allocation/deallocation process, for example through the use of traffic shaping and policing.
However, this assumption on the part of the DetNet system designer must be tempered by the fact that any given component is designed for some set of use cases and accordingly will have certain limitations on its security properties and vulnerabilities. For example, due to cost and complexity factors, the security properties of a component designed for low-cost systems may be quite different from a component with similar intended functionality, but designed for highly secure or otherwise critical applications, perhaps at substantially higher cost. Thus, a significant responsibility of the designer of any component intended for use with DetNet is that they clearly document the security properties of the component. For example, to address the case where a corrupted packet in which the flow identification information is compromised and thus may incidentally match the flow ID of another (“victim”) DetNet flow, resulting in additional unauthorized traffic on the victim, the documentation might state that the component employs integrity protection on the flow identification fields. 
Even in the case that the security properties of the component as designed are well specified and understood, if the component malfunctions, for example due to physical circumstances unpredicted by the component designer, it may be difficult or impossible to fully prevent malfunction of the network. However, all networks are subject to this level of uncertainty; it is not unique to DetNet. Having said that, DetNet raises the bar by changing many added latency scenarios from tolerable annoyances to unacceptable service violations.   That in turn underscores the importance of system integrity, as well as correct and stable configuration of the network and its nodes, as discussed in [reference to Introduction section].  
. . .
END

REV2: (Second Revision 7Jan21)
3.1.  Resource Allocation

3.1.1 Inviolable Flows

A DetNet system security designer relies on the premise that any resources allocated to a resource-reserved (OT-type) flow are inviolable; in other words there is no physical possibility within a DetNet component that resources allocated to a given DetNet flow can be compromised by any type of traffic in the network; this includes malicious traffic as well as inadvertent traffic such as might be produced by a malfunctioning component, or due to interactions between components that were not sufficiently tested for interoperability. From a security standpoint this is a critical assumption, for example when designing against DOS attacks. In other words, with correctly designed components and security mechanisms, one can prevent malicious activities from impacting other resources.

However, achieving the goal of absolutely inviolable flows may not be technically or economically feasible for any given use case, given the broad range of possible use cases (e.g. [reference to DetNet Use Cases RFC8578]) and their associated security considerations as outlined in this document. It can be viewed as a continuum of security requirements, from isolated ultra-low latency systems that may have little security vulnerability (such as an industrial machine) to broadly distributed systems with many possible attack vectors and OT security concerns (such as a utility network). Given this continuum, the design principle employed in this document is to specify the desired end results, without being overly prescriptive in how the results are achieved, reflecting the understanding that no individual implementation is likely to be appropriate for every DetNet use case. 

3.1.2 Design Trade-Off Considerations in the Use Cases Continuum

It is important for the DetNet system designer to understand, for any given DetNet use case and its associated security requirements, the interaction and design trade-offs that inevitably need to be reconciled between the desired end results and the DetNet protocols, as well as the DetNet system and component design. 
For any given component, as designed for any given use case (or scope of use cases), it is the responsibility of the component designer to ensure that the premise of inviolable flows is supported, to the extent that they deem necessary to support their target use cases.  

For example, the component may include traffic shaping and policing at the ingress, to prevent corrupted or malicious or excessive packets from entering the network, thereby decreasing the likelihood that any traffic will interfere with any DetNet OT flow. The component may include integrity protection for some or all of the header fields such as those used for flow ID, thereby decreasing the likelihood that a packet whose flow ID has been compromised might be directed into a different flow path. The component may verify every single packet header at every forwarding location, or only at certain points. In any of these cases the component may use dynamic performance analytics [ref to DPA section] to cause action to be initiated to address the situation in an appropriate and timely manner, either at the data plane or controller plane, or both in concert. The component’s software and hardware may include measures to ensure the integrity of the resource allocation/deallocation process. Other design aspects of the component may help ensure that the adverse effects of malicious traffic are more limited, for example by protecting network control interfaces, or minimizing cascade failures. The component may include features specific to a given use case, such as configuration of the response to a given sequential packet loss count. 

Ultimately, due to cost and complexity factors, the security properties of a component designed for low-cost systems may be (by design) far inferior to a component with similar intended functionality, but designed for highly secure or otherwise critical applications, perhaps at substantially higher cost. Any given component is designed for some set of use cases and accordingly will have certain limitations on its security properties and vulnerabilities. It is thus the responsibility of the system designer to assure themselves that the components they use in their design are capable of satisfying their overall system security requirements. 

3.1.3 Documenting the Security Properties of a Component

In order for the system designer to adequately understand the security related behavior of a given component, the designer of any component intended for use with DetNet needs to clearly document the security properties of that component. For example, to address the case where a corrupted packet in which the flow identification information is compromised and thus may incidentally match the flow ID of another (“victim”) DetNet flow, resulting in additional unauthorized traffic on the victim, the documentation might state that the component employs integrity protection on the flow identification fields. 

3.1.4 Fail-Safe Component Behavior

Even when the security properties of a component are understood and well specified, if the component malfunctions, for example due to physical circumstances unpredicted by the component designer, it may be difficult or impossible to fully prevent malfunction of the network. The degree to which a component is hardened against various types of failures is a distinguishing feature of the component and its design, and the overall system design can only be as strong as its weakest link. 
However, all networks are subject to this level of uncertainty; it is not unique to DetNet. Having said that, DetNet raises the bar by changing many added latency scenarios from tolerable annoyances to unacceptable service violations.   That in turn underscores the importance of system integrity, as well as correct and stable configuration of the network and its nodes, as discussed in [reference to Introduction section].  
. . .
END
-----------REV2 END--------------------------------

-----Original Message-----
From: Magnus Westerlund <[e-mail]> 
Sent: Thursday, January 7, 2021 2:23 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-security-13: (with DISCUSS and COMMENT)

Hi,

So I think I did missinterpret the intention of the original sentence a bit.
This longer text do help me understand and it might be useful for others.
However, I do wonder if there are an even better description of this?

So to me there appear to be a design principle here that the resources for one
flow are inviolable. That way one can keep the different flows and resource
allocations independent. However, this design principle is only fulfilled if the
individual components and the setup of the chain of components ensures this
design priniciple. 

So with correctly designed components and security mechanisms one can prevent
malious acitvities from impacting other resources. And this might be the simpler
case at least on a theoreticall level as the malicous attacker can be limited in
where it can impact traffic flows or network control interfaces through security
mechanisms. 

For network internal malfunctions this design principle might not be as feasible
to achive the total goal, but the design principle should lead to that impact is
minimized to the diretly affected flows, i.e. avoid casade failures. For my case
of rewritten flow-id then only the original and target flow should be affected.
In addition this failure should rapidly be detected so the failure can be
addressed. 

As you discuss to attempt to ensure this inviolable resource allocation, to
detect my specific case, the system designer needs a component where each
individual flow is verified to be within resource allocation as each single
device where resource contention could occurr, i.e. in each router or switch on
the path through the network. 

So taking my specific case of network internal rewrite of the flow-ids. With
flow shapers in each forwarding instance one can prevent the flow to go beyond
its resource allocation and cause impact outside of the directly impacted flows.
However, the system and its protocols have not been built to prevent the
impacted flow from being harmed here as this internal failure is unlikely enough
that putting in the mechanism to verify each single packet belonging to each
flow is deemed to expensive. Instead it is trade-off that a flow shaper would
cause drops if over using the resources, raising an alarm that something is
malfunctioning as these drops occurs. While having security mechanism to
identify flows correctly at the ingress and prevent malicous attackers modified
packets to join a flow is likely a necessary mechanism. 

So the whole point with this text was to verify if I have correctly understood
what is attemtped to described here. And secondly maybe indicate that the
proposed text maybe can be further improved by more accurately describe the
principle and the fact that certain choices have been made on protocol level for
what support is required. In addtion the implementor of each component as well
as the system builder needs to consider how the set of chosen components
interact to reach the security goals related to different aspects, in this case
the resource allocation. 

Please consider if your text proposal can be further improved to more correctly
describe what is relevant here. As the section is intended to be a high level
requirement on individual components the hard question is how much requirement
is necessary to be explicit about. I think the aggregation example in Section
3.1 do point to the challenges here to fulfill this design principle. As the
goal of aggregating is to only need aggregate state in the middle which in its
turn can violate the principle of inviolable for each component, as adding one
flow to much to the aggregate through an error will potentially impact all the
other component flows. 

Cheers

Magnus Westerlund


On Wed, 2021-01-06 at 15:33 -0800, Ethan Grossman wrote:
> Hi Magnus,
> Thank you for your review comments, they are very helpful. We have
> incorporated David's comments into our proposed new text for the two
> sections referenced, as follows. Please let us know if this sufficiently
> addresses your comments. 
> Sincerely,
> Ethan (as DetNet Security draft editor) 
> 
> ----------------START --------------------------------------------
> OLD: 
> 3.1.  Resource Allocation
> A DetNet system security designer relies on the premise that any resources
> allocated to a resource-reserved (OT-type) flow are inviolable, in other
> words there is no physical possibility within a DetNet component that
> resources allocated to a given flow can be compromised by any type of
> traffic in the network; this includes both malicious traffic as well as
> inadvertent traffic such as might be produced by a malfunctioning component,
> for example one made by a different manufacturer.  From a security
> standpoint, this is a critical assumption, for example when designing
> against DOS attacks.
> It is the responsibility of the component designer to ensure that this
> condition is met; this implies protection against excess traffic from
> adjacent flows, and against compromises to the resource
> allocation/deallocation process, for example through the use of traffic
> shaping and policing.
> . . .
> NEW: 
> 3.1.  Resource Allocation
> A DetNet system security designer relies on the premise that any resources
> allocated to a resource-reserved (OT-type) flow are inviolable; in other
> words there is no physical possibility within a DetNet component that
> resources allocated to a given flow can be compromised by any type of
> traffic in the network; this includes malicious traffic as well as
> inadvertent traffic such as might be produced by a malfunctioning component,
> or due to interactions between components that were not sufficiently tested
> for interoperability. From a security standpoint, this is a critical
> assumption, for example when designing against DOS attacks.  
> It is the responsibility of the component designer to ensure that this
> condition is met; this implies protection against excess traffic from
> adjacent flows, and against compromises to the resource
> allocation/deallocation process, for example through the use of traffic
> shaping and policing.
> However, this assumption on the part of the DetNet system designer must be
> tempered by the fact that any given component is designed for some set of
> use cases and accordingly will have certain limitations on its security
> properties and vulnerabilities. For example, due to cost and complexity
> factors, the security properties of a component designed for low-cost
> systems may be quite different from a component with similar intended
> functionality, but designed for highly secure or otherwise critical
> applications, perhaps at substantially higher cost. Thus, a significant
> responsibility of the designer of any component intended for use with DetNet
> is that they clearly document the security properties of the component. For
> example, to address the case where a corrupted packet in which the flow
> identification information is compromised and thus may incidentally match
> the flow ID of another ("victim") DetNet flow, resulting in additional
> unauthorized traffic on the victim, the documentation might state that the
> component employs integrity protection on the flow identification fields. 
> Even in the case that the security properties of the component as designed
> are well specified and understood, if the component malfunctions, for
> example due to physical circumstances unpredicted by the component designer,
> it may be difficult or impossible to fully prevent malfunction of the
> network. However, all networks are subject to this level of uncertainty; it
> is not unique to DetNet. Having said that, DetNet raises the bar by changing
> many added latency scenarios from tolerable annoyances to unacceptable
> service violations.   That in turn underscores the importance of system
> integrity, as well as correct and stable configuration of the network and
> its nodes, as discussed in [reference to Introduction section].  
> . . .
> END
> 
> OLD: 
> 8.1.6.  End-to-End Delivery
> Packets sent over DetNet are not to be dropped by the network due to
> congestion.  (Packets may however intentionally be dropped for intended
> reasons, e.g. per security measures).
> . . .
> NEW: 
> 8.1.6.  End-to-End Delivery
> Packets that are part of a resource-reserved DetNet flow are not to be
> dropped by the DetNet due to congestion.  Packets may however be dropped for
> intended reasons, for example security measures. For example, consider the
> case in which a packet becomes corrupted (whether incidentally or
> maliciously) such that the resulting flow ID incidentally matches the flow
> ID of another DetNet flow, potentially resulting in additional unauthorized
> traffic on the latter. In such a case it may be a security requirement that
> the system report and/or take some defined action, perhaps when a packet
> drop count threshold has been reached (see also [reference to Dynamic
> Performance Analytics section]). 
> . . .
> END
> 
> -----------------------END-------------------------------------
> 
> -----Original Message-----
> From: Black, David <[e-mail]> 
> Sent: Tuesday, December 22, 2020 9:19 AM
> To: Magnus Westerlund <[e-mail]>; The IESG
> <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; Black, David <[e-mail]>
> Subject: RE: [Detnet] Magnus Westerlund's Discuss on
> draft-ietf-detnet-security-13: (with DISCUSS and COMMENT)
> 
> Hi Magnus,
> 
> > Can we really ensure that a malfunctioning component can't compromise 
> > the resources of another one. The most simple example I would have is 
> > a router with a malfunction rewriting the destination address or flow 
> > label of a packet causing the packet to change the flow it is 
> > belonging too,
> 
> No, but ...
> 
> ... DetNet is fundamentally relying on system integrity and correct
> configuration of the DetNet implementations.  This is not a new concept -
> e.g., if an MPLS LSR fouls up the label switching, all manner of things can
> go very wrong very quickly ... which is something that generally doesn't
> happen in practice.  That said, DetNet raises the bar by changing many added
> latency scenarios from tolerable annoyances to unacceptable service
> violations.   That in turn increases the importance of system integrity and
> correct/stable configuration of the network and its nodes.  I would suggest
> a rewording along these lines if that's acceptable to you, as I don't think
> this area of concern justifies additional defense mechanisms in the data
> planes.
> 
> > I would also recommend that you don't indicate that a different 
> > manufacturer can be blamed. Isn't a malfunction going to occur where 
> > they occur, it is not like a single vendor network will be without 
> > malfunctions due to hardware issue, nor have its set of software bugs.
> 
> +1
> 
> Thanks, --David (as Transport Technical Advisor to the detnet WG)
> 
> > -----Original Message-----
> > From: detnet <[e-mail]> On Behalf Of Magnus Westerlund 
> > via Datatracker
> > Sent: Tuesday, December 22, 2020 9:12 AM
> > To: The IESG
> > Cc: [e-mail]; [e-mail]; 
> > [e-mail]; detnet- [e-mail]
> > Subject: [Detnet] Magnus Westerlund's Discuss on
> 
> draft-ietf-detnet-security-13:
> > (with DISCUSS and COMMENT)
> > 
> > 
> > [EXTERNAL EMAIL]
> > 
> > Magnus Westerlund has entered the following ballot position for
> > draft-ietf-detnet-security-13: Discuss
> > 
> > When responding, please keep the subject line intact and reply to all 
> > email addresses included in the To and CC lines. (Feel free to cut 
> > this introductory paragraph, however.)
> > 
> > 
> > Please refer to 
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-detnet-security/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > Section 3.1:
> > 
> >    A DetNet system security designer relies on the premise that any
> >    resources allocated to a resource-reserved (OT-type) flow are
> >    inviolable, in other words there is no physical possibility within a
> >    DetNet component that resources allocated to a given flow can be
> >    compromised by any type of traffic in the network; this includes both
> >    malicious traffic as well as inadvertent traffic such as might be
> >    produced by a malfunctioning component, for example one made by a
> >    different manufacturer.
> > 
> > Can we really ensure that a malfunctioning component can't compromise 
> > the resources of another one. The most simple example I would have is 
> > a router with a malfunction rewriting the destination address or flow 
> > label of a packet causing the packet to change the flow it is 
> > belonging too, thus if occurring for any significant amount of packets 
> > causing overflow in the next hop router when the original and the 
> > remarked flow compete for the same resources assigned. The only way to 
> > ensure that this happens is to verify a strong header integrity 
> > protection at each point a decision on how to forward, classify or 
> > remark the flow is done. So Section
> > 3.3 indicate that this is an issue, but only discusses how it can be 
> > solved over ethernet. This issue hasn't been well handled in either 
> > the MPLS or IP detnet data planes as no additional mechanism was required
> 
> to ensure this criteria is meet.
> > 
> > So I think the requirement that also malfunctions in equipment don't 
> > result in flow violations is hard, and will require that the already 
> > approved data plane specification needs additional mechanism that 
> > verify all data used on each occasion the data is used. Neither MPLS 
> > nor IP as currently specified fulfill this, not even against 
> > non-malicious malfunctions or corruption type malfunctions. Then we 
> > have those malfunction that breaks the network or where control plane
> 
> information provided is being corrupted.
> > 
> > I have only looked a bit deeply on one type of malfunction that I know 
> > that can occur. I convinced that this document will indicate a number 
> > of additional potential ways things can go wrong that can't be 
> > determined without additional mechanisms and likely additional per 
> > packet fields. Thus, I think we need to discuss if the security 
> > properties matches the actual approved data plane, or if the property is
> 
> so important that the data plane specification is moved back to the WG to be
> fixed?
> > 
> > I would also recommend that you don't indicate that a different 
> > manufacturer can be blamed. Isn't a malfunction going to occur where 
> > they occur, it is not like a single vendor network will be without 
> > malfunctions due to hardware issue, nor have its set of software bugs.
> > 
> > Section 9.1:
> > 
> >    The IP protocol has a long history of security considerations and
> >    architectural protection mechanisms.  From a data plane perspective
> >    DetNet does not add or modify any IP header information, so the
> >    carriage of DetNet traffic over an IP data plane does not introduce
> >    any new security issues that were not there before, apart from those
> >    already described in the data-plane-independent threats section
> >    Section 5, Security Threats.
> > 
> > The above requirement from Section 3.1 in regards to IP header fields 
> > used for flow classification are not automatically fulfilled without 
> > additional mechanisms. Thus, I would claim that DETNET unless Section 
> > 3.1 requirement is minimized will require support for a strong 
> > integrity mechanism over all headers. So if this needs to be keyed or 
> > not is totally dependent on if malicious modifications of packet headers
> 
> needs to be taken into account or not.
> > 
> > Section 9.2:
> > 
> > Same as previous issue but for integrity over the MPLS headers.
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > 8.1.6.  End-to-End Delivery
> > Packets sent over DetNet are not to be dropped by the network due to
> >    congestion.  (Packets may however intentionally be dropped for
> >    intended reasons, e.g. per security measures).
> > Maybe it need to be stated that packets for a flow that are within 
> > flow parameters are not to be dropped due to congestion.
> > 
> > The security aspects include packets being dropped due to corruption 
> > malicious or not.
> > 
> > 
> > 
> > _______________________________________________
> > detnet mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/detnet
> 
>