Security Challenges of Intent-Based Networking

Intent fulfillment.  The fulfillment phase translates high-level intents to low-level network objects following three stages: translation, compilation, and activation.

Translation.  Translation converts user-defined intents into network-level intents. Translation allows non-expert users to simply define their desired goals using a human language or a declarative language, and IBN can leverage natural-language processing (NLP) or a domain-specific compiler to accomplish this task.

Compilation.  Compilation transforms network-level intents into network objects, which include abstractions such as device configuration information, forwarding rules in the data plane, and network topology. To bridge the gap between users and network behaviors, the IBN controller uses the network-level intents and a global network view to calculate viable forwarding rules that could satisfy the requirements. For example, in Figure 2, the IBN controller calculates all paths between the marketing team’s hosts and the database hosts by referring to group information and the underlying network topology.

Activation.  Activation implements and realizes the network objects in the underlying network devices. Activation can be delegated to the existing responsible system, such as an SDN controller.

In Figure 2, the activation stage controls network devices by sending flow (forwarding) rules on software switches (for example, switches S1 and S2), changing configurations of devices (for example, the load balancer LB), and executing remote commands. Activation may also modify the executable code present on programmable devices (for example, a programmable data-plane configuration implemented by the data plane programming language P4). For any errors, such as a flow table overflow, the IBN controller will return the error message to the compilation stage to recompile an intent from which the object originated.

Intent assurance.  Once an intent has been fulfilled, IBN continues with a goal of continuous assurances that the network performs as expected. Such assurances enable greater insight capabilities to proactively optimize and suggest network improvements to the operator. The assurance phase consists of three stages: observation, verification, and optimization.

Observation.  Observation enables the construction of a centralized and global view of the network. Such observation occurs by periodically monitoring the network and synchronously receiving any messages from network devices. One goal from observation is to measure the network’s performance to detect possible degradations. For instance, a switch in Figure 2 might experience a traffic bottleneck; depending on configuration, the switch may proactively notify the IBN controller or the IBN controller may reactively detect such traffic conditions.

Verification.  Verification confirms whether given intents are correctly implemented. If the IBN controller determines that an intent is not activated correctly after observation, the intent can be re-compiled with new parameters.

For instance, if there are two intents that compile down to flow rules that use the same matching fields (for example, a TCP/IP 5-tuple) but that implement different actions (for example, forward traffic on a particular port) on the same switch, the traffic may match successfully with the low-priority intent before such a match is checked against the high-priority intent. That distorts the goal of the high-priority intent taking the highest priority.

To avoid such situations, the IBN controller can choose a new path for the low-priority intent. Additionally, whenever the network state changes (for example, link failure), the verification process can help select affected intents for re-compilation and assess the effectiveness of given intents using the network statistics gathered during observation.

Optimization.  Optimization summarizes network behavior and recommends suggested improvements. When an issue occurs in traditional networks, operators attempt to understand the root causes of the issue using a set of primitive tools (for example, ping, traceroute, and iperf) and check that the individual device configurations are implemented as expected. Such an approach does not scale well for large networks and is subject to human error and misinterpretation.^a

IBN summarizes the network’s current status and reports key findings, which reduces the manual effort required to diagnose or improve network configuration. For instance, in Figure 2, the IBN controller reports to a network operator that 80% of the traffic destined to the load balancer LB via switch S1 comes from host C. Optimization can also automatically produce recommendations and subsequently implement them. An IBN-based network can learn from such summaries and suggest new intents. For instance, in Figure 2, the IBN controller suggests a new 300Mbps bandwidth constraint that the network operator can implement or that the IBN controller implements automatically on the operator’s behalf. The overarching goal of optimization is to reduce operational costs and improve the network’s utilization, reliability, and security.

Attacking intent compiler trust.  Faithfully translating intents into forwarding rules crucially depends on a unique component in IBNs: the compiler. Software bugs in the compiler can cause not only syntactic errors that are usually visible to users with a system failure, but also semantic errors that often do not cause any crash and instead result in violating the integrity of how the network should operate (T1).

