Conceptio › Archive › arXiv CS

arXiv CSopen access

Rethinking Software-Defined Networking Link Discovery with Dynamic Randomization

· arxiv_cs

arXiv CS · Papers · License: Open Access

Open Source ↗Direct PDF ↓

distributed-systems internet networking protocols

networking, internet, protocols, distributed systems

Rethinking Software-Defined Networking Link Discovery with Dynamic Randomization

arXiv:2609.14805v1 [cs.NI] 13 Sep 2026

Mingming Chen University of Texas at Dallas

Teryl Taylor IBM Research

Frederico Araujo IBM Research

Thomas La Porta The Pennsylvania State University

Trent Jaeger University of California, Riverside

Abstract

SDN centralization enables several services, including a network topology service that discovers the ground-truth layout of the network. Topology discovery is a critical function in both traditional networks and SDN, as it provides essential real-time information for efficient traffic routing. In traditional networks, this is typically accomplished using the standard Link Layer Discovery Protocol (LLDP) [15]. However, there is no standardized topology discovery protocol for SDN. As a result, many SDN implementations repurpose LLDP for convenience [7, 43], often without accounting for the unique security implications of SDN. Most open-source SDN controllers adopt the de facto OpenFlow Discovery Protocol (OFDP), which uses LLDP packets—or, in the case of hybrid networks that include both SDN and traditional switches, combines them with the Broadcast Domain Discovery Protocol (BDDP) [7,45]—to discover links. In addition, nine SDN discovery protocols derived from OFDP also depend on LLDP [12]. There has been a growing number of recent attacks targeting SDN discovery protocols across diverse attack surfaces. On the control plane, adversaries exploit real vulnerabilities—e.g., CVE-2024-46942 [36] and CVE-2024-46943 [37]—to inject malicious flow entries, enabling flow entry-induced, globalized topology poisoning attacks [12] (e.g., CVE-2024-37018 [35]). On the data plane, malicious hosts or switches exploit vulnerabilities [48] such as CVE-2016-2074 [34] and CVE2016-10377 [33] to intercept and relay LLDP packets, enabling localized topology poisoning attacks [6, 16, 21, 25, 30, 46]. These CVEs demonstrate that such vulnerabilities are real and actively exploited, yet the continued reliance on LLDP leaves existing discovery mechanisms exposed. Applying traditional LLDP to SDN is problematic because the discovery process in a traditional network relies on each switch forwarding source information to its neighbors using LLDP packets—a model designed for decentralized architectures. However, this assumption is unnecessary in SDN, where a centralized controller manages discovery and can utilize entirely different strategies. While LLDP is effective at discovering links in SDN, its standardized packet type and format unintentionally expose its link discovery purpose, making it

Software-defined networking (SDN) separates the control and data planes, enabling programmable, centralized network management. A core SDN service is topology discovery — a periodic process that identifies network links. However, our analysis of five open-source SDN controllers and ten discovery protocols shows that all remain vulnerable to at least one form of link-fabrication attack. The common root cause is their reliance on traditional Link Layer Discovery Protocol (LLDP) packets, whose static identifiers expose their discovery purpose and attract adversaries to exploit them. We propose C HAMELEON D ISC, a dynamic link-discovery protocol that simultaneously prevents and detects topologypoisoning attacks by eliminating this root cause. Our key insight is that an SDN controller can infer topology without embedding meaningful information in discovery packets. C HAMELEON D ISC removes targetable static LLDP signatures and employs a moving-target defense that combines decoy, obfuscation, and camouflage techniques instantiated dynamically at runtime to prevent topology poisoning and detect manipulation. We implement C HAMELEON D ISC on OpenDaylight and demonstrate effectiveness against all identifierbased topology-poisoning attacks. On a 252-link topology, median convergence is 1.37–4.53 s for legitimate link changes and 4.06 s for malicious relay detection, with 13.0 percentage points of additional mean CPU and negligible retained-heap difference. Across topologies up to 816 links, C HAMELEON D ISC provides a tunable security–performance trade-off; expanding discovery intervals reduces CPU and mapping-state at the cost of increased attack-detection latency.

Benjamin E. Ujcich Georgetown University

Introduction

Software-defined networking (SDN) decouples the control plane from the data plane, enabling centralized, programmable network management. This flexibility supports fine-grained control and global optimization across diverse environments, including network traffic sampling [13], cloud computing [51], data centers [50], and vehicular networks [18]. 1

vulnerable to link fabrication attacks (e.g., [6, 12, 21, 38, 46]). Designing a lightweight and secure SDN link discovery protocol to prevent a broad range of topology poisoning attacks remains a significant challenge. The decoupling of the control and data planes in SDN introduces vulnerabilities to information manipulation, exposing numerous attack vectors. Existing countermeasures [9, 21, 22, 46, 47] typically rely on known attack signatures and detect attacks only after they occur—often with substantial monitoring overhead [6, 16]. Among the ten SDN link discovery protocols we studied, only 3 incorporate security enhancements [8, 38, 39]. However, these either fail to prevent relay-based and newly discovered flow entry-induced topology poisoning attacks [6,12], or they are not fully compatible with SDN, as they require modifications to SDN switches. While cryptographic mechanisms can ensure message integrity, they do not prevent all forms of topology manipulation. Attacks such as relay-based or flow entry-induced topology poisoning do not alter packet content or fabricate discovery packets; instead, they exploit forwarding behavior. As a result, even with strong integrity guarantees, adversaries can still mislead the controller about the actual network topology. To address these challenges, we introduce C HAMELEON D ISC, a lightweight SDN link discovery protocol fully compatible with existing SDN architectures that, for the first time, prevents and detects all known topology-poisoning attacks exploiting static identifiers or discovery signatures in discovery packets [6, 9, 12, 21, 38]. Our key insight is that an SDN controller can infer topology without embedding meaningful information in discovery packets that can be abused by the attacker. C HAMELEON D ISC provides robust protection against a wide range of threats originating from diverse attack surfaces via orchestrating a three-role discovery ensemble: (1) DecoyType packets (LLDP/BDDP) lure adversaries targeting traditional discovery traffic; (2) MorphType packets randomize all fields, obfuscating discovery intent and blocking attacks that exploit static identifiers; and (3) CamoType (ARP/IP) packets blend with normal traffic to validate genuine connectivity and expose malicious switches capable of advanced packet analysis and manipulation. Crucially, our camouflage layer creates an inescapable dilemma for attackers: an attacker who manipulates normal data-plane traffic exposes themselves through network disruption, while attackers who avoid attacking the data plane inadvertently render their topology manipulation detectable. By cross-checking link inferences from these heterogeneous probes through multiple validations, the controller distinguishes legitimate link changes from fabricated ones, attributes inconsistencies to the responsible host, application, or switch, and updates topology only after consecutive, consistent confirmations. This strategy prevents adversaries from using the packets’ static identifier or discovery signature to persistently fabricate false links, effectively mitigating multiple attack vectors. More importantly, the dynamic obfuscated discovery packets preserve correct SDN topology discovery: because the

controller initiates the discovery packets and receives them after a one-link traversal, it can accurately recover the link source using a pre-stored mapping between the dynamically randomized packet and its true origin, and retrieve the link destination from metadata provided by the reporting switch. Implementing C HAMELEON D ISC is challenging for several reasons. First, constructing the discovery packet and selecting its type is critical to ensuring one-link traversal. Achieving this is non-trivial across different packet types. For obfuscated MorphType packets and camouflage packets, we must ensure that they exclusively match the lowest-priority table-miss entries on the corresponding switches, without being intercepted by higher-priority flow entries. Second, using camouflage ARP packets for verification requires avoiding interference with controller services (e.g., ARP Handler and Host Tracker). C HAMELEON D ISC therefore constructs CamoType probes using fresh, non-conflicting MAC/IP identities that mimic legitimate new-host arrivals and adds filters to ARP-related network applications. Third, generating randomized values for each field of the discovery packets in a time- and space-efficient manner requires careful consideration. Finally, realizing built-in detection without additional real-time monitoring is challenging, as it requires integrating prevention and detection within the lightweight discovery process. Our approach recognizes that link discovery in SDN environments differs fundamentally from traditional network architectures. C HAMELEON D ISC ensures compatibility with trending SDN southbound protocols (e.g., OpenFlow and P4-runtime), eliminating the need for additional monitoring systems or modifications to standard SDN switches. By comparison, existing defenses fall short in addressing all attack vectors. They require significant architectural modifications and add significant complexity caused by real-time monitoring or logic trees, resulting in higher resource consumption and reduced system efficiency. By focusing on the protocol’s inherent vulnerabilities, our approach overcomes these limitations. We summarize our contribution as follows: • We propose C HAMELEON D ISC, a dynamically randomized link discovery protocol that prevents and detects all known topology-poisoning attacks exploiting LLDPbased static identifiers, while remaining lightweight and fully compatible with existing SDN architectures. • We present a theoretical analysis of C HAMELEON D ISC’s resilience under adversarial conditions. With three-round validation, MorphType alone yields an expected randomguessing attack time of approximately 44 years, while CamoType provides an additional verification layer against adversaries that evade randomized discovery. • We implement C HAMELEON D ISC on OpenDaylight and evaluate its security, convergence, and performance. C HAMELEON D ISC defeats all four identifier-based topology-poisoning attacks as well as an advanced relay attack. On a 252-link topology, median convergence is 1.37–4.53 s for legitimate link changes and 4.06 s for ma2

controller as Step ➃. At Step ➄, the controller mistakenly believes the packet traveled from Switch A’s Port 2 to Switch C’s Port 1, thereby fabricating a non-existent link A2−1C. The core of topology poisoning attacks lies in misleading the controller into inferring incorrect link source (link-src) or link destination (link-dst) information. Since the link-src is extracted directly from the LLDP packet, fabricating it typically involves spoofing an LLDP packet with falsified source information. While such attacks can be mitigated by validating the integrity of LLDP packets, fabricating link-dst is more challenging to detect. The link-dst is determined by identifying the switch that returns the LLDP packets to the controller. Any method that causes LLDP packets to traverse multiple links can also lead to an incorrect link-dst inference. The example in Figure 1(b) demonstrates how a malicious application or backup controller can manipulate LLDP packet forwarding by injecting poisonous flow entries. Similarly, a malicious switch (e.g., Switch B) or hosts can intercept LLDP packets, filter them out, and relay or replay them to another switch (e.g., Switch C) to cause incorrect link-dst (e.g. A2 → 1C). Our proposed defense to mitigate Marionette and other attacks, called C HAMELEON D ISC, is shown in Figure 1(c), which we discuss in Section 4. The root cause of topology poisoning attacks that rely on static identifiers is as follows:

