Internet-Draft Decentralized Threat Signaling Protocol December 2025
Luo Expires 19 June 2026 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-luo-orasrs-decentralized-threat-signaling-00
Published:
Intended Status:
Standards Track
Expires:
Author:
Z. Luo
OraSRS Protocol

Decentralized Threat Signaling Protocol (DTSP) using OraSRS

Abstract

This document specifies the Decentralized Threat Signaling Protocol (DTSP), a mechanism for distributed edge clients to collaboratively detect, report, and mitigate network threats. The protocol defines a state machine for threat lifecycle management (T0-T3), a standardized data format for threat signaling, and security mechanisms to prevent abuse in a permissionless environment.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 19 June 2026.

▲

Table of Contents

1. Introduction

The increasing sophistication of network attacks requires a collaborative defense mechanism that operates at the edge. Centralized threat intelligence systems suffer from single points of failure and latency issues. DTSP enables a decentralized network of edge clients to share threat intelligence in real-time, leveraging a blockchain-based consensus mechanism for verification.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Protocol Logic

The lifecycle of a threat in DTSP is modeled as a Finite State Machine (FSM). Each edge client maintains the state of detected threats.

3.1. State Machine

The FSM consists of the following states:

  • IDLE: No threat detected.

  • OPTIMISTIC_BLOCK (T0): Local detection of suspicious activity. Immediate local mitigation.

  • REPORTED (T1): Threat evidence submitted to the network.

  • VERIFIED (T2): Network consensus reached. Threat confirmed.

  • GLOBAL_ENFORCE (T3): Global propagation of the threat signature.

  • EXPIRED: Threat entry validity period ended.

3.2. State Transitions

3.2.1. T0: Local Detection

The Edge Client MUST transition to the OPTIMISTIC_BLOCK state immediately upon detection of traffic matching local heuristic rules (e.g., high-frequency connection attempts).

In this state, the client:

  1. MUST block the source IP locally.

  2. SHOULD generate a ThreatEvidence package.

3.2.2. T1: Signaling

The Edge Client MUST transition to the REPORTED state after generating valid evidence. The client sends a ThreatSignal message to the network. To prevent front-running, the client MUST use a Commit-Reveal scheme:

  1. Commit: Send Hash(Evidence + Salt).

  2. Reveal: Send Evidence + Salt after a random delay.

3.2.3. T2: Verification

The state transitions to VERIFIED when the network (via Smart Contract or Oracle) validates the evidence. A threat is considered verified if: Sum(Reputation(Reporters)) > Threshold.

3.2.4. T3: Global Enforcement

Upon entering the GLOBAL_ENFORCE state, the threat signature is added to the Global Blocklist. All participating clients MUST synchronize this list and enforce blocking rules via their local kernel datapath (e.g., eBPF).

4. Data Format

4.1. Threat Signal

The ThreatSignal message is used to report a detected threat. It is serialized using JSON.

+-----------+-----------+-----------------------------------------+
| Field     | Type      | Description                             |
+-----------+-----------+-----------------------------------------+
| version   | uint8     | Protocol version (e.g., 1)              |
| type      | uint8     | Threat type (0=DDoS, 1=Scan, 2=Malware) |
| source_ip | bytes     | IP address (4 or 16 bytes IPv4/IPv6)    |
| target_ip | bytes     | Victim IP (Optional)                    |
| timestamp | uint64    | Unix timestamp of detection (ms)        |
| evidence  | bytes     | Cryptographic proof or log snippet      |
| signature | bytes     | Digital signature of reporting client   |
+-----------+-----------+-----------------------------------------+

4.2. Evidence Package

Table 1
Field Type Description
packet_dump bytes Sample of malicious packets (pcap)
flow_stats struct Flow statistics (PPS, BPS, duration)
heuristics string ID of the heuristic rule triggered

5. Security Considerations

5.1. Sybil Attack Defense

To prevent Sybil attacks where an adversary creates multiple identities to flood the network with false reports, DTSP utilizes a Reputation System.

  • Each client MUST stake tokens to participate in reporting.

  • The weight of a report is proportional to the client's ReputationScore.

  • ReputationScore increases with valid reports and decreases with false positives.

5.2. Commit-Reveal Mechanism

To prevent "free-riding" (copying others' reports) or front-running:

  1. Clients MUST NOT broadcast raw evidence immediately.

  2. Clients MUST broadcast Commit = Hash(Evidence + Salt).

  3. After T_reveal blocks, clients MUST broadcast Reveal = (Evidence, Salt).

  4. The network verifies Hash(Reveal) == Commit.

6. IANA Considerations

This document has no IANA actions.

7. Informative References

[OraSRS]
Luo, Z., "OraSRS: A Compliant and Lightweight Decentralized Threat Intelligence Protocol", , <https://doi.org/10.31224/5985>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

Author's Address

Z. Luo
OraSRS Protocol