WO2022128141A1

WO2022128141A1 - System and method for increasing availability of zero trust network devices

Info

Publication number: WO2022128141A1
Application number: PCT/EP2020/087351
Authority: WO
Inventors: Oleg Pogorelik; Alon Zilberman; Michael Shurman; Muhammad Barham
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-12-20
Filing date: 2020-12-20
Publication date: 2022-06-23
Anticipated expiration: 2023-06-20

Abstract

The present disclosure relates to the field of computer networks, in particular zero trust networks (ZTNs). More specifically, the present disclosure relates to increasing availability of ZTN devices, which e.g. include a ZTN controller, or an internet of things (IoT) device. The present disclosure therefore provides a system (100) for increasing availability of zero trust network, ZTN, devices (101, 103, 104). The system (100) comprises a ZTN controller (101), configured to establish a ZTN session (102) between a first ZTN device (103) of the system (100) and a second ZTN device (104) of the system (100) based on session information (105). The system (100) is configured to, if it is determined, by the system (100), that one of the ZTN controller (101), the first ZTN device (103) or the second ZTN device (104) is unavailable, establish, by the system (100), the ZTN session (102) between the first ZTN device (102) and the second ZTN device (103) based on session information (105a) used for a previous ZTN session between the first ZTN device (103) and the second ZTN device (104), and/or by repeatedly pushing session information (105b) to the first ZTN device (103) or the second ZTN device (104).

Description

SYSTEM AND METHOD FOR INCREASING

AVAILABILITY OF ZERO TRUST NETWORK DEVICES

TECHNICAL FIELD

The present disclosure relates to the field of computer networks, in particular, to zero trust networks (ZTNs). More specifically, the present disclosure relates to increasing availability of ZTN devices, which e.g. include a ZTN controller, or an internet of things (loT) device, in such ZTNs.

BACKGROUND

Zero trust networking aims at providing security to peer-to-peer (P2P) communication applications and services. It provides a security concept and a threat model, which no longer assume that actors, systems or services operating from within a security perimeter of a network should be automatically trusted, but instead must verify any entity trying to connect to the system, before granting access. Zero trust principles are: “never trust, always verify, and minimize access privileges

A ZTN often comprises loT devices, or is often built, at least partly, in an loT network. A ZTN implementation, however, strongly relies on a central policy decision function, which is e.g. implemented by a conventional zero trust controller (ZTC, or also called ZTN controller).

A policy decision function serves queries from a conventional ZTN client regarding the possibility of accessing a resource. The policy decision function may use sophisticated algorithms (e.g. rules) considering multiple factors related to a conventional ZTN client, e.g. an application, a user, a scenario, a context, or a pre-configured system setting. In response to a query, the requesting ZTN client receives a policy that may contain either a decline, or credentials for accessing an appropriate ZTN resource and specifying access rights (such as a right to view, copy, modify, capture information, active, deactivate, etc.).

A ZTC is required to be exceptionally reliable and available, and is usually running on server or a dedicated hardware device. While enterprises and small businesses can meet a ZTC availability requirement easily (due to their well-equipped infrastructure), in consumer operated home networks, hardware costs and complex maintenance of a ZTN are a huge burden for user acceptance. An alternative option of running a ZTC in a cloud environment raises privacy concerns and availability issues that might be caused by network availability and latencies.

FIG. 11 shows a conventional implementation of a ZTN 1100, comprising an Access Controller, a first loT device loTl and a second loT device IoT2. The Access Controller (e.g. a server device) comprises a conventional ZTC 1101, which is configured to allocate policies 1102 per session and maintain session keys including their initial creation, refreshment, and revocation. Each of the loT devices loTl, IoT2 comprises a conventional zero trust (ZT) client 1103a, 1103b, which is configured to manage session initiation flows in the respective loT device. Each of the loT devices loTl, IoT2 further comprises an authenticator 1104a, 1104b and a ZT gateway 1105a, 1105b. The authenticator 1104a, 1104b is configured to manage network filters, while the ZT gateway 1105a, 1105b is configured to enforce policies (e.g. by using network filters).

Thereby, initiation of a session flow (that is, communication between the loT devices loTl, IoT2, also called ZTN session) typically includes the following steps, as shown in FIG. 11 : In step 1111 an application 1106a running on the first loT device loTl requires access (e.g. initiated by a user 1108) to a counterpart application 1106b (e.g. a service) in the second loT device IoT2 and therefore provides IDs for authentication and policy adjustment to the ZTC 1101. In step 1112 the ZTC 1101 evaluates a policy and allocates appropriate resources to the ZT Client 1103a in the first loT device loTl. In step 1113 the ZTC 1101 evaluates the policy and allocates appropriate resources to the ZT Client 1103b in the second loT device IoT2. In step 1114, an application on the first loT device loTl and a service on the second loT device IoT2 communicate via an established session flow by using the allocated resources. WiFi resources 1107a, 1107b of the first loT device loTl, respectively the second loT device IoT2 can be used for communication.

To increase reliability, a conventional ZTN focusses on ZTC distribution and redundancy. That is, a conventional ZTN is expected to have more than one ZTC 1101 capable device so that, if a currently active ZTC 1101 becomes unavailable, its function can be moved to another device.

In a consumer environment, a ZTC could for example run on a smart TV and move to a tablet computer or a network speaker if the smart TV is shut off. However, there are many consumer ZTN networks where ZTC distribution and redundancy isn’t possible: consumer networks (in particular loT networks) are insecure, as no hardware security is included. As a result, a device querying a policy cannot rely on a provided decision. Further, power and performance of network nodes often are below ZTC requirements. A ZTC is expected to serve queries from many loT devices, multiplied by several sessions created by various applications running on a given device. Slow processing results in denial of service and/or improper operation caused by delays.

That is, high costs and complexity associated with the ZTC (including privacy issues related to a cloud based implementation) are a barrier for high availability of a ZTC, and thus for an implementation of a ZTN in a consumer network.

SUMMARY

In view of the above-mentioned problem, an objective of embodiments of the present disclosure is to improve the availability of a ZTN while meeting requirements for cost, complexity and privacy.

This or other objectives may be achieved by embodiments of the present disclosure as described in the enclosed independent claims. Advantageous implementations of embodiments of the present disclosure are further defined in the dependent claims.