licious relay detection. Across topologies up to 816 links, C HAMELEON D ISC maintains bounded mapping state, and its discovery interval provides an explicit trade-off between detection latency and controller overhead.

Motivation and Background

OpenFlow is a standard SDN southbound protocol enabling a centralized controller to communicate directly with switches. Once the controller establishes a connection with the switches, it gathers essential switch hardware information and data statistics. The central controller periodically discovers the network topology as the basis for instructing switches on how to forward traffic. The controller can proactively install forwarding rules to all the connected switches—an approach known as proactive forwarding. SDN also supports a key feature called reactive forwarding: if an arriving packet does not match any existing flow entry that can forward it normally in the data plane, the table-miss flow entry sends this packet to the controller in a packet-in message. The de-facto OpenFlow Discovery Protocol (OFDP) uses packet-out and packet-in messages to carry LLDP packets for link discovery. However, because OFDP relies on static LLDP packets, it introduces vulnerabilities in the link discovery process, as programmable forwarding can be exploited.

2.1

The static fields of LLDP packets (e.g., the LLDP ether-type, which explicitly signals the discovery intent) are an easy target for attackers, who can spoof or exploit these fixed identifiers to manipulate packet forwarding via various attack surfaces.

Motivating Example

In Figure 1(a), we show how OFDP is used for link discovery normally. A controller composes an LLDP packet for Port 2 on Switch A (denoted LLDPA2 ) to detect the link originating from that port. In Step ➀, the controller issues Switch A a packet-out message containing LLDPA2 with action of instructing it to forward LLDPA2 via Port 2. The LLDPA2 packet has an ether-src value that matches the MAC address of Port 2 on Switch A. In Step ➁, the neighboring Switch B receives LLDPA2 on its Port 1. In Step ➂, finding no flow entry match, Switch B’s table-miss flow entry instructs the switch to forward the LLDPA2 packet back to the controller within packet-in message. In Step ➃, upon receiving this packet-in message, the controller knows the communication originally emanated from Switch A’s Port 2 (by parsing LLDPA2 ) and has now returned from Switch B’s Port 1 (by reading ingress field of packet-in), thus concluding a valid link A2−1B. Figure 1(b) shows how a recent flow entry-induced poisoning attack, called Marionette [12], can subvert this normal discovery process to fabricate links. If Marionette resides in a follower controller or an SDN application, it can install a malicious, higher-priority flow entry eB2 on Switch B. After Step ➁, because LLDPA2 has A2_mac as ether-src, it matches eB2 instead of the table-miss entry. As a result, Switch B forwards LLDPA2 out of Port 2 instead of returning it to the controller at Step ➂. Switch C, connected at that port, treats LLDPA2 as a table-miss packet and sends it back to the

We define four types of topology poisoning attacks below: Spoof-Based Topology Poisoning: A malicious host or switch can fabricate LLDP or packet-in that encapsulate LLDP, causing controller to infer incorrect link-src [21] or link-dst [9]. Replay-Based Topology Poisoning: A malicious host stores LLDP packets and replays them to another switch, causing the legitimate controller to infer a nonexistent link 1 [38]. Relay-Based Topology Poisoning: A malicious switch intercepts LLDP packets and relays them to another switch, causing the legitimate controller to infer a wrong link-dst [6]. Flow Entry-Induced Topology Poisoning: A malicious application or controller peer injects poisonous flow entries to override default entries to manipulate LLDP packet forwarding, causing the legitimate controller to infer a wrong link-dst [12].

2.2

Existing Defenses and Challenges

Existing OFDP implementations differ in packet encoding and forwarding rules, but all retain recognizable LLDP-based discovery identifiers (Appendix A). In addition to the efforts by open-source controllers discussed in Appendix A to 1 The link discovery discussed refers to switch-to-switch links.

(a) OFDP discovers a real link A2 → 1B

(b) Marionette [12] fabricates a link A1 → 1C

Figure 1: Motivating Example for C HAMELEON D ISC Table 1: Effectiveness of State-of-the-Art Countermeasures against Topology Poisoning Attacks Topo. Poisoning Attacks

Open-Source Controllers

Topology Poisoning Detections

Cause Attack Surface

Ryu Pox Flood ODL ONOS Authen. Port- Topo Latency Sphinx SPV sOFTDP SLDP TILAK C HAMELEON light -Based Based Guard -Based D ISC

Spoof

Mal-Host [21] Mal-Switch [9]

✗ ✗

✓ ✗

✓ ✓

✓ ✗

✓ ✓

✓ ✗

✓ ✓

Replay Mal-Host [38]

✗

✓

dyn. ✓ stat. ✗

✗

✓

Relay

Mal-Switch [6]

✗

✓

✗

✓

Flow Entry

Mal-App [12] ✗ Mal-Ctrl Peer [12] ✗

✗ ✗

✓ ✓

secure SDN topology discovery, researchers have proposed approaches aimed at topology poisoning detection and the development of secure SDN discovery protocols. Table 1 summarizes the effectiveness of existing countermeasures against various types of topology poisoning attacks.

Secure SDN Discovery Protocols

LLDP secrets, but reuse of Ethernet headers reveals packet intent, making them vulnerable to switch-spoofing, relaying, and flow entry–induced attacks. SLDP [38] introduces partial header randomization with token-based source MACs and flow entries tied to tokens. However, other static header fields remain recognizable and can still be exploited by malicious switches, controller applications, or peers to manipulate packet forwarding. TILAK [39] offers similar security scope by randomizing only ether-dst, and thus faces the same limitations as SLDP. S OFTDP [8] uses encryption and Bidirectional Forwarding Detection (BFD) but requires switch modifications and incurs high deployment cost.

Detection approaches primarily rely on known attack signatures and are therefore effective against previously identified topology poisoning attacks. For example, authentication-based schemes verify LLDP integrity to prevent spoofing and replay attacks, but offer limited protection against other vectors. Port-based verification [9, 16] assumes each active port should map to only one peer, catching spoof-based links but not others. Latency-based approaches [22, 47] infer fabrication by measuring anomalously high link latencies, particularly effective when hosts are involved. TopoGuard and TopoGuard+ [21, 46] track switch identities to defend against host-involved spoofing but do not address control plane misuse. A more advanced class of detection methods includes verification-based approaches, which aim to detect fabricated links by validating network state through auxiliary observations. The most capable solutions, such as SPHINX [16] and SPV [6], can detect most of the topology poisoning attacks. However, they suffer from scalability issues due to real-time monitoring on the data plane and fail to detect recent flow entry–induced topology poisoning attacks, as they overlook the control-plane attack surface [12].

Challenges: Preventing topology poisoning in SDN remains a significant challenge due to the architecture’s open and programmable nature. While centralized control offers powerful capabilities, such as global network visibility and real-time reconfigurability, it also introduces additional attack surfaces. Moreover, the inherent programmability of SDN expands the potential attack vectors. The growing diversity of topology poisoning attacks highlights a critical need: to maintain a secure and trustworthy topology view, the controller must operate under the assumption that no other network component, including hosts, switches, applications, or controller peers, can be fully trusted. Although several schemes mitigate specific attacks once the attack vector is identified, achieving comprehensive prevention remains difficult. Designing a mechanism that not only prevents topology poisoning but also

Prevention methods aim to harden the discovery protocol against tampering. Many controllers embed static or dynamic 4

detects ongoing manipulation—while remaining lightweight and SDN-compatible—poses an even greater challenge. A key distinction underlies this challenge: prevention versus detection. Prevention-oriented protocols harden the discovery process so attacks cannot succeed in the first place, while detection-oriented approaches monitor for anomalies after discovery has occurred. As Table 1 shows, existing secure SDN discovery protocols (e.g., SLDP, TILAK) focus on prevention but cannot detect ongoing manipulation, while detection approaches (e.g., SPHINX, SPV) react to anomalies but cannot prevent attacks from influencing the topology view in the first place. C HAMELEON D ISC is the first protocol to systematically combine defenses that prevent attacks during link discovery and detect manipulations that evade those preventative measures: a moving-target discovery process built on dynamic randomization of all discovery-packet fields blocks identifier-based attacks during discovery, while verification triggered on each link change event catches manipulations that bypass randomization.

Among these, the malicious switch is the most powerful: it has direct data-plane access, can manipulate any packet crossing it — not only those tied to specific flow entries or known discovery formats — and operates at hardware forwarding speeds that defeat latency-based detection. C HAMELEON D ISC’s defense layers scale with adversary capability — DecoyType and MorphType address host, control-plane, and switch attacks on static-identifier discovery packets, while CamoType is the additional layer to thwart an advanced malicious switch that redirects discovery packets outside the flow-entry mechanism or applies traffic analysis to randomized discovery packets. Adversary Knowledge. The adversary knows the full C HAMELEON D ISC design, including that discovery-packet fields are randomized using a cryptographically secure PRNG (§5.5), but not the generator’s private state. A malicious host observes only its own link, whereas a malicious switch may observe and tamper with all traffic traversing it, including tablemiss packets sent to the controller. A malicious application or controller peer may additionally observe packet-in events. We reasonably assume that no single compromised host/switch observes the majority of hosts, since hosts are distributed across access links and switches see only traffic traversing them. The trusted leader controller shares neither its PRNG state, the identity of future discovery probes, nor its private packet-tosource mapping with any other network component. Therefore, even after observing many packet-in/packet-out samples, an adversary lacking the private PRNG state cannot predict future randomized probe fields. A deployment that substitutes a weaker generator forfeits this guarantee.

Scope and Threat Model

Scope. C HAMELEON D ISC is a lightweight, SDN-compatible protocol for discovering the topology of pure OpenFlow networks while preventing and detecting topology-poisoning attacks2 . We cover topology-poisoning attacks that exploit static LLDP identifiers — including Spoof-, Replay-, Relay-, and Flow Entry-Induced attacks — as well as advanced attacks that identify discovery signatures through traffic analysis. Here, discovery signatures refers to recognizable packet types specifically used for link discovery; attacks that manipulate prevalent data-plane packet types for non-discovery purposes are out of scope. We assume that no flow entry matches solely on the incoming port (in_port): matching only on in_port provides coarse control, is rarely used in production, and contradicts SDN best practices [29, 41, 42]. We also assume SDNprevalent reactive forwarding [29, 31], meaning a table-miss entry is installed to send unknown packets to the controller.

