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

[Ike Kunze <[e-mail]>]

Hi David,

thank you for your very helpful comments.
Please find my thoughts inline.


Am 18.07.2019 um 20:00 schrieb David R. Oran <[e-mail]<mailto:[e-mail]>>:


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 operational.

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 work
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.

[Ike] I agree with you in that the adoption of in-network computing can also be an incentive to reconsider the current practices within enterprise networks.
In fact, I think that authenticating network elements that access or process the data packets, as well as informing the end-hosts about the fact that the packets
are modified is very important, especially since in-network computing interferes with the traditional end-to-end principle.
These are aspects that COIN certainly has to deal with at some point and we are very interested in examining these issues in more detail.

Regarding the applicability of in-network computing on encrypted traffic: I think that this is a major hurdle in the process of establishing acceptance for COIN in general and has implications on far more application areas than just the industrial domain. This is why I think that it should be discussed in greater detail in a separate draft.


  1.  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 source.

[Ike] Yes, the concrete design/implementation of the filters has a direct impact on the requirements of elements on which these filters are deployed.
The same is true for the different (pre-)processing methods as well as the different control algorithms.
Dealing with and accounting for the different capability requirements of elements is hence essential and has to be considered by COIN going forward.
An in-network computing framework should surely take the different capabilities into account when distributing tasks across the network.

The other critical aspect you mention, e.g. when saying "so an upstream computation element can tell the difference among …“, from my perspective boils down to the question of how in-network computing mechanisms of any sort can be integrated into ’traditional’ communication schemes.
This once again relates to the issue with the end-to-end principle mentioned above.

  1.  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 network.

[Ike] I am not sure either if the question will ever be answered with „yes“. However, I think that the increasing dynamics in the production domain in general and, especially, in the interaction between robots & humans make it increasingly difficult to realize these human-visible safety boundaries, although I agree that they would perhaps be the best solutions so that workers could easy perceive the dangerous regions.
Thus, it should be worth it to investigate whether in-network computing can at least complement current safety measures and perhaps even improve them.
Maybe we should rephrase our question, e.g., to "To what extent can the software….?“.
Turning this the other way around, i.e., investigating the impact of in-network computing on already existing safety measures is something that I personally have not thought about before, but I agree that it is certainly worth a conversation.

  1.  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.

[Ike] Thank you for the hint. We will consider that for a possible update of the draft.


Thanks,
DaveO

--
Coin mailing list
[e-mail]<mailto:[e-mail]>
https://www.irtf.org/mailman/listinfo/coin


Best
Ike
--
Ike Kunze, M.Sc.
Researcher

COMSYS - Communication and Distributed Systems
RWTH Aachen University
Ahornstr. 55
52074 Aachen, Germany
Tel: [phone]
[e-mail]<mailto:[e-mail]>
http://www.comsys.rwth-aachen.de/team/ike-kunze/