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

[Ethan Grossman <[e-mail]>]

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