Stealthy Adversary Assumption. Consistent with our focus on covert topology poisoning that leaves other services intact (§Scope), we impose two behavioral constraints. First, adversaries do not manipulate normal data-plane traffic (e.g., ARP or IP), as this disrupts operations and exposes their presence. Second, adversaries do not alter default flow entries such as the table-miss — not a limit on what a compromised switch can do, but on what a stealthy attacker will do: table-miss drives reactive forwarding, so overriding it stalls flow setup for every host behind the switch and produces controller-visible outages, and can further be locked by configuration [27, 28]. This does not exempt a stronger attacker who installs higher-priority rules to catch discovery packets; C HAMELEON D ISC defends against that case via field randomization and CamoType (§IV). The result is an inescapable dilemma regardless of privilege: disrupting normal forwarding risks exposure, while leaving it intact renders topology manipulation detectable.

Threat Model. We assume only the leader controller responsible for topology discovery is trusted. All other components are considered potentially compromised. These attacks may originate from malicious hosts [21, 38], applications or controller peers [12], or switches [6, 9]. Specifically, we assume: • A malicious host may analyze, fabricate, or replay discovery packets (e.g., LLDP) toward its connected switch. • A malicious application or controller peer may read topology, nodes, and flow entries, and write flow entries. • A malicious switch may inspect packets to recognize discovery packets (including randomized variants), forward such packets between switches with or without flow entries, and tamper with their corresponding packet-in messages.

C HAMELEON D ISC: Less is More

To defend against topology poisoning attacks that exploit static identifiers or discovery signatures [6, 9, 12, 21, 38], C HAMELEON D ISC addresses the root cause (§2.1) of these attacks in modern SDN discovery protocols. Our approach

2 Hybrid deployments with both traditional and OpenFlow switches are

outside the scope of this work.

is guided by three key insights.

gains the flexibility to select discovery packets from a wide range of packet types and fields while maintaining correct link inference, thereby eliminating the fundamental dependency on static identifiers that traditional LLDP-based protocols require and enabling security mechanisms to be naturally embedded in the discovery process.

Insight 1: SDN does not require informative discovery packets to reveal link-src for link discovery. In topology discovery protocols, a link is inferred when a packet sent from one switch port is received by another. In traditional distributed networks—where switches operate independently and maintain local topology state—each switch must self-identify in its LLDP packet via a Chassis ID and Port ID. This allows neighboring switches to record the connection and identify the link (Appendix B). By contrast, SDN’s centralized architecture gives the controller complete knowledge of all switches once controller–switch connections are established. Embedding explicit link-src information in discovery packets is therefore unnecessary and instead leaks sensitive details that attackers can exploit. We observe that neither the payload nor the header must reveal link-src. Because the controller acts as both sender and receiver of discovery packets, it can maintain a local mapping between each transmitted packet and its corresponding link-src. When a packet returns, the controller consults this mapping to recover the link-src, enabling accurate topology reconstruction without embedding sensitive information in the packet. We assign each link-src a distinct randomized packet, ensuring that returning packets map unambiguously back to their source. Recent work such as SLDP [38] notes that many LLDP fields are unnecessary in SDN and trims the format to an Ethernet header plus Chassis ID and Port ID. However, these fields remain sensitive: adversaries can still exploit them to spoof discovery packets and fabricate false links.

Insight 3: Existing defenses assume discovery packets must self-identify, inherited from distributed networks. Yet, centralized SDN architectures can remove this requirement, enabling fully controller-driven discovery. Prior approaches failed to fully exploit this architectural shift because they missed its key implication. SLDP introduces token-based MAC randomization for authentication but still relies on static identifiers, such as a fixed ether-type, to mark discovery packets. This dependency leaks a stable discovery signature, leaving SLDP vulnerable to relay-based poisoning by malicious switches and flow entry–induced poisoning by malicious applications or controller peers. SPV, in contrast, depends on the SDN controller to discover links and performs only post-hoc verification using IP probes. It reacts to link-change events reported by the controller—events derived from identifier-based LLDP discovery, and therefore can detect but cannot prevent topology-poisoning or proactively discover links. SPV also assumes a trusted control plane, making it unable to detect flow entry–induced poisoning launched by a malicious application or controller peer. Neither SLDP nor SPV recognizes or leverages the central insight: both preserve the legacy assumption that discovery packets must reveal their source identity and follow a fixed, wirerecognizable format. C HAMELEON D ISC discards this assumption entirely. It redefines SDN discovery as an information-free, dynamically evolving process that eliminates all static identifiers exploitable by adversaries, unifying prevention and detection within a single lightweight design that is capable of neutralizing all identifier-based topology-poisoning vectors. C HAMELEON D ISC prevents topology-poisoning attacks [6, 9, 12, 21, 38] by removing static identifiers that attackers can use to manipulate the discovery packet forwarding. As shown in Figure 1(c) (see page 3), with the ether-src randomized in a MorphType packet, eB 2 no longer matches the packet after Step ➁. Consequently, at Step ➂, Switch B behaves normally, returning the discovery packet to the controller due to the tablemiss. At Step ➃, the controller consults its mapping table to recover the link-src (A2), allowing the controller to identify the legitimate link A2 → 1B. CamoType packets use ARP to follow the same path for verification.

Insight 2: Dynamically randomizing all discovery-packet fields can preserve link discovery functionality while preventing information leakage, blocking static-identifier attacks, and enabling camouflage. As shown in Figure 1, static fields such as ether-dst, ether-src, and ether-type expose recognizable signatures that attackers can exploit to manipulate topology discovery. In traditional networks, discovery protocols rely on fixed packet formats and protocol-specific handling. In contrast, SDN provides an architectural advantage that C HAMELEON D ISC leverages to eliminate such vulnerabilities. We observe that reactive forwarding—a key capability of SDN—creates an opportunity to secure SDN discovery. In SDN, each switch installs a table-miss flow entry that forwards all unmatched packets, regardless of their headers, to the controller. This mechanism provides an opportunity for discovery packets to reach the controller after exactly one link traversal without relying on flow entries that match a static ether-type or other fixed header fields. Essentially, any discovery packet that triggers the table-miss rule after one-link hop can serve as a discovery packet. Consequently, C HAMELEON D ISC

System Design

Building on these insights, we observe that any packet— regardless of header or payload—can support link discovery in SDN as long as it triggers the table-miss rule after one 6

Table 2: Deployment Prerequisites for C HAMELEON D ISC Requirement

Decoy Morph Camo

(a) Default flow entries are protected

✓

(b) A default flow entry forwarding LLDP/BDDP packet to controller

G #

—

G #

✓

—

(d) A default flow entry forwarding ARP packet to controller

—

✓

(e) No flow entry matching solely on in_port intercepting table-miss

G #

✓

—

Figure 2: C HAMELEON D ISC System Design C HAMELEON D ISC requires the following conditions for each of DecoyType, MorphType, and CamoType to operate correctly, as shown in Table 2. It uses DecoyType and MorphType for periodic link discovery, and reserves CamoType for link change verification. This separation is motivated below: • MorphType reinforces DecoyType: MorphType performs periodic discovery without static identifiers, preventing topology poisoning attacks that rely on fixed signatures. • CamoType defends against MorphType evasion: if an advanced attacker intercepts all unknown packets to classify and attack MorphType, CamoType — disguised as normal data plane traffic — creates an inescapable dilemma: manipulating it disrupts normal communication and immediately exposes the attacker, while avoiding it leaves the topology manipulation detectable. • CamoType is reserved for verification only: overusing CamoType (e.g., ARP/IP) for periodic discovery would leak too many samples, helping attackers distinguish discovery probes from legitimate traffic. By limiting CamoType to link change events — which are infrequent — C HAMELEON D ISC preserves camouflage and denies attackers the sample volume needed for classification.

✓ Required; — Not required; G #DecoyType requires either (b), or

both (c) and (e), depending on the controller, see Table 6.

hop. C HAMELEON D ISC secures discovery through a threelayer defense, each layer strengthening protection against progressively more capable adversaries. DecoyType retains traditional LLDP-based discovery as an intentional honeypot (Insight 3): attackers who exploit it reveal themselves through inconsistency, while those who ignore it are caught by deeper layers. Because DecoyType reuses existing LLDP infrastructure, including it costs nothing even when aware attackers ignore it. MorphType eliminates informative payloads through full randomization (Insights 1 and 2): the controller’s mapping table recovers link-src without embedding it in the packet, and removing static identifiers prevents exploitation. CamoType leverages camouflage as normal traffic for selective verification (Insight 2): under the stealthy adversary model, tampering with such normal data-plane packets risks immediate exposure. Each layer is detailed below. DecoyType packets preserve traditional identifiers and serve as bait for attackers exploiting static, LLDP-style discovery. Their predictable formats and explicit link-src fields attract legacy attacks, which the controller later detects by cross-checking inconsistent results.

5.1

Built-in Prevention and Detection

C HAMELEON D ISC embeds prevention and detection directly into its discovery workflow, allowing the controller to continuously discover network topology and simultaneously prevent and detect topology poisoning attacks as part of a single, integrated process. To ensure robust protection along with detection against forged links, we layer three discovery probes with progressively higher security levels and trigger CamoType verification on every link change event — i.e., whenever any probe reports a discovery result differing from the lastconfirmed topology — accepting the link update only when CamoType corroborates the result. Algorithm 1 formalizes this workflow, where lines 3–6 correspond to the DecoyType and MorphType discovery phases and lines 10–13 correspond to the CamoType verification phase. The unified workflow encompassing all three phases is illustrated in Figure 2. Figure 2 and Algorithm 1 together illustrate the full discovery process. At step ➀, C HAMELEON D ISC collects the current

MorphType packets randomize all headers and payloads to eliminate identifier and link-src leakage. Running in parallel with DecoyType, MorphType provides clean, identifier-free discovery. Any discrepancy between the two immediately signals manipulation of discovery traffic. CamoType packets act as a final, camouflaged verification layer. Whenever DecoyType or the verified MorphType result reports a link change — i.e., a discovery result differing from the last-confirmed topology — the controller issues CamoType ARP probes constructed with fresh, non-conflicting MAC/IP identities that mimic legitimate new-host arrivals and blend with normal ARP traffic on the wire (Section 5). Under the stealthy adversary model (Section 3), selectively manipulating such traffic risks disrupting legitimate ARP processing and exposing the attacker. 7

Algorithm 1 Prevention and Detection of C HAMELEON D ISC

