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

[Magnus Westerlund <[e-mail]>]

For your information,

I will have christmas vacation from now until the 7th of Jan so don't expect any
rapid response. 

Cheers

Magnus

On Tue, 2020-12-22 at 06:12 -0800, Magnus Westerlund via Datatracker wrote:
> 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.
> 
> 
>