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

[Ethan Grossman <[e-mail]>]

Hi Rob,
Thank you for your review comments. Our dispositions of them are below, inline, prefixed with the individual author's name who addressed them (EAG (me) or Tal Mizrahi). We expect to publish a draft revision within a few days (14) which will include this new material. If you have any further thoughts on our dispositions or the draft in general, please don't hesitate to let us know. 
Sincerely,
Ethan (as Editor, DetNet Security Considerations draft)

-----Original Message-----
From: Robert Wilton via Datatracker <[e-mail]> 
Sent: Thursday, January 7, 2021 5:24 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Lou Berger <[e-mail]>; [e-mail]
Subject: Robert Wilton's No Objection on draft-ietf-detnet-security-13: (with COMMENT)

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

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

-----Original Message-----
From: Robert Wilton via Datatracker <[e-mail]> 
Sent: Thursday, January 7, 2021 5:24 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Lou Berger <[e-mail]>; [e-mail]
Subject: Robert Wilton's No Objection on draft-ietf-detnet-security-13: (with COMMENT)

----------------------------------------------------------------------
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?

EAG: Added some text to clarify, including: 
"Data flows with deterministic properties are well-established for Ethernet networks (see TSN, <xref target="IEEE802.1BA"/>); DetNet brings these capabilities to the IP Network"

	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.

Tal: Added a slightly modified version of this text to Sec 5.2.3: 
<t>A specific example of a resource segmentation attack is by overloading the control 
		  plane of the DetNet node, e.g., by overloading the exception path queue on the 
		  router.  Thus, if any of the DetNet streams require or expect some packets to be punted 
		  to the control plane or software data plane for processing, 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. It should be noted that various attacks
		  directed at the control plane (either the CPU of the DetNet node or a network controller) 
		  can be used to compromise the network, but this document focuses on threats that are
		  specific to deterministic networks.</t>

	(3) Is there any potential issue with traffic being carried over L2 load balanced links (e.g. LAG, Link Aggregation) 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.

EAG: This is indeed a valid concern; we have already addressed this in section 3.2. 

	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

========== END ===============