if only MorphType and CamoType agree (line 21), DecoyType is the manipulated layer; the controller updates the topology with CamoType’s report and inspects the responsible switch to classify the attack source as Marionette, MalHost, or MalSw (lines 22–28). Third, if MorphType’s report does not match CamoType (line 30), the controller treats CamoType as the ground-truth reference — justified by the Stealthy Adversary Assumption (§3), under which tampering with CamoType’s normal data-plane probes would manipulate ARP traffic and risk immediate exposure — and flags an advanced attacker (AdvAttack) capable of manipulating MorphType forwarding (line 31). We formalize this guarantee in Proposition 1. This verification is robust to benign faults because link update acceptance requires corroboration: an incorrect verdict needs a DecoyType, MorphType, and CamoType probes to fail in the same cycle, and the joint failure is far less likely than failure of a single probe [11]. A transient loss is therefore resolved by re-probing before a verdict is finalized; a late-arriving probe behaves like a loss for that round, and packet-in congestion manifests as added delay, so all such faults reduce to the transient-loss case. This exposure is limited to begin with, as verification is triggered only on a reported change and interswitch links are stable the vast majority of the time [19]. Finally, a sustained high joint loss rate is operationally equivalent to a link failure, so treating the link as unavailable is the correct outcome rather than a false positive. This robustness costs one extra CamoType verification per change, adding a brief confirmation delay. The exchange is favorable: the delay is paid only on rare link-change events, and a short wait to confirm a link is far cheaper than committing the controller to a false topology. The discovery process for DecoyType packets follows traditional SDN mechanisms and introduces no additional overhead. The primary challenges lie in designing and composing MorphType and CamoType packets.

Require: DS: Topo datastore; P: Ports; T : Mapping table; q: Num of rounds. 1: while true do 2: for pi ∈ P do 3: D.pkti ← gen_Dpkt(pi ); M.pkti ← gen_Mpkt(pi ); 4: upd_Map(T , D.pkti , pi ); upd_Map(T , M.pkti , pi ); 5: D.pktIni ← probe(D.pkti ); M.pktIni ← probe(M.pkti ); 6: D.linki ← inf(D.pktIni ,T ); M.linki ←inf(M.pktIni ,T ); 7: M.chgi ← diff(DS,M.linki ); 8: if |M.chgi | > 0 then 9: M.linki ← multi_round_verify(M.chgi ,pi ,q); 10: end if 11: Chg.linki ← diff(DS,D.linki ,M.linki ); 12: if |Chg.linki | > 0 then 13: R.sw ← get_sw(Chg.linki ); 14: C.pkti ← gen_Cpkt(pi ); 15: upd_Map(T , C.pkti , pi ); 16: C.pktIni ← probe(C.pkti ); 17: C.linki ← inf(C.pktIni ,T ); 18: if D.linki == M.linki ==C.linki then 19: update(DS,Chg.linki ); 20: report(AcceptLinkChg); 21: else if M.linki ==C.linki then 22: update(DS,C.linki ); 23: if detect_pois_Entry(R.sw) then 24: report(Marionette); 25: else if detect_host(R.sw) then 26: report(MalHost); 27: else 28: report(MalSw); 29: end if 30: else 31: report(AdvAttack); 32: end if 33: end if 34: end for 35: end while

topology and switch-port information for each discovery cycle. At step ➁, for each port pi (line 2), the controller generates corresponding DecoyType and MorphType packets for pi (line 3). At step ➂, the controller stores the mapping of DecoyType and MorphType to their link-src (line 4). At steps ➃➄➅, the DecoyType and MorphType packets are sent out as probes and returned to the controller through the table-miss flow entry (line 5). At step ➆, the controller recovers the link-src by querying the mapping table and derives the link-dst from the packet-in message (line 6). The steps of CamoType verification (lines 14–17) follow the same logic. Continuing in Algorithm 1, when MorphType reports a link change (line 7), C HAMELEON D ISC triggers multi-round MorphType verification to filter out transient network faults and random-guessing-based flow entry-induced topology poisoning (lines 8–10). Whenever any probe (DecoyType or MorphType) reports a link change — i.e., a discovery result differing from the last-confirmed topology (lines 11–12), the controller triggers CamoType verification (lines 14–17) and resolves the outcome via three branches. First, if DecoyType, MorphType, and CamoType all agree on the new link (line 18), the link update is accepted as legitimate (lines 19–20). Second,

5.2

EtherType and Packet Construction

Constructing discovery packets correctly is essential for both concealment and network interoperability. The ether-type field is tightly regulated: specific values denote standardized packet formats whose payloads must follow corresponding specifications. C HAMELEON D ISC therefore selects ether-type values that either (i) correspond to a packet type forwarded to the controller under SDN flow-entry configuration, or (ii) fall within IEEE-unreserved ranges [23] suitable for triggering table-miss. Each discovery packet is padded to at least 64 bytes to meet the minimum Ethernet frame size. Table 7 (Apppendix F) summarizes the selected types. LLDP and BDDP [7,45] serve DecoyType. Unregistered EtherTypes form the MorphType pool: only 276 of the 216 values are registered, leaving ample space for randomized, nonconflicting packets. ARP (0x0806) is ideal for CamoType, as it is naturally forwarded to controllers via a single preinstalled flow rule.3 3 match: ether-type: 0x0806; action: to-controller.

Algorithm 2 MorphType Discovery Packet Generation

IPv4/IPv6 can also serve as CamoType but require more careful flow-table handling to ensure reliable table-miss behavior [6].

5.3

Require: x: Switch ID, macList: List of MAC addresses existing in the target network, typeList: List of EtherTypes that should be avoided. Ensure: {morphPktix }: MorphType packets for Port i on Switch x. 1: for Port i on Switch x do 2: sMAC = dMAC = 0; 3: morphType = 0; 4: macList = add(sMAC,macList); 5: typeList = add(morphType,typeList); 6: while sMAC ∈ macList do 7: sMAC = rand_gen_mac(); 8: end while 9: while dMAC ∈ macList do 10: dMAC = rand_gen_mac(); 11: end while 12: while morphType ∈typeList do 13: morphType = rand_gen_type(); 14: end while 15: morphHdr = build_hdr(sMAC, dMAC, morphType); 16: morphPktix = build_disc_pkt(morphHdr); 17: end for

Non-Disruptive Verification

CamoType leverages normal data-plane packet types for verification, requiring careful construction to avoid interference with existing controller services. C HAMELEON D ISC therefore synthesizes standards-compliant ARP probes that mimic legitimate new-host arrivals using a fresh MAC address not present in the controller’s host state and an unused IP address from the local subnet. This avoids reusing an existing host identity, which could otherwise cause ARP Handler or Host Tracker to associate that host with the wrong switch port. A CamoType-specific filter prevents these controllergenerated synthetic identities from being processed as legitimate hosts by ARP Handler and Host Tracker. Because the synthetic MAC/IP pair is fresh and does not overlap with an existing host, the filter can identify CamoType probes without suppressing legitimate ARP traffic. CamoType probes are additionally issued after a randomized delay to reduce timing-based classification. IP packets can also serve as CamoType probes, but require more careful flow-table handling to ensure reliable forwarding; we refer to SPV [6] for a detailed treatment.

5.4

the network. This approach is efficient, with its performance backed by probabilistic guarantees, as demonstrated next.

5.5

Efficient Ethernet Header Randomization

We apply Ethernet header randomization only to MorphType packets, as DecoyType and CamoType require registered packet types to fulfill their respective roles. Because certain MAC addresses must be excluded from the candidate pool, and the pool size is enormous, maintaining the entire candidate pool for shuffling randomized MAC addresses or EtherType values consumes significant memory. To address this issue, we opt to generate randomized numbers first and then verify whether they are allowed or blocked. Below, we provide evidence supporting the practicality of this method. Generating collision-free discovery-packet fields is reliable and efficient, even at large network scale. In large SDN deployments, the total number of MAC addresses (across hosts and switch ports) is at most tens of millions [14, 24, 40], while the theoretical maximum is 248 (about 281 trillion). Thus, the probability of randomly generating a MAC address that exists in the network is 3.55×10−8 . The probability of generating two MAC addresses that both collide with existing ones is merely 1.26025 × 10−15 . Similarly, randomly generating an ether-type that falls among the 276 effectively registered out of 216 possible values is 0.00421, and regenerating a second collision is 1.77441×10−5 . Hence, randomly selecting ether-src, ether-dst, and ether-type while checking against known addresses/types remains highly feasible. To efficiently handle repeated checks against known addresses and types, we use a hash set (preprocessed for fast lookup), which provides an average lookup time of O(1), further reducing time complexity. Building on the discussion of packet construction and table-

Preventing Table-Miss Overrides

Because DecoyType (LLDP) and CamoType (ARP) packets are naturally sent to the controller by design, preventing table-miss overrides is only crucial for MorphType to maintain accurate link discovery. Our focus is on scenarios that reuse the default table-miss flow entries for discovery without dynamic data plane monitoring. The EtherTypes considered here include unassigned types (MorphType) and Layer-2 packet types of ARP (CamoType) and LLDP (DecoyType) that are inherently designed to be sent to the controller. The Layer-3 EtherType of IP (CamoType) follows the treatment described in SPV [6], to which we refer for further details. Additionally, we select randomized MAC addresses that are not present in the SDN network for ether-src and ether-dst, further minimizing interference from existing flow entries and reducing the likelihood of unintended matches. This strategy eliminates the need for dynamic data plane monitoring and ensures that normal flow entries do not inadvertently match discovery packets for the reasons in Appendix C. If the SDN controller does not configure flow entries based on the Ethernet header, any MAC address in the ether-dst or ether-src fields may inadvertently trigger table-miss flow entries. When flow entries explicitly match ether-src, ether-dst, or ether-type, C HAMELEON D ISC ensures that discovery packets avoid using those specific Ethernet headers to prevent unintended flow entries by avoiding all MAC addresses already present in the target SDN network, as normal flow entries do not match MAC addresses absent from 9

miss enforcement, we propose an algorithm (Algorithm 2) to generate C HAMELEON D ISC discovery packets. For each switch, packets are randomly generated for every port (lines 1–17). Each port starts with source MAC, destination MAC, and ether-type set to 0 (lines 2–3), which are then added to the MAC address list and type list (lines 4–5). While any value of ether-src, ether-dst, and ether-type remains in its respective list, it is regenerated randomly until it no longer appears (lines 6–14). The random regeneration draws from the operating system’s cryptographically secure random source (/dev/urandom) [20], built on a NIST-standardized DRBG design [10], so generated values remain unpredictable to an adversary even after observing many packet-in/packet-out samples. Finally, we construct the Ethernet header, build the discovery packet, and add it to the packet list (lines 15–17). The MAC list is sourced from the controller’s host tracker, which maintains active host and switch-port MACs as part of standard SDN operation and evicts entries when hosts expire. Because the host tracker is internal to the trusted controller, attackers cannot manipulate this list to shrink or enlarge the exclusion pool.

