[Detnet] Robert Wilton's No Objection on draft-ietf-detnet-security-13: (with COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-detnet-security-13: No Objection

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/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this document.  Sorry, I've run out time to review this in detail,
although I don't immediately see any manageability concerns when I scanned
through the document.

A few minor comments for your consideration:

1) Perhaps it might be helpful to mention remind that DetNet isn't the same as
TSN in the introduction?

I don't know if these are already covered, or if they are not valid problems,
but I guess a couple of attacks that I would be concerned with are:

(2) Overloading the exception path queue on the router.  E.g., if any of the
DetNet streams require/expect some packets to be punted to the control plane or
software data plane for processing (OAM related perhaps), and there is a single
queue from the forwarding ASIC to a control plane or software data plane, then
it could be possible for Non Detnet flows to overload that shared queue such
that punted packets on the DetNet flows would end up being dropped.

(2b) Related to (2), if an attacker was able to overload the router or linecard
CPU, e.g., through excessive management API requests, then it may be plausible
that it could also cause control plane processing of packets to be dropped, or
slowed down.

(2c) If the control plane is being managed by a separate controller than
presumably both (2) and (2b) could equally apply to getting traffic to a
controller, or processing events on the controller.

(3) Is there any potential issue with traffic being carried over L2 load
balanced links (e.g. LAG) that apply statistical QoS.  E.g., by crafting
traffic on a non DetNet flow that overloads one LAG member but doesn't overload
the statistical QoS guarantees.  Perhaps this is outside the considerations for
DetNet, or already covered by TSN.

I'll leave it to the authors to determine whether any of these are valid and
require further text, or if they are either already sufficiently covered, out
of scope, or not valid concerns.

Regards,
Rob