Semantic errors in IBN can cause two types of misbehaviors that attackers can exploit: a desired intent is not implemented in the network, or an undesired intent is implemented. To resolve the former case, the verification stage should validate the installed intents. However, since there is no general sound and complete algorithm for the verification problem, practical verifiers often focus on soundness, which means they are incomplete.

Attacking intent composability.  Intents can partially or fully overlap with one another with respect to their reachability, bandwidth, and temporal properties (T2). As a result, IBN may be able to fulfill multiple intents when considered in isolation, but the network may not be able to meet the intended properties when combined. That could result in a denial of service attack against network availability.

Figure 3 shows an example that violates intent composability. While an alternative path exists for either intent to use S₁₃ in the route between both sides of the network topology, the IBN controller selects the same path for both intents. That causes a bottleneck in S₁₂ that could have been avoided with proper composability.

Conflicts among intents can be exceedingly hard to avoid. Intent APIs are often quite expressive and sometimes leverage a natural language. While composition tools^3,29,31 can synthesize specific types of intents, they require domain-limited, structured inputs such as graphs or regular expressions. If users’ intents cannot be represented in such formats, IBNs cannot apply these tools to resolve their conflicts.

Complicating this matter are dynamic functions in translation or compilation stages that evolve over time. Unlike predefined types of intents, it might be infeasible to even define a conflict for intents with new conditions and parameters created by these functions.

Finally, the multi-tenant nature of IBN makes composition a challenging security problem because composition conflicts and vulnerabilities can arise among different tenants’ priorities. For instance, a malicious tenant may infer information about network utilization or other tenants’ intents depending on carefully crafted intents that the malicious tenant attempts to install (T3).

Attacking intent linearity.  New intents may also trigger “side intents” when combined with existing intents (T4). A side intent is traffic that is implicitly allowed but does not exist in any of the intents individually. Side intents allow attackers to escalate their access privileges to violate availability policies.

Figure 4 shows a violation of intent linearity. The first and the second intents try to permit only the marketing team (MKT) to connect to the database (DB). The third intent tries to allow guests to access the customer service team (CST) via a NAT middleware box (NAT). Data-plane attackers can launch link-flooding attacks¹⁸ to congest targeted links such as (S₂₂, S₃₃) and (S₂₁, S₃₄). When the (S₂₂, S₃₃) link fails, traffic from MKT to DB must go through S₃₂. Similarly, when the (S₂₁, S₃₄) link fails, traffic from guests to CST must also go through S₃₂. Finally, the guest attackers can leverage the two intents’ behaviors to access DB by sending a crafted packet that spoofs MKT as the source (T5). Since the implicit side intent that is exploited (that is, connectivity between S₃₁ and DB) is not explicitly visible in the flow table, it is difficult for network operators to detect such conditions.

Attacking intent granularity.  One of the classic principles of secure design is the principle of least privileges.³⁰ For IBN, this requires the finest granularity of intent possible to avoid allowing greater connectivity than desired. A coarse intent can affect the network in unexpected ways and allow undesirable communication (T6). Coarse intents can conflict with each another because they cover larger subsets of the traffic space. Coarse intents can arise either from operators implementing an under-specified (that is, over-provisioned) privilege policy or from the IBN controller incorrectly implementing the network’s compilation and activation mechanisms.

Figure 5 shows an example of an unintended consequence of a coarse intent that over-provisions privileges. If the network operator simply defines the intent to provide connectivity between the customer service team (CST) and a database (DB), any guest of the CST department may gain unauthorized access to the database (T7).

Exploiting application–intent interactions.  Modern network operating systems that use SDN allow for external network applications to extend the control plane’s functionality. In SDN, applications subscribe to events of interest so that the applications can consume and react to the events. For example, a Layer 2 forwarding switch application may subscribe to new packets coming from the data plane that have not matched existing forwarding rules, and the application may choose to install new forwarding rules in the data plane.

Similarly, network applications can subscribe to intent-related events via the IBN controller. That enables external network applications to install, reconfigure, remove, or observe intents. In such an environment, it is critically important to the overall network security posture for operators to be able to define the privilege model between intent applications and the IBN-enabled network.