relay) fall outside MorphType’s defense and are handled separately by CamoType (Proposition 1). The attacker is limited to maintaining at most p malicious flow entries matching either of ether-src, ether-dst, and ether-type in the flow table without detection. The SDN controller re-discovers links every l seconds; when MorphType reports a candidate link change, the controller requires q consistent MorphType discoveries before passing the result to final verification. Before formalizing the analysis, we address two attack strategies that appear viable but are fundamentally ineffective. Wildcard and bitmask matching. Wildcard matching ignores a field entirely; bitmask matching matches arbitrary bit patterns via a mask [49]. Both mechanisms are typically used on IP addresses, where the hierarchical subnet structure (CIDR prefixes) makes selective matching meaningful — a structure absent in EtherType and MAC address spaces. Consequently, any mask broad enough to catch MorphType’s randomized EtherTypes also catches standard data-plane types (IPv4, IPv6, ARP). Catching a uniformly random MAC similarly requires a mask covering a substantial fraction of the address space, which also covers legitimate host and switch MACs. In both cases, intercepting MorphType requires disrupting normal traffic, violating the Stealthy Adversary Assumption (§3). The following analysis therefore restricts the attacker to specific-value matching.

Theoretical Resilience Analysis

Although MorphType’s defense relies on randomized discovery packets and is therefore inherently probabilistic, this section establishes the theoretical foundation for evaluating its resilience against random guessing under realistic conditions. We adopt a q-round MorphType verification model corresponding to Algorithm 1. Multi-round verification is triggered only when MorphType reports a change, thereby retaining lightweight single-round probing during normal operation while strengthening verification of suspicious or changed topology observations. CamoType provides a separate final verification layer, whose guarantee is formalized in Proposition 1. By incorporating practical parameters aligned with real-world discovery settings, we show that the probability of a successful topology poisoning attack is extremely low. Moreover, multi-round verification further diminishes this likelihood, while the inclusion of CamoType final verification (e.g., ARP) elevates the defense to an additional level — since ARP is a ubiquitous and legitimate packet type that adversaries are highly unlikely to manipulate without exposing their presence; we formalize this guarantee in Section 6.2. Together, these mechanisms provide strong assurance of C HAMELEON D ISC’s robustness even in adversarial environments. Our objective is to bound MorphType resilience to random guessing — i.e., the expected number of rounds before an attacker can force MorphType to report a fabricated link via random flow-entry installation. End-to-end correctness is provided by CamoType verification on every link change event (Proposition 1, §6.2); the bound below quantifies how rarely MorphType fabrications even reach that gate. This bound covers attackers restricted to flow entry installation; compromised switches that bypass the flow-entry mechanism (e.g., advanced

Adaptive observation. Even if an attacker observes a MorphType packet in transit and extracts its randomized header fields, two barriers prevent exploitation. First, installing a matching flow entry requires completing an OpenFlow rule installation cycle within the millisecond window before the controller collects the current probe — practically infeasible. Second, C HAMELEON D ISC re-randomizes all header fields every discovery round, so knowledge of round N provides zero advantage for round N + 1. The attacker must successfully intercept q consecutive independent rounds, the expected time for which is quantified below.

6.1

MorphType Resilience Markov Chain

Consider a set containing 2m consecutive numbers: S = {0,1,2,...,2m −1}. An attacker randomly selects p numbers from this set. In each round, the SDN controller randomly selects a number from a subset T ⊆ S of size n. We define: • A q-hit streak is q consecutive rounds where the controller’s choice lies within the attacker’s p chosen values. • A q-miss streak is q consecutive rounds where the controller’s choice lies outside attacker’s p chosen values. The objective is to compute the expected number of rounds required to achieve a q-hit streak or a q-miss streak. This problem can be modeled using a Markov chain, as the probability of the next round making q-hit streak depends only on the current state of (q − 1)-hit streak and not on the 10

sequence of prior states. Without loss of generality, we focus on analyzing the probability of a q-hit streak; the analysis for a q-miss streak follows analogously.

number of rounds to achieve 3-hit streak is given by: 1+Pin +Pin2 1 1 1 = + + E0 = (11) 1−Pout −Pin Pout −Pin2 Pout Pin3 Pin2 Pin Similarly, the expected number of rounds to achieve a 3-miss streak is given by: 2 1 1 1+Pout +Pout 1 M0 = = 3 + 2 + (12) 2 1−Pin −Pout Pin −Pout Pin Pout Pout Pout By substituting (5) and (6) into the analysis, we have: • Expected attack time ≈ 278 million rounds (~44 years if 5 seconds per round). • Expected recovery time ≈ 3 rounds. These bounds upper-bound the rate at which MorphType random guessing can produce sustained fabrications; the end-toend guarantee combines this rate with CamoType verification.

• Probability of the SDN controller selecting a number in the attacker’s set: p Pin = (1) n • Probability of selecting a number outside attacker’s set: n− p Pout = 1−Pin = (2) n Define states 0,1,...,q: • State i (SiH ): The process has i-hit streak. • State 0 (S0H ): No such streak currently exists. • State q (SqH ): A q-hit streak has occurred. Transitions: • From State i < q, moving to state i + 1 occurs with probability Pin , and falling back to state 0 (breaking the streak) occurs with probability Pout .

6.2

While Section 6.1 bounds MorphType resilience to random guessing, an advanced adversary may still fabricate links by intercepting all unknown packets at a compromised switch or by selectively manipulating one probe layer. CamoType verification, triggered on every link change event, closes these gaps. An adaptive adversary aware of C HAMELEON D ISC may attempt to selectively manipulate individual probe types. Any such manipulation that fabricates a link, however, produces a reported link change and thus triggers CamoType verification, reducing every fabrication strategy to the dilemma below. The following proposition formalizes the guarantee.

• Ei : Expected number of rounds to reach state q from state i. Using Markov chain theory and the law of total expectation, the recurrence relations for expected hitting times are: Ei = 1+Pin Ei+1 +Pout E0 , for i < q

(3)

with the boundary condition: Eq = 0

(4)

The boundary condition Eq = 0 arises because once the process reaches state q, the q-hit streak is achieved, and no further rounds are needed to reach the desired goal. Solving this system of equations yields E0 , the expected number of rounds to achieve q-hit streak— an informative measure of C HAMELEON D ISC’s resilience. We evaluate the MorphType resilience to random guessing under realistic settings. We use the parameter values below in the Markov chain model to reflect real-world scenarios and provide insights into C HAMELEON D ISC’s resilience.

Proposition 1 (CamoType Stealth Dilemma). Let A be any adversary satisfying the Stealthy Adversary Assumption (§3). If any probe (DecoyType or MorphType) reports a link change differing from the last-confirmed topology (Algorithm 1), then at CamoType verification exactly one of the following holds: (i) A does not tamper with the CamoType probe. CamoType reveals the true link, and any probe disagreeing with it is flagged as manipulated per Algorithm 1 (lines 14–27). (ii) A tampers with the CamoType probe, manipulating normal data-plane traffic and exposing A . Hence no A can both fabricate links and remain undetected.

• p = 100: Max num of malicious flow entries in a switch. • m = 16: Attack to match ether-type (16-bit). • n = 2m −276 = 65,260: Num of available ether-types. • q = 3: Requires 3 consistent MorphType discoveries. • l = 5: Sending discovery every 5 seconds. The resulting probabilities are: p 100 ≈ 0.0015323322 (5) Pin = = n 65,260 Pout = 1−Pin = 0.9984676678 (6) Attack and Recovery Time. Due to q = 3 and (3), we have: E0 = 1+Pin E1 +Pout E0

(7)

E1 = 1+Pin E2 +Pout E0

(8)

E2 = 1+Pin E3 +Pout E0

(9)

CamoType Stealth Guarantee

Proof. No adversary—malicious host, switch, application, or controller peer—can single out the CamoType: its identity is never revealed (§III), and CamoType is constructed to resemble ordinary ARP traffic and its identity is not disclosed outside the trusted controller. Under our adversary-knowledge and stealth assumptions, an attacker cannot reliably target CamoType without also risking interference with legitimate ARP traffic. Two cases arise. (i) A leaves the probe intact: CamoType returns the true link, and any disagreeing DecoyType or MorphType probe is flagged (Alg. 1, lines 14–27). (ii) A redirects the probe: resembling ordinary ARP/IP traffic under our adversary model, doing so—whether a switch rewriting packets or an application

E3 = 0 (10) By recursively solving these equations, the expected 11

or controller peer installing flow entries—also redirects normal traffic, violating constraint 1 and exposing A . The cases are exhaustive, so no A can fabricate a link undetected.

System Evaluation

We implement C HAMELEON D ISC on the open-source SDN controller OpenDaylight (Calcium release). We evaluate its effectiveness against known types of topology poisoning attacks in Section 7.1, the fine-grained convergence latency of discovery in Section 7.2, and the performance overhead in Section 7.3. We deploy C HAMELEON D ISC on Ubuntu 22.04.4 with a 2.4 GHz 8-core Intel Core i9 processor and 32 GB of memory. CPU utilization follows Linux process accounting, where 100% corresponds to one fully utilized core; thus, the 8-core system has a total capacity of 800%. C HAMELEON D ISC is integrated as a submodule of OpenDaylight’s l2switch project [1] with the loopremover modified to support reactive forwarding and a CamoType-specific ARP filter added to the arphandler and hosttracker to maintain compatibility with the host-tracker. The OpenFlow network is emulated using Mininet v2.3.0 [44] on another VM with the same system, CPU, and 16 GB of memory. By default, C HAMELEON D ISC sends one DecoyType and one MorphType probe every 5 seconds during normal operation. The link discovered by MorphType ages in 40 seconds. A MorphType-reported change triggers the three-round MorphType verification, while a remaining link-change event triggers a single CamoType ARP probe for final verification. To further obfuscate discovery behavior, MorphType frame sizes approximate the characteristic bimodal size distribution observed in real network traffic [26]: 50% are small frames (64–118 bytes), 40% are large frames near the Ethernet MTU (1418–1518 bytes), and the remaining 10% are distributed across the intermediate range. Each CamoType probe is additionally issued after a randomized delay of 0 to 2 seconds to hinder timing-based classification. Administrators retain full control over the choice and scheduling of discovery packets, enabling secure topology discovery without exposing discovery-related information to any network component.

7.1

Figure 3: C HAMELEON D ISC defeats relay attack Table 3: Convergence latency by stage event

stage

# events

median IQR p90 max (s) (s) (s) (s) link down detect 100 0.01 0.01–0.01 0.01 5.19 link down verify 100 4.52 4.10–4.95 5.40 5.54 link down converge 100 4.53 4.15–5.06 5.41 8.95 link up detect 100 0.30 0.27–0.30 0.31 0.67 link up verify 100 1.05 0.49–1.57 1.82 2.06 link up converge 100 1.37 0.82–1.83 2.18 2.49 mal-relay detect 100 2.95 1.52–4.12 4.70 5.18 mal-relay verify 100 1.22 0.78–1.69 1.91 2.04 mal-relay converge 100 4.06 2.85–5.16 5.96 7.21 pkt loss detect 97* 14.46 9.36–22.48 28.70 41.22 pkt loss verify sent to verify, but the probe never returned pkt loss converge 97* 14.46 9.36–22.48 28.70 41.22 *Loss still allowed enough probes to refresh the link in 3 of 100 events.

and 10. MorphType reports the genuine topology, and the resulting disagreement triggers CamoType verification, which confirms the genuine neighbor and rejects the fabricated link.

7.2

Fine-Grained Convergence Latency

We evaluate how quickly C HAMELEON D ISC’s accepted topology reflects four types of change: link down, link up, malicious relay, and 50% packet loss. All experiments use the 252-link topology in Figure 3. All events are launched from the C HAMELEON D ISC VM to the mininet VM via ssh, and timestamps are taken on the controller’s clock to avoid cross-VM synchronization issues. We record 100 link-down/up pairs, 100 malicious-relay attacks, and 100 events of 50% bidirectional packet loss (Table 3). We restart the controller for each case and randomly select the affected links. Events are spaced 17.25 s apart, deliberately offset from the 5 s periodic discovery interval. The detailed latency distribution of each case is in Appendix J. Overall, C HAMELEON D ISC converges quickly for both legitimate changes and attacks. Link-down events are detected almost immediately through asynchronous OpenFlow port-status notifications (0.01 s median), allowing the controller to observe the failure without waiting for the next periodic discovery probe, but require 4.53 s to converge because confirming an absent link requires waiting for

Effectiveness Against Topology Poisoning

We evaluate C HAMELEON D ISC against all four types of topology poisoning attacks defined in §2.1.We use a 5-switch ring to verify the detection outcome; the complete per-attack results are shown in Appendix E. C HAMELEON D ISC prevents all four identifier-based attacks: DecoyType may be manipulated, while MorphType avoids identifier-specific forwarding rules and CamoType verifies the resulting link change. Figure 3 illustrates a relay attack on a 50-switch fat-tree data-center topology with 252 inter-switch links. Malicious Switch 25 relays DecoyType LLDP packets, causing the controller to infer the fabricated link between Switches 9 12

Table 4: CPU & mapping entries overhead across topo sizes (Node, Link) (40, 282) (50, 252) (80, 314) (120, 816)

Ctrl base cham base cham base cham base cham

min 7.0 11.0 3.0 5.0 13.0 8.0 39.0 2.0

CPU (%) max mean 101.0 30.5 118.0 36.0 125.7 36.2 124.0 38.8 103.0 50.1 230.0 57.2 137.0 73.5 461.0 96.5

med. 24.0 29.0 36.0 32.0 48.5 51.0 70.0 73.2

# of mapping entries min max mean med. – – – – 40 80 63.0 60 – – – – 50 100 71.1 74 – – – – 80 160 121.6 120 – – – – 60 240 161.8 150

Figure 4: Trade-off between latency, CPU, and mapping entries

unanswered probes. Link appearance is faster (1.37 s median), as event-triggered probes return and allow verification to complete without silence timeouts. Malicious relays are detected in 4.06 s median: It is first exposed when a periodic DecoyType probe reports a fabricated link, so its detection latency includes the wait until that probe occurs. Under 50% bidirectional packet loss, 97 of 100 impaired links were retired within the 45 s window, with a median convergence time of 14.46 s. Because partial loss generates no port-status event and successful probes can still refresh the link, retirement is driven by periodic aging rather than changetriggered verification. CamoType is triggered only after the link is removed and therefore does not affect this convergence time. More generally, returned probes complete quickly, whereas missing replies incur configured timeout delays.

7.3

120 switches, with a maximum of 240 entries on the 816-link topology. This behavior is consistent with its design: entries represent only outstanding probes and are removed when probes return or expire, so state scales with concurrently active discovery rather than controller uptime. Together, these results show that C HAMELEON D ISC introduces modest steady-state overhead while larger fabrics mainly increase burst processing and in-flight mapping state. CPU also increases with topology size for both controllers. Relative to the baseline, C HAMELEON D ISC adds only 2.6–7.1 percentage points of mean CPU through 80 switches, while the 120-switch topology increases the mean by 23.0 points. The corresponding median increase at 120 switches is only 3.2 points, indicating that the larger mean is driven primarily by transient CPU bursts rather than sustained load. Such startup bursts can be mitigated by lengthening the MorphType discovery, which is demonstrated in the trade-off evaluation.

Performance Overhead Analysis

Trade-off between Detection and Overhead. On the 120switch topology, we vary the shared DecoyType/MorphType discovery interval from 3 to 15 s while retaining the randomized CamoType delay of [0,2] s (Figure 4 and Table 8 in Appendix G). For each interval, we evaluate 30 relay attacks. Median detection latency increases from 4.3 s at a 3 s interval to 11.8 s at 15 s, while mean CPU utilization decreases from 105% to 78%. The median mapping-table size decreases from 252 entries at 3 s to 60 entries at 12–15 s, with a substantial reduction already achieved at 5–7 s. These results expose a clear trade-off: shorter discovery intervals improve responsiveness but increase probe-processing load and the number of concurrent mappings, whereas longer intervals reduce overhead at the cost of slower attack detection. In our experiments, intervals of 5–7 s provide a practical middle ground. Additional discussion is provided in Appendix K.

We evaluate C HAMELEON D ISC’s controller overhead from three perspectives: resource usage under attacks, the additional packet-to-link-src mapping, and scalability with network size. Overhead Under Attacks. We first measure C HAMELEON D ISC’s steady-state overhead relative to the baseline controller. On the 252-link topology, C HAMELEON D ISC uses 46.6% mean CPU versus 33.6% for the baseline, while post-GC live heap is 199 MB versus 193 MB, with substantially overlapping distributions. We then examine whether attack handling introduces additional transient overhead beyond this steady-state cost. As shown in Appendix I, the injected attack and recovery events produce no visible CPU or retained-heap spikes. Thus, C HAMELEON D ISC incurs additional steadystate discovery overhead, but processing an attack does not measurably increase resource usage beyond that baseline. Scalability Across Network Sizes. We evaluate controller CPU and C HAMELEON D ISC’s mapping-table state across four fat-tree topologies ranging from (N, L) = (40, 282) to (120, 816). Each experiment starts from a clean controller and starts monitoring once stabilized; CPU is sampled every ∼1.2 s for 300 s, while mapping-table size is recorded from the controller approximately every 30 s. As Table 4 shows, the mapping table grows with topology size but remains bounded: its mean size increases from 63 entries at 40 switches to 162 at

Conclusion

C HAMELEON D ISC is a moving-target defense against topology poisoning attacks while remaining compatible with SDN workflows. Our analysis and evaluation demonstrate resilience against identifier-based and advanced relay attacks with practical convergence and a tunable security–performance trade-off. 13

References

[12] Mingming Chen, Thomas La Porta, Teryl Taylor, Frederico Araujo, and Trent Jaeger. Manipulating openflow link discovery packet forwarding for topology poisoning. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, pages 3704–3718, 2024.

[1] Mirror of the OpenDaylight l2switch gerrit project. https://github.com/opendaylight/l2switch. Accessed on 2025-07-20. [2] Mirror of the OpenDaylight openflowplugin gerrit project. https://github.com/opendaylight/ openflowplugin/tree/master. Accessed on 202503-19. [3] Open network operating system. //github.com/opennetworkinglab/onos. cessed on 2025-03-19.

[13] Mingming Chen, Thomas F La Porta, Trent Jaeger, and Srikanth V Krishnamurthy. Efficient lightweight coordinated sampling for dynamic flows: Theory and implementation. IEEE Transactions on Networking, 2025.

https: Ac-

[14] Cisco. Cisco Application Centric Infrastructure (ACI) Design Guide. https://www.cisco.com/c/en/us/ td/docs/dcn/whitepapers/cisco-applicationcentric-infrastructure-design-guide.html, June 6, 2024. Accessed on 2025-01-05.

[4] Ryu component-based software defined networking framework. https://github.com/faucetsdn/ryu/ tree/master. Accessed on 2025-03-19.

[15] Paul Congdon. Link layer discovery protocol and mib v2.0. https://www.ieee802.org/1/files/ public/docs2002/lldp-protocol-02.pdf, 2002. Accessed on 2025-07-31.

[5] Build SDN Agilely. https://ryu-sdn.org/, 2011. Accessed on 2023-06-19. [6] Amir Alimohammadifar, Suryadipta Majumdar, Taous Madi, Yosr Jarraya, Makan Pourzandi, Lingyu Wang, and Mourad Debbabi. Stealthy probing-based verification (spv): An active approach to defending software defined networks against topology poisoning attacks. In Computer Security: 23rd European Symposium on Research in Computer Security, ESORICS 2018, Barcelona, Spain, September 3-7, 2018, Proceedings, Part II 23, pages 463–484. Springer, 2018.

[16] Mohan Dhawan, Rishabh Poddar, Kshiteej Mahajan, and Vijay Mann. Sphinx: detecting security attacks in software-defined networks. In Ndss, volume 15, pages 8–11, 2015. [17] Linux Foundation. Opendaylight. //www.opendaylight.org/.

https:

[18] Sahil Garg, Kuljeet Kaur, Georges Kaddoum, Syed Hassan Ahmed, and Dushantha Nalin K Jayakody. Sdn-based secure and privacy-preserving scheme for vehicular networks: A 5g perspective. IEEE Transactions on Vehicular Technology, 68(9):8421–8434, 2019.

[7] Shaoyong Wu Ayaka Koshibe. Onos network discovery. https://wiki.onosproject.org/display/ONOS/ Network+Discovery, 2016. Accessed on 2023-05-25. [8] Abdelhadi Azzouni, Raouf Boutaba, Nguyen Thi Mai Trang, and Guy Pujolle. softdp: Secure and efficient openflow topology discovery protocol. In NOMS 20182018 IEEE/IFIP Network Operations and Management Symposium, pages 1–7. IEEE, 2018.

[19] Phillipa Gill, Navendu Jain, and Nachiappan Nagappan. Understanding network failures in data centers: measurement, analysis, and implications. In Proceedings of the ACM SIGCOMM 2011 Conference, pages 350–361, 2011.

[9] Sonali Sen Baidya and Rattikorn Hewett. Link discovery attacks in software-defined networks: Topology poisoning and impact analysis. J. Commun., 15(8):596–606, 2020.

[20] Zvi Gutterman, Benny Pinkas, and Tzachy Reinman. Analysis of the linux random number generator. In 2006 IEEE Symposium on Security and Privacy (S&P’06), pages 15–pp. IEEE, 2006.

[10] Elaine Barker and John Kelsey. Recommendation for random number generation using deterministic random bit generators, 2015-06-24 2015. doi:10.6028/NIST.SP.800-90Ar1.

[21] Sungmin Hong, Lei Xu, Haopei Wang, and Guofei Gu. Poisoning network visibility in software-defined networks: New attacks and countermeasures. In Ndss, volume 15, pages 8–11, 2015.

[11] Jean-Chrysotome Bolot. End-to-end packet delay and loss behavior in the internet. In Conference proceedings on Communications architectures, protocols and applications, pages 289–298, 1993.

[22] Xinli Huang, Peng Shi, Yufei Liu, and Fei Xu. Towards trusted and efficient sdn topology discovery: A lightweight topology verification scheme. Computer Networks, 170:107119, 2020. 14

[23] IEEE. Ieee registration authority: Assignments. https://regauth.standards.ieee.org/ standards-ra-web/pub/view.html#registries.

[33] National Vulnerability Database. CVE-201610377 Detail. https://nvd.nist.gov/vuln/ detail/cve-2016-10377, 2024. https: //nvd.nist.gov/vuln/detail/cve-2016-10377.

[24] Sushant Jain, Alok Kumar, Subhasree Mandal, Joon Ong, Leon Poutievski, Arjun Singh, Subbaiah Venkata, Jim Wanderer, Junlan Zhou, Min Zhu, et al. B4: Experience with a globally-deployed software defined wan. ACM SIGCOMM Computer Communication Review, 43(4):3–14, 2013.

[34] National Vulnerability Database. CVE-2016-2074 Detail. https://nvd.nist.gov/vuln/detail/cve2016-2074, 2024. [35] National Vulnerability Database. CVE-2024-37018 Detail. https://nvd.nist.gov/vuln/detail/CVE2024-37018, 2024.

[25] Samuel Jero, William Koch, Richard Skowyra, Hamed Okhravi, Cristina Nita-Rotaru, and David Bigelow. Identifier binding attacks and defenses in {Software-Defined} networks. In 26th USENIX Security Symposium (USENIX Security 17), pages 415–432, 2017.

[36] National Vulnerability Database. CVE-2024-46942 Detail. https://nvd.nist.gov/vuln/detail/CVE2024-46942, 2024. [37] National Vulnerability Database. CVE-2024-46943 Detail. https://nvd.nist.gov/vuln/detail/CVE2024-46943, 2024.

[26] Wolfgang John and Sven Tafvelin. Analysis of internet backbone traffic and header anomalies observed. In Proceedings of the 7th ACM SIGCOMM conference on Internet measurement, pages 111–116, 2007.

[38] Ajay Nehra, Meenakshi Tripathi, Manoj Singh Gaur, Ramesh Babu Battula, and Chhagan Lal. Sldp: A secure and lightweight link discovery protocol for software defined networking. Computer Networks, 150:102–116, 2019.

[27] Peyman Kazemian, Michael Chang, Hongyi Zeng, George Varghese, Nick McKeown, and Scott Whyte. Real time network policy checking using header space analysis. In 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI 13), pages 99–111, 2013.

