[Coin] A few comments on draft-kunze-coin-industrial-use-cases-00.txt

"David R. Oran" <daveoran@orandom.net> Thu, 18 July 2019 18:00 UTC

Return-Path: <daveoran@orandom.net>
X-Original-To: coin@ietfa.amsl.com
Delivered-To: coin@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 29B8B120B80 for <coin@ietfa.amsl.com>; Thu, 18 Jul 2019 11:00:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UR5EuFjqVGRl for <coin@ietfa.amsl.com>; Thu, 18 Jul 2019 11:00:49 -0700 (PDT)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9D3120B72 for <coin@irtf.org>; Thu, 18 Jul 2019 11:00:49 -0700 (PDT)
Received: from [] (50-193-44-142-static.hfc.comcastbusiness.net []) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id x6II0iC5009203 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO) for <coin@irtf.org>; Thu, 18 Jul 2019 11:00:46 -0700
From: "David R. Oran" <daveoran@orandom.net>
To: coin@irtf.org
Date: Thu, 18 Jul 2019 11:00:43 -0700
X-Mailer: MailMate (1.12.5r5643)
Message-ID: <F2B01856-B3CF-406C-9A35-A75D1F95441A@orandom.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_8B7BE2D4-F83D-45BF-9B7D-447033BB2117_="
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/coin/CT-ojmNNpOqY1bpY-efI-o5hbKU>
Subject: [Coin] A few comments on draft-kunze-coin-industrial-use-cases-00.txt
X-BeenThere: coin@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "COIN: Computing in the Network" <coin.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/coin>, <mailto:coin-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/coin/>
List-Post: <mailto:coin@irtf.org>
List-Help: <mailto:coin-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/coin>, <mailto:coin-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jul 2019 18:00:54 -0000

This is a useful first start at documenting an important use case, so 
thanks for taking the time to write and submit the draft. I think it 
would be a good document to adopt once the RG is fully formed and 

I have a few comments:

1. On security, you say:
“ Another aspect is that business data leaving the premise and control
    of the company further comes with security concerns, as sensitive
    information or valuable business secrets might be contained in it.
    Typical security measures such as encrypting the data makes in-
    network computing techniques hardly applicable as they typically 
    on unencrypted data.  Adding security to in-network computing
    approaches, either by adding functionality for handling encrypted
    data or devising general security measures, is thus a very promising
    field for research.”

	While it is true that data flowing over external links and ISPs 
represents a security hazard, the converse implication that data staying 
in the enterprise, or even confined to the factory floor is safe from 
confidentiality or modification threats and hence needs less protection 
is not. One would hope that by adopting in-network computing as a 
paradigm, this would be seen as an opportunity to actually *upgrade* the 
security of industrial automation by dealing with the multi-party nature 
of the communication paradigms and in fact allowing data to be:
		- encrypted over all links
		- authenticated by any element possessing the keys to read it
		- provenance tracked through any device that has the necessary keys 
and permissions to modify it

	Therefore, from a security standpoint, treating a network element like 
a switch or router that either observes of modifies data differently 
from a computational host that does so would be a mistake in my view.

2. On the need for sensor traffic filters, a bit more detail on the 
question of “how to design” would be helpful, since different design 
requirements lead to quite different capability requirements on the 
elements doing it. A few initial thoughts:
	- fuzzing thresholds with some soft state on values can suppress 
readings that haven’t changed enough to matter
	- If there are redundant sensors giving similar readings such that 
you’d like to suppress the redundancy, you need to either send some 
periodic suppression stats computed by the filter, or annotate the 
non-suppressed sensor data with either some count of the samples 
suppressed, or some error bars computed from the set of received values.
	- we learned quit painfully for event logs (which are similar 
time-series data to sensor data) that you need to periodically send 
something so an upstream computation element can tell the difference 
among potential data loss, the lack of new readings, or a broken data 

3. The point about safety is well taken. I’m not sure it’s necessary 
to say much more about this, however from personal experience I’d like 
to emphasize that you can’t achieve the requisite level of safety only 
by measures “inside” the system; especially not by relying on the 
computational elements alone. For example in the case of industrial 
robots, the environment needs human-visible safety boundaries that are 
not computed from the operation of the robot, but in fact mark the 
absolute physical extent of the robot’s reach. These are either 
painted on the floor, by placing the robot inside a physical bounding 
box that cannot be opened by the software, or some other 
outside-the-system mechanism. It may be that in-network computing 
doesn’t affect this at all, but it’s worth a conversation to see if 
there are new hazards introduced. Therefore when you ask “How can the 
software give guaranteed safety over best-effort networks?” the answer 
for me is clearly “no” and in fact is “no” for **any** kind of 

4. I might split up the security discussion into two pieces, or more it 
to the “security Considerations” section rather than leaving it 
“N/A”, which is a red flag for much of the community.