The effects of granting privileges may not be obvious. For instance, an attacker who does not have permission to request intents may indirectly install intents by invoking cross-plane³⁴ network events to which the intent applications subscribe (T8). This leverages triggered events in the complex inter-dependencies among network objects and the event-driven nature of network operating systems.

Attacking activation conflicts.  Intents with different objectives can have conflicts in implementation. This can occur when the compiled forwarding rules overlap, or when competing network configurations in network devices cause unintended consequences (T9). When a new intent with a higher priority has a conflict with an existing intent, the IBN controller should recompile the existing intent and try to activate it in other ways. If there is no way to reconcile these conflicts, the IBN controller should notify operators as to the unfulfilled intents. Otherwise, allowing activation conflicts will result in violating integrity of existing intents.

IBN controllers may be exploited if they handle multiple intents with identical network objects. In such cases, deleting one of the intents or changing the network configuration may cause unwanted behavior. For example, in CVE-2021-38364, deleting one of two intents that shared the same flow rules violated the other intent’s integrity.

Attacking intent–forwarding rule consistency.  Intents should be consistent with underlying network specifications, such as devices’ configurations, any supported protocols, and the network’s topology. Given that IBN abstracts away such details from users, users may unintentionally request intents that are beyond the capabilities of the underlying network (T10).

Improper handling of unsupported intents by the IBN controller may cause adverse effects on data-plane behavior and control-plane processes. For example, in CVE-2022-29605, an IBN controller repeatedly attempted to install an intent’s IPv6 forwarding rules into legacy switches that did not support IPv6, which misleads a network operator by showing an in-progress state.

Moreover, intents should be consistent across network changes. For instance, in CVE-2022-24035, an installed intent did not respond properly to subsequent network changes, which could result in a denial-of-service attack when combining link-flooding attacks (T11). Such inconsistencies can be hard to resolve for non-specialists, given that the network’s details are more opaque to operators.

Attacking intent state correctness.  An intent’s state should correctly represent the current stage at a specific time and the outcome of the intent. However, if the intent state is inconsistent with the intent processing, it will mislead a network operator or the intent controller, which can be used to attack control plane processes (T12). For instance, in CVE-2022-29607, modifying an existing intent to have the same source and destination address showed that the intent was installed without any flow rule, even though it should have been a failure.

If the intent state is inconsistent with the intent processing, it will mislead a network operator or the intent controller, which can be used to attack control plane processes.

If an intent that is expected to be correctly installed shows an internal corrupted error state, adversaries can exploit this to attack IBN (T13). For example, in CVE-2022-29606, an intent could be corrupted with a large switch port number, which allowed an attacker to bypass any intent by assigning the large number to the host port.

Exploiting network degeneracy.  IBN should consistently verify network invariants, such as the absence of forwarding loops and black holes. While a large body of literature in network verification has focused on these invariants, IBN faces additional challenges because operators (and developers) must find causal relationships between intents and conditions that cause the network to degenerate into undesirable behavior and violate network correctness properties (T14). For instance, in CVE-2022-29608, a one-way intent generated a forwarding loop in certain network topologies, which made it difficult to track the origin.

Another set of network degeneracy conditions can be caused by invalid intents, such as a zero-bandwidth intent. Without proper logic to detect such intents, the IBN controller could spend unnecessary resources to process invalid intents or even install ineffectual network objects, which ultimately affects control plane and data plane performance (T15). For example, in CVE-2022-29607, one controller implementation allowed an intent with the same source and destination addresses to be installed.

Exploiting optimization trust.  While optimization can be useful for efficiently using all the resources of a network, undermining the information used in optimization can create security challenges. Optimization algorithms and those algorithms’ implementations must be correct and trustworthy to avoid introducing vulnerabilities. Attackers can exploit such vulnerabilities to influence network decision making or to achieve undesirable network conditions (T16).

In addition to the optimization code, the monitoring and telemetry data being observed must also be trustworthy (T17). That trustworthiness is derived in part from the trust placed on the underlying devices generating such data. IBN may use third-party sources, such as vendors that produce forwarding devices and developers that write software for network functions. An untrusted source can poison observed data, which can cause the optimization code to change the network in an undesirable fashion that is beneficial for an attacker.