[39] Ajay Nehra, Meenakshi Tripathi, Manoj Singh Gaur, Ramesh Babu Battula, and Chhagan Lal. Tilak: A token-based prevention approach for topology discovery threats in sdn. International Journal of Communication Systems, 32(17):e3781, 2019.

[28] Ahmed Khurshid, Wenxuan Zhou, Matthew Caesar, and P Brighten Godfrey. Veriflow: Verifying network-wide invariants in real time. In Proceedings of the first workshop on Hot topics in software defined networks, pages 49–54, 2012.

[40] Bruno Astuto A Nunes, Marc Mendonca, Xuan-Nam Nguyen, Katia Obraczka, and Thierry Turletti. A survey of software-defined networking: Past, present, and future of programmable networks. IEEE Communications surveys & tutorials, 16(3):1617–1634, 2014.

[29] Diego Kreutz, Fernando MV Ramos, Paulo Esteves Verissimo, Christian Esteve Rothenberg, Siamak Azodolmolky, and Steve Uhlig. Software-defined networking: A comprehensive survey. Proceedings of the IEEE, 103(1):14–76, 2014.

[41] Open Networking Foundation. OpenFlow Switch Specification, Version 1.5.1, March 2015. Available at https://opennetworking.org/softwaredefined-standards/specifications/.

