Now 5071 visitors
Today:0 Yesterday:0
Total: 147068 212S 50P 4R
2026-10-20, Week 43
Member Login
TACT Journal Homepage
Call for Paper
Committee
Find My Paper
Author Homepage
Statistics & History
Welcome Message
Paper Procedure
FAQ
Paper Archives
Outstanding Papers
Program & Proceedings
Presentation Platform
Hotel & Travel Info
Photo Gallery
Scheduler Login
Seminar
Archives Login
Sponsors


















Presentation Assistant Go to [Q&A Session]
Paper Number
Paper Title
Keyword
ICACT20260343 Slide.01        [Big Slide]      [YouTube] Chrome Click!!
Good morning everyone, and thank you for joining my presentation. Today I will present our work titled Distributed Trust-Guided DDoS Defense for Information-Centric Networking Using a Name Resolution Service. I am Jiangfeng He, and this work is co-authored with Yang Li from the Institute of Acoustics, Chinese Academy of Sciences. Our research focus is novel DDoS defense for NRS-based ICN, and the key idea is to combine distributed trust with federated learning to defend against attacks that specifically target resolution and forwarding resources.
ICACT20260343 Slide.02        [Big Slide]      [YouTube] Chrome Click!!
Here is the roadmap for today. First, I will introduce the motivation, and why NRS-based ICN changes the security landscape. Second, I will review background and related work, and explain why existing ICN defenses do not transfer well. Third, I will formalize the attack model, focusing on cache pollution and forwarding exhaustion. Fourth, I will walk through our trust-based framework, including DID-based identity, credit evaluation, trust synchronization, and federated learning. Fifth, I will show our ns-3 simulation evaluation, including baselines and results. Finally, I will summarize conclusions and future work.
ICACT20260343 Slide.03        [Big Slide]      [YouTube] Chrome Click!!
Let me start with the big picture. Networking is evolving from a host-centric, IP-style model to a more content-oriented model, because future applications demand large-scale content delivery with strict latency and availability requirements. In that context, Information-Centric Networking, or ICN, becomes an attractive candidate because it forwards based on names or identifiers and relies on in-network caching. However, when ICN is implemented using a Name Resolution Service, the architecture becomes more scalable and flexible, but it also introduces a new attack surface—especially around resolution and forwarding state.
ICACT20260343 Slide.04        [Big Slide]      [YouTube] Chrome Click!!
On this slide, I want to explain why we even need ICN and why the NRS-based design matters. In traditional IP networking, the model binds names to addresses, and the control and data planes are tightly coupled. This creates scalability and security limitations, especially when content volume and mobility keep increasing. ICN shifts the focus: instead of where is the server, we ask what is the content, and the network can cache data along the path. This naturally reduces repeated backbone traffic and improves user-perceived latency because popular content can be served closer to the edge. Now, ICN designs split into two families. One is pure name-based routing, like NDN or CCN, where routers maintain PIT, FIB, and CS tables and do per-hop name-prefix forwarding. The other is NRS-based ICN, where a separate name resolution system maps identifiers to forwarding hints or locators, and the control plane can distribute forwarding state in a more protocol-agnostic way. This separation improves scalability, but it also means the security bottlenecks move to the resolution–control loop.
ICACT20260343 Slide.05        [Big Slide]      [YouTube] Chrome Click!!
This slide highlights the core security problem. In NRS-based ICN, attackers can exploit two major weaknesses. First, cache pollution: the attacker manipulates request patterns so caches store low-reuse objects, pushing out popular content. When cache hits drop, more traffic falls back to resolution and producers, which increases load on NRS and control plane. This creates a reinforcing loop: worse caching leads to more resolution, which increases latency and further stresses the system. Second, forwarding exhaustion: the attacker targets the resolution–control–forwarding chain by triggering frequent resolution and rule installation or removal. Forwarding tables are limited, and control-plane bandwidth is limited, so repeated rule churn can delay or block legitimate forwarding setup. The important point is that many existing ICN defenses assume hop-by-hop router state, but in NRS-based ICN, the attack pressure concentrates on the NRS cluster and the centralized control logic.
ICACT20260343 Slide.06        [Big Slide]      [YouTube] Chrome Click!!
Now I will summarize what we contribute. Our first contribution is a distributed trust-based defense framework for NRS-based ICN that binds traffic to Decentralized Identifiers, or DIDs, and regulates access based on multi-factor behavioral credit scores derived from resolution and caching behavior. Second, we design a lightweight gossip protocol to synchronize trust across resolution domains, and we introduce credit-aware policy enforcement so that credit directly controls rate limiting, forwarding priority, and caching decisions. Third, we integrate a federated learning module that enables cross-domain detection of low-rate or collaborative attacks, without sharing raw traffic data. That preserves privacy and keeps coordination traffic modest. And the key innovation is this closed loop: identity and behavior continuously feed into resolution, forwarding, and caching decisions, so the system can selectively prioritize trustworthy requesters and suppress malicious patterns.
ICACT20260343 Slide.07        [Big Slide]      [YouTube] Chrome Click!!
Next, I will briefly position this work in the literature. I will compare classic IP-based DDoS defenses with ICN security mechanisms, then explain the limitations of existing approaches for NRS-based ICN, and finally show why emerging tools like DIDs and federated learning are promising—but still require deeper integration with ICN policies.
ICACT20260343 Slide.08        [Big Slide]      [YouTube] Chrome Click!!
Traditional DDoS mitigation in IP networks is fundamentally built around addresses, hierarchical name-to-address mappings, and centralized trust anchors. At the IP layer, defenses include filtering, rate limiting, and traceback. DNS security hardens name servers and enforces authentication and access control. More recently, reputation systems and ML-based intrusion detection also appear, but they still assume host-centric addressing. In ICN, security is name-centric and cache-centric. Attacks like interest flooding, cache pollution, and content poisoning exploit name-based forwarding and caches. Existing defenses often monitor per-router state such as PIT occupancy, satisfaction ratio, and cache hit behavior, and apply pushback or admission control. So the mismatch is clear: IP defenses assume addresses; many ICN defenses assume per-hop name-based router state.
ICACT20260343 Slide.09        [Big Slide]      [YouTube] Chrome Click!!
This slide explains why existing ICN defenses are inadequate for our setting. First, many defenses depend on per-hop state, like PIT, FIB, and CS tables, and continuous measurement of per-name statistics at each router. In NRS-based ICN, forwarding nodes do not necessarily maintain the same fine-grained per-name counters, because resolution is delegated to NRS. Second, many approaches rely on static thresholds, such as fixed satisfaction ratio thresholds. Static thresholds are fragile under dynamic traffic patterns and can be evaded by low-rate attacks. Third—and most importantly—bottlenecks migrate in NRS-based ICN. The main targets become the NRS cluster and the control plane that installs forwarding rules. So hop-by-hop defenses are difficult to port directly. Finally, existing defenses often treat consumers as effectively anonymous, driven by aggregate counters, which prevents the system from exploiting long-lived, per-requester trust history.
ICACT20260343 Slide.10        [Big Slide]      [YouTube] Chrome Click!!
So what can help? We see three relevant research directions. One is blockchain or PKI-like trust anchors for ICN content authenticity. Another is Decentralized Identifiers and Verifiable Credentials, which provide self-sovereign identity with cryptographic proofs. The third is federated learning-based intrusion detection, which allows collaborative training without sharing raw data. But there is an integration gap: many of these systems exist as overlays or generic security services. They do not directly feed trust or anomaly signals into identifier resolution, forwarding, and caching policies—which is exactly what NRS-based ICN requires. That gap motivates our framework: integrate identity, trust evaluation, and federated learning tightly into the NRS-based ICN control loop.
ICACT20260343 Slide.11        [Big Slide]      [YouTube] Chrome Click!!
Now I will formalize the threat model. We focus on two representative attacks in NRS-based ICN: cache pollution and forwarding exhaustion. I will start with attacker capabilities, then detail each attack mechanism, and finally define the evaluation scenarios and metrics we use later.
ICACT20260343 Slide.12        [Big Slide]      [YouTube] Chrome Click!!
We assume the attacker can control compromised hosts at multiple access points or edge nodes, so the attack is distributed. The attacker can craft arbitrary identifier-based requests, including valid and invalid identifiers, semantically similar names, and short-lived dynamic names, and can choose rates and distributions—high-rate, bursty, or mixed patterns. The attacker’s goal is not necessarily to compromise the controller, but to degrade availability and performance: increase resolution and forwarding latency, lower cache hit ratio, and cause rule churn. We also acknowledge advanced threats like Sybil identities, collusion, and federated learning poisoning. In this work, we assume consortium-controlled DID enrollment and authenticated updates, and we leave deeper study of those advanced threats to future work.
ICACT20260343 Slide.13        [Big Slide]      [YouTube] Chrome Click!!
Now let’s look at cache pollution. The attacker manipulates request distributions so caches fill with low-reuse objects, pushing out popular content. In NRS-based ICN, this is tightly coupled to the resolution–cache loop: when cache hit ratio drops, more requests need resolution and producer access, which increases NRS load and control-plane work, exacerbating latency and churn. Typical vectors include: Long-tail or random requests, which generate high-entropy name distributions so caches are constantly refreshed. Similar-name occupation, where names look syntactically close to popular ones but map to useless content. Dynamic naming, where frequent name changes prevent reuse even for logically identical content. So, in short: cache pollution is not just a cache issue—it amplifies NRS and control-plane stress.
ICACT20260343 Slide.14        [Big Slide]      [YouTube] Chrome Click!!
Next is forwarding exhaustion. Here the attacker targets the resolution–control–forwarding chain and limited forwarding rule capacity. By forcing frequent resolution and rule installation or removal, the attacker can exhaust forwarding table space or saturate control-plane bandwidth, delaying legitimate rule setups. Typical vectors include: High-rate invalid-identifier requests, triggering repeated resolution attempts. Dynamic short-lived sessions, where targets change rapidly, forcing frequent updates and rule churn. Mixed requests, combining valid and invalid traffic to increase decision complexity and latency. Attack patterns can be centralized in one domain or distributed across domains to maximize desynchronization and delay.
ICACT20260343 Slide.15        [Big Slide]      [YouTube] Chrome Click!!
For evaluation, we consider three scenarios: First, single-domain persistent pollution, with attackers concentrated in one resolution domain. Second, distributed forwarding exhaustion, where attackers spread across several domains to stress multiple NRS clusters and forwarding tables. Third, hybrid attacks, combining pollution and exhaustion with intermittent bursts and dynamic naming. We measure three metrics: F1-score for detection accuracy, combining precision and recall. Request Success Ratio, or RSR, the fraction of requests that obtain valid responses. Cache Hit Ratio, or CHR, the fraction of requests served from in-network caches. These metrics together tell us whether we detect attacks, keep service available, and preserve caching efficiency.
ICACT20260343 Slide.16        [Big Slide]      [YouTube] Chrome Click!!
Now I will present our framework, which we call DT-NRS, meaning Distributed Trust for NRS-based ICN. The framework integrates four components: DID-based identity, multi-factor credit evaluation, trust synchronization with credit-aware policies, and federated learning-aided detection. The goal is to build a closed loop where observed behavior continuously informs resolution, forwarding, and caching decisions.
ICACT20260343 Slide.17        [Big Slide]      [YouTube] Chrome Click!!
Let’s walk through the architecture. Component A is DID-based identity management, binding each entity to a stable identity to enable accountability. Component B is a multi-factor credit model computed from resolution and caching behavior. Component C is trust synchronization via a lightweight gossip protocol, so domains share trust views without a centralized database. Component D is federated learning detection, enabling collaborative detection of low-rate, cross-domain attacks without sharing raw traffic. Together, these components form a closed loop: identity and behavior lead to credit; credit guides policies; and federated learning enhances detection and feeds back into credit updates.
ICACT20260343 Slide.18        [Big Slide]      [YouTube] Chrome Click!!
Now I will focus on identity. We use W3C Decentralized Identifiers as the identity foundation. The control plane maintains DID documents and public keys over a consortium-controlled registry or ledger, while the data plane uses cached verified key digests and validates lightweight credentials—such as JWT-like credentials carried in requests—so that we avoid expensive per-request identity resolution on the fast path. Enrollment is controlled by a domain authority: it issues or endorses the DID document and records it in the domain registry. Key rotation and revocation are supported by updating the DID document or adding a revocation entry. We also include cold-start protection: newly enrolled entities start at a neutral credit level and face conservative rate limits until sufficient observations accumulate, limiting abuse. So the takeaway is: DIDs let us maintain long-lived accountability without relying on centralized identity authorities, while keeping fast-path verification lightweight.
ICACT20260343 Slide.19        [Big Slide]      [YouTube] Chrome Click!!
ow, how do we compute trust? For each entity u, at an edge node we summarize behavior over time using two categories of features: long-term statistics and recent observations, derived from resolution and cache behavior within a sliding window. We normalize features and form a combined feature vector. Then we use a linear scoring function, followed by a logistic transform to obtain an instantaneous credit. To smooth short-term fluctuations and capture longer-term behavior, we apply exponential smoothing, where alpha is 0.7 to balance stability and responsiveness. Finally, we map credit into five trust levels: trusted, normal, under observation, high-risk, and malicious. Intuitively, if a DID consistently exhibits low resolution success or low cache hit behavior—patterns consistent with pollution or exhaustion—its credit will drop, and policy enforcement will progressively restrict it.
ICACT20260343 Slide.20        [Big Slide]      [YouTube] Chrome Click!!
Local credit is useful, but attackers can move across domains. So we synchronize trust views. We use a lightweight gossip protocol that runs every 2 seconds. In each round, a node randomly selects one or two neighbors and sends a summary of the top 50 DIDs whose credit changed beyond a threshold 0.1. Each summary record includes a tuple like DID, credit, timestamp, signature. Receivers keep the latest valid signed record and update local credit accordingly. Because each node exchanges only O records per round with a constant number of neighbors, overhead stays small. In our simulations, the additional gossip traffic stays below about 2% of observed control-plane traffic. Now, how do we use credit? For forwarding and rate control, high-credit entities get priority and loose limits, while low-credit entities are throttled or blocked. For credit-aware caching, content requested by high-credit entities is preferentially cached and retained longer, while content induced by low-credit entities is generally not cached or is evicted first. So credit directly becomes an operational control knob for both caching and forwarding behavior.
ICACT20260343 Slide.21        [Big Slide]      [YouTube] Chrome Click!!
Even with credit evaluation, low-rate coordinated attacks may be weak at any single node but strong globally. This motivates federated learning. Each edge node maintains a local dataset, where the features are compressed behavior features and the labels indicate normal or attack derived from local rules and credit histories. We use a lightweight model and train collaboratively using FedAvg. Each round, selected nodes perform local updates and send model parameters to the controller, which aggregates them. Raw traffic never leaves local nodes, preserving privacy and reducing coordination overhead. In our experiments, the detector is a two-layer fully connected neural network with 32 hidden units and ReLU activation. Each selected node runs 3 local epochs with learning rate 0.01, and we perform 20 aggregation rounds. The federated learning output is used as an auxiliary signal to adjust credit: if the global model consistently assigns high anomaly scores to an entity across multiple domains, we scale down its instantaneous credit before smoothing, accelerating its transition toward high-risk or malicious classification. So federated learning helps us detect cross-domain patterns that local-only credit evaluation might miss.
ICACT20260343 Slide.22        [Big Slide]      [YouTube] Chrome Click!!
Now I will move to evaluation. We implement DT-NRS in ns-3, extending it to support ICN with explicit name resolution and SDN-style control, and then evaluate against representative baseline defenses adapted from NDN literature and ML-based detection.
ICACT20260343 Slide.23        [Big Slide]      [YouTube] Chrome Click!!
Here is our simulation setup. We use an ns-3 topology with 20 edge nodes, 10 cache nodes, and 2 content producers. Edge nodes are grouped into multiple resolution domains, each served by a local NRS cluster. We have 300 legitimate users and 200 malicious users. Benign users follow a Zipf-like popularity distribution with parameter 0.7, while attackers follow the cache pollution and forwarding exhaustion models, including high-entropy names, similar-name pollution, invalid identifiers, and dynamic short-lived names. Each simulation runs for 250 seconds. Attacks start at 40 seconds and stop at 200 seconds, so we observe both attack and recovery phases. System parameters include 10 Mb/s link capacity, 10 ms propagation delay, cache size of 1000 Data packets with LRU replacement, and a content namespace of 10,000 objects.
ICACT20260343 Slide.24        [Big Slide]      [YouTube] Chrome Click!!
We compare DT-NRS against five representative defenses adapted to the same environment: 1. Token-based control-plane mitigation 2. Congestion-aware rate control 3. FITT-like feedback throttling 4. Cache-filtering or cache shield against pollution 5. Isolation Forest anomaly detection These baselines represent classic thresholding, feedback, cache admission filtering, and an unsupervised ML method—so we cover a broad range of strategies.
ICACT20260343 Slide.25        [Big Slide]      [YouTube] Chrome Click!!
Now let’s look at detection accuracy. Across all three scenarios—pollution, exhaustion, and hybrid—DT-NRS achieves the highest F1-scores: roughly 0.94 under cache pollution, 0.96 under forwarding exhaustion, and 0.95 under hybrid attacks. The best baselines remain around 0.82 to 0.92, depending on the scenario. The key message is that combining behavioral credit with federated learning improves detection accuracy substantially, especially when attacks span multiple domains or use low-rate evasion. In practice, higher F1 means we both catch more attacks and avoid unnecessary throttling of legitimate users.
ICACT20260343 Slide.26        [Big Slide]      [YouTube] Chrome Click!!
Detection accuracy is important, but users care about service. During the attack window, baselines show a clear drop in Request Success Ratio and Cache Hit Ratio, often falling below 80% RSR and 65% CHR. DT-NRS degrades more slowly and recovers faster. At the worst point, RSR stays around 88 to 90 percent, meaning roughly nine out of ten legitimate requests still succeed even under sustained attacks. Meanwhile, CHR remains close to 70 percent, indicating that caching still works effectively and continues to offload the backbone and origin servers during attacks. So DT-NRS does not just detect attacks—it preserves availability and cache efficiency, which are the key promises of ICN.
ICACT20260343 Slide.27        [Big Slide]      [YouTube] Chrome Click!!
Finally, we evaluate overhead. On the fast path, credit updates and feature extraction are constant-time operations per request with constant-size metadata lookup, so per-request processing overhead is lightweight. On the control path, trust synchronization exchanges only top-M summaries every Tg seconds. With M equals 50 and Tg equals 2 seconds, per-node communication cost is bounded and remains small. In our simulations, the added gossip traffic stays below about 2% of observed control-plane traffic. For federated learning, we communicate only model parameters rather than raw traffic. The model is lightweight, so coordination remains modest while still enabling cross-domain learning. So overall, DT-NRS is designed to be practical for edge deployments where overhead must remain low.
ICACT20260343 Slide.28        [Big Slide]      [YouTube] Chrome Click!!
Now I will conclude. I will summarize the key findings, highlight the main research implications, and then describe future directions, including larger-scale validation and deployment considerations for emerging scenarios like 6G edge and Industrial IoT.
ICACT20260343 Slide.29        [Big Slide]      [YouTube] Chrome Click!!
Let me restate the main takeaways. First, we show that NRS-based ICN introduces new vulnerabilities to cache pollution and forwarding exhaustion, because attacks stress the resolution and control loop rather than only per-hop router state. Second, we propose DT-NRS: a distributed trust framework where entities are bound to DIDs, credit is computed from resolution and cache behavior, and trust is synchronized across domains via lightweight gossip. Third, our simulation results demonstrate strong performance: detection F1 improves by about 10 percentage points compared to representative defenses, while maintaining RSR around 88–90% and CHR around 70% during attacks. And the core innovation is that we exploit per-requester trust information—rather than treating consumers as anonymous—while using federated learning to capture cross-domain coordinated behavior.
ICACT20260343 Slide.30        [Big Slide]      [YouTube] Chrome Click!!
In terms of implications, this work suggests that combining distributed identity, behavioral trust evaluation, and federated learning provides a viable, privacy-preserving defense model for multi-domain ICN deployments. It is practical because overhead is low, and it is resilient because trust adapts to behavior rather than relying on static thresholds. For future work, we plan to validate the framework on a large-scale physical testbed with more realistic traffic and heterogeneous hardware. We also want to explore deployment in emerging scenarios such as 6G edge computing and Industrial IoT, where lightweight decentralized security is critical. Finally, we will study more advanced threats in depth, including Sybil identities, collusion, and federated learning poisoning, potentially using robust aggregation and outlier filtering strategies.
ICACT20260343 Slide.31        [Big Slide]      [YouTube] Chrome Click!!
That’s the end of my presentation. Thank you very much for your attention. I’m happy to take questions and discuss any details—whether about the attack models, the credit design, gossip synchronization, federated learning, or the ns-3 evaluation.