Security-privileged intents.  To allow for flexible network policies, IBNs should provide new intent types and properties that represent diverse, expressive, and flexible security policies. Since these security-related intents will impact the whole network, IBN can enforce multi-level intents that differentiate such security-related intents from regular intents installed by third parties or individual users. While users can create and observe their intents, a security module (that is, reference monitor) within the IBN controller should manage security-related intents akin to user-space and kernel-space privileges in traditional host-based operating systems.

Secure intent composition.  During intent translation, IBNs can benefit from an additional secure composition layer to resolve intent composability. Although previous work has attempted to synthesize the diverse types of intents,^3,29,31 these tools often require complex inputs such as policy graphs or regular expressions. Secure composition tools should be able to automatically recognize side intents and coarse intents.

Access control and information flow control.  To tackle privilege-related challenges in IBN, new access-control and information flow-control mechanisms should be designed, similar to those used in various multi-user or multi-application environments (for example, host operating systems, mobile operating systems) but that take into account the unique security challenges posed by IBN.

IBN can benefit from a fine-grained, role-based access-control (RBAC) model to define permissions for each user. For example, one IBN implementation used in ONOS provides just three permissions (reading, writing, and event subscription) that provides an operator with nearly unrestricted control over all network intents. To further limit access, IBN should provide fine-grained controls that enable operators to only manage a subset of the overall intent space, similar to the concept of network slicing.

While ostensibly straightforward to implement, IBN introduces new challenges with RBAC because the mapping between intents and the underlying configuration (for example, flow rules, network protocols) must also follow the same access-control policy in spite of any optimizations (for example, multiple intents sharing the same underlying flow rules).

IBN can further construct intents to manage different intent spaces.⁵ In such a model, each user can create intents within their virtual network. Those intents are then composed and deconflicted at the whole-network scale. Even if duplicate forwarding rules exist for intents in different intent spaces (for example, a forwarding rule that tunnels traffic between regions), the whole-network view can reconcile these flow rules globally.

RBAC alone, however, may be insufficient for properly controlling access in IBN. Previous work has shown that SDNs are vulnerable to cross-app poisoning attacks in which a malicious application can indirectly trick a privileged application to manipulate the control-plane state shared by both applications.³³ Since IBNs also run applications that create intents and subscribe to intent-related events, IBN is also vulnerable to similar attacks.

To avoid such vulnerabilities, IBN design should incorporate an internal security framework that functions as a reference monitor while enforcing information flow control (IFC) among intent-related control-plane decisions. Such a framework would monitor all requests from both users and applications to create intents, intent-related events subscribed to by the applications, and the subsequent operations.

In short, IBN should not only provide a complete permission model for both network operators and applications, but also protect against confused deputy attacks that could leverage data dependencies among different intent applications and the intent–forwarding rule mappings.

Intent verification.  Although network verification has been studied within the networking community,^2,28 the intent semantics and the network invariants need to be verified for IBN. Beyond verifying intent semantics among diverse intents, IBN may need to verify intents which cannot be defined by one of known properties, such as smart functions that evolve during the intent lifecycle. Furthermore, IBN controllers can leverage incremental verification techniques to verify network invariants (that is, the absence of network degeneracy conditions) and pinpoint specific intents to blame if those invariants are violated. To avoid disclosing internal errors in processing intents, IBN must be able to distinguish the exposure of intent states depending on security levels. In addition, IBN should defend against the adversaries speculating the underlying network by probing with test intents.

Intent consistency.  Ensuring consistency between the control-plane intents and data-plane forwarding rules is complicated by asymmetric operations (for example, rules that are installed some time after the creation of intents) and network dynamics (for example, rules that change according to underlying network events). Such a consistency should not be viewed as an invariant, but rather as a property that is eventually correct.

For such a property to be useful, however, consistency must be achieved prior to network changes; otherwise, the network will be perpetually in an inconsistent state. Periodic monitoring is thus a possible approach to ensure intent consistency (for example, the intent cleanup function in ONOS), but additional work is needed to make such monitoring code fast and scalable in a large network. Backup intents can also be leveraged as a fail-safe mechanism to resolve inconsistencies within an IBN.