A first aspect of the present disclosure provides a system for increasing availability of ZTN devices, wherein the system comprises a ZTN controller, configured to establish a ZTN session between a first ZTN device of the system and a second ZTN device of the system based on session information; wherein the system is configured to, if it is determined, by the system, that one of the ZTN controller, the first ZTN device or the second ZTN device is unavailable, establish, by the system, the ZTN session between the first ZTN device and the second ZTN device based on session information used for a previous ZTN session between the first ZTN device and the second ZTN device, and/or by repeatedly pushing session information to the first ZTN device or the second ZTN device.

This is beneficial, as the ZTN can continue to operate, even if one of the ZTN controller, the first ZTN device or the second ZTN device is unavailable. In particular, when new policy decisions can’t be made, no new kinds of ZTN sessions will be allowed, but old and permanent (re-occurring) sessions may continue to work as usual. Policy-related commands worked out by the ZTN controller (before the controller was disconnected) can be reliably delivered to a target ZTN device, e.g. using P2P communication. This ensures that e.g. the ZTN controller, or one of the first or second ZTN device can be operated on hardware, which is occasionally unavailable.

In particular, the session information includes at least one of a session key, a session token, a session access policy. This is in particular the case for the session information used for the previous ZTN session, and for the repeatedly pushed session information.

In particular, the ZTN controller is an loT device. In particular, the first ZTN device is an loT device. In particular, the second ZTN device is an loT device.

In particular, repeatedly pushing session information includes pushing the session information at least two times. In particular, pushing means forwarding the session information, e.g. without that the forwarding was requested by the receiving device.

In particular, the ZTN session between the first ZTN device and the second ZTN device includes a peer-to-peer (P2P) connection of the first ZTN device and the second ZTN device.

In an implementation form of the first aspect, if it is determined, by the first ZTN device, that the ZTN controller is unavailable, establish, by the first ZTN device, the ZTN session between the first ZTN device and the second ZTN device based on the session information used for the previous ZTN session between the first ZTN device and the second ZTN device.

This ensures that the first ZTN device can detect that the ZTN controller is unavailable and that the first ZTN device can then establish the ZTN session without the presence of the ZTN controller. The first ZTN device increases security of communication by using the session information used for the previous ZTN session, while due to the unavailability of the ZTN controller, no now session information can be provided.