[30] Eduard Marin, Nicola Bucciol, and Mauro Conti. An in-depth look into sdn topology discovery mechanisms: Novel attacks and practical countermeasures. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, pages 1101–1114, 2019.

[42] Open Networking Foundation. SDN Architecture, Issue 1.1 (ONF TR-521). Technical report, Open Networking Foundation, Febrary 2016. Available at https://opennetworking.org/softwaredefined-standards/archives/.

[31] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker, and Jonathan Turner. Openflow: enabling innovation in campus networks. ACM SIGCOMM computer communication review, 38(2):69–74, 2008.

[43] OpenDaylight Project. OpenFlow Plugin: Operations Guide. https://docs.opendaylight.org/ projects/openflowplugin/en/latest/users/ operation.html, 2024. Accessed: 2025-05-23.

[32] Colin Scott Murphy. The pox network software platform. https://github.com/noxrepo/pox, 2013. Accessed on 2023-06-19.

[44] Mininet Project. Mininet: An instant virtual network on your laptop (version 2.3.0). http://mininet.org, 2023. Accessed: August 2025. 15

Table 5: LLDP Packet Fields in SDN Controllers [39]

[45] Ryan Izard Qing Wang, Geddings Barrineau. Floodlight sdn openflow controller. https: //github.com/floodlight/floodlight, 2016. Accessed on 2023-06-19. [46] Richard Skowyra, Lei Xu, Guofei Gu, Veer Dedhia, Thomas Hobson, Hamed Okhravi, and James Landry. Effective topology tampering attacks and defenses in software-defined networks. In 2018 48th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), pages 374–385. IEEE, 2018.

Controller Ether-Dst Ether-Src Ether- Payload Type {Src Sw, Port ID}

Security

Ryu [4]

01:80:c2: Src Port 00:00:0e Mac Addr

0x88cc Chassis ID, Port ID

None

Pox [32]

01:23:20: Src Port 0x88cc Chassis ID, 00:00:01 MAC Addr Port ID

None

Floodlight 01:80:c2: Src Port 0x88cc Opt.<Sw ID>, Static Hash [45] 00:00:0e MAC Addr Port ID ODL [2]

[47] Dylan Smyth, Sean McSweeney, Donna O’Shea, and Victor Cionca. Detecting link fabrication attacks in software-defined networks. In 2017 26th International Conference on Computer Communication and Networks (ICCCN), pages 1–8. IEEE, 2017.

ONOS [3] a5:23:05: Fingerprint 0x88cc Chassis ID, 00:00:01 Port ID

Partial Static Hash Dynamic Secret

Table 6: Flow Entries Assisting SDN Link Discovery [39]

[48] Kashyap Thimmaraju, Bhargava Shastry, Tobias Fiebig, Felicitas Hetzelt, Jean-Pierre Seifert, Anja Feldmann, and Stefan Schmid. Taking control of sdn-based cloud systems via the data plane. In Proceedings of the Symposium on SDN Research, pages 1–15, 2018. [49] ONF TS-009. Openflow switch specification version 1.3.2. https://opennetworking.org/wp-content/ uploads/2014/10/openflow-spec-v1.3.2.pdf. [50] Tao Wang, Fangming Liu, and Hong Xu. An efficient online algorithm for dynamic sdn controller assignment in data center networks. IEEE/ACM Transactions on Networking, 25(5):2788–2801, 2017.

Controller

Match

Priority Action

Ryu [5]

ether-type: 0x88cc 65535 ether-dst: 01:80:c2:00:00:0e

To-controller

Pox [32]

ether-type: 0x88cc 65000 ether-dst: 01:23:20:00:00:01

To-controller

Floodlight [45] Table-miss

To-controller

ODL [17]

Table-miss

To-controller

ONOS [7]

ether-type: 0x88cc

40000

To-controller

from compromised switches and to relay-based or flowentry–induced attacks (Table 1), which manipulate forwarding rather than packet contents. Floodlight’s static cryptographic hash is also vulnerable to replay attacks. Table 6 shows two main types of flow entries for discovery: • table-miss entries, which forward all unmatched packets to the controller; • LLDP-specific entries, which match on the LLDP ether-type and forward packets to the controller. Floodlight and ODL rely on table-miss entries, while ONOS, Ryu, and Pox install LLDP-specific entries. However, the discovery-related flow entries in Pox, Floodlight, ODL, and ONOS can be overridden by malicious high-priority rules from Marionette. Ryu assigns its LLDP-specific entries the highest priority, but attackers can lower default priorities or insert competing high-priority entries to attack. Matching behavior among equal-priority entries is switch-dependent [49], complicating security in multi-vendor environments. Overall, none of the five implementations provides comprehensive protection against topology poisoning attacks.

[51] Qiao Yan, F Richard Yu, Qingxiang Gong, and Jianqiang Li. Software-defined networking (sdn) and distributed denial of service (ddos) attacks in cloud computing environments: A survey, some research issues, and challenges. IEEE communications surveys & tutorials, 18(1):602–622, 2015.

01:23:00: Src Port 0x88cc Opt.<Sw ID, 00:00:01 MAC Addr Port ID>

SDN Topology Discovery Implementations

There is no standardized SDN topology discovery protocol. Although OFDP is the de-facto approach, open-source controllers differ in three key aspects: • the LLDP ether-header; • the payload encoding the link-src; • the flow entries used to return LLDP packets. Table 5 summarizes LLDP configurations across five controllers, showing variations in ether-dst, ether-src, and payload fields. Despite these differences, all rely on a fixed LLDP ether-type—the root cause exploited by existing topology poisoning attacks. Floodlight, OpenDaylight (ODL), and ONOS embed secrets in LLDP packets to authenticate them, but remain vulnerable to spoofed packet-in messages

Case Study of LLDP in SDN Controllers

We analyze the behavior of trending open-source SDN controllers. As detailed in Section 2.1, a controller sends discovery packets to switches using packet-out messages, 16

(a) Packet-out Message Breakdown (a) Markov Chain of q-hit streak

(b) Transition Matrix of q-hit streak

Figure 6: Markov Chain Model of q-hit streak

