Residual challenges. For the RA enabler, we implement a deep attestation protocol. Our solution is hardware dependent, i.e., it is based on a specific type and implementation of the so-called root of trust - TPM. Network nodes without TPM or with another type of root of trust (e.g., TrustZone) cannot run our protocol. 4 xxxxx://xxxxxxxxx.xxxxxxxxx.xxx/publicationDetails/biblio?CC=WO&NR=2020212501A1&KC=A1&FT=D&locale=fr_EP#
Residual challenges. The most evident open challenge is the scalability of RCA. In many practical cases, the number of components/indicators to be taken into the analysis could be enormous. This can lead to a big volume of data processed. Similarly, the historical database of learned events can become remarkably more voluminous and sophisticated. It raises a natural concern about the response time of the tool. Besides, it is also important to note that failures usually propagate in complex systems through causal chains and produce evolving fingerprints of noisy symptoms. One of the first tasks to accomplish for an automated tool helping humans troubleshooting a system is to group events that are causally connected and keep unrelated events separated. Achieving this is often not straightforward since components of a system can exhibit similar symptoms of two unrelated failures. The failure can also present symptoms very similar to a normal activity. For example, when we no longer receive sensed data from a sensor, it is difficult to determine whether the sensor has moved out of the range (normal activity); or the communication has failed (failure). To deal with this problem, we need a higher level of granularity in the monitoring indicators and a deeper analysis to distinguish the different cases.
Residual challenges. T4.4 will concentrate on the development of the Component Instance Description part of the Manifest. Current version of manifest is mostly expressed in proprietary format and YANG. The next challenge is to extend TOSCA specification with liability and accountability properties proposed in the manifest. As a result, the manifest would be easily interpreted by orchestrators which widely use TOSCA to describe service deployment as well as routers or network devices which commonly use YANG to describe network configurations. The operational limitations need to be enriched beyond the MUD Threat profile, in order to express conditions and expected countermeasures.
Residual challenges. The most important challenge to be considered consists of the lack of scalability of RCA, in particular, the Bayesian Network inference algorithm as it scales badly when the number of network elements increases. An example was Figure 11, with 30 seconds for 500 network elements.
Residual challenges. The most evident open challenge is the scalability of GRALAF. In many practical cases, the number of components/indicators to be taken into the analysis could be very large. This situation can lead to a big volume of data processed and very complex algorithms to run. Similarly, the historical data and liability model have to be managed for size and be kept concise. Moreover, the representative strength 5 xxxxx://xxxxxx.xxxx.xx/paper/8157-dags-with-no-tears-continuous-optimization-for-structure-learning.pdf, xxxxx://xxxxxxxxx.xxxxxxxxxxx.xx/ of the network model is another residual challenge. This is also related to how model generation will be performed. The translation of a 5G environment should be realistic and should include critical elements in the network and service infrastructure. We are planning to cooperate with other partners and utilize existing enablers for system modelling, if possible. 5 Liability enablers integration into INSPIRE-5Gplus architecture The High-Level Architecture (HLA) of INSPIRE-5Gplus shown in Figure 13 serves a framework to integrate the different liability enablers described in Section 4 in the common architecture. The mechanism will be based on interactions based on interfaces between enablers and common components. Next subsections describe the position of each of liability enablers and the identified interactions. Figure 15 INSPIRE-5Gplus High Level Architecture (HLA)
Residual challenges. The main technical limitation from PoT is that it is based on the assumption that we are selecting specific nodes on the network to validate, not all nodes. Adding new nodes, such MiTM or redirection of the path between PoT nodes, will be not detected. 6 xxxxx://xxxxxx.xxx/HugoRP97/cne_opot_sdk_public/
Residual challenges. The eTRM depends on the concrete API provided by each particular SDN controller, as it is directly attached to an SDN controller. Each SDN controller propose specific API and provides the network topology in a given format (JSON based)
Residual challenges. The main constraints are the components descriptors and different possibilities are existing. For example, for VNF, the existing version was adapted for TOSCA and OSM but it is a limitation. For software, only Java code is evaluated. So the technical constraints are to define the components we want to evaluate and the technologies used for evaluating the enabler. To bypass this limitation, a manual way could be used for evaluating a component by using different reports and information provided with the component. In this case, a DTwC would be also delivered.
Residual challenges. The main current problem is to integrate the entries/values required to calculate the trust value from the rest of enablers. To address this challenge, the TRM will implement extensible mechanisms to be able to calculate trust values from the different INSPIRE-5Gplus enablers as well as from future security enablers. This approach will be validated in the testbed by generating multiple entries from both, INSPIRE-5Gplus security enablers and trust value generators developed for testing purposes. Further relevant challenges are the ones posed by Hyperledger Fabric (as the calculation is performed inside a Smart Contract). There are no more technological limitations found at the time of writing.
Residual challenges. Currently no limitations appeared, but based on the work done up until now, if any limitations should appear, they would come from the selected Blockchain system and the use of smart contracts to deploy in it. For example, one of the Blockchain weaknesses is the necessity of a large number of nodes. The testbed to be used during the experimental and validation phase have a reasonable number of machines to be used as peers but, the testbed is shared with other projects and so, their time plans and use of machines could affect the correct test case evaluation.
