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

[Magnus Westerlund <[e-mail]>]

Hi,

First, of all I am sorry to not have followed up earlier. 

I think Rev 2 was better and have multiple sections makes it easier to read. 

So I am ready to clear my discuss when the improved text in Section 3.1 is
avaialble. 

Cheers

Magnus



On Thu, 2021-01-07 at 15:12 -0800, Ethan Grossman wrote:
> 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
> > 
> > 
> 
>