which requires parsing the LLDP packets. In the ONOS implementation, the link-src is inferred from the mandatory Chassis ID and Port ID fields, while optional fields contain additional "name" and "device" information. Conversely, the OpenDaylight implementation derives link-src information from the optional fields, which store "switch name" and "source port" details initially recorded by the controller. From this example, we can see that there are various ways to store link-src information. However, to the best of our knowledge, all open-source controllers, including both ONOS and OpenDaylight, overlook that ether-src alone is sufficient to retrieve link-src information and fail to utilize it for this purpose. That is because: (1) ether-src (the source switch port MAC address) is equivalent to the Chassis ID (derivation from the source port’s MAC address); (2) the SDN controller maintains a one-to-one mapping between port MAC addresses and switch Port IDs in its data store. Therefore, Observation 1 is justified. Given the controller’s knowledge of all switches, any packet with the ether-src set to a source switch port can be used for topology discovery.

(b) ONOS Packet-in Message Breakdown

(d) LLDP Packet Redundencies

Figure 5: Field-Level Breakdown of Discovery Process Messages

and these packets are returned from neighboring switches to the controller via packet-in messages. Figure 5 decomposes the messages involved in the discovery process, including implementation examples from ONOS and OpenDaylight. The key insight from Figure 5(a) is that the LLDP packet is embedded as data within the packet-out message sent by the controller to the switch. Upon receiving this packet-out message, the switch forwards the data based on the instructions in the action field. Crucially, the output port specified in the action must correspond to the Port ID associated with the LLDP packet to ensure accuracy. Each Chassis ID uniquely corresponds to its Port ID because it is a MAC address derivative of the source port. Notably, the MAC address of the source port also determines the value of ether-src. When a neighboring switch receives the LLDP packet, it forwards it back to the controller due to the table-miss or LLDP flow entry, as discussed in Section 2.1. Figures 5(b) and 5(c) illustrate the differing implementations of the packet-in message for ONOS and OpenDaylight controllers, respectively. In both cases, the controllers determine the link-dst based on the ingress port of the packet-in message. The distinction lies in determining the link-src (link-src),

Non-Conflicting Randomization

Selecting randomized MAC addresses that are not present in the SDN network eliminates the need for dynamic data plane monitoring and ensures that normal flow entries do not inadvertently match discovery packets. • Hosts and switches, which have MAC addresses, change infrequently in a non-wireless network4 ; so, their corresponding flow entries, if any, also tend to remain stable. • Flow entries matching individual Ethernet source or destination addresses are rare5 . • Flow entries that match only on ether-type typically forward control packets to the controller (e.g., ARP and LLDP), aligning with C HAMELEON D ISC’s goal of ensuring discovery packets reach the controller.

Markov Chain Model

4When devices are replaced or reconfigured (months to years) 5 SDN rules typically match on IP and TCP/UDP not MAC addresses.

Figure 8: Mapping-Table Overhead Under Attacks

Figure 7: C HAMELEON D ISC with topology poisoning attacks

the final verification on every link change event — whether DecoyType and MorphType agree on a new link or disagree. The reported change is accepted only when ARP probes — which blend with legitimate data-plane traffic — confirm it. C HAMELEON D ISC also defends against a more advanced threat in which a malicious switch intercepts all unknown packets arriving on a specific in-port—an attack we refer to as an advanced relay attack, also shown in Figure 7. Malicious Switch 2 blindly relays both LLDP packets and all unknown packets arriving on Port 1 to Port 2, and vice versa, regardless of flow entries. This behavior causes both LLDP and MorphType discovery to be misled, fabricating a bidirectional link between Switch 1 and Switch 3. However, CamoType discovery remains unaffected, as ARP packets resemble normal data-plane traffic that attackers are unlikely to manipulate to maintain stealth.

In Figure 6, we depict the Markov Chain Model for the MorphType resilience evaluation.

Effectiveness Against Topology Poisoning

We intentionally use a small 5-switch ring topology in Figure 3 (hosts on SW1/SW4 omitted for clarity) as a proof-of-concept to demonstrate detection correctness, which is topology-independent since detection operates per port. We simulate all four types (i.e., spoof, replay, relay, and flow entry-induced) of topology poisoning attacks on a 5-switch ring topology in Mininet. Using Scapy, we craft spoofed packets to launch spoof-based attacks and capture authentic LLDP packets to simulate replay-based attacks. We install malicious flow entries to simulate relay-based and flow entry-induced poisoning. All four attacks ultimately manipulate LLDP packet handling — either the packet content (spoof, replay) or its forwarding (relay, flow entry-induced) — so each generation procedure is short and self-contained. C HAMELEON D ISC prevents all four types of identifierbased topology poisoning attacks (§2.1), as illustrated in Figure 7. Whenever DecoyType or the verified MorphType result reports a link change, CamoType verification is triggered, and the resolution depends on which probes agree with CamoType (Algorithm 1, lines 14–27). Spoof- and replay-based attacks from malicious hosts are silently suppressed by ODL’s dynamic LLDP hash, which C HAMELEON D ISC inherits without modification — DecoyType discovery in Figure 7 reflects this protection. Flow entry-induced attacks from malicious applications or controller peers, and relay-based attacks from malicious switches, both mislead DecoyType discovery by manipulating LLDP forwarding via poisonous flow entries or in-port relays. In the above cases, MorphType reveals the true topology because its randomized headers ensure only table-miss rules match, blocking malicious flow entries and bypassing static-identifier exploitation. CamoType serves as

Ethernet Types of C HAMELEON D ISC

Table 7 summarizes the Ethernet types suitable for C HAMELEON D ISC to support secure topology discovery.

Trade-off Table

Table 8 shows the details of CPU, number of mapping entries, and detection latency measurements with varied Decoy and MorphType intervals.

Mapping-Table State

Figure 8 confirms this behavior over 90 minutes, six controller restarts, and 216 injected link-down and link-up changes. On the topology in Figure 3, the table contains a median of 79 entries and peaks at 83, requiring only 16 KB. The oldest-entry age also remains bounded by the retention interval, confirming that entries are continuously retired rather than accumulated. 18

Table 7: Ethernet Types Chosen by C HAMELEON D ISC DiscType PktType EthType

Description

Decoy

LLDP

0x88cc

Advertising identity and capability information to neighbor switches for discovery purposes

BDDP

0x8999

Leveraging broadcast frames to advertise link information to discover hybrid links by collaborating with LLDP packets

Morph

Rand

Unassigned Randomly select an EtherType value, verify it remains unassigned in the IEEE Registration Authority [23], and ensure no conflict with other internal standards

Camo

ARP

0x0806

Resolves IP-to-MAC address mappings; suitable for camouflaged verification and naturally supported by default flow entries.

IPv4/ IPv6

0x0800/ 0x86DD

Ubiquitous data-plane types suitable for camouflage, but require careful construction to meet header standards and avoid flow rule conflicts.

Table 8: Trade-off between detection latency, CPU utilization, and mapping-table size interval latency (s) (s) min max mean 3 1.6 9.9 4.5 5 1.2 11.2 5.4 7 2.6 26.8 8.1 9 2.3 18.6 8.8 12 2.8 20.5 9.8 15 3.8 19.2 11.5

CPU (%) mapping entries med min max mean med min max mean med 4.3 4 411 105 97 240 315 260 252 4.2 7 259 90 79 120 183 171 180 6.7 8 483 87 80 120 676 160 120 7.9 16 299 82 73 120 240 141 120 9.7 13 351 80 70 60 120 70 60 11.8 5 277 78 72 60 120 71 60

C HAMELEON D ISC’s principal additional persistent state. Each entry is created when a probe is sent and removed when it returns or expires. Consequently, the table is bounded by probes in flight rather than controller uptime. The mapping table in this case has around 50-83 entries, which is around 16kB. The next section evaluates the scalability via CPU and mapping table size with various topologies. Although ARP-based CamoType discovery relies on a static packet type and is theoretically targetable, manipulating such common data-plane traffic carries a high risk of exposure—contradicting the assumptions of our stealth-focused threat model. Manipulating IP-based CamoType discovery packets presents even greater risk since IP is the predominant packet type in network traffic, further discouraging adversarial interference. However, composing IP-based CamoType packets introduces considerable overhead because it requires dynamically collecting and analysing flow entries on each switch [6]. We therefore choose ARP-based CamoType.

Figure 9: CPU and Heap Overhead Under Attacks

Performance overhead under attacks

We measure C HAMELEON D ISC against the baseline implementation on the topology of Figure 3. Each configuration runs for 17 minutes, with three attack/recovery pairs injected at fixed intervals (Figure 9). CPU is sampled roughly once per second. Because JVM resident-set size does not reliably reflect live application memory, we measure post-GC live heap from the JVM garbage-collection log and validate it with a forced full collection at the end of each run. As Figure 9 shows, attacks and recoveries do not visibly perturb CPU or retained memory. On average, C HAMELEON D ISC uses 46.6% CPU versus 33.6% for the baseline, an increase of 13.0 percentage points, although C HAMELEON D ISC approximately doubles periodic discovery probes by transmitting both DecoyType and MorphType. The live-heap distributions substantially overlap: C HAMELEON D ISC settles around 199 MB versus 193 MB for the baseline (179–208 MB versus 184–198 MB). The packet-to-link-src mapping is

Latency Distribution

Figure 10 shows the latency distributions for link-up and link-down events, Figure 11 shows the distribution under relay attacks, and Figure 12 shows the distribution when monitored links experience 50% packet loss.

Discussion

Limitations. C HAMELEON D ISC targets common reactive forwarding setups that avoid coarse-grained flow rules matching in-port. In purely proactive networks — rare 19

Figure 10: Latency Distribution While Link Up and Down

Figure 12: Latency Distribution While 50% Packet Loss involved.

Open Science We provide an anonymized artifact containing the source code, experiment scripts and configurations, raw evaluation data, and analysis scripts used in this paper. https: //anonymous.4open.science/r/ChameleonDisc-B484/

Figure 11: Latency Distribution While Relay Attack in practice — MorphType becomes ineffective, requiring administrators to manually configure to-controller entries and rely on CamoType (e.g., ARP, IP). Compatibility with Hybrid SDNs. C HAMELEON D ISC’s core design — randomized discovery packets validated centrally — extends naturally to hybrid SDNs and other southbound interfaces (e.g., P4Runtime, BGP-based control). Adaptation primarily requires rethinking discovery initiation and packet-in processing, which we leave to future work. Open Source. Once accepted, we will release C HAMELEON D ISC as open source to foster collaboration and further improvements from the security and networking community.

Ethical Considerations

This work focuses solely on defense mechanisms. All referenced vulnerabilities are previously disclosed with public CVEs; no new vulnerabilities or human-subject data are 20

Record · ID 919303 · SHA-256 0502f0a600058376
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.