]> OraSRS Protocol

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.

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.

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 when, and only when, they appear in all capitals, as shown here.

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.

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.

State Transitions

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.

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.

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.

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).

Data Format

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

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

Security Considerations

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.

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.

IANA Considerations This document has no IANA actions.

Informative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.