In a further implementation form of the first aspect, the session information used for the previous ZTN session between the first ZTN device and the second ZTN device was obtained from the ZTN controller. This ensures that the session information of the previous ZTN session which is used by the first ZTN device to establish a session is originally provided by the ZTN controller (that is, the session information can be trusted, as it was provided by a trusted device (i.e. the ZTN controller).

In a further implementation form of the first aspect, the session information further includes a re-use limit, wherein the first ZTN device is further configured to establish the ZTN session between the first ZTN device and the second ZTN device based on the re-use limit.

This ensures that the session information used for the previous ZTN session becomes invalid after a predefined number of re-uses or after a predefined amount of time, which increases security.

In particular, the re-use limit includes a maximum number of allowed re-uses of the session information used for the previous ZTN session and/or a maximum time of allowed re-use of the session information used for the previous ZTN session.

In a further implementation form of the first aspect, the second ZTN device is further configured to only establish the ZTN session with the first ZTN device based on the session information used for the previous ZTN session, if it is determined, by the second ZTN device, that the ZTN controller is unavailable.

This is beneficial as it increases security of the system as the re-use of the old session information is only allowed by the second ZTN device, if the ZTN controller is really unavailable.

In particular, the second ZTN device tries to connect directly to the ZTN controller to determine, if the ZTN controller is available or not.

In a further implementation form of the first aspect, the system is further configured to repeatedly push session information to the second ZTN device, if it is determined, by the ZTN controller, that the second ZTN device is unavailable. This ensures that the second ZTN device receives the session information immediately after the second ZTN device becomes available again.

In particular, the session information is pushed, by the ZTN controller, directly or indirectly.

In particular, the system is further configured to repeatedly push the session information to the second ZTN device until an acknowledgement is received from the second ZTN device.

In particular, the system is further configured to repeatedly push the session information to the second ZTN device until a predefined time limit or a predefined number of pushes is exceeded.

In particular, once the repeatedly pushed session information is successfully received by the second ZTN device, the ZTN session between the first ZTN device and the second ZTN device is established, based on the received repeatedly pushed session information.

In a further implementation form of the first aspect, the ZTN controller is further configured to repeatedly push session information to the second ZTN device directly, if it is determined, by the ZTN controller, that the second ZTN device is unavailable.

This is beneficial, as no intermediate device is necessary for transmitting information to the second ZTN device.

In a further implementation form of the first aspect, the ZTN controller is further configured to, if it is determined, by the ZTN controller, that the second ZTN device is unavailable, configure the first ZTN device to repeatedly send a request for ZTN session establishment to the second ZTN device.

This ensures that the second ZTN device receives the request for ZTN session establishment immediately after the second ZTN device becomes available again.

In particular, the first ZTN device is further configured to repeatedly send the request for session establishment to the second ZTN device until an acknowledgement is received from the second ZTN device. In particular, the first ZTN device is further configured to repeatedly send the request for session establishment to the second ZTN device until a time limit or a number of requests is exceeded.

In particular, once the repeatedly sent request for session establishment is successfully received by the second ZTN device, the ZTN session between the first ZTN device and the second ZTN device is established, based on the repeatedly pushed session information received by the second ZTN device.

In a further implementation form of the first aspect, the ZTN controller is further configured to, if it is determined, by the ZTN controller, that the second ZTN device is unavailable, configure a third ZTN device of the system to repeatedly push the session information to the second ZTN device.

This is beneficial, as another ZTN device can be employed for pushing session information, which increases redundancy.

In particular, the third ZTN device (which can e.g. be called anchor device) is less secure and trusted, compared to the ZTN controller, but is able to relay instructions (i.e. the session information) of the ZTN controller.

In particular, the third ZTN device is further configured to repeatedly push the session information to the second ZTN device until an acknowledgement is received from the second ZTN device by the third ZTN device.

In particular, the third ZTN device is further configured to repeatedly push the session information to the second ZTN device until a predefined time limit or a predefined number of pushes is exceeded.

In a further implementation form of the first aspect, the ZTN controller is further configured to configure the third ZTN device to repeatedly push the session information to the second ZTN device before the ZTN controller becomes unavailable. This ensures that the session information can be provided to the second ZTN device, even in a case in which the ZTN controller is not available in the ZTN, e.g. after shutting down the ZTN controller.

In a further implementation form of the first aspect, the ZTN controller is further configured to store the session information in the third ZTN device for repeatedly pushing the session information to the second ZTN device by the third ZTN device.

This ensures that the third ZTN device is aware of the relevant session information to be pushed to the second ZTN device.

In particular, this can be regarded as indirectly pushing the session information to the second ZTN device, by the ZTN controller.

In a further implementation form of the first aspect, the session information stored in the third ZTN device is encrypted with a public key corresponding to the second ZTN device.

This ensures that the session information cannot be eavesdropped or altered in the third ZTN device.

In particular, the session information stored in the third ZTN device comprises a running index, and/or a time stamp.

This allows preventing replay attacks, e.g. where an old message is re-used in an inappropriate situation.

In particular, the ZTN controller is configured to encrypt the session information with the public key before storing the encrypted session information in the third ZTN device.

In a further implementation form of the first aspect, the second ZTN device is further configured to only establish the ZTN session with the first ZTN device based on the received repeatedly pushed session information, if it is determined, by the second ZTN device, that the ZTN controller is unavailable. This is beneficial as it increases security of the system as using the session information (which is received from the third ZTN device) is only allowed by the second ZTN device, if the ZTN controller is really unavailable.

In particular, the second ZTN device directly tries to connect to the ZTN controller to determine, if the ZTN controller is available or not.

A second aspect of the present disclosure provides a method for increasing availability of zero trust network, ZTN, devices, wherein the method comprises the steps of establishing, by a ZTN controller of a system, a ZTN session between a first ZTN device of the system and a second ZTN device of the system, based on session information; if it is determined, by the system, that one of the ZTN controller, the first ZTN device or the second ZTN device is unavailable, establishing, by the system, the ZTN session between the first ZTN device and the second ZTN device, based on session information used for a previous ZTN session between the first ZTN device and the second ZTN device, and/or by repeatedly pushing session information to the first ZTN device or the second ZTN device.

In an implementation form of the second aspect the method further includes, if it is determined, by the first ZTN device, that the ZTN controller is unavailable, establishing, by the first ZTN device, the ZTN session between the first ZTN device and the second ZTN device based on the session information used for the previous ZTN session between the first ZTN device and the second ZTN device.

In a further implementation form of the second aspect, the session information used for the previous ZTN session between the first ZTN device and the second ZTN device was obtained from the ZTN controller.

In a further implementation form of the second aspect, the session information further includes a re-use limit, wherein the method further includes establishing, by the first ZTN device, the ZTN session between the first ZTN device and the second ZTN device based on the re-use limit.

In a further implementation form of the second aspect, the method further includes establishing, by the second ZTN device, the ZTN session with the first ZTN device based on the session information used for the previous ZTN session only, if it is determined, by the second ZTN device, that the ZTN controller is unavailable.

In a further implementation form of the second aspect, the method further includes, by the system, repeatedly pushing session information to the second ZTN device, if it is determined, by the ZTN controller, that the second ZTN device is unavailable.

In a further implementation form of the second aspect the method further includes repeatedly pushing, by the ZTN controller, session information to the second ZTN device directly, if it is determined, by the ZTN controller, that the second ZTN device is unavailable.

In a further implementation form of the second aspect the method further includes, if it is determined, by the ZTN controller, that the second ZTN device is unavailable, configuring, by the ZTN controller, the first ZTN device to repeatedly send a request for ZTN session establishment to the second ZTN device.

In a further implementation form of the second aspect the method further includes, if it is determined, by the ZTN controller, that the second ZTN device is unavailable, configuring, by the ZTN controller, a third ZTN device of the system to repeatedly push the session information to the second ZTN device.

In a further implementation form of the second aspect the method further includes configuring, by the ZTN controller, the third ZTN device to repeatedly push the session information to the second ZTN device before the ZTN controller becomes unavailable.

In a further implementation form of the second aspect the method further includes storing, by the ZTN controller, the session information in the third ZTN device for repeatedly pushing the session information to the second ZTN device by the third ZTN device.

In a further implementation form of the second aspect, the session information stored in the third ZTN device is encrypted with a public key corresponding to the second ZTN device.

In a further implementation form of the second aspect the method further includes establishing, by the second ZTN device, the ZTN session with the first ZTN device based on the received repeatedly pushed session information only, if it is determined, by the second ZTN device, that the ZTN controller is unavailable.

The second aspect and its implementation forms include the same advantages as the first aspect and its respective implementation forms.

A third aspect of the present disclosure provides a computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the steps of the method of the second aspects or any of its implementation forms.

The third aspect and its implementation forms include the same advantages as the second aspect and its respective implementation forms.

A fourth aspect of the present disclosure provides a non-transitory computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to carry out the steps of the method of the second aspect or any of its implementation forms.

The fourth aspect and its implementation forms include the same advantages as the second aspect and its respective implementation forms.

In other words, the present disclosure provides a technique for partial ZTN controller function distribution that allows a ZTN to continue operation when a ZTN controller (or a first or second ZTN device) is not available. At least one of the ZTN controller or the first or second ZTN device may implement a command persistent storage, so that a command can be re-used after a timeout of one of the ZTN controller or the first or second ZTN device. Further, ZTN controller function may partially be delegated to a third ZTN device (e.g. called anchor device, which can be less secure or trusted compared to the ZTN controller, but can be able to keep and relay commands of the ZTN controller). Thus, in case of an absence of the ZTN controller, the third ZTN device can deliver a command on behalf of the ZTN controller to the first or second ZTN device.

In contrast to conventional solutions focusing on full controller function delegation or redundancy, which requires installation of the several powerful devices able to support controller functions completely, the solution according to the present disclosure allows to support zero trust networking for systems including very basic devices only (e.g. ZTN devices that aren’t secure and powerful enough to fully support ZTN controller function). Solutions according to embodiments of the present disclosure in particular may allow to implement a ZTN in home loT networks with a single or visiting (e.g. smart phone of the family member) ZTN controller capable device. Such a ZTN can operate as expected when the ZTN controller is connected and, continue to operate even if the ZTN controller or other ZTN device is disconnected.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

The above-described aspects and implementation forms of the present disclosure will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

FIG. 1 shows a schematic view of a system according to an embodiment of the present disclosure;

FIG. 2 shows a schematic view of a system according to an embodiment of the present disclosure in more detail;

FIG. 3 shows a schematic view of an operating scenario of the system according to an embodiment of the present disclosure; FIG. 4 shows a schematic view of another operating scenario of the system according to an embodiment of the present disclosure;

FIG. 5 shows a schematic view of another operating scenario of the system according to an embodiment of the present disclosure;

FIG. 6 shows a schematic view of a ZTN controller according to an embodiment of the present disclosure;

FIG. 7 shows a schematic view of a ZTN client according to an embodiment of the present disclosure;

FIG. 8 shows a schematic view of another operating scenario of the system according to an embodiment of the present disclosure;

FIG. 9 shows a schematic view of another operating scenario of the system according to an embodiment of the present disclosure;

FIG. 10 shows another schematic view of a method according to an embodiment of the present disclosure;

FIG. 11 shows a schematic view of an operating scenario of a conventional ZTN.

DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1 shows a schematic view of a system 100 according to an embodiment of the present disclosure. The system 100 is for increasing availability of ZTN devices 101, 103, 104. To this end, the system 100 comprises a ZTN controller 101, a first ZTN device 103 and a second ZTN device 104.

The ZTN controller 101 is configured to establish a ZTN session 102 between the first ZTN device 103 and the second ZTN device 104. The ZTN session generally is established based on session information 105. The session information 105 may include several kinds of session information 105a, 105b, as it is going to be described in the following. To increase availability of the ZTN devices 101, 103, 104, the system 100 is configured to, if it is determined that one of the ZTN controller 101, the first ZTN device 103 or the second ZTN device 104 is unavailable, establish, the ZTN session 102 between the first ZTN device 103 and the second ZTN device 104 based on session information 105a used for a previous ZTN session between the first ZTN device 103 and the second ZTN device 104, and/or by repeatedly pushing session information 105b to the first ZTN device 103 or the second ZTN device 104.

Using the session information 105a used for a previous ZTN session between the first ZTN device 103 and the second ZTN device 104 provides secure means to establish the ZTN session 102 between the first ZTN device 103 and the second ZTN device 104, when the ZTN controller 101 is not available. Repeatedly pushing session information 105b to the first ZTN device 103 or the second ZTN device 104 quickly delivers information required for session established to the first ZTN device 103 or the second ZTN device 104, as soon as these devices are available again.

Optionally, the ZTN session 102 between the first ZTN device 103 and the second ZTN device 104 is established by the first ZTN device 103, based on the session information 105a used for the previous ZTN session between the first ZTN device 103 and the second ZTN device 104 if it is determined, by the first ZTN device 103, that the ZTN controller 101 is unavailable. That is, the first ZTN device 103 checks if the ZTN controller 101 really is unavailable, and only establishes the ZTN session 102, if the ZTN controller 101 can’t be reached.

Further optionally, if the ZTN controller 101 can’t be reached, the first ZTN device 103 only uses this kind of session information 105 to set up the ZTN session 102, which is session information 105a that was used for a previous ZTN session between the first ZTN device 103 and the second ZTN device 104 and which was obtained from the ZTN controller 101. The session information 105a that was used for the previous ZTN session was originally provided by the ZTN controller 101 and thus can be relied on for establishing a new ZTN session 102, even if the ZTN controller 101 is unavailable.

Further optionally, if the first ZTN device 103 tries to establish the ZTN session 102 with the second ZTN device 104, based on the session information 105a used for the previous ZTN session, the second ZTN device 104 only establishes the ZTN session 102 with the first ZTN device 103, if it determines, that the ZTN controller 101 is unavailable. Only if the ZTN controller 101 really is unavailable, a request from the first ZTN device 103 (which is based on previously used session information 105a) is accepted. If the ZTN controller 101 is however still available, a request from the first ZTN device 103 is rejected by the second ZTN device 104. Since the ZTN controller 101 is available, the first ZTN device 103, and/or the second ZTN device 104 will originate new access requests and operate in accordance with the new response of the ZTN controller 101. In this case, old session information 105a becomes irrelevant and will be dropped by the first ZTN device 103, and/or the second ZTN device 104.

Moreover, the system 100 optionally pushes the session information 105b to the second ZTN device 104 repeatedly only, if it is determined (e.g. by the ZTN controller 101) that the second ZTN device 104 is unavailable. That is, only if the second ZTN device is really unavailable at present, the system 100 repeatedly pushes the session information 105b to it. Thereby, unnecessary pushing is avoided. Further, due to the pushing, the second ZTN device 104 receives the repeatedly pushed session information 105b as soon it is available again.

Optionally, the ZTN controller 101 repeatedly pushes the session information 105b to the second ZTN device 104 directly, that is, without any intermediate entity which only forwards the session information 105b.

If the second ZTN device 104 is unavailable, the ZTN controller 101 optionally can configure the first ZTN device 103 to repeatedly send a request for ZTN session establishment to the second ZTN device 104. Thus, not only the session information 105b is received by the second ZTN device as soon as it is available again, but also the request for ZTN session establishment.

The second ZTN device 104 can establish the ZTN session 102 with the first ZTN device 103 based on the received repeatedly pushed session information 105b. However, the second ZTN device 104 optionally only may do so, if it determines that the ZTN controller 101 is unavailable. Thus, the second ZTN device 104 double checks if the ZTN controller 101 really is unavailable and thereby can reject malicious requests. In other words, information from an anchor device is only accepted, if the ZTN controller 101 is really unavailable.

FIG. 2 shows a schematic view of a system 100 according to an embodiment of the present disclosure in more detail. The system 100 shown in FIG. 2 comprises all features and functionality of the network device 100 of FIG. 1, as well as the following optional features: As it is illustrated in FIG. 2, the session information 105a, 105b further may include a re-use limit 201a, 201b. The first ZTN device 103 can be configured to establish the ZTN session 102 between the first ZTN device 103 and the second ZTN device 104 based on the re-use limit 201a, 201b. That is, the re-use limit 201a, 201b e.g. is a numerical value and the ZTN session 102 may only be established based on the session information 105a, 105b, as often, as it is indicated by the re-use limit 201a, 201b.

As it is further illustrated in FIG. 2, if the ZTN controller 101 determines that the second ZTN device 104 is unavailable, the ZTN controller 101 optionally can configure a third ZTN device 202 of the system to repeatedly push the session information 105b to the second ZTN device 104. The third ZTN device 202 may also be called anchor device. Thereby, a function of the ZTN controller (e.g. a policy decision function) is partially outsourced to the third ZTN device 202. Optionally, the ZTN controller 101 configures the third ZTN device 202 to repeatedly push the session information 105b to the second ZTN device 103 before the ZTN controller 101 becomes unavailable. This might e.g. be the case if the ZTN controller 101 has to be shut down due to low battery power, or if it is detected (based on low signal strength) that the ZTN controller 101 is going to leave a wireless network connecting in to the second ZTN device 104 and the third ZTN device 202. In particular, the session information 105b is stored in the third ZTN device 202 for repeatedly pushing it to the second ZTN device 104. As it is further illustrated in FIG. 2, the session information 105b which is stored in the third ZTN device 202 may e.g. be encrypted with a public key 203. The public key 203 e.g. corresponds to the second ZTN device 104, that is, it is stored in the second ZTN device 104 and is provided for signing the session information 105b.

FIG. 3 illustrates an operating scenario of the system 100 in which the ZTN controller 101 (labelled “SDP controller” in FIG. 3) is occasionally unavailable. As illustrated, the ZTN controller 101 is comprised by an Access Controller, which e.g. runs on a mobile phone. In this scenario, the mobile phone running the Access Controller might be switched off or might go out of a network range. That is, the ZTN controller 101 can be unavailable when the first ZTN device 103 (also labelled “loTl” in FIG. 3) tries to establish a ZTN session 102 with the second ZTN device 104 (also labelled “IoT2” in FIG. 3). To remedy the non-availability of the ZTN controller 101, the first ZTN 103 device and the second ZTN device 104 can be modified to support conditional re-use of the last known communication settings of a given session. Connection state persistency is thus added to the first and second ZTN device 103, 104. In other words, the ZTN session 102 between the first ZTN device 103 and the second ZTN device 104 is based on session information 105a used for a previous ZTN session. That is, a last session (which comprises already allocated connection settings and credentials) can be re-established on application demand. An aging policy associated with the last session (e.g. as a part of session credentials provided by the ZTN controller 101) may allow to limit a number of re-uses and/or a re-use time period. In other words, the first ZTN device 103 can establish the ZTN session 102 between the first ZTN device 103 and the second ZTN device 104 based on a re-use limit 201a, 201b.

In the following, the operating scenario shown in FIG. 3 is going to be described in detail: In step 311, e.g. in response to an input of a user 307 an application 305a (possibly identified by an application identifier “AppID”) running on the first ZTN device 103 sends a request to the ZTN controller 101 in order to establish a ZTN session 102 with a corresponding application 305b (labelled “Service” in FIG. 3) of the second ZTN device 104. However, the ZTN controller 101 cannot be reached, and no policy can be decided from policies 301 by the ZTN controller 101. If the ZTN controller 101 would be available, in step 312 session information 105 comprising a decided policy would be transmitted to a ZT client 302a in the first ZTN device 103. Further, if the ZTN controller 101 would be available, in step 313 session information 105 comprising a decided policy would also be transmitted to a ZT client 302b in the second ZTN device 104. However, due to the absence of the ZTN controller 101, these steps cannot be performed and session information 105 cannot be provided as requested. To remedy the nonavailability of the ZTN controller 101, session information 105a which was used for a previous ZTN session between the first ZTN device 103 and the second ZTN device 104 can be used again. This session information is e.g. read by the ZT Client 302a, respectively by the ZT Client 302b from a connection state persistent storage in the first ZTN device 103, respectively in the second ZTN device 104. Then, in step 314, an SPA controller 303a, a ZT Gateway 304a and wireless communication means 306a of the first ZTN device 103, as well as an SPA controller 303b, a ZT Gateway 304b and wireless communication means 306b of the second ZTN device 104 establish the ZTN session 102 based on the session information 105a which was used for a previous ZTN session.

FIG. 4 illustrates an operating scenario of the system 100 in which the second ZTN device 104 (labelled “IoT2” in FIG. 4) is occasionally unavailable. As illustrated, during establishment of the ZTN session 102, the ZTN controller 101 (labelled “SDP controller” in FIG. 4) provides session information 105b (e.g. comprising connection settings and credentials for running a secure P2P session) to the second ZTN device 104.

However, this procedure fails as the second ZTN device 104 is not available during the time of session initiation. To remedy the non-availability of the second ZTN device 104, the ZTN controller 101 can implement session states to allow for repetitive pushing (re-update) of session settings (i.e. the session information 105b) to the second ZTN device 104, after it is available again. For this purpose, the ZTN Controller 101 can be equipped with a state repository 308. In case that the second ZTN device 104 isn’t available at the time of initiation of the ZTN session 102, the ZTN controller 101 can save settings for further re-deployment after the second ZTN device 104 reconnects again. In other words, session information 105b is repeatedly pushed to the second ZTN device 104, until the second ZTN device 104 is available again.

In the following, the operating scenario shown in FIG. 4 is going to be described in detail: In step 411, e.g. in response to an input of a user 307, an application 305a (e.g. a temperature sensing application, indicated by the thermometer in FIG. 4, e.g. identified by an application identifier “AppID”) running on the first ZTN device 103 (labelled “loTl” in FIG. 4) sends a request to the ZTN controller 101 in order to establish a ZTN session 102 with a corresponding application 305b running on the second ZTN device 104. The request for initiating a ZTN session 102 reaches the ZTN controller 101, and a policy can be decided from policies 301 by the ZTN controller 101. In step 412, session information 105b comprising a decided policy is transmitted to a ZT client 302a in the first ZTN device 103. Further, in step 413 the ZTN controller 101 attempts to send session information 105b comprising a decided policy to a ZT client 302b in the second ZTN device 104. However, due to the absence of the second ZTN device 104, step 413 cannot be completed and session information 105b cannot be provided as requested. To remedy the non-availability of the second ZTN device 104, the ZTN controller 101 repeatedly pushes session information 105b to the second ZTN device 104. Once the second ZTN device 104 becomes available again, the session information 105b is received by the ZT Client 302b in the second ZTN device 104. Then, in step 414, an SPA controller 303a, a ZT Gateway 304a and wireless communication means 306a of the first ZTN device 103, as well as an SPA controller 303b, a ZT Gateway 304b and wireless communication means 306b of the second ZTN device 104 establish the ZTN session 102, in particular based on the session information 105b which was repeatedly pushed to the second ZTN device 104.

FIG. 5 illustrates an operating scenario of the system 100 in which the second ZTN device 104 (labelled “IoT2” in FIG. 5) is occasionally unavailable and the ZTN controller 101 (labelled “SDP Controller” in FIG. 5) becomes unavailable before the second ZTN device 104 reconnects. That is, after the second ZTN device 104 reconnects, the ZTN controller 101 cannot push the session information 105b to the second ZTN device 104. To remedy the nonavailability of the ZTN controller 101, the ZTN controller 101 can push refresh packs to an anchor device (e.g. a third ZTN device 202 that is connected before the ZTN controller 101 becomes unavailable, and can serve as a relay for information provided by the ZTN controller 101, after the ZTN controller 101 is disconnected). In other words, the ZTN controller 101 can configure a third ZTN device 202 (in particular before the ZTN controller 101 becomes unavailable) to repeatedly push the session information 105b to the second ZTN device 104 (once the ZTN controller 101 is unavailable). Then, the third ZTN device 202 monitors availability of the disconnected second ZTN device 104 (e.g. by listening to re-connect DHCP request or by pinging its known IP address) and pushes session information 105b (e.g. encrypted with a public key 203 of the second ZTN device 104 to avoid eavesdropping or altering of the session information 105b) prepared by the ZTN controller 101 to the second ZTN device 104 after the second ZTN device 104 reconnects. In particular, the session information 105b might only be relayed in the third ZTN device 202 for a predefined period of time (that is, based on a re-use limit 201a, 201b).

In the following, the operating scenario shown in FIG. 5 is going to be described in detail: In step 511, e.g. in response to an input of a user 307 an application 305a (e.g. identified by an application identifier “AppID”) running on the first ZTN device 103 (labelled “loTl” in FIG. 5) sends a request to the ZTN controller 101 in order to establish a ZTN session 102 with a corresponding application 305b (labelled “Service” in FIG. 5) running on the second ZTN device 104. The request for initiating a ZTN session 102 reaches the ZTN controller 101, and a policy can be decided from policies 301 by the ZTN controller 101. In step 512 session information 105b comprising a decided policy is transmitted to a ZT client 302a in the first ZTN device 103. However, the ZTN controller 101 becomes unavailable before it could push the session information 105b also to the second ZTN device 104, which would normally be done in step 514. To remedy for the non-availability ofthe ZTN controller 101, in step 513 (that is, before the ZTN controller 101 became unavailable), the ZTN controller 101 configured a third ZTN device 202 (which is e.g. running on a smart TV, as illustrated in FIG. 5) to repeatedly push the session information 105b to the second ZTN device 104. In particular, the session information 105b is stored in a storage 504 in the third ZTN device 202 for repeatedly pushing the session information 105b to the second ZTN device 104. Once the second ZTN device 104 is available again, in step 515 the session information 105b is immediately received by the second ZTN device 104, which can establish the ZTN session 102 with the first ZTN device 103 without further interruption. Then, in step 516, an SPA controller 303a, a ZT Gateway 304a and wireless communication means 306a of the first ZTN device 103, as well as an SPA controller 303b, a ZT Gateway 304b and wireless communication means 306b of the second ZTN device 104 establish the ZTN session 102, in particular based on the session information 105b which was repeatedly pushed to the second ZTN device 104. Thus, availability of the ZTN is increased. The third ZTN device 202 in particular comprises an application 501, and SPA controller 502 and an SDP gateway 503, which at least partly contribute to the receiving, storing and repeatedly pushing of the session information 105b.

FIG. 6 schematically illustrates a structure of the ZTN controller 101 according to an embodiment of the present invention. In FIG. 6, the ZTN controller 101 is operated by a hardware device 601 (e.g. a server device, preferably a consumer device). The ZTN controller 101 can however also comprise the hardware device 601.

As illustrated in FIG. 6, the ZTN controller 101 comprises a flow controller (FC) 602. To handle timeout exceptions of ZTN devices 103, 104 (e.g. that a ZTN device 103, 104 is unavailable and isn’t accepting session initiation command), the FC 602 can save session information 105b in a persistent cache for further periodic retries. A kill time stamp (e.g. a re-use limit 201a, 20ab) can be attached to the command to enable aging policies. The FC 602 can periodically poll a states cache in order to retrieve commands for retry and to clean outdated states. To handle the case of occasional disconnection of the ZTN controller 101, the FC 602 can perform replication of undelivered commands in anchor devices (e.g. the third ZTN device 202). The FC 602 can interact with an anchor discovery engine 604 and push all undelivered commands to the anchor device for further delayed delivery. Packed commands can be protected (e.g. encrypted & signed with SHA, etc.) using a public key 203 and can be provided with an attached policy, specifying a relay latency and a number of retries per command. The ZTN controller 101 can communicate with a session states cache 603, which can store commands and related settings that could not be completed (including a command ID, a client IP, an ID, a session port, a key, a token, an access policies, a number of retries, a timeout, an aging period) and support their retrieval, update and removal.

The ZTN controller 101 can also communicate with an anchor discovery engine (ADE) 604, a module that can be used for discovery of anchor devices which can communicate with a first ZTN device 103 or a second ZTN device 104 and can deliver a command pack (e.g. session information 105b) on behalf of the ZTN controller 101. A command pack can be handled by the anchor device as a binary pack, which is to be delivered. The ADE 604 will maintain an updated map of network devices, network relations between them as well as technical characteristics, such as a devices network proximity, memory capacities of a pack storage of a device, CPU utilization, or battery level, to allow for optimal selection of an anchor device for command propagation.

A communication stack 605, which is available to the ZTN controller 101 can be updated to support retrying sending session information 105 towards ZTN device 103, 104 (e.g. as logical application level retry); to support pushing a command pack to an anchor device; to send anchor device discovery multicast messages (e.g. on SNMP Port 161, to get MIB2.ID, MIB2. Capabilities, etc.); and to send anchor device discovery response messages (e.g. SNMP Response IoT_Lights_123, Anchor, Free Cache = 100 commands, etc.).

FIG. 7 schematically illustrates a structure of a ZTN device 701 according to an embodiment of the present invention. The ZTN device 701 e.g. can be the first ZTN device 103, the second ZTN device 104, or the third ZTN device 202.

The ZTN device 701 also can comprise an FC 702, e.g. to handle non-availability of the ZTN device 701 or the ZTN controller 101. In case that the ZTN controller 101 is unavailable at a time of session establishment, the ZTN device 701 can re-use session settings (keys, tokens, access policies, etc.) provided by the ZTN controller 101 for the last session with an appropriate peer. In other words, it can use session information 105a used for a previous ZTN session between the first ZTN device 103 and the second ZTN device 104. Session settings (e.g. session information 105a) can be stored in a session state cache 705 and can be re-used in case that the ZTN device 701 is unavailable during session initiation. Session settings can be valid only for a re-occurring session with a same device & service/application. Session age parameters can be checked before re-use and removed if an aging period or number of reuses is expired. The session state cache 705 stores settings of a last session for further re-use. A state can be saved or refreshed on every successful ZTN session 1024 establishment. The session state cache 705 can support session settings persistency, retrieval, update and purge.

The ZTN device 701 also can comprise an anchor tasks manager (ATM) 706, which manages command propagation. It can store command packs (e.g. session information 105b) to deliver them to currently unavailable targets (e.g. the first or second ZTN device 103, 104). Command packs can be stored in an anchor pack cache 707. A pack (e.g. session information 105b) can contain encrypted commands augmented by appropriate propagation policies (including a number of retries, a timeout setting, aging, etc.). The ATM 706 can periodically check packs and retry to deliver them to the targeted ZTN devices 103, 104. A pack can be pushed towards a peer target (e.g. the first or second ZTN device 103, 104) and be removed from the repository after a confirmation of successful delivery.

The ZTN device 701 also can comprise an anchor pack cache 707, a part of the ZTN device 701 allowing pack storage and retrieval upon demand. The anchor pack cache (also called repository) can be secured using available securing techniques (e.g. encrypted using a device master key), can be limited in size and optimized to preserve power/performance as well as memory wear out.

The ATM 706 and the anchor pack cache 707 in particular ensure that the ZTN device 701 can act as a third ZTN device 202.

Further, an SDP Gateway 703 and a communication stack 704 are available to the ZTN device 701 which enable retry and propagate commands, in particular for relayed session control and refresh command propagation. The communication stack 704 also supports anchor discovery request and response commands; to respond to ZTN controller 101 anchor discovery requests (e.g. to listen to a known port and respond to a known command); to query a targeted ZTN device 103, 104 for availability (e.g. to listen to a wakeup message from the target, or to ping a known port); or to push a pack to a target ZTN device 103, 104 (e.g. using a statically or dynamically allocated port, or a protocol). FIG. 8 schematically illustrates an operating scenario of a ZTN, in particular comprising a ZTN controller 101, a first ZTN device 103 and a second ZTN device 104.

Steps 801 to 809 illustrate regular session establishment between a first and a second ZTN device 103, 104. In step 801 the first ZTN device 103 sends a request for establishment of a ZTN session 102 (e.g. a “Service request”) to the ZTN controller 101. In step 802 the ZTN controller evaluates a policy, which in step 803 is going to be provided to the first ZTN device 103, comprised by session information. The first ZTN device 103 prepares its gateway accordingly in step 804. In step 805, the policy is also provided to the second ZTN device 104, comprised by session information. The second ZTN device 104 prepares its gateway GW accordingly in step 806. In step 807, the ZTN session 102 between the first ZTN device 103 and the second ZTN device 104 is started. In step 808, the second ZTN device 104 prepares a service 305b. In step 809, the first ZTN device 103 and the second ZTN device 104 communicate with each other.

The operating scenario of FIG. 8 in particular also relates to controller-less session establishment, which includes the following steps: In step 810 the first ZTN device 103 sends a request for establishment of a ZTN session 102 (e.g. a “Service request”) to the ZTN controller 101. The ZTN controller 101 however is not available, see step 811. Thus, in step 812, the first ZTN device 103 obtains a timeout. In step 813, session information 105a used for a previous ZTN session between the first ZTN device 103 and the second ZTN device 104 is obtained by the first ZTN device 103, and its gateway is prepared accordingly in step 814. The first ZTN device 103 requests the second ZTN device 104 to establish a ZTN session 102 in step 815. Before establishing the ZTN session 102 with the first ZTN device 103, also based on the session information 105a used for a previous ZTN session, the second ZTN device 104 checks, in step 816, if the ZTN controller really is not available. A timeout is obtained in step 817, and in steps 818 and 819 the second ZTN device 104 determines, that the ZTN controller 101 really is not available. In step 820, the second ZTN device 104 prepares its gateway (based on the session information 105b, used for a previous ZTN session) and sends an acknowledgement to the first ZTN device 103 in step 821. In step 822, the ZTN session 102 between the first ZTN device 103 and the second ZTN device 104 is started. In step 823, the second ZTN device 104 prepares a service 305b. In step 824, the first ZTN device 103 and the second ZTN device 104 communicate with each other. The third ZTN 202 is not required for the above described operating scenario. FIG. 9 schematically illustrates an operating scenario of a ZTN, comprising a ZTN controller 101, a first ZTN device 103, a second ZTN 104 device and a third ZTN device 202. FIG. 9 in particular relates to delayed command propagation, that is the indirect pushing of session information 105b to the first ZTN device 103 by means of a third ZTN device 202 (e.g. an “anchor device”).

In step 901, the ZTN controller 101 discovers anchor capabilities (that is, the ability of a ZTN device to act as an anchor device) by sending discover requests to the second ZTN device 104 and the third ZTN device 202. The ZTN controller discovers that the third ZTN device 202 can act as an anchor device. In other words, the ZTN controller 101 runs periodic anchor discovery and maintains an updated map of anchors and their capabilities. In step 902, session information 105 is provided to the second ZTN device 104. In step 903, session information 105 is provided to the first ZTN device 103. In step 905, the second ZTN device 104 prepares its gateway according to the received session information 105. The first ZTN device 103 however is not available any more (see step 906), which is why a timeout is obtained at the ZTN controller in step 907. In step 908, the ZTN controller 101 configures the third ZTN device 202 to repeatedly push session information 105b to the first ZTN device 103 or the second ZTN device 104. Figure 9 shows that the session information is pushed to the first ZTN device 103. However, as the following explain, the session information may be pushed to the second to the second ZTN device 104. To this end, session information 105b is provided to the third ZTN device 202 and is stored in its anchor pack cache. In other words, a pack containing an undelivered command accompanied by aging policy is created, and pushed to the anchor device for further delivery in a case when the ZTN controller isn’t connected. In step 912, the session information 105b (i.e. the retrieved pack) is now repeatedly pushed to the first loT device 103 or the second loT device 104, and/or the session information 105b is pushed to the first ZTN device 103 or the second ZTN device 104, in particular after the first ZTN device 103 wakes up (step 910) or the second ZTN device 104 wakes up and provides signs of life in particular to the third ZTN device 202 (step 911) e.g. by a multicast message. Once the first ZTN device 103 or the second ZTN device 104 receives the pushed session information 105b, it checks if the ZTN controller 101 really is unavailable (step 913). In other words, the first ZTN device 103 or the second ZTN device 104 checks availability of the ZTN controller 101 and applies the pack only in case that the ZTN controller 101 is unavailable. It will also check aging settings before. In case that the ZTN controller 101 is available, the pack will be dropped. It can happen that the same pack is already provided or will be provided by the ZTN controller 101, so there is no need to handle a less trusted command from the anchor device. In step 914, the first ZTN device 103 or the second ZTN device 104 obtains a timeout and validates the session information 105b in step 915. In step 916, the gateway of the first ZTN device 103 or the second ZTN device 104 is prepared, while in step 917 an acknowledgement is sent to the third ZTN device 202, which in response removes the pack (that is, the session information 105b) from its cache (step 918). In other words, in any case, after receiving the pack, the targeted ZTN device 103, 104 will confirm its acceptance and will cause the removal of the pack from the cache of the anchor device. In step 919, the ZTN session 102 between the first ZTN device 103 and the second ZTN device 104 is started. That is, after applying a delayed command, the first ZTN device 103 will prompt the second ZTN device 104 about readiness or the second ZTN device 104 will prompt the first ZTN device 103 about readiness. In step 920, the second ZTN device 104 or the first ZTN device 103 prepares a service 305b. In step 921, the first ZTN device 103 and the second ZTN device 104 communicate with each other.

FIG. 10 shows a schematic view of a method 1000 according to an embodiment of the present invention. The method 1000 is for increasing availability of ZTN devices 101, 103, 104, and comprises a steps of establishing 1001, by a ZTN controller 101 of a system 100, a ZTN session

102 between a first ZTN device 103 of the system 100 and a second ZTN device 104 of the system 100, based on session information 105. The method 1000 further comprises a step of, if it is determined, by the system 100, that one of the ZTN controller 100, the first ZTN device

103 or the second ZTN device 104 is unavailable, establishing 1002, by the system 100, the ZTN session 102 between the first ZTN device 103 and the second ZTN device 104, based on session information 105a used for a previous ZTN session between the first ZTN device 103 and the second ZTN device 104, and/or by repeatedly pushing session information 105b to the first ZTN device 103 or the second ZTN device 104.

The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed disclosure, from the studies of the drawings, this disclosure, and the independent claims. In the claims as well as in the description, the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

1. A system (100) for increasing availability of zero trust network, ZTN, devices (101, 103, 104), wherein the system (100) comprises a ZTN controller (101), configured to establish a ZTN session (102) between a first ZTN device (103) of the system (100) and a second ZTN device (104) of the system (100) based on session information (105); wherein the system (100) is configured to, if it is determined, by the system (100), that one of the ZTN controller (101), the first ZTN device (103) or the second ZTN device (104) is unavailable, establish, by the system (100), the ZTN session (102) between the first ZTN device

(103) and the second ZTN device (104) based on session information (105a) used for a previous ZTN session between the first ZTN device (103) and the second ZTN device (104), and/or by repeatedly pushing session information (105b) to the first ZTN device (103) or the second ZTN device (104).

2. The system (100) according to claim 1, further configured to, if it is determined, by the first ZTN device (103), that the ZTN controller (101) is unavailable, establish, by the first ZTN device (103), the ZTN session (102) between the first ZTN device (103) and the second ZTN device (104) based on the session information (105a) used for the previous ZTN session between the first ZTN device (103) and the second ZTN device (104).

3. The system (100) according to claim 2, wherein the session information (105a) used for the previous ZTN session between the first ZTN device (103) and the second ZTN device (104) was obtained from the ZTN controller (101).

4. The system (100) according to claim 2 or 3, wherein the session information (105) further includes a re-use limit (201a, 201b), and wherein the first ZTN device (103) is further configured to establish the ZTN session (102) between the first ZTN device (103) and the second ZTN device (104) based on the re-use limit (201a, 201b).

5. The system (100) according to any one of claims 2, 3 or 4, wherein the second ZTN device

(104) is further configured to only establish the ZTN session (102) with the first ZTN device (103) based on the session information (105a) used for the previous ZTN session, if it is determined, by the second ZTN device (104), that the ZTN controller (101) is unavailable.

27

6. The system (100) according to claim 1, further configured to repeatedly push session information (105b) to the second ZTN device (104), if it is determined, by the ZTN controller (101), that the second ZTN device (104) is unavailable.

7. The system (100) according to claim 6, wherein the ZTN controller (101) is further configured to repeatedly push session information (105b) to the second ZTN device (104) directly, if it is determined, by the ZTN controller (101), that the second ZTN device (104) is unavailable.

8. The system (100) according to claim 7, wherein the ZTN controller (101) is further configured to, if it is determined, by the ZTN controller (101), that the second ZTN device (104) is unavailable, configure the first ZTN device (103) to repeatedly send a request for ZTN session establishment to the second ZTN device (104).

9. The system (100) according to claim 6, wherein the ZTN controller (101) is further configured to, if it is determined, by the ZTN controller (101), that the second ZTN device (104) is unavailable, configure a third ZTN device (202) of the system to repeatedly push the session information (105b) to the second ZTN device (104).

10. The system (100) according to claim 9, wherein the ZTN controller (101) is further configured to configure the third ZTN device (202) to repeatedly push the session information (105b) to the second ZTN device (103) before the ZTN controller (101) becomes unavailable.

11. The system (100) according to claim 9 or 10, wherein the ZTN controller (101) is further configured to store the session information (105b) in the third ZTN device (202) for repeatedly pushing the session information (105b) to the second ZTN device (104) by the third ZTN device (202).

12. The system (100) according to any one of claims 9 to 11, wherein the session information (105b) stored in the third ZTN device (202) is encrypted with a public key (203) corresponding to the second ZTN device (104).

13. The system (100) according to any one of claims 9 to 12, wherein the second ZTN device (104) is further configured to only establish the ZTN session (102) with the first ZTN device

(103) based on the received repeatedly pushed session information(105b), if it is determined, by the second ZTN device (104), that the ZTN controller (101) is unavailable.

14. A method (1000) for increasing availability of zero trust network, ZTN, devices (101, 103, 104), wherein the method (1000) comprises the steps of

- establishing (1001), by a ZTN controller (101) of a system (100), a ZTN session (102) between a first ZTN device (103) of the system (100) and a second ZTN device (104) of the system (100), based on session information (105);

- if it is determined, by the system (100), that one of the ZTN controller (100), the first ZTN device (103) or the second ZTN device (104) is unavailable, establishing (1002), by the system (100), the ZTN session (102) between the first ZTN device (103) and the second ZTN device

(104), based on session information (105a) used for a previous ZTN session between the first ZTN device (103) and the second ZTN device (104), and/or by repeatedly pushing session information (105b) to the first ZTN device (103) or the second ZTN device (104).

15. A computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the steps of the method (1000) according to claim 14.