Network Working Group Z. Luo Internet-Draft OraSRS Protocol Intended status: Standards Track 16 December 2025 Expires: 19 June 2026 Decentralized Threat Signaling Protocol (DTSP) using OraSRS draft-luo-orasrs-decentralized-threat-signaling-00 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. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Luo Expires 19 June 2026 [Page 1] Internet-Draft Decentralized Threat Signaling Protocol December 2025 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Protocol Logic . . . . . . . . . . . . . . . . . . . . . . . 2 3.1. State Machine . . . . . . . . . . . . . . . . . . . . . . 2 3.2. State Transitions . . . . . . . . . . . . . . . . . . . . 3 3.2.1. T0: Local Detection . . . . . . . . . . . . . . . . . 3 3.2.2. T1: Signaling . . . . . . . . . . . . . . . . . . . . 3 3.2.3. T2: Verification . . . . . . . . . . . . . . . . . . 3 3.2.4. T3: Global Enforcement . . . . . . . . . . . . . . . 4 4. Data Format . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Threat Signal . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Evidence Package . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5.1. Sybil Attack Defense . . . . . . . . . . . . . . . . . . 4 5.2. Commit-Reveal Mechanism . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Informative References . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 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: Luo Expires 19 June 2026 [Page 2] Internet-Draft Decentralized Threat Signaling Protocol December 2025 * 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. Luo Expires 19 June 2026 [Page 3] Internet-Draft Decentralized Threat Signaling Protocol December 2025 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 +=============+========+======================================+ | 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 | +-------------+--------+--------------------------------------+ Table 1 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. Luo Expires 19 June 2026 [Page 4] Internet-Draft Decentralized Threat Signaling Protocol December 2025 * 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", 2025, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Author's Address Z. Luo OraSRS Protocol Luo Expires 19 June 2026 [Page 5]